scif_yar | Заявления и реальность

Заявления
Как пишет CNews со ссылкой на портал Telegraf.by, взлом АИС «Паспорт» открыл им доступ к важной информации, касающейся белорусских силовиков. По утверждению киберпартизан, в их распоряжении теперь имеются персональные данные руководителей целого ряда силовых структур Белоруссии. Вместе с этим у них есть сведения о сотрудниках Комитета госбезопасности (КГБ), а также людей, входящих в близкое окружение Президента Белоруссии Александра Лукашенко.
https://www.iksmedia.ru/news/5845470-Kiberpartizany-zayavili-o-vzlome.html

Реальность - внутренний слив. То есть система изначально построена таким образом, что можно дернуть разом все данные, с любого места - что кто-то и сделал. И свалил.
Ошибки проектирования, ошибки эксплуатации.

Вообще мы уже давно все живем в стеклянном доме, а с биометрией и мониторингом кто куда ходил по рожам (уже в работе года три, а то и пять) и машинам - совсем стеклянном.

Flat | Top-Level Comments Only

From:

elglin

А ты попробуй на салфетке прикинуть, как ты доступ так будешь разграничивать.
У тебя же есть табличка Persons, в которой ВСЕ. Ну она партиционирована, скорее всего, и, возможно, пошардена, но права-то одни и те же на все записи. То есть если у тебя есть SELECT * FROM Persons;, то ты на коне уже. Ты можешь сколько угодно говорить, что у тебя там разграничение на уровне приложеньки, но приложенька же идет сервисным аккаунтом к базе, и кто-то, сука, этот пароль знает... ну или знает пароль от пароля и так далее, строго quis custodiet ipsos custodes.
А если ты хочешь это пофедерировать в том смысле, что у тебя есть Persons, ImportantPersons и VeryImportantPersons, то это тоже можно, но у тебя сложность лезет вверх ну очень сильно.

From:

scif_yar

>>А ты попробуй на салфетке прикинуть, как ты доступ так будешь разграничивать.
-
Изян. Ставится не стык приложенька - база, а приложенька - апишечка -база, причем с очень ограниченным функционалом, и главное с а)задержкой в 2 секунды на запрос б)не более 50 запросов от одного имени в) постановкой на контроль при более чем 20 запросах г)авто взводом флага "алярм" при запросе контрольных юзеров - которых вживую или нет (хани пот ас-из) или это руководство.

From:

elglin

Ну окей, ты убрал с атаки стык приложенька-база, теперь под атакой стык апишечка-база. Что не отменяет того, что давать доступ к базе Только и Исключительно через анально огороженную апишечку есть хорошо и правильно.
Я тут скорее к чему - то, что ты описываешь, это хорошая такая защита от юзера, у которого должен быть кокойто доступ, но которому явно не положено иметь все (про суточную квоту запросов я ни фига не подумал, кстати). А я больше про защиту от одмина, который имеет жырный доступ ко всему.
Единственное, что приходит в голову, это то, что в базенке лежат шифрованные данные, дешифратор отдельный и дергается только апишечкой, огороженной, как ты сказал. Тогда получается, что админ БД может сгрузить базенку, но удачи с поломкой шифра, владелец шифра вообще ничего не может, а владелец апишечки может нафармить сколько-то юзеров, но не всех.

Но это все усложняет систему и требует тщательной архитектуры - проще херакнуть незапароленный Эластик, нет времени объяснять.

From:

scif_yar

>>Тогда получается, что админ БД может сгрузить базенку, но удачи с поломкой шифра, владелец шифра вообще ничего не может, а владелец апишечки может нафармить сколько-то юзеров, но не всех.
-
Искаропки давным давно
Transparent Data Encryption - с 2008 SQL
https://efsol.ru/articles/encryption-means-microsoft-sql-server.html

https://docs.microsoft.com/ru-ru/sql/relational-databases/security/encryption/sql-server-encryption?view=sql-server-ver15

---
>>я больше про защиту от одмина, который имеет жырный доступ ко всему.
-
Какой?
Компутер стоит в анальной выгородке, никакого физического доступа.
Вместо терминала - тонкий клиент с огороженной USB. любые диски и носители - Only In.
Бекап - на шифрованные кассеты. Ключ отдельно торчит.

From:

scif_yar

>>я больше про защиту от одмина, который имеет жырный доступ ко всему.
-
Скажем так, я в курсе о существовании мест, где ты вход на этаж согласуешь две недели, и потом за тобой ходит специально обученный лейтенант в штатском. Который может и не очень понимает в джойн лефт, но ему и не надо - ему надо чтоб ты "туда" не втащил телефон (на входе сдаешь), не дергал диски и вообще не делал резких и не понятных движений. Там может внутри сто раз стоять admin|admin (но нет), но у тебя возможности что-то стащить не так чтоб много.
Ну это в нормальной практике.
Так то вон - гомо-архивом ЗК заведует

From:

antontsau.livejournal.com

я в дазах банных ни хрена не рублю конечно, но неужели в распространенных глюкалках нет функционала жесткого линка, ну типа селект фром (персонс) И (уровень не выше "мелкий начальник"), и никак иначе, а просто селект фрок зарезан КЕМ? И этот самый уровень зависит от привилегий лезущего?

From:

elglin

Я вот тоже не ДБА, но кмк в том же постгресе этого функционала нет, только GRANT ON . Теоретически ты можешь делать вьюхи, которые как раз SELECT FROM Persons WHERE rank <5; и давать доступы на них, но это на почитать только. Хотя никто не мешает дать тебе права на INSERT/UPDATE, но не SELECT, а SELECT только из вьюхи - и если вдуматься, это уже почти там, где надо.

From:

scif_yar

перенос функция из апишечки в БД и хранимочки возможен и ведет к махровому гомосексуализму

From:

scif_yar

>>ну типа селект фром (персонс) И (уровень не выше "мелкий начальник"), и никак иначе, а просто селект фрок зарезан КЕМ?
-
Есть в каком то виде. Называется "хранимые процедуры" (UPD - ну и вьюхи тоже в целом). Но это по сути установка той же прокладки что и апи, только на уровень ниже и не спасает от медленной утечки - то есть у тебя стоит приложение, которое тыкает в экран и делает скрины, например.

Edited Date: 2021-10-25 11:22 am (UTC)

From:

antontsau.livejournal.com

как минимум это закрывает от всяких младших дворников, которым Все Знать неположено. Старший дворник, ну и уборщица с мастерключом, разумеется доступ все равно имеют и могут хотя бы через просмотры все вытягивать.