はじめに

今回は、ここ数カ月で急激に数が増えてきている組織ポリシーについて説明します。本稿執筆時点で、AWSでは12の組織ポリシーが提供されています。第18回で紹介したリソースコントロールポリシーや宣言型ポリシー、第23回で紹介したSecurity Hub CSPM ポリシーなども組織ポリシーの一種です。ここ数カ月のうちに以下4つの組織ポリシーが新たに提供されました。

  • Amazon Inspectorポリシー
  • Amazon Bedrockポリシー
  • アップグレードロールアウトポリシー
  • S3ポリシー

以下、これらの組織ポリシーの概要とユースケースについて説明します。

Amazon Inspectorポリシー

Amazon Inspectorポリシーは、2025年11月19日に提供された組織ポリシーです。Amazon Inspectorの設定を管理するための組織ポリシーで、組織全体で Amazon Inspectorの設定を一元的に管理できます。Amazon Inspectorポリシーで必要なスキャンタイプとリージョンを指定することで、アタッチされた組織やOUで配下のすべてのAWSアカウントに対して、Inspectorの設定を強制できます。

このポリシーが提供される前は、第8回で紹介したような方法でInspectorの有効化は可能でしたが、InspectorポリシーによってOrganizationsから直接Inspectorの設定を管理できるようになりました。現時点ではOrganizations配下のAWSアカウントに対するInspectorの一括設定ができる方法が2種類あるため、使い分けの判断が難しい機能かもしれません。

これまでのInspector管理アカウントからの操作では、OU単位での一括操作はできなかったため、OU単位でのInspector設定管理を行いたい場合にはInspectorポリシーを利用することになるでしょう。

なお、筆者の環境でInspectorポリシーの例として紹介されているInspectorポリシーの作成を試したところ、以下の画像のように「The provided policy document does not meet the requirements of the specified policy type.」というエラーが表示され、Inspectorポリシーの作成に失敗しました。

公式ドキュメントでは記載を見つけられなかったのですが、disable_in_regionsについても指定が必須のようです。特定のリージョンのみ有効化する場合でも、無効化リストの明示的な空指定が必要な仕様と推測されます。例えば、下記のような記載とすればInspectorポリシーの作成に成功しました。本稿執筆時点の不具合かもしれませんが、同仕様については注意いただければと思います。


{
  "inspector": {
    "enablement": {
      "ec2_scanning": {
        "enable_in_regions": {
          "@@assign": [
            "ap-northeast-1",
            "ap-northeast-3"
          ]
        },
        "disable_in_regions": {
          "@@assign": []
        }
      }
    }
  }
}

Amazon Bedrockポリシー

Amazon Bedrockポリシーは、管理アカウントに作成したBedrockのガードレール設定をOrganizations配下のAWSアカウントに適用するための組織ポリシーです。下記のように、事前に管理アカウントに作成したBedrockガードレールをポリシー内で指定します。


{
  "bedrock": {
    "guardrail_inference": {
      "ap-northeast-1": {
        "config_1": {
          "identifier": {
            "@@assign": "arn:aws:bedrock:ap-northeast-1::guardrail/:"
          },
          "input_tags": {
            "@@assign": "ignore"
          }
        }
      }
    }
  }
}

なお、筆者の環境ではポリシーを適用されるリージョンとガードレールが存在するリージョンが異なっている場合は、「The provided policy document does not meet the requirements of the specified policy type.」というエラーが表示され、Bedrockポリシーの作成に失敗しました。本稿執筆時点では公式ドキュメントに明確な記載はありませんが、Bedrockポリシーが適用されるリージョンとガードレールが存在するリージョンを一致させる必要があるようです。

作成したBedrockポリシーをOUにアタッチすることで、複数のAWSアカウントに対してBedrockガードレールの設定を強制させることができます。Bedrockポリシーを設定すると、以下の画像の通り、「Organization-level enforced guardrails」として設定がされます。

なお、Bedrockポリシーを利用する際には、Bedrockガードレールのリソースベースポリシーにて、Organizationsの全AWSアカウントからのアクセスを許可する必要があります。詳細は公式ドキュメントを参照ください。

