この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
特定のIAMユーザーからS3へのアクセスを許可することを目的として、S3バケットポリシーのPrincipalにIAMユーザーを指定する際、忘れがちだけれども結構重要な注意点をはじめて知ったのでご紹介いたします。
Principalには存在しないIAMユーザーを設定できない
Principalには存在しないIAMユーザーを設定できません。 すべてーのユーザーを意味するワイルドカード（*）を使用することもできません。
このあたりの詳細は公式ドキュメントに記載されています。
PrincipalにIAMユーザーのARNが含まれている場合、内部で一意のプリンシパルIDへ変換を行っているそうです。 これは、ユーザーを削除して再作成することにより、誰かがそのユーザーの特権をエスカレートするリスクを緩和することを目的としています。
これはIAMロールでも同様の挙動をします。
実際にやってみる
存在しないIAMユーザーのARNをPrincipalに設定した場合
存在しないIAMユーザーのARNをPrincipalに設定して、バケットポリシーを保存しようとします。
そうすると図のようなエラーが発生します。
Principalで設定したIAMユーザーを削除して再作成した場合
まずはIAMユーザーを作成します。 principal-test-user というユーザー名で作成します。
作成したIAMユーザーのARNをPrincipalに設定して、バケットポリシーを保存します。 特に問題なく保存できます。
principal-test-user でアクセスキーを作成して、AWS CLIでのアクセスもできます。
$ export S3_BUCKET_NAME=<<BUCKET_NAME>>
$ aws s3 ls s3://${S3_BUCKET_NAME}
2019-08-16 15:36:06 13 hello_world.html次に、Principalに設定した principal-test-user を削除してみます。
その後、さきほど設定したバケットポリシーを確認してみると、Principalに設定していたIAMユーザーのARNが謎の文字列に変わっています。これがおそらく内部で一意に管理しているプリンシパルIDに関連している何かかと思います。
もう一度、principal-test-user というユーザー名でIAMユーザーを作成してみます。
その後、バケットポリシーを確認してみると、さきほどと変わらず謎の文字列が設定されています。
このままだと principal-test-user ユーザーでS3にアクセスできなさそうな気がしますが、一応AWS CLIでアクセスできるか確かめてみます。
$ export S3_BUCKET_NAME=<<BUCKET_NAME>>
$ aws s3 ls s3://${S3_BUCKET_NAME}
An error occurred (AccessDenied) when calling the ListObjectsV2 operation: Access Denied想像どおりアクセスは拒否されました。
再度、バケットポリシーにIAMユーザーのARNをPrincipalに設定して、バケットポリシーを保存します。
その後、AWS CLIでS3にアクセスしてみると問題なくアクセスできました。
$ export S3_BUCKET_NAME=<<BUCKET_NAME>>
$ aws s3 ls s3://${S3_BUCKET_NAME}
2019-08-16 15:36:06 13 hello_world.htmlIAMユーザーの再作成を行った場合、ポリシーの再設定をするまでアクセスできないことがわかりました。
おわりに
ポリシーのPrincipalでは、ユーザーを削除して再作成することによる、誰かがそのユーザーの特権をエスカレートするリスクを緩和していることがわかりました。
ポリシーのPrincipalにIAMユーザー/ロールを設定している場合、IAMユーザー/ロールを削除して再作成するとアクセスできなくなるので、再度ポリシーを設定する必要があることがわかりました。
ポリシーのPrincipalを設定する際には、この重要な仕様を忘れないように気をつけたいと思います。
17
