AssumeRole(スイッチロール)で複数AWSアカウント運用【ビギナー向け】

記事タイトルとURLをコピーする

技術三課の杉村です。これからAWSを本格的に利用していこうと思っている方のために、複数AWSアカウントの運用を簡単にご説明します。 前回のブログをご理解いただいていることを前提としていますので、未読の方は以下をご参照ください。

AWSアカウントとは?IAMとは?【ビギナー向け】

なお本投稿ではAWSビギナーの方でも理解いただけるよう表現を抽象化したり、あえて深く説明していない部分もありますが、まずは概要を理解するためのものとお考えください。

1. 複数AWSアカウントの利用

前回のブログでは、AWSアカウントを部署単位、あるいは環境単位で分けるメリットを以下のように説明しました。

  1. AWS権限の明確な分離(セキュリティ・ガバナンス上のメリット)
  2. AWS利用料金の明確な分離(コスト管理上のメリット)

さらに凝った設計(セキュリティ・ガバナンス・コンプライアンス)を考えたとき、下記のAWS Landing ZoneというAWSから発表されているマルチアカウント設計が参考になります。

AWS Landing Zone

ただしこれは非常にリッチ、重厚、複雑なものであり、実際にはその考え方を取捨選択して部分的に採用したほうがよいケースもあります。

今回の投稿では、AWS Landing Zoneのようなマルチアカウント運用を理解する際には前提として理解しておかなければならない、AssumeRole(スイッチロール)の概念をご説明します。

2. AssumeRole(スイッチロール)とは

前回の投稿でも説明した通り、IAM UserやIAM Roleは、他のIAM RoleをAssumeRoleしてその権限を引き受けることができます。

例えば、あるIAM User "UserA" にはこんな権限が与えられていたとします。 ※ UserAはマネジメントコンソール(以下、マネコン)のログインパスワードが発行されていて、マネコンにログインできるものとします。

  • IAM Role "RoleA" をAssumeRoleする権限

権限(IAM Policy)は上記の1個しかアタッチされていませんので、UserAはマネコンにログインはできるものの、他には何もすることができません。 EC2一覧の画面に遷移しても「権限不足であなたには見せられませんよ」表示されるだけです。 ただUserAは、IAM Role "RoleA" をAssumeRoleする権限を持っています。

マネコンの上部メニューから "スイッチロール" を選択します。 そしてスイッチ先のIAM Role名とそのIAM Roleが存在するAWSアカウントIDを入力するのです。

すると、UserAさんは晴れてRoleAの権限を引き受けることができます。

RoleAには以下の権限がついています。

  • EC2へのフルアクセス権限

これによりUserAさんは、EC2インスタンス一覧を閲覧したり、EC2インスタンスを構築したりできるようになりました。

スイッチロールとAssumeRoleという言葉が出てきましたが、同じようなものと理解してOKです。 厳密に言うと、AssumeRoleはAWSの用意するAPIの名前であり、スイッチロールは「Roleを引き受けて権限をスイッチする」という作業のことを指します。 スイッチロールという目的のために、AssumeRole APIを発行する、というようなイメージです。

3. 複数アカウント間のAssumeRole(スイッチロール)

3-1. 架空のシナリオで考えてみる

さて、AssumeRole(スイッチロール)はなんとなくわかったと思いますが、なぜこんな面倒なことをするのでしょう?

さっきの例だと、最初からIAM User "UserA" に「EC2へのフルアクセス権限」を付与していればいい話ですね。

ではこのような例を考えます。 あなたがとある企業の情シス部門であり、クラウド推進のミッションを担っています。 会社の全てのAWSアカウントにはあなたが目を光らせなくてはいけません。

開発部署A, 開発部署B, 開発部署Cがあり、みなAWSを利用しています。 しかも彼らは「本番環境」「ステージング環境」「開発環境」をそれぞれ持っていて、AWSアカウントは全て分かれています。 AWSアカウントが6環境あるということですね。

3-2. IAM Userのみの場合

これらすべてにログインして管理するには、IAM Userを各AWSアカウントに1個ずつ、計6個作らなくてはいけないということになります。 それぞれにパスワードを設定し、権限が設定し、、、 しかも情シス部員はあなただけではなく、5名の部下も同じようにAWSアカウントにログインできる必要があります。 ということは、5ユーザー×6アカウントで、30のIAM Userとそのパスワードを管理しなくてはいけないのでしょうか...

さらに、通常時は閲覧のみの権限でアクセスし、トラブル時など必要な場合のみ編集権限に切り替えて利用したいとなると、一人につき2つのIAM Userをもつことになるので、60 User...

またある日部下の一人が異動となり、全てのAWSアカウントにログインする権限をはく奪するときは、どうでしょう。

これが大変なのは容易に想像がつくと思います。

3-3. IAM Roleを使った場合

IAM Userは各個人ごとに、情シスの管理する中央AWSアカウントに作成することにします。 ※ちなみにこの中央AWSアカウントには、CloudTrail(AWSのAPIコールのログ記録サービス)ログやConfig(構成管理サービス)のログなども集約しています。

そして、各利用部門のAWSアカウントには "ItReadOnly"(閲覧権限のみのロール。情シス部員のみスイッチ可能), "ItAdministrator"(編集権限有りのロール。情シス部員のみスイッチ可能) の2ロールを作成します。

情シス部門員は、まず自分のIAM Userで中央AWSアカウントにログインし、そののちログインしたいAWSアカウントの適したIAM Roleにスイッチロールすればよいわけです。 権限管理は、これらのIAM UserがどのIAM RoleをAssumeRoleできるかという権限をしっかり管理すればよいことになります。

退職者や異動者が出ても、中央AWSアカウントに集約したIAM Userを一つだけ削除すればよいのです。

上記の図のようにスイッチロール(AssumeRole)すると、マネジメントコンソール画面にはスイッチした先のAWSアカウントのAWSリソースが閲覧・編集できるようになるのです。

非常に簡単ですが、これが複数AWSアカウント運用におけるAssumeRoleというIAM戦略のエッセンスをご紹介しました。

杉村 勇馬 (記事一覧)

サーバーワークス → 株式会社G-gen 執行役員CTO

2021 Japan APN Ambassadors / 2021 APN All AWS Certifications Engineers

マルチAWSアカウント管理運用やネットワーク関係のAWSサービスに関するブログ記事を過去に執筆。

2021年09月から株式会社G-genに出向、Google Cloud(GCP)が専門に。G-genでもGoogle Cloud (GCP) の技術ブログを執筆中。