はじめに：SaaSのセキュリティは、事業の存続に関わる

私はこれまで、SaaS事業に関わってきました。その経験から、セキュリティインシデントは事業に直接影響し、最悪の場合は会社が潰れるほどの事態になり得るものとして捉えています。

上司からも同じ趣旨の話をされ、この意識は今も私がセキュリティ運用に取り組むうえでの前提になっています。
顧客のデータを預かり、そのサービスを事業の中心に置く会社にとって、サービスの停止や情報漏洩は技術部門だけの問題ではありません。何を守り、どの兆候を検知し、誰が停止や復旧を判断するかは、事業を続けるための判断でもあります。

それでも、「IAMは必要最小限に絞っている」「監査ログを取得している」「監査もクリアしている」と確認した後に、ぼんやりと思うことがあります。

本当に、明日もこの状態が安全と言い切れるのだろうか……？

システムも組織も変わり続け、完璧なセキュリティは存在しません。だからこそ、対策を導入したことだけで安心せず、変化に気づき、被害を抑え、安全を確認して復旧するまでを運用として設計する必要があります。

本記事では、2026年の国内企業の公表事案から必要な対策を考え、SREとDevSecOpsの視点で整理します。Google Cloudでの実装例と、検知後の判断・対応の流れを通じて、事業を守るセキュリティ運用を考えたいと思います。

ベンチャー・SaaS企業の事案から、何を運用に組み込むか

ここでは、2026年10月11日時点の公表資料から、SaaSの開発・運用に置き換えて考えやすい事例を取り上げます。プロダクト、開発環境、外部サービスという守る対象に注目します。各社の人員構成やセキュリティ専任者の有無は、公表資料からは判断しません。

自分が経験したような少人数のSaaS企業では、セキュリティ専任者を置けるとは限りません。こうした事案から、開発者とSREが日々の仕事に何を組み込むべきかを考えたいと思います。

Helpfeel / Gyazo：一つの機能が侵害された後の影響を考える

Helpfeelは9月16日、画像共有サービス「Gyazo」の画像アップロードサーバーにある脆弱性を悪用され、任意のコマンドを実行されたと公表しました。その後、データベースへのアクセスを確認し、約2,362万件のユーザー関連データと、約4.9億件に加えて別途約240万件の画像メタデータの流出を確認しています。ユーザー関連データの件数には匿名アカウントも含まれ、被害者の人数と同じではありません。Helpfeelの第一報

画像メタデータには画像URLを構成する情報などが含まれ、画像の不正閲覧につながるリスクもあります。9月25日の第二報では、削除済み画像のメタデータ約1.74億件の流出も追加で判明したと報告しています。メタデータの流出件数を、そのまま画像ファイルの流出件数として扱わないことも必要です。Helpfeelの第二報

この事案を自分たちの環境に置き換えるなら、アップロード処理が侵害された場合、どのデータにアクセスでき、どこへ送信できるかを確認したいと思います。機能ごとの権限と接続先を分け、想定外のプロセス実行、データの大量取得、外向き通信を検知します。一つの機能への侵入がサービス全体のデータへ広がる経路を、設計段階で洗い出す必要があると考えます。

Commune：提供するSaaSの事故が、顧客の事業にも及ぶ

LINEヤフーは10月9日、コミューンが提供するコミュニティサービスを利用した「DS.LAB」で、利用者1,750名の情報が閲覧・取得された可能性を公表しました。侵入先はコミューンが運用するサーバーで、システムの不備を悪用されたとされています。LINEヤフー自身のシステムへの不正アクセスとは区別されています。LINEヤフーの公表資料

SaaSを提供する側のインシデントは、利用企業の調査や顧客説明、サービス停止にもつながります。自分たちが預かる情報の一覧、顧客ごとの影響範囲、緊急連絡先を把握し、何が分かった時点で誰に知らせるかを決めておきたいと思います。

自社が外部SaaSを利用する場合も、保存するデータを必要な範囲に絞り、事故の連絡経路や利用停止の手順を確認します。提供する側と利用する側の両方から、サービスの依存関係を運用に含める必要があります。

比較事例：マネーフォワードは開発環境から考える

