🤘
Professional Security Operations Engineer 認定試験範囲の解説 2026

クラウドエース株式会社
2026/05/18に公開
こんにちは。クラウドエース株式会社で Google Cloud 認定トレーナーをしている廣瀬 隆博です。

ヘヴィメタルのライブに行くと、ステージ前ではモッシュやダイブといった 激しい自己表現 が繰り広げられます。セキュリティ（警備員）の方々は最前線でファンが怪我をしないよう、そしてステージに侵入しないよう必死に防御してくれています。しかし、どれだけ強固な警備体制を敷いていても、熱狂のあまりステージ前の柵を越えてしまうファン はゼロにはなりません。そんな時、大切なのは 「絶対に越えさせないこと」以上に、「越えられてしまった後、いかに素早く安全を確保し、事態を収拾するか」 だったりします。
実は、昨今のサイバー セキュリティの世界でも同じ考え方となっています。今回は、そういった「新しい考え方を実現する仕組みから具体的な技術要素」まで、幅広く解説していきます。Professional Security Operations Engineer 認定試験の解説記事 ではありますが、サイバー セキュリティに関してこれから学習していきたい方にもおススメの内容 となっております。是非お読みいただけますと幸いです。

 本記事を読み始める前に本記事は Professional Security Operations Engineer の認定試験範囲について解説するものであり、IT システムやサイバー セキュリティに対して、ある程度の知識・経験を保有している方に向けた内容となっています。どなたにも理解いただけるように、なるべく平易な表現を心がけておりますが、あらかじめご了承ください。

 解説画像に関して本ブログでは、Gemini が生成した画像を使用しています。そのため、文字化けや分かりづらい表現などが含まれていることがあります。公開前にチェックしていますが、そういった画像が含まれていた際はご容赦ください。

 試験範囲の概要解説を始める前に、そもそもどんな試験なんだ？ ということに少し触れておきましょう。
https://cloud.google.com/learn/certification/security-operations-engineer?hl=ja
本記事の執筆時点では、公式 Web サイトに以下の概要が書かれていました。
ワークロード、エンドポイント、インフラストラクチャに対するセキュリティ上の脅威を検出、監視、分析、調査し、対応します。Google Cloud リソースを使用して企業環境を保護する役割であり、検出ルールの作成、ログの優先順位付けと取り込み、オーケストレーション、対応の自動化に精通していることが求められます。さらに、脅威の検出と対応のためのセキュリティ ポスチャーと脅威インテリジェンスの活用経験も求められます。
この時点で 試験の難易度が高そうに感じられますが、実際にその通り ですね。私も最初にこれを読んだときはチンプンカンプンでした。少しずつ紐解きながら解説していきますので、本記事を読み終えた後には理解できるようになっていることでしょう。
そんな背景もあり、Security Operations（以下、SecOps と表記） 自体の話をする前に、まずは前提となる知識から解説してまいります。

 前提知識
IT システムのセキュリティと聞いて、皆さんはどのような対策を思い浮かべるでしょうか。多くの方は、ファイアウォールやアンチ ウイルスソフトを導入し、いかに悪意のある攻撃者の組織ネットワークへの侵入を防ぐか ということをイメージするかもしれません。これは高く分厚い城壁を築くようなもので、「境界防御」や「予防」に重点を置いた従来型のセキュリティ対策です。

しかし現代において、この「いかに侵入を防ぐか」という考え方だけでは、組織を完全に守りきれない時代になっています。その背景には、サイバー攻撃の著しい高度化 があります。攻撃者の手口は日々巧妙になり、正規のユーザーを装って認証情報を盗み出すフィッシング攻撃や、まだ対策が確立されていない未知の脆弱性を突くゼロデイ攻撃など、どれだけ城壁を高くしても、あの手この手で内部に侵入されてしまう のが現実です。また、クラウド サービスの普及やリモートワークの拡大により、かつてのように 「社内は安全、社外は危険」という明確な境界線を引くこと自体が難しくなっています。
これからの時代は、侵入されることを前提 として考えなければなりません。つまり、どんなに強固な予防策を講じても「いつかは壁を越えられてしまう」という前提に立ち、侵入された後、いかに速くその異常を見つけ出し（検知）、被害が拡大する前に対処して復旧するか（対応） にシフトしているのです。

この「検知と対応」のスピードと精度こそが、現代の組織を守る最大の鍵となります。そして、脅威を迅速に見つけて対処するための、一連の継続的な運用プロセスを実現するために SecOps が用いられます。
なお、SecOps はセキュリティ戦略を示す言葉であると同時に、後述する Google Cloud が提供するサービスである Google Security Operations にも含まれる用語です。本記事では、この両方の側面について解説しますが、特に区別を意識せずとも読み進めることができます。

 SecOps
SecOps とは、組織のシステムやネットワークに対するセキュリティ上の脅威を迅速に検出、特定し、被害を防ぐために監視・調査・分析などを行う一連の運用プロセスのことを指します。その土台となる活動は「モニタリング（監視）」であり、ファイアウォールなどの様々なセキュリティ ツールから送られてくるログを観察し、潜在的なセキュリティ イベントの兆候（異常やアラート）を検知することから始まります。

そして、この SecOps のプロセスを専門に実行し、組織をサイバー攻撃から守るための組織やチームの総称を Security Operations Center（以下、SOC と表記） と呼びます。いわば、サイバー空間における「防衛の最前線基地」ですね。

ネットワークの健全性を維持する Network Operations Center（以下、NOC と表記）とは異なり、SOC はセキュリティ脅威への対応に特化しています。
SOC は Security Information and Event Management（以下、SIEM と表記） や Security Orchestration, Automation and Response（以下、SOAR と表記） を用いてアラートに対応します。SecOps の活動を理解するために、まずはこれらを順に解説していきます。

 SOC
日々膨大に発生するアラートに対応するため、SOC の内部は対応のレベル（Tier）ごとに役割分担されている のが一般的です。高度な組織では、以下のような体制でインシデントに立ち向かいます。

