Комментарии 23
Не забывайте, что в некоторых случаях необходимо соблюдать требования:
Федеральный закон № 152-ФЗ "О персональных данных" от 27.07.2006:
Определяет понятие обезличенных данных
Устанавливает требования к обезличиванию персональных данных
Приказ ФСТЭК России от 11.01.2017 № 3 "Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных":
Содержит требования к техническим средствам обезличивания данных
ГОСТ Р ИСО/МЭК 29100-2014 "Информационная технология. Защита данных. Рамочная модель конфиденциальности":
Описывает методологию обезличивания данных
ГОСТ Р ИСО/МЭК 29198-2-2016 "Информационная технология. Защита данных. Методы обезличивания данных. Часть 2. Техники обезличивания":
Предоставляет рекомендации по методам обезличивания
Постановление Правительства РФ от 01.11.2012 № 1119 "Об утверждении правил определения категории защищенности объектов обработки персональных данных":
Учитывает степень обезличивания при категорировании объектов
Положение Банка России от 25.06.2018 № 613-П "О требованиях к защите информации, составляющей банковскую тайну":
Содержит требования к обезличиванию банковских данных
Приказ Минкомсвязи России от 25.03.2014 № 125 "Об утверждении Административного регламента Федеральной службы по надзору в сфере связи, информационных технологий и массовых коммуникаций по предоставлению государственной услуги по осуществлению контроля соблюдения операторами персональных данных требований законодательства Российской Федерации о персональных данных":
Включает проверку соблюдения требований к обезличиванию данных
Спасибо большое! Пошел копировать части кода себе)
То есть часть функционала приложения, причем критическая, выносится на уровень СУБД.
В целом усиливает интегрированность и ухудшает модифицируемость в будущем, потребует более глубокой переделки, это минус...
В вопросах защиты данных почти всегда приходится искать компромисс между удобством разработки и безопасностью)
Маскирование на уровне СУБД позволяет централизованно управлять доступом к данным и снижает риски утечек, в том числе через ошибки в приложении. В критически важных системах безопасность нередко оказывается приоритетнее гибкости, но решение всегда зависит от контекста.
removed
В PostgreSQL и MySQL динамическое маскирование можно реализовать с помощью триггеров, представлений или расширений. Например, вы можете создать представление, которое возвращает маскированные данные в зависимости от пользователя
В MySQL это решается созданием "дублирующей БД", которая вместо таблиц содержит маскирующие представления с опцией SQL SECURITY DEFINER к таблицам основной БД.
Соответственно учётной записи того, кто должен работать с маскированными данными, даётся право SELECT на дублирующую БД, и отбираются все права на реальную. И от имени такой УЗ можно смотреть только маскированные данные.
В то же время разработчик, имеющий права на чтение и редактирование обеих БД, может для проверки своей работы просто переключаться между базами одним коротким USE databasename и смотреть, как работает один и тот же запрос и с маскированием, и без.
PS. И не понял, каким боком тут триггеры затесались - вроде триггеры для SELECT ещё пока нигде не реализованы.
Благодарю за ценный комментарий!
Описанный вами подход с дублирующей БД выглядит красиво, особенно для случаев, когда важно строго изолировать доступ.
Что касается триггеров, немного упустила этот момент, упоминать их в рамках динамического маскирования в MySQL было не совсем уместно, поскольку select-триггеры отсутствуют. Их скорее можно встретить в сценариях, когда маскирование применяется на этапе записи (insert/update). Это очень хорошее замечание, спасибо, что обратили внимание!)
Светлана, спасибо! Видел, что во многих компаниях вопрос с шифрованием и маскированием всегда важен.
Еще для смежной задачи (своевременное обнаружение утечек) - есть способ с "канарейками". Например, создаем фейк-юзера с паролем 123456 и пристально следим за логами. Реального юзера за ним нет, он никогда не залогинится. Но если вдруг залогинился - значит, кто-то угнал нашу базу юзеров. Аналогично, например, с ключами доступа к AWS - создаем специальный аккаунт, которым не пользуемся. И если кто-то воспользовался - поздравляю, кто-то влез на сервер и читает наши конфиги.
Все эти варианты ломаются на одном вопросе - должен быть доверенный человек, который сохраняет ключи шифрования. Что бы мы не придумали, нам нужен человек. Человек, которому можно доверять в этом вопросе. Хоть какую систему придумывай по защите, она в конце - концов опирается на человека.
Хоть симетричное шифрование, хоть любое другое - всегда есть главный ключ. И хотел бы я ошибаться.
Разработчики и DBA выражают благодарность всем безопасникам! Что бы мы без вас делали!
Больше логов богу логов! Ведь у нас ещё есть свободное место на дисках. Больше паразитной нагрузки на процессор, фигли он на 80% прохлаждается.
И, да, обязательно меняйте пароли каждые 3 месяца на такие, которые невозможно запомнить и приходится записывать. На всех экземплярах разные!
Б - Безопасность!
Благодарю за ваш комментарий!
Да, к сожалению, иногда приходится жертвовать удобством пользователей во имя безопасности. Та же самая нагрузка на процессор может стоить дешевле, чем последствия инцидента. Но поверьте, мы всегда взвешиваем риски и не вставляем палки в колеса просто так! В конце концов, мы тоже обычные пользователи и все эти правила касаются и нас, в том числе)
Как говорится, безопасность, как антивирус: иногда мешает работать, но когда срабатывает, все говорят спасибо:)
Боюсь, в современных реалиях невозможно полностью отказаться от хранения данных. Бизнесу нужны данные для своих процессов, к примеру, для проведения аналитики и обработки заказов. Да и законодательство может требовать хранения определённых данных. Минимизировать критичные данные — да, это одна из задач ИБ, храним только самое необходимое, и при этом защищаем.
Спасибо за статью! Подскажите, есть ли возможность автоматизировать процесс маскирования?
Спасибо за ваш комментарий!
Тут можно в разные стороны порассуждать, смотря что именно вы хотите автоматизировать)
Например, коробочный DDM подразумевает в себе автоматизацию, это и есть принцип работы динамического маскирования. Если мы говорим, к примеру, про автоматическое маскирование новых таблиц, можно накрутить кастомные SQL-скрипты.
Можно встроить маскирование в CI/CD пайплайн, маскировать данные при деплое тестовой бд.
Кроме того на рынке много готовых решений, которые позволяют задать политики маскирования один раз и применять их ко всем данным. Так что вариантов много, все зависит от вашей потребности)
Была схожая проблема и мы решили ее с помощью Инфраскоп (PAM) , оказалось в нем есть DAM и DDM и проблему решили руками вендора
Очень интересно и полезно! Спасибо большое за материал
А в магазине Озона когда-нибудь будет поиск по заказам?
Оч. навороченная система Delphix для маскирования, заодно и оптимизация разворачивания тестовых сред и сред разработки.
Маскирование данных от А до Я