Спроектируйте базовую стратегию шифрования данных «в покое» (at rest) и «при передаче» (in transit) для связки: вычислительные инстансы, объектное хранилище и управляемая база данных.

Короткий ответ

Для данных at rest включают шифрование дисков, объектного хранилища и базы данных средствами провайдера (с ключами провайдера или собственными ключами через KMS), а для in transit принудительно используют TLS для всех соединений между компонентами, не полагаясь на «доверенную» внутреннюю сеть как достаточную защиту.

Как это работает подробнее

шифрование at rest защищает данные на физическом носителе провайдера и обычно прозрачно для приложения; шифрование in transit защищает данные от перехвата при передаче по сети, в том числе внутри облака, где трафик может проходить через общую инфраструктуру.

Пример кода

example.txtКопировать

EBS volume: encrypted=true, kms_key=customer-managed-key
S3 bucket: default encryption SSE-KMS, bucket policy requires aws:SecureTransport=true
RDS instance: storage_encrypted=true, require_secure_transport=ON (sslmode=require на клиенте)

Что использовать на практике

• Рекомендация. включают шифрование at rest при создании ресурса по умолчанию, используют собственные ключи шифрования там, где нужен контроль над ротацией и отзывом; для in transit терминируют TLS на балансировщике и дополнительно требуют TLS для соединения приложение-БД и HTTPS-эндпоинты объектного хранилища.
• Проверка. попытка подключиться к базе данных без TLS должна быть отклонена сервером, а запрос к bucket по обычному HTTP должен быть заблокирован политикой bucket.

Подводные камни

• Риск. считать, что раз трафик «внутри VPC», TLS не нужен, и оставлять соединение приложение-БД без шифрования
• Риск. включать шифрование диска, но забывать про шифрование резервных копий/снапшотов
• Риск. использовать управляемые провайдером ключи там, где комплаенс требует собственных ключей с возможностью отзыва.