COLUMN

AWSリソースの設定変更履歴を管理する「AWS Config」とは？実際に使用してみた

AWSリソースの設定を「いつ」、「だれが」、「どのように」変更したのか確認したいタイミングがあります。
そんなときに使用したいのがAWS Configです。
AWS Configを利用することで、AWSリソースの設定を記録し、設定の変更や他のリソースとの依存関係が時間経過とともに確認できます。
当コラムではAWS Configの簡単な説明と、実際の利用例を紹介します。

こちらのコラム「AWS Config でAWSリソースやソフトウェアの設定履歴を保存し、コンプライアンス対策やセキュリティの強化を！」ではAWS Configの活用方法を紹介しています。
是非ご確認ください。

AWS Configとは？

AWS ConfigはEC2、EBS、セキュリティグループ、VPCなどのAWSリソース(※)の設定を評価、監査、審査できるサービスです。
AWSリソースの設定変更の記録を行い、その設定に対し問題がないか確認し、問題がある場合はメール通知や修正対応ができます。
※AWS Config がサポートする AWS リソースの詳細は以下を参照してください。

リンク：AWS Config でサポートされている AWS リソースタイプとリソース関係

また、料金については以下を参照してください。
リンク：https://aws.amazon.com/jp/config/pricing/

どのようなことができる？

では、実際にどのようなことができるのかを紹介します。

リソースの管理

AWS Configではサポートしている各リソースに対し、常に監視を行っています。
リソースの作成、変更、削除が行われるとAWS SNSトピックやAWS Cloudwatch Eventsを通じて通知が行われます。これにより、変更に対するモニタリングを行う必要が無くなります。
また、AWS Configが提供するルールにより、リソース設定の評価を行うことができます。
※AWS Configのルールは予め用意されたルールと自身で作成できるカスタムルールが存在します。
定義されたルールの一覧はこちらです。

監査とコンプライアンス

AWSリソースがプロジェクトのポリシーやベストプラクティスに準拠していることを確認するために監査が必要となる場合があります。
AWS Configでプロジェクトのポリシーやベストプラクティスをルールとして設定し、AWSリソースのコンプライアンスへの準拠状況を確認することができます。
ルールを使用し、コンプライアンスに違反しているリソースが検出されると、違反したリソースに非準拠のフラグが付けられます。
※非準拠のフラグの例

設定変更の管理とトラブルシューティング

１つのリソースへの設定変更が、関連する他のリソースに予期せぬ影響を与える場合があります。
あるリソースの変更によって、関連する他のリソースへの影響が発生した場合、AWS Configによって変更前の状態を確認して元の設定値に修正することができます。
例えば、セキュリティグループの設定を変更した影響としてインスタンスへアクセスできなくなってしまった場合、AWS Configでセキュリティグループの設定変更履歴から元の設定値を確認し、誤った変更を手動で修正できます。
また、ルールに従って非準拠のセキュリティグループを自動で修正する事も可能です。

セキュリティ分析

セキュリティの潜在的な脆弱性を分析するには、ユーザーに付与されているIAMアクセス許可や、リソースへのアクセスを制御するセキュリティグループのルールなど、AWS リソースの設定に関する詳細な履歴情報が必要になります。

AWS Config で記録していた期間内であれば、IAM のユーザー、グループ、またはロールに割り当てられた IAM ポリシーを確認できます。
この情報に基づいて、特定の時間にユーザーに付与していたアクセス権限を確認できます。
例えば、ユーザーAが 201X年X月X日にVPC設定を変更するアクセス権限を持っていたかどうかを確認できます。
また、特定の時間に開いていたポートのルールなど、セキュリティグループの設定を確認することもできます。
この情報により、特定のポートに着信するTCPトラフィックをセキュリティグループの設定が原因でブロックしていたのかどうかを判断できます。

利用例

ひとつ目の例として、ルールに準拠してないセキュリティグループの設定を評価し、修正を行い、ルールに準拠するまでを確認します。

以下の手順に沿って行います。
1.設定
2.ルール
3.確認