Tier 1 : トリアージ スペシャリスト
最初にアラートを受け取る「第一応答者」です。アラートの初期評価を行い、それが誤検知なのか、本当の脅威なのかを見極め、優先順位（トリアージ） をつけます。対応が必要と判断した場合は、速やかに詳細なデータを添えて Tier 2 へ引き継ぎ（エスカレーション） ます。


Tier 2 : インシデント対応者
Tier 1 から引き継がれたインシデントを深く調査する「中核的な調査員」です。脅威の根本原因や影響範囲を特定し、被害が広がらないようネットワークから隔離するなどの 封じ込め（Containment） や復旧手順を実行します。


Tier 3 : 脅威ハンター
より高度で重大なインシデントに対応するエキスパートです。また、平時にはアラートが鳴るのを待つのではなく、自ら能動的にログを探索し、システムに潜伏している未知の脅威を探し出す 脅威ハンティング を行います。


SOC マネージャ
SOC チーム全体を統括するリーダーです。重大なインシデントが発生した際には、他の部門の責任者や 最高情報セキュリティ責任者（CISO）といった経営トップ、さらには外部機関とのコミュニケーション窓口としての責任を担います。

このように、SecOps とは単にツールを導入して終わるものではなく、ツールが発した警報を専門のチームである SOC が連携して処理し、被害を最小限に食い止めるための 人とプロセスの総合力 なのです。

 SIEM
SIEM は、日本語では「セキュリティ情報・イベント管理」と訳されます。一言で例えるなら、組織のネットワーク全体を見渡す 「超高性能な防犯カメラ ネットワーク（目）」であり、そこに映った膨大な映像から異常を瞬時に見つけ出す「AI（頭脳）」 のようなシステムです。

 SIEM の必要性
現代の企業環境では、パソコン、サーバー、ファイアウォール、クラウド サービスなど、ありとあらゆる IT 機器やシステムが 日々膨大な量のログを出力 しています。例えば、「誰が何時にログインしたか」「どの IP アドレスと通信したか」といった動作の記録です。

攻撃者は、この 膨大な正常なログの海の中に、自身の攻撃の痕跡（異常な通信や不審なファイルの実行など）を巧妙に隠して侵入してきます。 これを人間が 1 行ずつ目で見て異常を探し出すのは、それこそ砂浜から一粒のダイヤモンドを探すようなもので、現実的ではありません。

 相関分析
SIEM は、組織中のあらゆる機器から送られてくるログデータを一元的に収集・保管します。そして、単にログを集めるだけでなく、異なるシステムから送られてきたバラバラのログ同士を繋ぎ合わせる 「相関分析」 をリアルタイムで行います。
例えば、以下のような個別の出来事があったとします。
（深夜2時に）ある従業員が社内システムにログインした
（直後に）その従業員のアカウントで、普段は触らない機密データのフォルダにアクセスした
（さらに直後に）外部の見知らぬサーバーに向けて大量のデータ送信が発生した
1 つ 1 つのログだけを見れば「ただのログイン」や「ただの通信」として見過ごされてしまうかもしれません。しかし、SIEM は これらの「点」のログを線で結び合わせ、「これは通常ではありえないパターンの行動（情報漏洩の兆候）だ！」と自動的に判断し、SOC チームにアラート（警報）を発する のです。
つまり、SIEM という「目と頭脳」があるからこそ、SOC チームは隠れた脅威にいち早く気づき、迅速なインシデント対応（防衛）を開始することができるのです。

 SOAR
前項で解説した SIEM が、脅威を見つけ出す「目と頭脳（高性能な防犯カメラとAI）」だとしたら、異常を検知した後にどうするべきでしょうか？ 従来は、警報が鳴るたびに担当者が慌てて状況を確認し、手作業で対処していました。しかし、それではサイバー攻撃のスピードに到底追いつけません。

そこで登場するのが、SOAR です。SOAR は、異常を検知した瞬間に、あらかじめ決められたマニュアルどおりに即座に動いてくれる『自動で駆けつける警備員』 のような存在です。

SIEM などで検出された脅威やアラートに対して、複数のセキュリティツールを連携（オーケストレーション）させ、対応プロセスを自動化（オートメーション）するソリューションを指します。

 Playbook
SOAR の最大の特徴は、Playbook と呼ばれる自動化ワークフローです。インシデントが発生した際、セキュリティ担当者（アナリスト）は通常、以下のような多くの手作業に追われることになります。
「アクセス者の IP アドレスは本当に危険か？」を外部の脅威データベースに問い合わせて調べる
危険だと判明したら、被害が広がらないようにアクセス先のデバイスをネットワークから隔離する

関係部署に Slack やメールで警告を送る
チケット管理システムにインシデントを起票する
SOAR を導入すると、これらの「毎回必ずやる定型作業」をプレイブックとして設定しておくことで、アラートが鳴った瞬間にシステムがすべて自動で実行されます。 つまり、これまで人手に頼っていた 初動対応が数秒から数分で完了する ようになるわけです。

これにより、インシデントへの対応時間が劇的に短縮されるだけでなく、夜間や休日であっても、担当者のスキルに依存しない「常に一定の品質での対応」が可能になります。

また、日々大量に発生するアラートに人間が対応し続ける「アラート疲れ」からエンジニアを解放し、彼らが より高度な「脅威ハンティング（未知の脅威探し）」などの重要な業務に集中できる環境を作り出す ことができるのです。

 SIEM と SOAR の連携
ここまで、脅威を見つけ出す SIEM と、自動で対処する SOAR について解説してきました。この 2 つはそれぞれ単独でも優れた機能を持っていますが、真の力を発揮するのは 両者をシームレスに連携させた時 です。

