概要

AWS OrganizationsのSCPを使ってIAMユーザーの新規作成を制限し、特定の主体のみを例外として許可する方法を解説します。許可リスト方式による統制強化で、IAMユーザー乱立を防ぎ、セキュリティガバナンスを向上させます。

目次

はじめに
SCPによるIAMユーザー作成制限の基本
最小構成のSCPポリシー
実践的な拡張版SCP
許可リスト（例外設定）の実装
実装時の注意点とベストプラクティス
AWS CLIによる実装手順
既存のIAMユーザーへの影響
終わりに
参考文献・参考サイト

1. はじめに

AWS環境が拡大するにつれ、IAMユーザーが各部門や担当者によって無秩序に作成され、管理が困難になるケースが増えています。IAMユーザーの乱立は、以下のようなセキュリティリスクを招きます。

アクセスキーの流出リスク増加
退職者アカウントの削除漏れ
権限の過剰付与や棚卸しの困難化
コンプライアンス要件への抵触

AWS Organizationsのサービスコントロールポリシー（SCP）を活用することで、組織全体でIAMユーザー作成を統制し、特定の管理者ロールやユーザーのみに作成権限を集約できます。本記事では、許可リスト方式によるSCPの実装方法を、実践的な視点から解説します。

2. SCPによるIAMユーザー作成制限の基本

SCPの役割と特徴

サービスコントロールポリシー（SCP）は、AWS Organizations配下のアカウントに対して「実行可能な操作の上限」を定義する仕組みです。重要な特徴として以下の点があります。

権限の付与はしない：SCPは制限のみを行い、許可は各アカウントのIAMポリシーで行う必要があります
ルートユーザーにも適用される：通常のIAMポリシーと異なり、ルートユーザーの操作も制限できます
組織単位（OU）での適用が可能：複数アカウントを一括で統制できます

許可リスト方式の考え方

今回実装する許可リスト方式は、「原則禁止、例外のみ許可」というアプローチです。具体的には以下のロジックで動作します。

デフォルトでIAMユーザー作成操作を拒否（Deny）
特定のARN（ロールやユーザー）のみを例外として許可
許可リストに含まれない主体からの操作は恒常的にブロック

この方式により、誰が・どのような権限でIAMユーザーを作成できるかを明確に管理できます。

3. 最小構成のSCPポリシー

まずは、iam:CreateUserのみをブロックする最小構成を見ていきます。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyCreateUserExceptAllowlist",
      "Effect": "Deny",
      "Action": "iam:CreateUser",
      "Resource": "*",
      "Condition": {
        "StringNotLike": {
          "aws:PrincipalArn": [
            "arn:aws:iam::*:role/IAMUserCreator",
            "arn:aws:sts::*:assumed-role/IAMUserCreator/*",
            "arn:aws:iam::*:user/BreakGlass-IAMAdmin"
          ]
        }
      }
    }
  ]
}

ポリシーの構成要素

Effect: Deny：明示的な拒否を設定
Action: iam:CreateUser：IAMユーザー作成操作を対象
Resource: "*"：すべてのIAMリソースに適用
Condition：aws:PrincipalArnが許可リストに一致しない場合に拒否

このポリシーでは、IAMUserCreatorロールとBreakGlass-IAMAdminユーザーのみがIAMユーザーを作成できます。

4. 実践的な拡張版SCP

最小構成ではiam:CreateUserのみを制限しましたが、実際の運用では関連する操作も併せて制限すべきです。以下の拡張版では、IAMユーザー作成後の有効化や権限付与に関わる操作も包括的にブロックします。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyIamUserProvisioningExceptAllowlist",
      "Effect": "Deny",
      "Action": [
        "iam:CreateUser",
        "iam:CreateLoginProfile",
        "iam:CreateAccessKey",
        "iam:AddUserToGroup",
        "iam:AttachUserPolicy",
        "iam:PutUserPolicy",
        "iam:TagUser"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotLike": {
          "aws:PrincipalArn": [
            "arn:aws:iam::*:role/IAMUserCreator",
            "arn:aws:sts::*:assumed-role/IAMUserCreator/*",
            "arn:aws:iam::*:user/BreakGlass-IAMAdmin"
          ]
        }
      }
    }
  ]
}

