削除されたIAMユーザーのARNはどこへ行くのか?―KMSでキーポリシーが更新できなくなった話―

AWS認定 DevOpsエンジニア - プロフェッショナルには合格したものの、触れば触るほど「AWSなんも分からん……」と言う感じでダニング=クルーガー効果を地で行く毎日。

togetter.com

 

本日は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 の新しいコンソールエクスペリエンス

dev.classmethod.jp

 

[KMSのリソースベースのポリシー:キーポリシー]

AWSの各種サービスやリソースを利用する際に考慮すべき設定はいくつかある。

その中でも、リソースを利用できない場合に見直すべきポイントとして、以下の2つがある。

  1. リソースを利用するIAMユーザー/ロールが、利用を許可されているか
  2. 利用されるリソースが 、IAMユーザー/ロールに利用を許可しているか

 

KMSの場合には扱うリソースが「キー」なので、特にこのリソースベースのポリシーを「キーポリシー」と呼んでいる。

docs.aws.amazon.com

 

要するにこのリソースベースのポリシーことキーポリシーを利用すると、データの暗号化・復号化のために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である。

docs.aws.amazon.com

 

IAMユーザーのユーザー名でキーポリシーが設定されたまま残ってしまうと、次に同じユーザー名のIAMユーザーが作成された際に、削除された旧ユーザーがアクセスできていたリソースにもアクセスすることができてしまう。そういった事態を避けるために、(管理コンソール上では確認することはできないが)IAMで管理されているリソースには一意のIDが割り当てられているようだ。

 

この、削除済みIAMユーザーを示すIDがキーポリシーに残っている状態で、キーポリシーを保存しようとPutKeyPolicyというAPIを実行すると、次のようなエラーが表示され、キーポリシーを保存することができない。

f:id:kidani_a:20190629235358p:plain

PutKeyPolicy request failed
MalformedPolicyDocumentException - Policy contains a statement with one or more invalid principals.

 

削除済みIAMユーザーを示すIDを、キーポリシーから削除することでキーポリシーを保存することができるようになる。

……というのは、AWSサポートに問い合わせてようやく解決することができた。なんだかキーポリシーに見慣れない文字列が含まれているな、くらいには認識していたのだが、まさかそこが原因だとは気がつかなかった。サポート様様である。

 

この削除済みの各種IAMリソースに関するリソースポリシー保存時の挙動は、他のサービスでも共通なようだ。

例えば、S3バケットにはバケットポリシーと呼ばれるリソースポリシーを設定することができる。このリソースポリシーに削除ずみIAMリソースを示す一意のIDが含まれていると、KMSのキーポリシーの場合と同様にエラーが発生する。

f:id:kidani_a:20190630000125p:plain

エラー
Invalid principal in policy

 

[デフォルトビューとポリシービュー]

記事を書いている途中で気がついたのだが、削除済みIAMリソースが含まれたキーポリシーの場合、KMS管理コンソールでキーポリシーを編集する際に「ポリシービュー」での表示が強制されてしまうようだ。

f:id:kidani_a:20190630000838p:plain

 

ポリシービューを利用して削除済みIAMリソースを示す一意のIDをキーポリシーから削除すると、KMS管理コンソールの「デフォルトビュー」を利用することができるようになる。素のJSONを編集するよりは、IAMユーザーを検索して追加したりと多機能なデフォルトビューを利用する方が生産性が高そうだ。

f:id:kidani_a:20190630000918p:plain

 

[まとめ]

  • KMSはAWS上のデータを暗号化/復号化するための鍵を管理するサービス
  • 鍵を利用するには、鍵本体と鍵を利用するIAMユーザーそれぞれのポリシーに設定が必要
  • 削除済みIAMユーザーが鍵本体のリソースポリシーに設定されている場合、そのままだとポリシーを保存できなくなるので注意が必要
  • KMS管理コンソールではデフォルトビューでポリシーを編集すると便利