例えるなら、高性能な防犯カメラ（SIEM）が泥棒の侵入を検知しても、モニターを見ている人間が電話で警備員を呼んでいては、到着するまでに被害が拡大してしまいます。しかし、カメラが異常を検知した瞬間にシステムが連動して、自動的にすべてのドアをロックし、近くを巡回している警備員（SOAR）に直接出動指令が飛ぶ仕組みになっていたらどうでしょうか。泥棒に目的を達成させる隙を与えにくくなります。
サイバー セキュリティの世界では、SIEM と SOAR が連携することで、以下のようなメリットが生まれます。
インシデント対応時間の劇的な削減
セキュリティ運用の世界には、チームの対応効率を測る 平均対応時間（Mean Time to Respond、以下 MTTR と表記） という重要な指標があります。これは、アラートを検知してからインシデントを封じ込め、修復するまでにかかる平均時間のことです。SIEM と SOAR が連携していると、SIEM が不審な動きを「検知」した瞬間、人間の判断や手作業を待たずに SOAR のプレイブックが起動し、情報収集や初期の「隔離（封じ込め）」を自動実行します。これにより、これまで数時間から数日かかっていた対応が数秒から数分で完了するようになり、MTTR を劇的に削減できる のです。

攻撃者の潜伏時間を最小化
もう一つの重要なキーワードが 潜伏時間（Dwell Time） です。これは、攻撃者がシステムに侵入してから、防御側に検出・対応されるまでの時間を指します。攻撃者は、侵入後にすぐ破壊活動を行うのではなく、長期間システム内に潜伏し、より権限の高いアカウントを奪ったり、重要なデータを探し出したりします。SIEM の高度な分析力で潜伏時間を極限まで短縮し、見つけ次第 SOAR で即座にネットワークから切り離す。この連携によるスピード感こそが、被害を未然に防ぐ、あるいは最小限に食い止めるための最大の武器 です。

つまり、SIEM と SOAR の連携は、単なる「運用担当者の業務効率化」にとどまらず、攻撃者とのスピード勝負に勝つ ための現代における必須の戦術なのです。

 脅威インテリジェンスSIEM と SOAR の連携による自動防衛網が完成したとしても、そもそも「何が危険な攻撃なのか」を知らなければ、システムは脅威を見つけることができません。

そこで不可欠になるのが 脅威インテリジェンス（Cyber Threat Intelligence : CTI） です。
一言で例えるなら、世界中の警察機関からリアルタイムで送られてくる 世界規模のサイバー犯罪者の指名手配リストや手口のデータベース です。

「今、世界でどんな新しいサイバー攻撃が流行しているのか」「どの IP アドレスが悪意のあるハッカーのものか」「最新のマルウェアはどんな特徴を持っているのか」といった、世界中から収集・分析された最新の脅威情報の集合体を指します。
このインテリジェンスを自社のセキュリティ システムに取り込むことで、昨日まで世界に存在しなかったような最新の攻撃手法（ゼロデイ攻撃など）に対しても、いち早く気づき、防御の網を張ることができるようになります。

 統合プラットフォームの登場
これまでは「見つけるための SIEM」と「自動で対応するための SOAR」を別々のシステムとして解説してきましたが、最新のセキュリティ業界では、これらが最初から 一つに統合されたプラットフォーム が主流になりつつあります。

例えるなら、防犯カメラシステムと警備会社のシステムを別々に契約して無理やり繋ぎ合わせるよりも、最初から完全に連動するように設計された「オールインワンの最新セキュリティ システム」を導入した方が、連携もスムーズで圧倒的に管理が楽ですよね。

Google Cloud が提供する Google Security Operations（以下、Google SecOpsと表記） もその 1 つであり、本試験ではこのサービスに関する知識が問われます。
Google SecOps は、ここまで解説してきた SIEM と SOAR の機能に加えて、脅威インテリジェンスまでを包括的に統合したサービスです。Google ならではの、以下のような強力な特徴を持っています。
Google の叡智との融合
世界トップクラスのセキュリティ専門家集団である「Mandiant」の知見や、「Google Threat Intelligence」の最新情報が最初から組み込まれています。つまり、世界のどこかで新しい攻撃手法が発見されれば、その高度な情報がすぐに自社の防御システムに反映され、未知の脅威が自動的に検出されます。

ペタバイト級の圧倒的な処理スピード
Google 検索などを支える超強力なインフラ基盤で作られており、数ペタバイトという途方もない量のログデータを長期間保存し、信じられないほどのスピードで検索・分析することができます。バラバラのログを共通言語に翻訳し、パソコン、サーバー、ネットワーク機器など、環境内のあらゆるツールから送られてくるバラバラな形式のログを共通フォーマットに自動的に変換されます。これにより、まったく違うシステムのログ同士を横断して検索・調査することが可能になります。

このように、ただ「見つける」「対応する」システムを導入するだけでなく、Google の圧倒的なパワーと最新の脅威データを味方につける統合プラットフォームこそが、「侵入されることを前提とした時代」の企業を守る盾となるのです。

 試験範囲の解説いよいよ、試験の核となる 6 つの出題分野について詳しく解説していきます。本試験の特徴として、単に「この機能を知っているか？」ではなく、このシナリオにおいて、Google が推奨する最もセキュアで運用負荷の低いアプローチ（ベストプラクティス）はどれか？ が問われる点です。ぜひ、これらの知識を習得していきましょう。

 データ マネジメントGoogle SecOps を活用するために、はじめにログを集めなくてはなりません。 様々な環境から生成される膨大なログを、Google SecOps に対して効率的かつ低コストで取り込み、分析しやすい状態に正規化できるかどうかが問われます。

 パーサー
Google SecOps における パーサー とは、多種多様なログを Unified Data Model（以下、UDM と表記）という共通フォーマットに変換する機能です。しかし、あらゆるログを確実に変換できることは約束されておらず、場合によっては必要なデータが不足することがあります。
対策として、独自のカスタム パーサーをゼロから作り直したり、外部のミドルウェアでログを加工したりするのは、保守の観点から推奨されません。既存のデフォルト パーサーの上に重ねる形で パーサー拡張機能（Parser Extension） を作成し、不足しているフィールドだけを UDM にマッピングするのが効率的であり、Google SecOps における推奨事項となります。

 エイリアシング（Aliasing）
