developersIO
[アップデート]AWS OrganizationsにAmazon Inspectorのスキャン設定が柔軟に管理できる「Inspectorポリシー」が登場しました

[アップデート]AWS OrganizationsにAmazon Inspectorのスキャン設定が柔軟に管理できる「Inspectorポリシー」が登場しました

AWS re:Invent 2025
AWSAWS OrganizationsAmazon Inspector v2
FacebookHatena blogX
2025.11.24

あしざわです。

AWS OrganizationsでInspectorポリシーが利用可能になり、組織全体でAmazon Inspectorの設定をより柔軟に管理できるようになりました。

https://aws.amazon.com/jp/about-aws/whats-new/2025/11/amazon-inspector-organization-wide-management-aws-organizations-policies/

それでは詳しく見ていきましょう。

概要

Amazon InspectorはEC2、ECR、Lambdaをスキャンし、ソフトウェアの脆弱性やネットワーク露出がないかチェックするサービスです。

https://dev.classmethod.jp/articles/introduction-2024-amazon-inspector/

これまでのInspectorでは、AWS Organizationsと連携して以下の機能が利用できました。

  • 委任管理者の指定
  • メンバーアカウントのサービスの有効化
  • メンバーアカウントのスキャン設定の管理
  • 検出結果の統合

old_inspector
従来：InspectorのOrganizations連携の概要図

従来の方式でもマルチアカウント環境でInspectorスキャンを統合管理できていましたが、以下の課題がありました。

  • アカウント単位で設定するため、スキャン設定自体の管理が煩雑になる
  • リージョン単位で設定が必要

Inspectorポリシーの登場により、以下の機能が新しく利用可能になりました。

  • OU単位でのスキャン設定の適用
  • リージョンを跨いだ設定の一元管理

new_inspector_2
新機能：Inspectorポリシーの概要図

Inspectorポリシーを利用することで、これまでAWSアカウント単位で対応していたスキャン設定を、OUというグループ単位で割り当てられるようになります。

つまり、組織に新規アカウントが追加されたり規模が拡大しても運用のオーバーヘッドを抑えた状態でInspectorスキャンのベースラインを確保できるようになります。

ポリシーの構造

Inspectorポリシーの基本構造はこちら

