IAMセキュリティのベストプラクティス完全ガイド

IAMの基礎概念やポリシーの構造を理解した次のステップとして、本番環境で実践すべきセキュリティベストプラクティスを学びましょう。本記事では、AWS公式が推奨するIAMセキュリティのベストプラクティス15項目を体系的に解説します。これらを適切に実装することで、AWSアカウントのセキュリティを大幅に強化できます。

ベストプラクティスの全体像

AWSが推奨するIAMセキュリティのベストプラクティスは、大きく5つのカテゴリに分類できます。

mindmap
  root((IAMセキュリティ<br/>ベストプラクティス))
    ルートユーザーの保護
      ルートアクセスキーの禁止
      ルートユーザーへのMFA
      日常操作での使用禁止
    最小権限の原則
      必要最小限の権限付与
      Permission Boundary活用
      条件キーによる制限
    認証情報の管理
      認証情報のローテーション
      未使用認証情報の削除
      強力なパスワードポリシー
    IAMロールの活用
      一時的認証情報の使用
      クロスアカウントアクセス
      EC2インスタンスへのロール
    監査とモニタリング
      IAM Access Analyzer
      CloudTrailによる監査
      定期的なレビュー

それでは、各ベストプラクティスを詳しく見ていきましょう。

1. ルートユーザーのアクセスキーを作成しない

ルートユーザーはAWSアカウント内のすべてのリソースに対する完全なアクセス権を持ち、この権限を制限することはできません。ルートユーザーのアクセスキーが漏洩した場合、アカウント全体が完全に侵害される可能性があります。

推奨される対応

ルートユーザーのアクセスキーが存在する場合は、速やかに削除します。プログラムによるアクセスが必要な場合は、適切な権限を持つIAMユーザーまたはIAMロールを使用します。

flowchart LR
    A[ルートアクセスキー<br/>存在確認] --> B{アクセスキーが<br/>存在する?}
    B -->|Yes| C[キーの使用状況<br/>を確認]
    C --> D[依存関係を<br/>IAMロールに移行]
    D --> E[アクセスキーを<br/>無効化]
    E --> F[アクセスキーを<br/>削除]
    B -->|No| G[安全な状態]

確認方法

AWSマネジメントコンソールのIAMダッシュボードで、「セキュリティに関する推奨事項」セクションを確認します。ルートアクセスキーの有無が表示されます。

また、AWS CLIでも確認可能です。

1

aws iam get-account-summary --query 'SummaryMap.AccountAccessKeysPresent'

このコマンドが1を返した場合、ルートユーザーにアクセスキーが存在します。

2. ルートユーザーでMFAを有効化する

ルートユーザーは万能の権限を持つため、万が一パスワードが漏洩した場合でも不正アクセスを防止できるよう、必ずMFA（多要素認証）を有効化します。

推奨されるMFAデバイス

ルートユーザーには、フィッシング耐性の高いFIDO2セキュリティキーの使用が最も推奨されます。以下の優先順位でMFAデバイスを選択してください。

設定手順

1. ルートユーザーでAWSマネジメントコンソールにサインイン
2. 右上のアカウント名をクリックし、「セキュリティ認証情報」を選択
3. 「多要素認証（MFA）」セクションで「MFAデバイスを割り当てる」をクリック
4. デバイスタイプを選択し、画面の指示に従って設定

3. 日常的なタスクにルートユーザーを使用しない

ルートユーザーは、AWSアカウントの作成時に自動的に作成されますが、日常的なタスクには使用すべきではありません。代わりに、管理者権限を持つIAMユーザーまたはIAM Identity Centerのユーザーを作成して使用します。

ルートユーザーが必要なタスク

以下のタスクは、ルートユーザーでしか実行できないため、これらの場合のみルートユーザーを使用します。