複雑な組織環境では、同じユーザーでもシステムによって異なる識別子が使われることが多々あります。これらを別々のユーザーとして扱ってしまうと、脅威の相関分析が途切れてしまいます。読者の皆さんも、すべての社内システムに対して同じ ID でログインできるとは限らない でしょう。
エイリアシング（Aliasing） 機能を活用して、異なる ID 表現を「一つの統合されたエンティティ」として紐付け（名寄せ）します。これにより、ID の形式が違っても一連の不審な行動としてシームレスにトラッキングすることが可能になります。

例えば Windows では DOMAIN\user、Google Workspace では user@example.com といったように、同じユーザーであってもシステムによって異なる ID を持っており、これを紐づけする作業ですね。

 エンリッチメント（データの文脈付加）
セキュリティ監視で扱うログには、監査ログのような「イベントデータ（何が起きたか）」と、Active Directory などで管理される「エンティティデータ（誰が・どんな属性か）」の 2 種類があります。イベントデータ単体でも「あるユーザー ID がデータベースにアクセスした」という事実は分かります。しかし、それだけでは「そのアクセスが正規の業務なのか、悪意のあるものなのか」を判断するための背景情報（コンテキスト）が不足してしまいます。
そこで重要になるのが エンリッチメント（文脈付加） です。 Active Directory や Google Workspace といった システムから組織のコンテキスト データを直接 Google SecOps に取り込み、 発生したイベントデータに対して「部署」や「役職」といった属性情報を自動的に結びつけます。このエンリッチメントを行うことで、単なる無機質なログが「開発部のユーザーが、普段は触らない本番環境のデータベースにアクセスした」という、意味のある情報に変わります。結果として、ユーザーの普段の行動パターン（ベースライン）からの逸脱を正確に捉える、高度な異常検知が可能になるのです。

 ログ保管先ストレージの選択
取り込んだログの保管先の選択や、エクスポート時の最適化も、データ マネジメント分野の重要なテーマです。データの利用目的に応じて使い分けましょう。
ここでは、「ログを 7 年保管しておく必要がある」という要件があった場合を例に解説します。
Cloud Storage
「法的要件により、証拠となるセキュリティ ログを 7 年間、管理者であっても絶対に変更・削除できない状態で保管したい」というシナリオでは、Cloud Storage を選択します。
バケットに保持ポリシーを設定し、バケットロック 機能でポリシーを完全にロックすることで、データの強固な不変性を保証することができます。


BigQuery
長期間のログデータに対して高速に SQL クエリを実行し、自社のログと外部の脅威インテリジェンスを掛け合わせて相関分析を行いたい場合などには、処理能力に優れた BigQuery を選択します。
日付ごとに別々のテーブルを作る「日付シャーディング」という手法は、パフォーマンスが低下するため非推奨です。
複数テーブルを横断して検索する際、テーブルごとに構造（スキーマ）やアクセス権限の検証処理が発生し、これがクエリ実行時の大きな負荷（オーバーヘッド）となってしまうためです。

パーティション分割テーブル（Partitioned tables）を推奨します。
「1 つのテーブルに対する検証処理」で済むためオーバーヘッドを回避できます。
条件に合わない日時のデータをスキャン対象から外す（パーティション プルーニング）ことができるため、スキャン量が抑えられてコストが削減されると同時に、クエリの実行パフォーマンス自体も大幅に向上します。
パーティションの有効期限（例：2555日＝約7年）を設定し、データ ライフサイクルを自動管理するのが鉄則となります。




 検出エンジニアリング
ここでは、セキュリティ運用の要となる「検出エンジニアリング」について解説します。最大の目的は、精度の高い検知を行い、アナリストを疲弊させる誤検知を削減すること です。

この目的を達成するためには、Google Cloud 環境をパトロールする Security Command Center（以下、SCCと表記）、全体の情報を集約・分析する司令塔である Google SecOps、そして脅威を見つけ出すためのルール言語 YARA-L 2.0 を組み合わせて使いこなす必要があります。まずは、それぞれの役割と連携について見ていきましょう。

 SCC
Google Cloud 環境を守る上で、SecOps と必ずセットで覚えなければならない SCC は、昨今のトレンドである Cloud-Native Application Protection Platform（以下、CNAPP と表記） と呼ばれる領域の製品です。一言で言えば、Google Cloud 環境全体をパトロールし、弱点（脆弱性・設定ミス）と侵入者（脅威）を自動で検出する専用の統合防衛システム です。

具体的に、SCC は以下のような頼もしい機能を持っています。
設定ミスの自動チェック（Security Health Analytics）
「ストレージ バケットが誰でも見られる設定になっている」「ファイアウォールの穴が開きっぱなしになっている」といった、人間がやりがちな「戸締まりの忘れ」を自動で検知して警告してくれます。

リアルタイムの脅威検知（Event Threat Detection など）
「不審なプログラム（マルウェア）が実行された」「勝手に暗号資産（仮想通貨）のマイニングが始まった」といった攻撃者の悪意ある動きを、リアルタイムで検知します。

攻撃ルートの予測（Attack Path Simulation）
「もしこの設定ミスを突かれたら、最終的にどの重要データまで到達されてしまうか」という攻撃者の侵入ルートをシミュレーションし、優先して直すべき弱点を教えてくれます。

Web アプリケーションの脆弱性診断（Web Security Scanner）
Google Kubernetes Engine（以下、GKEと表記）上などで動く Web アプリケーションに対して、脆弱性（XSS や SQL インジェクションなど）を探します。


 SCC と Google SecOps の連携
最も重要なのが、SCC と Google SecOps の連携 です。