{
    "inspector": {
        "enablement": {
            "[scan_type]": {
                "[regions]": {
                    "[Inheritance operators]": ["RegionName1", "RegionName2"..., "RegionNameN"]
            }
        }
    }
}

ポリシーには以下のコンポーネントが含まれます。

  • inspector (必須)
    • ポリシードキュメントの最上位キー
  • enablement (必須)
    • Inspectorを有効化する方法を定義
  • [scan_type] (任意)
    • Inspectorのスキャンタイプ、現状は5種類ある
      • ec2_scanning：EC2スキャン
      • ecr_scanning：ECRスキャン
      • lambda_standard_scanning：Lambda標準スキャン
      • lambda_code_scanning：Lambdaコードスキャン
        • (このスキャンタイプだけ、lambda_standard_scanningの子要素として追加する必要あり)
      • code_repository_scanning：コードリポジトリスキャン
  • enable_in_regions (scan_typeごとに必須)
    • 有効化するリージョンを設定します
  • disable_in_regions (scan_typeごとに必須)
    • 無効化するリージョンを設定します
  • [Inheritance operators(継承演算子)] (必須)
    • Key：基本的には以下のいずれかを使用
      • @@assign：上書き
      • @@append：追加
      • @@remove：削除
    • Value：有効化するリージョンを指定(例: "us-east-1", "ap-northeast-1")
      • ALL_SUPPORTEDを指定すると全リージョン指定 + 今後追加される新しいリージョンが自動追加されます
    • 詳細は公式ドキュメント 継承演算子 へ

参考までに、ポリシーの例は以下のとおりです。

{
    "inspector": {
        "enablement": {
            "ec2_scanning": {
                "enable_in_regions": {
                    "@@assign": ["us-east-1", "us-west-2"]
                },
                "disable_in_regions": {
                    "@@assign": ["eu-west-1"]
                }
            }
        }
    }
}

やってみた

Inspectorポリシーの利用方法はこちらのドキュメントに記載されています。

https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_inspector_getting_started.html

この方法を参考に作成した、検証のシナリオがこちらです

  1. Inspector委任管理者の設定
  2. Inspectorポリシーの設定
  3. OUへポリシーアタッチ
  4. 新規AWSアカウント追加

はじめにInspectorの委任管理者アカウントの設定を行います。検証環境では委任管理者設定ができていなかったのでやってますが、実施済みの場合は飛ばしてください。

続いて、委任管理者アカウントからInspectorポリシーを作成します。そして、指定のOUへ作成したポリシーをアタッチします。

最後に、ポリシーがアタッチされているOU配下で新しいAWSアカウントを発行し、自動的にInspectorポリシーが適用されることを確認します。

こちらが検証の最終形を図解したものが以下です。

ou-configure2

それでは検証を進めていきます。

なお、検証環境にはControl Towerが有効化されたOrganizations組織を利用します。マネジメントコンソールの操作はすべてAdministrator権限が付与されたIAMで実施します。

Inspector管理者権限の委任

まずはここの部分から進めていきます。

ou-configure-0

マネジメントコンソールからOrganizations 管理アカウントにサインインします。

Inspectorのサービス画面で設定を進めます。

CleanShot 2025-11-20 at 19.20.06@2x

管理者の設定画面に遷移しました。

以下を入力して設定します。

  • 委任された管理者アカウント ID：AuditアカウントのAWSアカウントID
  • Delegation policy（委任ポリシー）：Update delegation policy for me
  • チェックボックス：チェックする

CleanShot 2025-11-20 at 19.27.47@2x

この設定による委任ポリシーの差分は以下のようです

  • 既存のポリシードキュメントへのarn:aws:organizations::222222222222:policy/o-abcdefghij/inspector_policy/*の追記
  • SecurityServicesDelegatingPolicyTagActions ステートメントの追加

自動作成された委任ポリシーのサンプル：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "SecurityServicesDelegatingOrgReadActions",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111111111111:root"
      },
      "Action": "organizations:ListRoots",
      "Resource": "*"
    },
    {
      "Sid": "SecurityServicesDelegatingNecessaryOrgManagementActions",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111111111111:root"
      },
      "Action": [
        "organizations:DescribeOrganization",
        "organizations:DescribeOrganizationalUnit",
        "organizations:DescribeAccount",
        "organizations:ListRoots",
        "organizations:ListOrganizationalUnitsForParent",
        "organizations:ListParents",
        "organizations:ListChildren",
        "organizations:ListAccounts",
        "organizations:ListAccountsForParent",
        "organizations:ListTagsForResource",
        "organizations:ListDelegatedAdministrators",
        "organizations:ListHandshakesForAccount"
      ],
      "Resource": [
        "arn:aws:organizations::222222222222:root/o-abcdefghij/*",
        "arn:aws:organizations::222222222222:organization/o-abcdefghij",
        "arn:aws:organizations::222222222222:ou/o-abcdefghij/*",
        "arn:aws:organizations::222222222222:account/o-abcdefghij/*",
        "arn:aws:organizations::222222222222:policy/o-abcdefghij/inspector_policy/*"
      ]
    },
    {
      "Sid": "SecurityServicesDelegatingPolicyDescribeActions",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111111111111:root"
      },
      "Action": [
        "organizations:DescribePolicy",
        "organizations:DescribeEffectivePolicy",
        "organizations:ListPolicies",
        "organizations:ListPoliciesForTarget",
        "organizations:ListTargetsForPolicy"
      ],
      "Resource": [
        "arn:aws:organizations::222222222222:root/o-abcdefghij/*",
        "arn:aws:organizations::222222222222:ou/o-abcdefghij/*",
        "arn:aws:organizations::222222222222:account/o-abcdefghij/*",
        "arn:aws:organizations::222222222222:policy/o-abcdefghij/inspector_policy/*"
      ]
    },
    {
      "Sid": "SecurityServicesDelegatingPolicyMutationActions",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111111111111:root"
      },
      "Action": [
        "organizations:CreatePolicy",
        "organizations:UpdatePolicy",
        "organizations:DeletePolicy",
        "organizations:AttachPolicy",
        "organizations:DetachPolicy",
        "organizations:EnablePolicyType",
        "organizations:DisablePolicyType"
      ],
      "Resource": [
        "arn:aws:organizations::222222222222:root/o-abcdefghij/*",
        "arn:aws:organizations::222222222222:ou/o-abcdefghij/*",
        "arn:aws:organizations::222222222222:account/o-abcdefghij/*",
        "arn:aws:organizations::222222222222:policy/o-abcdefghij/inspector_policy/*"
      ]
    },
    {
      "Sid": "SecurityServicesDelegatingPolicyTagActions",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111111111111:root"
      },
      "Action": [
        "organizations:TagResource",
        "organizations:UntagResource"
      ],
      "Resource": [
        "arn:aws:organizations::222222222222:policy/o-abcdefghij/inspector_policy/*"
      ]
    }
  ]
}

委任管理者の設定が完了しました。

（その後、右下のActivate this accountから管理アカウントのInspectorを有効化しておきました）

CleanShot 2025-11-20 at 19.40.58@2x

Inspectorポリシーの設定

続いて、こちらを進めます。

ou-configure-1

操作するアカウントを委任管理者に設定したAuditアカウントに切り替えます。

Organizationsのサービス画面に移動します。

ポリシータブにInspectorポリシーという項目が追加されています。

CleanShot 2025-11-20 at 19.50.27@2x 1

Inspectorポリシーを有効化します。

CleanShot 2025-11-20 at 19.51.57@2x 1

設定できました。デフォルトでは何も設定されていません。

CleanShot 2025-11-20 at 20.11.38@2x

ポリシーを作成から、ポリシー名、ポリシードキュメントを入力します。

今回は以下2つのポリシーを作成しました。

  • ポリシー名：inspector-policy-for-workload
  • ポリシードキュメント：
{
    "inspector": {
        "enablement": {
            "ec2_scanning": {
                "enable_in_regions": {
                    "@@assign": ["ap-northeast-1", "ap-northeast-3"]
                },
					"disable_in_regions": {
                    "@@assign": []
                }
            },
            "ecr_scanning": {
                "enable_in_regions": {
                    "@@assign": ["ap-northeast-1", "ap-northeast-3"]
                },
					"disable_in_regions": {
                    "@@assign": []
                }
            },
            "lambda_standard_scanning": {
                "enable_in_regions": {
                    "@@assign": ["ap-northeast-1"]
                },
                "disable_in_regions": {
                    "@@assign": []
                },
                "lambda_code_scanning": {
                    "enable_in_regions": {
						"@@assign": ["ap-northeast-1"]
					},
					"disable_in_regions": {
                        "@@assign": []
                    }
                }
			}
		}
    }
}
  • ポリシー名：inspector-policy-for-sandbox
  • ポリシードキュメント：
{
    "inspector": {
        "enablement": {
            "ec2_scanning": {
                "enable_in_regions": {
                    "@@assign": ["ap-northeast-1"]
                },
            }
        }
    }
}

ポリシーが作成できました。

CleanShot 2025-11-21 at 17.22.57@2x

ポリシーのOUへのアタッチ

そしてこちらです。

ou-configure-2 1

ポリシーで定義したInspectorの設定をAWSアカウントに反映するため、ポリシーをOUにアタッチします。

今回は以下のようにポリシーをアタッチします。

  • inspector-policy-for-sandbox ：Sandbox OUにアタッチ
  • inspector-policy-for-workload：Workload OUにアタッチ

アクション > ポリシーのアタッチから作成したポリシーをOUに関連づけていきます。

CleanShot 2025-11-21 at 17.23.39@2x

Workload OUを選択し、ポリシーをアタッチします。

CleanShot 2025-11-21 at 17.24.46@2x

設定できました。

CleanShot 2025-11-21 at 17.25.58@2x

同様にSandbox OUにもポリシーをアタッチします。

CleanShot 2025-11-21 at 17.30.47@2x

ここで各アカウントのInspector設定状態を確認しましょう。

Inspectorポリシーによる設定状況は、委任管理者アカウントのアカウント管理タブから確認できます。

CleanShot 2025-11-24 at 00.41.37

東京リージョンで確認できた結果はこちら。

  • sample-a(Sandbox OU)：EC2、ECR、Lambdaスキャン(標準+コード)が有効化されている
  • sample-b(Workload OU)：EC2スキャンのみ有効化されている

CleanShot 2025-11-21 at 18.09.11@2x

大阪リージョンでも確認してみようとしたところ、このような画面になりました。Inspectorの状態を閲覧するアカウントでInspectorが有効化されていないと見られないようです。Activate this accountからInspectorを有効化しましょう。

CleanShot 2025-11-21 at 18.02.17@2x

大阪リージョンで確認できた結果はこちら。

  • sample-b(Workload OU)：EC2、ECRスキャンが有効化されている

CleanShot 2025-11-21 at 18.06.42@2x 2

ここまで想定通りです。

新規AWSアカウント追加

最後にAWSアカウント追加するとどうなるのか確かめてみましょう。

構成図は最終形のこちらです。

ou-configure-3

AWSアカウントの作成はOrganizationsで実施しており、Control Towerのアカウントファクトリー機能は使用していません。

チェックはOrganizationsコンソールからAWSアカウントを追加してから10分後を目処に確認しました。AWSアカウント作成直後に確認したところ、まだステータスがDisassociateのままであることが確認できたためです。

東京リージョンで確認できた差分を青枠で示しています。

  • sample-c (Workload OU)：EC2、ECR、Lambdaスキャン(標準+コード)が有効化されている

CleanShot 2025-11-21 at 18.32.54@2x

大阪リージョン確認できた差分を青枠で示しています。

  • sample-c (Workload OU)：EC2、ECRスキャンが有効化されている

CleanShot 2025-11-24 at 01.10.07

想定通りの設定になっていることが確認できました。

最後に

本ブログでは、AWS Organizationsに追加されたInspectorポリシーの解説・検証を行いました。

この度初めてOrganizationsポリシーを触ったのですが、SCPと違って少しクセがあリました。一度触れておくと今後のアップデートに追従しやすくなるのではと思います。

また、他のOrganizationsポリシーである「アップグレードロールアウトポリシー」も直近で追加されています。

https://dev.classmethod.jp/articles/organizations-upgrade-rollout-policy-amazon-aurora-rds/

頻繁に追加されるOrganizationsポリシーは、今後のOrganizationsガバナンス機能の中心として存在感を示していきそうです。

新しいポリシーを検証してどんどん組み込み、組織のガバナンスを強化していきましょう。

以上です。

この記事をシェアする

FacebookHatena blogX

関連記事

第5世代 AMD EPYC (Turin) 搭載「R8a」がリリース、東京リージョンでも「M8a」が利用可能になりました
suzuki.ryo
2025.11.24
[アップデート] AWS CloudTrail のデータイベントで 5 分単位の集約情報を記録できるようになりました
yhana
2025.11.24
Amazon Quick Suite の Quick Research 機能を使ってみた
石川覚
2025.11.24
AWS CLIのaws loginコマンドをリモートマシンで使う
大瀧隆太
2025.11.23