宣言型ポリシーによる予防的統制の強化
2024年12月1日に宣言型ポリシー (Declarative policies) が発表されました（日本語はこちら）。
宣言型ポリシーとは
宣言型ポリシーは、複数アカウントに対して一貫したセキュリティベースラインを設定するために有用な機能です。SCP (Service control policy) や RCP (Resource control policy) がコントロールプレーンやリソースへのAPIアクセスの認可処理に適用されていたのに対して、宣言型ポリシーは各AWSのコントロールプレーンに適用されるポリシーです。
SCPやRCPによる制御はAPIリクエストに対して適用されるため、サービスに新しい機能やAPIが導入されると、SCPやRCPでの対応が完了するまでの間にアカウント利用者が望ましくない操作を実行できるという課題がありました。宣言型ポリシーはリソースの属性・状態が望ましくない状態になること自体を防止できるため、そのような心配がなく、確実に統制を効かせることができます。
要因（リソースを望ましい状態から逸脱させる操作）を制限するのではなく、結果（リソースの属性・状態）を制限することができるので、抜け漏れも発生しづらく、簡単に統制を効かせることができるのも利点です。
宣言型ポリシーでは、リクエストが拒否された際のエラーメッセージをカスタマイズすることができます。操作に失敗した時に、どこに問い合わせて良いのか分からず何時間も溶かしたことがある人は少なくないと思いますが、メッセージに問い合わせ先を表示しておけば安心ですね。実際の利用シーンを踏まえた嬉しい機能です。
宣言型ポリシーの適用
Organizationsで組織全体や特定OU/アカウントに対して適用することができます。既存アカウントの場合、所属するOUに宣言型ポリシーを適用した時点、もしくは宣言型ポリシーが適用されたOUにアカウントを追加した時点から、宣言型ポリシーによる統制が適用されるようになります。アカウントにポリシーに準拠しないリソースがある場合も、既存リソースが削除されたりするようなことはなく、適用開始時点から非準拠アクションが失敗するようになります。宣言型ポリシーはコントロールプレーンに適用されるものなので、自然な挙動といえます。
宣言型ポリシーはControl Towerから適用することもできますが、記事執筆時点ではサポートされているポリシーには次表のような違いがあるようです。類似もしくは関連しそうなConfigのマネージドルールを併記しておいたので、これらを利用中の方は発見的統制に加えて予防的統制の導入を検討されると良いと思います。
Control Towerで適用される具体的なポリシーはドキュメントに書かれているので、適用前によく確認することをお勧めします。例えば、[CT.EC2.PV.7] Disallow all public sharing of Amazon EBS snapshots で適用される宣言型ポリシーはこんな感じ。
{
"ec2_attributes": {
"snapshot_block_public_access": {
"state": {
"@@assign": "block_all_sharing",
"@@operators_allowed_for_child_policies": ["@@all"]
}
}
}
}
Control Towerでは適用するポリシーをカスタマイズできませんが、OrganizationsではマネコンからVisual EditorやJSON Editorを用いて柔軟なポリシーを作成できるようになっています。細かい制御が必要な場合はOrganizationsから設定する必要があります。
ステータスレポート
宣言型ポリシーはステータスレポートを使用して現在のステータスを評価してから適用することがベストプラクティスとされています。
ステータスレポートを生成することで、実際にポリシーを適用する前に適用候補のアカウントの準備状況を把握することができます。アカウント間でポリシーに関するリソースの属性が一貫しているかも確認できます。
ステータスレポートは指定したS3バケットに作成されます。S3バケットには次のようなバケットポリシーを設定する必要があります。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DeclarativePoliciesReportBucket",
"Effect": "Allow",
"Principal": {
"Service": [
"report.declarative-policies-ec2.amazonaws.com"
]
},
"Action": [
"s3:PutObject"
],
"Resource": "arn:aws:s3:::<bucketName>/*",
"Condition": {
"StringEquals": {
"aws:SourceArn": "arn:<partition>:declarative-policies-ec2:<region>:<accountId>:*"
}
}
}
]
}
公式ドキュメントのPrerequisitesに次のような記載があり、私はOregon (us-west-2) を利用していることからOregonに作成したバケットを指定したのですがエラーが発生しました。N.Virginia (us-east-1) のバケットを指定するとうまくいったので、レポート生成処理は N.Virginia で動作しているのかもしれませんね。
You must have an S3 bucket before generating the report (create a new one or use an existing one), it must be in the same Region in which the request is made, and it must have an appropriate S3 bucket policy.
(Google翻訳) レポートを生成する前に S3 バケット (新規作成または既存のバケットを使用) が必要であり、そのバケットはリクエストが行われたのと同じリージョンにあり、適切な S3バケットポリシーを持っている必要があります。
まとめ
宣言型ポリシーの登場によって、より簡単かつ確実に予防的統制を適用することができるようになりました。まだサポートされているポリシーが少ないのですが、CIS Benchmarksなどのよく利用されるガイドラインに簡単に準拠できるルールが増えていくことを期待したいと思います。
Discussion