2025.03.21

宣言ポリシーの活用法

akira

こんにちは akiraです。先日、JAWS DAYS 2025に参加しAWSエンジニアたちの熱量を全身で感じてきました！コミュニティを通じて新たなつながりを得られるのもAWSの大きな特徴だと思います。

今回は前回のブログで紹介しきれなかった宣言ポリシーの活用方法についてできるだけ具体的にご紹介したいと思います。

サービスコントロールポリシー/リソースコントロールポリシーとの比較などについては前回のブログをご参照ください。

宣言ポリシーは何が違うのか？

Contents

宣言ポリシーに関するおさらい
適用方法と特徴的な機能の紹介
まとめ

宣言ポリシーに関するおさらい

本ブログのみを読んでも理解できるように簡単に宣言ポリシーに関して整理したいと思います。
※一部前回のブログと内容が重複いたしますがご了承ください

ポリシーの分類

宣言ポリシーはAWS Organizations のポリシータイプの一つで、Management Policies（以降は管理ポリシーと記載）に分類されます。（表ポリシーの比較を参照）。

項目	認証ポリシー	管理ポリシー
項目	組織全体の AWS アカウントのセキュリティを一元管理するのに役立つ	組織全体で AWS サービスとその機能を一元的に設定および管理するのに役立つ
サービス	・サービスコントロールポリシー (SCP) ・リソースコントロールポリシー(RCP)	・宣言ポリシー・バックアップポリシー・タグポリシー・チャットボットポリシー・AI サービスのオプトアウトポリシー
管理アカウントへの適用	適用されない	適用される
適用ポリシー表示可否	表示できない	表示できる

ポリシーの比較

特徴と現時点の機能

宣言ポリシーのポイントは、容易にOrganizations全体へAWSサービスのベースライン設定適用を宣言的に実施できることです。特徴的な機能をまとめると以下があげられます。

APIを意識した設定が不要で、APIの変更時に更新作業が発生しない
アカウントステータスレポートによる適応状況確認
ポリシーによるエラーメッセージのカスタマイズ

上記の各機能については後節でご紹介します。

提供されているポリシー

ブログを執筆している2025年3月15日時点でEC2に関連する6項目に対するポリシーが提供されています。
公式ドキュメントを参照すると、"Supported attributes for declarative policies for EC2" とサービス名を含めて記載されていることから、今後もサービス単位での拡張が行われていくのではないかと個人的には想像しています。（参考：Supported AWS services and attributes）

AWSサービス	サービス属性	ポリシーの効果
Amazon VPC	VPC ブロックパブリックアクセス	VPC内のリソースがインターネットゲートウェイを介してインターネットにアクセスできるかを制御
Amazon EC2	シリアルコンソールアクセス	EC2シリアルコンソールにアクセスできるかを制御
	Image Block パブリックアクセス	AMIのパブリック公開可否設定を制御
	許可されたイメージの設定	利用可能なAMIの制御
	インスタンスメタデータのデフォルト	EC2 インスタンスの起動に対するメタデータ設定値の制御
Amazon EBS	スナップショットブロックパブリックアクセス	EBSスナップショットのパブリック公開の可否設定を制御

EC2に対する宣言ポリシー

適用方法と特徴的な機能の紹介

ここからは宣言ポリシーの実際の適用方法や前節で紹介した特徴的な機能について深堀りしていきたいと思います。

適用方法

設定はAWS Organization（以下組織と記載）の管理画面にて適用することができます。

AWSマネジメントコンソールより、AWS Organizations > ポリシーと進むと以下のように設定画面が表示されます。（初回のアクセス時は”無効”と表示されるはずです）

無効と表示されている場合、EC2 の宣言型ポリシーを押下することで以下の画面へと遷移し、EC2 の宣言型ポリシーを有効にするを押下することで有効化できます。

有効化するとポリシーを作成することができ、以下のようなビジュアルエディタからのポリシー作成が可能です。

JSON形式でポリシーを管理することも可能で、以下のような形式になります。
（この例ではAMIのパブリック共有を禁止しています）

{
	"ec2_attributes": {
		"image_block_public_access": {
			"state": {
				"@@assign": "block_new_sharing"
			}
		}
	}
}

作成したポリシーはSCP等と同様に組織単位に対して適用が可能です。組織単位に適用することで、組織ごとの要件に応じた制限を適用することができます。

APIを意識しないポリシーの設定

前項の宣言ポリシーのJSONサンプルを見てもわかるように宣言ポリシーでは実行されているAPIを意識せずにポリシーの設定が可能となっています。

例えば、サービスコントロールポリシー（SCP）を用いてAMIのパブリック共有を防ぎたい場合、各アカウントの各リージョンでAMI のパブリックアクセスブロックを有効化したうえで次のポリシーを適用する必要があります。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "SamplePolicy",
      "Effect": "Deny",
      "Action": [
        "ec2:DisableImageBlockPublicAccess"
      ],
      "Resource": "*"
    }
  ]
}

APIレベルで意識して制御できるメリットがある一方で、見方を変えると、AWS側の変更によってAPIの内容が変更になった場合にSCPが想定した挙動をしなくなってしまうというデメリットもあると言えます。

また、今回の例だとすでにパブリックアクセスブロックが無効化されていた場合、すべてのリージョンに対して有効化をして上げる必要があります。組織を活用してポリシーを適用することでその手間は大きく省けると言えます。

加えて、宣言ポリシーの場合はAPIを意識する必要がないため、APIに変更に伴う管理コストが発生しない点も大きな特徴と言えます。

Declarative policies

アカウントステータスレポートの活用

SCPの例でも少し触れたように、ポリシー適用前にどの程度の違反が生じているかを管理するのはとても大変です。
宣言ポリシーではアカウントステータスレポートを用いることで、レポート作成時点でどのポリシーをどのアカウントで違反しているかを可視化することができます。

アカウントステータスレポートを活用することで新たなポリシー適用前の影響調査や、適用後のポリシー運用に活用することができます。

エラーメッセージのカスタマイズ

最後にエラーメッセージのカスタマイズについてもご紹介します。

カスタムメッセージはポリシー作成時に設定することが可能で、以下のようにポリシードキュメントへの誘導も可能です。

SCPではこの機能は存在せず、アカウント利用者は一方的にAccess Denyされてしまうので自身の権限が不足しているのか、SCPによって機能が制限されているのかの判断がつきませんでした。

カスタムエラーメッセージを活用することで以下のように拒否理由（This action is restricted by our security rule TEST-001.\nFor more information: https://hogehoge.com）を表示することでアカウント利用者にもわかりやすく権限を制御することができます。

まとめ

宣言ポリシーを活用することで容易にセキュアなAWS管理を実現することが出来そうです。まだまだ、ポリシー数は少ないので今後の追加にも期待していきたいですね。ご紹介した特徴的な機能を活かして既存のAWS Organizationにも適用いただければと思います。また、このブログがその一助になれば幸いです。

#AWS #AWS Organizations #Declarative policies

AUTHOR