マネーフォワードは規模の異なる比較事例として取り上げます。5月1日、GitHubの認証情報の漏洩とリポジトリの不正コピーを公表しました。リポジトリにはビジネスカード保有者370件の氏名のアルファベット表記とカード番号の下4桁が含まれ、流出の可能性がありました。ソースコードに含まれていた認証キーやパスワードも無効化・再発行しています。マネーフォワードの第一報

6月23日の第四報では、顧客や取引先、従業員の情報など、追加で流出の可能性が判明した範囲を報告しています。370件が事案全体の件数ではありません。一方、本番データベースへの不正アクセスや、本番環境からの情報漏洩はなかったと報告しています。端末のマルウェア感染やAWS・Google Cloudの権限奪取を、確認した公表資料から原因・被害として断定することはできません。マネーフォワードの第四報

ここから考えたいのは、本番環境に加え、GitHubや開発端末も顧客データと認証情報を守る対象だということです。実データを開発用のコードやテストデータに混ぜない運用、認証情報の混入を検知する仕組み、開発環境の監視を用意します。現在のコードから削除しても履歴に残るため、漏洩した秘密情報は失効・更新まで行う必要があります。

侵入起点と、被害を広げる経路を分けて考える

Gyazoとマネーフォワードの公表資料が示す侵入起点は、それぞれアプリケーションの脆弱性とGitHubの認証情報の漏洩です。公開バケットなどのクラウド設定不備を直接の原因とする事案ではありません。それでも、侵害された処理やIDがどこまでアクセスできるかは、クラウド基盤を設計する際の問いになります。

以下は自分たちの環境に適用する対策案であり、各社でこれらが未実施だった、実施すれば被害を防げたと断定するものではありません。

GitHub ActionsのOIDCは、クラウドへの長期有効なキーを減らす手段になります。ただし、信頼されたワークフローが改変されれば、その権限を悪用される可能性は残ります。ワークフローの変更権限や本番デプロイの承認も合わせて管理します。

DBへの接続を許可するIAMと、接続後にどのテーブルを読み書きできるかを決めるDB権限は分けて考えます。たとえばCloud SQL for MySQLのユーザー権限も、必要な操作の範囲に合わせて設計します。IAMを絞るだけで全件抽出を防げるとは限らず、顧客ごとの認可やデータの分離も必要になります。

外向き通信も、NATを設置しただけで送信先が制限されるわけではありません。WAFもすべての脆弱性を防ぐものではありません。入口の防御、侵害後の権限・通信の制限、検知と封じ込めを組み合わせ、どの対策が何を抑えるのかを明確にします。

図は、自分たちの設計を検討するための概念図です。各対策が抑える経路を確認し、侵害されたIDやワークロードから到達できるデータと接続先を洗い出します。実際の事案の構成を示すものではありません。

これらの事例だけから2026年全体の攻撃傾向を断定することはできません。ただ、自分たちのSaaSでは、プロダクト本体、開発環境、外部サービスまでを守る範囲として考える必要があります。ここから先は、そのための設計と運用を整理します。

監査とチェックリストを、日々の運用につなげる

被害やニュースをきっかけにした対応で終わらせない

セキュリティでは、被害が起きた後や、他社の事案が話題になってから対策に動くことが少なくないと感じます。「自社にも同じ問題がないか」と確認することは必要ですが、そのきっかけを待っている間にも、自分たちのシステムは変わり続けています。

機能開発や日々の運用には目の前の期限があります。一方、まだ被害が出ていないリスクへの対応は、後回しになりやすいです。だからこそ、話題になったときだけ点検するのではなく、公開範囲、権限、脆弱性、ログの取得状況を継続的に確認する仕事として組み込んでおきたいと思います。

他社のインシデントから学ぶことも重要だと思います。公表された原因や被害を自分たちの環境に置き換えて考えることで、普段の点検では見落としていたリスクに気づくことがあります。他社の事案をきっかけに見つかった問題も、設計や運用の改善につなげていきたいです。

「同じ製品を使っていないから大丈夫」で終わらせず、認証情報が盗まれたら、管理用システムが侵害されたら、データを大量に取得されたらどうなるかを、自分たちの環境で考えます。そこで見つかった問題を、具体的な対策のタスクにします。

