Проблема: Несанкционированный доступ к данным корпорации со стороны провайдера облачных услуг (CSP), третьих лиц (инсайдеры, хакеры) или по запросу госорганов (вне юрисдикции РФ). Данные в покое (at rest) и в транзите (in transit) уязвимы к перехвату.

Причины:
1. Отсутствие контроля: Стандартное SSE (Server-Side Encryption) — ключи у провайдера. CSP может расшифровать данные.
2. Утечки ключей: Хранение мастер-ключей в том же облаке (Azure/AWS KMS без HSM).
3. Человеческий фактор: Неправильная настройка политик IAM (Identity and Access Management) — публичный доступ к бакетам.
4. Юридические риски: Cloud Act (США) и 242-ФЗ (РФ) — требования к предоставлению данных.

Решение:
1. Архитектура Zero Trust: Внедрить Client-Side Encryption (CSE) или End-to-End (E2EE) перед отправкой в облако.
- Генерация ключей локально (на клиенте).
- Использование HSM (Hardware Security Module) для хранения мастер-ключа.
2. Шифрование в покое (REST): AES-256-GCM + RSA-4096 для envelope encryption.
- Пример команды для локального шифрования файла перед загрузкой в S3:
bash
openssl enc -aes-256-gcm -salt -in file.txt -out file.enc -k "ваш_пароль" -pbkdf2

- Загрузка только `file.enc`.
3. Шифрование в транзите (TLS 1.3): Обязательно HTTPS с HSTS и Certificate Pinning.
4. Управление ключами:
- Никогда не хранить мастер-ключ у CSP. Использовать собственный HSM (например, на базе YubiHSM или AWS CloudHSM с выделенной VPC).
- Ротация ключей раз в 90 дней.
5. Интеграция с SIEM: Мониторинг access logs провайдера на предмет чтения метаданных (например, AWS CloudTrail с аномалиями).
6. Юридическая защита (РФ): Применение сертифицированных ФСБ криптосредств (КриптоПро CSP, VipNet) для шифрования до загрузки в облака зарубежных юрисдикций.

Итоговое правило: Никакой расшифровки на стороне CSP. Все ключи — только у клиента. Шифровать перед отправкой, а не после.