AWS環境のセキュリティ対策を見直そう（ログ/サイバー攻撃編）

皆さん、アマゾン ウェブ サービス（以降、AWS）環境のセキュリティ対策を後回しにしていませんか？

近年AWSをはじめとするクラウドサービスの導入が進む一方で、設定ミスや運用管理の甘さによる情報漏洩のリスクも高まっています。

前回の記事では、AWSにおけるセキュリティ対策として、一般的なセキュリティ概念である「予防的統制」と「発見的統制」をAWSにどのように適用するか、そしてそのうちの「予防的統制」に関する具体的な対応策をご紹介しました。

今回は「発見的統制」に焦点を当て、ログ管理とサイバー攻撃対策にどのように対応すべきかを解説します。

発見的統制の一つ目の対応策として、ログ管理について解説します。
　

ログを確認することで、「誰が・いつ・どのリソースに・どんな操作をしたか」を把握できるため、不正アクセスの検知やトラブル発生時の原因特定がしやすくなります。そのため、該当のログを正確に収集・管理することは非常に重要です。

ここからは、ログ管理の具体的な内容として「ログの収集と保存」と「ログの分析と活用」の2点を焦点に挙げて説明します。

ログの収集と保存は、セキュリティ運用をするうえでまず初めに実施するべきです。誰がどのリソースに対して、どんな操作を行ったかを記録することで、万一のトラブル時にも原因を特定しやすくなります。

トラブル発生に備えて保存すべきログは主に以下です。

その他、OS、アプリケーション、ネットワークなど各種ログがあります。

特に、後々証跡として利用が可能なクラウド環境へのアクセスログや操作ログの保存は欠かせません。こういったログを取得するAWSサービスとして、AWS CloudTrailやAWS Configといったサービスを利用できます。

AWS CloudTrailは、AWSアカウントでのAPIコールを記録するサービスです。誰がどんな操作をしたのかを把握できるため、設定変更や異常な操作の追跡が可能になります。例えば、重要なリソースの設定が変更された場合も、誰の操作によって実施されたかすぐに特定できます。

AWS Configは、AWSリソースの設定変更を記録し、その設定がルールに合っているかチェックするサービスです。例えば、「セキュリティグループは特定のルールに従うべき」といったポリシーを設定しておけば、そのルールに反する設定変更があった際に通知を受け取ることができます。

CloudTrailとConfigは有効化自体は簡単にできますので、有効化されていない方はすぐに実施ください。

ログはただ収集・保存するだけではなく、「分析と活用」を実施することが非常に重要です。
操作履歴や構成変更の記録をもとに、不正アクセスや誤操作の兆候を早期に検知し、素早い対応につなげることができます。

ログの分析や活用ができるAWSサービスとして、CloudWatch Logsを紹介します。

Amazon CloudWatch Logsは、アプリケーションやAWSサービスからのログデータを収集・保存し、モニタリングやアラート、ダッシュボード表示に活用できるサービスです。システムやアプリケーションのログを一元的に管理できるため、インフラとアプリ両方の動作状況を確認しやすくなります。
前の章でご紹介したCloudTrailやConfigのログも、CloudWatch Logsに出力しておけば、可視化や監視の対象にできます。
例えば、S3バケットの削除操作を検知したり、セキュリティやコンプライアンス対応に役立てることが可能です。

CloudWatch Logsのログクエリの実行結果イメージは以下になります。独自のクエリ言語を用いて、必要な情報を出力することができます。

【CloudWatch Logs ログクエリ実行結果 イメージ】

簡単に出力できる一方、以下のようなお声もいただくケースがあります。

上記ニーズに対応するには、サードパーティ製品の導入もよいでしょう。

例えば、Logstorageという製品では、上記のAWSサービスでは実現できない以下の機能を有しています。

続いて、サイバー攻撃についてです。

サイバー攻撃とは、ネットワークやシステムへの不正侵入・破壊などを目的とした不正行為です。フィッシングやランサムウェアなどが代表例で、企業にとって事業継続の脅威となります。

こうした攻撃に対しては、早期検知と迅速な対応がカギになります。ここからは具体的な対策方法として「脅威検知サービスの利用」と「多層防御の実施」の2点を説明します。

近年は、AIや機械学習を活用した自動脅威検知が主流です。ネットワークやシステム内の異常をリアルタイムで把握し、不正アクセスや内部不正、マルウェアを早期に検出できます。

AWSでは、こうした脅威検知を実現するためのサービスとしてAmazon GuardDutyを提供しています。

Amazon GuardDutyは、AWS上のログやネットワーク動作を分析し、潜在的な脅威を自動で検出するサービスです。

本サービスは、ワンクリックで簡単に有効化でき、すぐに利用を開始できます。

また、GuardDutyでは、必要に応じて『Malware Protection』という追加機能も利用可能です(有償オプション)。

この機能を活用することで、Amazon S3やAmazon EC2、Amazon EBSなどのリソースに対してマルウェアの脅威をより詳細に検出・対処することが可能になります。例えば、EC2にダウンロードされた不正なスクリプトや、S3にアップロードされたウイルス付きファイルの検出などが可能です。

ログやネットワーク動作を元にした検知よりも高レベルの対応をしたい場合、本機能の利用をご検討下さい。

複数レイヤーにおける防御（多層防御）は、サイバー攻撃に対する備えとして有効です。ネットワーク、アプリケーション、エンドポイントといった複数のレイヤーに防御策を講じることで、一つの防御層が突破された場合でも、他の層で機能を食い止められます。

多層防御の構成要素は主に以下です。

今回は対応策の一部である、AWS ShieldとAmazon Inspectorをお伝えします。

AWS Shieldは、AWSリソースをDDoS攻撃から保護するためのサービスです。AWS環境ではデフォルトでStandardプランが有効化されており、基本的なDDoS防御は機能しています。より高度な保護が必要な場合は、有料のAdvancedプランを選択できます。

プランの簡易表

Amazon Inspectorは、EC2やコンテナ、Lambda関数の脆弱性や不適切な設定を自動で検出するサービスです。CVEや、PCI DSS等のセキュリティ基準に基づいたチェックが可能です。また、結果はInspectorのダッシュボードに表示されます。

以下が検出結果のイメージです。画面右にあるように「緊急度の高い脆弱性」が即座に分かるなどといった使いやすいデザインです。こういった結果を元に、パッチ適用などのアクションにつなげることが可能になります。

【Inspector 検出結果 イメージ】

Inspectorは、リソース単位でセキュリティ状況を把握するのに効果的です。
一方で、複数のクラウド環境、オンプレミスをまとめて管理したい場合は、サードパーティ製品の検討も推奨します。例えば、「Tenable」は複数の環境を一元管理できる脆弱性管理ツールとして有効です。

Tenableの詳細はこちら
https://www.ashisuto.co.jp/product/category/vulnerability-management/tenable/

いかがでしたでしょうか？

AWSのセキュリティ対策は、「予防」と「発見」の両方を意識した設計がカギです。
本記事では「発見的統制」に着目して、ログの活用とサイバー攻撃への備えをご紹介しました。改めて自社環境を見直すきっかけとして、ぜひご活用ください。