AWS活用で実現する多層防御 中堅・中小企業よセキュリティ対策をあきらめるな：セキュリティ対策としてのAWS移行のススメ（2/2 ページ）

[濱田一成，ITmedia]

AWSによる高度な「検知」機能の実現

　基盤にAWSを採用したシステムは、従来と比べてはるかに柔軟なキャパシティー（コンピューティングリソースやメモリ、ストレージなどの容量）を持っている。AWSのサーバやストレージは必要な分だけリソースを用意できるため、「検知」機能のデータを扱うのに最適だ。

　例えばオブジェクトストレージサービス「Amazon Simple Storage Service」（Amazon S3）であれば、保存容量は無制限で、必要なだけデータを保管できる。ML（機械学習）や予測分析の精度はデータ量の多さに比例することから、データを蓄積すればするほど「検知」機能の精度は高まる。

　コンピューティングサービスの「Amazon Elastic Compute Cloud」（Amazon EC2）や「AWS Lambda」は、データ処理に必要なだけのコンピューティングリソースを自由に確保できるため、ログ分析の基盤に最適だ。

　オンプレミスやクラウドに関係なく、稼働しているシステムは常に膨大なデータを生成している。これらを取捨選択することなく全て検知に活用できるのはキャパシティーが柔軟なクラウドならではの強みだ。

　ここまで「検知」機能の課題と解決方法をキャパシティーの観点から説明した。残る課題は人手や学習コストに関わる人的リソースだが、AWSのサービスを活用すればこれも解決できる可能性が高まる。

　ここでは脅威検知サービスである「Amazon GuardDuty」（以下、GuardDuty）と、フォレンジック調査を支援する「Amazon Detective」について解説する。

AWS運用に必須のサービス　Amazon GuardDutyは何ができる？

　GuardDutyはAWSのさまざまな情報を分析し、AWSアカウントへの攻撃を発見する脅威検知サービスだ。データの取り込み設定などの専門知識は不要で、コンソールからサービスを有効化するだけで利用できる。以下はGuardDutyのダッシュボードだ。

Amazon GuardDutyのダッシュボード例（出典：ソニービズネットワークス作成）

　検知結果はもちろん、検知の傾向や関連するリソースも一覧で確認できる。検知できる脅威の例には以下のようなものがある。

• AWSのサーバの不審な振る舞い
• AWSアカウントに対しての侵害

　「AWSのサーバの不審な振る舞い」とは、不審なアドレスへの通信や他サーバへの大量の通信などを指す。一般的にマルウェアに感染したサーバはC&Cサーバ（botに指令を出すための指令サーバ）や攻撃対象のサーバと通信しようとする。

　GuardDutyは継続的にログを分析し、AWSの脅威インテリジェンスに登録されている悪意あるアドレスやドメインに明らかに異常な量の通信を検知した場合、脅威と判定する。

　GuardDutyが“真価”を発揮するのが「AWSアカウントに対しての侵害」だ。連載第1回でAWSの「責任共有モデル」を解説したが、AWSのセキュリティ対策を検討する上で忘れてはならないレイヤーがAWSアカウント自体のセキュリティだ（下図の赤枠部分）。

AWSの責任共有モデル+α（出典：ソニービズネットワークス作成）

　サーバの不審な振る舞いについては、UTM（統合脅威管理）などのセキュリティアプライアンスを置きトラフィックを監視することで検知できるだろう。しかし、AWSアカウント自体への脅威をGuardDuty以外のソリューションで検知することは困難だ。他では代替出来ないという理由から、GuardDutyはAWSを利用する際の必須サービスとされる。

　GuardDutyが検出できるAWSアカウントに対しての侵害とは、通常とは異なる地域からのAWS API実行や、異常な回数のAWS API実行などだ。GuardDutyは常にAWS APIの実行ログを取り込んでおり、外国のIPアドレスからのAPI実行や突発的なAPI実行を脅威と判定する。

　GuardDutyのデータソースは、「VPC Flow Logs」（AWSに構築したプライベートネットワーク内のログを収集するサービス）やDNSクエリログ、AWS CloudTrailログ、その他AWSアカウント内で発生する通信ログなどだ。GuardDutyはこれらの情報から検知モデルを作成し、AWSの脅威データベースの情報を組み合わせ、AWSへのさまざまな脅威を検知する。

フォレンジック調査を簡単に　Amazon Detecitveによる可視化と分析

　Amazon Detectiveはセキュリティに特化した分析サービスだ。主にGuardDutyで検知した脅威をさまざまな情報と相関的に分析する。以下がAmazon Detectiveの調査画面の例だ。

Amazon Detectiveのコンソール例（出典：ソニービズネットワークス作成）

　図内の1「観測された戦術」は、検知内容の目的を表示している。この図では、左側に寄るほど「偵察的なアクション」になり、検知内容の深刻度が低くなっている。逆に右に寄ると「攻撃的・破壊的なアクション」の可能性が疑われ、深刻な状況であると判断できる。図は以下を目的とした攻撃であることを示唆（しさ）している。

• 認証情報アクセス：　アカウント名とパスワードの窃取
• 探索：　環境の調査

　図内2「可視化」は、関連するGuardDutyの検知結果とリソース一覧がグラフ化されている。これによると、1つのIPアドレスから1つのデータベースに対して9種類の攻撃が実行されていることが分かる。

　つまり、今回の攻撃は「IPアドレス1.2.3.4からデータベースに対して認証情報の窃取を試みている」ものであり、「IPアドレス1.2.3.4からの接続を禁止する」という処置が必要だ。

　オンプレミスで脅威検知を実装する場合、ログを取り込み分析する仕組みと、検知した場合のフォレンジック調査（セキュリティインシデントに関する調査の呼び名）の仕組みを両方用意しなければならない。

　特にフォレンジック調査は自分でインシデントに関連するログに当たりを付けて相関分析を実施する必要があり、専門知識が必要とされる作業だ。AWSであればGuardDutyとAmazon Detectiveによって、検知から調査までシームレスに実行できる。また、コストも最小限でこれらを導入できる。

AWS移行はキャパシティーの制約を解消する

　セキュリティ強化には「多層防御」の考え方が欠かせない。なぜならどれだけ「防御」機能を対策しても、ヒューマンエラーなど不測の事態は必ず発生するからだ。AWSは「検知」機能の課題であったキャパシティーの制約は解決しつつある。中堅・中小企業でもAWSを活用すれば、多層防御の仕組みを構築できるようになっている。

　ここまで、NIST CSFの「検知」機能におけるAWS利用のメリットを解説した。次回は「対応・復旧」機能で必要なセキュリティ対策が、AWS利用によってどう変わるのかを解説する。