はじめに

初めまして、新入社員の小林です。クラウド事業推進部に配属され、約半年が経過しました。
配属されるまでは、AWSについての知識が一切なく不安でしたが、心強い先輩方の助けもあり何とか今までやってこれています。
現在は、主に保守・運用をメインに業務をしています。
今回は、AWSでの運用を行う上で活躍するAWS Config（以下、Config）を活用し、セキュリティ通知や自動修復機能を実装する際のポイントについて記載したいと思います。

Configでできること

Configでは、AWSサービス（EC2，S3，IAM etc...）の構成情報を取得し、設定状況やリソースの構成を詳細に把握・可視化します。
一部、AWSサービスの種類やリージョンによってはサポートされていないリソースが存在するため、詳細については公式ドキュメントを参照してください。

▼Configでサポートされているリソースタイプ docs.aws.amazon.com

Configは主に以下の役割があります。

リソースの記録
リソースの評価

リソースの記録

Configの管理レコーダーを使用することでConfigにAWSサービスの構成情報を記録することができます。
デフォルトでは、グローバル IAM リソースタイプを除く、サポートされているすべてのリソースタイプを記録します。
リソースの記録方法は2つあります。

記録方法	説明
継続的な記録	変更が発生するたびに設定の変更を継続的に記録する
日時記録	以前に記録された設定項目と異なる場合にのみ、過去 24 時間におけるリソースの最新の状態を表す設定項目を受け取る

リソースの評価

Configルールを設定することにより、Configに記録されているリソースを評価します。
Configルールには、AWSによって定義済みであり簡易的なカスタマイズが可能なマネージドルールと、1から自分で定義するカスタムルールが存在します。
リソースが評価されると、ルールに適合しているか否かを表す「COMPLIANT(準拠)」、「 NON_COMPLIANT（非準拠）」の評価結果を返します。
Configによるリソースの評価数はコストとも密接に関わってくるため、リソースの記録設定を調整することもConfigを有効に活用するポイントになります。
Configの利用料は以下を参照してください。

▼Configの料金 aws.amazon.com

通知を実装しよう

Configでは、上記のようにリソースの記録を行い、評価が行われます。これらの記録の結果はConfigのダッシュボードからも確認が可能ですが、毎回検知結果を確認するのは大変です。そして、毎日膨大な量のAWSリソースがチェック・検知されるため、どのリソースから対処していくべきかを判断することも大変です。

その際には、Configの検知結果をSlackやメールに通知することによって、自分でマネジメントコンソールで検知結果を確認する手間を省くことができます。

また、検知の対処を効率的に行うために、Configの通知を行う際にはAWS Security Hub Cloud Security Posture Management（以下、Security Hub CSPM）の検知結果を通して行いましょう。
Security Hub CSPMから通知を行う理由として、大量通知を防ぐこと、リソースの修復対応の優先順位を明確にすることの2点が挙げられます。

Security Hub CSPMは、AWS のセキュリティ状態を包括的に把握し、最も優先度の高いセキュリティ問題を特定することが可能なサービスです。複数のセキュリティサービスの検知結果を集約でき、AWSのベストプラクティスなセキュリティ基準にしたがって各サービスの検知の重大度を示します。
そのため、Security Hub CSPMを使うことで、大量に検知されるConfigの検知に対して重大度の高い検知のみに絞って通知することができ、自分で対応の優先度を考える手間を最小限にすることができます。

ConfigおよびSecurity Hub CSPMを利用した通知機能の構成図の例がこちらになります。

この構成図での通知の流れは以下の通りです。

Configの検知結果をSecurity Hub CSPMに集約する
Amazon EventBridge（以下、EventBridge）で上記のイベントを検知し、AWS Lambda（以下、Lambda）を起動する
Lambdaでユーザーへの通知処理を行う

自動修復機能を実装しよう

