Защита баз данных в банке: DAM, маскирование и контроль доступа
База данных в банке — это место, где одновременно лежат деньги (остатки, проводки), персональные данные клиентов и банковская тайна. Поэтому защита БД строится не одной мерой, а несколькими слоями: контроль доступа и разделение полномочий администраторов (DBA), шифрование и маскирование данных, а сверху — мониторинг активности базы данных (Database Activity Monitoring, DAM), который видит и записывает, кто и какие запросы выполнял. **Если коротко:** межсетевой экран и антивирус не закрывают риск на уровне самой СУБД. Привилегированный администратор, скомпрометированная учётная запись приложения или выгрузка таблицы целиком — это события внутри базы, и поймать их можно только средствами, которые работают на этом уровне. Ниже разбираем слои защиты, сопоставляем типовые угрозы с мерами, даём чек-лист и показываем, куда смотреть в требованиях регулятора. Сравнить поставщиков по подтверждённым сигналам можно в [рейтинге защиты баз данных и DAM](/rating/database-security-db-activity-monitoring).
Визуальный контекст исследования
Изображение помогает быстро считать тему материала: инфраструктура, данные, доступы и контрольные точки, которые важно проверить перед выбором решения.
Рейтинги подрядчиков по теме исследования
Если после чтения нужен короткий список исполнителей, начните с профильных рейтингов cyber-index.ru: в них видны компании, кейсы, интервью, категории экспертизы и доверительный индекс.
Как проверять выводы исследования
Используйте материал как основу для shortlist: сопоставьте выводы с профилями компаний, связанными рейтингами, кейсами, интервью клиентов и источниками. Если в статье есть список источников, начинайте проверку с него; если источников мало, дополнительно запросите у подрядчика методику, baseline и примеры работ.
Авторы и проверка материала
У каждого исследования есть персональные авторы, профиль экспертизы, дата публикации, список источников и редакционная проверка выводов.
Авторы закреплены по теме исследования и опираются на практические разборы страниц, кейсов, источников и рыночных выборок.
В профиле автора указаны зона экспертизы, роль в редакции, регалии и темы, за которые он отвечает.
Материалы связаны с методологией cyber-index.ru, внутренними рейтингами, карточками компаний и источниками.
Позиции не продаются, выводы отделены от рекламы, а проверяемые утверждения поддержаны источниками и датами обновления.
Почему банковскую БД защищают отдельно
Периметр и рабочие станции защищают одни средства, а саму СУБД — другие. Между приложением и базой данных проходит поток SQL-запросов, и большинство критичных действий (массовое чтение таблицы клиентов, изменение остатков, выдача прав, удаление журналов) выглядят как легитимные операции. Сетевой экран их не отличит, а штатный аудит СУБД администратор при желании может отключить или почистить.
В банке к этому добавляется регуляторная рамка. Финансовые организации работают с персональными данными и банковской тайной, а Банк России предъявляет повышенные требования к защите информации в финансовой сфере (линейка стандартов и положений по информационной безопасности, включая национальный стандарт по защите информации финансовых организаций). Конкретные номера и редакции стоит сверять по действующим документам регулятора — но принцип устойчив: доступ к данным должен контролироваться, действия привилегированных пользователей — фиксироваться, а сами данные — защищаться шифрованием и обезличиванием там, где это применимо.
Слои защиты базы данных в банке
Защита БД работает как набор независимых рубежей: если один обойдён, срабатывает следующий. Ни один слой не заменяет остальные.
- **Контроль доступа.** Кто и к каким объектам базы вообще может обращаться: учётные записи, роли, права на уровне таблиц и столбцов, сетевые ограничения. Базовый принцип — минимально необходимые привилегии. - **Разделение полномочий DBA.** Администратор обслуживает базу, но не должен бесконтрольно читать и выгружать клиентские данные. Привилегированные действия выводятся под отдельный контроль и независимый аудит. - **Шифрование.** Данные «на диске» (at rest) и «в канале» (in transit) шифруются, чтобы кража файлов БД, резервных копий или перехват трафика не давали доступа к содержимому. - **Маскирование (обезличивание).** В тестовых, аналитических и сервисных контурах реальные значения (ФИО, номера карт, счетов) заменяются на правдоподобные, но ненастоящие — чтобы чувствительные данные не расползались за пределы продуктивной среды. - **Мониторинг активности (DAM).** Независимая от администратора БД фиксация запросов: кто, когда, с какого адреса, какой SQL выполнил, сколько строк затронул. DAM даёт аудит, оповещения по подозрительным шаблонам и доказательную базу для разбора инцидентов.
Вклад слоёв в защиту банковской БД
Редакционная оценка значимости слоя для типового банковского контура (0–100) по открытым практикам. Это не вендорский бенчмарк и не замена проектированию под вашу архитектуру.
Угроза → мера: что чем закрывается
Таблица сопоставляет типовые угрозы банковской БД со слоем защиты, который их закрывает. Большинство сценариев требует сочетания мер, а не одной.
| Угроза | Чем закрывается | Что это даёт на практике |
|---|---|---|
| Привилегированный DBA выгружает клиентскую базу | Разделение полномочий DBA + DAM | Действия админа фиксируются независимо и попадают в оповещения |
| Скомпрометирована учётная запись приложения | Контроль доступа (минимум прав) + DAM | Ограничен объём доступа; аномальные выборки видны в мониторинге |
| Кража файлов БД или резервной копии | Шифрование at rest | Без ключей содержимое нечитаемо |
| Перехват трафика между приложением и СУБД | Шифрование in transit (TLS) | Запросы и ответы защищены в канале |
| Утечка реальных данных из тестового контура | Маскирование данных | В не-боевых средах нет настоящих ПДн и реквизитов |
| Массовое чтение таблицы (SELECT всех клиентов) | DAM + контроль доступа | Аномалия по объёму строк фиксируется и блокируется/оповещает |
| Очистка журналов аудита администратором | DAM (независимый аудит) | Журнал ведётся вне контроля администратора БД |
| Неконтролируемый рост прав со временем | Контроль доступа + регулярная ревизия | Избыточные и «теневые» права выявляются и снимаются |
Где здесь DAM и почему он ключевой
Мониторинг активности базы данных — это слой, который делает остальные проверяемыми. DAM перехватывает SQL-трафик (через агент на сервере СУБД, сетевой сбор или встроенные механизмы) и ведёт независимый журнал: пользователь, источник, запрос, время, объём результата. Главное свойство — независимость от администратора базы: даже носитель максимальных прав не должен иметь возможности незаметно отключить или подчистить эту запись.
Поверх журнала DAM строит правила: оповещать при нетипичных выборках, при доступе к чувствительным таблицам вне рабочего окна, при массовом экспорте, при действиях привилегированных учётных записей. Это и закрывает «слепую зону» периметровых средств, и даёт банку доказательную базу для разбора инцидентов и ответа регулятору. Как именно устроен аудит запросов, разбираем в материале [Database Activity Monitoring: как устроен аудит запросов к СУБД](/research/kak-rabotaet-dam-audit-sql).
Чек-лист защиты БД в банке
Как выстроить защиту БД: 5 шагов
-
01
Классификация данных
Определите, какие таблицы и столбцы содержат ПДн, банковскую тайну и платёжные реквизиты — это вход для всех остальных мер.
-
02
Наведение порядка в доступах
Пересоберите роли по принципу минимальных привилегий, отделите администрирование от доступа к данным, уберите избыточные права.
-
03
Шифрование и маскирование
Включите шифрование данных на диске и в канале; настройте обезличивание для тестовых и аналитических сред.
-
04
Внедрение DAM
Подключите независимый мониторинг активности в режиме наблюдения, соберите базовый профиль запросов, затем включите правила и оповещения.
-
05
Регулярная ревизия
Поставьте на поток пересмотр прав, проверку правил DAM и сверку статуса средств защиты по реестрам.
Требования регулятора: на что смотреть
Для банка защита БД — это часть выполнения требований к информационной безопасности финансовых организаций. Банк России развивает линейку стандартов и положений по защите информации, к ним примыкает национальный стандарт по защите информации финансовых организаций. Не приводим здесь конкретные номера и редакции, чтобы не вводить в заблуждение: их нужно сверять по действующим документам регулятора на момент проекта.
Что стабильно требуется по сути: контроль и разграничение доступа, защита персональных данных, фиксация действий пользователей (особенно привилегированных), защита и хранение журналов, применение средств защиты с подтверждённым статусом. Для проверяемого выбора опирайтесь на первоисточники — [реестр отечественного ПО](https://reestr.digital.gov.ru/) и [реестр сертифицированных СЗИ ФСТЭК](https://reestr.fstec.ru/).
Как мы оцениваем поставщиков
cyber-index.ru не продаёт места в рейтинге. Поставщики средств защиты БД и DAM сравниваются по проверяемым сигналам: подтверждённые внедрения и кейсы, отзывы и интервью клиентов, внешняя репутация, специализация, прозрачность и свежесть данных. Поэтому статью стоит читать в связке с [рейтингом защиты БД и DAM](/rating/database-security-db-activity-monitoring): здесь — слои и критерии, там — сравнение конкретных компаний по подтверждённым фактам.
Следующий шаг
Разобрались со слоями защиты — переходите к сравнению поставщиков: **[рейтинг защиты баз данных и DAM →](/rating/database-security-db-activity-monitoring)**. Полезно прочитать рядом: [рейтинг российских DAM-систем](/research/reyting-dam-sistem-rossiya), [чем заменить Imperva и IBM Guardium](/research/zamena-imperva-guardium-dam) и [как устроен аудит запросов к СУБД](/research/kak-rabotaet-dam-audit-sql).
Частые вопросы
Чем защита БД отличается от обычного межсетевого экрана?
Межсетевой экран контролирует сетевой периметр, а защита базы данных работает на уровне самой СУБД и SQL-запросов. Многие критичные действия (выгрузка таблицы клиентов, изменение остатков, выдача прав) выглядят легитимно на сетевом уровне — поймать их можно только средствами уровня базы: контролем доступа, разделением полномочий DBA и мониторингом активности (DAM).
Что такое DAM и зачем он банку?
DAM (Database Activity Monitoring) — это независимый от администратора мониторинг активности базы: кто, когда и какой запрос выполнил, сколько строк затронул. Он даёт аудит, оповещения по подозрительным шаблонам и доказательную базу для разбора инцидентов, закрывая «слепую зону» периметровых средств.
Зачем разделять полномочия администратора БД?
Чтобы носитель максимальных прав не мог бесконтрольно читать, выгружать или незаметно менять клиентские данные и чистить журналы. Администрирование базы отделяют от доступа к содержимому, а привилегированные действия выводят под независимый аудит — это снижает риск внутренней утечки.
В чём разница между шифрованием и маскированием?
Шифрование защищает данные от посторонних (украденные файлы БД или перехваченный трафик без ключей нечитаемы), но авторизованный пользователь видит реальные значения. Маскирование заменяет реальные данные на правдоподобные ненастоящие — его применяют там, где настоящие значения не нужны: в тестовых, аналитических и сервисных контурах.
Каким требованиям регулятора должна отвечать защита БД в банке?
По сути регулятор требует разграничения доступа, защиты персональных данных, фиксации действий пользователей, защиты журналов и применения средств с подтверждённым статусом. Конкретные номера стандартов и положений нужно сверять по действующим документам Банка России, а статус средств — по реестру отечественного ПО и реестру сертифицированных СЗИ ФСТЭК.
Где сравнить конкретные DAM-системы и средства защиты БД?
В рейтинге защиты БД и DAM — там поставщики ранжированы по подтверждённым сигналам. Полезен и обзор российских DAM-систем.
Источники и метод проверки
База данных в банке — это место, где одновременно лежат деньги (остатки, проводки), персональные данные клиентов и банковская тайна. Поэтому защита БД строится не одной мерой, а несколькими слоями: контроль доступа и разделение полномочий администраторов (DBA), шифрование и маскирование данных, а сверху — мониторинг активности базы данных (Database Activity Monitoring, DAM), который видит и записывает, кто и какие запросы выполнял. **Если коротко:** межсетевой экран и антивирус не закрывают риск на уровне самой СУБД. Привилегированный администратор, скомпрометированная учётная запись приложения или выгрузка таблицы целиком — это события внутри базы, и поймать их можно только средствами, которые работают на этом уровне. Ниже разбираем слои защиты, сопоставляем типовые угрозы с мерами, даём чек-лист и показываем, куда смотреть в требованиях регулятора. Сравнить поставщиков по подтверждённым сигналам можно в [рейтинге защиты баз данных и DAM](/rating/database-security-db-activity-monitoring).