AWS認定 DevOpsエンジニア - プロフェッショナルには合格したものの、触れば触るほど「AWSなんも分からん……」と言う感じでダニング＝クルーガー効果を地で行く毎日。
本日はKMSとIAMにハマった話。
[KMSとは]
AWS Key Management ServiceことKMSは、AWS上のデータを暗号化したり復号化したりするための鍵を管理するサービスである。
クラウドサービスとしてユーザーから預かったデータを暗号化してデータベースやストレージに保管する際に、KMSにお世話になることが多い。代表的なAWSサービスだとDynamoDBやS3が挙げられる。
保管時の Amazon DynamoDB 暗号化 - Amazon DynamoDB
Amazon Simple Storage Service (Amazon S3) で AWS KMS を使用する方法 - AWS Key Management Service
そのKMSを、先日AWS管理コンソールで操作する用事があった。普段から鍵管理サービスとしてお世話にはなっているものの、AWS SDKを通じてのAPI利用する程度だったので、管理コンソールの画面がいつの間にか新しくなり、以前のIAMの画面から独立していて驚いた。
AWS Key Management Service の新しいコンソールエクスペリエンス
[KMSのリソースベースのポリシー：キーポリシー]
AWSの各種サービスやリソースを利用する際に考慮すべき設定はいくつかある。
その中でも、リソースを利用できない場合に見直すべきポイントとして、以下の2つがある。
- リソースを利用するIAMユーザー/ロールが、利用を許可されているか
- 利用されるリソースが 、IAMユーザー/ロールに利用を許可しているか
KMSの場合には扱うリソースが「キー」なので、特にこのリソースベースのポリシーを「キーポリシー」と呼んでいる。
要するにこのリソースベースのポリシーことキーポリシーを利用すると、データの暗号化・復号化のためにKMSからキーを取得することができるのが誰か、という設定をキーそのものに持たせることができる。
ただし、キーポリシーの設定だけではキーを利用できるとは限らない。キーポリシーの設定に加えて、キー利用者のIAMユーザーないしIAMロールの側でKMSのリソースの利用が許可される設定の両方がそろって初めて確実にKMSのキーをデータの暗号化・復号化に利用することができる。
キーポリシーの具体例を見ておくと以下のようになる。 123456789012というAWSアカウントのIAMユーザー「iamusersample」に、各種キー利用を許可するポリシーの例である。
{
"Id": "KMSSampleKeyPolicy",
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Allow use of the key",
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:DescribeKey"
],
"Effect": "Allow",
"Resource": "*",
"Principal": {
"AWS": [
"arn:aws:iam::123456789012:user/iamusersample"
]
}
}
]
}
[IAMユーザー削除後のキーポリシーの変化]
改めて先ほどのキーポリシーを見ると、プリンシパル（Principal）の項目に"arn:aws:iam::123456789012:user/iamusersample"とIAMユーザーのARN（Amazon Resource Name）が指定されている。
このようなキーポリシーが設定されている状態で、IAMの管理コンソールを開き、このIAMユーザーを削除して数秒経過すると、キーポリシーが以下のように変化する。
{
...（略）...
"Principal": {
"AWS": [
"AIDAXXXXXXXXXXXXXXXXX"
]
...（略）...
}
このAIDAで始まる文字列は、IAMに設定されている一意のIDのうち、IAMユーザーに割り当てられているIDである。
IAMユーザーのユーザー名でキーポリシーが設定されたまま残ってしまうと、次に同じユーザー名のIAMユーザーが作成された際に、削除された旧ユーザーがアクセスできていたリソースにもアクセスすることができてしまう。そういった事態を避けるために、（管理コンソール上では確認することはできないが）IAMで管理されているリソースには一意のIDが割り当てられているようだ。
この、削除済みIAMユーザーを示すIDがキーポリシーに残っている状態で、キーポリシーを保存しようとPutKeyPolicyというAPIを実行すると、次のようなエラーが表示され、キーポリシーを保存することができない。
PutKeyPolicy request failed MalformedPolicyDocumentException - Policy contains a statement with one or more invalid principals.
削除済みIAMユーザーを示すIDを、キーポリシーから削除することでキーポリシーを保存することができるようになる。
……というのは、AWSサポートに問い合わせてようやく解決することができた。なんだかキーポリシーに見慣れない文字列が含まれているな、くらいには認識していたのだが、まさかそこが原因だとは気がつかなかった。サポート様様である。
この削除済みの各種IAMリソースに関するリソースポリシー保存時の挙動は、他のサービスでも共通なようだ。
例えば、S3バケットにはバケットポリシーと呼ばれるリソースポリシーを設定することができる。このリソースポリシーに削除ずみIAMリソースを示す一意のIDが含まれていると、KMSのキーポリシーの場合と同様にエラーが発生する。
エラー Invalid principal in policy
[デフォルトビューとポリシービュー]
記事を書いている途中で気がついたのだが、削除済みIAMリソースが含まれたキーポリシーの場合、KMS管理コンソールでキーポリシーを編集する際に「ポリシービュー」での表示が強制されてしまうようだ。
ポリシービューを利用して削除済みIAMリソースを示す一意のIDをキーポリシーから削除すると、KMS管理コンソールの「デフォルトビュー」を利用することができるようになる。素のJSONを編集するよりは、IAMユーザーを検索して追加したりと多機能なデフォルトビューを利用する方が生産性が高そうだ。
[まとめ]
- KMSはAWS上のデータを暗号化／復号化するための鍵を管理するサービス
- 鍵を利用するには、鍵本体と鍵を利用するIAMユーザーそれぞれのポリシーに設定が必要
- 削除済みIAMユーザーが鍵本体のリソースポリシーに設定されている場合、そのままだとポリシーを保存できなくなるので注意が必要
- KMS管理コンソールではデフォルトビューでポリシーを編集すると便利
