この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
コンバンハ、千葉（幸）です。
何かとコンフォーマンスしがちな今日この頃、いかがお過ごしでしょうか。
AWS Config の適合パック（コンフォーマンスパック）というものについて、最近知る機会がありました。適合パックについて、公式ブログでは以下のような説明があります。
適合パックを使用すると、コンプライアンスルールのパッケージを作成することができます。このパッケージはAWS Config ルールと修復アクションの両方を単一のエンティティにまとめたもので、大規模な展開を容易にします。そして、これらを組織全体に展開し、顧客や他のユーザーと共有できます。さらに、適合パックによりコンプライアンス・レポートも簡素化されます。これからは適合パックレベルでのレポートが可能になり、そこから従来通り個別のルールやリソースのレベルへ詳細化していくことも可能です。既存のレポート機能はすべてそのまま機能したままで、異なるチーム、異なるコンプライアンス体制、もしくは異なるガバナンス体制によって管理されたコンプライアンスセットを論理的にグルーピングすることができます。
なるほど。
...つまり ...どういうことだってばよ？
となったので、絵を描いてみることにしました。困ったらとりあえず描きますよね。
目次
AWS Config ルールの絵を描く
適合パックを構成する要素として、AWS Config ルールと修復アクションがあります。まずはここから抑えることにします。
AWS Config ルールを表したのが以下のイメージです。
AWS Config ルールを作成することでリソースに対する設定内容を評価することができます。AWSリソースは評価の結果、Config ルールに準拠しているか否かが定義されます。
例えば自アカウントのS3バケットを対象に「S3バケットがパブリックに書き込み可能な状態になっていないか」を評価するルールを作成すると、各S3バケットに対して評価が行われ、準拠状態にあるS3バケットとそうでないバケットに振り分けられます。
AWS Config ルールは、いくつかの要素から構成されます。
- 名称
- 説明
- トリガー
- ソースルール
名称と説明は特筆すべき点はないので、他の要素を掘り下げます。
AWS Config ルールのトリガー
トリガーは「定期的」「設定変更」の2種類に分類されます。前者は指定した時間ごとに定期的に評価が行われます。後者は指定したリソースに対する設定変更が発生した場合に評価が行われます。リソースの指定の仕方は、先ほどのS3の例に則ると以下のような指定の仕方ができます。
- リソースの種類（S3バケット全体）
- 識別子まで含めたリソース（1つ以上のS3バケットを明示的に指定）
- 特定のタグがついたリソース
そして、どちらのトリガータイプを指定できるかについては、AWS Config ルールにおける「ソースとなるルール」に影響を受けます。（ややこしいですね。）
指定できるルールには以下2種類があります。
- AWS Config マネージドルール
- AWS Config カスタムルール
AWS Config マネージドルール
マネージドルールは、評価内容を予めAWSが定義してくれているルールです。
再びS3の例を取ると、S3_BUCKET_PUBLIC_WRITE_PROHIBITEDという識別子のマネージドルールを使用したConfig ルールを作成することで、簡単に評価を行うことができます。
s3-bucket-public-write-prohibited
ドキュメントを確認すると、このマネージドルールはトリガータイプとして「設定変更」がサポートされていることが分かります。
マネージドルールによっては、パラメータとして何かしらの値を渡す必要があるものがあります。定義されているAWS Config マネージドルールの一覧および詳細は、以下を参照してください。
AWS Config カスタムルール
カスタムルールは、独自に定義した評価内容を Config ルールに設定できるものです。カスタムルールの内容をLambdaファンクションとして作成しておき、 Config ルールにそれを設定することで実現します。Lambdaファンクションの作成時に、トリガータイプ「定期的」「設定変更」それぞれに対応した設計図が用意されているため、それをカスタマイズして作成することもできます。
コードのサンプルは各言語ごとにいくつか用意されているので、こちらも参考にできます。
AWS Config 修復アクションの絵を描く
AWS Config ルールの確認が終わったので、もう一つのキーワード修復アクションを確認します。
イメージは以下です。
修復アクションは、AWS Config ルールに紐づける形で設定します。ルールによる評価の結果「非準拠」になったリソースに対して修復アクション（リソースの設定変更）を行い、「準拠」状態へ遷移させることができます。修復の実行を「自動」で行うか「手動」で行うかを選択可能です。
修復アクションは AWS Systems Manager の Automation ドキュメントによって行われます。 Config ルールと同じように、AWSが管理しているドキュメントと、カスタマーが独自に作成するドキュメントとが選択できます。いずれも、実行には Automation が assume するためのロールが必要となります。
冒頭のS3の例に戻ると、AWS管理の Automation ドキュメントAWS-DisableS3BucketPublicReadWriteを修復アクションとして指定することで、非準拠リソースを修復することができます。
修復アクションを設定する際には、繰り返し回数や失敗率に応じたレート制限を指定したり、ドキュメントによってはパラメータを設定します。
修復アクションの設定・動作イメージとしては以下を参照すると分かりやすいでしょう。ここでは、AWS Config マネージドルールに対してAWS-DisablePublicAccessForSecurityGroupというAWS管理のドキュメントを使用して自動で修復アクションを実行させています。
AWS Config 適合パックの絵を描く
ここまで AWS Config ルールと修復アクションを確認しました。これらは従来から存在するコンポーネントであり、これ自体は新しい考え方ではありません。両者をパッケージ化してひとつのかたまりとして管理できるようになったのが AWS Config 適合パックです。
イメージは以下です。
この図においては適合パックを一つしか表現していませんが、適合パックは一つのエンティティであり、複数作成することができます。適合パックの中心となるのはテンプレートです。 CloudFormation と同じような記法で一つ以上の AWS Config ルール（および必要に応じて修復アクション）を定義し、一括でデプロイすることができます。デプロイされた Config ルールは個別に作成された場合と同様に管理することもできますし、適合パックというグループの中で管理することもできます。
適合パックによるデプロイの裏側では CloudFormation が呼び出されているようです。修復アクションを含める場合の Automation 用のロールや、 AWS Config カスタムルールを使用する場合のLambdaファンクションなどは、ここでのデプロイの対象外となるため、先行して作成しておく必要があります。また、適合パックのデプロイにはサービス用のロールが必要になります。
適合パックという概念が登場する前から、 CloudFormation で AWS Config ルールと修復アクションを作成して管理するということはできました。それをさらにラップ・グルーピングして、適合パックという単位で管理できるようになったのが嬉しい部分だと理解しました。適合パック単位でレポートを作成してS3バケットに対して出力してくれたり、複数リージョンや別アカウントへの横展開がしやすいというメリットがあります。
適合パックの設定イメージは以下エントリを参照すると分かりやすいでしょう。
適合パックは Organizationsとも連携可能なため、以下のような形でマスターアカウント配下のAWSアカウントにデプロイすることができます。このような一元管理にも対応しています。
AWS Config からの通知
少し毛色が変わりますが、 AWS Config から行われる通知についても整理しておきます。
大きく分けて2種類あります。
配信チャネルによるストリーム通知
まずは配信チャネルによるSNSトピックへの通知です。Config をマネジメントコンソールから操作されたことがある方は、「設定」ペインでこのような表示がピンと来るかもしれません。ここの設定内容を指します。
ここで通知が行われるトリガー・内容は以下の通りです。
- リソースの設定項目の変更
- リソースの設定履歴がアカウントに配信された
- 記録対象のリソースの設定スナップショットがアカウントで起動および配信された
- リソースのコンプライアンス状態とリソースがルールに準拠するかどうか
- リソースに対してルールの評価が開始された
- AWS Config からアカウントに通知を配信できなかった
これらの項目はカスマイズ不可です。直接SNSトピック経由でEメール通知を行うと膨大な量の通知が飛ぶことになるため、間にLambdaファンクションを挟むなどして必要な通知のみを取捨選択することをお勧めします。
Events ルールによる通知
CloudWatch / Amazon EventBridge のEventsルールを使用することで、特定の AWS Config のイベントが発生した際に通知を行うことができます。ここで指定できるイベントの種類としては以下があります。
- CloudTrail 経由の AWS API 呼び出し（Configに対する呼び出し発生時）
- 設定項目の変更（リソースに設定変更が発生した時）
- 設定ルールのコンプライアンス変更（Config ルールに対して非準拠が発生した時）
- 設定ルールの再評価ステータス（再評価が行われた時、そのステータス）
- 設定スナップショット配信ステータス（設定スナップショットが配信された時、そのステータス）
- 設定スナップショット履歴の配信ステータス（設定スナップショット履歴が配信された時、そのステータス）
イベントごとに、いくつかのメッセージタイプが定義されています。例えば設定スナップショットの配信ステータスに関するメッセージであれば、「配信に成功した」「配信に失敗した」を表すメッセージタイプがあります。特定のメッセージタイプが発生した場合のみ通知を行うようフィルタリング することが可能です。
また、イベントの種類によっては、リソースタイプをフィルタリング することができます。「S3バケットに対する設定変更が行われた」場合のみイベントを発生させたり、リソースIDと組み合わせて「特定のS3バケットに対する設定変更のみ通知させる」といったことができます。
さらには、イベントの種類によっては AWS Config のルール名 によるフィルタリングも可能です。特定の Config ルールにおいて非準拠が発生した場合のみ通知を行いたい、というケースに対応しています。
標準で用意されている通知の種類は上記の通りですが、AWS Config カスタムルール（Lambdaファンクション）や、修復アクション（ AWS Systems Manager の Automation ドキュメント）の中に通知の仕組みを入れ込むみことも可能です。
終わりに
AWS Config 適合パックについて整理しました。これで無事コンフォーマンスすることが可能になったかと思います。便利な仕組みは積極的に活用していきたいですね。
（途中でやめようかと何回か思ったけどちょうど良いやめ時を失って結局最後まで描き切った）絵が、皆さんの理解の一助になれば幸いです。
以上、よろしくお願いいたします。
7
