Future Tech Blog
フューチャー技術ブログ
Infrastructureカテゴリ

AWS IAMロールの信頼関係の気になる動作

はじめに

はじめまして。TIG DXチーム 1の村瀬です。2019年6月に中途入社しました。

最近当社Tech Blogが活発ですがより弾みをつける為、参加いたしました。

AWSのIAMロール便利ですよね。利用していますか？今回は IAMロールの信頼関係 で気になる動作を確認したので検証してみました。

IAMロールとは

公式ドキュメントより抜粋します。

IAM ロールは、特定のアクセス権限を持ち、アカウントで作成できる IAM アイデンティティです。IAM ロールは、 AWSで許可/禁止する操作を決めるアクセス権限ポリシーが関連付けられている AWS アイデンティティであるという点で、IAM ユーザーと似ています。ただし、ユーザーは 1 人の特定の人に一意に関連付けられますが、ロールはそれを必要とする任意の人が引き受けるようになっています。また、ロールには標準の長期認証情報 (パスワードやアクセスキーなど) も関連付けられません。代わりに、ロールを引き受けると、ロールセッション用の一時的なセキュリティ認証情報が提供されます。

ロールを使用して、通常は AWS リソースへのアクセス権のないユーザー、アプリケーション、サービスにそのアクセス権を委任できます。たとえば、AWS アカウントのユーザーに、通常はないリソースに対するアクセス許可を付与したり、ある AWS アカウントのユーザーに、別のアカウントのリソースに対するアクセス許可を付与したりできます。または、モバイルアプリに AWS リソースの使用を許可しても、(キーの更新が困難であり、キーの抽出が可能である) アプリへの AWS キーの埋め込みは禁止する場合があります。AWS の外部 (社内ディレクトリなど) に ID をすでに持っているユーザーに AWS へのアクセスを許可することが必要になる場合があります。または、リソースを監査できるように、アカウントへのアクセス権を第三者に付与することが必要になる場合もあります。

https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_roles.html

別のAWSアカウントのIAMユーザからスイッチ可能なIAMロール作成手順

1.マネジメントコンソールで信頼されたエンティティの種類の選択で別のAWSアカウントを選択しアカウントIDを入力し、次のステップへ
2.必要なポリシーをアタッチして
3.ロール名を入力してロールの作成
4.作成したロールの信頼関係の編集でポリシードキュメントを修正し信頼ポリシーの更新

信頼関係jsonイメージ
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:user/murase"
      },
      "Action": "sts:AssumeRole",
      "Condition": {}
    }
  ]
}

これに対して信頼関係の編集で存在しないエンティティを下図のように指定するとエラーとなり、保存できませんでした。裏でエンティティの存在確認が行われているんですね。

存在しないIAMユーザを指定してエラーになった図

検証

検証1

では、存在するエンティティ(IAMユーザ)を指定してIAMロールを作成し、その後IAMユーザを削除したらどうなるでしょうか？

手順は省略しますが、結果は以下の通りです。

IAMユーザ削除後の信頼関係jsonイメージ
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "AIDA3ZFZ4X6FO5HB76XYS"
      },
      "Action": "sts:AssumeRole",
      "Condition": {}
    }
  ]
}

信頼されたエンティティが意図しない文字列「AIDA3ZFZ4X6FO5HB76XYS」に変わりました。

検証2

では、先ほど削除したIAMユーザと同名のIAMユーザを再作成するとロールの信頼されたエンティティがどうなるか見てみましょう。

またまた手順は省略しますが、結果は以下の通りです。

同名IAMユーザ作成後の信頼関係jsonイメージ
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "AIDA3ZFZ4X6FO5HB76XYS"
      },
      "Action": "sts:AssumeRole",
      "Condition": {}
    }
  ]
}

信頼されたエンティティは相変わらず意図しない文字列のままでした。再作成したIAMユーザと合致しない為、スイッチロールできませんね。

まとめ

削除したIAMユーザとたまたま同名のIAMユーザを作成して意図しないロールが利用できてしまうのは問題ですし、セキュリティを考慮するとこのような動作をするのは納得できます。

実際のケースとしてプロジェクトからの離脱などの理由によりIAMユーザを削除することがあるかと思います。削除後に復帰することがなければ良いのですが、復帰することがあり以前のロールが利用できることを望むのであればIAMユーザを削除するのではなくコンソールへのアクセスの無効化やアクセスキーの削除にてIAMユーザをログインできないようにする運用が得策です。

また、信頼されたエンティティを更新する際にエンティティの存在チェックがなされるので意図しない文字列がある場合にはそれを削除しないと更新ができません。CloudFormationやTerraformでIAMロールが管理されていればそれほど手間なく更新可能かと思いますが、手運用の場合には気を付けましょう。

  1. 1.Technology Innovation Groupの略で、フューチャーの中でも特にIT技術に特化した部隊です。その中でもDXチームは特にデジタルトランスフォーメーションに関わる仕事を推進していくチームです。 ↩