インシデントは事業の存続にも関わります。私が意識しているこの前提に立つなら、平時の対策や対応準備も事業を続けるための仕事になります。被害が出る前に、必要な時間と予算、判断の責任を組織として確保しておく必要があります。

静的なチェックリストの限界

ISMSやSOC 2などのフレームワーク、各種のセキュリティポリシーは非常に重要です。ただし、監査を通過しても、その後の変更によるリスクが自動的に検知されるわけではありません。監査に合格した翌日、誤ったTerraformのコードがマージされ、意図せず公開バケットが作られるかもしれません。その変更を検知する仕組みは、日々の運用として用意する必要があります。

生き物としてのクラウドインフラ

クラウドインフラは、日々の機能開発、頻繁なデプロイ、サードパーティ連携、組織の拡大に伴って刻一刻と変化し続ける「生き物」です。 コードが増え、依存関係が複雑になると、手動チェックや更新されていないルールだけでは変化を見落としやすくなります。一度確認した結果だけで、変化し続けるインフラを「今は安全だ」と言い切ることはできません。

侵害を前提に、事業への影響を小さくする

システムを設計するとき、私たちはつい正常系で「どう動くか」に意識を奪われがちです。どのAPIを呼び出し、どうデータを渡し、どう速くレスポンスを返すかを考えます。

しかし、信頼性（Reliability）とセキュリティを確保するアーキテクトには、侵害されたときの挙動まで考える視点が求められます。

Assume Breach（侵害を前提とした設計）

「もし認証情報が漏洩したら？」「もし一部のコンテナが乗っ取られたら？」と問い、侵害が起きた状態から逆算して設計します。これがAssume Breachの考え方です。

正常系だけでなく、侵害された際の影響範囲をどこまで小さくできるかも考えます。これはBlast Radiusの最小化と呼ばれます。不審な挙動をいかに即座に検知し、どのように封じ込めるかまでを設計に含めて初めて、侵害を前提としたレジリエンスを備えたインフラになります。

セキュリティはSREだけの仕事ではない

こうしたセキュリティ対策やインフラの監視を誰が担うのかも、組織として考える必要があります。

「SREが全部やる」構造の危険性

特にリソースが限られた組織では、「セキュリティの専門家がいないから、IAMもログ監視も脆弱性対応も、すべてSREが引き受ける」という形になりがちです。 しかし、すべてをSREが引き受けると、運用が属人化します。特定のSREに知識と権限が集中した結果、そのメンバーが退職すると、誰もインフラのセキュリティ状態を把握できなくなります。これは、コスト管理や運用設計でも起きる属人化と同じ問題です。

DevSecOpsの本質と責任の共有

DevSecOpsとは、単にCI/CDパイプラインに脆弱性スキャンツールを組み込むことではありません。 「セキュリティは全員の関心事であり、個々の変更や運用には責任を持つ開発者がいる」という状態を、組織の仕組みとして作ることです。SREは安全なガードレールや共通基盤を整え、開発チームとともに設計、変更管理、監視、インシデント対応を担います。担当範囲を明確にしながら、サービス全体のリスクと運用上の課題を共有します。Google SREの開発者との責任共有も、こうした協働を考える手がかりになります。

設計・開発の段階から、予防策を組み込む

DORAのPervasive securityでは、設計、開発、テスト、リリースを通じて、セキュリティを日々の仕事に組み込むことを重視しています。侵害後の対応を準備すると同時に、危険な変更や実装を早い段階で見つける仕組みも用意したいと思います。

少人数のSaaS企業でも、たとえば次のように既存の開発工程へ組み込めます。

• 新機能の設計時に、扱うデータ、アクセスするID、外部サービスとの接続、信頼の境界を確認する
• 他の顧客のデータを参照・変更できないことを、自動テストで確かめる
• PRやCIで、秘密情報の混入、依存関係の脆弱性、IaCによる公開範囲や権限の変更を検査する
• 共通の認証・認可処理や安全な設定のテンプレートを用意し、開発者が利用しやすくする

検査に失敗したときは、誰が修正するか、どの条件でリリースを止めるかを決めます。例外には理由、判断者、期限を残します。専任者がいない場合も、開発チームとSREでレビューを担い、専門的な判断が必要な変更には外部支援を求めます。検査を増やすことだけを目的にせず、見つかった問題を開発中に修正できる流れを作ります。

