# セキュリティの責任分担 ## 定義 セキュリティの責任分担とは、「セキュリティは全員の責任である」という原則のもとで、組織のどの部分が何を担うべきかを切り分ける枠組みである。『Building Secure and Reliable Systems』第20章は、セキュリティと信頼性を専門家だけに委譲すべきではないと明言する——孤立した専門家チームに委ねると、他チームに変更を強制できないまま同じ失敗が繰り返され、専門家チームの仕事はSisyphean(徒労)になるためである。開発者・SRE・セキュリティエンジニア・テストエンジニア・テックリード・マネージャー・エグゼクティブまで、システムのライフサイクル全体に関わる全員が非機能要件としてのセキュリティを担う。 その上で専門家に固有の役割は、(1) 設計レビュー・監査・テストによるコンサルテーション、(2) 暗号やカスタムAAAシステムのような専門知識を要する技術の直接実装、(3) 集中インフラ・組織横断の自動化の構築、(4) ベストプラクティス・ポリシー・教育の整備という4つに限定される。専門家をどこに配置するか(完全な組み込み・完全な中央集権・その中間のハイブリッド)には唯一の正解がなく、組織の目的と文化に依存する。専門家が「越えられない関門(ブロッキングゲート)」になるか「組織を前に進めるイネーブラ」になるかは、この配置と報告系統の設計、および専門家自身が自らの役割を(1)〜(4)に自制できるかにかかっている。(Source: [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 20 Understanding Roles and Responsibilities]] ch.20 §Who Is Responsible for Security and Reliability?, §The Roles of Specialists, §Integrating Security into the Organization) ## 横断的知見 - **本概念(ch.20の「全員責任」原則)は、[[セキュリティエンジニアリングチームの管理と組織的リスク]]concept が集約するSecurity Engineering 3e第27章の議論と、異なる問いを立てている**: 第27章は「良いチームをどう構築・管理するか」(Bezos' law、要件理解の失敗、主任プログラマチーム、多様性)という、既に専門家チームが存在することを前提にした組織的リスク管理・チームビルディング論である。これに対しch.20は「そもそも専門家チームに全てを背負わせるべきか」という一段手前の設計判断を扱い、専門家の役割を4機能に限定したうえで残りをチーム全体に分散させることそのものを処方箋とする。両者は「セキュリティ組織をどう作るか」という共通の関心を、前者はチーム内部の力学として、後者は組織全体への責任の配分として補完的に論じている。(Source: [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 20 Understanding Roles and Responsibilities]] ch.20 §Who Is Responsible for Security and Reliability?, [[@2020__Wiley__Security Engineering 3e - Chapter 27 Secure Systems Development]] ch.27 §27.5.8, §27.6) - **ch.20の「セキュリティチャンピオン」モデルは、[[SREエンゲージメントモデル]]concept が集約するYoshikawaの4区分(引き受ける/一緒にやる/助言する/配る)のうち「Consulting(助言する)」と「Embedded(一緒にやる)」の中間的な役割を、SREとは独立に信頼性・セキュリティ以外の領域(セキュリティ)で組織が自然に発明した実例として読める**: セキュリティチャンピオンは中央セキュリティチームに所属せず各プロダクトチームに配置されるが、コードや設定を直接変更する権限を持つわけではなく、中央チームが策定したポリシー・フレームワーク・インフラの実装を「推進する」役割にとどまる。これは[[SREエンゲージメントモデル]]concept が指摘する「『SREをはじめよう』第13章のスウォームモデルはEmbeddedとConsultingの中間形態」という既存の知見と同型の設計であり、異なる専門ドメイン(SRE対セキュリティ)が独立に同種の中間的配置へ到達したことを示す。(Source: [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 20 Understanding Roles and Responsibilities]] ch.20 §Example - Embedding Security at Google, [[SREエンゲージメントモデル]]) - **ch.20のRed Team/Blue Team/Purple Teamという色分けされた役割区分は、[[机上演習とレッドチーム演習]]concept がBSRS第16章から集約する「侵襲度で段階配置する」枠組みに、演習の一段階としてではなく組織上の恒常的な役割区分としての側面を加える**: 第16章のRed Team演習は机上演習→単一コンポーネント障害注入→…という侵襲度の連続体の最終段階として位置づけられていたが、ch.20はRed Team・Blue Team・Purple Teamを特定の演習イベントではなく、組織内に恒常的に存在しうる役割の呼称として定義し、Blue Teamを「防御側にいる誰でも」と定義することで本概念の「全員責任」原則と直接に接続する。また、Red Teamを脆弱性スキャンチーム・ペネトレーションテストチームと明確に区別する基準(目標指向性・数週間の期間・プロダクト横断的なスコープ)を示しており、第16章が言及しなかった「Red Teamとは何でないか」という境界を補う。(Source: [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 20 Understanding Roles and Responsibilities]] ch.20 §Special Teams - Blue and Red Teams, [[机上演習とレッドチーム演習]]) ## 未解決の問い - セキュリティチャンピオンモデルとSREエンゲージメントモデルの「配る(Infrastructure/Tools)」位置は、ch.20の「集中インフラ・組織横断の自動化の構築」という専門家の第3機能と直接対応するように見えるが、SRE領域の「配る」位置への移行が組織規模の関数であること(既出の17章知見)が、セキュリティ領域のセキュリティチャンピオンモデルにも同様に当てはまるかは、本conceptの現ソース(ch.20のみ)では検証できない。 - ch.20は「専門家がブロッキングゲートになる」失敗パターンを、報告系統の独立性(中央チームをプロダクトエンジニアリングとピアに置く)で防ぐと処方するが、[[セキュリティエンジニアリングチームの管理と組織的リスク]]concept が扱う「良いCISOの平均在任期間は約2年」という短命さの問題は、この報告系統設計と関係があるか未検証。 - 専門家の4機能(コンサルテーション・専門実装・集中インフラ・教育)のうち、どれが「全員責任」原則と最も緊張関係にあるか(たとえば専門実装への依存が強すぎると開発チームの当事者意識を削ぐのではないか)は、ch.20は明示的に論じていない。 ## 関連 - 概念: [[セキュリティエンジニアリングチームの管理と組織的リスク]](専門家チーム内部のリスク管理・チームビルディング) / [[SREエンゲージメントモデル]](異なる専門ドメインでの類似の配置問題) / [[机上演習とレッドチーム演習]](Red Team演習という実践面) - source: [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 20 Understanding Roles and Responsibilities]] — 本概念の一次資料 - 関連章: [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 19 Case Study - Chrome Security Team]](分散型セキュリティチームの詳細な実例) ## 出典 - Heather Adkins, Cyrus Vesuna, Hunter King, Felix Gröbert, and David Challoner, "Understanding Roles and Responsibilities," in Heather Adkins et al. (eds.), *Building Secure and Reliable Systems*, O'Reilly Media, 2020, Chapter 20.