🦔

Professional Security Operations Engineer 試験完全攻略ガイド 2025

2025/09/19に公開

こんにちは、クラウドエースの小田です。

2025 年 9 月 16 日にリリースされた Google Cloud の最新認定資格である Professional Security Operations Engineer (PSOE) のベータ版試験を先月受験し、無事取得することができたため、「Professional Security Operations Engineer 試験完全攻略ガイド2025」 と題して、合格体験記＋攻略記事を残します。
この資格取得を目指す方に有益な情報となれば幸いです。

certified-badge

注意事項

試験を知る

出題背景と範囲

まず、認定試験ガイドを確認すると、大きく 6 つのセクションに分類されていることが分かります。

Platform operations (~14%)
- 検出と対応の強化
- アクセスの構成
Data management (~14%)
- セキュリティツールへのログ取り込み
- ユーザー、アセット、エンティティのベースライン識別
Threat hunting (~19%)
- 環境全体での脅威ハンティングの実行
- 脅威インテリジェンスの活用
Detection engineering (~22%)
- リスク検出と脅威特定のメカニズム開発・実装
- 検知への脅威インテリジェンスの活用
Incident response (~21%)
- セキュリティインシデントの封じ込めと調査
- レスポンス Playbook の構築・実装・使用
- ケース管理ライフサイクルの実装
Observability (~10%)
- 洞察を提供するためのダッシュボードとレポートの開発・維持
- ヘルスモニタリングとアラートの設定

試験ガイドから、この試験は単純な知識問題ではなく、実際のセキュリティ運用シナリオに基づいた実践的な問題が多く出題されることが推測されます。
そのため、Security Operations Center (以降、SOC) や Network Operation Center (以降、NOC) の経験、Google Security Operations (以降、SecOps) と Security Command Center (以降、SCC) の操作経験があることが前提になっています。

試験の対策

先に取得しておくことをおすすめする資格

Professional Cloud Security Engineer(PCSE): Google Cloud の一般的なセキュリティプロダクトについての理解
Associate Cloud Engineer(ACE): Google Cloud の基本の理解

推奨される準備方法

📚 必須ドキュメント
以下のドキュメントには目を通しましょう。

Google SecOps 公式ドキュメント: UDM、YARA-L、SOAR、データ取り込み方法など、試験の核となる技術要素の理解に必須
SCC 公式ドキュメント: Google Cloud の脅威検出と設定ミス検知機能の理解に必須
GTI 公式ドキュメント: GTI の活用方法と実践的な知識の習得に必須
YARA-L 2.0 公式ドキュメント: Detection Engineering セクションの検出ルールの技術習得に必須
MITRE ATT&CK Framework: 攻撃手法の分類と TTPs の理解、脅威ハンティングの基礎知識として必須
MISP 公式ドキュメント: オープンソースの脅威インテリジェンスプラットフォームの理解と外部 IoC 扱い方の習得に必須

🛠️ ハンズオン・オンデマンド学習

Google Cloud Skills Boost: 動画やハンズオンラボを通じて学習できます。

📝 理解度チェック

公式の模擬試験: 公式の模擬試験を受験しましょう。

💼 実務経験

SOC/NOC での運用経験
SIEM 製品の操作経験
インシデント対応経験

前提知識

セキュリティ専門用語

PSOE 試験では多くのセキュリティ専門用語が出題されます。必須ドキュメントに書いてある資料などを利用し、以下の用語を事前に理解しておくことが重要です。
IoC 等、いくつかの単語は、この記事中で説明しています。
また、用語間の関係性や実際のセキュリティ運用でどのように連携するかも併せて理解しておくと、より実践的な問題に対応できるようになります。

攻撃手法・脅威関連

