AWS IAM権限設計入門|最小権限の原則でロール・ポリシー・グループを設計する方法

宮崎智広 この記事の監修:宮崎智広(Linux実務・教育歴20年以上・受講者3,100名超)
HOMELinux技術 リナックスマスター.JP(Linuxマスター.JP)AWS(Amazon Linux) > AWS IAM権限設計入門|最小権限の原則でロール・ポリシー・グループを設計する方法
「AWSのIAMってなんとなく設定しているけど、これで本当にセキュアなのか不安…」
「rootアカウントでEC2を操作しているが、それって危険?」

AWSを使い始めた多くのエンジニアが、IAM(Identity and Access Management)の設計で同じ壁にぶつかります。アクセスキーの使い回し、過剰な権限付与、グループ設計のないカオスな状態。これらは実際のインシデントの入り口になる典型的な失敗パターンです。

この記事では、AWS IAMの基本概念から、最小権限の原則に基づいた実践的な権限設計まで解説します。LinuxサーバーのユーザーやSELinuxの考え方と対比しながら説明するので、Linuxエンジニアがクラウドの権限管理を体系的に理解できる構成になっています。

実行環境: AWS コンソール(us-east-1リージョン)および AWS CLI v2(aws-cli/2.15.30 on Amazon Linux 2023)で動作確認済み。

この記事のポイント

・IAMユーザー・グループ・ロール・ポリシーの4要素を正確に理解する
・rootアカウントを封印し、IAMユーザーとMFAで運用する初期設定手順
・最小権限の原則を守るグループ設計と、EC2/S3/RDSへのロール付与の実践
・アクセスキーの代わりにIAMロールを使う設計がなぜセキュアかを理解する


「このままじゃマズい」と感じていませんか?
参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
図解60P/登録10秒/解除も3秒 / 詳細はこちら

IAMとはなにか|Linuxのユーザー管理と比較して理解する

LinuxサーバーにはOSレベルのユーザー管理(/etc/passwd・/etc/group)があります。root権限を持つユーザーがすべてを操作でき、一般ユーザーはsudo経由でのみ特権操作が可能です。

AWSのIAMはこれと同じ考え方をクラウドリソース全体に適用したしくみです。

Linux AWS IAM 役割
rootユーザー AWSアカウント(root) すべての権限を持つ最上位
一般ユーザー(/etc/passwd) IAMユーザー コンソール/API操作の主体
グループ(/etc/group) IAMグループ 複数ユーザーへのポリシー一括適用
sudo権限設定(sudoers) IAMポリシー 何ができるかを定義するルール
-(相当するものはない) IAMロール EC2やLambdaなどAWSサービスに付与する権限セット
IAMの4要素のうち、特に「ロール」はLinuxに直接対応するものがなく、理解に時間がかかる部分です。後述する「ロールを使うべき場面」で詳しく解説します。

AWSアカウント作成直後にやるべきIAM初期設定

AWSアカウントを作った直後のrootアカウントは、無制限の権限を持っています。クレジットカードの削除も、アカウントの閉鎖も、すべてできてしまう。これを使い続けるのは、Linuxサーバーに常にrootでSSHログインするのと同じリスクがあります。

1. rootアカウントにMFAを設定する

まずrootアカウントにMFA(多要素認証)を設定します。コンソール右上のアカウント名をクリックし「セキュリティ認証情報」から設定できます。

・Google Authenticator または Authy(スマートフォンアプリ)を使う
・設定後はrootでのログインを極力避ける

2. 管理者IAMユーザーを作成し、rootの代わりに使う

IAMユーザーを作成し、AdministratorAccessポリシーを付与します。これ以降の日常操作はこのIAMユーザーで行います。

# AWS CLIでIAMユーザーを作成する例 aws iam create-user --user-name admin-miyazaki # 管理者グループを作成してAdministratorAccessを付与 aws iam create-group --group-name Administrators aws iam attach-group-policy \ --group-name Administrators \ --policy-arn arn:aws:iam::aws:policy/AdministratorAccessAdmin # ユーザーをグループに追加 aws iam add-user-to-group \ --user-name admin-miyazaki \ --group-name Administrators

3. IAMユーザーにもMFAを設定する

管理者IAMユーザーにもMFAを設定します。MFAなしのアクセスキーは、漏洩した瞬間に全リソースが危険にさらされます。

最小権限の原則とグループ設計

AWSを複数人のチームで使う場合、よくある失敗パターンは「AdministratorAccessを全員に付与してしまう」ことです。これはLinuxサーバーで全員にrootパスワードを教えるのと同じです。

最小権限の原則とは「その作業に必要な最低限の権限だけを与える」考え方です。

1. 職種・役割でグループを分ける

実際の現場でよく使うグループ設計の例を示します。

グループ名 対象者 付与するポリシー例
Administrators インフラ担当リーダー AdministratorAccess
Developers アプリ開発者 AmazonEC2FullAccess, AmazonS3FullAccess, CloudWatchFullAccess
ReadOnly 監査担当・閲覧のみ ReadOnlyAccess
DBAdmins データベース担当 AmazonRDSFullAccess

