第7回：何が起きているか把握する！ログの集中管理と監視アラート
はじめに
お疲れ様です。SKYこと関谷です。
前回の第6回では、組織のポリシーという「ガードレール」の仕組みについて学びました。外部IPアドレスの禁止やサービスアカウントキーの作成制限など、危険な設定を組織全体で予防的に防ぐ方法を理解していただけたかと思います。これまでの6回を通じて、Google Cloud のセキュアな土台を作るための基本的な要素、つまり組織構造、IAM、VPC、ファイアウォール、Shared VPC、そして組織のポリシーという防御の層を積み重ねてきました。
しかし、ここで一つ重要な疑問が浮かび上がります。せっかく強固なセキュリティ設定を施しても、「実際に何が起きているのか」を把握できなければ、本当に安全だと言えるでしょうか。頑丈な鍵をかけた家に住んでいても、誰かが侵入を試みた痕跡や、家族が誤って窓を開けっ放しにしていることに気づけなければ、安心して暮らせませんよね。
今回の第7回では、Google Cloud 環境で「何が起きているか把握する」ための仕組みとして、ログの集中管理と監視アラート について解説していきます。これまで構築してきたセキュリティ対策が実際に機能しているかを確認し、万が一問題が発生した際には素早く気づいて対応できる体制を整えることが、この回のゴールです。
この回では、なぜログを一箇所に集めることが大切なのか、どのようにログを活用すれば良いのか、そして最低限設定しておくべき監視アラートは何かを、できるだけ分かりやすく、実践的にお伝えしていきます。
セキュリティ対策は「設定して終わり」ではなく、「継続的に見守る」ことで初めて完成します。それでは、Google Cloud におけるログ管理と監視の世界へ、一緒に踏み出していきましょう。
ブログシリーズその他の執筆
2025/10/25更新
本編
番外編
第３回では紹介しなかった関連機能の説明です
7-1. なぜログを1つの場所に集める必要があるのか？
それでは、Google Cloud 環境におけるログ管理について考えていきましょう。まず最初に理解していただきたいのは、ログの集中管理がなぜ重要なのかという点です。
バラバラに保存されたログの問題
皆さんの組織には、おそらく複数のプロジェクトが存在しているでしょう。開発環境、検証環境、本番環境など、第2回で学んだリソース階層の考え方に沿って、目的ごとにプロジェクトを分けているはずです。
ここで問題になるのが、各プロジェクトのログがそれぞれバラバラに保存されている状態です。これは、推理小説のページが複数の部屋に散らばっているようなものです。不審なアクティビティを調査しようとしても、各プロジェクトに一つずつアクセスして確認しなければならず、攻撃の全体像を把握することが非常に困難になります。
攻撃者は通常、一つのプロジェクトだけを狙うのではなく、開発環境で認証情報を盗み出し、それを使って本番環境に侵入するといった横断的な侵害を試みます。このような攻撃を発見し、追跡するには、複数のプロジェクトにまたがるログを時系列で確認できる仕組みが必要です。
ログ集中管理がもたらす三つのメリット
ログを一箇所に集めることで、次の三つの重要なメリットが得られます。
迅速なインシデント対応 が可能に：
セキュリティインシデントが発生したとき、最も重要なのは「いつ」「誰が」「何を」したのかを素早く特定することです。ログが一箇所に集約されていれば、BigQuery などの分析ツールを使って組織全体のアクティビティを横断的に検索でき、攻撃の痕跡を迅速に発見できます。
運用効率が大幅に向上 ：
ログの保存期間や保存先などの設定を、プロジェクトごとに個別に管理する必要がなくなります。第6回で学んだ組織のポリシーと同じように、組織レベルで一度設定すれば、新しいプロジェクトが作成されたときも自動的に同じルールが適用されます。設定の一貫性も保てるため、あるプロジェクトでは30日間、別のプロジェクトでは7日間といった不統一も防げます。
コンプライアンス要件への対応 ：
多くの業界では、法規制によって特定のログを一定期間保存することが義務付けられています。専用のログ集約プロジェクトを設けることで、組織全体のログを一元管理し、必要な保存期間を確実に守ることができます。また、ログへのアクセス権限も厳格に管理できるため、ログの改ざんや削除といったリスクも低減できます。
7-2. Cloud Logging のアーキテクチャ
前節でログの集中管理の重要性を理解していただきました。それでは、Google Cloud で実際にログを集める仕組みはどのようになっているのでしょうか。ここでは、Cloud Logging の基本的なアーキテクチャについて、初級者の方にも分かりやすく解説していきます。
Cloud Logging の基本的な流れ
Google Cloud では、すべてのサービスが自動的にログを生成しています。Compute Engine の VM、Cloud Storage、BigQuery、Cloud SQL など、あらゆるリソースが動作ログやアクセスログを出力します。これらのログは、まず Cloud Logging というサービスに自動的に集められます。
ここで重要なのは、ログは自動的に生成されるものの、それをどこに保存するか、どのくらいの期間保存するかは、私たち利用者が設計する必要があるということです。
デフォルトでは、ログは各プロジェクト内のログバケットに保存されます。
管理アクティビティ監査ログとシステムイベント監査ログと、データアクセス監査ログとポリシー拒否監査ログでデフォルトの保存期間は異なります。
前節で説明したような 集中管理を実現するには、ログを意図的に別の場所へ転送する設定が必要 になります。
ログルーターとシンクの役割
Cloud Logging でログの転送を制御する仕組みとして、ログルーター と シンク という二つの重要な概念があります。
ログルーターは、生成されたログを受け取り、 どう処理すべきかを判断する 交通整理役です。
郵便局の配送センターでたくさんの荷物（ログ）が届いたとき、それぞれの宛先を見て適切な場所に振り分ける役割を果たします。
シンクは、 ログの転送先と転送ルールを定義する 設定です。
「どのログを、どこに送るか」を具体的に指定します。例えば、「監査ログだけを BigQuery に送る」「エラーログだけを Cloud Storage に保存する」「すべてのログを別のプロジェクトに転送する」といった具合です。 一つのプロジェクトに複数のシンクを設定することもでき、同じログを複数の宛先に送ることも可能 です。
重要な点として、
Cloud Logging は 各プロジェクト、フォルダ、組織に対して、システムによって二つのシンクを自動的に作成 します。
一つは _Required シンクで、重要な監査ログの一部を _Required ログバケットに転送します。
もう一つは _Default シンクで、その他のログを _Default ログバケットに転送します。
これらの自動作成されるシンクにより、すべてのログが確実に保存される仕組みになっています。
ログルーターは、設定されたシンクのルールに従って、ログを適切な宛先に転送します。ユーザーが作成したカスタムシンクで指定されなかったログも、 _Required シンクまたは _Default シンクのいずれかによって自動的に保存されます。
この仕組みにより、 重要なログだけを長期保存用の外部ストレージに転送し、その他は標準のログバケットで保管するといった柔軟な運用が実現 できます。
次の表で、ログルーターとシンクの役割と特徴を整理しました。
ログルーターとシンクの役割と特徴
| 要素 | 役割 | 主な機能 | 設定単位 |
|---|---|---|---|
| ログルーター | ログの交通整理役 | 生成されたログを受け取り、シンクの設定に基づいて適切な宛先に振り分ける | プロジェクト、フォルダ、組織 |
| シンク | 転送ルールの定義 | どのログをどこに送るかを指定する（フィルタ条件と転送先を設定） | プロジェクト、フォルダ、組織ごとに複数設定可能 |
集約先としてのCloud Storage、BigQuery、Pub/Subの使い分け
ログの転送先として、Google Cloudでは主に三つの選択肢があります。それぞれに特徴があり、用途に応じて使い分けることが重要です。
Cloud Storage：
大量のログを長期間、低コストで保存したい場合に最適です。コンプライアンス要件などで「とにかく保存しておく必要がある」というログは、Cloud Storage に転送しましょう。ログは JSON ファイルとして保存されるため、必要になったときにダウンロードして分析できます。ただし、保存されたログをリアルタイムで検索・分析することには向いていません。図書館の書庫に保管された資料のようなイメージです。必要なときに取り出せますが、即座に内容を検索することは難しいのです。
BigQuery：
ログを分析したい場合に最も強力な選択肢です。BigQuery は Google Cloud が提供する超高速なデータウェアハウスで、数テラバイトものログに対しても数秒で SQL 検索を実行できます。「過去3ヶ月間で、特定のユーザーがどのリソースにアクセスしたか」「特定の API エラーが発生した回数の推移」といった複雑な分析も、SQLを書くだけで簡単に実行できます。セキュリティインシデントの調査や、アクセスパターンの分析には、BigQuery へのログ転送が非常に有効です。ただし、Cloud Storage に比べるとコストは高くなります。
Pub/Sub：
ログをリアルタイムで別のシステムに連携したい場合に使用します。Pub/Sub はメッセージングサービスで、ログが生成されると同時に他のシステムに通知できます。例えば、重大なエラーが発生したときに即座にアラートを送信したり、ログを外部の SIEM（セキュリティ情報イベント管理）システムに転送したりする用途に適しています。リアルタイム性が求められる場合は、Pub/Sub を経由する設計を検討しましょう。
実際の運用では、これらの転送先を組み合わせて使うことが一般的です。例えば、すべての監査ログをBigQuery で分析できるようにしつつ、同時に Cloud Storage にも保存して長期保管要件を満たす、といった設計が考えられます。
次の表で、三つの転送先の特徴を比較しました。それぞれの長所と短所、適した用途を理解することで、適切な設計判断ができるようになります。
ログの転送先
| 転送先 | 主な用途 | 長所 | 短所 | コスト | 適したユースケース |
|---|---|---|---|---|---|
| Cloud Storage | 長期保管 | 大容量を低コストで保存可能、データの永続性が高い | リアルタイム検索・分析には不向き | 低 | コンプライアンス要件によるログの長期保管、アーカイブ |
| BigQuery | 分析・調査 | 高速なSQL検索、大規模データの複雑な分析が可能 | ストレージコストがCloud Storageより高い | 中〜高 | セキュリティインシデント調査、アクセスパターン分析、監査レポート作成 |
| Pub/Sub | リアルタイム連携 | リアルタイム処理、外部システムへの即時転送が可能 | ログの永続的な保存には別途転送先が必要 | 低〜中 | 即時アラート送信、外部 SIEM システムへの連携、リアルタイム監視 |
アーキテクチャの全体像
ここまでの内容を整理すると、Cloud Logging のアーキテクチャは次のような流れになります。各プロジェクトのリソースからログが生成され、それが Cloud Logging のログルーターに集められます。ログルーターは、設定されたシンクのルールに基づいて、ログを適切な転送先に振り分けます。転送先は、長期保管用の Cloud Storage、分析用の BigQuery、リアルタイム連携用の Pub/Sub など、用途に応じて選択します。
この仕組みを組織レベルで設定することで、すべてのプロジェクトのログを自動的に集約プロジェクトに転送し、前節で説明した集中管理を実現できるのです。
7-3. 【具体的な方法】ログ集約プロジェクトの設計
前節で Cloud Logging のアーキテクチャを理解していただきました。それでは、実際にログの集中管理を実現するには、どのようにプロジェクトを設計すればよいのでしょうか。この節では、ログ集約プロジェクトの具体的な設計方法を解説します。
ログ集約専用プロジェクトを作成する理由
まず考えるべきは、ログを保管するための専用プロジェクトを用意することです。なぜ専用プロジェクトが必要なのでしょうか。それは、ログという機密性の高い情報を、他のリソースから分離して管理するためです。
ログには、誰がいつ何をしたかという重要な情報が含まれています。もし本番環境のプロジェクトと同じ場所にログを保存していたら、本番環境を操作できる人がログも自由に閲覧・削除できてしまいます。これでは、不正を行った人が証拠を消すことも可能になってしまいます。
専用プロジェクトを作成することで、ログへのアクセス権限を厳格に管理できます。第3回で学んだ「最小権限の原則」をここでも適用し、セキュリティチーム、監査チーム、そして限られた管理者だけがログにアクセスできるように設定します。
推奨されるフォルダ構成とプロジェクト配置
ログ集約プロジェクトをリソース階層のどこに配置するかは重要です。一般的には、組織のルート直下に「共通サービス」または「セキュリティ」というフォルダを作成し、その中にログ集約プロジェクトを配置する方法が推奨されます。ログは組織全体の横断的な情報であり、特定の部門や環境に属さない性質を持つためです。
規模の大きい組織では、環境ごとにログ集約プロジェクトを分ける設計もあります。本番環境用と開発環境用を別々に用意することで、開発者は開発環境のログにアクセスできるが、本番環境のログには一切アクセスできないという、より厳格な分離が実現できます。
ログ集約の例
監査ログは必ず集約する
Google Cloud には、さまざまな種類のログが存在しますが、セキュリティの観点から最も重要なのが監査ログです。監査ログには四つの種類があります。
管理アクティビティ監査ログ：
リソースの設定変更や管理操作を記録します。VM インスタンスの作成、IAM ロールの付与、ファイアウォールルールの変更などです。このログはデフォルトで有効になっており、無効化できません。
Cloud Logging では保存期間は400日間です。
データアクセス監査ログ：
リソース内のデータを読み取ったり変更したりする操作を記録します。
データアクセス監査ログには「管理読み取り」「管理書き込み」「データ読み取り」「データ書き込み」の四つのサブタイプがあり、このうち 管理書き込みのみがデフォルトで有効 になっています。その他のサブタイプはデフォルトでは無効です。
データアクセスは非常に頻繁に発生し、すべてを記録するとログの量が膨大になり、コストも増大するためです。しかし、機密性の高いデータを扱うプロジェクトでは、必要なサブタイプを有効化すべきです。
デフォルトの保存期間は Cloud Logging では30日間です。
システムイベント監査ログ：
Google のシステムによって実行された管理操作を記録します。
このログもデフォルトで有効です。
Cloud Logging では保存期間は400日間です。
ポリシー拒否監査ログ：
ユーザーまたはサービスアカウントが VPC Service Controls によってアクセス拒否された場合に記録されます。このログもデフォルトで有効になっており、無効化できません。ただし、除外フィルタによって一部のログを除外することは可能です。
Cloud Logging では保存期間は30日間です。
ログ集約プロジェクトでは、 少なくとも管理アクティビティ監査ログ、システムイベント監査ログ、ポリシー拒否監査ログを必ず収集すべき です。
データアクセス監査ログについては、組織のセキュリティポリシーとコストを考慮して、必要なサブタイプを選択して有効化し収集します。
代表的なログの種類と特徴
| 監査ログの種類 | 記録される操作 | デフォルト設定 | デフォルト保存期間 | ログ量 | 推奨設定 |
|---|---|---|---|---|---|
| 管理アクティビティ | リソースの設定変更、管理操作 | 有効（無効化不可） | 400日 | 中 | 必ず集約 |
| データアクセス | データの読み取り・変更操作 | 管理書き込みのみ有効、その他は無効 | 30日 | 大 | 機密データを扱うプロジェクトでは必要なサブタイプを有効化して集約 |
| システムイベント | Googleシステムによる自動操作 | 有効 | 400日 | 小 | 必ず集約 |
| ポリシー拒否 | VPC Service Controlsによるアクセス拒否 | 有効（無効化不可、除外フィルタで一部除外可能） | 30日 | 小〜中 | 必ず集約 |
組織レベルでのシンク設定
ログ集約を効率的に実現するには、組織レベルまたはフォルダレベルでシンクを設定することが重要です。これは第6回で学んだ組織のポリシーと同じ考え方です。 上位の階層で設定すれば、その下のすべてのプロジェクトに自動的に適用 されます。
組織レベルでシンクを設定すると、現在存在するすべてのプロジェクトはもちろん、将来新しく作成されるプロジェクトのログも自動的に集約プロジェクトに転送されます。プロジェクトごとに個別設定する手間が省け、設定漏れも防げます。
シンクの設定では、フィルタ条件を使って「どのログを転送するか」を指定できます。すべてのログを無条件に転送するとコストが膨らむため、組織の要件に応じて適切なフィルタを設定しましょう。
組織・フォルダレベルのシンク
ログの保存期間とライフサイクル管理
ログをどのくらいの期間保存するかは、 コンプライアンス要件、コスト、そして実際の利用目的によって決まります。
監査ログは、多くの業界で最低1年間、できれば3年から7年間の保存が推奨または義務付けられていることがあるようです。まずは 自組織のコンプライアンス要件を確認 してください。
なお、Cloud Logging のログバケットでは、2023年3月1日以降、 30日を超えて保持されているログデータにストレージ費用が適用 されるようになりました。この料金体系の変更を踏まえ、コストとコンプライアンス要件のバランスを考慮した保存戦略の策定が重要です。
BigQuery に保存するログは、頻繁に分析する期間に限定することでコストを抑えられます。例えば、直近3ヶ月分のログは BigQuery で高速に分析できるようにし、それより古いログは Cloud Storage に保存する設計が効果的です。
Cloud Storage では、ライフサイクル管理機能を使って、古いログを自動的に低コストなストレージクラス（Nearline、Coldline、Archive）に移動させることができます。例えば、最初の30日間は Standard ストレージクラス に保存し、その後は Coldline に移動、1年後は Archive に移動、という段階的な管理が可能です。
ログの保管先とライフサイクル管理
| 期間 | 主な保存先 | ストレージクラス | 用途 |
|---|---|---|---|
| 直近3ヶ月 | BigQuery | - | 日常的な分析、インシデント調査 |
| 3ヶ月〜1年 | Cloud Storage | Standard/Nearline | 過去のインシデント調査、定期的な監査レポート |
| 1年〜3年 | Cloud Storage | Coldline | コンプライアンス監査、重大インシデントの詳細調査 |
| 3年以上 | Cloud Storage | Archive | 長期保管要件の遵守、法的証拠保全 |
IAM権限の適切な設定
ログ集約プロジェクトへのアクセス権限は、非常に慎重に設定する必要があります。ログには機密情報が含まれているため、第3回で学んだ「最小権限の原則」を徹底的に適用します。
基本的な考え方として、ログを閲覧できる人と、ログ基盤を管理する人を明確に分けることが重要です。セキュリティチームや監査チームには、BigQuery のデータ閲覧者ロールや Cloud Storage の閲覧者ロールを付与します。一方、ログ基盤を管理するインフラチームには、シンクの設定変更やストレージ設定の変更ができる権限を付与しますが、必ずしもログの内容を読む権限は必要ありません。
また、ログを誤って削除してしまうリスクを防ぐため、削除権限は非常に限られた管理者だけに付与すべきです。
Cloud Storage には、バケットロック（Bucket Lock）という機能があり、一度保存したデータを指定期間は削除できないように設定できます。
重要な点として、
バケットロックを適用すると、その保持ポリシーを削除したり保持期間を短縮したりすることが永久に不可能になります。 この操作は 不可逆的 であるため、慎重に実施する必要があります。
ただし、 保持期間を延長することは可能 です。
ログ権限付与例
| 役割 | 主な責務 | BigQueryの権限 | Cloud Storageの権限 |
|---|---|---|---|
| セキュリティアナリスト | ログの分析、インシデント調査 | データ閲覧者 | オブジェクト閲覧者 |
| 監査担当者 | コンプライアンス監査 | データ閲覧者（特定テーブルのみ） | オブジェクト閲覧者 |
| ログ基盤管理者 | シンク設定、ストレージ管理 | 管理者 | 管理者 |
| システム管理者 | 緊急時の対応、障害調査 | ジョブユーザー | オブジェクト閲覧者 |
実装の順序と注意点
ログ集約プロジェクトを実装する際は、次の順序で進めることをお勧めします。
- 最初に、ログ集約専用プロジェクトを作成します。命名規則は第2回で学んだように、目的が分かりやすい名前を付けましょう。
- 次に、BigQuery のデータセットと Cloud Storage のバケットを作成します。
- その後、組織レベルまたはフォルダレベルでシンクを作成します。最初は監査ログだけを対象にして、動作を確認してから徐々に範囲を広げていくアプローチが安全です。
- 最後に、IAM 権限を設定します。
注意すべき点として、
組織レベルでシンクを設定すると、ログ集約プロジェクト自体のログも転送対象になってしまう 可能性があります。
これを防ぐには、シンクのフィルタ条件で、ログ集約プロジェクトを明示的に除外する設定を追加します。
具体的には、インクルージョンフィルタに以下のような除外条件を含めます。
NOT resource.labels.project_id="ログ集約プロジェクトのID"
または、シンクのエクスクルージョンフィルタ（除外フィルタ）を使用して、ログ集約プロジェクトからのログを除外することもできます。
この設定を行わないと、ログがループして無限に増え続ける 事態になりかねません。
また、データアクセス監査ログを有効化すると、ログ量が大幅に増加します。まずは重要なプロジェクトやリソースだけで試験的に有効化し、コストとログ量を確認してから全体に展開することをお勧めします。
7-4. Cloud Monitoring による監視とアラート設定
前節までで、ログを集約し保存する仕組みを整えました。
しかし、ログを集めるだけでは不十分です。膨大なログの中から重要な事象を見つけ出し、迅速に対応するには、自動的に監視してアラートを発する仕組みが必要です。
なぜ監視とアラートが必要なのか
企業の Google Cloud 環境では、1日に数百万ものログが生成されます。人間が毎日目視で確認するのは現実的ではありません。
監視の目的は、問題発生時にできるだけ早く気づくこと です。攻撃者の侵入から検知までの時間が長いほど被害は拡大するため、自動アラートでこの時間を短縮することが重要です。
Cloud Monitoring の基本的な仕組み
Cloud Monitoring は、次の流れで動作します。
- まず、ログベース指標という機能でログの内容を数値化します。「過去5分間に失敗したログイン試行が何回あったか」という数値を作り出します。
- 次に、アラートポリシーを設定してこの数値が閾値を超えたときに通知を発します。
- そして、通知チャネルでメールや Slack などの通知先を指定します。
この仕組みの優れた点は、複雑な条件も設定できることです。
「特定のユーザーが本番環境で管理者権限を使ってファイアウォールルールを変更した」といった、複数条件を組み合わせた監視が可能で、本当にセキュリティ上重要な事象だけを検知できます。
通知アラートフローの例
最低限設定すべきアラートの種類
すべてのログにアラートを設定するのは現実的でも効果的でもありません。セキュリティ上のリスクが高い事象に焦点を絞ることが重要です。
IAM権限変更のアラートは最優先 です。
組織や本番環境のIAMポリシーが変更されたとき、特にオーナー権限や編集者権限のような強力な権限が付与されたときは即座に確認が必要です。攻撃者が永続的なアクセスを確保するためによく使う手法だからです。
ネットワーク設定変更のアラートも重要 です。
ファイアウォールルールやVPCの設定変更、特に外部からのアクセスを許可するルール追加は通知すべきです。これらの変更を見逃すと、データベースが意図せず外部に公開されるといった深刻な事態につながります。
その他、サービスアカウントキーの作成、異常なログイン試行や通常と異なる場所からのアクセス、大量のリソース削除やデータのエクスポートといった破壊的な操作も監視対象です。
アラートの種別一覧
| アラート種別 | 重要度 | 検知すべき事象 | 対応の緊急度 |
|---|---|---|---|
| IAM権限変更 | 高 | 組織・本番プロジェクトでのIAMポリシー変更 | 即時対応 |
| ネットワーク設定変更 | 高 | ファイアウォールルールの追加・変更 | 即時対応 |
| サービスアカウントキー作成 | 中〜高 | サービスアカウントキーの新規作成 | 24時間以内 |
| 異常なログイン | 中 | 通常と異なる国・地域からのアクセス | 24時間以内 |
| リソースの大量削除 | 高 | 複数のVMやストレージの連続削除 | 即時対応 |
| データのエクスポート | 中〜高 | BigQueryやCloud Storageからの大量データエクスポート | 24時間以内 |
ログベース指標とアラートポリシーの設定
ログベース指標は、ログの内容を集計して数値化したものです。
指標はログのフィルタ条件を指定して作成します。IAM 権限変更を検知する指標では、監査ログの中から「SetIamPolicy」といったメソッドを指定します。
ファイアウォールルール変更を検知する指標では、リソースタイプとして「gce_firewall_rule」を指定し、メソッドとして「insert」「update」「delete」を指定します。
指標を作成したら、アラートポリシーを設定します。
最も基本的な条件は「指標の値が閾値を超えたとき」です。「IAM 権限変更が5分間に1回でも発生したら通知」という設定が考えられます。
閾値の設定は環境によって調整が必要で、重要なのは誤検知を減らしながら見逃しも防ぐバランスを見つけることです。
指標別のアラート設定条件例
| 指標名 | 閾値 | 評価期間 | アラート条件 |
|---|---|---|---|
| iam_policy_changes_count | 1回以上 | 5分 | 5分間に1回でも発生 |
| firewall_changes_count | 1回以上 | 5分 | 5分間に1回でも発生 |
| sa_key_creation_count | 1回以上 | 10分 | 10分間に1回でも発生 |
| vm_deletion_count | 3回以上 | 5分 | 5分間に3回以上発生 |
| bigquery_export_count | 5回以上 | 30分 | 30分間に5回以上発生 |
通知チャネルの設定と使い分け
アラートが発生したときの通知先を決めるのが通知チャネルの設定です。
- メールは確実に記録が残る基本的な通知方法です。
- Slack などのチャットツールはチーム全体で情報を共有しやすく、素早く対応を決定できます。
- PagerDuty や OpsGenie などのインシデント管理ツールは、24時間365日の監視体制を実現したい組織に適しており、担当者に電話や SMS で通知し、応答がなければ次の担当者に自動的にエスカレートします。
重要なのは、 アラートの緊急度に応じて通知方法を使い分ける ことです。
すべてのアラートを電話通知してしまうと「アラート疲れ」が発生し、重要なアラートに気づけなくなります。緊急度が高く即座に対応が必要なアラートだけを強い通知方法にし、それ以外は穏やかな通知方法にすることで持続可能な運用体制を実現できます。
通知チャネルごとの使い分け
| 緊急度 | 推奨される通知チャネル | 対応期限 |
|---|---|---|
| 緊急 | PagerDuty（電話・SMS）+ Slack + メール | 15分以内に初動対応 |
| 高 | Slack + メール | 1時間以内に確認 |
| 中 | Slack + メール | 営業時間内に確認 |
| 低 | メールのみ | 翌営業日までに確認 |
アラート対応のワークフローと継続的改善
アラートが発生したときに、誰が何をどの順序で確認し対応するかを事前に決めておく必要があります。
これを プレイブック と呼びます。プレイブックには、 アラートの内容を確認する手順、初動対応の判断基準、異常と判断した場合のエスカレーション先を含めるべき です。プレイブックは文書として整備するだけでなく、 定期的に訓練を行うことが重要 です。
アラートを運用し始めると、必ず誤検知が発生します。
これを防ぐには継続的なチューニングが必要です。 誤検知を減らす最も効果的な方法は、フィルタ条件を精緻化すること です。例えば、自動化ツールが行う正常な変更を除外する条件を追加します。閾値の調整も重要で、運用しながら誤検知が多い指標については閾値を徐々に調整していきます。
定期的にアラートの効果を評価することも忘れてはいけません。
発生したアラートのうち、 どれだけが本当に対応が必要だったか、どれだけが誤検知だったかを集計 します。誤検知率が高いアラートは見直しの対象で、重要なインシデントを見逃していないかも確認し、必要に応じて新しいアラートの追加や既存アラートの条件緩和を検討します。
7-5. まとめ
第7回も終盤になりました。ここまでログの集中管理と監視アラートについて学んできましたが、振り返ってみましょう。
本回のまとめ
この回では、セキュリティの土台を作る上で欠かせない「何が起きているか把握する」仕組みについて解説してきました。どんなに強固なセキュリティ設定を施しても、実際に何が起きているのかを把握できなければ、本当に安全だとは言えません。
7-1：
なぜログを一箇所に集める必要があるのかを説明しました。ログがバラバラに保存されていると、セキュリティインシデント発生時に攻撃の全体像を把握することが困難になります。迅速なインシデント対応、運用効率の向上、コンプライアンス要件への対応という三つのメリットを理解していただけたと思います。
7-2：
Cloud Loggingのアーキテクチャについて学びました。ログルーターとシンクという仕組みで、ログを適切な転送先に振り分けることができます。転送先は、長期保管用のCloud Storage、分析用のBigQuery、リアルタイム連携用のPub/Subがあり、用途に応じた使い分けができるようになりました。
7-3：
ログ集約プロジェクトの具体的な設計方法を解説しました。専用プロジェクトを作成する理由、推奨されるフォルダ構成、四つの監査ログの種類とその特徴、組織レベルでのシンク設定、保存期間とライフサイクル管理、IAM権限の適切な設定という、実装に必要な知識を網羅的に学びました。
7-4：
Cloud Monitoringを使った監視とアラート設定について学びました。ログベース指標の作成、アラートポリシーの設定、通知チャネルの使い分け、そしてアラート対応のワークフローと継続的改善まで、包括的に理解していただけたと思います。
「何が起きているか把握する」仕組み
これまでの回との繋がり
第7回で学んだログ管理と監視は、これまでの回で構築してきたセキュリティの土台と密接に繋がっています。
このブログシリーズも終盤に差し掛かっていますので、これまでの回と本回のつながりを下記の表にまとめます。
第１～６回までと本回との接点（全９回予定）
| 回 | 主なテーマ | ログ管理・監視との関連性 |
|---|---|---|
| 第1回 | セキュリティの全体像 | 多層防御の一つとして、ログ管理と監視が位置づけられる |
| 第2回 | 組織とリソース階層 | ログ集約プロジェクトの配置、組織レベルでのシンク設定 |
| 第3回 | IAMによる権限管理 | ログ集約プロジェクトへのアクセス権限設定、IAM変更の監視、自動作成されるシンク用サービスアカウントの権限管理 |
| 第4回 | VPCとファイアウォール | ネットワーク設定変更の監視とアラート |
| 第5回 | Shared VPC | ネットワーク基盤の一元管理とログの一元管理の類似性 |
| 第6回 | 組織のポリシー | 予防（ポリシー）と検知（ログ監視）の組み合わせ |
実践へ向けて：最初の一歩
ログ管理と監視の実装は、一度にすべてを完璧に構築する必要はありません。段階的に進めていくことが、現実的で効果的なアプローチです。
最初の一歩として、ログ集約専用プロジェクトを一つ作成し、組織レベルで管理アクティビティ監査ログだけを BigQuery に転送するシンクを設定してみましょう。これだけでも、組織全体の IAM 変更やリソース設定変更を一箇所で確認できるようになります。
次に、IAM 権限変更とファイアウォールルール変更という、最も重要な二つのアラートを設定してみましょう。ログベース指標を作成し、アラートポリシーを設定し、自分のメールアドレスに通知を送るようにします。これで、重要な変更が発生したときに気づける体制が整います。
そして、実際に運用しながら徐々に範囲を広げていきます。データアクセス監査ログを有効化する、Cloud Storage への長期保管を追加する、Slack への通知を設定する、アラートの種類を増やす、といった具合です。
大切なのは、完璧を目指すのではなく、 まず始めること です。小さく始めて、徐々に成長させていくことが、持続可能なログ管理と監視体制を作る鍵です。
次回予告：データ保護戦略
次の第8回では、「最後の砦！データ保護戦略（暗号化とVPC-SC）」 というテーマで学んでいきます。これまでの回で構築してきた組織構造、IAM、ネットワーク、組織のポリシー、そしてログ管理と監視をすべてすり抜けて、万が一データに不正アクセスされた場合、最後の防御線となるのがデータ保護戦略です。
データの暗号化 と VPC Service Controls について学ぶことで、データそのものを守り、データへのアクセス経路を制御する方法を理解できます。
Google によるデフォルト暗号化の仕組み、顧客管理の暗号鍵（CMEK）と Cloud KMS の役割、そして VPC Service Controls による境界防御の考え方を、初級者の方にも分かりやすく解説していきます。
第7回までで基礎的なセキュリティの土台を築き、第8回でデータ保護という最後の砦を学び、そして第9回ではAIを活用した高度なセキュリティと、これまでの知識を統合する実践シナリオで総仕上げを行います。全9回の本ブログシリーズも、いよいよ佳境に入ってきました。
長文のご拝読ありがとうございました！
本編もあと２回となりました。次回の第8回も、ぜひご拝読をお願いいたします。
7-6. 参照情報
この第7回の執筆にあたり、以下の Google Cloud 公式ドキュメントおよび公式ブログを参照しました。
ログ管理と監視について、より詳しく学びたい方は、これらの公式情報源をご確認ください。
Cloud Logging に関する公式ドキュメント
Cloud Logging documentation
Route logs to supported destinations
Aggregate logs across projects
Cloud Audit Logs overview
Enable Data Access audit logs
ログの保存と分析に関する公式ドキュメント
Export logs to BigQuery
Export logs to Cloud Storage
Manage log retention
Object Lifecycle Management
Cloud Monitoring に関する公式ドキュメント
Cloud Monitoring documentation
Create log-based metrics
Introduction to alerting
Create alerting policies
Create and manage notification channels
セキュリティとコンプライアンスに関する公式ドキュメント
Control access to logs
Security best practices
Compliance resource center
実装例とベストプラクティスに関する公式ドキュメント
Best practices for Cloud Logging
Security log analytics patterns
Monitor and respond to Cloud Audit Logs
Discussion