KMS и шифрование

Dropbox хранит 750 петабайт пользовательских файлов. Один мастер-ключ = одна точка отказа всей инфраструктуры. Capital One потерял данные 100M клиентов в 2019 из-за S3 без шифрования. Как построить шифрование, которое масштабируется на эксабайты и переживает компрометацию любого отдельного ключа?

• **Dropbox** использует envelope encryption для всех файлов: DEK на файл, KEK в собственном KMS на базе HSM
• **Stripe** ротирует CMK раз в 365 дней автоматически и хранит секреты только в Vault, нигде не в коде
• **Capital One 2019**: 100M кредитных заявок украдены через SSRF из EC2 без шифрования - инцидент на $190M

Envelope Encryption

У Dropbox хранится 750 петабайт пользовательских файлов. Шифровать каждый файл напрямую мастер-ключом нельзя: компрометация ключа = потеря всех данных, ротация = перешифровка 750 ПБ. Решение - **envelope encryption**: данные шифруются одноразовым data key (DEK), а DEK хранится зашифрованным под мастер-ключом (KEK). Это два уровня и две операции.

При записи: генерируется DEK (AES-256), данные шифруются DEK, DEK шифруется KEK (вызов KMS), зашифрованный DEK сохраняется рядом с данными. При чтении: достаём зашифрованный DEK, расшифровываем его в KMS, расшифровываем данные локально. KEK никогда не покидает HSM, нагрузка на KMS минимальна (только короткий DEK).

**Why two layers?** Прямое шифрование больших объёмов через KMS - дорого ($0.03/10k вызовов) и медленно (1 RPS на ключ). DEK - локальная операция через AES-NI, миллионы операций в секунду. KMS отвечает только за защиту маленького зашифрованного DEK.

CMK: Customer Master Key

**CMK (Customer Master Key)** - это и есть KEK в envelope encryption. В AWS KMS живёт в HSM (Hardware Security Module), сертифицированном FIPS 140-2 Level 3. Ключ никогда не экспортируется в открытом виде; все операции (Encrypt, Decrypt, GenerateDataKey) выполняются внутри HSM.

Три типа CMK по управлению: **AWS-managed** (например, `aws/s3` - бесплатно, но без контроля политики), **customer-managed** ($1/мес + вызовы, но кастомная policy и ротация), **AWS-owned** (невидимы клиенту, используются внутренними сервисами). Доступ управляется через **key policy** (на самом ключе) + IAM policy (на пользователе) - оба должны разрешать операцию.

**kms:ViaService** ограничивает использование ключа конкретным AWS-сервисом. Это защита от exfiltration: даже скомпрометированная роль не сможет дешифровать данные напрямую, только через S3/RDS/etc.

Secrets Manager

Пароль от PostgreSQL хранится в `.env`, копируется в Docker-образ, попадает в CI-логи, читается всеми инженерами. Это типичная ситуация в стартапе. **AWS Secrets Manager** (или HashiCorp Vault, GCP Secret Manager) - сервис для централизованного хранения секретов с шифрованием через KMS, аудитом через CloudTrail и API для приложений.

Приложение не хранит пароль локально - оно вызывает `GetSecretValue` при старте или раз в час. Secrets Manager расшифровывает значение через CMK и возвращает по IAM-разрешению. Все обращения логируются: видно, кто и когда читал секрет.

**Secrets Manager vs Parameter Store** в AWS: Parameter Store бесплатен для standard tier, но без автоматической ротации и с лимитом 4 КБ. Secrets Manager - $0.40/секрет/месяц, но даёт ротацию через Lambda и нативную интеграцию с RDS/Redshift.

Ротация ключей и секретов

Пароль от продакшен-БД не менялся 3 года - типичная картина. Через 3 года: уволилось 5 инженеров (но они помнят пароль), копия пароля валяется в десятке мест, при leak менять придётся в 20 сервисах. **Ротация** - регулярная смена секрета без downtime. Для CMK: AWS делает это автоматически раз в год. Для секретов: ротация через Lambda.

Ротация делается в 4 шага (модель AWS): **createSecret** (Lambda генерирует новый пароль), **setSecret** (применяется в БД), **testSecret** (проверка соединения с новым), **finishSecret** (новый промотится в текущую версию `AWSCURRENT`, старый получает метку `AWSPREVIOUS`). Приложения, читающие секрет каждый час, переключатся автоматически.

Период между шагами **setSecret** и **finishSecret** - окно с двумя действующими паролями: старый ещё работает (приложения кэшируют), новый уже работает. Это **намеренный overlap** - без него ротация валит сервис.

Ключевые идеи

• **Envelope encryption** разделяет ключи на два уровня: DEK для локальных операций, KEK в HSM для защиты DEK - решает проблему масштаба и ротации
• **CMK customer-managed** даёт контроль над политикой, ротацией и удалением; AWS-managed ключи не подходят для compliance-сценариев
• **Secrets Manager** заменяет хранение паролей в .env централизованным сервисом с аудитом через CloudTrail
• **Автоматическая ротация** через Lambda с 4 шагами и overlap-окном делает ротацию безопасной для приложений
• **kms:ViaService и key policy** - защита от exfiltration: ключ работает только через целевой AWS-сервис

Связанные темы

Возвращаясь к 750 ПБ Dropbox: envelope encryption делает шифрование масштабируемым, ротация - ограничивает blast radius, secrets manager убирает пароли из кода. Эта инфраструктура связана с:

• IAM и контроль доступа — Key policy и IAM policy совместно решают, кто может расшифровать секрет - без IAM шифрование бесполезно
• Compliance и логирование — CloudTrail логирует каждый KMS Decrypt и каждый GetSecretValue - база для SOC2/PCI-аудита и forensic-анализа

Вопросы для размышления

• Стартап на 5 разработчиков выбирает между Parameter Store ($0) и Secrets Manager ($0.40/секрет/мес). Когда экономия 100 долларов в месяц перестаёт оправдывать отсутствие ротации?
• Envelope encryption защищает от компрометации KEK через ротацию. Но что если KMS-сервис целиком скомпрометирован (insider threat в AWS)? Какие архитектурные решения существуют против этой угрозы?
• Ротация раз в 90 дней - стандарт compliance, но для долгоживущих соединений (Kafka между ЦОД) overlap-окно может быть часами. Где граница между безопасностью и операционной сложностью?

Связанные уроки

• cloud-13 — IAM контролирует доступ к KMS ключам
• cloud-15 — KMS audit log - основа compliance
• bc-06-digital-signatures — KMS - centralized key management vs blockchain distributed
• bc-07-ecc — ECC ключи используются в cloud KMS
• bt-04-dns-tls — TLS certificates управляются через KMS
• net-23-https-tls — HTTPS private keys хранятся в KMS