Тут можно в разные стороны порассуждать, смотря что именно вы хотите автоматизировать)
Например, коробочный DDM подразумевает в себе автоматизацию, это и есть принцип работы динамического маскирования. Если мы говорим, к примеру, про автоматическое маскирование новых таблиц, можно накрутить кастомные SQL-скрипты.
Можно встроить маскирование в CI/CD пайплайн, маскировать данные при деплое тестовой бд.
Кроме того на рынке много готовых решений, которые позволяют задать политики маскирования один раз и применять их ко всем данным. Так что вариантов много, все зависит от вашей потребности)
Боюсь, в современных реалиях невозможно полностью отказаться от хранения данных. Бизнесу нужны данные для своих процессов, к примеру, для проведения аналитики и обработки заказов. Да и законодательство может требовать хранения определённых данных. Минимизировать критичные данные — да, это одна из задач ИБ, храним только самое необходимое, и при этом защищаем.
Да, к сожалению, иногда приходится жертвовать удобством пользователей во имя безопасности. Та же самая нагрузка на процессор может стоить дешевле, чем последствия инцидента. Но поверьте, мы всегда взвешиваем риски и не вставляем палки в колеса просто так! В конце концов, мы тоже обычные пользователи и все эти правила касаются и нас, в том числе)
Как говорится, безопасность, как антивирус: иногда мешает работать, но когда срабатывает, все говорят спасибо:)
Благодарю за ценный комментарий! Описанный вами подход с дублирующей БД выглядит красиво, особенно для случаев, когда важно строго изолировать доступ. Что касается триггеров, немного упустила этот момент, упоминать их в рамках динамического маскирования в MySQL было не совсем уместно, поскольку select-триггеры отсутствуют. Их скорее можно встретить в сценариях, когда маскирование применяется на этапе записи (insert/update). Это очень хорошее замечание, спасибо, что обратили внимание!)
Отличное дополнение, благодарю! В статье я акцентировала внимание на технических аспектах, но безусловно, следует помнить про нормативные требования и сверяться с действующим законодательством.
В вопросах защиты данных почти всегда приходится искать компромисс между удобством разработки и безопасностью)
Маскирование на уровне СУБД позволяет централизованно управлять доступом к данным и снижает риски утечек, в том числе через ошибки в приложении. В критически важных системах безопасность нередко оказывается приоритетнее гибкости, но решение всегда зависит от контекста.
Спасибо за ваш комментарий!
Тут можно в разные стороны порассуждать, смотря что именно вы хотите автоматизировать)
Например, коробочный DDM подразумевает в себе автоматизацию, это и есть принцип работы динамического маскирования. Если мы говорим, к примеру, про автоматическое маскирование новых таблиц, можно накрутить кастомные SQL-скрипты.
Можно встроить маскирование в CI/CD пайплайн, маскировать данные при деплое тестовой бд.
Кроме того на рынке много готовых решений, которые позволяют задать политики маскирования один раз и применять их ко всем данным. Так что вариантов много, все зависит от вашей потребности)
Боюсь, в современных реалиях невозможно полностью отказаться от хранения данных. Бизнесу нужны данные для своих процессов, к примеру, для проведения аналитики и обработки заказов. Да и законодательство может требовать хранения определённых данных. Минимизировать критичные данные — да, это одна из задач ИБ, храним только самое необходимое, и при этом защищаем.
Благодарю за ваш комментарий!
Да, к сожалению, иногда приходится жертвовать удобством пользователей во имя безопасности. Та же самая нагрузка на процессор может стоить дешевле, чем последствия инцидента. Но поверьте, мы всегда взвешиваем риски и не вставляем палки в колеса просто так! В конце концов, мы тоже обычные пользователи и все эти правила касаются и нас, в том числе)
Как говорится, безопасность, как антивирус: иногда мешает работать, но когда срабатывает, все говорят спасибо:)
Благодарю за ценный комментарий!
Описанный вами подход с дублирующей БД выглядит красиво, особенно для случаев, когда важно строго изолировать доступ.
Что касается триггеров, немного упустила этот момент, упоминать их в рамках динамического маскирования в MySQL было не совсем уместно, поскольку select-триггеры отсутствуют. Их скорее можно встретить в сценариях, когда маскирование применяется на этапе записи (insert/update). Это очень хорошее замечание, спасибо, что обратили внимание!)
Верно, главное чтоб эти меры были не просто внедрены для галочки, а использовались эффективно)
Отличное дополнение, благодарю! В статье я акцентировала внимание на технических аспектах, но безусловно, следует помнить про нормативные требования и сверяться с действующим законодательством.
Прекрасно, надеюсь код поможет улучшить безопасность вашей системы!)
В вопросах защиты данных почти всегда приходится искать компромисс между удобством разработки и безопасностью)
Маскирование на уровне СУБД позволяет централизованно управлять доступом к данным и снижает риски утечек, в том числе через ошибки в приложении. В критически важных системах безопасность нередко оказывается приоритетнее гибкости, но решение всегда зависит от контекста.