※デザインが一新されたコンソールではなく旧コンソールを使用しています。

１．設定

左側にあるメニューの「設定」をクリックします。

記録

まずAWSリソースの変更路歴のログを収集するために、記録の「オンにする」をクリックします。

「記録はオン」に切り替わりました。

記録するリソースタイプ

セキュリティグループとインスタンスのログを30日間記録するように設定を行います。
特定の型へは、「EC2 Instance」、「EC2 SecurityGroup」を選択します。
データの保持期間へは、「AWS Configで記録された設定項目のカスタム保持期間を設定します」にチェックし、「カスタム」を選択し、「30」を入力します。

Amazon S3 バケット

設定変更履歴の保存先を設定します。今回は作成済みのS3を使用しますが、新たに作成することもできます。
「アカウントからバケットを選択」を選択し、S3バケット名を選択します。

Amazon SNS トピック

今回はリソースの変更時に通知を行うAmazon SNS トピックは使用しませんのでチェックは行いません。

Amazon CloudWatch Events ルール

今回はAmazon CloudWatch Eventsも使用しません。
使用する場合はAmazon CloudWatch Eventsのコンソールでルール作成ページアクセスします。

Amazon Configロール

AWS ConfigにS3 バケットへのアクセスを許可するロールを付与します。
「既存のAWS Configサービスにリンクされたロールを使用」を選択します。

右下の「保存」をクリックします。

保存後、以下の画面になります。

2．ルール

今回は、SSH全開放の設定をしているセキュリティグループを検知するルール追加します。

ルールを追加

評価結果確認

画面左側にある「ルール」をクリックします。

「ルールを追加」をクリックします。

ルールを追加

「ssh」を入力し、候補の「restricted-ssh」をクリックします。

「restricted-ssh」はAmazonで定義されたルールであり、SSH全開放の設定がされているセキュリティグループを検知します。既にルールが定義されているため変更せず「保存」をクリックします。

以下のように追加されました。

評価結果確認

ルール追加後、自動で評価が行われます。数分後にページの更新を行うとコンプライアンス欄に結果が表示されます。

「restricted-ssh」をクリックします。

ルールの詳細が表示され、対象のリソースを選択の欄にルールで評価されたセキュリティグループの結果が表示されます。
結果が非準拠であるリソースIDをクリックします。

リソースの詳細が表示されます。設定を変更するため、「リソースの管理」をクリックしEC2セキュリティグループ一覧へ移動します。

該当の設定が絞り込み検索されていますので、「セキュリティグループ」をクリックします。

SSHアクセスのソースIPアドレスとして「全開放の設定（以下1、3行目）」と「特定のみのIPを許可する設定（以下２行目）」が存在しているため、「インバウンドルールの編集」をクリックし、編集画面で「全開放の設定」のレコードを削除します。アウトバウンドも同様に「全開放の設定」を削除します。

「特定のみのIPを許可する設定」のみになりました。

AWS Configのルールに移動し「restricted-ssh」で再評価をクリックします。

先ほどのリソースに移動します。準拠になっていることが確認できます。

検証中などに誤ってEC2インスタンスが突如削除されてしまったというケースは存在すると思います。
ふたつ目の例として、AWS Configの変更履歴から削除されたインスタンスを「いつ」「誰が」削除したのか確認してみましょう。

AWS Configのダッシュボードで「EC2 Instance」をクリックします。

削除されたリソースを含めるにチェックし、「検索」をクリックします。

削除されたリソースをクリックします。

設定タイムラインをクリックします。

このタイムラインでリソースを変更した履歴を時系列で確認できます。
インスタンスが削除されたタイミングを確認するため、最後のタイムラインの「イベント」をクリックします。

サーバーの削除イベントである「TerminateInstances」より、削除日時およびユーザー名が確認できました。

おわりに

プロジェクトが定めたセキュリティルールに従ってシステムを運用するために、AWSconfigは強力なツールとなります。いざというときのためのトラブルシューティングまたはコンプライアンス状況監視ツールとして、AWS Configの記録を「オン」にし、サービスを有効活用しましょう。