宣言型ポリシー
次に、宣言型ポリシーについて、有効化する方法、具体的な設定を説明します。
宣言型ポリシーの有効化
宣言型ポリシーもリソースコントロールポリシーと同様に、本稿執筆時点で委任管理に対応していないため、以下の操作を管理アカウントで行います。
（1）Organizationsの画面へ遷移します。
（2）サイドメニューの「ポリシー」をクリックします。
（3）「EC2の宣言型ポリシー」をクリックします。
（4）「EC2の宣言型ポリシーを有効にする」ボタンをクリックします。
（5）宣言型ポリシーを有効にすると、現在の準拠状況を確認できるレポートを出力することが可能となりますが、そのためには信頼されたアクセス（ec2.amazonaws.com）の有効化も必要になります。本稿執筆時点では上記の手順でその有効化も同時に実施されるようですが、念のため以下コマンドで有効化されているかを確認ください（管理アカウントのCloudShellでの実行をおすすめします）。
aws organizations list-aws-service-access-for-organization --output text | grep "ec2.amazonaws.com"
ENABLEDSERVICEPRINCIPALS 2025-01-05T15:08:23.800000+00:00 ec2.amazonaws.com ← 表示されればOKです。
宣言型ポリシーの具体的な設定
宣言型ポリシーを実際に適用する前に、現在の準拠状況を確認するためのレポート出力を行うための設定を行います。
（1）管理アカウントでレポート出力用のS3バケットを作成します。S3バケットはus-east-1で作成します。具体的な手順はこちらに記載がありますが、バケットポリシーの部分が少しわかりにくいので、筆者が動作確認できたバケットポリシーの例も共有します。
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "DeclarativePoliciesReportBucket",
"Effect": "Allow",
"Principal": {
"Service": ["report.declarative-policies-ec2.amazonaws.com"]
},
"Action": ["s3:PutObject"],
"Resource": "arn:aws:s3:::S3バケット名/*",
"Condition": {
"StringEquals": {
"aws:SourceArn": "arn:aws:declarative-policies-ec2:us-east-1:アカウントID:*"
}
}
}]
}
（2）アクションから「アカウントステータスレポートを表示」をクリックします。
（3）「ステータスレポートを生成」ボタンをクリックします。
（4）作成したS3バケットを選択し、レポート対象となるOUを指定したうえで、「生成」ボタンをクリックします。
（5）正常に処理が開始されたことを確認します。
（6）少し待つとレポートが確認できるようになります。今回適用しようとしたOUでは、一貫した設定が使われており、宣言型ポリシーの利用には問題なさそうであることが確認できました。
（7）続いて、実際の宣言型ポリシーの設定を行います。再び宣言型ポリシーのページに戻り、「ポリシーを作成」ボタンをクリックします。
（8）ポリシー名と説明を入力し、サービス属性を選択します。今回はインスタンスメタデータをv2のみに強制するポリシーを作成します。
（9）宣言型ポリシーの特徴の一つであるカスタムエラーメッセージの設定も行い、「ポリシーを作成」ボタンをクリックします。
（10）正常に作成完了することを確認します。
（11）先ほどのリソースコントロールポリシーと同じく、SystemsManager OUへの適用を行います。「ポリシー」タブのEC2の宣言型ポリシーの「アタッチ」をクリックします。
（12）作成した宣言型ポリシーを選択し、「ポリシーのアタッチ」ボタンをクリックします。
宣言型ポリシーの動作確認
それでは、宣言型ポリシーの動作確認もしていきましょう。上記の宣言型ポリシーをアタッチしたOU配下のAWSアカウントでEC2のサービスへ移動します。サイドメニューの「設定」をクリックします。
「データ保護とセキュリティ」タブの「IMDS デフォルト」の「管理」ボタンが無効化されていると思います。
EC2の宣言型ポリシーでは、EC2インスタンスレベルでのインスタンスメタデータの設定ではなく、AWSアカウントレベルでのインスタンスメタデータの設定であることに注意してください。インスタンスメタデータの優先順位はこちらに記載の通り、インスタンス起動時に設定したものが最も優先されるため、この宣言型ポリシーを適用するだけでは、完全にv1の利用を禁止することはできません。
インスタンスメタデータv1の利用を完全に禁止するには、サービスコントロールポリシーの利用が必要となります。本稿執筆時点におけるEC2の宣言型ポリシーでは、以下の6つの制御がサポートされています。
- VPCブロックパブリックアクセス
- シリアルコンソールアクセス
- AMIブロックパブリックアクセス
- 許可されたANIの設定
- インスタンスメタデータのデフォルト
- スナップショットブロックパブリックアクセス
VPCブロックアクセス以外を適応すると、下記のようにアカウントレベルでの設定変更ができないように強制されます。
それでは、VPCブロックアクセスの挙動も確認してみましょう。まず下記のようにインターネットゲートウェイが存在するVPCを用意しておきます。
下記のようなインターネットの行きと戻りの両方を禁止する宣言型ポリシーを用意しておき、アタッチします。
少し待つと、「パブリックアクセスをブロック」がオンとなります。
またこの状態で新規にVPCを作成すると、作成後には必ず「パブリックアクセスをブロック」がオンとなり、適切に制御がされていることが確認できます。
筆者の考える各種ポリシーの使い分け
ここまでOrganizationsレベルでのアクセス制御の新機能であるリソースコントロールポリシーと宣言型ポリシーを紹介してきました。ではこれらのポリシーに加えてこれまでのサービスコントロールポリシーはどのように使い分けていくべきでしょうか。
筆者は本稿執筆時点では、急いで今までの制御方法（サービスコントロールポリシーやConfigルールなど）を変える必要はないと考えています。
本記事ではリソースコントロールポリシーの実例としてS3バケットへのアクセスをVPCエンドポイント経由のみとするユースケースを紹介しましたが、実案件で厳密にアクセス制御をする際にはS3バケット毎に個別のバケットポリシーを設定することも多く、今回のように横断的に同一の設定をするケースは少ないかと思います。また現時点では完全に他のサービスとの整合性も取れていないケースも散見されます。例えば筆者の環境では、リソースコントロールポリシーで「”aws:PrincipalIsAWSService”: “false”」を指定していても、リソースコントロールポリシーを適用したとたんにSecurityLakeの機能が動作しなくなるという事象も見られました。
宣言型ポリシーについても、少し片手落ち感はあり、上述したインスタンスメタデータのように、宣言型ポリシーのみで操作を禁止できないケースもあります。
ですので、現時点では積極的にこれらの機能を使うというよりも、使えそうなケースがあれば利用していくというスタンスを取るのが良いのではないかと考えています。
ただし、筆者は同時にこれらの機能に大変期待を感じています。これまではアクセス制御を行う方法として、IAMの負担が多く、様々なプロジェクト要件を満たすために、複雑怪奇なIAMポリシー（やサービスコントロールポリシー）が生み出されていることも多かったと感じています。その一部負担をリソースコントロールポリシーや宣言型ポリシーが担ってくれることに大きな期待も感じています。今後に機能追加や修正がされ、本番プロジェクトでも利用できるレベルとなれば、まずは宣言型ポリシーで制御を行い、その後はサービスコントロールポリシーやリソースコントロールポリシーで制御を行うという形がベストになるのではと感じています。
まとめ
今回は、Organizationsの新たな機能であるリソースコントロールポリシーと宣言型ポリシーの具体的な利用方法を詳しく紹介しました。本稿がOrganizations配下のAWSアカウントの運用管理のお役に立てば幸いです。
ホンダが間接材の購買にかかるコストを億単位で削減、そのカギは？