制限対象のActionとその役割

Action	役割	制限する理由
`iam:CreateUser`	IAMユーザーの作成	新規ユーザー作成の起点となる操作
`iam:CreateLoginProfile`	コンソールログインパスワードの設定	ユーザーをコンソール経由で有効化
`iam:CreateAccessKey`	アクセスキーの発行	プログラマティックアクセスを有効化
`iam:AddUserToGroup`	IAMグループへの追加	グループ経由での権限付与を防止
`iam:AttachUserPolicy`	マネージドポリシーのアタッチ	直接的な権限付与を防止
`iam:PutUserPolicy`	インラインポリシーの埋め込み	直接的な権限付与を防止
`iam:TagUser`	ユーザーへのタグ付け	タグベースの権限制御の悪用を防止

これらの操作を統制することで、IAMユーザー作成だけでなく、作成後の権限エスカレーションも防ぐことができます。

5. 許可リスト（例外設定）の実装

aws:PrincipalArnの使い方

許可リストの実装には、aws:PrincipalArn条件キーを使用します。このキーは、API呼び出しを行った主体（Principal）のARNと照合します。

重要なポイントは、IAMロールを使用する場合、2つのARN形式を指定する必要があることです。

"aws:PrincipalArn": [
  "arn:aws:iam::*:role/IAMUserCreator",              // ロール自体
  "arn:aws:sts::*:assumed-role/IAMUserCreator/*"    // AssumeRoleセッション
]

ロールとAssumeRoleセッションの違い

IAMロールは、実際に使用される際に「AssumeRole」によって一時的な認証情報が発行されます。このとき、Principal ARNは以下のように変化します。

ロール定義時：arn:aws:iam::123456789012:role/IAMUserCreator
AssumeRole後：arn:aws:sts::123456789012:assumed-role/IAMUserCreator/session-name

したがって、両方のパターンを許可リストに含めないと、実際の操作時にブロックされてしまいます。

アカウント横断での設定方法

複数のAWSアカウントで同名のロールを許可する場合、アカウントIDにワイルドカード（*）を使用できます。

"arn:aws:iam::*:role/IAMUserCreator"

特定のアカウントのみ許可する場合は、アカウントIDを明示します。

"arn:aws:iam::123456789012:role/IAMUserCreator",
"arn:aws:iam::987654321098:role/IAMUserCreator"

6. 実装時の注意点とベストプラクティス

ルートユーザーの扱い

このSCPポリシーは、ルートユーザーにも適用されます。ルートユーザーによるIAMユーザー作成を許可する場合は、以下のARNを追加してください。

"arn:aws:iam::*:root"

ただし、セキュリティベストプラクティスとしては、ルートユーザーの使用を最小限に抑えるべきです。緊急時のアクセス用にBreakGlass-IAMAdminのような専用IAMユーザーを用意し、通常はロールベースの運用を推奨します。

IAMポリシーとの組み合わせ

重要：SCPは権限を付与しません。許可リストに含めた主体には、別途IAMポリシーで必要な権限を付与する必要があります。

例えば、IAMUserCreatorロールには以下のようなIAMポリシーをアタッチします。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "iam:CreateUser",
        "iam:CreateLoginProfile",
        "iam:CreateAccessKey",
        "iam:AddUserToGroup",
        "iam:AttachUserPolicy",
        "iam:PutUserPolicy",
        "iam:TagUser"
      ],
      "Resource": "*"
    }
  ]
}

伝播時間と動作確認

SCPの適用や変更は、数分から最大15分程度かかる場合があります。以下の手順で動作を確認してください。

