Securify Blog 第2回 SRE 視点で考える「セキュリティ対策」─「やらないことを決める」戦略的な選択とは？ (2025年6月2日)

セキュリティ対策というと、「すべてを守らなければならない」という発想に陥りがちです。しかし現場では、人的リソースも予算も限られており、結果として対策が後回しになったり、形式的な対応にとどまってしまうケースも少なくありません。● セキュリティ対策に SRE の視点を取り入れる SRE（Site Reliability Engineering：サイト信頼性エンジニアリング）とは、ITサービスの信頼性を高めるために、ITエンジニア（開発者）が信頼性向上のために行う設計やアプローチを指します。その本質は、「信頼性を高め続けること」ではなく「どこまでなら落としてもよいか」という許容される範囲（エラーバジェット）を設け、運用全体を設計していくことにあります。 今回は、SRE支援を行う「Sreake（スリーク）」事業にて SREエンジニアとして多くの現場に携わり、事業部長を務めたのち、現在は統合セキュリティプラットフォーム「Securify（セキュリファイ）」の事業責任者を務める手塚 卓也と、クラウド・コンテナセキュリティの現場で実践を重ね、「Container Security」の監訳なども手がける水元 恭平が、セキュリティ対策と運用のリアルについて語り合います。 膨大な守備範囲、日々届く無数のアラート、形骸化しやすい運用…。SRE の合理性をヒントに、持続可能なセキュリティ対策を実現するための考え方に迫ります。▼プロフィール手塚 卓也（@tt0603） / 株式会社スリーシェイク Securify事業部 事業部長 新卒で ITベンチャー企業にインフラエンジニアとして入社。自治体やデータベースマーケティング会社でのインフラ設計/構築/運用を主に経験し、2018 年 10 月にスリーシェイクに転職。SRE支援を行う Sreake（スリーク）事業部のエンジニア、事業部長を経て、現在は統合セキュリティプラットフォーム「Securify」の事業部長としてプロダクトの成長とチームを牽引している。水元 恭平（@kyohmizu） / 株式会社スリーシェイク Sreake事業部 株式会社スリーシェイクに所属し、コンテナ・クラウドセキュリティの領域で技術支援を行っている。好きな技術は Kubernetes。 職務の一環として、技術イベントの運営やカンファレンスでの登壇を行う他、「Container Security」の書籍の監訳を務めた。●セキュリティ担当者に求められる役割手塚：セキュリティ対策って、つい「それ単体で完結するもの」として捉えられがちなんですけど、実際には独立した機能として抽象化できるものではなく、何かの仕組みに付随して生まれる負の側面への対処だと考えているんですね。水元：まさに、そう思います。手塚：たとえば、インフラだったり、パブリッククラウドだったり、そういった仕組みに対して、セキュリティは「べったり横についてくるような存在」で、そこに対して「じゃあ、どう守るか？」というのがセキュリティ対策だと思うんです。そうすると、企業としてセキュリティ担当者を置いた時に、その人が担うべき領域がどんどん広がっていって、気づけば守備範囲がものすごく膨大になっているんですよね。水元：手塚さんが言うように、セキュリティ対策って、たとえばアプリ開発のセキュリティであれば基本的には開発者が担う部分が大きいですし、クラウドやインフラ領域であれば、インフラの管理者が一定担うべきところではあると思うんです。手塚：そうですね。ただ、それぞれが「自分の担当範囲だけ守っていればいいのか」というと、それでは不十分で、結局は全体としてセキュアな状態が保たれていなければセキュリティは担保できないんですよね。水元：だからこそセキュリティ担当者の役割は、各領域の取りこぼしがないように全体をデザインすることだと思うんです。手塚：ある種、「イネーブリングチーム」的な立ち位置ですね。イネーブリングチーム 他のチームの自律性と成功を支援することを目的としたチームである。直接の機能開発や運用を担当するのではなく、知識・スキル・ツールの導入支援、ベストプラクティスの共有などを通じて、他チームが目的を達成できるよう支援する。出典：Matthew Skelton, Manuel Pais 著『Team Topologies（邦訳：チームトポロジー）』https://teamtopologies.com水元：はい、実際にそれに近いと感じます。セキュリティ担当者は開発者やインフラ担当者、それから経営層も含めて、各自がセキュリティにちゃんと向き合えるように支援したり、後押ししたりする存在でもあるべきなのかなと考えています。●ノイズにまみれた通知は「信頼」を失う水元：セキュリティに限らずですが、運用が形骸化してしまうケースも多いと思うんです。定期的に振り返ったり、日々改善するサイクルが回せていればいいのですが、たとえば「脆弱性が出たけれど、そこまで重要じゃないからクローズでいいよね」といった判断がされて、そのまま誰にも修正されずに放置されてしまう...そういうことも珍しくないと思います。手塚：それは本当によく見かけます。そのまま放置されてしまうケースは少なくないですよね。水元：一定の基準に準拠しなければならないケースでは形式的な対応にとどまりやすく、運用が形骸化しやすいと感じています。意識的に振り返ったり改善しようとしない限り、形だけの対応がずっと続いてしまうという状況に陥りやすいんですよね。手塚：僕としてもその課題感にはすごく共感します。一方で、形骸化してしまう理由があるのも事実だと思っています。たとえば、その運用や対応が「そんなに重要じゃない」と思われてしまっていたり、実際に本当に重要じゃなかったりするケースもあると思うんです。そうなると、信頼感が持てなくなってしまう。ここに課題があると考えています。たとえば、セキュリティ製品あるあるなんですが、ノイズが多すぎて本当に大事なことが埋もれてしまうことってありますよね。水元：いわゆる「オオカミ少年アラート」ですね。監視と同じでアラートが多すぎると、結局見なくなってしまうんですよね。●トリアージによって形骸化を防ぐ手塚：SRE的な視点で言うと、ただのメトリクスと SLI が切り分けられていないケースがあると思うんです。たとえば、それが本当に SLO に紐づく SLI なのか、あるいはクリティカルユーザージャーニーに関係しているのか、そのあたりが曖昧なまま運用されてしまっていることが多いと感じています。SLI（Service Level Indicator） 定義：サービスの性能や信頼性を測定する具体的な指標 例：レイテンシ、エラー率、スループット 重要性：ユーザー体験に直接影響を与える要素を数値化し、客観的な評価を可能にするSLO（Service Level Objective） 定義：SLI に基づいて設定される目標値 例：「99.9 %のリクエストが 200 ms以内に応答すること」 重要性：サービスの期待される品質レベルを定義し、チーム間の共通理解を形成する出展：https://sreake.com/blog/sli-slo-good-practices/メトリクス 定義：様々なデータポイントから定期的に集約されたイベントや属性を示す数値の情報 例：「APIレスポンスタイムは、サーバーでのリクエスト受信からレスポンス送信までの時間」 出展：https://sreake.com/blog/sre-monitoring-strategy/#section3-1メトリクスとしては、あること自体には意味があるんですが、それをどう扱うかが重要で、セキュリティで言えば、脆弱性管理におけるトリアージ（優先順位づけ）に近いと考えています。水元：優先順位づけは重要ですよね。優先度をつけることで、ノイズが減り、結果的に信頼される運用に繋がっていくと思います。さらに、その信頼によって、運用が形骸化してしまうことも防ぎやすくなりますよね。●SRE の合理性に学ぶ「やらないことを決める視点」手塚：メトリクスと SLI の切り分けの発想とか、SRE の考え方はセキュリティにも活きると思うんです。「セキュリティ対策＝とにかくやらなくてはいけないもの」という認識になりがちなんですが、「本当に必要なセキュリティ対策は何なのか？」という定義を、オブジェクティブとしてきちんと定めておくことが重要だと思うんです。水元：おっしゃる通りですね。まず目的を明確にすることが不可欠だと思います。判断の土台になる目的がないと、ただ対応に追われるだけの運用になってしまいがちです。手塚：その上で、「何を取らないといけないのか」「本当に見なければならないのは何か」を明確にする必要があります。いろいろなメトリクスがある中でも、「これは確実に見るべき」という重要な指標が、SLI的な観点から存在しているはずなので、そこをきちんと見極めて、運用としてしっかり回していけるかどうかが、要になると感じています。水元：SRE で言う「エラーバジェット」の話にも通じますよね。たとえば「このくらいの時間は止まってもいい」といった許容範囲をあらかじめ定めて、その中で運用していくという考え方です。リスクを正しく把握したうえで「これは優先度が低いから、今はやらない」と明確に判断しているのであれば、それは立派な戦略だと思うんです。意識的に「やらないことを決める」という姿勢は大切ですよね。手塚：SRE の本質って、信頼性をひたすら高めることではなくて「どこまでなら落としてもいいか」の基準を、あらかじめステークホルダー含めて合意しておくことなんですよね。たとえば可用性を 99.99 %にするのと、99.999 %にするのとでは、必要な対応やコストがまったく違う。だからこそ許容される範囲を決めて、その分のリソースを別の価値あるところに回す。それが SRE の合理的な考え方です。セキュリティもまさに同じで、完璧を目指すのは不可能だと思っています。だからこそ、失ってはいけないものを定義し、「何が本当に必要でどこに投資をしないといけないのか」を冷静に見極めていくことが、これからますます大切になると思います。元の記事を読む