Безопасность и СУБД: о чём надо помнить, подбирая средства защиты

Меня зовут Денис Рожков, я руководитель разработки ПО в компании "Газинформсервис", в команде продукта Jatoba. Законодательство и корпоративные нормы накладывают определенные требования к безопасности хранения данных. Никто не хочет, чтобы третьи лица получили доступ к конфиденциальной информации, поэтому для любого проекта важны следующие вопросы: идентификация и аутентификация, управление доступами к данным, обеспечение целостности информации в системе, регистрация событий безопасности. Поэтому я хочу рассказать о некоторых интересных моментах, касающихся безопасности СУБД.

В статье будет три части:

• Как защищать подключения.
• Что такое аудит действий и как фиксировать, что происходит со стороны базы данных и подключения к ней.
• Как защищать данные в самой базе данных и какие для этого есть технологии.

Защита подключений

Подключаться к базе данных можно как напрямую, так и опосредованно через веб-приложения. Как правило, пользователь со стороны бизнеса, то есть человек, который работает с СУБД, взаимодействует с ней не напрямую.

Перед тем как говорить о защите соединений, нужно ответить на важные вопросы, от которых зависит, как будут выстраиваться мероприятия безопасности:

• эквивалентен ли один бизнес-пользователь одному пользователю СУБД;
• обеспечивается ли доступ к данным СУБД только через API, который вы контролируете, либо есть доступ к таблицам напрямую;
• выделена ли СУБД в отдельный защищенный сегмент, кто и как с ним взаимодействует;
• используется ли pooling/proxy и промежуточные слои, которые могут изменять информацию о том, как выстроено подключение и кто использует базу данных.

Теперь посмотрим, какие инструменты можно применить для защиты подключений:

1. Используйте решения класса database firewall. Дополнительный слой защиты, как минимум, повысит прозрачность того, что происходит в СУБД, как максимум — вы сможете обеспечить дополнительную защиту данных.
2. Используйте парольные политики. Их применение зависит от того, как выстроена ваша архитектура. В любом случае — одного пароля в конфигурационном файле веб-приложения, которое подключается к СУБД, мало для защиты. Есть ряд инструментов СУБД, позволяющих контролировать, что пользователь и пароль требуют актуализации.

Почитать подробнее про функции оценки пользователей можно здесь, так же про MS SQL Vulnerability Assessmen можно узнать тут.

3. Обогащайте контекст сессии нужной информацией. Если сессия непрозрачная, вы не понимаете, кто в ее рамках работает в СУБД, можно в рамках выполняемой операции дополнить информацию о том, кто, что и зачем делает. Эту информацию можно увидеть в аудите.
4. Настраивайте SSL, если у вас нет сетевого разграничения СУБД от конечных пользователей, она не в отдельном VLAN. В таких случаях обязательно защищать канал между потребителем и самой СУБД. Инструменты защиты есть в том числе и среди open source.

Средства безопасности в коммерческих и open source СУБД

Таблица далеко не полная, но ситуация такая: в коммерческих продуктах задачи безопасности решаются давно, в open source, как правило, для безопасности используют какие-то надстройки, многих функций не хватает, иногда приходится что-то дописывать. Например, парольные политики — в PostgreSQL много разных расширений (1, 2, 3, 4, 5), которые реализуют парольные политики, но все потребности отечественного корпоративного сегмента, на мой взгляд, ни одно не покрывает.

Что делать, если нигде нет того, что нужно? Например, хочется использовать определенную СУБД, в которой нет функций, которые требует заказчик.

Тогда можно использовать сторонние решения, которые работают с разными СУБД, например, "Крипто БД" или "Гарда БД". Если речь о решениях из отечественного сегмента, то там про ГОСТы знают лучше, чем в open source.

Второй вариант — самостоятельно написать, что нужно, реализовать на уровне процедур доступ к данным и шифрование в приложении. Правда, с ГОСТом будет сложнее. Но в целом — вы можете скрыть данные, как нужно, сложить в СУБД, потом достать и расшифровать как надо, прямо на уровне application. При этом сразу думайте, как вы будете эти алгоритмы на application защищать. На наш взгляд, это нужно делать на уровне СУБД, потому что так будет работать быстрее.