クラウドの脅威検知サービスをメガクラウドで比べてみた
Alibaba Cloud、AWS、Azure、Google Cloud

脅威検知の位置付け

脅威検知は、米国国立標準研究所（NIST）のサイバーセキュリティフレームワーク（CSF）ではどのように位置付けられているでしょうか。

同様のフレームワークとして、ISMS、CIS Controls、PCI DSSなどもありますが、NISTでのガイドラインをもとにして説明をしていきます。NISTはサイバー攻撃にどう取り組むべきかに特化したフレームワークであり、同時に組織の規模の大小や種別を問わずに活用可能である点、また高度化しているサイバー攻撃を防御するだけではなく、本記事の主題である脅威を検知するという近年主流となるセキュリティ対策への言及もされているためです。

NISTのCSFでは共通となるサイバーセキュリティ対策として５つの機能を、フレームワークコアという名称で定義し、指針を示しています。５つの頭文字をとって、IPDRR などと呼ばれることもあります。

フレームワークコア（Framework Core）

• 特定（Identify）
  
• 防御（Protect、Prevent）
• 検知（Detect）
• 対応（Respond）
• 復旧（Recover）

フレームワークコアの最初に登場する"特定"という言葉が少し分かりにくいかもしれません。守るべきシステム、資産、データなどの保護対象を明確に識別するという意味です。

何を守るかが決まれば、そこへ"防御"を講じます。

その後に本記事のメインテーマである"脅威"を検知するフェーズが出てきます。フレームワークコア内では、異常なイベントを、継続的にモニタリングし、検知するプロセスであると説明がされています。外部から内部への異常な振る舞いだけに目を向けていては不十分です。例えば、インストールしたバイナリやライブラリが意図しない外向けの通信を発生させているかどうかも検出すべきイベントとなります。

クラウドを利用したインフラ構築から、アプリケーションを開発する流れにおいて、防御に関しては時間を割いて詰めることが多いと思いますが、検知という観点では十分に意識を働かせて動けていないという組織も多いのでではないでしょうか。

防御できているかどうかで、検知の必要性の有無が変わることはありません。防御が不正なインバウンドとアウトバウンドのトラフィックを防いでいても、検知は必要です。サイバー攻撃の手口を把握できていなければ、対応のフェーズでのアクションの計画と実行ができません。

最良の防御を敷いていても回避される可能性もあります。その防御は、ある時点でのベストなスナップショットに過ぎないとも言えるためです。

フレームワークコアのそれぞれの機能は並行かつ継続して実行されるものです。

防御と検知の違いが分かりにくいかもしれませんので、内部統制での表現で言い換えてみます。

• 防御：予防的統制（危ない設定、潜在的なリスクを予見する、また防止する統制）
  例：SSHで鍵認証していない
  　　セキュリティパッチを当てていない

• 検知：発見的統制（顕在化したリスクに気付くための統制）
  例：SSHによるブルートフォース攻撃を今まさに受けている
  　　脆弱性を狙った攻撃を受けている

クラウドの脅威検知サービス

各クラウドでの脅威検出サービスの有無を見ていきましょう。

どのクラウドにも存在しているようです。Alibaba、Azure、Googleではセキュリティ機能として統合されているため、それが脅威検出と同義のサービスとは限りません。”()”内が脅威検出のサービス名です。

利用に専門の知見は不要です。ワークロードをさまざまな情報と組み合わせ、機械学習等の技術も利活用し分析してくれます。検知の項目としきい値も自動で設定されます。

サービスを有効にすることで、どのリソースへの検知ができるようになるでしょうか。

• VM・コンテナ：　アプリケーションの実行環境。
• アカウント：　クラウドで管理するアカウントであったり、またAPI呼び出しを行なったりするサービスアカウント。
• データストレージ：　オブジェクトストレージであったり、リレーショナルデータベース、データレイクのようなリソース。

クラウドによっては、一部のリソースには未対応であるものの、主要なリソースには対応していることが分かります。
データストレージに関しては、対応していない場合や、オブジェクトストレージのみに対応している、またはSQL系へのサービスへも範囲を広げているなど相違があるようです。

