【GCPでセキュリティの柱を築く】SecurityCommandCenterを構成する
こんにちはクラウドアーキテクトの山下です。
ここまでGoogleCloudにおけるセキュリティ統制について触れてきました。
一般的にセキュリティ統制方法として未然にセキュリティリスクやインシデントを抑制する予防的統制とインシデントやリスクが発生してから検出する発見的統制が挙げられます。
今まで記事で触れてきたセキュリティ是正方法は事態を未然に防ぐ予防的統制でした。勿論、予防的統制によってガードを固める意義があります。
一方で、事態が発生してから検出されずスルーされてしまう事も危険です。気付かない内に侵入/攻撃されていて全て事が済んでから初めて気づくのでは遅すぎます。このリスクを解消するために発見的統制での対応を行います。
SecurityCommandCenterとは
GoogleCloudで発見的統制を行うためにSecurityCommandCenterというサービスが提供されています。SecurityCommandCenterはAWSのGuardDutyやAzureのDefenderと同様にクラウド自体のセキュリティとワークロードに関わる保護を行ういわゆるCNAPP(CSPM/CWPP/CIEM)サービスです。
※そもそもCNAPPとは・・・?
クラウド・ネイティブ・アプリケーション保護プラットフォームの事で、クラウドに関わるセキュリティ対策を各層別に検出/対応するための製品またはサービス群です。
以前紹介した責任共有モデルをあらためて確認します。
グラフ内の青帯の領域がユーザ責の箇所になり、IaaS/PaaSがGoogleCloudが主に対象とするところになります。
例えば、クラウドのインフラ部分はクラウド事業者が責任を持つものの、クラウド上の仮想マシンやオブジェクトストレージのネットワーク設定で全公開となるような設定をユーザが行ってもユーザ責となります。
このユーザ責の箇所での設定ミスや悪意のある設定を検出するためにも、OSやコードに含まれる脆弱性や危険な実装を特定するためにも、CNAPPを利用してセキュリティリスクの特定を行なっていきます。
SecurityCommandCenterの概要
それではCNAPPとしてのSecurityCommandCenter(以降SCC)が出来る発見的統制の内容について見ていきます。
構成サービス
SCCでは組み込みでセキュリティ対策機能が複数用意されており、それぞれカバーする領域が違います。
| サービス名 | 対象 | 確認内容 |
|---|---|---|
| Security Health Analytics | リソース設定 | GCPリソースの設定にセキュリティリスクが含まれていないかを確認 |
| Web Security Scanner | Webアプリ | WAFで確認するようなXSS,SQLインジェクションなどWeb経由での脅威と脆弱性の確認 |
| Event Threat Detection | 監査ログ | 監査ログから攻撃や不審な挙動があればすぐにその脅威を検出 |
| Container Threat Detection | コンテナランタイム | GKEなどでContainer-Optimized OSを用いたインスタンスがある場合、そのランタイムについて脆弱性が含まれていないか脅威がないかを確認 |
| Virtual Machine Threat Detection | 仮想マシン | GCEインスタンスのOS内で攻撃や脅威となる振る舞いがあれば検出する |
それぞれのサービスからさらに派生するサービスがあったり、コンテナと仮想マシンなどサービス間でそれぞれを補完し合うような場合もあります。
さらに、Mandiantの買収やGeminiの統合などGoogleCloudのセキュリティラインナップが劇的にこの数年で変化しているため、四半期後ぐらいに構成がぐっと変わっております・・・。
そのため、若干複雑で分かりにくいところではあるのですが…**責任共有モデルのどこの事を指しているのかを意識すれば迷子にはなりません。**逆に言うと、責任共有モデルで範囲とするものが満たせるよう、SCCとそれ以外の手法で検出や予防的統制が出来ないかを検討しましょう。
ライセンス/料金
SCCではティアが定義されており、ティア別でカバーできる領域や有効化できるサービスが異なります。大きくスタンダード、プレミアム(プロジェクト/組織)、Enterpriseに分かれています。
かつてはスタンダードとプレミアムだけでプレミアムが高額かつ申し込みをしないと利用できないものでした。しかし、現在ではプレミアムを従量課金で気軽に扱えるようになりました。
まずはプレミアムを有効に
プレミアムではスタンダードよりも脅威検出サービスが増加し、Security Health Analyticsで確認できる診断項目が増えます。コンテナや仮想マシンといったワークロードが稼働している場合や商用・本番環境ではプレミアムでの利用をお勧めします。プレミアムの有効はベストプラクティスとしても指定されています！
新しく追加されたEnterprise ※余談
GoogleCloud製のSIEM/SOARであるSecOps(SecurityOperations)が追加で利用できるプランです。
SIEM/SOARはSplunkやElasticを代表としたログ分析およびそこからセキュリティ上のリスク検出を行う技術です。SecOpsはこの機能をサードパーティではなく自社製品として展開されています。AzureのSentinelやAWSのOpenSearchなどがこちらに当たります。
SecOpsはMandiantのサービスと統合されており、なんとGeminiでSIEMの検出用ルール定義や対応策であるSOARのPlaybookを自動生成したり、自分が扱う特定のGoogleリソースに対してセキュリティ管理が行えます。
まだ気軽に利用できるものではないですが、Google Cloud NextやRSACなどイベント内のデモで確認させてもらいましたが・・・次世代のSOCでした。実際の操作感やハルシネーションのリスクなどは不明ですが今後期待しているサービスです。余談でした。
SecurityCommandCenterをどこに当てはめる？
SCCの構成サービスと料金について概要を説明してきました。次にSCCの構成サービスの選定方法について触れていきます。
これはGoogleCloudに限らずAWS、Azureでも同じですが、セキュリティサービスはたとえ仮想マシンを停止したり、そこまでリソースを作成していなくても課金がされてしまい高額になりがちです・・・。また、セキュリティは非機能要件なのでカバレッジを上げるために何でも有効にできる程でないシステムもあります。ユースケースと重要度に合わせて有効にしていくサービスと項目を選定していきましょう。
公式ドキュメントでユースケースに応じたサービス対応が記載されています。これを参考に対応付けとサービス選定と設定をおこなっていきます。
こちらはAWSの責任共有モデルとCWPP/CSPMが対象とするところですが、他にもデータに特化したDSPMやIAMなど認証認可に特化したCIEM、アプリケーションに特化したASPMなどCNAPPに関わる製品やサービスがサードパーティにて増加中です。SCCやGoogleCloudの他のサービスでもカバーできるものも多いので、ユーザ責のどこを満たすべきなのかをメインで考えましょう。
ただし、CSPM、SCCで言うところのSecurity Health AnalyticsとEvent Threat Detectionはどのようなプロジェクトでも対象となる範囲です。まずはこのCSPM部分から適用し、他のケースにも対応できるよう拡充していきましょう。
まとめ
今回は少しざっくりとした説明になってしまいましたが、SCCについての概要を書きました。
良い設計をする、通信や認証/認可を制御する、組織全体で同一のポリシーを効かせるなど色々なセキュリティ手法を紹介しましたが、結局システム設計者や実装者がこれを満たさないといけません。
設定ミスや経験不足、悪意によるものなど様々な要因でこれが崩れます。予防的統制をより強固にするためにも、人を責めず設定不備を修正することに重点を置くためにも発見的統制の導入は有用です。
SCCはこれを満たすサービスだけではなくSecOpsや他のサービス統合も行え、今後も進化が期待されます。GoogleCloudを扱うのであれば是非有効にしていきましょう！
Discussion