Google Cloud Champion Innovators Advent Calendar 2024 の23日目の記事です。
はじめに
アイレットでは、cloudpack というクラウドの構築・運用保守サービスを提供しています。2019 年からは Google Cloud（当時の GCP）にも拡大しています。
2015年から cloudpack サービスに対して、SOC2 報告書を受領していましたが、今年、ついに Google Cloud にも SOC2 報告書を受領しました！
2022年に監査対応などを主幹する内部統制推進室を兼任した際に、自分の中の目標に掲げていたことの一つが実現できたのですが、せっかくなのでそこで行った知見を共有しておきます。
SOC2 とは？
Google Cloud のサイトには、以下のように記載されています。
Service and Organization Controls（SOC）2 は、米国公認会計士協会（AICPA）の監査基準審議会（AICPA）SSAE 18 に基づく報告書です。この報告書は、トラスト サービスの基準（セキュリティ、可用性、処理の整合性、機密性保持、プライバシー）に関連するサービス組織の管理を評価するものです。
もう少し補足します。
SOC には、他にも SOC1 と SOC3 があります。
セキュリティ、可用性、処理の整合性、機密性保持、プライバシーに対する内部統制を対象範囲にする SOC2、3に対し、 SOC1 は財務報告に対する内部統制を対象とします。
SOC2 と SOC3 はスコープは同じですが、サービス利用者にのみ詳細な内容で報告する SOC2 に対し、SOC3 はサービス利用に関わらず概要を示します。
さらに、SOC1 および 2 には、Type 1 と 2 が存在します。
Type 1 はあるタイミングでの有効性を評価しますが、Type 2 は一定期間（6ヶ月以上）の運用状況の有効性を評価します。
サービス提供にあたってのセキュリティや可用性などについて、どのように定義、実装しているのかを文書化したものが、SOC2 記述書になり、外部機関によって、記述書通りに運用されていることが確認されたものが SOC2 保証報告書になります。
サービス利用者に詳細レベルで開示する可能性のある報告書のため、雑なものであれば信用を失います。とはいえ、厳正な審査があるので完璧にできていないことを書けば、保証を失います。
今回は、すでに提供済みの別のクラウド向けに受領した SOC2 記述書をベースに、セキュリティなどについて同等レベルのサービス内容で提供することを前提に、Type 1 で取得の準備を進めました。
対応したことをいくつか
まずは、セキュリティのデザインから入りました。アイレットでは、元々、別のクラウド事業向けに維持・公開している「cloudpack セキュリティホワイトペーパー」があります。こちらをベースに、Fit & Gap 分析を行い、Google Cloud との差分を明確にして必要なシステム改修を行った上で「cloudpack セキュリティホワイトペーパー for Google Cloud」をリリースしました。
ここまでは、2021 年に MSP 認定を取得するにあたって実施しておりました。
ご興味のある方は、以下からダウンロードください。
https://cloudpack.jp/whitepaper/security.html
SOC2 対応にあたって、プロセスの整備や文書化、教育なども行ってきたのですが、Champion Innovator アドカレなので、Tech 寄りの内容を少し踏み込んで。
監査ログの設計
SOC2 では、性悪説に基づくといいますか、内部犯行に対しても十分な対策をしておく必要があります。
そこで有効な対策の一つが、責任追従性の担保です。
Google Cloud には、監査ログの仕組みが提供されており、消したり無効化できない形で、「いつ誰がどこで何をしたか」を確認することができる操作ログが書き込まれます。
詳しくは、コチラ。
監査ログには、無効化や除外することができないログ（管理アクティビティ監査ログ、システムイベント監査ログ）と、無効化や除外ができるログ（データアクセス監査ログ、ポリシー拒否監査ログ）があります。後者の方は、プロジェクトの用途やかけることができるコストなどに応じて、有効化したりフィルタリングします。
これらは、プロジェクトごとに設定することができます。
さらに、Google Cloud の監査ログはプロジェクトごとに保持期間の設定やサイズ上限があります。
SOC2 に対応した内部統制においては、プロジェクトごとでなく一貫した基準でログポリシーを定義する必要があります。
また、定期的に怪しい挙動がされていないかのモニタリングが必要※です。
※これは SOC2 として必須ではなく、cloudpack サービス基準に基づくものです。以降も、すべての SOC2 対応で必須条件でないものもこのような書き方をする箇所がありますが、一般的に必要と思われるものを挙げるようにします。
このモニタリングを実装する際に、プロジェクトごとに行うことも論理的には可能です。事実、Google Cloud SOC2 対応を進める以前は、基準となる標準は定めていましたが、プロジェクトごとの要件に応じたログ設計に依存する形になっていました。操作履歴を追いたい際は、プロジェクト内の監査ログを参照していました。
今回、監査ログの一貫性維持と横断的なモニタリングのため、各プロジェクトから必要な監査ログを収集管理する仕組みを用意しました。
構成は以下のようなものになります。
Audit フォルダの中に、監査ログの集約管理用のプロジェクト (Audit プロジェクト) を作成しました。Audit フォルダは他のものと隔離し、アクセスできるメンバーも必要最小限にしています。
Audit プロジェクトには、SOC2 で定義している監査ログの保管ポリシー（1年）で設定した Logs Storage をデプロイしています。念のため、Google Cloud 用のものと、Google Workspace 用のものとに分けておきました。
組織 (Organization) で設定した Log Router が、cloudpack サービス対象の Google Cloud プロジェクトや、サービスに携わる社員の Workspace ログを収集して、それぞれの Logs Storage に転送します。
Google Cloud プロジェクト側の方は、配下のものも収集できるようにしています。
一方、Workspace の方は組織に直接出るために Includes は付けなくて大丈夫です。
Google Cloud プロジェクト側の方は、このままだと大量のログを転送することになります。SOC2 で取り扱うログは Google Cloud リソースの変更操作に限ります。別で収集している Google Workspace 側のログや、サービスアカウントや基盤による自動的なシステム変更は除外しています。また、Get や List のような参照系も除外しています。
kubernatice コマンドの操作も踏み台側で取得しているので除外しています。
しばらく観測しつつチューニングしたものなので、もう少し整理できる余地はある気がしますが、以下のような除外条件で実装しました。
これで組織内の Google Cloud プロジェクト群に対する社員のシステム変更操作ログを横断的にモニタリングできるようになりました。
protoPayload.serviceName!="login.googleapis.com" AND protoPayload.authenticationInfo.principalEmail!~".gserviceaccount.com$" AND protoPayload.authenticationInfo.principalEmail!="system@google.com" AND protoPayload.methodName!="google.identity.oauth2.GetToken" AND protoPayload.methodName!="google.identity.oauth2.GetTokenInfo" AND protoPayload.methodName!="google.identity.oauth2.RevokeToken" AND protoPayload.methodName!="google.admin.AdminService.securityCenterRuleThresholdTrigger" AND protoPayload.methodName!="google.admin.AdminService.securityCenterRuleActionCompletion" AND protoPayload.methodName!="cloudsql.instances.connect" AND protoPayload.methodName!="jobservice.insert" AND protoPayload.methodName!="google.logging.v2.LoggingServiceV2.ReadLogEntriesLegacy" AND protoPayload.methodName!="google.logging.v2.LoggingServiceV2.AggregateLogs" AND protoPayload.methodName!="compute.autoscalers.resize" AND protoPayload.methodName!="iam.serviceAccounts.actAs" AND protoPayload.methodName!="jobservice.jobcompleted" AND protoPayload.methodName!="dns.changes.create" AND protoPayload.methodName!~".aggregatedList$" AND protoPayload.methodName!~".CheckStatus$" AND protoPayload.methodName!~".automatedBackup$" AND protoPayload.methodName!~".StreamGenerateContent$" AND protoPayload.methodName!~".FetchRepositoryHistory$" AND protoPayload.methodName!~"(?i).Get" AND protoPayload.methodName!~"(?i).List" AND protoPayload.methodName!~"(?i).Search" AND protoPayload.methodName!~"(?i).Query" AND protoPayload.methodName!~"(?i).Count" AND protoPayload.methodName!~"(?i).Read" AND protoPayload.methodName!~"(?i).Run" AND protoPayload.methodName!~".list$" AND protoPayload.methodName!~".get$" AND protoPayload.methodName!~"^List" AND protoPayload.methodName!~"^Get" AND protoPayload.serviceName!="k8s.io" AND protoPayload.serviceName!="recaptchaenterprise.googleapis.com"
ダッシュボードを使った可視化
次いで可視化の改善も行いました。
私の記憶では以前は BigQuery などの分析サービスが必要だった気がしますが、今は Cloud Storage 上のログも、SQL で分析可能です。
ここでかなりお世話になったものが以下のリポジトリです。
https://github.com/GoogleCloudPlatform/security-analytics/tree/main
非公式になりますので、その点は注意を。
This is not an officially supported Google product. Queries, rules and other assets in Community Security Analytics (CSA) are community-supported.
こちらのクエリを大いに参考に、ダッシュボードを作りました。
このダッシュボードを Google Workspace を管理する部門に共有し、不審な動きがあった際の対応の迅速化を図りました。
1_02_suspicious_login_attempt.sql の検出が目立ちますが、こちらは、Google Workspace にて不審なログインの疑いがあると判断されたものです。
通常、アイレットではゼロトラストネットワークで SSO によるログインになりますが、キッティング操作時にその経路を辿らないログインをしたものが大半になります。
これまではいずれも確認して問題なかったものだけでしたが、ちゃんと通常と異なるログインを検知してくれているのは安心です。
まとめ
Google Cloud のクラウド事業に対する SOC2 認証取得に向けた取り組みの一部を紹介させていただきました。サービスプロバイダ視点では SOC2 保証は大変ではあるものの、お客様視点では詳細な情報を提供し、サービス内容を詳細に把握した上でご利用いただけるようになります。プロバイダ視点でも、第三者の厳正な監査があるため、ごまかしが効かない安定したサービス提供を可能にします。
その中で、今回自身が取り組んだ対応を通して、自分自身も多くの学びを得られ、この知見をシステム構築にも流用できそうに感じております。
SOC2 を目指される方や、横断的な管理でお悩みの方に少しでも役に立てば、これ幸い。
