AWS_IAM入門_最小権限の設計と運用ベストプラクティス

「AWSアカウントを作ったはいいが、IAMの設定が正しいのか自信がない」——クラウド移行の初期段階で、こうした不安を感じるインフラ担当者は少なくないはずです。

オンプレ環境では、サーバールームの入退室管理やActive Directoryで権限を制御してきた方も多いでしょう。AWSではその役割を担うのがIAM（Identity and Access Management）です。しかし、IAMのポリシー設計を誤ると、情報漏洩や意図しないリソース削除といった重大事故につながります。

この記事では、AWS IAMの基本概念から最小権限の設計方法、運用時のベストプラクティスまで、オンプレ経験者の目線でわかりやすく解説します。

なぜIAMが重要なのか？オンプレとの違い

オンプレ環境の権限管理は、物理的なアクセス制御とOSレベルのユーザー管理が中心でした。サーバールームに入れる人を制限し、LinuxならsudoersやPAMで権限を絞るのが一般的な手法です。

クラウドでは、この考え方が大きく変わります。AWSの操作はすべてAPI経由で行われるため、「誰が」「どのリソースに」「何をできるか」をAPI単位で制御する必要があります。この制御を一手に担うのがIAMです。

オンプレとの最大の違いは「攻撃面の広さ」です。オンプレならネットワーク境界で守れましたが、クラウドではインターネット経由でAPIを叩けてしまいます。認証情報が漏洩した瞬間に、世界中のどこからでもリソースを操作されるリスクがあります。

だからこそ、IAMの設計は「最小権限の原則」を徹底することが不可欠です。

IAMの基本概念を押さえる

1. IAMユーザーとIAMロール

IAMには「ユーザー」と「ロール」という2つの主要な概念があります。

・IAMユーザー: 人間がAWSマネジメントコンソールやCLIにログインするためのアカウント。長期的な認証情報（アクセスキー）を持つ
・IAMロール: 一時的な認証情報を使って権限を委任する仕組み。Amazon EC2インスタンスやAWS Lambda関数に割り当てて使う

オンプレで例えると、IAMユーザーは「個人のログインアカウント」、IAMロールは「特定の作業用に切り替える権限セット」に近い感覚です。sudoで一時的にroot権限を取得するイメージが近いかもしれません。

2. IAMポリシーの構造

IAMポリシーはJSON形式で記述します。主要な要素は以下の4つです。

・Effect: Allow（許可）またはDeny（拒否）
・Action: 許可/拒否するAPIアクション（例: ec2:StartInstances）
・Resource: 対象のAWSリソース（ARNで指定）
・Condition: 条件付きのアクセス制御（IP制限、MFA必須など）

実際のポリシー例を見てみましょう。以下は、特定のS3バケットへの読み取りのみを許可するポリシーです。

# S3バケットへの読み取り専用ポリシー（JSON）
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::my-app-bucket",
        "arn:aws:s3:::my-app-bucket/*"
      ]
    }
  ]
}

3. IAMグループで管理を効率化する

ユーザーが増えてくると、個別にポリシーを割り当てるのは現実的ではありません。IAMグループを作成し、グループにポリシーを付与して、ユーザーをグループに所属させるのが定石です。

オンプレのActive Directoryでセキュリティグループを使って権限管理していた方なら、まったく同じ考え方です。

最小権限ポリシーの設計手順

1. AWS管理ポリシーから始める

AWSが提供する管理ポリシー（AWS Managed Policy）を出発点にするのが効率的です。たとえば「ReadOnlyAccess」や「AmazonEC2FullAccess」など、用途別に用意されています。

ただし、AWS管理ポリシーはそのまま本番で使うには権限が広すぎることがほとんどです。あくまで「たたき台」として使い、不要な権限を削っていく方針が安全です。

2. IAM Access Analyzerで実際の利用状況を確認

IAM Access Analyzerの「ポリシー生成」機能を使えば、CloudTrailのログから実際に使われたAPIアクションだけを含むポリシーを自動生成できます。

1. IAMコンソールを開く
2. 左メニューから「Access Analyzer」を選択
3. 「ポリシー生成」タブを開く
4. 対象のIAMロールまたはユーザーと、分析期間（最大90日）を指定
5. 生成されたポリシーを確認・修正して適用

AWS CLIでAccess Analyzerの結果を取得する方法も紹介します。

# IAM Access Analyzerの検出結果を一覧表示（AWS CLI）
aws accessanalyzer list-findings \
  --analyzer-arn "arn:aws:access-analyzer:ap-northeast-1:123456789012:analyzer/my-analyzer" \
  --query "findings[*].[resource,resourceType,status]" \
  --output table

