Разберите, от каких угроз защищает шифрование данных в базе, если приложение расшифровывает их перед отправкой пользователю.
Шифрование базы защищает данные при компрометации носителя, резервной копии или дампа, если атакующий не получил ключи. Оно не защищает от скомпрометированного приложения, легитимного пользователя с разрешённым доступом или процесса, который уже расшифровывает данные. Граница защиты проходит там, где данные становятся доступными в открытом виде.
Шифрование данных «на хранении» появилось как мера защиты от кражи физических носителей, несанкционированного доступа к дискам, резервным копиям и снимкам баз данных. Оно дополняет контроль доступа: даже получив копию хранилища, нарушитель не должен автоматически получить содержимое.
Такой подход решает узкую проблему — компрометацию места хранения. Он не предназначен для защиты данных от компонента, которому по архитектуре разрешено их расшифровывать.
Предположим, база данных зашифрована, а приложение получает ключ и расшифровывает записи перед формированием ответа. Если злоумышленник украл диск или резервную копию, шифрование может остановить чтение данных.
Но при уязвимости приложения, компрометации его процесса или злоупотреблении разрешённой учётной записью атакующий может запросить расшифровку штатным способом. Дополнительные утечки возможны через журналы, кэш, временные файлы, трассировки и память процесса.
Нужно разделять угрозы по состоянию данных и точке атаки:
Эффективность зависит от управления ключами. Ключи не должны храниться рядом с базой в том же доступном атакующему контуре; важны разграничение прав, аудит операций с ключами, ротация и резервирование ключевого материала. При этом отдельное хранилище ключей не устраняет риск полностью: приложение всё равно должно получить временный доступ к ключу или операции расшифровки.
Для снижения риска применяют минимизацию данных, токенизацию или полевое шифрование отдельных чувствительных атрибутов. Полевое шифрование может ограничить доступ даже при чтении таблиц, но усложняет поиск, сортировку, аналитику, восстановление и управление ключами. Ни один из этих механизмов не заменяет авторизацию на уровне приложения.
Сервис хранит персональные данные клиентов в зашифрованной базе. Резервные копии выгружаются в отдельное хранилище, а ключ базы доступен приложению через систему управления ключами.
Рассматривались три варианта. Шифрование только диска было простым, но плохо защищало переносимые дампы и резервные копии. Шифрование всей базы с ключом в конфигурации приложения защищало копии без конфигурации, но создавало единый легко компрометируемый секрет. Полевое шифрование чувствительных полей уменьшало объём раскрываемых данных, но усложняло запросы и восстановление.
Выбрали шифрование базы и резервных копий с раздельным управлением ключами, ограниченными правами приложения и аудитом обращений к ключам. Для особо чувствительных полей добавили полевое шифрование и не записывали расшифрованные значения в журналы. В результате кража копии хранилища перестала быть достаточной для чтения данных, но контроль доступа к приложению и его процессу остался отдельной обязательной защитой.
Что изменится, если ключ хранится в отдельном сервисе, но приложение может расшифровать любую запись?
Разделение хранилища и ключей защищает от независимой компрометации базы, но не от злоупотребления самим приложением. Если приложение имеет широкое право расшифровывать любые записи, атакующий, получив контроль над ним, может использовать этот полномочий штатным образом. Поэтому нужны ограничение области доступа, контекстная авторизация, аудит и по возможности операции с ключами, не позволяющие приложению произвольно получить весь ключ.
Защищает ли шифрование базы от администратора базы данных?
Это зависит от архитектуры управления ключами. Если администратор имеет доступ и к зашифрованным данным, и к ключу либо к механизму расшифровки, шифрование обычно не создаёт эффективной границы против такого администратора. Защита возможна только при разделении полномочий, контроле операций с ключами и использовании схемы, где доступ к открытому содержимому требует независимого разрешения.
Почему шифрование отдельных полей не гарантирует отсутствие утечки через метаданные?
Даже без открытого значения могут быть видны идентификаторы записей, размеры шифротекста, частота обращений, время операций и связи между объектами. Эти сведения иногда позволяют вывести чувствительную информацию или сопоставить записи с внешними данными. Поэтому при оценке защиты нужно учитывать не только содержимое поля, но и доступные метаданные, журналы, индексы и шаблоны использования.