🙂

AWSのIAMを設定手順に沿って理解してみる

2022/11/12に公開

AWS

IAM

tech

はじめに

IAMユーザー、グループ、ポリシーそしてロール。さらにはアカウント、ルートユーザーはIAMとどう関係あるの？・・・。

私はAWSのアソシエイト資格取得を目指す方のトレーナーを普段しています。多くの方の意見として
AWSを学び始めると、テキストでも動画でも最初に混乱するのが権限管理サービスであるIAM(Identity and Access Management：アイアム)だとおっしゃいます。IAMは「認証」と「認可」の設定を行うことができるサービスです。

本記事の対象者

クラウドプラクティショナーの取得を目指して勉強中。
ハンズオンをテキストもしくは動画の通りに進めてみたが、結局IAMって何？
IAMロールが特にわからない。奥が深いようだが概略を知りたい（CLFの知識なので深掘りしません）
IAMユーザーを作ってログインしたけど、そこから何も操作できません・・・。
IAMって何となくは理解しているつもりだけど、人に説明しろと言われると体系的に伝えるの難しい。←私

本記事で取り上げる内容

AWSアカウント
ルートユーザー
IAMポリシー
IAMグループ
IAMユーザー
IAMロール

AWSアカウント

AWSを利用したい場合、まずはAWSアカウントを作成します。

AWSのアカウントと言うのはMicrosoftアカウントのような「個人に紐づいている」ような位置づけのアカウントではありません。

AWSアカウントとはAWSとのクラウドの利用契約(登録)を行うことで割り当てられるスペースであるといえます。利用者はそのアカウント内でVPCやEC2、RDSといったIaaS,PaaSのリソースを用いてワークロードを構築します。

参考：AWSアカウント作成の流れ

ルートユーザー

ルートユーザーとは、AWSアカウントの作成時に作成をされるもので1アカウントに必ず一つ紐づいているものです。その権限は強力で、アカウント内のすべてのAWSサービスとリソースへの操作権限を持つだけでなく、アカウント自体を消す（削除する）ことができる唯一のユーザーであり、請求情報（AWS利用料金の支払い方法）に対してフルアクセス権限を持ったユーザーになります。
このような唯一無二な権限を有しているため、日常的なタスクにおいてはルートユーザーは使用せず、この後説明するIAMユーザーなどを使用してください。なお、ルートユーザーはIAMの管理下とは全く別の存在となりますので、この後に説明するIAMグループ、ユーザー、ロールといった括りには存在せることはできません。ここが日常のタスクに利用すべきではないもう一つの理由です。

そう聞くと怖いから触ってはいけないもの（ユーザー）と思ってしまいそうですが、アカウント取得直後の、最初のIAMユーザー作成の時にははルートユーザーの利用が誰でも必要となります。
ログインしたらまず以下のことを設定しておいてください

多要素認証（MFA）を追加で有効化する。
アクセスキー、シークレットアクセスキーを発行しない。
パスワードのポリシー（文字数、使用文字）

参考：AWSアカウントのルートユーザー

これができたらIAMグループを作成します。
ただその前に、IAMユーザー、ロール（これらをプリンシパルと言います）にアタッチする「IAMポリシー」についての説明です。

IAMポリシー

IAMポリシーとは、どのプリンシパルは、何の操作ができるか（できないか）の権限をJSON形式で記述したドキュメントで、許可証のようなものです。これを割り当てることで、「誰が」その権限を持つのかといったことを決定します。

例：
AdministratorAccess・・・ルートユーザーの権限に次ぐ管理権限で全部許可
PowerUserAccess・・・AdministratorAccessからIAMを操作する権限を除いたユーザー
ReadOnlyAccess：リソースを見るだけ。「Read」の前にリソース名が入る
例：AmazonEC2ReadOnlyAccess・・・S3を見るだけ許可

参考：IAMでのポリシーとアクセス許可

IAMグループ

