対象読者: 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(ストレージ)を予定しています。
参考
- AWS IAM 公式ドキュメント
- シリーズ索引: AWSとは何か
- 前回: SNS入門