セキュリティ対策は、際限なく増やせます。ただ、制約や承認を増やしすぎて開発速度を落とせば、事業を守るための対策が、事業を進める妨げにもなります。対策を選ぶときは、抑えられるリスクと、開発・運用にかかる負担を合わせて考えたいです。

この点は、サービスレベルを考えるときにも似ていると思います。事業に必要な水準を決め、その水準を維持するために投資するという考え方です。顧客ごとのアクセス制御など、必ず満たす条件を明確にしたうえで、リスクに応じて対策の厚さを変えられる部分を整理したいです。

制約を設けるときは、何のリスクを抑えるためなのかを明確にすることが重要だと思います。「セキュリティのため」という理由だけで一律に禁止や承認を増やすのではなく、扱うデータや変更の影響に応じて判断する必要があります。開発者が理由を理解し、安全に進める方法を選べる仕組みにしたいと思います。

教育で、気づく・相談する・行動する力を育てる

技術的な対策に加え、教育によってセキュリティへの意識と、必要な行動を取る力を育てることも大切です。ISMSの基準となるISO/IEC 27001では、7.2で力量、7.3で認識を扱っています。ISOの解説資料でも、この位置づけが説明されています。SOC 2の評価に使われるTrust Services Criteriaでは、CC2.2の着眼点に、教育プログラムを通じたセキュリティの知識・意識の向上が含まれます。

少人数のSaaS企業なら、全員に必要な内容と、役割に応じた内容を分けて考えたいと思います。全員には、認証情報や顧客データの扱い、不審な依頼を受けたときの確認方法、異常に気づいたときの報告先を共有します。開発者には顧客ごとの認可や秘密情報の管理、SREには権限・公開範囲の変更や封じ込め手順、事業責任者には停止・再開や顧客説明の判断を、具体的な場面に沿って扱います。

入社時の説明に加え、役割やシステムが変わったときにも内容を更新します。他社の事案や自社のヒヤリハットを使った短い勉強会、机上演習なども考えられます。「怪しい依頼を受けたら誰に確認するか」「秘密情報を誤ってコミットしたら最初に何をするか」を、その場で確認できる内容にしたいと思います。

「Dockerで学ぶSQL・コマンドインジェクションの仕組みと対策」でも、SREが「セキュリティ警察」となり、レビューや承認、責任が一人に集中する懸念を書きました。教育も、SREだけが注意し続ける状態から、開発者がリスクを理解し、自分で確認・修正できる状態へ進むための取り組みとして考えたいと思います。

受講の記録に加え、理解度の確認や演習で迷った箇所を残し、教材と手順を見直します。分からないことを相談でき、誤操作や異常の疑いを早く報告できる環境も必要です。意識を上げるだけで個人に責任を負わせず、安全な既定値や自動検査と組み合わせます。

外部サービスも選択肢にする：自分たちで担う範囲を考える

セキュリティの検知や分析を、どこまで自分たちで実装・運用するかも設計上の判断になります。クラウドの標準機能や既存のツールを使い、足りない部分を外部サービスで補うという選択肢もあります。WizやSysdigなどは、その例として挙げられます。

アラートを、対応できる量と内容に整理する

環境の規模や依存関係によっては、脆弱性や設定不備の検出結果が多くなり、すべてを同じ優先度で確認することが難しくなります。外部に公開されているか、重要なデータへアクセスできるか、過剰な権限と結びつくかなどを合わせて、対応の優先順位を決めたいと思います。

こうした関連づけや分析を自前で実装する方法も、外部サービスに任せる方法もあります。必要な機能を考えるときは、設定評価、脆弱性の優先順位づけ、実行時の脅威検知などを分け、自分たちの環境で不足している範囲を確認します。製品や契約によって対象と機能が異なるため、導入候補が必要な情報を取得できるかを確かめます。

導入した安心感だけで終わらせない

私自身、セキュリティ対策を運用する中で、ツールやサービスの導入が精神安定剤のように感じられることがあります。「備えがある」という安心は得られるが、それで安全を保証できるわけではありません。

ツールやサービスは銀の弾丸ではなく、守れる範囲には限界があります。導入による安心感と、実際にどのリスクを抑えられているかは分けて考えたいと思います。検知結果を確認し、必要な対応を取り、検知できない範囲も把握します。