テスト用のOU配下アカウントで実施
許可リストに含まれない主体でIAMユーザー作成を試行し、拒否されることを確認
許可リストに含まれる主体で作成を試行し、成功することを確認

トラブルシューティング

問題	原因	解決策
許可リストの主体でも拒否される	AssumeRoleセッションのARN未指定	`assumed-role`パターンを追加
ルートユーザーでも拒否される	ルートユーザーが許可リストに含まれていない	`arn:aws:iam::*:root`を追加
変更が反映されない	SCP伝播の遅延	5〜15分待機後に再試行
権限エラーが発生	IAMポリシーで権限未付与	対象主体にIAMポリシーをアタッチ

7. AWS CLIによる実装手順

前提条件

AWS CLI v2がインストール済み
Organizations管理アカウントでの実行権限
適用対象のOU IDを確認済み

手順1：SCPポリシーの作成

まず、ポリシーをJSON形式でローカルファイルに保存します。

# ポリシーファイルの作成
cat > restrict-iam-user-creation.json << 'EOF'
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyIamUserProvisioningExceptAllowlist",
      "Effect": "Deny",
      "Action": [
        "iam:CreateUser",
        "iam:CreateLoginProfile",
        "iam:CreateAccessKey",
        "iam:AddUserToGroup",
        "iam:AttachUserPolicy",
        "iam:PutUserPolicy",
        "iam:TagUser"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotLike": {
          "aws:PrincipalArn": [
            "arn:aws:iam::*:role/IAMUserCreator",
            "arn:aws:sts::*:assumed-role/IAMUserCreator/*",
            "arn:aws:iam::*:user/BreakGlass-IAMAdmin"
          ]
        }
      }
    }
  ]
}
EOF

次に、Organizations APIを使ってSCPを作成します。

# SCPポリシーの作成
aws organizations create-policy \
  --content file://restrict-iam-user-creation.json \
  --description "Restrict IAM user creation to allowlisted principals" \
  --name "RestrictIAMUserCreation" \
  --type SERVICE_CONTROL_POLICY \
  --region us-east-1

注意：Organizations APIはus-east-1リージョンでのみ実行可能です。--region us-east-1を明示的に指定してください。

実行結果からポリシーIDを確認します。

{
  "Policy": {
    "PolicySummary": {
      "Id": "p-xxxxxxxxxx",
      "Arn": "arn:aws:organizations::123456789012:policy/o-xxxxxxxxxx/service_control_policy/p-xxxxxxxxxx",
      "Name": "RestrictIAMUserCreation",
      "Type": "SERVICE_CONTROL_POLICY"
    }
  }
}

手順2：OUへのアタッチ

作成したSCPを対象のOUにアタッチします。

# OUのIDを確認（事前に取得しておく）
aws organizations list-organizational-units-for-parent \
  --parent-id r-xxxx \
  --region us-east-1

# SCPをOUにアタッチ
aws organizations attach-policy \
  --policy-id p-xxxxxxxxxx \
  --target-id ou-xxxx-xxxxxxxx \
  --region us-east-1

手順3：動作確認

許可リストに含まれない主体でIAMユーザー作成を試行します。

# テスト用のプロファイルでIAMユーザー作成を試行（拒否されることを確認）
aws iam create-user \
  --user-name test-user \
  --profile test-account

# エラーメッセージ例
# An error occurred (AccessDenied) when calling the CreateUser operation: 
# User: arn:aws:iam::123456789012:user/normal-user is not authorized 
# to perform: iam:CreateUser with an explicit deny in a service control policy

次に、許可リストの主体（例：IAMUserCreatorロール）をAssumeして作成を試行します。

# IAMUserCreatorロールをAssume
aws sts assume-role \
  --role-arn arn:aws:iam::123456789012:role/IAMUserCreator \
  --role-session-name test-session \
  --profile management-account

