SREはどこまでやるのか？ セキュリティの民主化時代の 運用再設計ライフサイクル

SREの役割は従来、可用性やパフォーマンスの維持にフォーカスされてきました。しかしクラウドネイティブ化やDevOpsの進展により、セキュリティは特定の専門チームだけで完結するものではなくなり、SREもその一端を担うことが求められています。
一方で「どこまでSREがやるべきなのか」という問いに対しては明確な答えがなく、現場では責任の曖昧化や運用負荷の増大といった課題が顕在化しています。すべてをカバーしようとするほど、運用は破綻しやすくなるという現実もあります。

本セッションでは、セキュリティの民主化が進む現代において、SREが担うべき役割を再定義し、「全部やる」のではなく「回る仕組みを設計する」という観点から運用を再設計するアプローチを提示します。

Runtime検知、脆弱性対応、Agentless運用などの実例を交えながら、現場で実際に起きている課題とその解決策を整理し、SREとセキュリティの境界をどのように設計すべきかを具体的に解説します。

最終的には、検知・優先順位付け・自動化・フィードバックのループを中心とした新しい運用ライフサイクルを提示し、持続可能なセキュリティ運用の実現方法を共有します。

Transcript

1. SRE NEXT 2026 / SESSION SREはどこまでやるのか？ セキュリティの民主化時代の 運用再設計ライフサイクル SPEAKER 檜垣 慶太 / Sysdig
2. SRE NEXT 2026 / AGENDA 目次 01 問題提起：SRE / Platform / Security の境界 02 なぜ境界が曖昧になったのか（歴史的背景） 03 認知負荷の限界とセキュリティの民主化 04 Platform Engineering という解法 05 Embedded SRE をセキュリティに適用する 06 運用再設計ライフサイクルと実装 Sysdig Inc. Proprietary Information 2
3. PROBLEM SREの責任はどこまでか？ Security Platform SRE SRE本来の責任 信頼性‧可⽤性（SLO運⽤） + Platform セルフサービス基盤‧ガードレールの整備まで Security 検知‧脆弱性対応まで巻き込まれることも ▸ 責任は同⼼円状に外へ積み上がり続けている。 Sysdig Inc. Proprietary Information 3
4. ◦ SREの責任はどこまでか？ ◦ セキュリティは誰の仕事か？ 01 ◦ 運⽤はなぜ複雑になったのか？ ◦ 今の体制で守れているか？ なぜ境界が曖昧になったのか Sysdig Inc. Proprietary Information ◦ 運⽤をどう再設計すればよいのか？ 4
5. BACKGROUND / HISTORY そもそもの境界：インフラとアプリの分断 ▲ デプロイのたびに摩擦が⽣じ、障害時には責任のなすり合いが常態化 ▸ 分断は組織と評価指標に埋め込まれていた⸺Dev は速度、Ops は安定。 Sysdig Inc. Proprietary Information 5
6. BACKGROUND / HISTORY DevOpsは境界を “文化”で埋めようとした 分断 DevOps誕生 インフラとアプリが別組織‧別指標 ⽂化‧コラボレーションで接着 でも… 具体的な実践⽅法は未定義 • デプロイ摩擦 • 障害時の責任のなすり合い • Dev/Opsが協⼒しよう、という理想 の提唱 ▲ 再現性がない ▲ 規模が⼤きくなると機能不全に ▸ ⽂化は属⼈的⸺再現可能な実践⽅法は定義されなかった。 Sysdig Inc. Proprietary Information 6
7. BACKGROUND / HISTORY google-sre — the one-liner class SRE implements interface DevOps Google は DevOps という理想を、SLI / SLO / エラーバジェットという 定量的なエンジニアリング⼿法として実装した。 Ben Treynor Sloss（Google）の定式化として広く知られる ▸ SRE は DevOps という理想（interface）の実装（class）である。 Sysdig Inc. Proprietary Information 7
8. BACKGROUND / HISTORY セキュリティも同じ課題の連鎖をたどっている 2010s 2015頃 2018→2024 Now 専任セキュリティ時代 シフトレフト提唱 Falco 標準化 検知‧対応の⺠主化 課題：検知〜対応のタイムラグ 課題：ランタイムの当事者が曖昧 CNCF Graduated で検知が仕組み化 SRE / 開発が⼀次対応の当事者に ▸ 検知が仕組みになって初めて、⺠主化は絵空事でなくなる。 Sysdig Inc. Proprietary Information 8
9. BACKGROUND / HISTORY DevOpsとSREの矛盾 ▸ 内側の実践だったはずの SRE が、巨⼤化で外側のチームに切り離されていく。 Sysdig Inc. Proprietary Information 9
10. PROBLEM SREは“何でも屋 ”になっていないか？ ▸ 答えは線引きではなく、認知負荷をどう仕組みに逃がすかという設計の話。 Sysdig Inc. Proprietary Information 10
11. 本編の問い 少し手を挙げてみてください 直近1ヶ⽉で、“これって⾃分の仕事なんだろうか”と思いながら Q1 対応したインシデントがある⽅は？ SRE / Platform / Security の責任分解点が、 Q2 ドキュメントとして書かれているチームの⽅は？ （挙⼿しづらければ、⼼の中でカウントしてみてください） Sysdig Inc. Proprietary Information 11
12. PROBLEM SREが“何でも屋 ”になる4つの構造的理由 01 02 03 04 責任が「結果」で定義される 信頼性を脅かすものは理屈上すべてSREの仕事になる SREは構造的に“最後の受け⽫” ⾏き場のない仕事がデフォルトで落ちてくる 降ってくる⼤半は Extraneous Load 本来集中すべき設計判断の時間と認知資源を奪う “誰がやるか”の議論しかなかった “仕組みに逃がす”という第三の選択肢が存在しなかった ▸ 線引きの問題ではなく、設計の問題。 Sysdig Inc. Proprietary Information 12
13. COGNITIVE LOAD 3つのCognitive Load Intrinsic 学習対象の難解さによる負荷 例：分散システムの障害モード、脆弱性の技術判断 Extraneous 学習に無関係な余分な負荷 例：誤検知アラートの⼀次判定、複数ツールへの往復 Germane 適切な学習のための負荷 例：機能を考える、設計を Design Doc に整理する 出典：⼭⽥⽒『ちがいからみる Platform Engineering』を参考に Sysdig で再構成 ▸ SREの責任範囲論は、認知負荷の配分問題である。 Sysdig Inc. Proprietary Information 13
14. SECURITY DEMOCRATIZATION セキュリティの民主化 従来 ランタイムの異常 セキュリティ専任チーム SRE / 開発 アラートが発⽣ 検知‧トリアージ‧対応を独占 基本関与しない ▲ ⼀次対応まで タイムラグ ⼈がボトルネックになり、対応は営業時間と⼈数に縛られる ⺠主化時代 ランタイムの異常 仕組みが検知‧要約 SRE / 開発が⼀次対応 セキュリティ 同じアラート Falco / Sysdig Platform ガードレール内で⾃⼰解決 設計と例外対応に集中 ▸ 検知と要約は仕組みが担い、⼈は判断に集中する。 Sysdig Inc. Proprietary Information 14
15. SECURITY DEMOCRATIZATION 民主化の理想と、うまくいかない理由 理想 検知‧対応を現場（SRE / 開発）に広げれば、対応は速くなるはず ▲ 現実：そのまま渡すと、4つの理由で失敗する 01 認知負荷が直撃する 02 大半が Extraneous “何でも屋”の SRE に、素のアラートがそのまま乗る 誤検知の⼀次判定とツール往復が時間を奪う 03 04 判断基準がない 何が本当に危険か、現場だけでは決めきれない 丸投げになる 責任分解点が曖昧なまま、名前だけの“⺠主化”に ▸ ⺠主化は“丸投げ”ではない⸺仕組みを介した委譲である。 Sysdig Inc. Proprietary Information 15
16. SECURITY DEMOCRATIZATION なぜ今、認知負荷にセキュリティが乗るのか クラウド攻撃は、 秒単位で進行する。 5秒 検知に許される時間 検知から対応までの速度が問われる時代。⼈⼿前提の分業では、攻撃の速 度に追いつけない。 だからこそ、検知と⼀次対応を仕組みに埋め込む設計が SRE の認知負荷 の上に乗ってくる。 ▸ 秒単位の攻撃には、仕組みによる⼀次対応が前提になる。 Sysdig Inc. Proprietary Information 16
17. • SREの責任はどこまでか？ • セキュリティは誰の仕事か？ • 運⽤はなぜ複雑になったのか？ ◦ 今の体制で守れているか？ ◦ 運⽤をどう再設計すればよいのか？ 02 Platform Engineering という解法 Sysdig Inc. Proprietary Information 17
18. PLATFORM ENGINEERING Platform Engineering とは 開発者が⾃⼰解決できる“内部プラットフォーム”を、 プロダクトとして設計‧運⽤するアプローチ。 ⽬的は、認知負荷を下げ、速度と信頼性を両⽴させること。 ゴールデンパス 推奨構成を“舗装された道”として提供する セルフサービス 申請‧依頼を待たずに開発者⾃⾝で完結できる ガードレール 安全に使える範囲をあらかじめ仕組みで担保する Platform as a Product 開発者をユーザーとして扱い、改善し続ける 2026年までに、ソフトウェアエンジニアリング組織の 80% がプラットフォームチームを設置する 出典：Gartner（2022年予測） ▸ ⼈を増やすのではなく、仕組みで受けるための⽅法論。 Sysdig Inc. Proprietary Information 18
19. PLATFORM ENGINEERING 責任共有モデルと責任分解点 Application ビジネスロジック‧ランタイム設定 責任分解点 Platform ゴールデンパス‧ガードレール‧検知の要約 責任分解点 Cloud / Sysdig マネージドサービス‧ランタイムシグナルの責任範囲 出典：下川⽒『Platform Engineering on Serverless』の責任共有モデルを参考に Sysdig で再構成 ▸ 責任分解点を明⽰すれば、セキュリティも同じ設計原則で扱える。 Sysdig Inc. Proprietary Information 19
20. PLATFORM ENGINEERING X-as-a-Service：セルフサービス化 プラットフォーム API アプリ/SREチーム Sysdig / Falco セキュリティチーム セルフサービスでリクエスト ランタイム検知を⾃動適⽤ 検知結果を要約して返却 ガードレール内で⾃⼰解決 局所対応が必要な場合のみエスカレーション ▸ ⼈が出るのは局所対応だけ⸺残りはプラットフォームが受ける。 Sysdig Inc. Proprietary Information 20
21. PLATFORM ENGINEERING 最小限のプラットフォームから始める 01 最小限 Platform 02 計測 03 横展開 既存 OSS / AWS を活⽤し、最⼩構成 SPACE‧DORA 指標で認知負荷の変化を計測 効果を確認できたら社内で周知し、他チーム （Thinnest Viable Platform）から始める し、フィードバックを得る へ横展開する ▸ Thinnest Viable Platform から始めて、計測しながら広げる。 Sysdig Inc. Proprietary Information 21
22. PLATFORM ENGINEERING Embedded SRE と Platform Engineering の違い 低減する認知負荷 責任範囲 指標 コミュニケーション Embedded SRE Platform Engineering Intrinsic Intrinsic + Extraneous サービスの信頼性‧稼働率 認知負荷を下げるプロダクト運⽤ SLI / SLO SPACE, DORA Collaboration X as a Service 出典：⼭⽥⽒『ちがいからみる Platform Engineering』の⽐較表を参考に Sysdig で再構成 ▸ この軸を、そのままセキュリティに当てはめる。 Sysdig Inc. Proprietary Information 22
23. EMBEDDED SECURITY 同じ構造をセキュリティに適用する 低減する認知負荷 責任範囲 指標 コミュニケーション Embedded Security Security as a Platform Intrinsic（局所的な脅威判断） Intrinsic + Extraneous（検知〜要約全体） 特定サービスの脅威対応 ランタイム検知の仕組み化‧運⽤ MTTD / MTTR 検知の再現率‧⾃動対応率 ローテーションでの協働 Sysdig / Falco as a Service ▸ Embedded（⼈）と as a Service（仕組み）⸺両⽅が必要。 Sysdig Inc. Proprietary Information 23
24. • SREの責任はどこまでか？ • セキュリティは誰の仕事か？ • 運⽤はなぜ複雑になったのか？ • 今の体制で守れているか？ ◦ 運⽤をどう再設計すればよいのか？ 03 運用再設計ライフサイクルと実装 Sysdig Inc. Proprietary Information 24
25. REDESIGN LIFECYCLE 検知→トリアージ →対応→学習を仕組みに埋め込む ▸ ループのどこを仕組みに、どこを⼈に置くか⸺それが設計の核⼼。 Sysdig Inc. Proprietary Information 25
26. REDESIGN LIFECYCLE 表紙の問いに戻る Sysdig Inc. Proprietary Information 26
27. IMPLEMENTATION 実装：検知パイプラインの責任分解 Workload Falco Sysdig Platform SRE / 開発 コンテナ / ホスト ランタイム検知 要約‧優先度付け ⼀次対応 ▸ 責任の受け渡しを、ツール任せではなく設計として定義する。 Sysdig Inc. Proprietary Information 27
28. T-850 vs. T-X Rise of the Machines — AI と Agentic AI は何が違うのか ⾃律性 完全⾃律。ただし⽬的は最初 に与えられたまま固定 > 完全⾃律＋状況に応じて計 画そのものを再設計 意思決定 ⽬の前の脅威を評価し、定型 パターンで対応 > 戦う‧退く‧ハックするを リアルタイムに戦略判断 適応⼒ AI Sysdig Inc. Proprietary Information ⼈間の⾏動を簡易学習、基本 的なソーシャルキュー > ⾼度な模倣、環境や他シス テムまで乗っ取る Agentic AI 28
29. IMPLEMENTATION デモ：検知から一次対応まで Falco Sysdig Platform SRE 異常なランタイムイベントを検知 関連イベントを集約‧要約 優先度付きで通知 承認 / ロールバックを指⽰ ▸ ⼈が判断し、機械が実⾏する。逆ではない。 Sysdig Inc. Proprietary Information 29
30. TO-BE SRE・セキュリティ運用の将来像 2026 2027 2028 Beyond 検知の仕組み化 セルフサービス化 Germane Load に集中 “設計者”へ Falco/Sysdig の要約が標準運⽤に ガードレール内で開発者が⾃⼰解決 SRE は信頼性の設計判断に専念 認知負荷を配分する設計者になる ※ 仕組みに“奪わせる”のは Extraneous だけです ▸ “何でも屋”から、“認知負荷を配分する設計者”へ。 Sysdig Inc. Proprietary Information 30
31. CALL TO ACTION まずこの 3つだけ、今週やってみてください 01 棚出し 直近のオンコール対応を Intrinsic / Extraneous / Germane に分類してみる ▸ どこに Extraneous（余計な負荷）が溜まっているかが⾒える化される 01 棚出し 02 境界を書く 03 ⼀点突破 ▸ 線引きを議論するのではなく、⼩さく設計してみる。 Sysdig Inc. Proprietary Information 31
32. CALL TO ACTION まずこの 3つだけ、今週やってみてください 02 境界を書く SRE / Platform / Security の責任分解点を1枚のドキュメントにする ▸ 境界が“感覚”から“ドキュメント”になる（Q2 で挙がらなかったやつ） 01 棚出し 02 境界を書く 03 ⼀点突破 ▸ 線引きを議論するのではなく、⼩さく設計してみる。 Sysdig Inc. Proprietary Information 32
33. CALL TO ACTION まずこの 3つだけ、今週やってみてください 03 一点突破 ⼀番 Extraneous が⾼いタスクを1つ選び、⾃動化‧セルフサービス化を試す ▸ ⼩さく設計して仕組みに逃がす感覚を、チームで掴む 01 棚出し 02 境界を書く 03 ⼀点突破 ▸ 線引きを議論するのではなく、⼩さく設計してみる。 Sysdig Inc. Proprietary Information 33
34. 「どこまで」ではなく 「どう仕組みに逃がすか」 SREを“何でも屋”にしないために、認知負荷をどの仕組みに配分するかを設計する。 ※ こうならないための、“設計”です。 Sysdig Inc. Proprietary Information 34
35. REFERENCES 出典・参考資料 下川 健介⽒『Platform Engineering on Serverless』（Platform Engineering Kaigi 2024, Amazon Web Services Japan） 責任共有モデル、X-as-a-Service、最⼩限のプラットフォームから始める、の各図を参考に Sysdig ブランドで再構成 Sysdig Inc. Proprietary Information 35