運用負荷と費用を含めて選ぶ

外部サービスを使う場合も、検出結果の確認、修正、例外の判断は自分たちの仕事として残ります。対応する担当者、既存の通知やチケットとの連携、費用、導入後の運用負荷を含めて選ぶ必要があります。

判断の基準は、そのサービスによって必要なリスクを把握できるか、反復作業を減らせるか、改善に使う時間を確保できるかです。Google SREのトイル削減も、繰り返し発生する運用作業を減らし、継続的な価値を生むエンジニアリングに時間を使うことを重視しています。

自前の実装、クラウドの標準機能、外部サービスを組み合わせ、自分たちが維持できる運用を選びます。

Google Cloudで実現するなら：Professional Cloud Security Engineerの内容に沿って考える

ここまでの考え方をGoogle Cloudの運用に取り入れるなら、Professional Cloud Security Engineerの公式試験ガイドが整理の手がかりになります。アクセスの構成、通信と境界の保護、データ保護、運用管理、コンプライアンスという領域から、自分たちの環境に必要な対策を考えられます。

設計と運用の方針には、Google Cloud Well-Architected Frameworkも参考になります。この記事では、セキュリティとオペレーショナル エクセレンスの柱を中心に、試験ガイドの内容を日々の運用に結びつけて考えます。

責任共有モデルを出発点にする

まず、Google Cloudと利用者の責任範囲を確認します。マネージドサービスを使っても、利用者が管理するID、アクセス権限、データの扱いまでGoogleに任せられるわけではありません。責任の境界は利用するサービスによって変わります。責任共有モデルと運命の共有を踏まえ、どの設定や運用を自分たちが担うのかを明確にします。

そのうえで、利用者側の責任を組織内でも分担します。SREが共通の基盤や制約を整え、開発チームがアプリケーションの権限やデータ利用を管理する、といった役割分担を決めます。担当者と判断の根拠を文書に残すところまでが運用の設計です。

Cloud IdentityとWorkload Identityで、人とワークロードのIDを管理する

人のIDは、Cloud Identityでユーザーとグループを管理し、入社・異動・退職に伴う変更をアクセス権限に反映します。既存のActive Directoryなどと連携する場合は、Google Cloud Directory Sync（GCDS）でユーザーやグループを同期します。GCDSによるIDの同期と、外部IDプロバイダを使ったSSOによる認証は、それぞれ役割が異なります。ID管理のリファレンスアーキテクチャを基に、認証、2段階認証、特権アカウントの管理も含めて設計します。

ワークロードには人とは別のIDを与え、必要な権限だけを付与します。たとえば外部のCI/CDからGoogle Cloudにアクセスする場合は、Workload Identity Federationを使い、長期有効なサービスアカウントキーを配布せずに認証する構成を検討します。認証情報の置き場所だけでなく、どのワークロードに何を許可するかを管理することが重要です。

リソース階層とAccess Context Managerで、権限とアクセス条件を整理する

リソース階層では、組織、フォルダ、プロジェクトを使って管理単位を分けます。IAMの権限継承を踏まえ、上位階層で広い権限を付与していないかを確認します。組織ポリシーも組み合わせ、開発チームが守るべき共通の制約を設定します。

Access Context Managerでは、送信元IPやデバイスの状態などに基づくアクセスレベルを定義します。これをIAPやVPC Service Controlsで利用し、アクセス時の条件を制御します。IAMによる権限の管理と、アクセス元の条件を組み合わせて考えます。

ネットワークの境界制御は、通信の役割ごとに分ける

VPCとファイアウォールでは、必要な通信だけを許可するようにネットワークを設計します。外部公開するアプリケーションでは、ロードバランサーを入口として、Google Cloud ArmorによるWebアプリケーションファイアウォール（WAF）で不正なHTTPリクエストを制御します。利用者を限定する管理画面などには、Identity-Aware Proxy（IAP）による認証・認可を組み込みます。

Cloud DNSも境界の設計に含めます。公開する名前と内部だけで使う名前を分け、公開ゾーンではDNSSECによるDNS応答の真正性の検証も検討します。

