【GCPでセキュリティの柱を築く】Security Command CenterでCWPを適用する
こんにちは。クラウドアーキテクトの山下です。
Security Command Center(以降SCC)のCSPM(クラウドの設定不備、挙動検出)について触れたので、今回はCWP(ワークロード保護)適用を行っていきます。
CSPMはGoogleCloudのリソースに対してのセキュリティ保護を行いますが、ワークロード内での攻撃や侵入、不審な挙動を検出しきれるものではありません。GKEがいかに健全な設定であろうが、そこで動くコンテナ(Pod)に不備があると問題が発生します。GCEも同じマシン設定が良くてもOSから上位に不備があれば台無しです。アプリケーションの問題はOS、ミドルウェア、実際のソフトウェアを構成するコンポーネントまで精査しないといけません。
Web Security Scannerを構成する
WebSecurityScannerはネットワークを通じてアプリケーションの脆弱性を検出できるサービスです。エージェントを導入することなく、Webアプリケーションに含まれている脆弱性の検出を行えます。
フロントエンドのJavascript実装やHTTP/HTTPS通信の内容などWebアプリケーションにおける表層についてチェックします。
サポートするサービス
サポートしているサービスは以下の通りですが、CloudFunctionsやCloudRun、CloudStorageのWebコンテンツ公開をサポートしていません。ただし、これらは複雑で動的なフロントエンドが実装される事はないので問題ありません。一方、CloudRunはフロントエンド用途でも使えなくはないので注意です。
App Engine(Standard/Flexible)
Google Kubernetes Engine
Compute Engine
検出できる脆弱性
OWASP Top10に準拠したWebアプリケーションの脆弱性検出が定義されています。XSSやSQLインジェクションなど代表的なレベルものから、HTTP/HTTPS通信時の非暗号化やアプリケーションフロントエンドのフレームワークの脆弱性が行えます。
扱う上での注意点
CSPMの時と同様にWebSecurityScannerを過信するのは危険です。
公式ドキュメントでも言及されていますが、アプリケーションの単体/結合試験を代行してくれるものではなく、DASTを全て担うものではありません。
Lyft&Shiftで古いアプリケーションをGoogleCloudに移行してきた場合や、新規プロジェクトで脆弱性が含まれていないか全体管理としての使い方が本来の用途です。
また、WebSecurityScannerは１週間ごとの定期実行、かつリアルタイム検出を行うものではありません。そのため、本番環境でのリアルタイムな検出を期待してはいけません。
実際に扱う
前提
Webアプリケーションの脆弱性をスキャンするために純粋にトップページにアクセスだけするのではなく、Webサービスに対してある程度の画面操作を実施します。そのため、本番環境での利用は非推奨事項となっています。
これはBlue/Greenデプロイメントと組み合わせて利用することが前提としてあるように思えます。本番と同じ環境を2面用意し、アップデートの際に環境ごと切り替え、問題発生時にすぐに元の環境にロールバックする手法です。
設定を有効化する
毎度ながらSecurityCommandCenterのUIから有効化を選択して終わりです。シンプルすぎます。
Blue/Green環境を準備し非稼働環境で試験
稼働していないもう一つの環境でWebSecurityScannerでの試験を実施し、セキュリティスキャンを行います。本番環境に対して誤って試験しないようにターゲットを制限することができます。
WebSecurityScannerの設定は”検出と防御”からサービスを選択して実施します。スキャンしたいアプリケーションのURLとIPアドレスを元にスキャンを実施します。同じアプリケーション内でもスキャンされると問題なページやパスは除外を行うこともできます。
スキャンは24時間かかる事もあるので時間に余裕を持たせて夜間などの実施を実施します。
脆弱性が発見されたら
各脆弱性について修正方法についても具体的に提示がされています。こちらを参考に修正していきますが、注意なのは再度スキャンするのにも時間がかかるため悠長に待って再試験を行うのは効率が悪いという点です。
脆弱性について修正を行ったら再試験するかどうかはプロジェクトの状況に応じて変動させるのがよいでしょう。
環境を切り替える
スキャン後に問題ないことを確認、または修正が完了したら、アクセスする環境をDNSやLoadBalancerを通じて切り替えます。
VM/Container Threat Detectionを構成する
WebSecurityScannerは文字通り、Webアプリケーションの脆弱性検出を行うサービスでした。そのため、Webアプリケーションでないワークロードやバックエンドのロジック部分の実装に含まれるコンポーネントの脆弱性を検出することは出来ません。
この範囲をカバーできるものがVM/Container Threat Detectionです。仮想マシンとコンテナに含まれる静的な脆弱性検出と動的な脅威/不審な挙動を検出するサービスです。
これらはEvent Threat Detectionと相互に補完するよう設計されています。そのため、部分的な利用ではなく全て利用する事でその真価を発揮できます。
サポート対象
VMはGCEインスタンス、ContainerはContainer Optimized OSがワーカノードとして稼働しているコンテナが対象となります。VMは全てのOSが対象なのに対して、ContainerはOSが制限されているので注意です。
一方で、GKEでワーカノードを構成させる場合にContainer Optimized OS以外を利用するのはあまり得策ではありません。
コンテナアプリケーションを扱う際のNIST SP800-190にも定義されている通り、コンテナを稼働させるOSは必要最小限のものを構成し、必要なソフトやパッケージはOSにインストールせず、コンテナとして稼働させる事を推奨しています。AWSでもFargateがあえて提供されている背景でもあります。
検出対象
VMとContainerで検出できる脆弱性はそれぞれ以下の通りです。Containerはランタイムとコンテナについて検出を行いますが、OSや仮想マシンについて検出するものではありません。
一方、VMもコンテナについては検出対象ではありません。GKEを活用する場合は両方構成が必須なのはここからも伺えます。ただし、GCEだけの場合はVMだけでよいとも言えます。
この手のサービスはエージェントをOSにインストールしたり、コンテナのサイドカーとして構成するケースが多いのですが、流石GoogleCloudデプロイ方法はいわゆるエージェント型とは異なります。
| VM Threat Detection | Container Threat Detection | |
|---|---|---|
| デプロイ方法 | インスタンスを稼働させているハイパーバイザー経由で情報を取集(=エージェントレスかつ,スナップショットから間接的に情報を得ず直接取得) | 全ワーカーノードにDaemonSetとして１コンテナ常駐させる。コンテナを通じて情報収集・SCCに連携する(=OSには何も追加しない) |
| 検出項目 | カーネルへの不正操作、マルウェアの挙動検出 | コンテナ内のパッケージとバイナリ確認、コンテナからの不正操作検出 |
実際に扱う
有効にする方法は毎度のこちらです。簡単ですね。
動作確認する
Threat Detectionは動的な検出を行うため、きちんと機能しているか確認するためにはわざと不審な挙動を擬似再現させる必要があります。
検出結果を確認する
SCCの検出結果より発見された脆弱性や攻撃・侵入を検出される。
まとめ
CSPMではカバーできないワークロードの静的な脆弱性と動的な不審な挙動を検出できる機能としてSecurityCommandCenterではCWP機能のサービスが提供されています。
Webアプリケーションに特化したWebSecurityScanner,ワークロードの不審な挙動に特化したVM Container/Threat Detectionがありました。
しかし、簡単に有効化できるからととりあえず有効にするものでも全部カバーできると過信するのはやはり危険です。カバーしない範囲を加味して以下に気をつけましょう。
CWPは必須ではない
CWPは文字通りワークロードを自前で用意する場合に必要なサービスになります。例えばBigQueryやGCSをメインで扱っていて少しだけDataflowやPub/Subを使うといったよくあるユースケースではCWPは当然不要です。一つの観点としてはCompute系のサービスを利用するかどうかで要否の判断ができます。
カバー範囲に注意
GAE,GKE,GCEを活用するケースでは大変有用なものの、CloudRunやCloudFuntionsなどサーバレス系のサービスで稼働するワークロードは保護していない点には注意が必要です。サーバレスにデプロイするアプリケーションやコードについては他でカバーする必要があります。
また、GAE,GKE,GCEであってもその上で稼働するアプリケーションのセキュリティリスクを解消・検出できるものではないことにも注意が必要です。これを解消するためにはアプリケーションの製造工程でリスクをいかに混在させないかが大事になります。
コードスキャン、イメージスキャンやCIパイプライン内でのSASTやパッケージチェック、セキュアなコードの書き方など製造/開発工程での予防が前提となります。CSPMと同様、セキュアなアプリケーションを開発した上でなお発生する問題への対応として活用する必要があります。
Discussion