C2(Command and Control): 攻撃者が侵害されたデバイスと通信するために使用するサーバー
APT(Advanced Persistent Threat): 高度な標的型攻撃
Lateral Movement: システム侵入後、ネットワーク内を横移動し侵害範囲を拡大していく攻撃
Privilege Escalation: 権限昇格攻撃
Credential Dumping: 資格情報の窃取
Backdoor: システムへの不正アクセスを可能にする侵入口
Ransomware: データを暗号化して身代金を要求するマルウェア
XSS(Cross-Site Scripting): Web アプリケーションに悪意のあるスクリプトを挿入し、不正操作を実行する攻撃

検出・対応関連

IoC(Indicators of Compromise): 侵害の痕跡・指標(後述)
TTPs(Tactics, Techniques, and Procedures): 攻撃者の戦術・技術・手順
False Positive: 偽陽性(正常な活動を脅威として誤認)
Threat Hunting: 能動的な脅威の探索・調査
Forensic: デジタル証拠の収集、保存、分析を含むインシデント後の分析
Dwell Time: 攻撃者の侵入から検出までの時間
Containment: 脅威の封じ込めを指す用語
Enrichment: 追加情報による文脈付加
CSPM(Cloud Security Posture Management): クラウド環境の設定状況を継続的に監視し、セキュリティの設定ミスやコンプライアンス違反を検出するソリューション
CWPP(Cloud Workload Protection Platform): クラウド上で実行されるワークロード（仮想マシン、コンテナ、サーバーレス関数など）を保護し、脅威を検出・防御するセキュリティプラットフォーム
CNAPP(Cloud Native Application Protection Platform): クラウドネイティブアプリケーションとその基盤となるインフラストラクチャをアプリケーションのライフサイクル全体にわたって統合的に保護する統合セキュリティソリューション。CSPM、CWPP は CNAPP のコンポーネントの一部として含まれています。

組織・運用関連

SOC(Security Operations Center): セキュリティオペレーションセンター。セキュリティ脅威を迅速に検出・特定し、被害を防ぐために、監視・調査・分析などを行うセキュリティインシデントに対応するための組織。
NOC(Network Operation Center): ネットワークオペレーションセンター。ネットワークの継続的な監視を担い、ネットワークの健全性、可用性の維持を行うための組織。
SIEM(Security Information and Event Management): セキュリティ情報・イベント管理
SOAR(Security Orchestration, Automation and Response): セキュリティ業務の自動化
EDR(Endpoint Detection and Response): ラップトップ、サーバーなどのエンドポイントデバイスからログを収集し、データ分析手法を使用して疑わしいシステム動作を検出し、コンテキスト情報を提供し、悪意のあるアクティビティをブロックし、影響を受けるシステムを復元するための封じ込めなどのレスポンスを提供するソリューション
NDR(Network Detection and Response): ネットワークトラフィックの継続的監視と高度な分析により異常挙動を検知し、封じ込めなどのレスポンスを提供するソリューション
UEBA(User and Entity Behavioral Analytics): ユーザーエンティティ行動分析
TIP(Threat Intelligence Platform): 脅威インテリジェンスプラットフォーム
MSSP(Managed Security Service Provider): マネージドセキュリティサービスプロバイダー

コンプライアンス・標準など

MITRE ATT&CK: MITRE Corporation というサイバーセキュリティ分野などで米国政府機関等をサポートする非営利組織が開発した攻撃手法の分類フレームワーク。実際の攻撃で観測された戦術 (Tactics) と技術 (Techniques) を体系的に整理し、脅威の分析や検出ルールの開発に広く活用される
CVE(Common Vulnerabilities and Exposures): 脆弱性識別子
PCI DSS(Payment Card Industry Data Security Standard): クレジットカード業界の国際セキュリティ基準
SLA(Service Level Agreement): サービス水準合意

技術基盤知識

その他、以下の知識・経験があると学習がスムーズに進みます。

セキュリティ運用の基礎知識 (SOC、SIEM、インシデント対応)
MITRE ATT&CK framework の理解
YARA-L 言語の基本構文
脅威インテリジェンスの基礎概念
MISP(Malware Information Sharing Platform): オープンソースの脅威インテリジェンスおよび共有プラットフォーム
Google Cloud の基本的なサービス理解

プロダクト概要