GoogleのAPIやサービスへの接続では、限定公開のGoogleアクセスやPrivate Service Connectを検討します。前者は外部IPアドレスを持たないVMからGoogleのAPIやサービスにアクセスするための機能で、後者はVPC内からマネージドサービスなどにプライベートに接続するための機能です。

さらに、対応するGoogle Cloudサービスのデータを境界で保護するために、VPC Service Controlsを使います。これはIAMを補完してデータ流出リスクを減らす仕組みであり、VPCのファイアウォールとは役割が異なります。接続経路を限定することと、境界を越えたデータアクセスを制限することを分けて設計します。

Secret ManagerとCloud KMSで、秘密情報と暗号鍵を管理する

APIキーやパスワードなどは、Secret Managerで保管し、参照権限とバージョンを管理します。暗号鍵の管理にはCloud KMSを使います。秘密情報を保管する役割と、データの暗号化に使う鍵を管理する役割を分けて考えます。

どちらも、サービスを導入しただけでは運用は完了しません。誰が参照・利用できるか、いつ更新するか、漏洩時にどう失効させるかを決めます。SREと開発チームの間で、更新作業とアプリケーションへの反映の担当を明確にしておきます。

ネットワークログとSecurity Command Centerを、対応につなげる

ネットワークの挙動は、VPC Flow Logsやファイアウォールのログで確認します。VPC Flow Logsはサンプリングされた通信情報であり、すべてのパケットを記録するものではありません。調査の目的に合わせて取得対象や保存期間を決め、Cloud Loggingで分析します。

操作の追跡にはCloud Audit Logsも必要になります。Data Access監査ログはBigQueryを除いてデフォルトで無効のため、必要なサービスで明示的に有効化します。ログを集めるだけでなく、調査する人の権限と、インシデント時に確認する手順も整えます。

Security Command Centerでは、設定不備や脅威などの検出結果を確認します。組織レベルで有効化したPremiumなどの対象ティアでは、攻撃エクスポージャースコアと攻撃パスを使った優先順位づけもできます。ただし、攻撃パスは想定される経路のシミュレーションであり、実際の侵害を示す証拠ではありません。

「どう検知するか」を、対象・情報源・条件で具体化する

ログを保存し、Security Command Centerを有効にするだけでは、何を見て対応すべきかは決まりません。まずは「非公開のデータが公開される」「想定外の権限が付与される」「認証情報が悪用される」といった、検知したい状態や操作を決めます。そのうえで、情報源と検知条件を対応づけます。

設定不備の検知には、Security Health Analyticsなどの設定評価を使います。ただし、利用できる検出機能はティアや有効化・移行の状況によって異なり、新規有効化の環境ではCompliance Managerによる設定評価が案内されています。自分たちの環境で、必要な項目を評価する機能とルールが有効になっているかを確認します。

操作の検知では、たとえば本番プロジェクトのサービスアカウントキー作成を監視対象にします。Cloud Audit Logsのサービス名、メソッド名、対象リソース、操作の成否でログを絞り、ログベースのアラートを設定します。単一の操作に反応する条件と、ログベースの指標を使って一定時間の件数に反応する条件は分けて設計します。

Event Threat Detectionは、対応するログから既知の攻撃指標や攻撃手法、異常な挙動を検出します。一方、自社の業務で何件のデータ取得を異常とするかは、自分たちで定義する必要があります。組み込みの検出機能と、アプリケーションの特性に合わせた条件を組み合わせます。

検知条件を決めたら、必要なログが実際に出力され、検知の仕組みまで届いているかを確かめます。Data Access監査ログやアプリケーションログがなければ、そのログを前提とした条件では検知できません。検出機能の対象サービスや必要なログ、取得設定を確認するところまでが検知の設計です。

通知をつなぎ、検知できることを確かめる

運用への組み込み方としては、検出結果をPub/Subに継続的にエクスポートし、既存の通知やチケット作成の処理につなぐ構成が考えられます。ログベースのアラートにも通知先を設定し、対応するチーム、期限、修正後の確認方法を決めます。例外として受け入れるリスクには理由と見直し期限を残します。

通知には、対象リソース、操作したID、発生時刻、検知した理由、確認すべきログや手順へのリンクを含めます。アラートは調査のきっかけであり、侵害が確定したことを意味しません。通常の変更や承認済みの操作だったかを確認し、不審な場合は権限の停止や通信の制限などの封じ込め手順に進みます。

