キーポリシー、グラント、条件

キーを作成することは仕事の半分にすぎません。残りの半分は、誰がキーを使用できるかを制御することです。KMSでは、複数のアクセス機構を組み合わせて使用します。

最も重要なのはキーポリシーです。これは、キーに直接アタッチされるリソースベースのポリシーです。

すべてのKMSキーには、アクセスに対する主要な権限を持つキーポリシーがあります。

• ほとんどのサービスとは異なり、KMSキーにはキーポリシーが必須です。
• キーポリシーがアクセスを許可していない場合、IAMポリシーだけでは許可できません。

そのため、キーポリシーがゲートキーパーになります。

KMSキーへのアクセスには、まずキーポリシーでIAMを有効化する必要があります。そのうえで、IAMとキーポリシーが組み合わさってアクセスを許可します。

デフォルトのキーポリシーには、アカウントのIAMプリンシパルにアクセスを許可するステートメントが含まれています。ただし、これはIAMポリシーによる制限を受けます。このステートメントがなければ、キーポリシーで直接指定されたプリンシパルだけがキーを使用できます。

グラントは、キーの使用を委任するための柔軟で一時的な方法です。

• 多くの場合はプログラムから、特定のプリンシパルに特定の操作を許可します。
• AWSサービスは、ユーザーに代わってキーにアクセスするためにグラントを使用します。

不要になったグラントは廃止または取り消しできるため、短期間の委任に適しています。

有効期間ときめ細かさで使い分けます。

• 長期的で広範なアクセスには、キーポリシーとIAMを使用します。
• きめ細かく一時的な権限にはグラントを使用します。サービスやアプリケーションが動的に作成することがよくあります。

短期的な要件であれば、グラントによってキーポリシーを編集せずに済みます。

KMSは、kms:ViaServiceなど、ポリシーで使用できる強力な条件キーをサポートしています。

ViaServiceを使うと、キーの使用を特定のAWSサービス経由のリクエストに限定できます（S3経由だけにする場合など）。これにより、プリンシパルはS3が呼び出した場合にのみ復号でき、直接復号することはできません。

暗号化コンテキストは、暗号化または復号とともに渡すキーと値のペアの集合で、操作に暗号学的に結び付けられます。

• 復号時には同じコンテキストを指定する必要があります。
• 監査のためにCloudTrailに記録されます。

ポリシーでは、kms:EncryptionContext条件を使って特定のコンテキストを必須にできます。

別のアカウントにキーの使用を許可するには、キーポリシーで外部アカウントを許可し、外部プリンシパルにもIAM権限が必要です。

これはクロスアカウントロールと同じ、双方の許可が必要なパターンです。つまり、リソースポリシー（ここではキーポリシー）と呼び出し元のIAMポリシーの両方で操作を許可する必要があります。

キーにも最小権限を適用します。

• キー管理者（キーを管理するユーザー）とキーユーザー（暗号化や復号を行うユーザー）を分離します。
• ユーザーに対するkms:*の使用は避けます。
• ViaServiceと暗号化コンテキストを使って、権限の範囲をさらに絞ります。

これにより、プリンシパルが侵害された場合の影響範囲を限定できます。

よくある間違いは、キーポリシーを編集してIAMを有効化するステートメントを削除することです。

これを削除すると、アカウント管理者でさえアクセスできなくなります。キーポリシーがゲートキーパーであるため、キーから完全に締め出される可能性があります。復旧できないキーにならないよう、必ずアカウントレベルの管理用プリンシパルをキーポリシーに残してください。

CloudTrail（コンテキストを含むすべてのKMS呼び出し）とIAM Access Analyzer（外部アクセスを許可するキーポリシー）を組み合わせて、各キーを使用できるユーザーと実際に使用しているユーザーを監査します。

定期的に確認することで、リスクになる前に過度に広範なキーポリシーを見つけられます。

KMSアクセスについて考えてみましょう。

KMSアクセスの制御方法を学びました。

• キーポリシーが主要なゲートキーパーであり、IAMで使用するにはキーポリシーによる有効化が必要です。
• グラントは、一時的できめ細かな委任を実現します。
• ViaServiceや暗号化コンテキストなどの条件によって、権限の範囲を絞り込めます。