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リソースのコンプライアンスへの準拠状況を確認することができます。
ルールを使用し、コンプライアンスに違反しているリソースが検出されると、違反したリソースに非準拠のフラグが付けられます。
※非準拠のフラグの例

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

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

セキュリティ分析

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

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

利用例

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

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

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

1.設定

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

記録

まず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を許可する設定(以下2行目)」が存在しているため、「インバウンドルールの編集」をクリックし、編集画面で「全開放の設定」のレコードを削除します。アウトバウンドも同様に「全開放の設定」を削除します。

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

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

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

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

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

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

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

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

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

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

おわりに

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

24時間365日対応可能なクラウド監視・運用代行で、あなたをシステム運用から解放します!

クラウドの導入・運用に関する
ご相談、お問い合わせをお待ちしております。

無料ダウンロード

自社のクラウド導入に必要な知識、ポイントを
このに総まとめ!

あなたはクラウド化の
何の情報を知りたいですか?

  • そもそも自社は本当にクラウド化すべき?オンプレとクラウドの違いは?
  • 【AWS・Azure・Google Cloud】
    どれが自社に最もマッチするの?
  • 情シス担当者の負荷を減らしてコストを軽減するクラウド化のポイントは?
  • 自社のクラウド導入を実現するまでの具体的な流れ・検討する順番は?

初めての自社クラウド導入、
わからないことが多く困ってしまいますよね。

NTT東日本では
そんなあなたにクラウド導入に必要な情報を

1冊の冊子にまとめました!

クラウド化のポイントを知らずに導入を進めると、以下のような事になってしまうことも・・・

  • システムインフラの維持にかかるトータルコストがあまり変わらない。。
  • 情シス担当者の負担が減らない。。
  • セキュリティ性・速度など、クラウド期待する効果を十分に享受できない。。
理想的なクラウド環境を実現するためにも、
最低限の4つのポイントを
抑えておきたいところです。
  • そもそも”クラウド化”とは?
    その本質的なメリット・デメリット
  • 自社にとって
    最適なクラウド環境構築のポイント
  • コストを抑えるため
    具体的なコツ
  • 既存環境からスムーズにクラウド化
    実現するためのロードマップ

など、この1冊だけで自社のクラウド化のポイントが簡単に理解できます。
またNTT東日本でクラウド化を実現し
問題を解決した事例や、
導入サポートサービスも掲載しているので、
ぜひダウンロードして読んでみてください。

クラウドのわからない・
面倒でお困りのあなたへ

クラウドのご相談できます!
無料オンライン相談窓口

NTT東日本なら貴社のクラウド導入設計から
ネットワーク環境構築・セキュリティ・運用まで
”ワンストップ支援”が可能です!

NTT東日本が選ばれる5つの理由

  • クラウド導入を
    0からワンストップでサポート可能!
  • 全体最適におけるコスト効率・業務効率の改善
    中立的にご提案
  • クラウド環境に問題がないか、
    第3者目線でチェック
    してもらいたい
  • 安心の24時間・365日の対応・保守
  • NTT東日本が保有する豊富なサービスの組み合わせで
    ”課題解決”と”コスト軽減”を両立

特に以下に当てはまる方はお気軽に
ご相談ください。

  • さまざまな種類やクラウド提供事業者があってどれが自社に適切かわからない
  • オンプレミスのままがよいのか、クラウド移行すべきなのか、迷っている
  • オンプレミスとクラウド移行した際のコスト比較を行いたい
  • AWSとAzure、どちらのクラウドが自社に適切かわからない
  • クラウド環境に問題がないか、第3者目線でチェックしてもらいたい
  • クラウド利用中、ネットワークの速度が遅くて業務に支障がでている

クラウドを熟知するプロが、クラウド導入におけるお客さまのLAN 環境や接続ネットワーク、
クラウドサービスまでトータルにお客さまのお悩みや課題の解決をサポートします。

相談無料!プロが中立的にアドバイスいたします

クラウド・AWS・Azureでお困りの方はお気軽にご相談ください。

ページ上部へ戻る