最後に、検証用の環境で監視対象の操作を実行し、ログの記録から検知、通知、担当者による確認までを通して試します。設定不備の評価や件数のしきい値も、可能な範囲でテストケースを用意します。通知が届くまでの時間を測り、必要な対応時間に合うかを確認します。ルールや通知先を変更した後も、同じ流れで確かめます。

誤検知と見逃しを振り返り、検知条件と対応手順を更新し続けることが重要です。

これは、Well-Architected Frameworkのオペレーショナル エクセレンスの柱が扱うインシデント管理や継続的な改善にもつながります。Google Cloudの各サービスを、検知から対応、振り返りまでの一連の運用として組み合わせることが、ここまで述べてきたDevSecOpsの実践になります。

運用が機能しているかを測り、改善する

検知や対応の仕組みも、継続的に確かめる対象になります。自分たちの運用を見直すために、検証時に通知が届かなかったケース、一次応答までの時間、対応不要だった緊急通知の割合、期限を過ぎた修正・改善タスクを確認したいと思います。検知件数の増減だけでは、安全性が改善したかは判断できません。ログやルールの変更によって件数が変わる場合もあるため、検知のテスト結果や対応内容と合わせて評価します。

Google SREの監視とアラートの考え方も、人を呼び出す通知の負担とノイズを重視しています。緊急通知には今すぐ必要な行動を対応づけ、通常の修正タスクと分けます。繰り返し発生する確認や通知の重複は、手順や自動化を見直して減らします。

可用性のSLOと、セキュリティ対応の目標・必須条件は区別して整理します。たとえば、重要なアラートへの応答時間には目標を定め、顧客ごとのアクセス制御には満たすべき条件を定めます。可用性のエラーバジェットが残っていることを、機密性の侵害を許容する理由にはしません。目標に届かない場合は、担当者の努力だけに頼らず、通知、権限、手順、対応体制を見直します。

検知した後を設計する：誰が判断し、どう対応を進めるか

検知の仕組みがあっても、通知を受けた人が「これは誰に相談するべきか」「自分の判断で止めてよいのか」と迷っていては、対応が遅れます。セキュリティ運用では、アラートを受け取った後の判断と行動まで設計する必要があります。

Well-Architected Frameworkのインシデントと問題の管理でも、役割、連絡経路、エスカレーション、対応手順の文書化が推奨されています。ここでは、それをセキュリティ運用に当てはめた一例として考えます。

受付から終結までの流れを決める

基本の流れは、受付、初動調査、重大度判定、封じ込め、原因除去、復旧、振り返りです。ただし、被害が進行している場合は調査と封じ込めを並行して進めます。最初の判定で終わらせず、新しい情報が分かるたびに重大度と対応方針を見直します。

アラートには、誤検知、承認済みの変更、期限を決めて修正する設定不備、緊急対応が必要な侵害の疑いが混在します。すべてを同じ緊急度で扱わず、判断した理由を対応記録に残します。調査で判断できない場合も、保留のまま放置せず、次に確認する担当者と期限を決めます。

被害が進行しているときは、調査と封じ込めを並行します。証拠保全、対応記録、状況共有も各段階で続け、安全を確認したうえで再開を判断します。図の矢印は基本の流れであり、新しい情報が分かれば重大度や対応方針を見直します。

重大度と夜間対応の基準をそろえる

重大度は、ツールが表示するSeverityだけで決めません。対象が本番環境か、機密データにアクセスできるか、権限がどこまで広がるか、被害が進行しているか、サービスへの影響があるかを合わせて判断します。

たとえば、重要なデータへの不審なアクセスが続いている場合は、夜間でも担当者を招集し、封じ込めを検討します。一方、影響範囲を確認でき、直ちに被害が拡大する状況ではない設定不備は、期限を決めて通常のタスクとして対応します。この区別は組織が守るデータやサービスに合わせて決めるものであり、夜間に対応できる体制とも一致させる必要があります。

「緊急時はSREに連絡する」だけでは、担当者の不在や応答の遅れに対応できません。一次対応者が応答しない場合の連絡先、一定時間で判断できない場合の相談先、引き継ぐ情報までを決めておきます。

