対象読者
※要点整理から攻略するAWS認定 セキュリティ・専門知識を参考に作成
- この図を見た時、教科書的な説明は思い浮かぶが、実際の所IAM Roleについてよくわからない人
- 試験ではアクセスキーは×、IAM Roleは〇のように覚えてしまった人
こういった方に私なりに整理して、IAM Roleとは何かをお伝えできればと思います。
間違いなどありましたらコメントや編集リクエストいただければ確認し返答いたします。
結論
- IAM Roleは「ユーザが管理しなくていいアクセスキー」で「ユーザーとサービス」に「一時的」に権限を渡している。
- PrincipalでそのRoleを使っていいアカウント・AWSサービス等を限定する。
この記事で説明すること
- アクセスキーのデメリット
- IAM Roleによるデメリットの解消
- Principalについて
まずアクセスキーとIAM Roleを知ることで、アクセスキーのデメリットとIAM Roleでどう改善されているかを説明します。IAM Roleが返す一時的なセキュリティ認証情報がわかることでIAM Roleの仕組みがわかるようになります。
最後に、なぜPrincipalを設定するかを説明します。
この記事で説明しないこと
- IAM Roleの具体的な作成方法や設定方法
アクセスキーのデメリット
アクセスキーのデメリットは、流出リスクがあるアクセスキーを「ユーザーが管理しなくてはいけない」ことです。
まず、アクセスキーについておさらいします。
アクセスキーは、IAM ユーザーまたは AWS アカウントのルートユーザー の長期的な認証情報です。
※公式ドキュメントから引用。
https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_credentials_access-keys.html
また認証とは、システムやサービスへのアクセスを試みる個人またはエンティティの身元を確認し、証明するプロセスです。ここだとアクセスキーさえ持っていれば本人とみなすということです。
アクセスキー（正確にはシークレットキーもですが文章簡略化のため省略）で認証が完了するとどうなるでしょうか？本人＝AWSユーザーorルートユーザーですので、そのユーザーが持っている権限を使用することができるようになります。
アクセスキーによっては強力な権限を有する可能性があります。
AWS公式では以下のような理由から、90日毎にアクセスキーをローテーションすることを進めています。
アクセスキーIAM ユーザーの長期認証情報です。IAM 認証情報を定期的にローテーションすることで、侵害された IAM アクセスキーセットが AWS アカウントのコンポーネントにアクセスするのを防ぐことができます。
しかしアクセスキーが増えてくると管理が煩雑になっていきます。
- あれ？このアクセスキーはどこで使ってるんだっけ？
- え？このアクセスキーは消していいのか？
- （自動ローテ設定にしていない場合）どのアクセスキーをローテーションしたらいいんだ？
- あ、間違えてGithubにコミットしちゃった
- ハードコーディングしちゃってた
こういったミスが発生するのは「アクセスキーをユーザーが管理しなくてはいけない」からです。
さらに万が一流出したら、そのアクセスキーが失効するのは次のローテーション設定日になります。
IAM Roleによるデメリットの解消
アクセスキーには前述したようなデメリットがあります。
そのため、AWS公式でも基本的にIAM Roleを使用するよう呼び掛けています。
多くの一般的なユースケースでは長期的なアクセスキーの代替方法があります。アカウントのセキュリティを強化するには、以下を検討してください。
https://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/automatically-rotate-iam-user-access-keys-at-scale-with-aws-organizations-and-aws-secrets-manager.html
では、IAM Roleを使うとなぜアクセスキーのデメリットがなくなるのでしょうか？
AssumeRoleの動作を基に説明します。
IAM RoleはSTSに「一時的セキュリティ認証情報」の発行を依頼し、発行された「一時的セキュリティ認証情報」を使って、AWSリソースにアクセスを行う仕組みです。「一時的セキュリティ認証情報」をユーザーは管理する必要がありません。
これによってアクセスキーのデメリットであった「アクセスキーをユーザーが管理しなくてはいけない」「万が一流出したら、そのアクセスキーが失効するのは次のローテーション設定日」が解消されていることが分かります。
では「一時的セキュリティ認証情報」とはなんなのでしょうか？
「一時的セキュリティ認証情報」のレスポンス例を公式から抜粋して引用するとよくわかります。
これより、「一時的セキュリティ認証情報」とはセッショントークン、シークレットアクセスキー、有効期限、アクセスキーであることがわかります。
<Credentials>
<SessionToken>
AQoDYXdzEPT//////////wEXAMPLEtc764bNrC9SAPBSM22wDOk4x4HIZ8j4FZTwdQW
LWsKWHGBuFqwAeMicRXmxfpSPfIeoIYRqTflfKD8YUuwthAx7mSEI/qkPpKPi/kMcGd
QrmGdeehM4IC1NtBmUpp2wUE8phUZampKsburEDy0KPkyQDYwT7WZ0wq5VSXDvp75YU
9HFvlRd8Tx6q6fE8YQcHNVXAkiY9q6d+xo0rKwT38xVqr7ZD0u0iPPkUL64lIZbqBAz
+scqKmlzm8FDrypNC9Yjc8fPOLn9FX9KSYvKTr4rvx3iSIlTJabIQwj2ICCR/oLxBA==
</SessionToken>
<SecretAccessKey>
wJalrXUtnFEMI/K7MDENG/bPxRfiCYzEXAMPLEKEY
</SecretAccessKey>
<Expiration>2019-07-15T23:28:33.359Z</Expiration>
<AccessKeyId>AKIAIOSFODNN7EXAMPLE</AccessKeyId>
</Credentials>
アクセスキーがあれば、そのユーザーの権限を使えるのでしたよね。
IAM RoleのいわゆるAssumeRoleも裏でアクセスキーを作り、IAM Roleにアタッチされたポリシーにある権限を使用しているわけです。
この説明はクラスメソッドさんの以下の説明が分かりやすいと思いました。
まるごと引用はさすがに失礼と思い、該当箇所へリンクを張り付け致します。
https://dev.classmethod.jp/articles/iam-role-and-assumerole/#:~:text=%E3%81%A6%E3%81%82%E3%82%8A%E3%81%BE%E3%81%99%E3%80%82-,%E3%83%AD%E3%83%BC%E3%83%AB%E3%81%AE%E5%BC%95%E3%81%8D%E5%8F%97%E3%81%91%E3%81%A8%E3%81%AF,-%E6%9C%80%E7%B5%82%E7%9A%84%E3%81%AB
Principalについて
最後にPrincipalについてです。
便利なIAM Roleですが、「俺もIAM Roleしたい！」と知らないやつがAssumeRole APIを叩いてきて「うんわかった！」と権限を渡してしまっては困りますよね。
なのでPrincipalにAssumeRoleを許可するAWSアカウントやAWSサービスを書いておくわけです。
AWSサービスの場合、マネジメントコンソールのユースケースから選択すると、ユースケースに設定したサービスに対してPrincipalが書かれたIAM Roleが作成されます。
EC2に対して設定した例は以下です。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
ここで結論に戻る
ここで初めに出した結論にもどりますが、つまりIAM Roleとは
- IAM Roleは「ユーザが管理しなくていいアクセスキー」で「ユーザーとサービス」に「一時的」に権限を渡している。
- PrincipalでそのRoleを使っていいアカウント・AWSサービス等を限定する。
ものだということがわかりました。