AWSアカウント内でさまざまなサービスによってリソースを立ち上げ、構築してワークロードを実現します。ただ、そのワークロードは全てのユーザーが操作できるようにするのは望ましくありません。各サービスおよびリソースを指定して操作権限を制御するためにグルーピングするものがIAMグループということになります。
アカウント取得後初回ログイン時に作成するグループとしては「AdministartorAccess」のポリシーをアタッチしたグループを作成する必要があります。
会社でも営業車に営業以外の人が無条件に乗ることはできませんし、工場の生産設備を経理の人が触ることはまずできませんよね。

参考：IAMユーザーグループ

役割ごとのグループができたら、いよいよそこにユーザーを作ります。

IAMユーザー

IAMユーザーとは、AWSを利用するために使うものです。AWSを操作する時にアクセスするコンソール画面からサインインを行うときに「ルートユーザー」以外のもう一つの利用可能なプリンシパルが「IAMユーザー」です。

先ほど説明したポリシーが最終的に適用されるものがIAMユーザーになります。
ITの世界で一般的に説明されるアカウント（個人アカウント）に相当します。
ここがAWSの「アカウント」と「ユーザー」が混同してしまう要因かもしれません。

なおIAMユーザーの作成直後は何も権限が与えられていません。
必ず先に作成したIAMグループもしくはIAMユーザーに直接でも良いですがIAMポリシーをアタッチしてください。これを忘れると、コンソール画面からサインインしても何も操作権限が与えられていないユーザーということになりますので、ほぼ赤字だらけの画面になります。

参考：IAMユーザー

IAMロール

IAMロールとは、役割のようなものです。前述のポリシー（権限）を束ねることができ、それを代表する概念的な名前を付けることができます。ロールを説明する場合は、いきなり会社に例えてしまった方がわかりやすいので、以下のように説明しますね。

Role（ロール）とは「役、役割、役目、役柄、任務」という意味です。
会社（アカウント）内で従業員（ユーザー）に、1日の中で様々な職場のヘルプに行き役割（ロール）を代行させる場合、わざわざIAMグループにユーザーを登録移動したり、ユーザーポリシーの内容を書き換えするのではなく、IAMロールを使って必要なアクセス許可を「一時的に」与えることができます。

信頼されたエンティティ

ロールを作成するにあたり、マネジメントコンソールでは「信頼されたエンティティ」としてロールを作成できるユーザーやサービスを選択して設定します。EC2のWebアプリがRDSへの操作を行う場合は、EC2にRDSへのアクセス権限を有するIAMロールをアタッチします。AWSのサービスから別のAWSサービスにアクセスする場合はロールで権限を与える必要があるのです。これまで項目と同じように、会社に例えて説明しますと・・・。

営業担当が物流の配送用トラックを許可を得て利用（ユーザー→サービスの操作権限）
信頼されたエンティティ：AWSアカウント
物流部署の配送トラックを使って特別にイベント用機材を運ぶ（サービス→サービス）
信頼されたエンティティ：AWSのサービス
A社の従業員が関連会社B社での監査：スイッチロール。監査時のみ他アカウントにサインインできる。
信頼されたエンティティ：AWSのアカウント（ユーザーのクロスアカウントアクセス）
外部協力会社がサーバの搬入：工事責任者資格がある人に工事許可証を期間限定で発行し、作業許可を　与える。
※外部機関による認可を受けとことがわかるユーザーはAWSアカウントもその情報を引き継いで認証される
信頼されたエンティティ：WEBアイデンティティ
AzuerADやオンプレのADとのSAML2.0を使用したSSOもIAMロールを使って構築します。
※これは例えられませんでした。
信頼されたエンティティ：SAML2.0フェデレーション

IAMロールのAWSもアイコンはヘルメットの絵です。

そんな比喩だと私は解釈しています。

参考：IAMロール

まとめ

今回は実際の設定順序に沿って、IAMを説明しました。