要点: Encryptionの強度はIdentity、Key、運用Processで決まります。
課題
静的Secret、過剰権限、未設計Rotation、Shared・Dedicated Keyの曖昧さがRiskを増やします。
単純な対策だけでは不十分な理由
Application MemoryやLogもThreat Modelです。
Dedicated Tenant KeyはBlast Radiusを減らす一方、CostとRecoveryを増やします。
処理フロー
Workload Identity
短期Auth→Secret Manager
認可Delivery→KMS・HSM
Key Operation・Audit→Ciphertext
Version Key Ref
短期Auth→Secret Manager
認可Delivery→KMS・HSM
Key Operation・Audit→Ciphertext
Version Key Ref
アーキテクチャ上の判断
Envelope Encryption
Data KeyをMaster KeyでWrapします。
PolicyとStorage分離
CiphertextはKey Referenceだけを保持します。
Rotationを事前設計
Readerは複数Version、WriterはCurrentのみです。
さらに深く考える
Crypto-shreddingの証跡
Backup等を含むDeletion Guaranteeを定義します。
Emergency Access制限
Approval、Expiry、Auditを必須にします。
実装手順
- Secret・KeyのOwner、Consumer、Expiryを棚卸しします。
- Workload Identityで短期Credentialを取得します。
- Envelope EncryptionとKey Metadataを使います。
技術例: Version-aware Decrypt・Rotate
record = { ciphertext, wrappedDataKey, masterKeyVersion }
dataKey = kms.decrypt(record.wrappedDataKey, context = tenantId)
plaintext = decrypt(dataKey, record.ciphertext)
if record.masterKeyVersion != current:
enqueueRewrap(record.id)TenantとData ClassをEncryption ContextへBindします。
想定すべき障害パターン
- 旧Keyを早く無効化します。
- BackupにHistorical Keyがありません。
- DebugでPlaintextをExportします。
監視すべきシグナル
| シグナル | 確認する理由 |
|---|---|
| Secret・Key Age | Rotation遅延です。 |
| Decrypt・Deny率 | Incidentを検出します。 |
| Key Version別Record | Rotation進捗です。 |
設計の検証方法
- Mixed Version中にRotateします。
- 旧BackupをHistorical KeyでRestoreします。
- Wrong Tenant ContextでDecryptを試みます。
安全なRollout計画
Secret棚卸し、Workload Identity、重要DataのEnvelope Encryption、Rotation訓練の順で導入します。
本番前チェックリスト
- Source、Image、Log、CIにSecretを残しません。
- RotationにOverlapとRollbackがあります。
- Key AccessをLeast PrivilegeとAuditにします。
まとめ
Key ManagementはEncrypt CallでなくIdentity、Access、Rotation、RecoveryのLifecycleです。