試験要項として公表されているプロダクトについて、要点のみ解説します。
すべて問われるというわけではありませんが、公表されているプロダクトですので概要は把握しておくことを推奨します。
可能な限り、「SecOps」と「SCC」の理解を深め、Google Cloud でどのように要件に対応していくかを理解しておくことを推奨します。

Google Security Operations(SecOps)

Google SecOps は、SIEM、SOAR、および脅威インテリジェンスを包括的に統合したサービスです。

主要コンポーネント

SIEM(Security Information and Event Management)
SOAR(Security Orchestration, Automation and Response)

ログの収集からアラートとしての検知までが SIEM の範囲で、SOAR は検知後のアラートや脅威の管理、分析、対応まで行います。
secops
イメージ図: 独自に作成したもので、公式のものではありません

ティア構成

Google SecOps には利用規模やニーズに応じて 3 つのティアが用意されており、それぞれ機能やサポート範囲が異なります。

機能	Standard	Enterprise	Enterprise Plus
SecOps SIEM	✅	✅	✅
SecOps SOAR	-	✅ + multi-environment(MSSP)	✅ + multi-environment(MSSP)
UEBA DIY	✅	✅	✅
Rules(YARA-L)	最大 1,000 の単一イベントルールと 75 のマルチイベントルール	最大 2,000 の単一イベントルールおよび最大 125 のマルチイベントルール	最大 3,500 の単一イベントルールおよび最大 200 のマルチイベントルール
Applied Threat Intelligence	お客様独自の IoC	Google OSINT のみ	Mandiant による深い知見、Google Threat Intelligence の完全アクセス権
GCTI Curated Detections	-	✅	✅ + Active IR など
Gemini	-	✅	✅
BQ UDM Storage	-	-	✅

SIEM/SOAR 取り込み方法の違い

SIEM と SOAR におけるデータ取り込み方法の違いを説明します。

項目	SIEM のログ取り込み	SOAR のアラート取り込み
対象データ	様々なソースからの「生ログデータ」	外部 SIEM や CSPM などが生成した「アラート(相関性のあるイベント)」
目的	ログの収集・正規化、アラート(相関性のあるイベント)、脅威の検知、分析、ハンティング	アラートの集約・管理、インシデント対応の自動化、MTTR (平均復旧時間)削減
取り込み後の処理	UDM への正規化、検索、検出ルールの入力	ケースへの集約、エンティティマッピング、Playbook による自動対応
主な方法	直接取り込み、Bindplane、Feed Management、Ingestion API	コネクタ (プル型)、Webhook (プッシュ型)

IoC matches

Google SecOps では、IoC matches という機能により取り込んだログイベントを Google が保有している IoC のソースと自動で関連付けを行います。

IoC(Indicators of Compromise) とは、侵害の痕跡を示すパターンのことです。例えば、既知の悪意のあるドメイン、IP アドレス、ファイルハッシュ、URL が IoC にあたります。
疑わしいイベントがあった場合、それらが IoC matches の画面で一覧で表示されるため、簡単にそのイベントの詳細を追跡できます。

Curated Detections

Google Cloud Threat Intelligence (GCTI) チームにより事前定義された脅威検出ルールを提供する機能です。
各ルールの設定を有効にすると、そのルールで定義された不審な振る舞いのパターンが確認された際に、検知し表示されます。

UDM (Unified Data Model)【重要！】

SecOps が使用する統一データモデルであり、異なるログソースを共通フォーマットに正規化する役割を担います。
YARA-L 検出ルールや UDM Search で利用される重要な概念です。

YARA-L 検出ルールや UDM Search で使用するクエリはすべて手動で記述することも可能ですが、Gemini を使用して自然言語からルールを生成することも可能です。

一部抜粋してご紹介します。
基本構造:

principal: 動作主体(ユーザ、プロセス等)
target: 対象(ファイル、ネットワーク等)
network: ネットワーク関連情報
metadata: イベントメタデータ

重要フィールド詳細:

metadata.event_type: イベントタイプ
- NETWORK_CONNECTION: ネットワーク接続
- NETWORK_DNS: DNS 問い合わせ
- PROCESS_LAUNCH: プロセス起動
- USER_LOGIN: ユーザーログイン
ユーザー関連:
- principal.user.userid: 実行ユーザーID
- target.user.userid: 対象ユーザーID
- principal.user.type: ユーザータイプ (service_account 等)
ネットワーク関連:
- principal.ip: 通信元 IP
- target.ip: 通信先 IP
- principal.port: 送信元ポート
- target.port: 宛先ポート
- network.dns.questions.name: DNS 問い合わせ対象
- network.application_protocol: アプリケーションプロトコル
プロセス関連:
- principal.process.command_line: 実行コマンドライン
- principal.process.pid: プロセス ID
- target.file.md5, target.file.sha256: ファイルハッシュ

エンティティコンテキスト

Google SecOps 内で関連データの結合やエンリッチに使用されるコンテキストデータです。

ソースタイプ

Entity Context: ユーザーが SIEM に登録したコンテキスト。例: Entra ID Audit や Okta、Google Workspace などから取得されるアセットやユーザーグループ。
Derived Context: ユーザーのデータから自動計算されたコンテキスト。例: 初観測日時、最終観測日時、出現頻度など。
Global Context: Google Threat Intelligence、Google セーフブラウジングなどから提供されたコンテキスト。例: Whois、セーフブラウジング、Tor の出口ノード情報データ。
Unspecified Context: 一般的ではない、または予想されないコンテキストデータ。

エンティティタイプ

エンティティタイプとは、Google SecOps が扱う様々なエンティティを正規化し、共通の形式で分類するためのものです。
様々なソースから収集されたエンティティデータは、この共通のエンティティタイプにマッピングされ、エンティティ間の関係性に基づいたエンティティグラフという隣接リストに保持されます。

主要なエンティティタイプ

ASSET: 組織が所有するリソース(例：端末、サーバー)。主に ServiceNow CMDB などの Entity Context から取得されます。
DOMAIN_NAME: 観測されたドメイン名。Derived Context として記録され、IoC matches に使用されます。
FILE (HASH): 観測されたファイルハッシュ。Derived Context として記録されるか、IoC matches の用途で使用されます。ただし、IoC matches 以外の目的でファイルエンリッチデータとして Entity Context は使用できません。
GROUP: ユーザーグループ情報。Entity Context で使用されます。
IP_ADDRESS: IP アドレス情報。通常は graph.entity.hostname, graph.entity.ip などのアセットの一部として含まれますが、主に IoC matches に使用されます。
MUTEX: IoC matches に使用できます。
RESOURCE: クラウドベースのリソース(オブジェクトストレージ、IAM、データベースなど)。Entity Context の一部として使用されます。
URL: IoC matches 用途で Entity Context または Global Context から使用されます。
USER: ユーザー情報(例：Active Directory)のエイリアスやエンリッチに使用されます。IoC matches (例：メールアドレス)にも使用できます。

YARA-L 検出ルール【重要！】

VirusTotal の YARA に由来する Google SecOps SIEM の検出ルール構文であり、UDM に準拠した共通フィールドでルール作成が可能です。

rule <rule Name> {
  meta:
    // 必須
    // ルールの詳細情報(作成者、検出対象、説明、重要度、Mitre ATT&CK の TTPs、バージョン管理など)

  events:
    // 必須
    // UDM イベントの条件を指定

  match:
    // 省略可能(マルチ イベント ルールでは必須)
    // `events` セクション内で定義されたプレース ホルダー変数に基づいて、結果をグループ化

  outcome:
    // 省略可能
    // 調査に関する追加のコンテキストを提供するために使用

  condition:
    // 必須
    // 検出を発生させるために一致する必要があるイベントなどを記載

  options:
    // 省略可能
    // このルールの動作方法を変更するためのオプション
    // allow_zero_values = <true or false>
}

基本構文

シングルイベント検出:
1 つのイベントが存在するかどうかを確認するルールの例です。

