AWS IAMとは ― ユーザー・ロール・ポリシーで権限を管理する仕組み

AWSのアカウントを複数の人やアプリで使うなら、誰に何を許すかを決めておく必要があります。AWS IAMは、AWSのリソースを誰がどこまで操作してよいかを決めるサービスです。正式名はAWS Identity and Access Managementです。

管理の対象は、人だけではありません。アプリケーションや、EC2のようなAWSのサービス自体がAWSの操作を行うときも、IAMが権限を管理します。IAM自体の利用に追加の料金はかかりません。

IAMが管理する識別情報には、3つの種類があります。IAMユーザー・IAMユーザーグループ・IAMロールです。IAMユーザーグループは、以下ではグループと書きます。

IAMユーザーは、1人の人、または1つのアプリケーション専用の識別情報です。パスワードやアクセスキーのような、長期間使える認証情報を持ちます。

グループは、複数のIAMユーザーをまとめたものです。グループに権限を与えると、そのグループに入っているユーザー全員が、同じ権限を持ちます。

IAMロールは、特定の人には結び付かない識別情報です。信頼されたエンティティが、必要なときに一時的に引き受けて使います。エンティティとは、IAMユーザー・アプリケーション・EC2などのAWSのサービスのことです。ロールは、パスワードやアクセスキーのような長期的な認証情報を持ちません。引き受けるたびに、一時的な認証情報が発行されます。

EC2やLambdaのアプリは、データベースのパスワードをロールの権限でSecrets Managerから取得できます。EC2に付けたロールは、Systems Managerでサーバを管理するときの権限にもなります。自分のアプリの利用者にロールの一時的な認証情報を渡す仕組みは、Amazon Cognitoの記事で説明しています。

どの識別情報も、1つ以上のポリシーと結び付けられます。ポリシーが、その識別情報にできる操作を決めます。この3つとは別に、アカウントを作ったときに用意される特別な識別情報もあります。

AWSのアカウントを作ると、最初に1つだけ作られる識別情報があります。ルートユーザーです。ルートユーザーは、そのアカウントのすべてのAWSサービス・リソースへの完全なアクセス権を持ちます。

ルートユーザーには、ユーザーやロールのようにアイデンティティベースポリシーを結び付けられません。既定で、すべての操作が許可されています。そのため、乗っ取られたときの被害が、ほかの識別情報より大きくなります。AWS Organizationsで複数のアカウントをまとめているときは、組織側のポリシーを使えます。このポリシーで、メンバーアカウントのルートユーザーを制限できます。この組織側のポリシーをSCPと呼びます。SCPの仕組みは、AWS Organizationsの記事で説明しています。

AWS公式ドキュメントは、日常的な作業にルートユーザーを使わないことを強く勧めています。日常の作業には、管理用のIAMユーザーやロールを作って使います。ルートユーザーが必要になるのは、アカウント全体の設定を変えるような、限られた作業のときだけです。

公式ドキュメントが挙げるルートユーザーの保護方法のうち、代表的なものは2つです。1つは、多要素認証を設定することです。もう1つは、ルートユーザーのアクセスキーを作らないことです。多要素認証の仕組みは多要素認証の記事にまとめています。

ポリシーとは、識別情報やリソースに結び付けて、その権限を定める文書です。何を許可し、何を拒否するかを書きます。ほとんどのポリシーは、JSON形式で書かれます。

識別情報（ユーザー・グループ・ロール）に結び付けるポリシーを、アイデンティティベースポリシーと呼びます。リソースの側に付けるポリシーもあります。たとえば、暗号化の鍵に付けるキーポリシーです。AWS KMSの記事で説明しています。

ポリシーの中身は、1つ以上のステートメント（文）から成ります。各ステートメントの主な要素は、次のとおりです。

例えば「S3バケットの中のオブジェクトを読み取れる」という許可を考えます。ステートメントでは、Effectを「Allow」、Actionを「s3:GetObject」にします。Resourceには対象のバケットを指定します。

1つの識別情報に、複数のポリシーが適用されることがあります。複数のポリシーの中にAllowとDenyが混ざっているとき、AWSは決まった順番で評価して、最終結果を1つに決めます。以下の説明は、1つのアカウントの中で、アイデンティティベースポリシーだけが関わる基本的な場合を対象にしています。

評価の基本ルールは3つです。1つ目は、既定ではすべてのリクエストが拒否されることです。これを暗黙の拒否と呼びます。

2つ目は、リクエストを許可するには、ポリシーで明示的に許可する必要があることです。これを明示的な許可と呼びます。3つ目は、明示的な拒否があれば、明示的な許可より優先されることです。

この3つのルールから、評価の順番が決まります。最初に明示的な拒否を探し、見つかればそこで拒否が確定します。見つからなければ、次に明示的な許可を探し、見つかれば許可が確定します。どちらも見つからなければ、既定の暗黙の拒否になります。

次の図で「ポリシーなし」「Allowのみ」「Allow + Deny」の3パターンを選べます。同じ操作の最終結果がどう変わるかを確かめられます。

最小権限の原則とは、作業に必要な最小限の権限だけを与える考え方です。まず最小限の権限を与え、必要な分だけ追加します。AWS公式ドキュメントは、このほうが、最初から緩い権限を与えて後で絞るより安全だと説明しています。

権限を広く与えすぎると、ミスや乗っ取りが起きたときに、操作できる範囲が広がってしまいます。ユーザーやロールごとに、本当に必要な操作だけを許可するポリシーを作ることが、最小権限の原則の実践です。外部のアプリに渡す権限を必要な範囲に絞る考え方は、OAuthの記事でも触れています。

最小権限の原則には、認証情報が盗まれたときや設定ミスが起きたときに、被害の範囲を狭める効果があります。不正アクセスの被害を小さくする考え方は、不正アクセスの記事でも説明しています。ユーザーやロールが実際に行った操作は、CloudTrailにイベントとして記録されます。

• AWS「What is IAM?」（IAMの定義、ルートユーザー、料金）
• AWS「IAM Identities」（ユーザー・グループ・ロールの定義）
• AWS「Root user best practices for your AWS account」（ロールの一時的な認証情報、ルートユーザー保護）
• AWS「Policies and permissions in IAM」（ポリシーの定義、ステートメントの要素、最小権限の原則）
• AWS「Policy evaluation logic」（暗黙の拒否、明示的な許可・拒否の評価順）