「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ロールを使う設計がなぜセキュアかを理解する
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
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サービスに付与する権限セット |
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
{ "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 |
AWS環境の構築をもう一歩進めたい方は、マルチAZ冗長設計やVPC設計の記事もあわせてご覧ください。
AWSのインフラを堅牢に設計したい方は、Amazon Linux の入門教材・学習ロードマップもあわせてご覧ください。
Linux無料マニュアルを受け取る >>
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
登録10秒/合わなければ解除3秒 / 詳細はこちら
- 次のページへ:AWS RDSのマルチAZとリードレプリカで可用性を高めるデータベース設計入門
- 前のページへ:AWS Auto ScalingとELBで作る高可用性アーキテクチャ|EC2自動スケーリングとロードバランサーの設計パターン入門
- この記事の属するカテゴリ:AWS(Amazon Linux)へ戻る

無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。
登録無料・いつでも解除できます