3. Conditionで条件を絞り込む

最小権限をさらに強化するには、Condition要素を活用します。よく使われる条件は以下の通りです。

・IPアドレス制限: 社内ネットワークからのみアクセスを許可
・MFA必須: 多要素認証が有効なセッションのみ許可
・タグベースの制御: 特定のタグが付いたリソースのみ操作を許可

MFAを必須にするConditionの例です。

# MFA必須のCondition例（ポリシーのStatement内に追加）
"Condition": {
  "Bool": {
    "aws:MultiFactorAuthPresent": "true"
  }
}

料金の仕組み

IAM自体は無料で利用できます。ユーザー数やポリシー数に関係なく、追加料金は発生しません。

ただし、IAMと組み合わせて使うことが多い以下のサービスには料金がかかります（2026年3月時点）。

・AWS CloudTrail: 管理イベントは無料。データイベントの記録は10万イベントあたり$0.10（東京リージョン）
・AWS IAM Identity Center（旧AWS SSO）: 基本利用は無料。外部IdP連携も追加料金なし
・AWS Organizations: 無料。マルチアカウント管理でIAMと組み合わせて使う

IAMのセキュリティ対策にコストがかからないのは、AWSが「セキュリティは最優先事項」と位置づけている表れです。使わない理由がありません。

実務で効くIAM運用のベストプラクティス

ルートユーザーを封印する

AWSアカウント作成時に使ったメールアドレスとパスワードの組み合わせが「ルートユーザー」です。全権限を持つため、日常的な作業には絶対に使わないでください。

ルートユーザーにはMFAを有効化し、アクセスキーは作成しない。普段の作業はIAMユーザーまたはIAM Identity Center経由で行う。これが鉄則です。

アクセスキーよりIAMロールを使う

EC2上のアプリケーションからAWSサービスを呼び出す場合、アクセスキーを環境変数やコードに埋め込むのは危険です。GitHubへの誤コミットで認証情報が漏洩する事故は後を絶ちません。

代わりに、EC2インスタンスにIAMロールを割り当てます。ロールを使えば、一時的な認証情報が自動的にローテーションされるため、長期的な認証情報の管理が不要です。

オンプレでいえば、アプリケーションにパスワードをハードコードするのではなく、Kerberos認証のようにチケットベースで認証する仕組みに近いです。

AWS CloudTrailで操作を監査する

IAMの権限設計が正しく機能しているかを確認するには、CloudTrailが欠かせません。誰が・いつ・何をしたかをすべて記録してくれます。

Linuxのauditdやsyslogで操作ログを取っていた経験がある方なら、CloudTrailはそのクラウド版だと考えてください。セキュリティの詳しい基礎知識については、姉妹サイトLinuxMaster.JPでも解説しています。

よくあるトラブルと対処法

Access Deniedエラーで操作ができない

最も多いトラブルです。原因の切り分けには、IAMポリシーシミュレーターが役立ちます。

1. IAMコンソールで対象ユーザーまたはロールを選択
2. 「ポリシーシミュレーター」をクリック
3. 実行したいアクションとリソースARNを入力してシミュレーション
4. どのポリシーでDenyされているかが表示される

よくある原因としては、明示的なDenyポリシーが適用されている、リソースARNの指定が間違っている、SCPやPermissions Boundaryで制限されている、といったパターンがあります。

アクセスキーが漏洩してしまった

万が一、アクセスキーがGitHubなどに流出した場合は、即座に以下の手順を実行してください。

1. IAMコンソールで対象のアクセスキーを「無効化」する（削除ではなくまず無効化）
2. CloudTrailで漏洩したキーによる不正操作がないか確認
3. 不正なリソース（EC2インスタンスなど）が作成されていれば削除
4. 問題がなければアクセスキーを削除し、必要に応じて新しいキーを発行

ポリシーが複雑になりすぎて管理できない

ポリシーの肥大化は、多くのチームが直面する課題です。対策としては以下が有効です。

・サービス単位でポリシーを分割する（1ポリシー1サービスの原則）
・IAMグループとロールを組み合わせ、直接ユーザーにポリシーを付与しない
・定期的にIAM Access Analyzerで未使用の権限を洗い出し、削除する

本記事のまとめ

AWS IAMはクラウドセキュリティの土台です。最小権限の原則を守り、ルートユーザーを封印し、アクセスキーよりIAMロールを使う。この3つを徹底するだけで、セキュリティレベルは大幅に向上します。

オンプレ時代に培った「権限は必要最低限に絞る」という感覚は、クラウドでもそのまま通用します。まずは自分の環境のIAM設定を見直すところから始めてみてください。