Google Cloud をパトロールする SCC 単体でも非常に優秀ですが、SCC が見つけた「設定ミス」や「脅威の警告」を Google SecOps に送信することで、真価を発揮します。
SecOps は、SCC からの警告を、他のシステム（例えば社内 PC を守る Endpoint Detection and Response（EDR） や、Google Workspace の操作ログなど）から集めた情報と掛け合わせて相関分析を行います。これにより、「この攻撃者はどこから侵入してきて、他に何をしようとしているのか」という攻撃の全体像を明らかにすることができます。そして、SecOps に備わっている SOAR が発動し、「SCC が特定の脅威を見つけたら、自動でネットワークを遮断する」といった自動防衛の仕組みが完成します。
つまり、SCC がパトロールして異常を報告し、SecOps が全体情報を分析して自動で防衛部隊を動かす という形です。このシームレスな連携こそが、次世代のセキュリティ運用の理想形です。

 YARA-L 2.0
「SecOps が全体情報を分析し、自動で防衛部隊を動かす」と説明しましたが、SecOps が「何を異常とみなすか」を正しく判断するためには、明確な基準（マニュアル）が必要です。この 検知ルールを記述するための専用言語が YARA-L 2.0 です。

サイバー セキュリティ業界には、マルウェア（悪意のあるソフトウェア）の特徴を見つけ出すための「YARA（ヤラ）」という有名な言語があります。これを Google が ログ分析（Log）向けに特化させて独自に進化させたため、「YARA-L」と呼ばれています。
YARA-L 2.0 のルールは、主に以下の 4 つのセクション（ブロック）から構成されます。この基本構造を理解しておくと、複雑な検知ルールも格段に読み解きやすくなります。
meta（メタデータ）
ルールの名前、作成者、重要度（Severity）、ルールの目的などを記述する、いわば「ルールの表紙・説明書」にあたる部分です。

events（イベント）
「どのようなログを探すか」という条件を指定する、ルールの心臓部です。SecOps に集められた多種多様なログは UDM に整理し直されています。ここでは、「UDM の中の『送信元 IP アドレス』が『悪意のある IP アドレス』と一致する」といった検索条件を定義します。

match（マッチ） ※オプション
複数のログをグループ化したり、時間で区切ったりする部分です。例えば「送信元 IP アドレスごとに集計する」「10 分間という時間枠（Time window）で区切る」といった指定を行います。

condition（条件）
最終的にアラートを鳴らす（検知とする）ための引き金（トリガー）を定義する部分です。「events で見つけた不審なログイン失敗ログが、match で指定した 10 分間のうちに 5 回以上出現したらアラートを出す」といった最終決定を下します。

rule Brute_Force_Login_Detection {
  meta:
    author = "Security Team"
    description = "同一ユーザーによる 10 分間に 5 回以上のログイン失敗を検知する"
    severity = "HIGH"

  events:
    // ログの種類が「ユーザー ログイン」であること
    $e.metadata.event_type = "USER_LOGIN"
    // かつ、その結果が「ブロック（失敗）」であること
    $e.security_result.action = "BLOCK"
    // その時のユーザーIDを変数（$userid）として保持する
    $e.principal.user.userid = $userid

  match:
    // 変数（$userid）ごとに、10分間（10m）という時間枠でログを集計する
    $userid over 10m

  condition:
    // 条件に合致したイベント（$e）の数が5回以上（>= 5）であれば検知とする
    #e >= 5
}
つまり YARA-L 2.0 は、「どんなログを（events）」「どう集計して（match）」「どうなったら警告するか（condition）」 を整理して記述できる、SecOps の運用に欠かせない非常に柔軟な言語なのです。

 検知テクニックYARA-L 2.0 の概要を把握したところで、実践的なテクニックを理解していきましょう。

 参照リスト
Indicators of Compromise（以下、IoCと表記）とは、悪意のある IP アドレスやドメインなどの「脅威の目印」です。これを使って検知ルールを作る場合、IP アドレスなどの値を、YARA-L ルールの条件文に直接書き込む（ハードコードする）のは避けるべきです。脅威リストは日々更新されるため、そのたびにルール本体を書き直すのは非常に非効率だからです。
プログラムにおける環境変数と同じように、Reference List（参照リスト）を別途作成し、ルールからはそのリストを参照させる ことで、ルール本体を触ることなく、リスト側の更新だけで動的に検知網をアップデートできるようになります。
なお、Reference Lists は 2026 年の 9 月に Data Table へ置き換えられる予定です。今後の試験で出題される可能性もあるため、意識しておくと良いでしょう。
https://docs.cloud.google.com/chronicle/docs/reference/reference-lists
非推奨例
events:
    $e.metadata.event_type = "NETWORK_CONNECTION"
    // IP アドレスが増えるたびにルールを書き直さなければならない
    ( $e.target.ip = "192.0.2.1" or $e.target.ip = "198.51.100.2" or $e.target.ip = "203.0.113.5" )
推奨例
  events:
    // ログの種類が「ネットワーク通信」であること
    $e.metadata.event_type = "NETWORK_CONNECTION"
    
    // 宛先 IP アドレスが、参照リスト「bad_ip_list」の中に含まれているかチェック
    $e.target.ip in %bad_ip_list

 組織独自の脅威リスト
