Комментарии 28
В MSSQL есть dynamic data masking из коробки.
Статическое маскирование данных – это подход, который позволяет при создании копии базы данных
...
Это означает, что вы можете передать такую копию базы данных даже разработчикам на аутсорсинге, не опасаясь утечек ценных данных.
Имхо копировать прод бд для тестового контура, тем более, чтобы передать аутсорс разработке это не гуд, принципиально неверный подход
Среди тысяч бд и таблиц всегда найдется то, что не замаскируется
А если данные полей в бд не были шифрованы на уровне приложения (с хранением ключей отдельно) до передачи в базу – вы всё равно подвержены риску утечки данных (sql-inj, rce, непропатченные сервера, etc...)
Для dev да. Но dev временно и подобрее присмотром все равно приходится пускать на прод, когда есть проблема, которая воспроизводится только на прод
Что касается шифрования полей, то это на мой взгляд очень тухлая вещь
А если данные полей в бд не были шифрованы на уровне приложения (с хранением ключей отдельно) до передачи в базу – вы всё равно подвержены риску утечки данных (sql-inj, rce, непропатченные сервера, etc...)
Но ведь можно было прочитать про https://learn.microsoft.com/ru-ru/sql/relational-databases/security/encryption/sql-server-encryption?view=sql-server-ver16 ???
Можно было и это почитать
Если говорить в терминах MSSQL (исхожу из данных по ссылке), то мой комментарий про режим Always Encrypted:
Always Encrypted-enabled driver installed on the client computer achieves this by automatically encrypting and decrypting sensitive data in the client application.
The driver encrypts the data in sensitive columns before passing the data to the Database Engine, and automatically rewrites queries so that the semantics to the application are preserved.
У разных бд свои решения, может некоторые и не поддерживают такое из коробки (redis/memcache?), может какие-то хорошо работают on premise или on cloud
Или поддерживают, но за счёт явного вызова функций [де]шифрования в самих запросах, с засвечиванием ключей (pgcrypto?) в различных логах
Также, когда по одному пользователю из миллионов все гигабайты данных необходимо мгновенно "превратить в мусор", потому что "удалите мои данные по GDPR" – проще удалить персональный ключ дешифровки данных этого пользователя, что уничтожит данные даже в годовых бэкапах без затрагивания этих самых бэкапов, которые таже могут оказаться в утечках
Среди тысяч бд и таблиц всегда найдется то, что не замаскируется
Ну это вопрос тщательности подхода и функционала инструмента, которым делается маскирование.
Вода жидкая, Заголовок не под катом.
Обобщение снижает точность данных, заменяя их диапазоном значений. Вместо «Бобу 28 лет» можно сказать «Бобу от 20 до 30 лет». Этот метод полезен для аналитики, так как данные остаются верными.
Перестановка перемешивает значения в рамках столбца. Исходные данные могут быть восстановлены, если алгоритм перестановки будет расшифрован.
Это как же у автора ЗНАЧЕНИЕ в базе будет заменено ДИАПАЗОНОМ ? Вместо INT поставим TEXT ?
Перестановка - тоже отличная идея, потому что ЗАЧЕМ???
Тоже сразу подумал об этом.
1) Случайное значение, близкое к оригинальному. К примеру если мы видим значения возраста 65 лет в базе, где целевая аудитория условные 18-40 это выдаст факт маскировки.
2) Реальные данные с нарушенными связями не позволят злоумышленнику быстро проанализировать их и понять, что данные были замаскированы.
А ещё в PAM Инфраскоп есть модуль контроля к БД с динамическим маскированиеи ☝?
Вот даже статейку писали, давненько правда:
Любой PAM будет хорошим дополнением к защите. Проблема обычно в том, что это решение намного дороже, чем замаскировать данные. А чаще наблюдаю, что компании вообще ограничиваются подписанием NDA с аутсорсером и успокаиваются. Как Буд-то это является 100% гарантией, что данные не утекут.
Как раз таки стоимость PAMa в маскировании теряется, да и нет ни у кого больше такого функционала, именно в одном решении.
Гарда вот чет тоже не три копейки стоит, но про бюджеты разговор вечный, вопрос же целесообразности и обоснования необходимости затрат.
Моя ремарка больше к тому чтобы дополнить список решений в статье.
В статье по ссылке (Инфраскоуп) про маскирование буквально два слова. Вы, видимо, в теме, а остальным сложно сравнивать.
Моя ремарка больше к тому чтобы дополнить список решений в статье.
Так статья про маскирование конкретно, а не про широкую безопасность. Если для широкой темы, то конечно можно было бы расширить список много чем.
про бюджеты разговор вечный, вопрос же целесообразности и обоснования необходимости затрат.
Согласен про вечность вопроса о бюджете. Но сделать руками маскирование с помощью штатных средств СУБД будет явно проще чем делать руками PAM.
Автор, вы хотя бы потрудились правильно названия компаний написать, просто открыв ссылки, что вы сами разместили
Публикации
Маскирование баз данных