こんにちは、キクです。
｢AWS初心者だけど、何かしらの形でアウトプットしていきたい!!｣
本記事は、そんな思いから｢AWS学習記録｣として気ままにアウトプットしていくシリーズです。
今回は『AWS Config』をテーマに書いていきたいと思います！
それでは、よろしくお願いします。
はじめに
まずはじめに、今回の作業内容について簡単にご紹介します。
作業記録
本章では、実際にAWSでの操作内容を書いていこうと思います。
1. AWS Configの有効化
本項では、本記事のメインテーマである「AWS Config」の有効化を実施していきます。
本設定はリージョン単位での実施となるため、AWS Configで記録したいリージョンにて作業を実施します。
設定作業
■1-1. AWS Configトップ画面にて「1-Clickセットアップ」をクリック
メモ
初回設定時と設定後でトップ画面の表示が変わります。
▲設定後のコンソール画面
■1-2.「レビュー」画面にて、内容を確認して「確認」をクリック
■1-3. 左ペインにて「設定」をクリック
■1-4.「レコーダー」が「記録はオン」と表示されていることを確認
2. AWS Configルールの作成
本項では、AWS Config機能の一つである「ルール」を作成していきます。
AWS Configを有効化するだけでも各リソースの設定変更の記録は可能ですが、ルールを作成することでその内容に応じて「ルールに沿った適切な設定状態になっているか」というのを判定できるようになります。
設定作業
■2-1. AWS Config管理画面の左ペインにて「ルール」をクリック
■2-2.「ルールを追加」をクリック
■2-3.「ルールタイプの指定」画面にて、以下のパラメータを設定して「次へ」をクリック
■2-4.「ルールの設定」画面にて、以下のパラメータを設定して「次へ」をクリック
設定パラメータ
詳細
名前 ：Test-Restricted-Common-Ports
トリガー
変更範囲 ：リソース（デフォルト）
リソースカテゴリ ：すべてのリソースカテゴリ（デフォルト）
リソースタイプ ：Multiple Selected - AWS EC2 SecrityGroup（デフォルト）
パラメータ（一部変更）
キー ：blockedPort1
値 ：22
※その他の部分はデフォルト
■2-5.「確認と作成」画面にて、内容を確認して「ルールを追加」をクリック
■2-6. Configルールが作成されたことを確認
動作確認
■2-7. AWS Configルール作成後、「コンプライアンス」列のステータスが反映されるまで待機する
■2-8. 同画面にて、作成したConfigルール名(青字)をクリック
■2-9.「対象範囲内のリソース」にて、Configルールに対する準拠/非準拠のリソースを確認できる
■2-10. 適当な非準拠リソース(青字)をクリック
本操作により選択したリソースの管理画面に遷移します。
■2-11. 本画面（AWS Config -> リソース -> 対象リソース）にて指定した非準拠リソースの詳細情報が確認できる
ポイント
実際にこの非準拠リソース（セキュリティグループ）のインバウンドルールを確認してみると、Configルールで禁止している「ポート22（SSH）」が解放されていて違反状態であることが分かります。
3. 非準拠リソースの作成
本項では、先ほど作成したAWS Configルールに違反する「非準拠リソース」を作成していきます。
これにより、AWS Configルールが適切に動作するかを確認していきます。
今回の場合、リソースとしてはセキュリティグループを作成すれば問題ないですが、後続作業で少しだけ利用することを加味してEC2インスタンスも併せて作成していきます。
設定作業
■3-1. EC2管理画面にて「インスタンスを起動」をクリック
■3-2.「インスタンスを起動」画面にて、以下のパラメータを設定して「インスタンスを起動」をクリック
設定パラメータ
名前 ：Test-EC2
AMI ：Amazon Linux2 AMI
インスタンスタイプ ：t2.micro
キーペア名 ：適宜選択
ネットワーク設定
VPC ：デフォルトVPC
ファイアウォール（セキュリティグループ）：セキュリティグループを作成する
セキュリティグループ名：Test-SG
セキュリティグループルール1
タイプ ：ssh
プロトコル ：TCP
ポート範囲 ：22
ソースタイプ ：カスタム
ソース ：0.0.0.0/0
※その他の部分はデフォルト
■3-3. EC2管理画面の左ペインにて「セキュリティグループ」をクリック
■3-4. 項番3-2で作成したセキュリティグループ(Test-SG)のインバウンドルールで「タイプ：SSH / ポート範囲：22」が許可されていることを確認
動作確認
■3-5. AWS Config管理画面の左ペインにて「ルール」をクリック
■3-6. 対象Configルールの「コンプライアンス」列の非準拠リソース数が増えていることを確認
■3-7. 対象Configルール名(青字)をクリック
■3-8.「対象範囲内のリソース」にて、対象セキュリティグループ(Test-SG)が非準拠リソースとして表示されていることを確認
■3-9. 対象セキュリティグループ(Test-SG)のID（青字）をクリック
■3-10. 対象セキュリティグループ(Test-SG)がConfigルール「Test-Restricted-Common-Ports」に違反していることを確認
4. 修復アクションの設定
本項では、AWS Config機能の一つである「修復アクション」を設定していきます。
前項で非準拠リソースにしたセキュリティグループを手動で準拠リソースの状態、つまりインバウンドルールでのポート22（SSH）の無効化を実施してもいいのですが、修復アクションを設定することで「手動」あるいは「自動」で非準拠リソースを準拠リソースの状態にすることが可能です。
「手動」の場合においても、ボタン1つで準拠状態にできるので、インバウンドルールを直接操作するよりも安全です。
設定作業
■4-1. AWS Config管理画面の左ペインにて「ルール」をクリック
■4-2. 対象Configルールを選択し、「アクション -> 修復の管理」をクリック
■4-3.「編集：修復アクション」画面にて、以下のパラメータを設定して「変更を保存」をクリック
■4-4. 対象Configルール管理画面にて、設定した「修復アクション」情報が追加されていることを確認
5. 非準拠リソースへの修復アクションの実施
本項では、前項で設定した「修復アクション」を実際に使ってみようと思います。
設定作業
■5-1. 同画面の「対象範囲内のリソース」にて、対象セキュリティグループ(Test-SG)を選択して「修復」をクリック
■5-2. 対象セキュリティグループの「ステータス」列が「アクションが正常に実行されました」と表示されるのを確認
■5-3. しばらく待機した後、対象セキュリティグループが「非準拠リソース」一覧に表示されなくなったことを確認
■5-4.「準拠リソース」一覧に対象セキュリティグループが表示されることを確認
■5-5. EC2管理画面の左ペインにて「セキュリティグループ」をクリック
■5-6. 対象セキュリティグループのインバウンドルールから「タイプ：SSH / ポート範囲：22」が削除されていることを確認
6. リソースタイムラインの確認
本項では、AWS Config機能の一つである「リソースタイムライン」を確認していきます。
AWS Configを有効化することで各リソースの状態遷移は「リソースタイムライン」から確認できるので、適切に使いこなせるように慣れておきたいですね。
動作確認
■6-1. AWS Config管理画面の左ペインにて「ルール」をクリック
■6-2. 対象Configルール名(青字)をクリック
■6-3.「対象範囲内のリソース」にて「準拠」を表示して、対象セキュリティグループ(Test-SG)のID (青字)をクリック
■6-4. 対象セキュリティグループ(Test-SG)のリソース情報画面にて、「リソースタイムライン」をクリック
■6-5. 本画面にて指定したリソースの変更履歴などの情報を確認できる
7. Amazon SNS連携による通知設定
本項では、Amazon SNSを用いた通知設定を実施していきます。
設定画面に「Eメール設定した場合、Eメールが大量に送付される可能性がある」と注意書きが表示されますが、今回は一旦Eメールで設定します。
設定作業
■7-1. AWS Config管理画面の左ペインにて「設定」をクリック
■7-2.「設定」画面にて、「編集」をクリック
■7-3.「設定の編集」画面にて、以下のパラメータを設定して「保存」をクリック
設定パラメータ
配信方法
Amazon S3 バケット ：アカウントからバケットを選択
S3バケット名 ：適宜選択
Amazon SNS トピック
└Amazon SNS トピックへのストリーム設定の変更と通知：チェック
└トピックの作成 ：チェック
└SNS トピック名 ：Test-SNS-Topic
※その他の部分はデフォルト
■7-4.「配信方法」に作成したSNSトピック名が表示されることを確認
■7-5. AWS SNSの管理画面の左ペインにて「トピック」をクリック
■7-6. 項番7-3で作成したSNSトピック(青字)をクリック
■7-7.「サブスクリプション」タブを選択し、「サブスクリプションの作成」をクリック
■7-8.「サブスクリプションの作成」画面にて、以下のパラメータを設定して「サブスクリプションの作成」をクリック
設定パラメータ
詳細
トピックARN ：Test-SNS-TopicのARN（入力済み）
プロトコル ：Eメール
エンドポイント ：通知先Eメールアドレス
※その他の部分はデフォルト
■7-9. 指定したメールアドレス宛にSNSに関するメールが届いていることを確認
■7-10. メール内記載の「Confirm subscription (青字)」をクリック
■7-11. 登録が完了し「Subscription confirmed」画面が表示されたことを確認
■7-12. 対象トピック(Test-SNS-Topic)管理画面にて、対象サブスクリプションの「ステータス」が「確認済み」になっていることを確認
動作確認
セキュリティグループのインバウンドルール変更
■7-13. EC2管理画面の左ペインにて「セキュリティグループ」をクリック
■7-14. 対象セキュリティグループ(Test-SG)のインバウンドルールで「タイプ：SSH / ポート範囲：22」が許可されていないことを確認
■7-15. 対象セキュリティグループ(Test-SG)のインバウンドルールで「タイプ：SSH / ポート範囲：22」を許可する（ = インバウンドのルールの編集）
設定パラメータ
タイプ ：SSH
プロトコル ：TCP
ポート範囲 ：22
ソース ：Anywhere-IPv4（0.0.0.0/0）
■7-16. AWS Config管理画面の左ペインにて「ルール」をクリック
■7-17. 対象Configルール名(Test-Restricted-Common-Ports(青字))をクリック
■7-18.「対象範囲内のリソース」にて、対象セキュリティグループ(Test-SG)が非準拠リソースとして表示されていることを確認
■7-19. 項番7-8で指定したメールアドレス宛にセキュリティグループのルール変更に伴う通知が届いていることを確認
■7-20. タイトルに「NON_COMPLIANT」を含むメールを確認
対象セキュリティグループが非準拠リソース(complianceType：NON_COMPLIANT)と認識されたことが確認できる
EC2インスタンスの停止
■7-21. EC2管理画面の左ペインにて「インスタンス」をクリック
■7-22. 対象EC2インスタンス(Test-EC2)を停止
■7-23. 項番7-8で指定したEメールアドレス宛にEC2インスタンスの停止に伴う通知が届いていることを確認
8. Amazon EventBridge連携による通知設定
本項では、Amazon EventBridgeを用いた通知設定を実施していきます。
実際に通知を行うのは先程と同様に「Amazon SNS」ですが、本項では「特定の情報のみ」を通知するように設定していきます。
設定作業
■8-1. Amazon EventBridge管理画面の左ペインにて「ルール」をクリック
■8-2.「ルールの詳細を定義」画面にて、以下のパラメータを設定して「次へ」をクリック
■8-3.「イベントパターンを構築」画面にて、以下のパラメータを設定して「次へ」をクリック
設定パラメータ
イベントソース
イベントソース ：AWS イベントまたは EventBridge パートナーイベント
サンプルベント - オプション
サンプルイベントタイプ ：AWSイベント
サンプルイベント ：Config Rules Compliance Change
作成のメソッド ：カスタムパターン（JSONエディタ）
イベントパターン
イベントパターン ：プレフィックスマッチング
{
"source": ["aws.config"],
"detail-type": ["Config Rules Compliance Change"],
"detail": {
"messageType": ["ComplianceChangeNotification"],
"configRuleName": ["Test-Restricted-Common-Ports"],
"resourceType": ["AWS::EC2::SecurityGroup"],
"newEvaluationResult": {
"complianceType": ["NON_COMPLIANT"]
}
}
}
■8-4.「ターゲットを選択」画面にて、以下のパラメータを設定
設定パラメータ
ターゲット1
ターゲットタイプ ：AWSサービス
ターゲットを選択 ：SNSトピック
トピック ：Test-SNS-Topic
追加設定
ターゲット入力を設定 ：入力トランスフォーマー
※その他の部分はデフォルト
■8-5.「入力トランスフォーマー」直下にある「入力トランスフォーマーを設定」をクリック
■8-6.「入力トランスフォーマーを設定」画面にて、以下のパラメータを設定して「確認」をクリック
設定パラメータ
ターゲット入力トランスフォーマー
入力パス
{
"awsRegion": "$.detail.awsRegion",
"resourceId": "$.detail.resourceId",
"awsAccountId": "$.detail.awsAccountId",
"compliance": "$.detail.newEvaluationResult.complianceType",
"rule": "$.detail.configRuleName",
"time": "$.detail.newEvaluationResult.resultRecordedTime",
"resourceType": "$.detail.resourceType"
}
テンプレート
"発生時刻 : <time>"
"ルール名 : <rule> "
"リソースタイプ : <resourceType>"
"リソースID : <resourceId>"
"AWSアカウント : <awsAccountId>"
"上記リソースが <compliance> 判定となりました。"
"詳細は以下URLよりご確認ください。"
"https://console.aws.amazon.com/config/home?region=<awsRegion>#/timeline/<resourceType>/<resourceId>/configuration"
※その他の部分はデフォルト
■8-7.「ターゲットを選択」画面にて、「次へ」をクリック
■8-8.「タグを設定」画面にて、何もせずに「次へ」をクリック
■8-9.「レビューと作成」画面にて、内容を確認して「ルールの作成」をクリック
■8-10. EventBridgeルールが作成されたことを確認
動作確認
動作確認方法は既に実施した内容と同じであるため詳しい手順は割愛しますが、「非準拠 -> 準拠」「準拠 -> 非準拠」への切り替えに伴う通知状況を確認します。
■8-11. 対象セキュリティグループ(Test-SG)を「非準拠リソース」から「準拠リソース」へと設定変更
■8-12. 対象セキュリティグループ(Test-SG)のイベントタイムラインを確認
インバウンドルールが削除され、準拠状態になっていることが分かります。
■8-13. 項番7-8で指定したメールアドレス宛にセキュリティグループのルール変更(非準拠->準拠)に伴う通知が届いていないことを確認
「非準拠」から「準拠」への切り替えは、EventBridgeのルールで指定した内容に当てはまらないため通知は送信されません。
■8-14. 対象セキュリティグループ(Test-SG)を「準拠リソース」から「非準拠リソース」へと設定変更
■8-15. 項番7-8で指定したメールアドレス宛にセキュリティグループのルール変更(準拠->非準拠)に伴う通知が届いていることを確認
■8-16. 通知されたメールを確認し、設定変更したセキュリティグループが「NON_COMPLIANT」判定された通知であることを確認
本通知メールの内容は項番8-6の「テンプレート」に記載した内容であることが分かります。
個人的にはこの状態の方が項番7-20で確認した通知メールの内容(JSON形式)よりも内容の把握がしやすいように思うので、適切に活用していければと思います。
調べたこと
ここからは僕が作業中に疑問に思ったことや調べた内容について、備忘録的に書いていこうと思います。
初歩的な内容も多いかもしれませんがご了承ください・・・。
1. AWS Config関連
本項では、AWS Config関連の疑問や調べたことを整理していきます。
1-1. AWS Configの1-Clickセットアップで作成される「AWS Configロール」とは？
1-Clickセットアップ機能でAWS Configを設定したところ、以下のロールが設定されていました。
AWS Configロール名：AWSServiceRoleForConfig
これはどうやらAWS Config用のIAMロールのようで、試しにIAMロールの検索画面で検索してみたら同じ名前のIAMロールがありました。
このロールには「AWSConfigServiceRolePolicy」というIAMポリシーがアタッチされていました。
このポリシーには非常に多くのAWSサービスへのアクセス許可設定が入っており、加えてログの作成および格納に関する記述もありました。
公式説明としては以下の用途である記述がありました。
AWSServiceRoleForConfig ロールのアクセス許可ポリシーには、AWS Config リソースに対する読み取り専用と書き込み専用のアクセス許可と、AWS Config がサポートする他のサービスのリソースへの読み取り専用のアクセス許可が含まれます。
詳細については、「サポートされているリソースタイプ」を参照してください。
1-2. AWS Configの情報をSNSで配信する方法は？
本記事の作業を実施する前に「やってみたいこと」の1つとして「AWS Configの情報をSNSで配信したい」がありました。
実装方法を調べる中で先に見つけた方法としては、本記事内でも実施している「EventBridge」と連携した方法でした。
しかし、AWS Configの「設定」からConfigに紐付いたSNSトピックを作成して配信する方法があることを発見しました。
ただし、この方法だと「ルールに違反したものを送付」というよりもConfigで記録した変更履歴を軒並み送付する感じに近いということが判明。
EC2インスタンスを新規作成しただけでもそれに関連する内容で5通ほどメールが飛んできました。
よくよく設定画面を確認してみると「Eメールにすると大量に飛ぶかも」という旨の説明文が記載されていました。
1-3. 配信方法の設定時にS3バケットを設定する理由は？
正直、Eメール送付だけならS3バケットの設定は必要ないのでは？と思いながら作業をしていました。
しかし、改めて振り返ってみると、AWS Configの初期設定時点でS3バケットの設定を実施していたことが分かりました。
AWS ConfigのGUIでの初期設定方法には「今すぐ始める」「1-Click セットアップ」の2パターンがありますが、どちらも「配信方法」の設定としてS3バケットの項目がありました。
こうなると、AWS Configを利用する上でS3バケットの存在は「必須」であることが分かります。
ちなみに「1-Clickセットアップ」の場合には、S3バケットを指定することはできずに固定で、上記画像にあるような「config-bucket-AWSアカウントID」という名前のバケットを自動作成して利用するみたいです。
ところで、S3バケットには何が保存されるのでしょうか・・・？
公式設定手順に以下の内容が記載されていました。
[Delivery method] (配信方法) では、AWS Config から設定履歴と設定スナップショットのファイルを送信する先の S3 バケットを選択します。
参考：AWS Config 手動セットアップ
「設定スナップショット」はAWS Configの利用用途によってまちまちだと思いますが、「設定履歴」に関してはAWS Configとして必須の要素ですね。
本記事の作業内で「リソースタイムラインの確認」なども行いましたが、おそらくこれらのデータもS3バケットに格納されたものを利用していると考えられます。
なお、設定履歴のデータに関してはS3バケット内の以下のパスに保存されていました。
設定履歴格納パス
バケット -> AWSLogs -> AWSアカウントID -> Config -> リージョン名 -> YYYY -> MM -> DD -> ConfigHistory
1-4. S3バケットに保存される「ConfigWritabilityCheckFile」とは？
AWS Configに関するデータの配信先として指定したS3バケットには、「設定履歴データ」の他に「ConfigWritabilityCheckFile」という謎のデータも保存されていました。
このファイルに関する公式説明として以下の内容を発見しました。
S3 バケットには、ConfigWritabilityCheckFileという空のファイルも含まれています。AWS Config では、このファイルを作成してサービスによる S3 バケットへの正常な書き込みを検証します。
参考：Amazon S3バケットの設定スナップショットの表示
なるほどですね。
S3への書き込み検証用として利用されていることが分かりました。
1-5. 修復アクションとは？
修復アクションは、AWS Configのルールにおいて「非準拠リソース」として認識されているリソースを修復するもの。
その動作の実態としてはAWS Systems ManagerのAutomation機能が利用されていることが分かりました。
なお、修復アクションは「手動」または「自動」を選択することができます。
参考：AWS Config ルールによる非準拠リソースの修復
1-6. 修復アクションとして実行された「RevokeSecurityGroupIngress」とは？
修復アクションの実行後、対象リソースのタイムラインにて「RevokeSecurityGroupIngress」というCloudTrailイベントが記録されていました。
セキュリティグループの操作説明として以下の内容がありました。
ec2:RevokeSecurityGroupIngress: 既存のインバウンドルールを変更または削除します。
参考：Amazon EC2 コンソールで機能するサンプル ポリシー
今回確認した動作の通りではありますが、インバウンドルールを削除するという内容で間違いなさそうです。
2. EventBridge関連
本項では、EventBridge関連の疑問や調べたことを整理していきます。
2-1. EventBridgeってどんなもの？
イベントを通じてさまざまなアプリケーション同士を簡単に接続できるようにするサービス。
同じようなサービスに「Cloudwatch Events」がありますが、EventBridgeはCloudwatch Eventsをベースに構築されていることからより使いやすくなっているとのこと。
EventBridgeでは、AWS以外のSaaSサービスなどとも連携できるという部分が大きな違いである模様。
参考：【徹底解説】Amazon EventBridgeとは？
Event Bus
EventBridgeに届くすべてのイベントは、イベントバスに関連付けられる。
以下3種類がある。
・Default Event Bus
・Custom Event Bus：別のAWSアカウントとの間でイベントの送受信などに利用できる
・Partner Event Bus：AWS以外のSaaSサービス経由で利用できる
イベントバスのアクセス許可を管理するには、そのイベントバスにリソースベースのポリシーを設定する。
Event
AWS環境、SaaSパートナーサービスやアプリケーション、または自アプリケーションやサービスなどでの環境変化のことを指す。
イベントはJSONオブジェクトとして表現され、同じような構造をしている。
イベントには主に以下のフィールドがある。
■version
デフォルトは全イベントで「0」に設定される
■id
イベント毎に生成されるUUID
■detail-type
sourceフィールドと組み合わせてdetailフィールドに表示されるフィールドと値を識別する
■source
イベントを発生させたサービスを識別する
AWSサービスからのイベントは全て「AWS」から始まる
■account
AWSアカウントを識別する12桁の数字
■time
イベントを発生したサービスによって指定できるイベントのタイムスタンプ
■region
イベントが発生したAWSリージョンを識別する
■resources
JSON形式でイベントに関わるリソースを識別するARNが格納される
■detail
イベントに関わる情報を含むJSONオブジェクト
Rule
イベントをターゲットにルーティングするためのルール。
イベントバスに紐付き、イベントの検出パターンの定義やターゲット（どのターゲットにイベントを転送するか）の定義を記載する。
ターゲットに応じてIAMロールが必要になる。
Target
ルールに定義されたイベントパターンにイベントがマッチした際に、EventBridgeがイベントを送信する先のリソースまたはエンドポイントのこと。
ルールによってイベントデータが処理された後、関連情報をターゲットに送信する
イベントデータをターゲットに配信するためには、EventBridgeがターゲットリソースにアクセスするための許可が必要
2-2. ターゲット入力トランスフォーマーとは？
「入力パス」と「テンプレート」に必要情報を記載したが、実際に何をしているものなのか。
前者で変数の定義をして、後者で変数を利用しながら実際に送付するメールの文面を設定している感じなのだろうか？
調べてみると、入力パスの内容はEventBridgeに送られてきたJSON形式のログイベントから特定の値を変数として抽出する役割がありました。
たとえば、「"awsAccountId": "$.detail.awsAccountId"」では「$.detail.awsAccountId」という記述により送られてきたデータからAWSアカウントIDを抽出し、その値を変数「awsAccountId」に代入するという流れになる。
また、テンプレートでは実際にメール通知する際の文面を設定しています。
入力パスで定義した変数をテンプレート内で利用することも可能。
参考：EventBridgeの入力トランスフォーマーでSNSのメール通知内容を整形してみた
参考：Amazon EventBridge 入力変換の例
おわりに
いかがだったでしょうか。
今回はAWS Configを用いたAWSリソースの設定変更履歴の追跡や評価、そしてSNSやEventBridgeを用いた通知についてチャレンジしました。
もともとはAWS Configの基本操作を少し練習するくらいのつもりでしたが、「通知もしてみたい」という欲からSNSやEventBridgeの練習もできたので良かったです。
EventBridgeに関しては全く触ったことがなかったので、こんな感じで使うのかと僕自身勉強になりました。
今後もいろいろな技術に触れて、少しずつでも発信していければなと思います。
次はAWSで何をしてみよう？：)
本記事を最後まで読んでいただき、ありがとうございました。
ではでは！