SCC の機能である Event Threat Detection（以下、ETDと表記）には、Google の強力なインテリジェンスに基づく「組み込みの検知ディテクター」が用意されています。しかし、「自社で独自に収集した悪意のある IP アドレスリスト」との通信を検知したい場合はどうすればよいでしょうか。組み込みのディテクターに独自の IP アドレス を追加することはできません。このような場合は、Configurable Bad IP テンプレートを使用して、ETD のカスタムモジュールを新しく作成する のが適切な方法です。
なお、カスタムモジュールを作成する際、設定ファイル（JSON）の metadata セクションには、必ず severity (重要度)、description (説明)、recommendation (推奨事項) の3つを含める必要があります。Google は自社独自のルールに対する推奨事項までは自動生成してくれないため、「検知時にどう対応すべきか（Recommendation）」をルール作成者自身が定義しなければなりません。
{
  "displayName": "自社独自の脅威 IP アドレス通信検知",
  "templateId": "CONFIGURABLE_BAD_IP",
  "enablementState": "ENABLED",
  "params": {
    "bad_ips": [
      "192.0.2.50",
      "198.51.100.100",
      "203.0.113.25"
    ]
  },
  "customOutputMetadata": {
    "severity": "HIGH",
    "description": "自社SOCが独自に収集した悪意のあるIPアドレス（ブラックリスト）に対するアウトバウンド通信を検知しました。",
    "recommendation": "手順1: 該当する送信元のエンドポイントを速やかにネットワークから隔離してください。\n手順2: EDR のログを確認し、不審なプロセス（マルウェア等）が実行されていないか調査してください。\n手順3: チケットを起票し、インシデントレスポンスチームへエスカレーションしてください。"
  }
}

 誤検知（False Positive）は「ルールの除外」で対応する
Google が提供する高品質な標準検知ルール（Curated Detections）が、自社の正規のバックアップ処理などに対して大量の「誤検知アラート」を出してしまう場合の対処法です。アラートがうるさいからといって、ルールそのものを無効化したり、重要度を下げたりするのはセキュリティ低下を招きます。ルールの除外（Rule exclusions）を設定し、自社にとって正常な通信パターンだけを例外としてフィルタリングする ようにしましょう。

 リスクスコアとの掛け合わせ（コンテキストアウェアな検知）
脅威リストにあるファイルがダウンロードされた際、それだけでアラートを出すとノイズ（不要な警告）になりがちです。「宛先のエンドポイント（PCなど）のリスクスコアが Medium または High の場合のみアラートを出す」といったロジックをルールに組み込むことで、状況に応じた精度の高い検知 が実現できます。

 Web Security Scanner は用途に合わせて「スキャンの種類」を変える
GKE 上で動く Web アプリケーションの脆弱性（XSSやSQLインジェクションなど）をプロアクティブに探す場合、「マネージドスキャン」と「カスタムスキャン」があります。マネージドスキャンは手軽ですが、デフォルトポートしか見ず、ログイン（認証）も突破できません。「認証が必要なページ」や「非標準ポート」をスキャンする場合は、必ず「カスタムスキャン」を使用します。
ただし、本番環境に影響を与えずにカスタムスキャンを実行したい場合は、スキャンのリスクレベルを必ず LOW に設定しましょう。 そうしないと、データの意図しない変更などが発生する可能性があるためですね。

 IoC から TTPs（攻撃者の戦術）へのシフト
攻撃者は、IP アドレスやドメインなどの IoC を簡単に変更して検知を逃れようとします。そのため、Google SecOps では単に IoC をモグラ叩きのように追うだけでなく、攻撃者の行動パターンそのものである戦術・技術・手順（Tactics, Techniques, and Procedures：TTPs）を検知することが重視 されています。
SecOps で検出された脅威は、サイバー攻撃の戦術を体系化した MITRE ATT&CK（マイターアタック）フレームワーク のどこに該当するかが自動的にマッピングされます。これにより、アナリストは「点」の目印ではなく「面」の戦術として、「攻撃者が今どの段階にいて、次に何をしようとしているのか」を俯瞰しながら対応することができるのです。

 脅威ハンティング
脅威ハンティングとは、アラートが鳴るのを待つ（受動的な対応）のではなく、SOC アナリストが自ら仮説を立てて、環境内にすでに潜伏しているかもしれない未知の脅威を「能動的に探しに行く」 活動を指します。 Google SecOps の強力な検索能力や、脅威インテリジェンスをいかに使いこなすか が鍵となります。

 レトロハンティング
新しい標的型攻撃（APT）の脅威レポートが公開され、新たな悪意のある IP アドレスやファイルハッシュといった IoCを入手した場合、今後に備えて検知ルールを作るだけで満足してはいけません。YARA-L 検出ルールを作成し、過去のイベントデータに対してレトロハンティングを実行する べきです。Google SecOps はデフォルトで 12 ヶ月分のログを保持しているため、この機能を使えば過去に遡って迅速に侵害の有無を特定できます。

 低出現頻度（Low Prevalence）
攻撃者が内部から外部の指令サーバー（C2サーバー）へ通信を確立する際、脅威インテリジェンスにもまだ登録されていない「新しく取得されたばかりのドメイン」を使うことがあります。既存の脅威リストとの照合（マッチング）に頼るのではなく、Google SecOps が自動計算している プレバレンス（出現頻度）のエンリッチメントデータを利用します。 「過去 10 日間で自社環境内で初めて見られた」といった条件を指定し、統計的に自社内でほとんど観測されたことがない、低出現頻度（Low Prevalence）ドメインへの通信 を炙り出す手法が有効です。

 普段の行動（ベースライン）
「普段は国内からアクセスしている従業員が、突然海外の IP アドレスから機密データにアクセスした」場合、これはリスクが高いと判断する必要があります。攻撃者は侵入後、資格情報の窃取（Credential Dumping）を行い、正規ユーザーのふりをしてシステム内を横移動（Lateral Movement）します。 こうなると従来のマルウェア検知では見つけられません。そこで必要になるのが、ユーザー・エンティティ行動分析（User and Entity Behavior Analytics、UEBA） のアプローチです。 Risk Analytics ダッシュボードを使用し、「普段は国内からアクセスしている従業員が、突然海外から機密データにアクセスした」といったベースラインからの逸脱を炙り出します。
その際に短期間のブルートフォース（総当たり）攻撃の痕跡を探すなら、リスク計算ウィンドウを「24時間」に設定します。また、長期間にわたる潜伏活動（Low and Slow攻撃）を調査するなら「7 日間」のウィンドウを使用するといった、時間枠の使い分けも必要となります。

 インシデント対応
