はじめに

この記事はセキュリティチームの Sysdig 活用事例をテーマにした「Sysdigブログリレー 」4日目の記事です。

Google の Security Command Center (SCC) なども、Google Cloud を管理する方法として一般提供されています。

今回は、Sysdig というサードパーティ製品を活用し、CSPM や CIEM を活用して安全な Google Cloud Infrastructure を構築する方法を検討します。

AWS 他の事例などは、ブログリレーの他の記事を参照してみてください。

導入オプション

Sysdig を Google Cloud に導入するに当たり、大きく 2 つのオプションがあります。

Project 単位の導入と、Organization 単位の導入です。

Project 単位は、Project ごとに導入するためライセンスなどの管理が容易です。
組織全体を管理する場合には、Organization 単位の導入が便利です。

今回は、Organization 単位の導入を試してみて、設定方法や、管理の模索、課題を確認してみたいと思います。

導入

導入手順を簡単にまとめます。

今回導入する機能は、CSPM / CIEM / CDR / Vlunerability Host Scaning を利用してみます。

導入の詳細は、Sysdig ドキュメント内の GCP のサイトに詳細があります。

Google Cloud の準備

ユーザーロールの付与

導入手順によると、プロジェクトレベルでは以下の権限が必要とのことです。

  • roles/iam.serviceAccountAdmin (サービス アカウント 管理者)
  • roles/iam.serviceAccountKeyAdmin (サービス アカウント キー 管理者)

Organization Level では以下の権限が必要とのことです。

  • roles/iam.organizationRoleAdmin (組織のロール管理者)
  • roles/resourcemanager.organizationAdmin (組織の管理者)

今回、CDR を利用するので、以下のロールもプロジェクトレベルで必要となります。

  • roles/pubsub.admin (Pub/Sub 管理者)
  • roles/logging.configWriter (ログ構成書き込み)
  • roles/iam.serviceAccountUser (サービス アカウント ユーザー)

手順書には記載がありませんが、以下の権限もプロジェクトレベルで必要なようです。

  • roles/serviceusage.serviceUsageConsumer (Service Usage ユーザー)
  • roles/iam.workloadIdentityPoolAdmin (IAM Workload Identity プール管理者)

また、Organization Level では以下の権限が必要でした。

  • roles/logging.configWriter (ログ構成書き込み)

これを受けて、以下のような設定になりました。

  • 組織レベル
    • ログ構成書き込み
    • 組織のロールの管理者
    • 組織の管理者
  • プロジェクトレベル
    • IAM Workload Identity プール管理者
    • Pub/Sub 管理者
    • Service Usage ユーザー
    • サービス アカウント キー管理者
    • サービス アカウント ユーザー
    • サービス アカウント管理者
    • ログ構成書き込み
実行環境の準備

Terraform および、Google SDK の実行環境を準備します。
今回は、Cloud Shell を利用しますが、どちらも準備されているので省略します。

$ terraform -version
Terraform v1.6.0
on linux_amd64

$ gcloud version
Google Cloud SDK 489.0.0
API の有効化

CSPM の利用のため、以下の API を有効化します。

API Name API ID
Identity and Access Management (IAM) API iam.googleapis.com
IAM Service Account Credentials API iamcredentials.googleapis.com
Security Token Service API sts.googleapis.com
Cloud Resource Manager API cloudresourcemanager.googleapis.com
Cloud Identity API cloudidentity.googleapis.com
Admin SDK API admin.googleapis.com
Cloud Asset API cloudasset.googleapis.com
Compute Engine API compute.googleapis.com

今回、CDR を利用するため Cloud Pub/Sub API を有効化します。

API Name API ID
Cloud Pub/Sub API pubsub.googleapis.com

コマンドで実行する場合は、下記のようなコマンドになります。

gcloud services enable --project PROJECT_ID \
iam.googleapis.com iamcredentials.googleapis.com sts.googleapis.com \
cloudresourcemanager.googleapis.com cloudidentity.googleapis.com \
admin.googleapis.com cloudasset.googleapis.com compute.googleapis.com \
pubsub.googleapis.com

チェックする場合は、下記のコマンドです。

gcloud services list --project PROJECT_ID --enabled

Sysdig Integration

Feature

Add GCP Account を選択すると、Integration のウィザードが出てきます。
こちらは、デフォルトで実施します。

Onboarding Type

Onboarding Type は先に説明したとおり Organization を選択しました。

Installation