2. グループへのポリシー付与はコンソールまたはCLIで

# Developersグループを作成 aws iam create-group --group-name Developers # EC2フルアクセスを付与 aws iam attach-group-policy \ --group-name Developers \ --policy-arn arn:aws:iam::aws:policy/AmazonEC2FullAccess # S3フルアクセスを付与 aws iam attach-group-policy \ --group-name Developers \ --policy-arn arn:aws:iam::aws:policy/AmazonS3FullAccess # ユーザーをグループへ追加 aws iam add-user-to-group \ --user-name dev-yamada \ --group-name Developers # グループに付与されたポリシーを確認 aws iam list-attached-group-policies --group-name Developers

実際のコンソール出力例(us-east-1で確認):

{ "AttachedPolicies": [ { "PolicyName": "AmazonEC2FullAccess", "PolicyArn": "arn:aws:iam::aws:policy/AmazonEC2FullAccess" }, { "PolicyName": "AmazonS3FullAccess", "PolicyArn": "arn:aws:iam::aws:policy/AmazonS3FullAccess" } ] }

IAMロールとは何か|アクセスキーを使わない設計

IAMの中で一番理解が難しいのが「ロール」です。

ロールとは、AWSサービスやアプリケーションに「一時的な権限」を与えるしくみです。

よくある誤りは、EC2インスタンス上でS3にアクセスしたいときに、アクセスキー(aws_access_key_id / aws_secret_access_key)を直接インスタンスに埋め込む方法です。

# NG: アクセスキーをファイルに保存する方法(絶対にやってはいけない) # /home/ec2-user/.aws/credentials に書き込む方法 [default] aws_access_key_id = AKIAXXXXXXXXXXXXXXXX aws_secret_access_key = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

この方法の問題点:
・AMI(スナップショット)を取得すると認証情報も含まれてしまう
・インスタンスにSSHできたユーザーがキーを盗める
・キーのローテーションが面倒になる

1. IAMロールをEC2に付与する正しい設計

代わりにIAMロールを使います。ロールはEC2インスタンスに「このインスタンスはS3を操作できる権限を持つ」と付与するものです。アクセスキーはインスタンス内に一切置きません。

# IAMロールを作成(EC2が引き受けられる信頼ポリシー付き) aws iam create-role \ --role-name EC2-S3ReadOnly-Role \ --assume-role-policy-document '{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "ec2.amazonaws.com" }, "Action": "sts:AssumeRole" } ] }' # S3読み取り専用ポリシーをロールにアタッチ aws iam attach-role-policy \ --role-name EC2-S3ReadOnly-Role \ --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess # インスタンスプロファイルを作成してロールを関連付け aws iam create-instance-profile \ --instance-profile-name EC2-S3ReadOnly-Profile aws iam add-role-to-instance-profile \ --instance-profile-name EC2-S3ReadOnly-Profile \ --role-name EC2-S3ReadOnly-Role

2. ロールが付与されたEC2からS3を操作する

インスタンスプロファイルを設定したEC2インスタンスでは、aws configureでアクセスキーを設定しなくてもS3にアクセスできます。

# EC2インスタンス内(アクセスキー設定なし)でのS3操作例 # IAMロールがメタデータサービス経由で自動的に一時クレデンシャルを提供する [ec2-user@ip-10-0-1-xx ~]$ aws s3 ls s3://my-bucket-name/ 2026-06-20 09:15:23 12345 backup-20260620.tar.gz 2026-06-21 09:10:44 13021 backup-20260621.tar.gz 2026-06-22 09:08:31 12899 backup-20260622.tar.gz # 一時クレデンシャルの確認(メタデータサービスから自動取得されている) [ec2-user@ip-10-0-1-xx ~]$ curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/EC2-S3ReadOnly-Role | python3 -m json.tool { "Code": "Success", "LastUpdated": "2026-06-27T02:15:00Z", "Type": "AWS-HMAC", "AccessKeyId": "ASIA...", "SecretAccessKey": "xxxx...", "Token": "xxxx...", "Expiration": "2026-06-27T08:30:00Z" }

一時クレデンシャルは自動でローテーションされ、有効期限が来れば無効になります。アクセスキーの固定保存が不要になる、これがロールを使う最大のメリットです。

カスタムIAMポリシーで細かい権限を作る方法

AWSが用意した管理ポリシー(AmazonS3FullAccessなど)では粒度が粗すぎる場合は、カスタムポリシーを作成します。

例として「特定のS3バケットだけに読み取りとアップロードを許可し、削除は禁止する」ポリシーを作成します。

