【図解】AWS IAMとは。会社の受付に例えると、ユーザーとロールの違いが分かる

対象読者: AWSをこれから触る人。 AWS勉強シリーズの3本目です。全体の地図は索引記事にあります。

IAMとは何か

AWS Identity and Access Management(IAM)は、AWSのリソースへのアクセスを安全に制御するためのサービスです。「誰が(認証)」「何をしていいか(認可)」を管理します。AWSアカウントを作った瞬間から存在していて、EC2でもS3でも、どのサービスを使うときも必ずIAMの権限チェックを通ります。IAM自体の利用は無料です。

AWSを学ぶ順番でIAMが最初に来る理由は単純で、他の全部の前提だからです。「権限が足りなくてエラーになる」は初心者が最初に踏む壁で、それを読み解くにはIAMの語彙が要ります。

何に使うか

• 人ごとにアカウントを分ける: チームで1つのAWSアカウントを共有するとき、開発者・運用担当・閲覧のみの人にそれぞれ別のログインと権限を与える
• 必要最小限の権限だけ渡す: 開発者にはS3の読み書きは許すが、請求情報やIAM設定は触らせない、といった線引き
• プログラムやサービスに権限を渡す: EC2上のアプリがS3を読めるようにする、Lambda関数がSQSからメッセージを取れるようにする。人ではなくサービスに権限を付ける場面はAWSでは非常に多い
• 他アカウントや外部IDプロバイダとの連携: 別のAWSアカウントの人に一時的に作業させる、社内のGoogle WorkspaceやActive Directoryのアカウントでログインさせる

重要用語

仕組みの要点

権限はポリシーという形で表現され、それをユーザー・グループ・ロールのいずれかに付けます。ポリシーの中身はこういうJSONです。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:ListBucket"],
      "Resource": "*"
    }
  ]
}

読み方は「S3の読み取り(GetObject)と一覧(ListBucket)を、全リソースに対して、許可する」です。Actionは サービス名:操作名 の形で、Resourceは対象を絞りたければARN(AWS内のリソースID)を書きます。何も書かれていない操作は既定で拒否です。明示的なDenyは常にAllowより優先されます。

判定の流れは、①ログインで身分を確認(認証)→②その身分に付いた全ポリシーを集めて、頼まれた操作が許可されているか判定(認可)、です。

このコードを動かす前提

この記事のコードはPython(boto3)です。動かす方法は2通りあります。

A. AWSアカウント無しで試す(おすすめ): motoというAWSのそっくりさんを使うと、課金もサインアップもなしでPCの中だけで動きます。

python3 -m venv venv
./venv/bin/pip install boto3 moto

from moto import mock_aws

@mock_aws            # この中のboto3呼び出しは全部ローカルの偽AWSに行く
def main() -> None:
    ...              # 以下の記事のコードをここに入れる

main()

B. 本物のAWSで動かす: 先にIAMユーザーとアクセスキーを作って aws configure で登録しておく必要があります。手順はすぐ下の「最初の1回だけやる手順」です。IAMのコードだけは管理者権限のあるユーザーで動かします。

最初の1回だけやる手順(アカウントを作った直後)

ここはこのシリーズで唯一、画面操作が要る所です。これをやらないと2記事目以降のコードは全部 Unable to locate credentials か AccessDenied で止まります。所要15分。

手順5のコマンドです。

pip install awscli          # 未導入なら
aws configure
# AWS Access Key ID:     手順4のキーID
# AWS Secret Access Key: 手順4のシークレット
# Default region name:   ap-northeast-1
# Default output format: json
aws sts get-caller-identity

最後のコマンドで、こういう形が返れば完了です。

{
    "UserId": "AIDA...",
    "Account": "123456789012",
    "Arn": "arn:aws:iam::123456789012:user/あなたのユーザー名"
}

Arn の末尾が user/名前 ではなく root になっていたら、ルートのアクセスキーを作ってしまっています。そのキーはIAM → セキュリティ認証情報から削除して、手順2からやり直してください。

ここから先、ルートユーザーは使いません。請求の設定変更やアカウント閉鎖のような一部の操作だけルートが要ります。

