Регулятор всё настойчивее спрашивает не только про защиту канала, но и про данные, которые лежат на дисках. Приказ ФСТЭК № 21 от 18.02.2013 прямо относит защиту машинных носителей и криптографические меры к мерам обеспечения безопасности персональных данных. ФЗ-152 и постановление № 1119 требуют закрыть актуальные угрозы – а кража или копирование файлов базы, бэкапа, снимка виртуальной машины относятся к угрозам вполне реальным. Шифрование данных при хранении (encryption at rest) перестало быть опцией для параноиков и стало пунктом, который проверяют на аттестации. Разберём, как подготовить промышленную СУБД к этому требованию без остановки бизнеса.

Что именно требует регулятор

Ключевой нюанс – нельзя взять первый попавшийся AES из библиотеки и отчитаться. Для информационных систем, обрабатывающих персональные данные, средства криптографической защиты должны быть сертифицированы ФСБ России (ГОСТ 28147-89, по новому стандарту – ГОСТ Р 34.12-2015 «Кузнечик»). Встроенный в СУБД зарубежный TDE на AES закроет техническую угрозу кражи файлов, но для формального соответствия его придётся дополнять сертифицированным СКЗИ – например, на уровне диска или контейнера через КриптоПро, ViPNet или «Континент».

Поэтому первый шаг – не настройка, а классификация. Определите уровень защищённости ИСПДн по 1119, постройте модель угроз и зафиксируйте, какие данные подлежат шифрованию: вся база, отдельные табличные пространства, бэкапы, журналы. Чем точнее граница, тем меньше лишней нагрузки.

Уровни шифрования и нагрузка

У шифрования при хранении есть три практических точки приложения:

  • Уровень диска или тома – прозрачно для приложения, закрывает кражу физического носителя и бэкапа, но не защищает от привилегированного доступа к работающей БД.
  • Уровень СУБД (TDE) – Oracle Advanced Security, MS SQL Transparent Data Encryption, для PostgreSQL – шифрование файловой системы или сторонние модули. Шифрует файлы данных и журналы, дешифрование происходит при чтении в память.
  • Уровень приложения / отдельных колонок – шифруем только чувствительные поля (паспорт, СНИЛС). Точно, но требует переработки кода и ломает индексацию по зашифрованным столбцам.

Платить придётся производительностью. На наших проектах TDE по табличному пространству добавлял 3–8% к нагрузке CPU при интенсивной записи. Это нужно мерить до внедрения, а не после жалоб пользователей. Включите детальный мониторинг – мы уже настраивали централизованный сбор логов и метрик на ELK, и в случае с шифрованием такая телеметрия позволяет отделить просадку от криптографии от обычных всплесков.

Отдельно про архитектуру: если система уже разрезана на сервисы, шифрование вписывается аккуратнее. Мы писали про это в итогах года на микросервисах – изоляция хранилищ означает, что защищать и аттестовывать можно один сервис, а не монолит целиком.

Управление ключами – узкое место

Сам алгоритм почти никогда не ломают. Ломают процесс хранения ключей. Если мастер-ключ лежит рядом с зашифрованной базой в открытом виде – шифрование декоративное. Поэтому выносите ключи в отдельное хранилище: аппаратный модуль (HSM), сертифицированный токен или хотя бы изолированный сервер с жёстким разграничением доступа.

Заранее пропишите регламент: ротацию ключей, процедуру при увольнении администратора, восстановление при потере. Потеря мастер-ключа означает потерю всех данных – резервная копия ключа и план восстановления обязательны и тестируются заранее.

Вывод

Подготовка к требованиям регулятора по шифрованию хранения – это последовательность: классификация ИСПДн → модель угроз → выбор сертифицированного СКЗИ → выбор уровня шифрования под нагрузку → регламент управления ключами. Технология вторична, первичны корректная граница защиты и работающий процесс с ключами – именно это закладывается на этапе проектирования информационной безопасности под аттестацию и реальную эксплуатацию.