AWS Key Management Service(KMS) part1
暗号化を支える暗号鍵
暗号化で実現できる性質
| 機密性 | 許可された人だけが対象の情報にアクセスできる性質 |
| 真正性 | 本物であることを確実に証明する性質 |
| 完全性 | データがすべて正確である状態を維持する性質 |
| 非否認性 | 当事者による行動をあとから否定されないようにする性質 |
上記の性質を保つため、暗号鍵は決して漏洩してはならない
暗号鍵の安全な管理において考慮すべきポイント
- 暗号鍵の保管
- どこに保管されているか
- 保管されているハードウェアは安全か
- 暗号鍵の管理
- 誰が、いつ、どこで、どのように使われるか
鍵自体のセキュリティを担保する管理の仕組みがあるか
IPA,CRYPTRECによる暗号鍵管理を安全に行うための考慮事項
上記のように暗号鍵管理の仕組みを構築・運用するには様々な検討が必要
暗号鍵の管理
Key Management Infrastructure : KMIを下記の要件を考慮し管理する必要性がある
- 暗号鍵の保管：鍵を安全に保管するストレージ、対タンパ性(※)を持つハードウェアセキュリティモジュール(HSM)
- 暗号鍵の管理：ライフサイクル管理、アクセス制御、モニタリング
(※)耐タンパ性とは、内部情報を不正に読み取られる・改ざんされることに対する耐性のこと。
AWS KMS概要
AWS Key Management Service (AWS KMS)
- KMIをAWSが運用するマネージドサービス
- 100以上のサービスと統合されている
- AWS CloudTrailなどのモニタリングサービスと統合され監査を実現
AWS KMSの概要
- KMSは鍵の保管をHSMで行い、暗号鍵の管理としてアクセス制御やライフサイクル管理を実現している
- S3やEBSなどのサービスでのデータの暗号化や署名に利用され、独自アプリにも適用が可能
- CloudTrailやCloudWatchと統合され、監査が可能
（誰が、いつ、どのAWSリソースからどのAWSリソースに対して、どのAPIを用いたか）
AWS KMSで扱う暗号鍵
エンベロープ暗号化
複数の暗号鍵を用いた暗号化方式
- データ暗号化鍵(Data Excryption Key:DEK)を用いてデータを暗号化
- DEKは別の暗号鍵(Key Encryption Key:KEK)を用いて暗号化
- DEKで暗号化されたデータと、KEKで暗号化されたDEKを一緒に保管し、平文のDEKは利用が終わり次第、廃棄
メリットは2層レイヤーでの暗号化によるデータの保護
- 暗号鍵の中央管理の簡易化
- KEKが安全に保管すべきルートとなるキー
- データの暗号化にDEKを利用するため、KEKの数を最小限に抑えられる
AWS KMSで扱う暗号鍵と暗号鍵ヒエラルキー
- ルートキーであるKEK：KMSキー
- DEK：データキー
KMSキーから、データキーを生成し、各サービスにおける暗号化は、エンベロープ暗号化によって実現
KMSキー：マスターとなる暗号鍵(KEK)
- 論理的な暗号鍵
- キーマテリアル（暗号鍵のもととなるプレーンテキスト）やメタデータなどがセットになっている単位で関連すデータを保管するコンテナ
- ローテーションなどを通じてキーマテリアルは変化するが、論理的なコンテナとしてのKMSキーはそのまま利用
- 暗号化された状態で耐久性の高いストレージに保管
- KMS外でキーマテリアルの利用エクスポートができないよう設計
KMSでは、コンテクスト（暗号化の所有、用途、利用できるリージョン、キーマテリアルのオリジン）に応じて暗号鍵の種別を選択可能
例：カスタマーマネージド、対称鍵、単一リージョン、KMSオリジン などを選択
KMSのデータキー：データを暗号化する暗号鍵(DEK)
- KMSアーキテクチャー外で利用する前提となっている
- 各AWSサービス側で利用される
- 利用が終わり次第、破棄される
- この取り扱いもマネージドで行われ、ユーザーが意識する必要はない
AWS KMSの鍵管理
ライフサイクル管理
KMSキーの作成から削除までのライフサイクル
例）
- 鍵の作成→Enabled(有効)
- 鍵の有効化/無効化→Disabled(無効)
- 鍵の削除→Pending Deletion(削除保留中)→指定期間経過→Detetion(削除)
キーの作成
GUI、API、IaCで作成
キーのローテーション
暗号化のベストプラクティスにおいて、暗号化キーの広範な再利用は推奨されない
有効なKMSキーを一定期間ごとにローテションする必要性
- 自動：キーマテリアル(キーID、キー用途などのメタデータを保管したコンテナ)を毎年追加、古いマテリアルも保存
- 手動：KMSキー自体を新たに作成、キーの参照の変更が必要
キーの削除
KMSキーの削除操作は元に戻せないため、無効化も活用を検討
7-30日間の削除待機期間を指定
削除予定の鍵のモニタリングで利用されていないかを確認することも重要
アクセス制御
IAM等と同じく、暗黙的な拒否＜明示的な許可＜明示的な拒否
各ポリシーは併用可能（併用前提）
キーポリシー
キーと１：１に紐づくリソースベースのパーミッション
- JSON形式
- キーごとにアクセス制御が行える
- キーポリシーの利用をアクセス制御運用上優先することがベストプラクティス
- GUIなどで作るとデフォルトではアカウントに対して有効だが、IAMポリシーでのアクセス許可にもキーポリシー内で許可が必要
※鍵の管理不能リスクを削減することも可能 - 鍵の管理者と鍵の利用者は操作できる権限を分けることが推奨（最小権限の原則）
IAMポリシー
プリンシパルベースのパーミッション
- JSON形式
- キーポリシーの利用を運用上で優先するが、キーポリシーでは制御できないKMSキーの作成操作の制御に有効
- キーの作成（CreateKey）権限を最小範囲に制限するための利用
- 権限を付与するKMSキー（Resource句）をポリシーで指定する
- Resource句でのワイルドカード”*”指定を避ける
- 他のAWSアカウントでのKMSキー操作に対する許可となるリスク
（例：キーの表示、ローテション設定確認、暗号/復号化に関わる操作）
グラント
クライアントによる他プリンシパルへのパーミッション委任
Part.2のスコープのため割愛
モニタリング
AWS CloudTrail
APIオペレーションのすべての呼び出しを記録される（キーマテリアルの自動ローテション等）
- KMS内部のオペレーションもすべて記録される
- デフォルトでは90日間保管のため、必要に応じて証跡を作成
- 平文情報などの機微情報はログから省略される
Amazon CloudWatch
KMSキーの重要なメトリクス・イベントについて監視やメールによるアラートが可能
- KMSに対するリクエスト数
- 削除保留中キーの利用
- キーの自動ローテーション
- キーの削除
AWS KMS暗号化技術の詳細
FIPS140-2セキュリティレベル3認証済みのHSM
- 暗号鍵は内部的に複数の処理で暗号化され、暗号処理のときのみHSM上で利用可能
- KMSアーキテクチャ外へのKMSキーのエクスポートはできない
- 平文のKMSキーはディスクに書き込まず、保護されたHSMの揮発性メモリでのみ利用
- FIPS140-2では、弱い暗号アルゴリズムの利用に制限
- KMSサービス内のアップデートではNIST認証のラボによる監査を受けて実施
KMSにおけるエンベロープ暗号化のフロー詳細
- クライアントによるデータキーの作成要求、呼び出し元のアクセス権限に基づき認証
- 認証に問題がなかった場合、KMSがユニークなデータキーを作成
- KMSキーをストレージから取り出し複合、データキーを暗号する
- 平文のデータキーと暗号化されたデータキーをクライアントに返却
- クライアントは平文のデータキーを利用してデータを暗号化し、利用後は即座に破棄、
暗号化されたデータと暗号化されたデータキーは一緒に保管する
上記のうち、KMSキーが利用される2と3の処理はHSM上でのみ行われている
KMSのコンプライアンス
- FIPS 140-2 セキュリティレベル3
- AWS System and Organaization Controls(SOC1,SOC2,SOC3)
- PCI DSS レベル1
- ISOおよびCSA STAR認証
- FedRAMP
- HIPAA