使い方

実務でいちばん多い「グループに権限を付けて、ユーザーをグループに入れる」形と、「サービスにロールを渡す」形を、Python(boto3)で示します。

import json
import boto3

iam = boto3.client("iam")

# ① グループを作る
iam.create_group(GroupName="developers")

# ② 権限(ポリシー)を作ってグループに付ける。ここではS3の読み取りだけ
policy = {
    "Version": "2012-10-17",
    "Statement": [{"Effect": "Allow",
                   "Action": ["s3:GetObject", "s3:ListBucket"],
                   "Resource": "*"}],
}
arn = iam.create_policy(PolicyName="S3ReadOnly-for-devs",
                        PolicyDocument=json.dumps(policy))["Policy"]["Arn"]
iam.attach_group_policy(GroupName="developers", PolicyArn=arn)

# ③ ユーザーを作ってグループに入れる。以後taroはS3の読み取りだけできる
iam.create_user(UserName="taro")
iam.add_user_to_group(GroupName="developers", UserName="taro")

サービスに権限を渡すときは、ユーザーではなくロールを使います。ロールには「誰がこの身分を引き受けていいか」を書く信頼ポリシーがセットで要ります。

# ④ EC2が引き受けられるロールを作り、S3読み取りの権限を付ける
trust = {
    "Version": "2012-10-17",
    "Statement": [{"Effect": "Allow",
                   "Principal": {"Service": "ec2.amazonaws.com"},   # 引き受けていいのはEC2
                   "Action": "sts:AssumeRole"}],
}
iam.create_role(RoleName="ec2-s3-reader",
                AssumeRolePolicyDocument=json.dumps(trust))
iam.attach_role_policy(RoleName="ec2-s3-reader", PolicyArn=arn)

このロールをEC2インスタンスに割り当てると、その上で動くプログラムはアクセスキーを持たなくてもS3を読めます。サーバーにアクセスキーを置かないための正攻法がこれです。

使い分け。ユーザーかロールか

下の絵が判断の基準です。

左が人、右がプログラム。プログラムにパスワードは要りません。

試験でも実務でも「アクセスキーをEC2に置くか、ロールを使うか」は定番の判断問題で、答えは常にロールです。

料金の考え方

IAM、IAM Identity Center、STS(一時認証情報の発行)は追加料金なしです。課金されるのは、IAMで作った身分を使って他のサービス(EC2やS3)を使ったときの、そのサービス側の料金だけです。IAM Access Analyzerの一部機能(未使用アクセスの分析など)は別料金があります。

よくある注意点

一番やってはいけないのが、左のやり方です。

右のように、ロールを付けておけばキーを置く必要がありません。

• ルートユーザーで日常作業をしない。 アカウント作成直後にルートにMFAを設定し、管理用のIAMユーザー(またはIdentity Centerのユーザー)を作ってそちらで作業します。ルートが必要なのはアカウント設定変更など限られた操作だけです
• アクセスキーをコードやリポジトリに書かない。 GitHubに上げた瞬間に拾われて不正利用される事故は今も続いています。プログラムにはロールを使う、ローカルではCLIの認証設定を使う
• 最初から広い権限を付けない。 AdministratorAccess を全員に付ける運用は楽ですが、事故のときの被害が全損になります。用途別のグループに最小権限で
• IAMの変更は反映に少し時間がかかる。 IAMは結果整合性なので、ポリシーを変えた直後は古い判定が返ることがあります。アプリの中でIAMを動的に書き換える設計は避けてください

まとめ

• IAMは「誰が・何をしていいか」を管理する、全サービスの前提
• 権限はポリシー(JSON)で書き、ユーザー・グループ・ロールに付ける。既定は拒否、明示Denyが最優先
• 人にはユーザー+グループ、サービスにはロール。アクセスキーはサーバーに置かない
• ルートユーザーはMFAをかけて封印し、日常はIAMユーザーで

次回はS3(ストレージ)を予定しています。

参考

• AWS IAM 公式ドキュメント
• シリーズ索引: AWSとは何か
• 前回: SNS入門