# 返された一時認証情報を使ってIAMユーザー作成（成功することを確認）
export AWS_ACCESS_KEY_ID="取得したAccessKeyId"
export AWS_SECRET_ACCESS_KEY="取得したSecretAccessKey"
export AWS_SESSION_TOKEN="取得したSessionToken"

aws iam create-user --user-name test-user-allowed

成功すれば、SCPが正しく動作しています。

手順4：ポリシーの更新（必要に応じて）

許可リストに主体を追加する場合は、ポリシーを更新します。

# 修正したポリシーファイルで更新
aws organizations update-policy \
  --policy-id p-xxxxxxxxxx \
  --content file://restrict-iam-user-creation-v2.json \
  --region us-east-1

8. 既存のIAMユーザーへの影響

このSCPポリシーを適用しても、既存のIAMユーザーには直接的な影響はありません。以下の点を理解しておきましょう。

影響がないもの

既存IAMユーザーのコンソールログイン
既存IAMユーザーのアクセスキー使用
既存IAMユーザーへの権限変更（許可リストの主体が実施する場合）
既存IAMユーザーの削除

影響があるもの

既存のIAMユーザーが許可リストに含まれていない場合、以下の操作が制限されます。

操作	制限内容
新規IAMユーザー作成	自分自身や他のユーザーを作成できない
アクセスキー追加発行	既存ユーザーに新しいアクセスキーを追加できない
ログインプロファイル作成	既存ユーザーにコンソールパスワードを設定できない
グループへの追加	ユーザーをIAMグループに追加できない
ポリシーのアタッチ	ユーザーに直接ポリシーをアタッチできない

移行期の運用ベストプラクティス

SCPを新規適用する場合、以下の段階的なアプローチを推奨します。

テスト環境での検証：開発用OUで先行適用し、業務影響を確認
許可リストの整備：必要な管理者ロール・ユーザーを事前に定義
段階的な展開：まず非本番環境のOUに適用し、問題がなければ本番環境へ
モニタリング：CloudTrailでAccessDeniedイベントを監視し、想定外の拒否がないか確認

# CloudTrailでSCPによる拒否を確認するクエリ例
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=CreateUser \
  --max-results 50 \
  --region ap-northeast-1 \
  | jq '.Events[] | select(.CloudTrailEvent | contains("service control policy"))'

9. 終わりに

本記事では、AWS OrganizationsのSCPを使ってIAMユーザーの新規作成を制限し、許可リスト方式で特定の主体のみに権限を集約する方法を解説しました。

重要ポイントの振り返り

SCPは「許可の上限」を定義し、実際の権限付与はIAMポリシーで行う
AssumeRoleセッションのARNパターンも許可リストに含める必要がある
既存IAMユーザーへの直接的影響はないが、新規作成や権限変更が制限される
段階的な展開とモニタリングで安全に運用開始できる

次のステップ

IAMユーザー作成の統制に加えて、以下の施策も検討することで、より強固なセキュリティガバナンスを実現できます。

IAMロールベースのアクセス管理：IAMユーザーから一時的な認証情報への移行
AWS IAM Identity Centerの導入：シングルサインオンによる集中管理
SCPによる他の重要操作の制限：S3バケットの公開設定、VPC削除など
AWS Configによるコンプライアンス監視：IAMユーザー数の継続的な監視

組織のセキュリティ要件に応じて、これらの施策を組み合わせることで、AWSアカウント全体のガバナンスを強化していきましょう。

10. 参考文献・参考サイト

「Service control policies (SCPs)」AWS Organizations User Guide, https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html
「IAM JSON policy elements: Condition」AWS Identity and Access Management User Guide, https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html
「AWS global condition context keys」AWS Identity and Access Management User Guide, https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html
「AWS CLI Command Reference - Organizations」AWS CLI Documentation, https://docs.aws.amazon.com/cli/latest/reference/organizations/index.html
「Using CloudTrail Event History」AWS CloudTrail User Guide, https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events.html