rule single_event_rule {
  meta:
    author = "example@example.com"

  events:
    $e.metadata.event_type = "USER_LOGIN"

  condition:
    $e
}

マルチイベント検出:
特定の期間の複数のイベントをグループ化し、イベント間の相関関係を特定する際に利用するルールの例です。

rule multi_event_rule {
  meta:
    author = "example@example.com"

  events:
    $e.metadata.event_type = "USER_LOGIN"
    $e.principal.user.userid = $user

  match:
    $user over 10m

  condition:
    #e >= 10
}

外部 IoC エンティティの活用：
フィードを通じて取り込んだ MISP の IoC データと相関するイベントを検出するマルチイベントルールの例です。

rule ioc_detection {
  events:
    $dns.metadata.event_type = "NETWORK_DNS"
    $dns.network.dns.questions.name = $dns_query

    $ioc.graph.metadata.product_name = "MISP"
    $ioc.graph.metadata.entity_type = "DOMAIN_NAME"
    $ioc.graph.metadata.source_type = "ENTITY_CONTEXT"
    $ioc.graph.metadata.threat.summary = "C2 domains"
    $ioc.graph.entity.hostname = $dns_query

  match:
    $dns_query over 5m

  condition:
    $dns and $ioc
}

SIEM のデータ取り込み

Feed

Google SecOps の Feed は、様々なデータソースから自動的にログデータを取り込むための機能です。

Feed の動作プロセス

データソース接続: 設定されたソースから定期的にデータを取得
正規化処理: 取得したデータを UDM(Unified Data Model) 形式に変換
取り込み実行: 正規化されたデータを Google SecOps に保存

Feed エラーの種類と対処法

Feed のエラーと対処方法を一部抜粋して紹介します。

LOGIN_FAILED
- エラー概要: データソースへの接続は確立されたが、認証情報が誤っている
- 対処: 認証情報の確認・再設定
PERMISSION_DENIED
- エラー概要: 認可されていないため、アクセスが拒否された
- 対処: 必要なアクセス権限の追加・確認
INVALID_FEED_CONFIG
- エラー概要: Feed 構成に誤りがある
- 対処: Feed 構成の見直し
HTTP_404
- エラー概要: ファイルやリソースが存在しない
- 対処: ファイル・リソースの存在確認、アクセス権の確認
CONNECTION_FAILED
- エラー概要: データソースの IP アドレスとポートに到達できない状態
- 対処: 接続先の確認、ファイアウォール設定の確認

直接取り込み

Google Workspace、Google Cloud の Audit Log、SCC の Security Health Analytics や Threat Detections の検出結果 (Findings) などを取り込む際に利用します。

クラウド取り込み

Cloud Storage、S3 や Azure Blob バケットに保存されているデータをスケジュールに従って Feed で転送します。

Ingestion API

ログデータを Google SecOps に直接送信するための機能です。

Forwarder

オンプレミスやクラウド上の各種ログを Google SecOps に転送する専用エージェントです。
多様なデータソース (Syslog、ファイル、クラウドストレージ等) に対応しています。
現在は後述する Bindplane ですべての役割を担うことができます。

Bindplane

オンプレミスやサードパーティシステムからログを収集できるエージェントです。
Google SecOps のライセンスを持っていると無料で利用できます。

Bindplane についてや、Bindplane を使ったログ取り込み方法は以下の記事で解説しています。

Bindplane Agent が止まるとログが送られなくなるため、Events Per Second(EPS) を監視し、ログ収集状況を監視できるように設定することをおすすめします。

ケース管理

SOAR では SIEM で発報されたアラートを自動的に 1 つのケースとしてまとめ、優先順位付け、担当者の割り当て、エスカレーションを実施するためのケース管理機能があります。

ケース管理方法については、以下の記事で解説しています。

Playbook

自動化されたセキュリティ対応ワークフローであり、アラート検証、対応、エスカレーションを自動実行します。

使用例:

