[レポート]AWSで加速するセキュリティ-脅威検知と対応- #AWSSummit

Well-Architected Frameworkを100%生かす方法をAWS Summitで聞いてきました。WA の概要とシステム開発の各フェーズにおける活用方法を紹介します。 #AWSSumit
2018.05.30

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

今日は2018/05/30より3日間に渡って東京で開催されている「AWS Summit Tokyo 2018」からセッションをレポートします。

このレポートはTech上級 「AWS セキュリティ入門 2 ー 脅威検知と対応 ー」です。スピーカーはアマゾンウェブサービスジャパン株式会社 ソリューションアーキテクトの藤倉 和明氏です。

レポート

AWSセキュリティは6つの領域で構成

  • ID,アクセス管理
  • 発見的統制
  • インフラストラクチャー保護
  • データ保護
  • インシデントレスポンス
  • リスクコンプライアンス

本セッションは、インシデントレスポンス、発見的統制を扱う。 予防的統制は、あらかじめ想定されるリスクの発現を予防するためのもの。 発見的統制は、あらかじめ想定したリスクと未知の驚異の発現をあらゆるイベントから検知し、その影響を抑えるためのもの。

インシデントレスポンス

検知した脅威への対応とシステムの復旧や影響範囲の特定などを行う。 AWSのサービスをあげると、Lambda、SNS、Config、AWS Systems Managerなどを利用できる。

本セッションのポイント

AWSによって、4つの視点でセキュリティが加速する。 セキュリティの対応は時間との勝負。パッチ適用、インシデント対応など。 しかし、実際には迅速な対応は難しい。

イベントの管理

発見的統制、インシデントレスポンスの第一歩はイベントの管理から 従来のセキュリティでは、ログ基盤、ログエージェント、権限管理、加工、可視化などが必要。 AWSでは有効化するだけでそれらが可能。

イベントマネジメントプラットフォーム

OSログ、AWS Config、CloudTrail、VPC Flow LosをCloudWatch Logsに集約、Kibanaで可視化するといったことが可能

Amazon CloudWatch

CloudWatch = システム監視が可能。CloudWatch Logs = ログ管理プラットフォーム。CloudWatch Events = イベントをトリガーにアクションを実行する機能

CloudWatch

CloudWatchコンソールでは、グラフごとのカラーを選択したり、統計情報(単位)を変更できる。 異常値をすぐに確認できる。

CloudWatch Logs

CloudWatch Logsでは、EC2にエージェントをインストールして、各種ログを収集できる。 マネージドサービスであるVPC Flow Logs、CloudTrail、Lambdaなどもログ集約できる。 CloudWatch Alertで通知。Kinesis Firehoseに連携などできる。

CloudWatch Event

Event Ruleを定義し、様々なサービスと連携できる。 イベントソースとして、EC2 Status変更、時間、API Callなどを指定する。ターゲットはLambda Function、SNS、SSM Run Commandなどを指定する。

統合CloudWatchエージェント

WindowsとLinuxのインスタンス、オンプレミスのサーバーも統合的にメトリクスの収集、ログファイルの送信が可能。 AWS Systems Managerで設定を一斉配布できる。

AWS CloudTrail

ほとんどのAWSサービスに対応し有効にするだけでイベント収集が可能

AWS Config

アカウント内に存在するリソースを検出し、現在の設定内容を記録し、設定内容に対する全ての変更をキャプチャする。 Config Rulesを利用し、変更管理、継続監査とコンプライアンスを実現する。CloudWatch Eventsと連携し、誤操作や悪意のある変更を検知する。

VPC Flow Logs

VPCのネットワークインターフェイスとの間で行き来するIPトラフィックに関する情報全てをキャプチャできる。 オンプレミスで、全てのインターフェイス、L2スイッチなどをキャプチャすることは大変。 AWSでは有効化するだけで確認できる

セキュリティダッシュボード

VPC Flow Logs, Amazon Elasticsearch Service、Kibanaによる可視化して実現できる。 例として、ある時点からリジェクトが多くなった場合、マルウェアへの感染や誤った設定が考えられる。ダッシュボードではドリルダウンして確認できる。

インシデントの検知

多くのイベントから、インシデントを検知しなければならない。 ログを活用した対策が考えられる。 ログ情報の統合、分析、システムのセキュリティ状態の総合的な管理機能を導入しているには、大企業でも29.9%。 ログを活用した対策が普及しているとは言い難い。

Amazon GuardDuty

セキュリティの観点から脅威リスクを検知するAWSマネージドサービス。 有効化するのみではじめられる。

インシデントへの対応が早い

「セキュリティ・オートメーション」という考え方がある。 AWSのサービスはほとんどがAPIを公開している。 プログラムで対応する。 マイニングされた場合、GuardDuty > CloudWatch Event > Lambdaで踏み台にされた端末を隔離の流れを自動化できる。 いつでもすぐに対応できるようにすることが重要

脅威がある状態からの回復が早い

脆弱性への対応

AWS Systems Managerで脆弱性のあるEC2を検知、Run Commandからyum updateを実行する。

感染後の対応

感染した端末をGuard Dutyで検知、CloudWatch Eventsで拾い、Lambdaで隔離。 感染する前のAMIを保持しておけば、速やかに業務復旧できる。 オンプレミスでは、端末在庫を抱えておくなどの必要がある。AMIではスナップショットの保存料金だけ必要になる。

セッションのまとめ

AWSでイベント管理が、インシデント検知が、インシデントレスポンスが、復旧・回復が、早くなる

最後に

オンプレミスでは骨が折れる内容をAWSでは、機能を有効化するだけで実現できたり、AWSが提供する基盤を利用することで楽に実現できることがわかりました。