Configを導入する目的は非準拠リソースを検知して、脆弱な設定がされたAWSリソースがAWS環境内に残存しないようにすることです。 Configによる検知と通知の仕組みだけでは、通知を受け取ったユーザーが AWS リソースの設定変更や修正まで確実に実施できず、結果として問題のあるAWSリソースが環境内に残り続けてしまうケースがあります。
この問題を解決するために、特定の脆弱なリソースが作成された場合に自動修復できる仕組みを導入する必要があります。

その際に有効的なのがConfigの自動修復機能です。自動修復機能を導入するには、Lambdaを使用して非準拠リソースを修復する方法と、AWS Systems Manager Automation（以下、SSM Automation）とConfigのマネージドな修復アクションを組み合わせて修復を実装する方法の2つがあります。

今回例としてあげている構成図は、「一定期間ローテーションのされていないアクセスキーを無効化する」ための機能を実装したものです。
アクセスキーとは、IAMユーザーの長期的な認証情報です。アクセスキーが漏洩してしまうと大きなセキュリティリスクが生じてしまうため、徹底した管理が必要です。そのため、定期的にアクセスキーのローテーションを行い、新しいものに更新することを推奨しています。
長期間ローテーションされずに放置されているアクセスキーは情報漏洩の原因となるため、自動で無効化するように仕組みを作ります。

2つの方法の違いについて図を用いて確認してみましょう。

Lambdaを用いた自動修復機能

構成図で示している処理の流れは以下の通りです。

Configマネージドルールの【access-keys-rotated】で非準拠リソースが検知される
非準拠の検知イベントをEventBridgeでキャッチする
EventBridgeをトリガーに設定したLambdaが起動する
アクセスキーを無効化する処理と処理結果をAmazon Simple Notification Service（以下、SNS）に送信し、通知する処理が行われる

SSM Automation + Configの修復アクションを用いた自動修復機能

構成図で示している処理の流れは以下の通りです。

Configマネージドルールの【access-keys-rotated】で非準拠リソースが検知される
SSM Automationで【修復アクション】に設定したAutomationドキュメントがアクセスキーを無効化する
アクセスキーが無効化されたイベントをEventBridgeでキャッチする
EventBridgeの入力トランスフォーマー機能を使用し、SNS通知を行う

上記の構成ではLambdaを使用することなく、EventBridgeとSNSのみで通知機能を実装しています。
EventBridgeの入力トランスフォーマー機能は、EventBridgeがSNSに検知イベントを渡す前にJSON形式のイベント内容を読みやすいJSON形式のイベントに変更することができます。この機能を活用することにより、Lambdaを使用しない実装を行うことができるため、我々の手で管理する負担を減らすことができます。
簡単な通知の実装や処理は、Lambdaを使わずに実装できないかを考えてみましょう。

2つの自動修復機能の比較

2つの方法の違いを次の表で比較します。

	管理	開発方法	料金
Lambda	ランタイムの更新などの管理が必要	Python等のおなじみの言語で開発可能	約 0.000012USD/1実行
SSM Automation + 修復アクション	Lambdaのようにランタイム更新など定期的な運用は発生しない	SSM Automationを使用したYAML,JSONコードでの開発or ワークフロー形式での開発	0.002USD/1ステップ

Lambdaを使用した方法は、細かい分岐を設定したい場合に向いており、使い慣れた言語で実装する点が利点だと感じています。
また、SSM Automationを使用した方法は、ランタイム更新の必要性が無い点や、拡張性が高く、ワークフロー形式でオートメーションを作成できるため、視覚的にわかりやすい実装ができる点にメリットがあると感じました。

おわりに

いかがでしたか？
Configなどのセキュリティに関するAWSサービスはアップデートも多いため、機能をフル活用して便利な運用に切り替えていくには学習の継続が必要だと痛感しています。まだまだ勉強中の駆け出しエンジニアですが、AWSサービスの活用の幅を広げていくことでAWSの運用を楽にしていきたいです。