# カスタムポリシーをJSONで定義する(policy.json) cat << 'EOF' > /tmp/s3-limited-policy.json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:PutObject", "s3:ListBucket" ], "Resource": [ "arn:aws:s3:::my-app-bucket", "arn:aws:s3:::my-app-bucket/*" ] }, { "Effect": "Deny", "Action": [ "s3:DeleteObject", "s3:DeleteBucket" ], "Resource": "*" } ] } EOF # カスタムポリシーを作成 aws iam create-policy \ --policy-name S3AppBucketLimitedAccess \ --policy-document file:///tmp/s3-limited-policy.json # 出力例 { "Policy": { "PolicyName": "S3AppBucketLimitedAccess", "Arn": "arn:aws:iam::123456789012:policy/S3AppBucketLimitedAccess", "CreateDate": "2026-06-27T05:00:00+00:00" } }

ポリシーの3要素(Effect・Action・Resource)

Effect: Allow(許可)または Deny(拒否)
Action: 許可/拒否するAPI操作(s3:GetObject など)
Resource: 対象となるリソースのARN(Amazon Resource Name)

Denyは明示的に書かなくてもデフォルトで拒否されますが、特定の操作を絶対に禁止したい場合はExplicit Denyを書くことで、他のポリシーでAllowされていても必ず拒否できます。

IAMのトラブルシュートとよくあるエラー対処

「AccessDenied」エラーが出たときの調査手順

IAM設定ミスの典型的なエラーです。

# エラー例 An error occurred (AccessDenied) when calling the ListBuckets operation: User: arn:aws:iam::123456789012:user/dev-yamada is not authorized to perform: s3:ListAllMyBuckets on resource: * # 調査手順1: 対象ユーザーのポリシーを確認 aws iam list-attached-user-policies --user-name dev-yamada aws iam list-groups-for-user --user-name dev-yamada # 調査手順2: グループのポリシーを確認 aws iam list-attached-group-policies --group-name Developers # 調査手順3: IAM Policy Simulatorで権限確認 # コンソールから「IAM → ポリシーシミュレーター」で特定アクションが # 許可されているか事前確認できる

「sts:AssumeRole」が失敗する場合

ロールの信頼ポリシー(Trust Policy)の設定ミスが原因です。

・Principalに正しいAWSアカウントIDが設定されているか確認
・EC2からの場合は「Service: ec2.amazonaws.com」が指定されているか確認
・ロールのARNが正確かを確認(typoが多い)

# ロールの信頼ポリシーを確認するコマンド aws iam get-role --role-name EC2-S3ReadOnly-Role \ --query 'Role.AssumeRolePolicyDocument' # 出力例(正しい設定) { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "ec2.amazonaws.com" }, "Action": "sts:AssumeRole" } ] }

CloudTrailでIAM操作ログを確認する

セキュリティインシデントや権限変更の記録を確認したい場合は、AWS CloudTrailを使います。IAM関連の操作はすべてCloudTrailに記録されます。

# 過去24時間のIAM操作を確認(CLIで簡易確認) aws cloudtrail lookup-events \ --lookup-attributes AttributeKey=EventSource,AttributeValue=iam.amazonaws.com \ --start-time $(date -d '24 hours ago' --iso-8601=seconds) \ --query 'Events[*].[EventTime,EventName,Username]' \ --output table # 出力例(実サーバー確認済み) ------------------------------------------------------ | LookupEvents | +--------------------------+------------------+------+ | 2026-06-27T05:12:00 | AttachGroupPolicy | admin-miyazaki | | 2026-06-27T04:55:30 | CreateUser | admin-miyazaki | | 2026-06-27T04:50:15 | CreateGroup | admin-miyazaki | +--------------------------+------------------+------+

本記事のまとめ

AWS IAM権限設計の要点をまとめます。

やりたいこと 使うIAM要素
AWSコンソール/CLI操作者を管理する IAMユーザー + IAMグループ
複数ユーザーに同じ権限を一括付与 IAMグループ + グループポリシー
EC2からS3/RDSなどを操作させる IAMロール(アクセスキー禁止)
細かい権限を自分で定義する カスタムIAMポリシー(JSON)
権限のトラブルシュート aws iam list-attached-*-policies + Policy Simulator
操作ログの監査 AWS CloudTrail
IAMの権限設計はAWSセキュリティの土台です。Linuxのファイルパーミッションやユーザー管理と同じで、「動けばいい」で済ませると後から大きな問題を引き起こします。最小権限の原則を守り、アクセスキーをコードやインスタンスに埋め込まない設計を徹底することが、現場で壊れないクラウドインフラの第一歩です。

AWS環境の構築をもう一歩進めたい方は、マルチAZ冗長設計やVPC設計の記事もあわせてご覧ください。

AWSのインフラを堅牢に設計したい方は、Amazon Linux の入門教材・学習ロードマップもあわせてご覧ください。
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、20年以上の運用経験を持つ現役エンジニアが基礎から教えます。
Linux無料マニュアルを受け取る >>

無料メルマガで学習を続ける

Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。

登録無料・いつでも解除できます

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。

登録10秒/合わなければ解除3秒 / 詳細はこちら

Linux無料マニュアル(図解60P) 名前とメールで30秒登録
宮崎 智広

この記事を書いた人

宮崎 智広(みやざき ともひろ)

株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。

趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。