Bedrockポリシーは、ベストプラクティスとして通常はリソース配置が推奨されない管理アカウント上でBedrockガードレールを作成する必要がある点や、本稿執筆時点ではプレビュー機能であるリソースベースポリシーの利用が必須である点など、機能としてまだ発展途上の印象があります。今後のアップデートで、委任管理者アカウントへの対応など、より使いやすい形でリリースされてくることを期待したいところです。

アップグレードロールアウトポリシー

アップグレードロールアウトポリシーは、2025年11月21日に提供された組織ポリシーです。RDSやAuroraのマイナーバージョンの自動アップグレードを段階的に適用するための組織ポリシーです。これまで紹介してきた組織ポリシーと異なり、マネジメントコンソール上でビジュアルエディタが提供されており、以下の画像のように比較的容易に設定が可能です。

First、Second、Lastの3つのアップグレード順序を指定でき、設定されたメンテナンスウィンドウ中に「First」とマークされたリソースにアップグレードを行います。その後、通常1週間後に「Second」とマークされたリソースがアップグレードされます。公式ドキュメントには待機期間についての明確な記載はありませんが、順序として最後に「Last」とマークされたリソースがアップグレードされる仕様となっています。

これまでこうした段階的なデータベースのアップグレードは、手動で同様の仕組みを実現して対応していたケースが多いでしょう。 アップグレードロールアウトポリシーを利用することで、段階的なアップグレードをより容易に実現できるようになります。

なお、アップグレードロールアウトポリシーは、データベースエンジンのマイナーバージョンの自動アップグレードが有効になっているインスタンスのみが対象となります。

S3ポリシー

S3ポリシーは、2025年11月26日に提供された組織ポリシーです。S3パブリックアクセスブロック設定をOrganizations配下のAWSアカウントに一元的に適用するための組織ポリシーです。

少々わかりにくいのですが、S3のパブリックアクセスブロック設定の対象はAWSアカウントレベルS3バケットレベルの2種類があります。S3ポリシーで制御できるのはAWSアカウントレベルのパブリックアクセスブロック設定です。

S3ポリシーでAWSアカウントレベルのパブリックアクセスブロック設定を指定することで、アタッチされた組織やOUで配下のすべてのAWSアカウントに対して、S3のパブリックアクセスブロック設定を強制できます。

S3ポリシーもビジュアルエディタが提供されており、以下の画像のように比較的容易に設定が可能です。ただし、現時点で対応しているのはすべてのパブリックアクセスをブロックする設定のみとなっています。

公式ドキュメントに記載の通り、S3ポリシーでは下記4つのパブリックアクセスブロック設定が可能ですが、個別に制御することは少なく、基本的に全機能を有効化することが多いと思います。

# 設定項目 内容
1 BlockPublicAcls 新しく追加されたバケットまたはオブジェクトに適用されるパブリックアクセス許可をブロックし、既存のバケットおよびオブジェクトの新しいパブリックアクセスコントロールリスト(以下、ACL)の作成を防ぐ
2 BlockPublicPolicy バケットとオブジェクトへのパブリックアクセスを許可する新しいバケットポリシーとアクセスポイントポリシーをブロックする
3 IgnorePublicAcls バケットとオブジェクトへのパブリックアクセスを許可するすべてのACLを無視する
4 RestrictPublicBuckets バケットとオブジェクトへのパブリックアクセスを許可するポリシーを持つバケットまたはアクセスポイントのパブリックアクセスとクロスアカウントアクセスを無視する

AWSアカウントレベルのパブリックアクセスブロック設定は、Security Hub CSPMのコントロールの一つであるS3.1でチェックされることもあり、可能であれば有効化しておきたい設定です。S3ポリシーを利用することで、Organizations配下のAWSアカウントに対して一元的にS3のパブリックアクセスブロック設定を強制できるようになります。

まとめ

今回は、ここ数カ月で新たに提供された4つの組織ポリシーについて説明しました。組織ポリシーはOrganizations配下のAWSアカウントに対して一元的に設定を強制できるため、ガバナンス向上に役立ちます。今回紹介した組織ポリシーも、いずれも特定のユースケースにおいて有用なものです。各組織ポリシーの特徴とユースケースを理解した上で、適切に活用していきましょう。