【GCPでセキュリティの柱を築く】Security Command CenterでCSPMを適用する
こんにちは。クラウドアーキテクトの山下です。
Security Command Center(以降SCC)の概要について触れたので、今回は実際に適用を行っていきます。前回のおさらいですが、SCCは以下のサービスとこれらを有効化するためのサブスクリプション体系がありました。
GoogleCloudとしてはPremiumサブスクリプションを有効化する事が推奨されており、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内で攻撃や脅威となる振る舞いがあれば検出する |
共通で設定するもの
プレミアムティアを選択する
SCCを活用する際はプレミアムティアを有効にすることがGoogleCloudとしては推奨されています。これを実現するためには、ティアの選択をまず最初に行う必要があります。
サブスクリプション体系
| 種類 | 詳細 | 用途と向いているユーザ |
|---|---|---|
| Enterprise | マルチクラウド CNAPP セキュリティ、SIEM/SOARでのケース管理と修復ハンドブック | マルチクラウドで扱いたい。Google製のSIEM/SOARを扱いたい。 |
| Premium | Google Cloudでセキュリティ対策管理、攻撃パス、脅威の検出、コンプライアンスのモニタリング | Google Cloudをメインで扱いたい。CNAPPのみをメインで扱えれば十分。 |
| Standard | Google Cloudで基本的なセキュリティ対策管理 | 検証/開発環境で最低限のセキュリティで十分。 |
SCCのメニュー内で任意の項目を選びます(概要でも脅威でも脆弱性でもなんでも可)。共通で右上に表示されているSettingsを選択します。
設定メニューのティアの詳細タブを選択し、ティアの管理をクリックします。
ティアの管理画面でサブスクリプションプランを選択できます。ここではプレミアムティアを選択します。
階層別の適用状況を確認する
SCCは組織ポリシーやIAMと同様に階層別に適用を分けて行う事が可能です。SCCは組織で有効化し、その配下のフォルダやプロジェクトについて組織のSCC設定を継承するか、無効にするかが選択できます。
検証環境としてプロジェクトを利用している場合に、検出対象から除外する場合や料金を節減する場合に有用です。本番であれば継承または有効を選択しましょう。
Health Analyticsを設定する
HealthAnalyticsはGoogleCloudリソースが脆弱な設定をされている場合に検出されるものになります。いわゆるCSPM機能になります。
対象サービス
サポートしているGoogleCloudサービスは以下の通りです。
#サポートしているサービス群
- ServiceAccount
- ComputeEngine
- GKE/コンテナ
- Dataproc
- BigQuery
- Pub/Sub
- CloudSQL
- CloudStorage
- CloudDNS
- VPC/ファイアウォールルール
- CloudIAM
- CloudKMS
- CloudLogging
- CloudMonitoring
- 組織ポリシー
見てわかる通り、主要なサービスをカバーしているものの、全てのサービスをカバーしているわけではありません。全ての脆弱性を検出できると過信するのは今の段階では危険です。よい設計の補助として活用するのがおすすめです。 とはいえ、有効にすることでセキュリティ監視を行えるようになります。
AWSの検出ルールに注意
HealthAnalyticsのメニューを見ると多くのAWSの検出ルールが定義されている事に気づきます。GoogleCloudに関連したルールだけを有効化できるように選別を予めしておきたいところですが、これが現在行えません。(フィルターでAWSなどの項目があれば…)
簡単な見分け方として、AWSのルールはデフォルトでは無効になっています。
デフォルトで無効のポリシーと同じで必要であれば有効にするものなのでまずは無視しても問題ないでしょう。
勿論、AWSも検出したい場合は有効化すべきですが、まずはGoogleCloudから始めましょう。
Premiumにするだけで多くの機能が有効になる
以下のモジュール以外はPremiumを有効にするだけで有効にすることが出来ます。
暗号化キーについて個別の要件を満たしていない事を検出したい場合や、Assetなど資産情報を管理できていない場合に検出を行いたい場合など、要件に合わせて検出すべきなのかそうでないのかが変わる要素にこちらが含まれています。
#デフォルトで無効のモジュール
BIGQUERY_TABLE_CMEK_DISABLED
BUCKET_CMEK_DISABLED
CLOUD_ASSET_API_DISABLED
DATAPROC_CMEK_DISABLED
DATASET_CMEK_DISABLED
DISK_CMEK_DISABLED
DISK_CSEK_DISABLED
NODEPOOL_BOOT_CMEK_DISABLED
PUBSUB_CMEK_DISABLED
SQL_CMEK_DISABLED
SQL_NO_ROOT_PASSWORD
SQL_WEAK_ROOT_PASSWORD
VPC_FLOW_LOGS_SETTINGS_NOT_RECOMMENDED
実際に設定する
プレミアムティアの設定と同じメニューでSecurity Health Analyticsの設定を管理をクリックします。
サービスの有効化で組織階層で有効を選択します。以上です！非常に簡単です。
デフォルトで無効になっているものを有効化したり、有効化にしたくない項目がある場合はモジュールから有効/無効にできます。
Event Threat Detectionを設定する
Event Threat DetectionはCSPMにおけるPostureいわゆる振る舞いに関わる検出を行えるサービスです。不審な動きがあったときにリアルタイムで検出を行う事が出来ます。
つまりSecurity Health Analyticsが静的な設定に関わる脆弱性を検出するのに対して、Event Threat Detectionは動的な挙動に関わる脆弱性や実際の攻撃を検出します。その元ネタとなるのは監査ログを始めとしたログです。Premiumティアでないと利用できないので注意です。
検出する振る舞い
振る舞いを検知するのでサービスではなく攻撃手法に基づいた内容がベースになります。攻撃一覧は以下のリンクとモジュールから確認できます。
※注意
ドキュメントでは攻撃タイプが定義されているのに、実際にそのルールがない場合があります。カバーしていない攻撃手法や手法によって充実度合いも異なるので、予め攻撃のカバレッジを確認しましょう。恐らく今後追加されていくのだと思います。
手がかりとなるログを事前に収集する
振る舞いをSCCが検出できるためにはSCCがログにアクセスできる必要があります。
そのため、攻撃を検出するために必要なログを有効化する必要があります。
AuditLogは当然デフォルトで有効なので意識する必要はありませんが、通信ログやDBやK8sなどのサービス固有の監査ログはデフォルトではCloudLoggingに出力されません。利用しているIaaS/PaaSのサービスは監査目的でもSCCでの振る舞い検知のためにもロギングを有効にするのがベストプラクティスと言えます。
実際に設定する
プレミアムティアの設定と同じメニューでEvent Threat Detectionの設定を管理をクリックします。やる事は同じです。
モジュールについてもSecurity Health Analyticsと同様の内容になります。
カスタムでモジュールを作成する
Security Health AnalyticsとEvent Threat Detectionでは見てきた通り、GoogleCloudが事前で定義している検出項目があります。一方で、ユーザで独自に検出ルールを定義することが出来ます。
特定のアドレス以外から通信できる設定だったら検出するSecurity Health Analyticsのモジュールや特定のアドレスから通信があれば検出するEvent Threat Detectionのルールを定義する事が可能です。
SecurityHealthAnalytics
組織ポリシーをカスタムで定義する場合と同様にCEL構文で検出ルールを定義していきます。プロジェクト内のリソースをyamlで定義し、yamlのフィールドから検出したい項目について判定を行う構文を作成していきます。
そのため、CELはyamlに対してSQL構文のようにクエリをかけて検出条件にマッチするかどうかを判定します。検出条件に該当した場合にそのリソースが違反として扱われます。
サンプル例
https://cloud.google.com/security-command-center/docs/custom-modules-sha-code?hl=ja&_gl=1107m7qa_gaMTQwOTE4ODQxNi4xNjcwMjA2MDAy_ga_WH2QY8WWF5*MTcyNzI0ODU2MS43MTEuMS4xNzI3MjUxOTM1LjQ4LjAuMA..#example_cel_expressions
CELのテストを充実させ誤検知/検知漏れを防止し、CELでの特有の構文を保守/i運用していく事を考えるとあまり多用はしない方が今は良いのではないかと思います・・・。
Geminiがこのモジュール定義をスムーズに行う、CELをWrapperでもっと可読性の高い構文で定義できるようになるなど今後の拡張に期待です。
EventThreatDetection
SecurityHealthAnalyticsとは異なりテンプレートが用意されており、簡単に定義する事が出来ます。CELに比べると自由度は下がるというデメリットはあるものの、運用性や保守性を考えると有用です。
テンプレートから項目を選んで
検出する内容を定義するだけ
まとめ
SecurityCommandCenterのCSPM機能についてどのように適用するのかを見てきました。
自分たちの利用しているプロジェクトのリソースが攻撃や侵入をされてしまう状況なのか、または実際に不審な挙動があったのかを検出する事が出来ます。これを行う事でプロジェクトのセキュリティ拡充を行う事が出来ます。
一方で、SecurityCommandCenterを過信し頼り切るのはアンチパターンです。
なぜなら、SecurityCommandCenterがカバーできる範囲は限られているのと、仮に検知できたとしても修正を誰かが行わないといけないためです。
発見的統制がカバーすべきなのはセキュアな設定を適切にしている前提で、どうしてもヒューマンエラーや運用上の理由でセキュリティ対策が漏れてしまっているものです。すべてを検知しようとするとアラートが多発してその確認と対応だけで疲弊してしまいます。
今までの記事で触れて来たセキュアな状態を目指して、その補助として活用していきましょう。
予防と発見それぞれのバランスが釣り合って初めて強固なセキュリティが実現できます。
Discussion