自動エンリッチ: VirusTotal、脅威インテリジェンス API での IoC 調査
封じ込め: エンドポイント隔離、アカウント無効化の自動実行
外部チケット管理サービス連携: Service Now や Jira などへの連携

VirusTotal Integration

マルウェア分析とエンティティのエンリッチに利用できる重要な外部連携サービスです。

主要用途

ファイルハッシュ分析: ファイルハッシュを用いた脅威判定
URL・ドメイン分析: URL やドメインの安全性確認
Entity Graph Integration: 自動エンリッチ、VirusTotal の情報による精度向上
SOAR Playbook: 自動化ワークフローでの活用

False Positive (偽陽性) 対策【重要！】

SecOps を効果的に運用するには、False Positive (偽陽性) を適切に処理し、将来の発生を抑止する仕組みが不可欠です。

偽陽性とは、実際には脅威ではない正常な活動を、誤って脅威として検知してしまうことです。
偽陽性が多発すると、アナリストの疲弊や本当に重要なアラートの見逃しにつながるため、SecOps の運用において重要視されるトピックです。

一方で、偽陽性を減らすために検出しきい値を下げるなどの対応を行ってしまうと、今度は False Negative (偽陰性) が発生し、実際の攻撃を見逃してしまうリスクが高まります。
偽陰性はセキュリティ侵害を招く可能性があるため、偽陰性の発生レベルを変えずに偽陽性だけを減らすことが重要ですが、これは非常に難しい課題です。

また、偽陽性は利用環境や組織の特性に依存する面も大きく、検出ルールの調整だけでは完全に解決できません。
そのため、運用面での対策により同じ偽陽性が繰り返し検出されないようにすることで、運用負荷を改善し、アナリストがより重要な脅威に集中できる環境を整備することが求められます。

False Positive に対するアプローチ

ワークフローの分岐: Playbook の初期段階で、アラートが「True Positive(実際の脅威)」か「False Positive(偽陽性)」かを判断するステップを設けます。
タグ付けによる可視化: 誤検知と判断されたケースは、クローズする際に「False Positive」などの一貫したケースタグを付与することで、後から誤検知の傾向を分析したり、レポートやダッシュボードで関連メトリクスを追跡する際に活用できます。
カスタムリストによる再発防止: 既知の誤検知であると特定されたエンティティ(IP アドレスやファイルハッシュなど)は、カスタムリストに追加します。カスタムリストを活用することで、特定のアラートに、カスタムリストに存在するエンティティを含む場合、同じ要因による重複したアラートの発生を抑制できます。
学びの記録: False Positive のワークフローには、Lessons Learned Block (教訓ブロック) を追加し、学びを記録することで検出ルールのチューニングやプロセスの改善に繋げることができます。
その他: YARA-L 検出ルールの condition セクションで適切なしきい値を設定することで、False Positive を減らすことが期待できます。

Security Command Center(SCC)

Security Command Center(SCC) は、Google Cloud 上で使用しているサービスの脆弱性や脅威となりうる設定を検知することができるサービスです。

ティア構成

SCC には利用規模やニーズに応じて 3 つのティアが用意されており、それぞれ機能やサポート範囲が異なります。

機能	Standard	Premium	Enterprise
マルチクラウド対応	-	-	✅
Security Health Analytics	△	✅	✅
Threat Detection 系	△	✅	✅
Web Security Scanner	△	✅	✅
Attack Path Simulation	-	✅	✅
AI Protection	-	-	✅
CIEM	-	-	✅
DSPM	-	-	✅
Google SecOps (機能制限版)	-	-	✅
Assured OSS	-	-	✅

主要機能

Security Health Analytics(SHA): 設定ミス検出
Event Threat Detection: リアルタイム脅威検出
Virtual Machine Threat Detection: Compute Engine VM 上のクリプトマイニング、マルウェアなどの脅威検出
Container Threat Detection: Google Kubernetes Engine コンテナや Cloud Run の脅威検出
Web Security Scanner: Web アプリ脆弱性診断
Attack Path Simulation: 攻撃パスシミュレーション
AI Protection: Model Armor など、AI ワークロードを保護する機能
CIEM: ID に関する構成ミス検出
DSPM: Sensitive Data Protection と連携してデータを保護
Assured OSS: Google が脆弱性のスキャン、分析、ファジングテストを行った OSS パッケージを、自社の開発プロジェクトに安全に組み込むことができる機能です。特にコンテナ環境では、Container Threat Detection と組み合わせることで、信頼できる OSS パッケージの使用と実行時の脅威検出による多層防御を実現できます。