• AWSアカウントの設定変更（アカウント名、メールアドレス、パスワード）
• AWSアカウントの解約
• IAMユーザーへの請求情報へのアクセス許可
• リザーブドインスタンスマーケットプレイスへの出品登録
• GovCloudへのサインアップ
• 無効化されたSTSリージョンの有効化
• 誤って設定されたS3バケットポリシーやSQSポリシーの修復

推奨される運用フロー

flowchart TD
    A[タスクの発生] --> B{ルートユーザーが<br/>必要なタスク?}
    B -->|Yes| C[ルートユーザーで<br/>サインイン]
    C --> D[MFA認証]
    D --> E[タスク実行]
    E --> F[即座にサインアウト]
    B -->|No| G[管理者IAMユーザー<br/>でサインイン]
    G --> H[タスク実行]

4. フェデレーションIDプロバイダーを使用する

組織で既にIDプロバイダー（Active Directory、Okta、Azure ADなど）を使用している場合は、AWS IAM Identity Centerを通じてフェデレーションを設定することを推奨します。これにより、以下のメリットが得られます。

フェデレーションのメリット

IAM Identity Centerの構成

flowchart LR
    subgraph "企業ネットワーク"
        U[ユーザー]
        IdP[IDプロバイダー<br/>Azure AD/Okta]
    end
    
    subgraph "AWS"
        IC[IAM Identity Center]
        A1[AWSアカウント1]
        A2[AWSアカウント2]
        A3[AWSアカウント3]
    end
    
    U --> IdP
    IdP -->|SAML/SCIM| IC
    IC --> A1
    IC --> A2
    IC --> A3

5. 最小権限を適用する

最小権限の原則は、IAMセキュリティの根幹となる考え方です。ユーザーやロールには、タスクを実行するために必要な権限のみを付与します。

最小権限の実装アプローチ

最小権限を実装するには、以下のステップで段階的にアプローチします。

flowchart TD
    A[権限設計開始] --> B[必要なアクションの<br/>特定]
    B --> C[対象リソースの<br/>特定]
    C --> D[条件の追加<br/>IP/MFA/タグ等]
    D --> E[ポリシーの作成]
    E --> F[テスト環境で<br/>検証]
    F --> G{動作確認}
    G -->|OK| H[本番適用]
    G -->|NG| I[権限の調整]
    I --> F

実践的なテクニック

リソースレベルのアクセス許可を使用する

