この記事でわかること
-
従来のセキュリティ対策が陥る「完璧主義の罠」とその弊害
-
SREの「エラーバジェット」思考をセキュリティ運用に応用する具体的な方法
-
アラート疲れを防ぎ、持続可能な運用を実現するトリアージとチーム体制
日々進化する脅威に対応するため、セキュリティ対策は複雑化・高度化しています。しかし、その結果として「すべてを守らなければならない」という完璧主義に陥り、膨大なアラート対応に現場が疲弊しているケースも少なくありません。
「完璧を目指さない」ことを前提とするSRE（Site Reliability Engineering）の合理的な思考は、この課題を解決するヒントになります。
今回は、株式会社スリーシェイクでコンテナ・クラウドセキュリティの技術支援に携わる水元恭平氏にインタビュー。SREの「エラーバジェット」思考をセキュリティに応用し、持続可能な運用体制を築くための実践的アプローチについて伺いました。
水元 恭平
株式会社スリーシェイク Sreake事業部
株式会社スリーシェイクに所属し、コンテナ・クラウドセキュリティの領域で技術支援を行っている。好きな技術はKubernetes。 職務の一環として、技術イベントの運営やカンファレンスでの登壇を行う他、「Container Security」の書籍の監訳を務めた。
【X（旧Twitter）】：https://x.com/kyohmizu
目次
完璧主義が招く「アラート疲れ」と「運用の形骸化」
まず、水元さんのこれまでのご経歴と、SREやセキュリティ領域との関わりについて教えていただけますか？
私はスリーシェイクが2社目で、前職では約9年間、Windows環境でのアプリ開発をしていました。当時はクラウドやKubernetes（※1）とは縁がなかったのですが、個人的にSREやセキュリティ、クラウドネイティブ系のエンジニアコミュニティで活動する中でKubernetesに強い興味を持ち、「業務でも扱いたい」と思うようになったのが転機です。
その繋がりがきっかけで、約5年前にSREエンジニアとしてスリーシェイクに入社しました。 入社当初はSREとして配属されましたが、案件の都合でセキュリティ領域をメインで担当するようになりました。現在は、SREとしての知見も活かしつつ、クラウドセキュリティ（AWS/GCP）やクラウドネイティブ系のセキュリティ技術支援を専門にしています。
※1 Kubernetes: 多数のコンテナを本番環境で自動運用・管理するためのソフトウェア。「コンテナオーケストレーションツール」とも呼ばれる。
アプリ開発からインフラ、そしてセキュリティへと領域を広げてこられたのですね。今回のテーマは「SRE思考のセキュリティ運用」ですが、従来のセキュリティ対策ではどのような課題があるのでしょうか？
やはり「完璧主義の罠」に陥りがちだという点です。 例えば、何かのルール（セキュリティ基準）に準拠しようとして、上から下までチェックリストをすべて満たそうとするケースです。 そうすると、膨大な数のポリシー違反やアラートが最初に出てしまい、結局すべてを処理しきれずに頓挫してしまうことになりかねません。
耳が痛い話です。現場としては対応しきれないですよね。
無理に対応しようとすると、今度は「開発生産性の毀損」という別の問題が起きます。 例えば、ネットワークを過度に制限して開発に支障が出たり、リリースプロセスが複雑になりすぎてスピードが落ちたりする。これは結果としてビジネスインパクトにつながってしまいます。
そうして対応しきれないアラートが増えると、ノイズが多すぎて本当に危険なアラートが埋もれてしまう状況になってしまいますよね。現場がアラート対応に疲弊してしまう根本的な原因はどこにあるのでしょうか？
まず、ツール自体が過剰にアラートを出しすぎているという問題があります。 もちろん緊急度は定義されていますが、その総量があまりに多い。「今すぐ対応する必要があるもの」は、実はそれほど多くないのが現状です。
緊急度は定義されていても、ノイズが多いということですね。
また、SREの視点から言うと、そもそもただのメトリクス（測定値）と、本当にサービスの信頼性に関わるSLI（サービスレベル指標）（※2）が切り分けられていないケースが多いんです 。
そのアラートが本当にSLO（サービスレベル目標）やクリティカルユーザージャーニー（顧客の重要な体験）に関係しているのか、曖昧なまま運用されてしまっている 。だから「これは対応しなくても問題ない」という意識が運用者の中に芽生えてしまい、本当に重要なアラートも見過ごされがちになります。
加えて、セキュリティ運用にリソースを割けていないケースも多いようです。開発者やインフラ担当者が兼務していると、どうしても対応できる範囲は限られてしまいます。 結果として、緊急度が高いものやインターネット露出面だけを確認し、他は対応せずに「閉じてしまう」運用になりがちです。
※2 SLI (Service Level Indicator): サービスレベル指標。サービスの信頼性や性能を測定する具体的な指標（例：レイテンシ、エラー率）。SLO（目標値）の達成度を測るために使われます。
SREの「エラーバジェット」をセキュリティに応用する
そうした課題を解決する鍵が「SRE思考」ということですね。改めて、水元さんの言葉で「SREとは何か」を教えていただけますか？
SRE（Site Reliability Engineering）とは、大雑把に言うと「ソフトウェアエンジニアリングのアプローチで運用課題を解決する」ことです。 中核となる要素には「計測（観測性※3）」や「自動化」があり 、その結果としてサービスの信頼性を維持することと、開発スピードを向上させること、この二つを両立させるための「仕組みづくり」全般を指すと考えます。
また、SREの本質は、信頼性をひたすら高め続けることではなく、「どこまでなら落としてもよいか」という許容される範囲（エラーバジェット）をあらかじめステークホルダーと合意し、運用全体を設計していくことにもあります 。
※3 観測性 (Observability): システム内部の状態を、外部への出力（ログ、メトリクス等）からどれだけ深く理解できるかを示す性質。問題の原因究明に不可欠。
信頼性と開発速度はトレードオフになりがちですが、それを両立させる仕組みだということですね。SREのどのような点がセキュリティ運用に有効だとお考えですか？
「不確実性を一定許容する」という点と、「計測と自動化」という点がセキュリティ運用にとって特に有効だと考えています。 「不確実性を許容する」というのは、まさに「セキュリティを完璧に目指さない」という話に当てはまります。
そして「計測と自動化」は、先ほどのアラート疲れのような運用負荷をどうやって効率化・改善していくか、という点に直結します。
SREの核心的な概念に「エラーバジェット（許容される障害の範囲）」がありますが、これをセキュリティに応用するとは、具体的にどういうことでしょうか？
まず大前提として、実際の「侵害」や「インシデント」が発生した場合、それは一発アウトです。 これはエラーバジェットを全て消費しきったのと同じで、開発を止めてでも最優先で対応すべきものです。
確かに、そこは可用性（※4）（例：99.9%）の考え方とは違いますね。
※4 可用性 (Availability): システムが停止することなく、正常に稼働し続ける能力のこと。「99.9%（スリーナイン）」のように稼働率で示されることが多い。
セキュリティにおけるエラーバジェットは、むしろ「通常運用のリスクをどれだけ許容できるか」という度合いだと考えています。 例えば、脆弱性対応やポリシー違反の解消は、通常業務として一定のSLO（※5）（サービスレベル目標）を定義して運用していると思います。
※5 SLO (Service Level Objective): サービスレベル目標。SREにおいて、サービスの信頼性（例：可用性99.9%）を具体的に定めた目標値のこと。
例えば「CVSS（※6）スコアがCriticalの脆弱性は48時間以内に対応する」といったものです。 しかし、リソース不足などでその対応がどんどん「遅延」したり「滞留」したりしていく。この「遅延・滞留」が一定の閾値を超えたら、エラーバジェットを消費したとみなし、アラートを出して解消に注力する、といった考え方です。
※6 CVSS (Common Vulnerability Scoring System): 発見された「脆弱性（セキュリティ上の弱点）」の深刻度を、共通の基準で評価し、数値化（スコアリング）する仕組み。「Critical（緊急）」などで示されます。
なるほど。「侵害」そのものではなく、侵害に至る可能性のある「リスクの放置」をバジェットとして管理するのですね。 とはいえ、「セキュリティに妥協（許容範囲）は許されない」といった経営層や他部門からの反発はありませんか？
それはありますね。 ただ、そこはもう「セキュリティに100%はあり得ない」という現実を前提として認識してもらうしかありません。 その上で、なぜ完璧を目指さないのかを「ビジネスインパクト」で説明することが重要です。
ビジネスインパクトですか。具体的にはどういうことでしょう？
「完璧」を目指すために過剰な対策や複雑なプロセスを導入した結果、開発スピードが落ちてビジネス機会を損失する影響と、ある程度のリスクを許容した場合の影響。この2つを天秤にかけ、どちらを優先すべきか判断することです。
例えば、SREの可用性でよく言われる話ですが、可用性を99.99%にするのと、99.999%にするのとでは、必要な対応やコストがまったく違います 。セキュリティも同じで、完璧を目指すのは不可能です。その分のリソースを別の価値あるところに回す、という合理的な判断が必要です 。
「やらないこと」を決める優先順位づけの実践法
エラーバジェットの考え方は、「やらないことを決める」ことにも繋がると思います。膨大な脆弱性やアラートに対し、どのような基準で優先順位づけ（トリアージ）をされていますか？
まず大前提として、「自分たちが失ってはいけないものは何か」「本当に必要なセキュリティ対策は何か」という目的（オブジェクティブ）をきちんと定めることが重要です 。 その上で、CVSS（共通脆弱性評価システム）のスコアだけでは不十分だと考えています。 我々が重視しているのは、それに加えて「 攻撃の可能性 」と「 ビジネス（システム）への影響 」です。
「攻撃の可能性」とは、具体的にどう判断するのでしょう？
例えば、そのシステムが「インターネットに露出しているか」は大きな判断基準です。 さらに、その脆弱性に対する「攻撃コード（※7）がすでに公開されているか」どうかも見ます。
公開されていれば、誰でも簡単に攻撃できるため、緊急度は一気に上がります。 こうした複数の要素を組み合わせて、対応の緊急度を判断することが重要です。
※7 攻撃コード (Exploit Code): システムの脆弱性を悪用して攻撃を行うためのプログラム。これが公開されると、誰でも容易に攻撃を試みることが可能になるため危険度が上がります。
水元さんのご専門であるKubernetes環境などで、リスクを認識しつつも「今は対応しない」と判断した具体例があれば教えていただけますか？
例えば、先日コンテナランタイム（※8）に緊急度の高い脆弱性が出ましたが、これはリスクは認識しつつも、緊急対応は不要（＝優先度を下げる）と判断しました。 これは先ほどの基準で言えば「攻撃の可能性が低い」ためです。
※8 コンテナランタイム (Container Runtime): コンテナを実際に実行・管理するためのソフトウェア。「containerd（コンテナディー）」などがあり、Kubernetesがこれを操作してコンテナを動かします。
どういうことかと言うと、クラウドネイティブのアーキテクチャは層構造（クラウド/クラスター/コンテナ/アプリ）になっていて、基本的にインターネットに直接露出しているのは一番上の「アプリケーション」層と一番下の「クラウド」層です。真ん中にあるKubernetesクラスター（※9）本体やコンテナランタイムは、通常インターネットから直接アクセスできません。
※9 クラスター (Cluster): 複数のサーバー（ノード）を連携させ、全体で一つのシステムとして動作させる技術。Kubernetesでは、コンテナを動かすサーバー群の管理単位を指します。
露出していない層、ということですね。
今回の脆弱性を悪用するためには、まずアプリケーション層が侵害され、そこを踏み台（※10）にして内部ネットワークに侵入するか、あるいは内部の人間が悪意を持って操作する必要があります。 攻撃のハードルが高い、つまり「攻撃の可能性が低い」ため、まずは露出しているアプリケーション層の防御を優先すべき、その他は後で対応するという判断です。
※10 踏み台 (Stepping Stone): 攻撃者が目的のサーバーに直接侵入せず、中継地点として利用する別のサーバーのこと。まずセキュリティの甘いサーバーに侵入し、そこから内部へ攻撃を広げます。
アラート疲れを防ぐ「自動化」と「継続的な見直し」
優先順位づけをしても、日々のアラート対応に追われると「アラート疲れ」は防げません。現場が疲弊せず、重要なアラートに集中できるトリアージ設計や運用のポイントは何でしょうか？
ポイントは2つで、1つは「自動化を進める」こと。もう1つは「対応できる範囲に（アラートを）とどめる」ことです。
自動化というのは、具体的にどの部分を進めれば良いですか？
まず取り組むべきなのは、人的な判断や情報収集、トリアージといった雑務的な部分です。 例えば、アラートが出た際に、それに関連する情報を外部（例：脅威インテリジェンス ※11）から収集したり、内部の資産台帳（※12）と突き合わせたりする作業を自動化するだけでも、運用負荷は大きく下がります。
※11 脅威インテリジェンス (Threat Intelligence): サイバー攻撃の手法、攻撃者の情報、脆弱性情報などを収集・分析した知見やデータのこと。
※12 資産台帳 (Asset Inventory): 組織が保有するIT資産（サーバー、ソフトウェア、データなど）の一覧と、その重要度や管理者などの情報をまとめた台帳。
もう1つの「対応できる範囲にとどめる」というのは、緊急度の低いアラートはそもそも発生しないように抑制・無効化してしまうということです。
抑制・無効化しても大丈夫なのでしょうか？
もちろん、そのアラートを止めたことで発生するリスクは、認識した上で「許容する」という判断が必要です。
重要なのは、一度設定して終わりではなく、それらのルールや仕組みを継続的に見直し、改善していくことです。 ツールを導入しただけ、ルールを作っただけで放置すると、すぐに形骸化してしまいます。
「イネーブリングチーム」として伴走し、自走できる組織を作る
運用の仕組みだけでなく、チーム体制も重要ですね。水元さんはセキュリティ担当者を「イネーブリングチーム（※13）」的な立ち位置と捉えていらっしゃるとのことですが、従来の「ゲートキーパー（門番）」型とは何が違いますか？
※13 イネーブリングチーム (Enabling Team): 他のチーム（例：開発チーム）が自律的に高いパフォーマンスを発揮できるよう、ツール提供や教育などで支援（Enable＝可能にする）する専門チーム。
SREの考え方と似ていますが、まず「使うだけで自然と安全になる」ような仕組みや基盤を標準提供することが挙げられます。 その上で、開発チームやインフラチームの中に我々が実際に入り込んで、教育やツール提供、プロセス改善を支援します。 門番のように「あれはダメ」「これはダメ」と制限するのではなく、開発者やインフラ担当者、それから経営層も含めて、各自がセキュリティにちゃんと向き合えるように支援したり、後押ししたりするのがイネーブリングチームの役割です。
スリーシェイク様は「内製化の伴走支援」を強みとされ、最終的にクライアントが「卒業（自走）」することを目指していると伺いました。 SREの専門チームが伴走支援する際、従来のSIerとの違いはどこにあるのでしょうか？
我々は「言われたことをそのままやる」ことはしません。まずお客様の課題感を整理し、事前に持ってこられた課題とは異なる「より本質的で、コスト効率の良い優先順位」を再提案することが多いです。
課題の再定義から入るのですね。
はい。そして、先ほどのイネーブリングチームのように、お客様のチームに深く入り込みます。 重要なのは、お客様の事情や体制、リソースを考慮し、彼らが「実際に運用できる範囲」の仕組みを一緒に作り上げることです。
なぜなら、処理しきれない高機能な仕組みを提供しても、運用でつまずいてしまっては意味がありませんから。 そこでマインドセットやスキル、ノウハウを移転し、最終的に我々がいなくても自走できる状態を目指すのが、我々の伴走支援です。
逆に、SRE的なアプローチを自社だけで導入しようとする際、エンジニアが陥りがちな「落とし穴」はありますか？
やはり「ツール導入だけで終わってしまう」ことですね。 ツールを入れたときに「誰がどうやって運用するのか」という体制やプロセス設計を考えないと、結局アラートが放置されて何も変わりません。
また、社内のSREチームや共通基盤チームとの連携も非常に重要です。 彼らと協力して自動化や基盤活用を進めれば、セキュリティ運用の負荷を大幅に下げられる可能性があります。
最後に、こうした戦略的なセキュリティ運用を担うエンジニアとして、今後どのようなスキルや視点が求められるか、読者へのメッセージをお願いします。
セキュリティ運用は、もはやツールを操作するだけではありません。仕組みを自動化するための「実装スキル」や、インフラ・開発の知識がますます求められています。 SREチームがそうであるように、開発経験者やインフラ経験者がセキュリティチームに加わることで、チーム全体の能力は格段に上がります。
特にクラウド化が進む中で、SREやセキュリティ人材の需要は高まっています。 中でもクラウドネイティブ領域のセキュリティは、まだ専門家が少ない「ブルーオーシャン」でもあるので、これから挑戦する価値は非常にあると思います。
ライター
