当エントリは弊社AWS事業本部による『AWS 入門ブログリレー 2024』の31日目のエントリです。
このブログリレーの企画は、普段 AWS サービスについて最新のネタ・深い/細かいテーマを主に書き連ねてきたメンバーの手によって、 今一度初心に返って、基本的な部分を見つめ直してみよう、解説してみようというコンセプトが含まれています。
AWS をこれから学ぼう！という方にとっては文字通りの入門記事として、またすでに AWS を活用されている方にとっても AWS サービスの再発見や 2024 年のサービスアップデートのキャッチアップの場となればと考えておりますので、ぜひ最後までお付合い頂ければ幸いです。
では、さっそくいってみましょう。今回のテーマは『AWS Config』です。
目次
- 全体像をざっくりと紹介
- セキュリティや統制で役立つサービスである
- リソースの構成情報を記録してくれる
- 加えて構成情報を評価できる
- Config記録を深堀り
- 設定レコーダーを作成して記録を開始する
- 記録をチューニングする
- 構成情報はJSONで管理されている
- S3バケットに配信できる
- Configルールを深堀り
- ルールを作成して構成情報を評価する
- AWS管理ルールを使ってお手軽に展開する
- カスタムルールを使って柔軟にルールを定義する
- 修復アクションを関連付けできる
- デプロイ前の検証もできる
- ほか主要な機能
- Conformance Packs で Configルールをパッケージ化する
- Aggregator を使って Configデータを集約する
- 高度なクエリ を使って構成情報を棚卸しする
- Organizations 連携で簡単にセットアップする
- ほか細かい機能
- Security Hub 上でConfigルールを確認できる
- SNSやEventBridgeを使って通知する
- ダッシュボードあります
- サードパーティリソースも記録できる
- 料金
- 設定項目ごとに料金がかかる
- ルールによりリソースが評価されるごとに料金がかかる
- 終わりに
- 参考
全体像をざっくりと紹介
セキュリティや統制で役立つサービスである
AWS Config は セキュリティや統制で役立つサービスです。
主な機能は Configuration Recorder による記録(Record) と Config Rules による評価(Evaluate) です。
記録により、AWS上にどのようなリソースが存在し、どのような設定であるかを把握できます。 評価により、AWS上のリスクのある設定を早期に発見し、解消できます。
なぜ必要？
クラウド(AWS)の特徴として「アジリティの向上」がありますよね。 開発者はサービス稼働に必要なリソースを迅速に展開できます。
ただ、これは裏返すと 「大量のリソースが猛スピードで作られて、 AWS環境がわちゃわちゃになってくる 」リスクもあるわけです。 ガバナンスが低下してくるのです。 そのままにしていると、潜在的なセキュリティリスクのある設定を見逃すかもしれません。
とはいえ ガバナンスを取り戻すために、 大量のリソースの設定を手動で棚卸しするのは骨が折れます。
そういった大変さを補ってくれるのが AWS Config です。
AWS Config は「アジリティとガバナンスの両立」を実現するのに必要不可欠なサービスです。
リソースの構成情報を記録してくれる
Config の根幹は、 AWSリソースの構成を記録しつづけること です。
AWSリソースに関する「今どのような状態か」や「いつ、どのような設定変更がされたか」、 「他のリソースとどのような関係か」を確認できます。
マネジメントコンソールやAPIを通じて、 サービス横断で各種AWSリソースの構成情報を確認できます。
同じように、 そのリソースがどのような設定変更を辿ったのか、 追跡できます。
加えて構成情報を評価できる
そのうえで Configルール というリソースも作成できます。 これは「記録している構成情報が 理想的な状態かどうかを評価してくれる機能 」です。 評価の例としては「セキュリティグループでSSH全開放になっていないか」や 「S3バケットがパブリック公開されていないか」などがあります。
マネジメントコンソール上で 評価結果を確認できます。 セキュアなAWS環境利用を維持するのに役立ちます。
また、似たようなポジションのAWSサービスとしては AWS Trusted Advisor や AWS Security Hub があります。 これらも「AWSリソースが理想的な状態になっているのか」をチェックするのに役に立ちます。
Config記録を深堀り
Configのメイン機能である「Configuration Recorder による記録(Record)」を深堀りしていきます。
設定レコーダーを作成して記録を開始する
構成情報の記録を開始するには、 設定レコーダー と呼ばれるリソースを作成する必要があります。 設定レコーダーはリージョンごとに1つのみ作成できます。
設定レコーダーでは以下のようなパラメータを指定します。
- 記録するリソースタイプ (「すべて」 もしくは 「特定のリソースタイプ」)
- 記録頻度 (「継続的な記録」もしくは「日時記録」)
- Configデータの保持期間
- …など
セットアップの詳細については以下を参照ください。
記録をチューニングする
サポートされているリソースタイプは以下から確認できます。 2024/04 時点で 400 個以上のリソースタイプがあります。
取得するリソースタイプは以下2パターンのチューニングが可能です。それぞれ紹介します。
- カスタマイズ可能なオーバーライドのあるすべてのリソースタイプ
- 特定のリソースタイプ
カスタマイズ可能なオーバーライドのあるすべてのリソースタイプ
現在および将来サポートされるリソースタイプを記録します。
また、チューニングとして「記録頻度」と「オーバーライド設定」を指定できます。 これらは以下アップデートから追加された項目です。
- [アップデート]AWS Configで特定のリソースタイプだけを記録から除外できるようになりました！ | DevelopersIO
- [アップデート]AWS Config が定期的な記録をサポートするようになりました: 変更追跡を効率的にスケールします #AWSreInvent | DevelopersIO
特定のリソースタイプ
明示的に指定したリソースタイプのみを記録します。 リソースタイプと記録頻度の組み合わせを設定します。
構成情報はJSONで管理されている
構成情報はリソース単位でJSONとして管理されています。 以下サンプルとして VPCの構成情報 の JSON を記載します。 単なる設定値だけでなく、 他リソースとの関連 (relationships) も記載されているのがポイントです。
{
"version": "1.3",
"accountId": "123456789012",
"configurationItemCaptureTime": "2024-04-04T00:42:37.085Z",
"configurationItemStatus": "OK",
"configurationStateId": "1712191357085",
"configurationItemMD5Hash": "",
"arn": "arn:aws:ec2:ap-northeast-1:123456789012:vpc/vpc-example",
"resourceType": "AWS::EC2::VPC",
"resourceId": "vpc-example",
"awsRegion": "ap-northeast-1",
"availabilityZone": "Multiple Availability Zones",
"tags": {
"Owner": "XXX",
"Name": "sample-vpc"
},
"relatedEvents": [],
"relationships": [
{
"resourceType": "AWS::EC2::NetworkAcl",
"resourceId": "acl-05d433aa25eef4f14",
"relationshipName": "Contains NetworkAcl"
},
{
"resourceType": "AWS::EC2::RouteTable",
"resourceId": "rtb-068891efb3943980e",
"relationshipName": "Contains RouteTable"
},
{
"resourceType": "AWS::EC2::SecurityGroup",
"resourceId": "sg-0e17fe0712d64e0a5",
"relationshipName": "Contains SecurityGroup"
}
],
"configuration": {
"cidrBlock": "10.0.0.0/16",
"dhcpOptionsId": "dopt-5975213e",
"state": "available",
"vpcId": "vpc-example",
"ownerId": "123456789012",
"instanceTenancy": "default",
"ipv6CidrBlockAssociationSet": [],
"cidrBlockAssociationSet": [
{
"associationId": "vpc-cidr-assoc-04b7257a2382af89f",
"cidrBlock": "10.0.0.0/16",
"cidrBlockState": {
"state": "associated",
"statusMessage": null
}
}
],
"isDefault": false,
"tags": [
{
"key": "Name",
"value": "sample-vpc"
},
{
"key": "Owner",
"value": "XXX"
}
]
},
"supplementaryConfiguration": {}
}JSONの各要素については以下公式ドキュメントに説明があります。
Configのマネジメントコンソール上では、 主要なパラメータをピックアップして表示してくれています。
S3バケットに配信できる
S3バケットに 設定スナップショット を配信できます。
AWS Config > [設定] > [配信方法] にて設定します。 以下のようなパスで、JSONとして保存されます。
${Bucket}/${Prefix}/AWSLogs/123456789012/Config/ap-northeast-1/2024/4/12/ConfigSnapshot/${長いファイル名}.json.gz
Athena、QuickSight などのツールを使って分析・可視化が可能です。
Configルールを深堀り
セキュリティチェックに役立つ「Config Rules による評価(Evaluate)」機能を深堀りしていきます。
構成情報を評価する
Configルール はリソースの構成情報を評価してくれる機能です。 リソースがルールに準拠していない場合、 非準拠( NON_COMPLIANT ) フラグが付けられます。
例えば以下のキャプチャでは、 vpc-flow-logs-enabled ルールが各VPCを評価しています。 VPC Flow Logs が有効化されていないVPCに対して、 非準拠( NON_COMPLIANT ) フラグが付けています。
AWS管理ルールを使ってお手軽に展開する
AWS管理ルール は AWSが事前に定義してくれているConfigルールです。 お手軽に展開できます。
2024/04時点で 370以上の AWS管理ルールがあります。 以下ドキュメントにて、ルールのリストを確認できます。
いくつか役立ちそうなルールをピックアップします。
| ルール | 対象リソース | 非準拠になる状態 |
|---|---|---|
| restricted-ssh | セキュリティグループ | インバウンドルールでSSHポートを全開放している |
| s3-bucket-level-public-access-prohibited | S3バケット | パブリックアクセス可能である |
| rds-storage-encrypted | RDS DBインスタンス | ストレージが暗号化されていない |
| ec2-managedinstance-applications-required | EC2インスタンス(※SSM管理下) | 指定したアプリケーションがインストールされていない |
| guardduty-enabled-centralized | AWSアカウント | GuardDutyが有効になっていない |
| required-tags | ドキュメント参照 | 指定したタグ(オプション: タグ値)がリソースに付与されていない |
カスタムルールを使って柔軟にルールを定義する
カスタムルールでは、自前で評価を定義します。
カスタムルールには2種類あります。 Lambda関数を使う方法と、Guardカスタムポリシーを使う方法です。
Lambda関数を使う方法では、 Lambda関数内でリソースを評価するロジックを記載します。 rdk と呼ばれる 「Configルール用 Lambda関数の作成をサポートするツール」もあったりします。
Guardカスタムポリシーでは CloudFormation Guard と呼ばれる 「ポリシーを定義するための言語」を使って ルールを定義します。
修復アクションを関連付けできる
Configルールに 修復アクション を関連付けできます これにより非準拠になったリソースに対して、修復を簡単に実行できます。
作成したルールの画面にて [修復の管理] を選択して設定します。
自動修復もしくは手動修復を選択できます。 修復アクションには Systems Manager(SSM)オートメーション ドキュメントを指定します。
デプロイ前の検証もできる
これまで説明したConfigルールは いわゆる "検出モード" でした。 実はもう一つモードがあります。それが "プロアクティブモード" です。
これはリソースをプロビジョニングする "前" に評価を実行できる機能です。
※「CloudFormationによるプロビジョニング」に限ります。
プロアクティブモードで利用できるAWS管理ルールには限りがあります。 以下ドキュメントを参照ください。
ほか主要な機能
Conformance Packs で Configルールをパッケージ化する
Conformance Packs (コンフォーマンスパック; 適合パック) を使って Configルールをまとめて管理、展開できます。 CloudFormationと同じのような記法でYAMLテンプレートを書きます。 Configダッシュボードにて、コンフォーマンスパックごとの準拠/非準拠状況を確認できます。
Conformance Packs の詳細は以下ブログが分かりやすいです。
また、AWSから Conformance Packs のサンプルテンプレートが多く提供されています。
Aggregator を使って Configデータを集約する
Config Aggregator(アグリゲーター) を作成することで、 Configデータ(リソース構成情報や Configルールの評価結果) を集約できます。 マルチアカウント、マルチリージョンで集約可能です。
実装としては、 各 "ソースアカウント" から Configデータを "アグリゲーターアカウント" に レプリケートしています。 アグリゲーターアカウント上で読み取り専用の集約ビューを見ることができます。
高度なクエリ を使って構成情報を棚卸しする
高度なクエリ は Config記録に対してクエリ実行して、 欲しい情報を取得できる機能です。 クエリ対象としてアグリゲーターも選択可能なので、 複数アカウント・複数リージョン横断で棚卸しができます。便利です。
マネジメントコンソールには AWS提供のサンプルクエリがいくつか提供されています。 よく使うクエリをカスタムクエリとして保存することもできます。
例えば以下のようなクエリを流すことで EC2インスタンス一覧を棚卸しできます。
SELECT
accountId,
awsRegion,
resourceId,
configuration.instanceType,
tags.tag,
resourceCreationTime
WHERE
resourceType = 'AWS::EC2::Instance'
ORDER BY
accountId;– クエリ引用: AWS Config の高度なクエリを使って AWS Organizations 配下の EC2 インスタンスを棚卸ししてみた | DevelopersIO
クエリの文法は公式ドキュメントの Query Components にあります。 また、SELECTで取得できるリソースタイプ・プロパティには、制限がある点に注意が必要です。 以下 GitHubページにてまとめられています。
ちなみに、今時点(2024/04)ではプレビューですが、生成AIを使ってクエリを出力できる機能があります。
Organizations 連携で簡単にセットアップする
Configは AWS Organizations 連携 に対応しています。 アカウント横断のConfig管理をより楽にしてくれます。
できることは主に以下2つです。
| できること | セットアップ例 |
|---|---|
| Conformance Packs を組織全体に展開する | 適合パック(Conformance Packs)を使って組織内のアカウントにConfigルールと修復アクションを展開してみた | DevelopersIO |
| 組織の Aggregator を作成する | 組織のConfigアグリゲータをAWS CLIで作成する | DevelopersIO |
ほか細かい機能
Security Hub 上でConfigルールを確認できる
AWS Configはデフォルトで AWS Security Hub と統合 されています。 Security Hub 上で Configルールの結果を確認できます。
様々なセキュリティ通知(もしくは何らかの処理)を Security Hub 経由で行い、 集中管理することが多いです。 その枠組みに Configルールも入れることができます。
SNSやEventBridgeを使って通知する
SNSトピックと連携しています。 例えばリソースが更新されたときに、 特定のEメールアドレスへ通知を送信することができます。
送信できるイベントについては以下公式ドキュメントを参照ください。
AWS Config は、以下のイベントの通知を送信します。
- リソースの設定項目の変更。
- リソースの設定履歴がアカウントに配信された。
- 記録対象のリソースの設定スナップショットがアカウントで起動および配信された。
- リソースのコンプライアンス状態とリソースがルールに準拠するかどうか。
- リソースに対してルールの評価が開始された。
- AWS Config からアカウントに通知を配信できなかった。
また、EventBridgeを使ったConfigイベントの検知も可能です。 「特定Configルールで非準拠になった」など、 特定イベントに絞りたい場合は EventBridge のほうが実装が楽です。
詳細や実装例は以下を参照ください。
- Monitoring AWS Config with Amazon EventBridge - AWS Config
- EventBridge を使って特定 Config ルールのコンプライアンスチェック内容を通知してみた | DevelopersIO
ダッシュボードあります
マネジメントコンソールで見られるダッシュボードは以下の3つです。
- Config > ダッシュボード
- Config > アグリゲーター > コンプライアンスダッシュボード
- Config > アグリゲーター > インベントリダッシュボード
アグリゲーターの2つのダッシュボードは比較的新しい機能(2023/11)です。
サードパーティリソースも記録できる
AWSリソース以外にも、 サードパーティのリソースやオンプレミスサーバーなどを記録できます。 いくつかツールやステップが必要です。詳しい設定方法は以下ドキュメントを参照ください。
料金
Configの利用でかかる料金について説明します。 ※最新の情報は公式を参照ください。
設定項目ごとに料金がかかる
配信された設定項目ごとに課金されます。 設定項目は「リソースが新規作成されたタイミング」や、 「リソースの関係に変更があったタイミング※」に作成されます。
※例えば「セキュリティグループをEC2インスタンスにアタッチした」ときに、 そのEC2インスタンスの設定項目が作成されます。 EC2インスタンス自体の設定は変わっていないが、 関係(relationships) が変わったため設定項目が作成された、ということです。
2024/04時点の東京リージョンの料金は以下のとおりです。
各 AWS リージョンの AWS アカウントごとに配信される設定項目あたりのコスト 連続的な記録 0.003USD 定期的な記録 0.012USD -- 引用: 料金 - AWS Config | AWS
ルールによりリソースが評価されるごとに料金がかかる
Configルール(やコンフォーマンスパック)の課金は「ルールの評価数」で決定されます。 もし、検出モードとプロアクティブモードの両方を有効化している場合、 「検出モードでの評価でのみ課金」となります。
2024/04時点の東京リージョンの料金は以下のとおりです。
AWS Config のルール
AWS Config ルール評価 料金 最初の 100,000 件のルール評価 リージョンごとのルール評価ごとに 0.001USD 次の 400,000 件のルール評価 (100,001～500,000) リージョンごとのルール評価ごとに 0.0008USD 500,001 件以上のルール評価 リージョンごとのルール評価ごとに 0.0005USD コンフォーマンスパック
コンフォーマンスパック評価 料金 最初の 100,000 件のコンフォーマンスパック評価 リージョンごとのコンフォーマンスパック評価あたり 0.001USD 次の 400,000 件のコンフォーマンスパック評価 (100,001〜500,000) リージョンごとのコンフォーマンスパック評価あたり 0.0008USD 500,001 件以上のコンフォーマンスパック評価 リージョンごとのコンフォーマンスパック評価あたり 0.0005USD -- 引用: 料金 - AWS Config | AWS
終わりに
以上、『AWS 入門ブログリレー 2024』の31日目のエントリ『AWS Config』編でした。 次回、2024/04/25 は弊社 千葉 幸宏（チバユキ） による「AWS IAM編」の予定です！
9