可能な限り、Resource要素にワイルドカード（*）ではなく、具体的なARNを指定します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::my-bucket/reports/*"
        }
    ]
}

条件キーで制限を追加する

IPアドレス、MFA認証、タグなどの条件を追加して、アクセスをさらに制限します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "ec2:*",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "aws:ResourceTag/Environment": "Development"
                },
                "IpAddress": {
                    "aws:SourceIp": "203.0.113.0/24"
                }
            }
        }
    ]
}

IAM Access Analyzerの活用

IAM Access Analyzerのポリシー生成機能を使用すると、CloudTrailのログに基づいて、実際に使用されたアクションのみを許可するポリシーを生成できます。

6. AWS管理ポリシーから始めてカスタムポリシーに移行する

IAMポリシーの設計では、まずAWS管理ポリシーを使用し、運用しながら徐々にカスタムポリシーに移行することを推奨します。

移行のアプローチ

flowchart LR
    A[AWS管理ポリシー<br/>で開始] --> B[CloudTrailで<br/>使用状況を監視]
    B --> C[不要な権限を<br/>特定]
    C --> D[カスタムポリシー<br/>を作成]
    D --> E[テスト環境で<br/>検証]
    E --> F[段階的に移行]

主要なAWS管理ポリシー

7. IAMユーザーではなくIAMロールを使用する

アプリケーションやAWSサービスがAWSリソースにアクセスする場合は、IAMユーザーのアクセスキーではなく、IAMロールを使用します。IAMロールは一時的な認証情報を提供するため、長期的な認証情報の漏洩リスクを軽減できます。

IAMロールの主な使用シナリオ

flowchart TB
    subgraph "IAMロールの使用シナリオ"
        direction TB
        
        subgraph "EC2インスタンス"
            E1[EC2] --> R1[インスタンスプロファイル]
        end
        
        subgraph "Lambda関数"
            L1[Lambda] --> R2[実行ロール]
        end
        
        subgraph "クロスアカウント"
            A1[アカウントA] --> R3[AssumeRole]
            R3 --> A2[アカウントB]
        end
        
        subgraph "コンテナ"
            ECS[ECS/EKS] --> R4[タスクロール]
        end
    end

EC2インスタンスへのロールの割り当て

EC2インスタンスでアクセスキーを使用する代わりに、インスタンスプロファイルを通じてIAMロールを割り当てます。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

# インスタンスプロファイルの作成
aws iam create-instance-profile --instance-profile-name MyAppProfile

# ロールをインスタンスプロファイルに追加
aws iam add-role-to-instance-profile \
    --instance-profile-name MyAppProfile \
    --role-name MyAppRole

# EC2インスタンスにインスタンスプロファイルを関連付け
aws ec2 associate-iam-instance-profile \
    --instance-id i-1234567890abcdef0 \
    --iam-instance-profile Name=MyAppProfile

8. 一時的な認証情報を使用する

長期的なアクセスキーではなく、一時的な認証情報を使用することで、セキュリティリスクを大幅に軽減できます。

一時的認証情報の取得方法

AWS CLI での一時認証情報の使用

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

# ロールを引き受けて一時認証情報を取得
aws sts assume-role \
    --role-arn arn:aws:iam::123456789012:role/MyRole \
    --role-session-name MySession \
    --duration-seconds 3600

# 取得した認証情報を環境変数に設定
export AWS_ACCESS_KEY_ID="ASIAXXX..."
export AWS_SECRET_ACCESS_KEY="xxx..."
export AWS_SESSION_TOKEN="xxx..."

9. アクセスキーを定期的にローテーションする

長期的なアクセスキーを使用する必要がある場合は、定期的にローテーション（更新）を行います。AWSは90日以内のローテーションを推奨しています。

アクセスキーのローテーション手順

flowchart TD
    A[新しいアクセスキー<br/>を作成] --> B[アプリケーションを<br/>新しいキーに更新]
    B --> C[新しいキーで<br/>動作確認]
    C --> D{動作OK?}
    D -->|Yes| E[古いキーを無効化]
    D -->|No| F[問題の調査・修正]
    F --> C
    E --> G[一定期間経過後<br/>古いキーを削除]

AWS CLIでのローテーション操作

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

# 新しいアクセスキーの作成
aws iam create-access-key --user-name MyUser

# 古いアクセスキーの無効化
aws iam update-access-key \
    --user-name MyUser \
    --access-key-id AKIAIOSFODNN7EXAMPLE \
    --status Inactive

# 古いアクセスキーの削除
aws iam delete-access-key \
    --user-name MyUser \
    --access-key-id AKIAIOSFODNN7EXAMPLE

10. 未使用の認証情報を削除する

使用されていない認証情報（パスワード、アクセスキー）は、不正利用のリスクを高めます。定期的に認証情報の使用状況を確認し、未使用のものは削除します。

認証情報レポートの生成

IAMの認証情報レポートを使用して、すべてのユーザーの認証情報の使用状況を確認できます。

1
2
3
4
5

# 認証情報レポートの生成を開始
aws iam generate-credential-report

# レポートのダウンロード
aws iam get-credential-report --output text --query Content | base64 -d > credential_report.csv

レポートで確認すべき項目

未使用認証情報の検出基準

一般的には、以下の基準で未使用認証情報を判定します。

• 90日以上使用されていないパスワード
• 90日以上使用されていないアクセスキー
• 作成後一度も使用されていない認証情報

11. 強力なパスワードポリシーを設定する

IAMユーザーに対して、強力なパスワードポリシーを適用します。これにより、推測されにくいパスワードの使用を強制できます。

推奨されるパスワードポリシー設定

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

{
    "MinimumPasswordLength": 14,
    "RequireSymbols": true,
    "RequireNumbers": true,
    "RequireUppercaseCharacters": true,
    "RequireLowercaseCharacters": true,
    "AllowUsersToChangePassword": true,
    "MaxPasswordAge": 90,
    "PasswordReusePrevention": 24,
    "HardExpiry": false
}

AWS CLIでのパスワードポリシー設定

1
2
3
4
5
6
7
8
9

aws iam update-account-password-policy \
    --minimum-password-length 14 \
    --require-symbols \
    --require-numbers \
    --require-uppercase-characters \
    --require-lowercase-characters \
    --allow-users-to-change-password \
    --max-password-age 90 \
    --password-reuse-prevention 24

パスワードポリシーの各項目

12. 人間のユーザーにMFAを要求する

コンソールにアクセスするすべてのIAMユーザーに対して、MFAを有効化することを強く推奨します。特に、管理者権限を持つユーザーには必須です。

MFAを強制するポリシー

以下のポリシーを適用することで、MFAが有効化されていないユーザーの操作を制限できます。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowViewAccountInfo",
            "Effect": "Allow",
            "Action": [
                "iam:GetAccountPasswordPolicy",
                "iam:ListVirtualMFADevices"
            ],
            "Resource": "*"
        },
        {
            "Sid": "AllowManageOwnMFA",
            "Effect": "Allow",
            "Action": [
                "iam:CreateVirtualMFADevice",
                "iam:EnableMFADevice",
                "iam:ListMFADevices",
                "iam:ResyncMFADevice"
            ],
            "Resource": [
                "arn:aws:iam::*:mfa/${aws:username}",
                "arn:aws:iam::*:user/${aws:username}"
            ]
        },
        {
            "Sid": "DenyAllExceptListedIfNoMFA",
            "Effect": "Deny",
            "NotAction": [
                "iam:CreateVirtualMFADevice",
                "iam:EnableMFADevice",
                "iam:ListMFADevices",
                "iam:ListVirtualMFADevices",
                "iam:ResyncMFADevice",
                "sts:GetSessionToken"
            ],
            "Resource": "*",
            "Condition": {
                "BoolIfExists": {
                    "aws:MultiFactorAuthPresent": "false"
                }
            }
        }
    ]
}

13. Permission Boundaryを活用する

Permission Boundaryは、IAMエンティティに付与できる権限の上限を設定する機能です。権限管理を委譲する際に、委譲先が過度な権限を付与することを防止できます。

Permission Boundaryの活用パターン

flowchart TD
    A[管理者] --> B[Permission Boundary<br/>を定義]
    B --> C[開発者に<br/>IAM作成権限を付与]
    C --> D[開発者がIAM<br/>ユーザー/ロールを作成]
    D --> E{Permission Boundary<br/>を超える権限?}
    E -->|Yes| F[操作拒否]
    E -->|No| G[作成成功]

権限委譲のためのPermission Boundary設定例

開発者がIAMユーザーを作成する際、必ずPermission Boundaryを付与することを強制するポリシーです。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "CreateUserWithBoundary",
            "Effect": "Allow",
            "Action": "iam:CreateUser",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "iam:PermissionsBoundary": "arn:aws:iam::123456789012:policy/DeveloperBoundary"
                }
            }
        }
    ]
}

14. IAM Access Analyzerで定期的に分析する

IAM Access Analyzerは、リソースポリシーを分析し、外部からアクセス可能なリソースや未使用のアクセスを検出するサービスです。定期的な分析により、セキュリティリスクを早期に発見できます。

IAM Access Analyzerの主な機能

外部アクセスアナライザーの有効化

1
2
3
4
5
6
7
8

# アナライザーの作成
aws accessanalyzer create-analyzer \
    --analyzer-name MyAnalyzer \
    --type ACCOUNT

# 検出結果の一覧取得
aws accessanalyzer list-findings \
    --analyzer-arn arn:aws:access-analyzer:ap-northeast-1:123456789012:analyzer/MyAnalyzer

未使用アクセスの分析

未使用アクセスアナライザーは、以下を検出します。

• 未使用のIAMロール
• 未使用のアクセスキー
• 未使用のパスワード
• 未使用の権限（特定のアクションが一度も使用されていない）

15. CloudTrailでIAMアクティビティを監視する

AWS CloudTrailを使用して、IAMに関するすべてのAPI呼び出しを記録・監視します。これにより、不正なアクティビティの検出や、インシデント発生時の調査が可能になります。

監視すべきIAMイベント

CloudWatch Alarmsによるアラート設定

重要なIAMイベントに対してアラートを設定します。以下は、ルートユーザーのログインを検知するメトリクスフィルターの例です。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

{
    "filterPattern": "{ $.userIdentity.type = \"Root\" && $.eventType = \"AwsConsoleSignIn\" }",
    "metricTransformations": [
        {
            "metricName": "RootAccountUsage",
            "metricNamespace": "CloudTrailMetrics",
            "metricValue": "1"
        }
    ]
}

EventBridgeルールによる自動対応

EventBridgeを使用して、特定のIAMイベントに対する自動対応を設定できます。

flowchart LR
    A[CloudTrail] --> B[EventBridge]
    B --> C{イベントパターン<br/>マッチ}
    C -->|マッチ| D[Lambda関数]
    D --> E[Slack通知]
    D --> F[自動修復]
    C -->|非マッチ| G[スキップ]

ベストプラクティスの実装チェックリスト

以下のチェックリストを使用して、組織のIAMセキュリティ状態を評価します。

flowchart TD
    subgraph "緊急度：高"
        A1[ルートアクセスキーの削除]
        A2[ルートユーザーのMFA有効化]
        A3[管理者ユーザーのMFA有効化]
    end
    
    subgraph "緊急度：中"
        B1[最小権限ポリシーの適用]
        B2[未使用認証情報の削除]
        B3[パスワードポリシーの設定]
    end
    
    subgraph "緊急度：低〜中"
        C1[IAMロールへの移行]
        C2[IAM Access Analyzerの有効化]
        C3[CloudTrailの監視設定]
    end

AWS Security Hubとの連携

AWS Security Hubを使用すると、IAMセキュリティのベストプラクティスへの準拠状況を自動的にチェックできます。CIS AWS Foundations Benchmarkなどのセキュリティ標準に基づいた継続的なコンプライアンスチェックが可能です。

Security Hubで確認できるIAM関連のチェック項目

• ルートアカウントにMFAが有効化されているか
• ルートアカウントにアクセスキーが存在しないか
• パスワードポリシーが適切に設定されているか
• 90日以上使用されていない認証情報がないか
• IAMポリシーがグループまたはロールにアタッチされているか

まとめ

本記事では、AWS公式が推奨するIAMセキュリティのベストプラクティス15項目を解説しました。これらのベストプラクティスを適切に実装することで、AWSアカウントのセキュリティを大幅に強化できます。

特に重要なポイントを振り返ります。

1. ルートユーザーの保護が最優先事項です。MFAを必ず有効化し、アクセスキーは作成しないでください
2. 最小権限の原則を徹底し、必要な権限のみを付与します
3. 一時的な認証情報を使用し、長期的なアクセスキーの使用を最小限にします
4. 定期的な監査を実施し、未使用の認証情報や過剰な権限を検出・削除します
5. CloudTrailとIAM Access Analyzerを活用して、継続的な監視と分析を行います

これらのベストプラクティスは一度設定して終わりではなく、継続的に見直しと改善を行うことが重要です。組織のセキュリティ要件や業務内容の変化に応じて、適切に調整してください。

参考リンク

• IAM でのセキュリティのベストプラクティス
• AWS アカウントのルートユーザーのベストプラクティス
• IAM Access Analyzer の使用
• AWS CloudTrail ユーザーガイド
• AWS Security Hub ユーザーガイド