Google Cloudの発見的統制機能で設定ミスや不審な活動を早期発見：Google Cloudチートシート（4）
Google Cloud利用のコツを紹介する本連載。今回はGoogle Cloudの発見的統制機能を使った脆弱性の早期発見について、具体的に説明します。
本連載「Google Cloudチートシート」では、Google Cloudを活用する上でのさまざまなコツを、できるだけ分かりやすく、簡潔に紹介しています。
セキュリティ管理には、予防的統制と発見的統制があります。予防的統制では、セキュリティリスクが起きないように未然に対策を施します。発見的統制では、既に発生している脅威や脆弱（ぜいじゃく）性を迅速に発見し、対応します。
第2回ではIAMを取り上げましたが、これはGoogle Cloudにおける予防的統制の手段の一つです。一方、発見的統制の手段としては、「Security Command Center」（以下、SCC）があります。今回は、SCCを使ってセキュリティ上の脅威の迅速な検知と対応を実現する、具体的な方法を紹介します。
解決できる課題
- Google Cloud上で利用しているサービスで、設定ミスによりセキュリティ上の脅威が発生しているのに気づくことができず、設定ミスに気づくのはセキュリティインシデント”発生後"になってしまう
- 設定ミスに気づいても、どう対応したらよいかが分からない
- セキュリティ上の脅威を検知したときに、見やすいところに速やかに通知してほしい
SCCで設定ミスを検知する
SCCは、Google Cloudのリソースを監視し、設定ミスや脆弱性を検出するサービスです。具体的には、「Cloud Audit Logs」（監査ログ）をはじめとした各種サービスのログを分析します。その結果、Googleが推奨していない設定が見つかると、リスクの通知を行い、是正策を提案します。
なお、Cloud Audit Logsとは「いつ」「誰が」「何を」したかが分かる、操作ログの出力サービスです。不正な操作についてもログに残ります。SCCを利用する上で、Cloud Audit Logsのログは特に重要です。
SCCの代表的な機能には、下のようなものがあります。
- Security Health Analytics：Cloud Audit Logsや各種サービスのログを用いて、攻撃を受ける可能性のある構成ミスを検出する
- サービスアカウントの脅威検出：サービスアカウントのキー情報漏えいを検知する
- Web セキュリティスキャナー：Webサービスの脆弱性を検出する
SCCには、「Standard Tier」と「Premium Tier」の2種類が存在します。
- Standard Tier: 無料だが、ごく一部の機能のみ利用可能
- Premium Tier: 有料だが、多くのリスク検知の仕組みを提供
SCCでは、Premium Tierで全機能を有効化することがベストプラクティスとされています。
SCCは組織、フォルダ、プロジェクト単位で有効化することができます。機能についても同様に、不要な機能をプロジェクト単位で外すことができます。
ただし、SCC自体がGoogleのセキュリティベストプラクティス集のようなものですので、基本的には全てのプロジェクトで全機能を有効化し、警告については即座に対応するようにしましょう。
Cloud Audit LogsとSCCを設定する
では、具体的なCloud Audit LogsとSCCの設定方法に入ります。
なお、セキュリティ設定など、大事なものは設定漏れをなくすため、組織で一律に設定することが原則です。例外的な扱いが必要な場合のみ、フォルダやプロジェクト単位で設定します。
Cloud Audit Logsは、以下のように設定していきます。
まず、「IAMと管理」→「監査ログ」でCloud Audit Logsの設定画面を開きます。
画面上部の「デフォルト構成の設定」をクリックします。
「管理読み取り」「データ読み取り」「データ書き込み」にチェックを入れて保存します。
これで全てのサービスに対して、全ての監査ログが出力されるように設定できます。
なお、セキュリティリスクが低い場合には、ログの保存費用を節約するために、ログを取得するサービスを絞ることも可能です。
Cloud Audit Logsについてはこのドキュメントも参考にしてみてください。
SCCは以下のように設定していきます（初回設定時は、Google Cloudのガイドが表示されます）。
SCCの設定画面は、「セキュリティ」→「リスクの概要」をクリックし、ダッシュボード画面を表示し、画面右上にある「設定」ボタンをクリックします。
次に「サービス」タブで、以下の各サービスを全て有効になるように設定しましょう（脆弱性評価はAWS環境がある場合のみ）。
「統合されたサービス」タブでも、有効にできるものは有効にしておきましょう。
上記のように設定した後、ある程度時間が経過すると、脆弱性などの検知が行われていきます。
検知したリスクは、下のようにGoogle Cloudダッシュボードに表示されます。このケースでは、多要素認証が有効化されていません。また、他ドメインのユーザーにIAMロールを付与しています。このため、脆弱性として表示されています。
SCCから即座に通知を受けられるように設定する
SCCは、検知した内容をダッシュボードに表示しますが、頻繁にダッシュボードを見るのは手間がかかります。脅威を検出したときに、メールやSlackなどで即座に通知できると便利です。
ただし、SCCはGoogle Cloudのメッセージサービスである「Google Cloud Pub/Sub」への通知は行ってくれますが、その先の各ユーザーのチャンネルに通知を行う機能はありません。そのため、Cloud Pub/Subへの通知が行われた後、メールやSlackなどへ通知する仕組みを用意する必要があります。
一番簡単なのは、Cloud Pub/Subに通知されたメッセージを「Google Cloud Functions」で受け取り、その内容を元に通知メッセージを作成して通知するプログラムを作成することです。
これにより、例えば以下のように、Slackへの通知が可能です。
なお、SCCは組織レベルで設定することが可能ですが、Cloud Pub/SubやCloud Functionsはプロジェクトのリソースです。
そのため、組織レベルで検知した内容を通知する場合は、組織内に共通基盤の役割を持ったプロジェクトを作成し、そこにCloud Pub/SubおよびCloud Functionsを作成して通知を行うようにしましょう。
以下のような構成になります。
SCCでよくある疑問と回答
SCCを設定する際のベストプラクティスは？
Googleがベストプラクティスとしているのは、Premium Tierにし、全機能を有効化することです。
個人的には上記を前提としつつ、組織リソースでPremium Tierを導入し、Premium Tierレベルが不要な場合はプロジェクト単位でStandard Tierを設定するのがよいと考えています。
また、機能については、組織では全機能を有効化しておき、プロジェクト単位で必要な機能に絞るという方法がよいと考えます。
理由は次の通りです。
- 組織レベルでSCCを有効化することで検知ができるようになる項目がある
- 組織レベルでPremium Tierを選択することで、Premium Tierの単価が2割安くなる
- 組織配下のプロジェクトに対して設定漏れがなくなる。Premium Tierが不要なプロジェクトについては、プロジェクトレベルでStandard Tierに変更が可能。SCCの機能の中でプロジェクトによっては不要なものもあるが、これはプロジェクトレベルで制御する
SCCをどのように設定したらよいか分からない
まずは、Googleのドキュメントにある通りPremium Tierを利用して、全機能を有効化してみましょう。
運用していく上で不要な通知が多すぎる場合は、各機能のON/OFFを調整したり、Muteルール機能を利用したりして、通知されないようにしてください。
ただし、Muteルールを適用した場合は、ミュートしたリスクを検知しても通知がされないのでご注意ください。
まとめ
発見的統制は、セキュリティインシデントの早期発見、迅速な対応、そして原因究明に不可欠です。SCCを適切に活用することで、より安全なGoogle Cloud環境を実現できます。
Copyright © ITmedia, Inc. All Rights Reserved.