要点: 暗号化は、アイデンティティ、アクセス、キー、運用手順をまとめて管理して初めて安全になります。
この記事の用語: KMS：暗号鍵管理サービス。Envelope Encryption：データ鍵をさらにMaster Keyで保護する方式。
現場の課題
環境ファイルのシークレットは長期間残り、サービスには必要以上の権限が与えられがちです。どのデータがどの鍵を使うか分からなければローテーションも進みません。
単純な対策だけでは不十分な理由
すべてのサービスがMaster Keyを読めるなら暗号化の効果は限定的です。Workload Identity、最小権限、キー バージョン、ローテーション、復元を一つのライフサイクルとして管理します。
処理フロー
Workload Identity
短期Auth→シークレット Manager
認可Delivery→KMS・HSM
キー Operation・Audit→Ciphertext
バージョン キー Ref
短期Auth→シークレット Manager
認可Delivery→KMS・HSM
キー Operation・Audit→Ciphertext
バージョン キー Ref
アーキテクチャ上の判断
Envelope Encryption
データ鍵をMaster KeyでWrapします。
ポリシーとStorage分離
Ciphertextはキー Referenceだけを保持します。
ローテーションを事前設計
Readerは複数バージョン、WriterはCurrentのみです。
さらに深く考える
Crypto-shreddingの証跡
バックアップ等を含むDeletion Guaranteeを定義します。
Emergency アクセス制限
Approval、期限、Auditを必須にします。
実装手順
- シークレットとキーを、担当者、利用サービス、期限ごとに棚卸しします。
- 静的認証情報を配布せず、Workload Identityで短期シークレットを取得します。
- Envelope Encryptionを使い、暗号文と一緒にキー バージョンを保存します。
コード例: バージョン-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)テナントとデータ 種別を暗号化 コンテキストへBindします。
想定しておく障害
- 旧キーを早く無効化します。
- バックアップにHistorical キーがありません。
- DebugでPlaintextをデータ出力します。
監視すべきこと
| 指標 | 何が分かるか |
|---|---|
| シークレット・キー Age | ローテーション遅延です。 |
| Decrypt・Deny率 | 障害対応を検出します。 |
| キー バージョン別レコード | ローテーション進捗です。 |
設計の検証方法
- Mixed バージョン中にRotateします。
- 旧バックアップをHistorical キーで復元します。
- Wrong テナントコンテキストでDecryptを試みます。
本番導入の進め方
シークレットを棚卸ししてソースコードから除き、一サービスへ短期アイデンティティを導入します。重要なデータ種別からEnvelope Encryptionを適用し、ローテーションと復元を訓練して広げます。
本番前チェックリスト
- ソースコード、Image、ログ、CIにシークレットを残しません。
- ローテーションにOverlapとロールバックがあります。
- キー アクセスを最小権限とAuditにします。
まとめ
鍵管理はアイデンティティ、アクセス、ローテーション、復旧のライフサイクルであり、一度の暗号化処理ではありません。