AWSソリューションアーキテクト・アソシエイト IAM編
私はIAMを理解するために、はじめにAWS公式のベストプラクティスを一通り読みましたが、あまり理解できませんでした。やはり、手を動かして覚えるのが一番だと思っています。
ポイントはEC2編で紹介しましたが、『My AWS System』を最小限のアクセスポリシーでもって構築することです。
IAMの最新ベストプラクティスはこちらからご覧ください。
IMAユーザー
Identity and Access Management (IAM) はAWSを利用する上で基本となる、ユーザー管理、グループ管理、アクセス権限の管理を担うサービスです。利用は無料です。
１．ルートユーザー
ルートユーザーとは、Amazon Web Services (AWS) アカウントを初めて作成したときのユーザーを指します。
ルートユーザーを使用すると、お客様の AWS アカウントのすべてのリソースへの完全かつ無制限なアクセス (請求情報へのアクセスやパスワードの変更など) が可能になります。このレベルのアクセスは、最初にアカウントを設定するときに必要です。ただし、日常のアクセスには、ルートユーザーを使用しないことをお勧めします。
このようにAWSでは、何でもできてしまうルートアカウントを普段は使わないでね、と言っています。そして、以下のことも推奨しています。
- ルートユーザーのアクセスキーは削除
- ルートユーザーのアクセスキーを保持する場合、アクセススキーは定期更新
- コンソールログインの強度なパスワード設定（IAMパスワードポリシーはルートユーザーには適用されない）
- 多要素認証（MFA）を推奨（IAM＞ユーザー選択＞認証情報＞MFA デバイスの割り当て＞管理）
では、ルートユーザーは何のためにあるのか、ということになります。実は、以下のようにルートユーザーにしかできないこともあります。
- アカウント情報の更新（アカウント名、パスワード、Email）
- AWSサポートプラン変更
- 唯一のIAM管理者が自身を削除してしまった場合の復元
- AWSアカウントの解約
アカウント情報の更新が主な内容ですね。あとは、管理者の管理といった感じでしょうか。
２．既存ユーザーとのフェデレーション（ID連携）
普通の企業であれば、既に社員一人一人に社員IDというものが割り当てられ、社内システムと紐づけられています。または、ウェブサービス上でIDを管理している企業もあるでしょう。
そういった、社内システムやウェブサービスのID認証とAWSのユーザー認証をフェデレーション（連携）することが出来ます。
ユーザーについては、概ね理解できる内容だったと思います。問題はここからです。
ユーザー・グループ・ロール・ポリシー
まずは、IAMの概念の中心となる4つのキーワード「ユーザー・グループ・ロール・ポリシー」を理解することから始まります。AWSの公式ドキュメントでも丁寧に説明されていますが、私は理解するのに時間が掛かってしまいました。
結論から言うと、IAMの権限管理は「ポリシー」を中心にして理解するのが簡単です。それを説明していきます。
１．「ポリシー」とは
ポリシーには、アイデンティティベースのポリシー、リソースベースのポリシー、アクセス許可の境界など、細かく種類が分かれています。しかし、AWSソリューションアーキテクトアソシエイトに合格する程度であれば、すべてを理解する必要はありません。
それよりも、権限管理を実際に運用していく上での基本を押さえることが大切です。
どんな企業にも、組織ごとにアクセス権限を指定して、誰が特定のシステムにアクセス出来て、誰がアクセスできないのか、細かく設計していると思います。それをAWSではIAMで管理しています。
原則、AWSのユーザーは作成した時点ではすべてのリソースにアクセスできません。
「ポリシー」の役割は、「ユーザー」・「グループ」・「ロール」に特定のリソースへのアクセス許可を与えるというものです。
たとえば、『EC2のすべてのインスタンスにアクセスする許可を与える』『RDSのインスタンスID＝12345に対して参照のみ行えることを許可する』といった具合に、細かくアクセス方法を限定することが出来ます。
２．「ユーザー」にアクセス許可を与える
先ほども述べましたが、「ユーザー」は作成した時点で全てのリソースに対してアクセスが出来ません。そこで、「ユーザー」に「ポリシー」をアタッチすることでアクセスの許可を与えることが出来ます。
下の図をご覧ください。
こちらは、「ユーザー（akoizumi@se-from30.com）」に対してEC2とS3へのアクセス許可するポリシーをアタッチしています。これにより、「ユーザー（akoizumi@se-from30.com）」はEC2とS3にアクセスることが出来るようになります。
ただし、RDSへはアクセスできません。RDSにアクセスするための「ポリシー」がアタッチされていないからです。
２．「グループ」にアクセス許可を与える
組織の規模が大きくなると、一人ひとりの「ユーザー」に対して「ポリシー」をアタッチしていくよりは、「グループ」で管理した方が効率が良いです。
こちらの図では、「グループA」に対してEC2とS3へのアクセス許可を与え、「グループB」に対してRDSへの許可を与えています。
その状態で、「ユーザー（akoizumi@se-from30.com）」を「グループA」に追加します。そうすると、「ユーザー（akoizumi@se-from30.com）」は所属する「グループA」のアクセス権を手に入れることが出来ます。
運用方法としては、同じシステムの担当者が複数人と存在すれば、同様に「グループA」に追加することで全員が同等のアクセス権を手に入れることが出来ます。
続いて、以下のような方法も可能です。
例えば、RDSへ接続できる専用の「グループB」を作成して、そこに「ユーザー（akoizumi@se-from30.com）」を追加します。これによって、「ユーザー（akoizumi@se-from30.com）」はRDSにもアクセスすることが出来るようになります。
３．「ロール」にアクセス許可を与える
「ロール」とは、EC2やRDS、Lambdaといったサービスに付与する「ポリシー」の集合体です。そして、大事なポイントとして「ロール」はEC2やRDSなどのサービスに対してアタッチするものです。
たとえば、以下のような使い方が出来ます。
このように、
- S3とRDSへのアクセスを許可する「ポリシー」をロールにアタッチ
- ロールをEC2にアタッチ
とすることで、EC2からS3やRDSへセキュアにアクセス出来るようになります。このアクセス許可の設定方法がAWSの勧めているベストプラクティスです。
ポリシーの定義方法（JSON形式）を覚える
ポリシーの作成方法は2種類あります。ビジュアルエディターというGUIで作成する方法と、JSON形式で直接入力する方法です。試験ではJSON形式の「ポリシー」について問われます。
これは実際に自分の手で触って覚えるしかありません。AWS公式ドキュメントを読みながら、自分の環境で様々なアクセス許可の設定を試しましょう。
たとえば、S3にアクセスするのもたくさんの種類があります。バケットを参照する、オブジェクトを更新する、削除する、といった具合です。以下にサンプルを表示します。
このポリシーでは、S3のkoizumi-dataというバケットに対して、アクションPutObject・GetObject・ListBucket・DeleteObjectを許可しておりそれ以外のアクションはできません。
試験では、JSON形式のポリシーを読んで、それがどのようなアクセス許可設定となっているかを問われますので、JSON形式の記述内容は理解しておかねばなりません。
試験対策
実際に試験を受けた感触としては、IAMに関して抑えるポイントは上記の内容で足りると思います。何よりも自分の手を動かして、何度も躓いて覚えたことがそのまま試験で役に立ちます。
手を動かす時のポイントとしては、最小限のポリシーを付与して、EC2同士のアクセスを可能にしたり、AWS CLI を実行する環境を構築することです。
頑張っていきましょう！