Google Threat Intelligence(GTI)

Google Threat Intelligence (以降、GTI) は、Google 独自の脅威インテリジェンスとサードパーティの脅威インテリジェンスを統合し、セキュリティチームが脅威を特定、調査、対応するのを支援するサービスです。

主要機能詳細

Threat Landscape: 業界で活動している脅威グループを特定し、その IoC、MITRE ATT&CK 戦術、TTPs などを調査

Digital Threat Monitoring: ダークウェブ、ディープウェブに掲載された情報(攻撃予告や顧客情報)を監視し、自社ブランドや製品名といったキーワード設定によるモニタリング

IoC Collections: IoC 共有・管理

私が Google Threat Intelligence のワークショップに参加した際の記事で GTI の機能について紹介しているため、こちらも参考になるかと思います。

その他 Google Cloud プロダクト

Cloud Audit Logs

アクセスが許可されたとき、拒否されたとき等、イベント発生時に Cloud Logging にログを記録します。
主要ログタイプにあるタイプ別に設定が可能です。Google Cloud を監視する上で最も重要なデータソースです。

主要ログタイプ

Admin Activity audit logs: VM インスタンスの作成・変更などのリソース設定変更の記録(要設定)
Data Access audit logs: リソース構成やデータの読み書きアクセスのログ(要設定)
System Event audit logs: リソース構成を変更する Google Cloud システムによって書き込まれるログ(デフォルト有効)
Policy Denied audit logs: セキュリティポリシー違反を理由にGoogle Cloud サービスがユーザーまたはサービスアカウントへのアクセスを拒否したときに書き込まれるログ(デフォルト有効)

Audit Manager

Audit Manager は、組織のコンプライアンス要件に基づいて各種リソースの設定を監査し、レポート生成を自動化するサービスです。
自動でワークロードを評価し、PCI DSS、CIS Controls、ISO 27001:2022 などのコンプライアンス基準を満たしていることの検証や、ユーザー独自コンプライアンス基準を満たしていることの検証ができます。

BigQuery

SecOps のデータエクスポート先として BigQuery データセットを使用できます。(Enterprise Plus ティアのみ)
UDM レコードや、フォワーダーの統計情報、エンティティに関する情報などを保存することができます。

権限管理

SecOps 用の IAM ロールと、SecOps 特有のアクセス制御については出題される可能性があるため抑えておきましょう。

SecOps の事前定義ロールと権限

ダッシュボードへのアクセスや、パーサー管理 UI などへのアクセス制御をしたい場合、Google SecOps 用の Google Cloud プロジェクトの IAM でアクセス制御を行います。

Workforce Identity Federation

Google SecOps の認証に組織の Cloud Identity や Google Workspace 以外のサードパーティーの IdP を利用したい場合、Workforce Identity Federation を利用します。

設定方法

Identity Provider(IdP) の準備: ユーザー認証、ユーザーグループの定義、SAML 2.0 アプリケーションのために、Okta、Entra ID などの IdP を利用する。
Cloud IAM Workforce Identity Federation の設定: IdP と Google Cloud を連携させるための Workforce Identity Pool と Workforce Identity Provider を Organization レベルで設定。
Cloud IAM ポリシーの作成: IdP で定義されたユーザーグループと SecOps の IAM ロール(役割)を紐付けるポリシーを、SecOps に紐付けられた Google Cloud プロジェクト内に設定。
SecOps アクセス用の管理者グループの作成や、SAML アプリケーションの作成、SAML 属性(groups, first name, last name, email など)のマッピングを行う。