少人数でも、判断者と実行者を明確にする

少人数の組織では、一人が複数の役割を兼ねることもあります。専任の担当者を役割ごとに置くことより、その場で誰が判断し、誰が実行するかを明確にすることが重要です。会社の事業に影響する判断については、経営・事業責任者への連絡と判断の経路も用意します。

役割分担の一例として、SREはクラウド基盤や通信経路の調査・変更を担い、開発チームはアプリケーションの挙動、正規の操作、データへの影響を確認します。セキュリティ担当は侵害の評価や対応方針を支援します。専門の担当者がいない組織では、その判断を担う責任者と、外部支援を求める条件を決めます。

複数のチームが動く場合は、対応全体を統括する責任者を置きます。技術的な調査、変更の実行、社内への状況共有を分担し、判断と作業の記録を一か所に集めます。役職やチーム名だけでなく、その時点で誰が担当するかが分かる状態にします。

特に、権限の停止やサービスの遮断は、技術的に実行できることと、実行を判断してよいことを分けて考えます。事前に承認した手順の範囲で一次対応者が実行できる操作と、責任者の判断が必要な操作を明確にします。緊急時の判断者が不在の場合の代行者も決めておきます。

封じ込めと復旧の条件をセットで用意する

封じ込めでは、不審なキーの無効化、権限の制限、通信の遮断、対象ワークロードの隔離などを検討します。ただし、共有のサービスアカウントやネットワーク設定を変更すると、正規の処理も止まる場合があります。どの処理に影響するか、代替手段があるかを確認し、変更内容と判断理由を記録します。

調査に必要なログ、設定、発生時刻などの情報も保全します。被害の拡大を止める対応と並行して、後から経緯を追える状態を残します。証拠を失う変更やリソースの削除を、調査手順を確認せずに進めないようにします。

復旧は、アラートが止まったことだけで判断しません。侵入経路や設定不備が修正されたか、漏洩した認証情報が失効しているか、不審な権限や処理が残っていないか、正規のサービスが動作するかを確認します。確認結果を基に再開を判断し、復旧後の監視方法と期間も決めます。

状況共有と振り返りも運用に含める

対応中は、確認済みの事実、未確認の点、実施した対応、次に判断することと情報の更新予定を分けて共有します。サービスやデータへの影響が疑われる場合は、事業責任者や必要な関係者に連絡します。社外への説明が必要になった場合も、誰が内容を確認し、誰が発信するかを事前に決めておきます。

対応が終わったら、検知までの時間、初動の遅れ、判断に迷った箇所、手順や権限の不足を振り返ります。検知ルールの修正、権限の見直し、ガードレールの追加、手順の更新を、担当者と期限のあるタスクにします。原因を個人の注意力だけに求めず、同じ状況で次の担当者も対応できる仕組みに改善します。

最後に、机上演習や検証環境での訓練を通じて、連絡先、判断権限、封じ込め、復旧までの流れを確かめます。手順書が存在することと、その手順で実際に動けることは別です。人やシステムが変わった後も、対応できる状態を維持するところまでがセキュリティ運用だと考えます。

おわりに：事業を守るために、運用を続ける

SaaSのセキュリティ運用は、事業を続けるための仕事です。最初のSaaS企業で、上司からインシデントは会社の存続にも関わるという話を聞きました。その話は、今もセキュリティ運用に取り組むうえでの前提になっています。

セキュリティに絶対のゴールはありません。インフラが動き続ける限り、リスクは形を変えて生まれ続けます。

だからこそ、私たちが目指すべきは「事故が絶対に起きない状態」ではなく、次の取り組みを続けられる組織と運用プロセスの確立になります。

• 自分たちのインフラの現状を正しく把握する
• リスクを直視して優先順位をつける
• 自動化や組織の仕組み、優れたツールを使って改善し続ける

こうした取り組みを続けられることが、組織のレジリエンスにつながります。

「うちは大丈夫」と言い切ることは難しいです。それでも、何を守り、どう検知し、誰が判断して対応するかを説明できる状態は目指せます。その仕組みを日々見直し、事業を守り続けることが、私の考えるSREとDevSecOpsのセキュリティ運用のあるべき姿だと考えています。