脅威検知の具体例

脅威検知項目は多岐にわたります。クラウドのリソースというカテゴリに分けて、代表的な検知例を一部あげてみます。

• VM（Virtual Machine）、コンテナ
  - ブルートフォースなど不審なアクセスの判断
  - マルウェアによるデータの外部への送信
• アカウント
  - 普段とは違う場所からのログイン
  - 異常なAPI実行数
• データストレージ
  - 公開権限の拡大によるデータアクセス
  - 不正なデータ参照

脅威を検知した場合にどのような警告が出てくるかを、AWSのGuardDutyのWeb管理コンソールで見てみましょう。警告をメール等で通知する仕組みも備えています。

AWSで脅威検知した場合の例（一部抜粋）

１行目はRootアカウントでのコンソールログインを、２行目はEC2へSSHのブルートフォースを検知した場合です。

静的に決められたルールのみが適用されるわけではないため、検知条件の仔細を把握しきれない不明瞭さから不安を感じることがあるかもしれません。

組織として個別に気づかなければならない行動もあるかもしれません。アプリケーションレイヤーで把握しなければいけない情報もあるでしょう。

専用の検知サービスが検出しない項目や、SaaS等のレイヤに対しては、個別に監視を入れるべきです。自動と手動のハイブリッドによりより強固な検知の仕組みが出来上がります。クラウドに備わっている統合監視サービスも充実しています。アノマリ検知など高度な設定も簡便にできるようになっています。

費用

どの程度の費用がかかるのか、AWSを例に見積もってみましょう。

費用は検知対象となるリソース単独の挙動で判断されるわけではありません。ネットワークトラフィック、イベントログなどのさまざまなデータソースから複合的に分析されます。

AWS GuardDuty 例
CloudTrailやVPC、DNSのログが活用され、そのイベント単位での課金が発生します。

• AWS CloudTrail 管理イベント分析
  100 万イベント/月あたり：100 万イベントあたり 4.00USD

• AWS CloudTrail S3 データイベント分析
  最初の 5 億イベント/月：100 万イベントあたり 0.80USD

• VPC フローログと DNS クエリログの分析
  最初の 500 GB/月：GB あたり 1.00USD

AWSの公式サイトでは、料金例として３つの参考例が紹介されています。

見積り

• 大規模：1,945 USD / 月
• 中規模：875 USD / 月
• 小規模：240/USD / 月

参考：Amazon GuardDuty の料金

利用状況によって大きく変わってくるのですが、これでは感覚的な費用感が分かりにくいかと思います。弊社内ではAWSクラウド費用総額の1〜2％という概算で見積りをしています。総額が100万円であれば1〜２万円という計算です。

すべてのクラウドがイベント単位での課金方法であるわけではありません。

Azureの場合は、Microsoft Defender for Cloud内でのリソースの種類（サーバ、コンテナなど）の単位で課金がかかります。ディフォルトではすべてのリソースが自動的に登録されて利用開始されため、不要なリソースは明示的にオプトアウトする必要があります。アカウントに関してはMicrosoft Defender for Identityからの利用になります。

Googleの場合は、クラウドの年間（換算）費用の5%が課金されます。最小年間費用が決められているため、小規模の導入のしきい値は少し高いかもしれません。

統合セキュリティサービスとして提供されており、脅威検知以外のセキュリティ機能も込みとなる点は認識が必要です。

余談ですが、AWSでも、防御はSecurity Hub、検知は今回紹介したGuardDutyがインターフェースに立ち、フレームワークコアのIPDRRの機能単位で各種セキュリティサービスが集約されてきている流れがあります。さらに統合が進み、IPDRRを包括的に一元管理するパッケージサービスとしての見せ方になるかもしれません。

まとめ

NISTのCSFの中から脅威検知に焦点を当てて解説しました。

日々変化する攻撃を検知する仕組みの構築は多大な労力を要する作業です。しかし、各クラウドの脅威検出サービスを使えばクリック一つで運用をはじめられます。まだご利用になっていない場合はぜひ導入のご検討をしてみてください。

関連サービス