対象読者: 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のアカウントでログインさせる

重要用語

用語	意味
ルートユーザー	アカウント作成時のメールアドレスでログインする最上位の身分。全権限を持つ。日常作業には使わない
IAMユーザー	人やアプリ用に作る個別の身分。ログインパスワードやアクセスキーを持てる
グループ	IAMユーザーの集まり。グループに権限を付けると所属ユーザー全員に効く
ロール	「一時的に引き受ける身分」。人だけでなくEC2やLambdaなどのサービスにも割り当てられる。パスワード無し
ポリシー	権限のルールを書いたJSON文書。「どの操作(Action)を、どのリソース(Resource)に、許可(Allow)か拒否(Deny)か」を書く
最小権限の原則	仕事に必要な最小限の権限だけを付与する考え方。IAM設計の基本
MFA	多要素認証。パスワードに加えてスマホの確認コード等を要求する

仕組みの要点

権限はポリシーという形で表現され、それをユーザー・グループ・ロールのいずれかに付けます。ポリシーの中身はこういう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)で示します。

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を読めます。サーバーにアクセスキーを置かないための正攻法がこれです。

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

場面	選ぶもの	理由
人がコンソールやCLIで作業する	IAMユーザー(+グループ)	個人ごとの身分と監査ログが要る
EC2 / Lambda / ECS上のプログラムがAWSを触る	ロール	キーを配布・保管せずに済む。漏えいリスクを減らせる
別アカウントの人に一時的に作業させる	ロール(クロスアカウント)	期限付きの一時認証情報で渡せる
社内のIDでログインさせたい	IAM Identity Center(旧SSO)	人数が増えるとIAMユーザーの手管理は破綻する

試験でも実務でも「アクセスキーを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(ストレージ)を予定しています。

参考