注意書きを確認し、項目を入力します。
定期的に更新されているようなので、必ず導入前に注意書きを確認してください。

以下の値を設定していきます。

項目 値
Organization Domain 導入する Google Cloud 組織のドメイン
Region of your GCP Project terraform provider の Region、今回は asia-northeast1
Project ID リソースが作成される Project です、 今回 Sysdig 専用に Project を作成しました

Cloud Shell の実行

Cloud Shell を利用して Installation に記載のある terraform ファイルを作成し、実行します。

$ mkdir sysdig
$ cd sysdig
$ vi main.tf
  # 貼り付け
$ terraform init && terraform apply

成功すると、terraform の成功メッセージが返ってきます。

Apply complete! Resources: 40 added, 0 changed, 0 destroyed.

Domain-Wide Delegation

今回は、Domain-Wide Delegation 機能を利用します。
これにより、Sevice Account はドメイン内のユーザーの代わりにユーザーデータにアクセス可能となります。
これは、CIEM 分析で必要となります。

クライアント ID の取得

Cloud Shell で terraform 実行が完了すると、Service Account が作成されます。

sysdig-secure-${乱数}@${PROJECT_ID}.iam.gserviceaccount.com のアカウントのクライアントID を取得します。

普段利用しない機能のため、とてもわかりにくいのですが。
該当サービスアカウントの『詳細設定』を選択した中にクライアント ID の項目があります。

Google Workspace の設定

Enable Domain-Wide Delegation in GCP の手順をもとに Google Workspace を設定します。

この項目は、手順書通りに実施して特に問題となる箇所はありません。

ここまで完了したら、Sysdig のウィザードに戻り Complete を選択します。

以上で、Google Cloud の Integration が完了します。

所感

Google Cloud で Sysdig を利用する上でのメリットや期待を記載します。
ここでの内容は、 2024 年 9 月 13 日現在時点のものであり、改善されている場合もあること、あらかじめご了承ください。

Project vs Organization

Sysdig を導入する単位として、Project と Organization がありますが、それぞれメリットとデメリットがあります。

Project 単位では、やはり導入が大変なことがデメリットとなります。
たとえば、多くのプロジェクトがある場合、それぞれで導入作業が必要となります。
また、 Sevice Account なども導入の都度作成されるため、多くのアカウント管理が必要になってしまいます。

組織単位で利用するのであれば、Organization 単位での導入が分かりやすいとおもいます。
Sysdig 専用の Project を作成し、Organization Level で導入することで Service Account を本番環境から切り離すことができ、アカウント管理が楽になります。

ライセンスを考えた場合、Project 単位では Prod (本番) 環境のみに導入するなど柔軟性が高く、Organization 単位の場合には、Dev (開発) 環境などにも入ってしまい、ライセンス管理との相性が良くないように感じました。
これは、どのように利用するか、組織の意向で選択が分かれる部分だと考えます。

また、現時点では Organization 単位での導入にあたって、Project 追加時の自動 Integration のような機能は無いようです。
Organization 単位の導入では、自動的に Project を Integration してほしいと感じました。

CIEM

Sysdig の CIEM 機能を利用すると、Google Cloud の Identity を管理するのがとても楽になることを感じました。

Sysdig には Findings として User ID にフラグ付けを自動的に行う機能があります。

一般的に Google Cloud の『Owner』や『Editor』はとても強力な権限を有しているため、最小権限の原則に従うと望ましくない権限です。

Finding として、『Owner Role Applied』や『Editor Role Applied』などの属性が付与されるため、これらの権限をチェックが簡単にできるようになります。
ほかにも、『Inactive』や『No MFA』に該当する User ID も特定してくれるため、大規模な Organization 上での管理が便利でした。

まとめ

Sysdig などの CNAPP ツールを導入する場合、Google Cloud であれば Organization レベルなどの組織レベルでの導入のメリットが高いと思います。

実際に導入してみて、課題感やメリットが見えたため記事にまとめました。

Google Cloud での Sysdig 活用事例を、これからも挙げていきます。

次回の記事は、稲田さんの「棚卸しや定期的な巡回が苦手な僕がSysdigを使って楽して AWS 上の設定をチェックし PCI DSS 4.0 に準拠してみた件について」です。
明日から連休なので、次回の記事は 9/24 (火) に公開予定です。

Sysdig などの CNAPP ツールをどう活用するか、に焦点を当てた記事です。
お楽しみにっ。