どんなに防御や検知を固めても、サイバー攻撃を完全に防ぐことはできません。実際に脅威が検出された後のインシデント対応では、「被害の拡大を防ぐ（封じ込め）」「犯人の痕跡を消さない（証拠保全）」「定型作業を自動化する（SOAR）」「チームで連携する（ケース管理）」 といった点を意識することが重要です。

 初動対応
マルウェア感染やデータ持ち出し（Exfiltration）が発覚した際、まずやるべきは被害を止めるための初動対応（Containment：封じ込め）です。 ここで慌ててリソースを「削除」や「再起動」してしまうと、メモリ上の揮発性データなど、原因究明に必要なフォレンジック（デジタル鑑識）の証拠が消えてしまうためです。
対象のリソースごとに、正しいアプローチを整理しておきましょう。


侵害された対象
❌ 絶対にやってはいけない NG 行動
⭕ 正解のアプローチ（証拠保全と隔離）


Compute Engine (VM)
慌てて VM を削除する、または再起動する。
VPC ファイアウォールなどで ネットワークから隔離 し、VMを稼働させたままディスクのスナップショットを取得する。

Cloud Run サービス
サービスそのものを削除する。
外部からの Ingress（上り）トラフィックを無効化して 隔離 し、分析用に保存する。

認証情報（サービス アカウント等）
サービス アカウントそのものを削除する。（監査ログが追えなくなるため）
該当のキーを 無効（Disable） する、またはアカウントを停止し、分析のために保持する。


 定型作業の自動化
Google SecOps に備わっている SOAR（自動化システム）を用いて、人間が手作業で行う必要のないタスクをいかに自動化（プレイブック化）するか という点も、対応品質や速度の向上には重要です。
フィッシング被害への対応
ユーザー アカウントが侵害された場合、手動でパスワード変更を促すのは遅すぎます。影響を受けたユーザーの認証情報リセットと OAuthトークンの無効化を自動的に実行する ことで速やかな初動対応が可能となります。

誤検知アラート疲れの解消
低重要度のノイズアラートが大量発生している場合は、許可リスト（Allowlist）に基づいて 既知の正しいソースからのアラートを自動的に閉じる（Dismiss） プレイブックを作成し、アナリストがアラート対応に疲弊するのを防ぎます。


 プレイブック ブロック
複数のプレイブックで「担当者へのメール通知」や「承認フロー」など、同じ処理を作りたい場合はどうすべきでしょうか？ 個別にコピー＆ペーストで作るのではなく、プレイブック ブロックとして共通部品化 し、各プレイブックに組み込むのがおすすめです。これにより、メールの文面を変更したい時も、ブロックを 1 箇所直すだけで全てのプレイブックに反映され、メンテナンスの手間が激減します。
プレイブック ブロック例
{
  "blockName": "Notify_and_Approve_Block",
  "description": "重大インシデント発生時の緊急メール通知と承認フロー",
  "inputs": [
    {
      "name": "Incident_Severity",
      "type": "String",
      "description": "インシデントの重要度"
    },
    {
      "name": "Target_Email_List",
      "type": "String",
      "description": "通知先のメーリングリスト"
    }
  ],
  "steps": [
    {
      "stepId": "action_1",
      "integration": "Google Workspace Gmail",
      "action": "Send_Email",
      "parameters": {
        "to": "${Target_Email_List}",
        "subject": "[緊急] 重要度 ${Incident_Severity} のインシデントが発生しました",
        "body": "直ちに初期調査の結果を確認し、対応を承認してください。"
      }
    },
    {
      "stepId": "action_2",
      "integration": "SecOps SOAR",
      "action": "Wait_For_Approval",
      "dependsOn": "action_1"
    }
  ]
}
プレイブック ブロック呼び出し例
{
  "playbookName": "Malware_Infection_Response",
  "description": "マルウェア検知時の自動対応フロー",
  "trigger": {
    "condition": "Alert.Type == 'Malware'"
  },
  "steps": [
    {
      "stepId": "step_1",
      "type": "Playbook_Block",
      "blockName": "Notify_and_Approve_Block",
      "description": "作成済みの共通ブロックを呼び出し、通知と承認を行う",
      "inputs": {
        "Incident_Severity": "${Alert.Severity}",
        "Target_Email_List": "security-leads@example.com"
      },
      "dependsOn": "step_1"
    }
  ]
}

 ケース管理とエスカレーション
インシデント対応はチーム戦です。SecOps 上で「今、誰がボールを持っているか」を明確にするワークフローの設計が問われます。
ケースの確実なエスカレーション
初期調査を行う Tier 1 アナリストから、より高度な分析を行う Tier 2 チームへケースを引き継ぐ際は、ケースのステージを「トリアージ」から 「Assessment（評価）」 に変更し、Tier 2 のロールにケースを再割り当てします。これにより、責任の所在と履歴がログに確実に残ります。

引き継ぎ（Handoff）の品質評価
チーム間の引き継ぎが上手くいっているかを測定するには、「引き継ぎ要求から受理されるまでの時間」や、「引き継ぎ前後の平均封じ込め時間（Mean Time To Contain : MTTC）」 を比較することで、プロセスの有効性を評価します。

緊急時のマルチチャネル通知
CISO（最高情報セキュリティ責任者）や関係者へ緊急アラートを送る際、単一のメールに頼るのは危険です。Google Cloud の Pub/Sub と Cloud Run Functions を使用して、重大度に応じて Google Chat、PagerDuty、SMS など 複数のチャネルへ条件付きで通知をルーティングする ことで、アラート自体の信頼性が高まります。


 プラットフォーム運用このセクションでは、Google SecOps や Security Command Center (SCC) といったセキュリティ ツールの基盤構築と、セキュアなアクセス制御（IAM）の設計が問われます。どうやって安全にツールを統合し、運用していくか という土台となる分野ですね。

 サービス アカウントキーを使わない
