Представьте: база данных зашифрована, но ключи лежат в том же хранилище. Какой защитный эффект останется после компрометации этого хранилища?
Практически никакого: если злоумышленник получает и зашифрованные данные, и ключи, шифрование не препятствует их расшифровке. Защитный эффект появляется, когда ключи хранятся и контролируются отдельно от данных, поэтому компрометация одного компонента не раскрывает второй автоматически.
Шифрование данных применяется для защиты информации при краже носителя, резервной копии или файлов базы данных. Однако хранение ключа рядом с зашифрованными данными сводит такую защиту к формальности: найденный контейнер содержит всё необходимое для восстановления исходной информации.
Из этой проблемы возник подход разделения данных и ключевого материала. Специализированные системы управления ключами, аппаратные модули безопасности и отдельные политики доступа позволяют ограничить круг компонентов, способных получить ключ.
Шифрование базы данных защищает содержимое только от тех, кто получил ciphertext, но не получил возможность расшифровать его. Если компрометированы файловое хранилище, резервная копия или снимок диска, а ключ находится там же и доступен тому же субъекту, атакующий обычно может восстановить данные.
Неверное решение создаёт ложное ощущение безопасности. Оно может быть полезно против случайного просмотра незашифрованного файла или физической потери носителя, но не против кражи полного набора данных вместе с ключами.
Ключ следует размещать в отдельном KMS или HSM, а доступ к нему выдавать по отдельной политике. Приложение или служба получает не свободный файл ключа, а ограниченную операцию расшифрования либо временный доступ, привязанный к своей идентичности и контексту.
Часто используется конвертное шифрование. Данные шифруются отдельным ключом данных, а этот ключ шифруется ключом, находящимся в KMS. В базе хранится ciphertext и зашифрованный ключ данных; для расшифрования требуется как доступ к базе, так и разрешение KMS.
Разделение не означает абсолютную безопасность. Если злоумышленник захватил приложение, которое легитимно может расшифровывать данные, он может извлекать plaintext через это приложение. Поэтому нужны минимальные привилегии, аудит обращений к ключам, сегментация, ротация, отзыв доступа и отдельная защита резервных копий.
Есть компромисс между безопасностью и доступностью. Потеря или блокировка ключевого сервиса может сделать данные недоступными, поэтому проектируют резервирование KMS, процедуру восстановления и контролируемое хранение резервных ключей. Ротация ключа-обёртки обычно не требует повторного шифрования всех данных, тогда как смена ключей данных может быть значительно дороже.
У аналитической платформы база и резервные копии хранились в одном объектном хранилище. Вариант с ключом в отдельном файле был прост и почти не требовал изменений, но при компрометации учётной записи хранилища раскрывал и данные, и ключ.
Вариант с ручным хранением ключа на отдельном сервере уменьшал риск совместной кражи, но создавал сложную процедуру доступа, единую точку отказа и слабую наблюдаемость. Был выбран KMS с отдельной ролью для приложения, журналированием операций расшифрования и резервным сценарием восстановления.
В результате кража резервной копии сама по себе перестала давать доступ к plaintext. При этом компрометация приложения всё ещё считалась отдельным сценарием и дополнительно ограничивалась областью ключей, доступных конкретной службе.
Вопрос: Достаточно ли хранить ключ в другом каталоге или в другой таблице той же базы?
Ответ: Нет, если тот же субъект с теми же полномочиями может получить и данные, и ключ. Важна не физическая разница расположения, а независимость границ доступа, учётных данных и контроля. Другой каталог может помочь от случайного удаления, но не от компрометации общего хранилища или общей административной учётной записи.
Вопрос: Защищает ли отдельный KMS от злоумышленника, который получил права приложения?
Ответ: Не обязательно. Если роль приложения разрешает расшифровывать любые данные, злоумышленник может использовать приложение или его учётные данные как легитимного клиента KMS. Поэтому разрешения ограничивают по службе, ключу, операции и по возможности по контексту запроса, а обращения к KMS контролируются и журналируются.
Вопрос: Что именно нужно менять при ротации ключа-обёртки в конвертном шифровании?
Ответ: Обычно достаточно повторно зашифровать хранящиеся ключи данных новым ключом-обёрткой. Большие массивы данных при этом не нужно сразу расшифровывать и шифровать заново, что снижает стоимость и риск простоя. Полное перешифрование данных всё же может потребоваться при компрометации ключа данных или по требованиям к криптографическому сроку его использования.