データ RBAC と機能 RBAC の違い

Google SecOps には、ユーザーがロールに基づいてデータを表示、編集、削除できるかどうかを制御するデータ RBAC と、ダッシュボードなどの特定の機能へのアクセス制御を行う、機能 RBAC があります。

データ RBAC: 特定のデータや情報へのアクセスを制御
機能 RBAC: 特定の機能へのアクセスを制御

試験準備

先に取得しておくべき資格

冒頭でも述べたとおり、以下の資格については必須知識と言えるほど基礎的なものです。
まだ取得していない方はまずはこちらを取得して Google Cloud の基礎を学び、そのうえで応用として本試験にチャレンジすることを強く推奨します。

Professional Cloud Security Engineer(PCSE)
Associate Cloud Engineer(ACE)

模擬試験

公式案内にもある通り、模擬試験を受験してご自身の理解度をチェックしてみてください。
必ずしも模擬試験の傾向や問題そのものがそっくり出題されるわけではありませんが、あくまで参考値として理解度を知ることができます。
(ここで点数が取れなくても落ち込むほどのものではありません)

模擬試験を受けて、Security Operations Engineer 試験で出題される可能性のある質問の形式と内容を把握します。

試験申し込み

ここまできたら試験を申し込むだけです。
Webassessor にて任意の日時で受験申し込みをし、当日受験をすれば完了です。
資格試験あるあるですが、受験申し込みをするまでに自らを奮い立たせるのが 1 番の難関です。

結果受領

合格すると以下のようなメールが届きます。
pse_successfull_mail_noti
SS:合格通知

おわりに

ベータ版の試験を受験した感想 (2025/08)

Google SecOps を全く触ったことがない方にとっては相当難易度が高く、セキュリティ運用についての実践的な判断力が問われる試験です。
「なぜその選択肢が最適なのか」の理由を深く理解していないと回答できない問題が多かった印象です。
例えば、検出ルールの YARA-L 言語の構文や適切な UDM フィールドの選択、SOAR Playbook の設計判断などです。

一方で、Google SecOps の基本概念をしっかり理解し、Google SecOps の運用に慣れ親しんでいれば、決して手の届かない試験ではないと思います。
そのため、デモ環境でも良いので Google SecOps を触っていただくことをおすすめします。

まとめ

最後まで読んでいただきありがとうございます。
ここまで読んで理解を深めることができれば、合格に必要な知識については十分お持ちのはずです。
よい結果を迎えられることを祈ります。

また、Google Cloud 認定試験は随時内容が更新されるため、この記事を閲覧された方は可能な限りお早めの受験を推奨します。

注意事項

試験を知る

出題背景と範囲

試験の対策

先に取得しておくことをおすすめする資格

推奨される準備方法

前提知識

セキュリティ専門用語

技術基盤知識

プロダクト概要

Google Security Operations(SecOps)

主要コンポーネント

ティア構成

SIEM/SOAR 取り込み方法の違い

IoC matches

Curated Detections

UDM (Unified Data Model)【重要！】

エンティティ コンテキスト

エンティティ タイプ

YARA-L 検出ルール【重要！】

SIEM のデータ取り込み

Feed

Feed の動作プロセス

Feed エラーの種類と対処法

直接取り込み

クラウド取り込み

Ingestion API

Forwarder

Bindplane

ケース管理

Playbook

VirusTotal Integration

主要用途

False Positive (偽陽性) 対策【重要！】

Security Command Center(SCC)

ティア構成

主要機能

Google Threat Intelligence(GTI)

主要機能詳細

その他 Google Cloud プロダクト

Cloud Audit Logs

主要ログタイプ

Audit Manager

BigQuery

権限管理

SecOps の事前定義ロールと権限

Workforce Identity Federation

データ RBAC と機能 RBAC の違い

試験準備

先に取得しておくべき資格

模擬試験

試験申し込み

結果受領

おわりに

ベータ版の試験を受験した感想 (2025/08)

まとめ

Discussion

エンティティコンテキスト

エンティティタイプ