サードパーティのツールに対して Google SecOpsやSCCへのアクセス権を付与したい場合、いくつかの手段があります。しかし、手軽だからといって Google Cloud のアカウントを新規発行したり、サービス アカウントのキー（JSONファイル）をダウンロードして渡したりするのは、重大なセキュリティ リスクとなる 可能性があります。
外部の Identity Provider（Azure AD や Okta など）と安全に連携できる Workforce Identity Federation や Workload Identity Federation を使用します。これにより、パスワードやキーを共有することなく、一時的で安全なアクセス権を提供することが可能になります。

 最小権限の原則
SecOps に限らず権限管理のベスト プラクティスとして、最小権限の原則 があります。過剰な権限を持つことで、誤った変更を加えてしまったり、そのアカウントが漏洩したときに大きなセキュリティ リスクとなります。
例えば、システムの開発者や運用者は必要に応じて変更権限を持つ可能性もありますが、アラートに対する初動でトリアージを担当する Tier 1 アナリストには、閲覧権限のみで必要十分でしょう。これはユーザー アカウントに限らずサービス アカウントでも同様で、自動化ワークフローを実行するアカウントに、安易に「オーナー」や「編集者」ロールを付与してはいけません。事前定義ロールとカスタムロールを用いて、必要な権限のみを割り当てるようにしましょう。

 機能ギャップ分析
例えば、「新しく導入した EDR ツールと、Google SecOpsの機能が重複している」という場面に遭遇します。その際に「重複しているから片方をすぐに無効化する」のではなく、まずは 機能ギャップ分析（Capability gap analysis） を実施します。既存のツールにはない独自のテレメトリー（ログの価値）があるかを評価し、それぞれのツールの強みを活かすアーキテクチャを考えましょう。

 Dry-run
組織のポリシー（Organization Policy）で新しい制限をかけたり、VPC Service Controlsで新しい境界（ペリメータ）を作ったりする際、「いきなり本番環境で有効化（Enforce）する」という選択肢は、正当な業務通信まで遮断してしまう恐れがあるため避けましょう。

必ず Dry-run（ドライラン）モード を使用して構築します。これにより、実際の通信は遮断せずに「もし有効化していたらブロックされていた通信」を監査ログで確認でき、安全に影響範囲をテストすることができます。

 オブザーバビリティ
このセクションでは、オブザーバビリティ（可観測性） について問われます。ここでは、単にセキュリティ脅威を監視することだけではなく、「セキュリティ監視システム自体が正常に動いているか（ヘルスモニタリング）」と、「経営層や関係者にセキュリティの状況をどう分かりやすく報告するか（ダッシュボード）」という 2 つの実践的なスキルが評価されます。

 サイレント ソース検知
「異常を知らせるアラート」と同等以上に恐ろしいのが、パイプラインの障害や、攻撃者による意図的なログ停止によって、来るはずのログが届かなくなった状態 です。これを検知するには、Cloud Monitoring を使用して、対象のログ指標に対する 指標なし（Metric-absence）のアラートポリシー を作成します。
注意点として、閾値を 0 に設定（MetricThreshold）してはいけません。データが全く来ない場合、閾値の比較自体が行われないため、必ず「MetricAbsence（データ不在）」の条件を使用する必要があります。

 経営層へのレポート
経営層へのレポートとして、手作業でグラフを作るのは手間がかかります。そこで、SCC の検出結果や SecOps のデータを BigQuery に継続的エクスポート（Continuous export）し、Looker Studio を接続してダッシュボードを構築 しましょう。
なお、BigQuery への直接アクセス権を持たない経営層に Looker Studio のダッシュボードを共有する場合、データソースの設定で 「オーナーの認証情報 (Owner's Credentials)」 を使用して共有しましょう。

 SLO のアラートは「短期と長期の二刀流」で構成
セキュリティ サービスの信頼性を測る SLO（サービスレベル目標）も監視しなくてはなりません。例えば「認証エラーの急増などの異常（エラー予算の消費）を検知する場合、1 つのアラートに頼るのではなく、短いルックバック期間（例: 数分）での Fast-burn（急激なエラー予算の消費）アラート と、長いルックバック期間（例: 数日）での Slow-burn（緩やかなエラー予算の消費）アラート の 2 つを組み合わせて構成しましょう。これによって、誤検知を減らしつつ迅速に対応することが可能となります。

 ログの質（パーサーエラー）を監視する
ログの取り込みパイプラインの健全性を監視する際、「ログの総量」だけを見ていては不十分です。ログが正常に SecOps へ取り込まれているかを評価するためには、以下の点に留意しましょう。
受信した総ログ数のうち、UDM（正規化フォーマット）に正常にマッピングされたログの割合
パーサー（Parser）のエラー発生率
インジェクション遅延（ログ受信から正規化までの時間）

 まとめ最初はチンプンカンプンだった内容について、1 つずつ紐解いていきました。ここまで読み終えたことで、意外と理解できたのではないでしょうか。考え方や用語に難しさを感じることの多い SecOps ですが、結局は 高度化する脅威に即時対応するために生まれた仕組み です。それを実現する要素に新しい用語や仕組みが多く使われているだけですので、理解してしまえば難しいものではありません。昨今のニュースでもサイバー攻撃に起因するものは多く取り上げられるので、是非ともこの機会に学習し、取り組みを始めていきましょう。
クラウドエース株式会社 Google Cloud 認定トレーナーの廣瀬 隆博がお届けしました。また次の記事でお会いしましょう。
侵害された対象	❌ 絶対にやってはいけない NG 行動	⭕ 正解のアプローチ（証拠保全と隔離）
Compute Engine (VM)	慌てて VM を削除する、または再起動する。	VPC ファイアウォールなどでネットワークから隔離し、VMを稼働させたままディスクのスナップショットを取得する。
Cloud Run サービス	サービスそのものを削除する。	外部からの Ingress（上り）トラフィックを無効化して隔離し、分析用に保存する。
認証情報（サービスアカウント等）	サービスアカウントそのものを削除する。（監査ログが追えなくなるため）	該当のキーを無効（Disable）する、またはアカウントを停止し、分析のために保持する。