はじめに
DevOpsを回している現場で、セキュリティが「リリース直前に立ちはだかる関門」になっていないでしょうか。
CI/CDによって1日に何度もデプロイできる状態を作り上げた一方で、セキュリティレビューだけが数週間単位のバッチ処理として残っている。結果として、セキュリティチームは「止める人」になり、開発・運用チームは「回避する人」になってしまう。これは多くの組織が通る道だと思います。
本書『Securing DevOps』は、この構造的な断絶に対して「継続的セキュリティ（Continuous Security）」という設計思想を提示します。著者はMozillaでFirefoxの運用セキュリティチームを率いていたJulien Vehent氏で、数百万人規模のユーザーを抱えるWebサービスを守ってきた実務経験がベースになっています。
本記事では、本書の全体構造と、設計・アーキテクチャの観点から特に示唆に富む部分を整理してお伝えします。
書籍情報
| 項目 | 内容 |
|---|---|
| 原題 | Securing DevOps: Security in the Cloud |
| 邦題 | Securing DevOps（クラウドにおけるセキュリティ） |
| 著者 | Julien Vehent |
| 出版 | Manning Publications |
| 構成 | 全13章／3パート |
| 想定読者 | DevOpsエンジニア、SRE、セキュリティエンジニア |
本書は「サム」という架空のDevOpsエンジニアを主人公に据えて書かれています。彼女は医療費請求プラットフォームを運営する小規模スタートアップに入社したばかりで、開発者がGitHubからDockerコンテナへ1日3回デプロイするような環境で、高リスクな医療データを守らなければなりません。専任のセキュリティチームがいない組織を前提にしている点が、本書を実務的にしています。
本書の中心概念：継続的セキュリティ
本書の骨格は、継続的セキュリティを構成する3つのフェーズです。この3つが、そのまま本書の3パートに対応しています。
┌─────────────────────────────────────────────┐
│ Phase 1: テスト駆動型セキュリティ（TDS） │ ← Part 1（2〜6章）
│ → セキュリティ制御を定義し、CI/CDでテストする │
├─────────────────────────────────────────────┤
│ Phase 2: 攻撃の監視と対応 │ ← Part 2（7〜10章）
│ → ログ、侵入検知、インシデントレスポンス │
├─────────────────────────────────────────────┤
│ Phase 3: リスク評価とセキュリティの成熟 │ ← Part 3（11〜13章）
│ → リスク管理、セキュリティテスト、3年計画 │
└─────────────────────────────────────────────┘
重要なのは、この3フェーズがフィードバックループを形成している点です。テストで守り、監視で気づき、評価で優先順位を見直し、またテストに戻る。単発の施策の羅列ではなく、循環する仕組みとして設計されています。
目標の不一致という出発点
第1章で印象的なのは、技術論に入る前に「目標の不一致」を問題として名指ししているところです。
- プロダクトマネージャーはエンゲージメントとリテンションを測る
- 開発者は使いやすさを測る
- 運用者は稼働時間とレスポンスタイムを測る
- セキュリティチームは、コンプライアンス準拠率やインシデント件数を測る
前者3つは顧客を向いていますが、セキュリティだけが自組織の内側を向いている。この視線のズレがコミュニケーションを壊す、というのが著者の診断です。
DevOpsが開発と運用の壁を壊したのと同じことを、セキュリティにも適用する。セキュリティを製品の外側から被せるのではなく、製品の機能として内側に実装する。この発想の転換が本書全体を貫いています。
Part 1：テスト駆動型セキュリティ（第2〜6章）
TDSという考え方
TDD（テスト駆動開発）が「まずテストを書き、次にそれを通すコードを書く」であるように、TDS（Test-Driven Security）は「まず期待するセキュリティ状態をテストとして書き、次にそれを通す制御を実装する」というアプローチです。
このアプローチの効用は、単に自動化されるという以上のものがあります。
- 要件が明文化される — テストを書くには、期待を具体的に言語化しなければなりません
- 粒度が強制される — 「通信を暗号化する」ではテストできません。「全トラフィックにHTTPSを適用し、暗号スイートはX/Y/Zに限定する」まで落とし込む必要があります
- 再利用性が高い — 多くのサービスが同じ基盤を共有するため、ベースラインテストは横展開できます
- デプロイ前に検出される — 顧客に影響が出る前に修正の機会があります
「ネットワーク通信を暗号化する」という曖昧な要件を避けよ、というのは設計をやる人間にとって非常に共感できる指摘でした。テスト可能性を要求することが、要件定義の質を強制的に引き上げるわけです。
ベースラインの例
本書が挙げるベースライン制御は、驚くほど地味です。
- 全システムでSSHのrootログインを無効化する
- リリースから30日以内に最新バージョンへパッチを適用する
- WebアプリケーションはHTTPSのみを使用する（HTTP不可）
- 認証情報をアプリケーションコードと同居させず、専用のVaultで管理する
- 管理インターフェースはVPN配下に置く
映画に出てくるような高度な攻撃ではなく、攻撃者は常に「容易な標的」を狙う、というのが前提です。脆弱なWebフレームワーク、古いシステム、推測可能なパスワードで公開された管理画面、リポジトリに漏洩した認証情報。これらを潰すことが最も費用対効果が高い、という現実的な立場を取っています。
セキュリティレイヤーの4層構造
Part 1では、AWS上に意図的に「安全でない」パイプラインを構築し、そこに4つのレイヤーを重ねていきます。
| 章 | レイヤー | 主な内容 |
|---|---|---|
| 3章 | Webアプリケーション | OWASP Top 10への対応、認証管理、依存関係の更新 |
| 4章 | クラウドインフラ | デプロイ時のセキュリティテスト、ネットワークアクセス制限、DB保護 |
| 5章 | 通信 | TLSの正しい実装、暗号スイートの選定 |
| 6章 | デリバリーパイプライン | GitHub/Docker Hub/AWSのアクセス制御、コミット・コンテナ署名、シークレット配布 |
第6章のパイプライン保護は特に現代的な論点です。CI/CDパイプラインが侵害されれば、攻撃者は本番で動くソフトウェアそのものを掌握できます。ソースコードとコンテナに整合性制御（署名）を加え、パイプライン自体に信頼の連鎖を作るという発想は、サプライチェーン攻撃が主要な脅威となった今、むしろ当時より重要度が上がっています。
第2章では、まず「安全でないパイプライン」を構築します。改善点を明示してから章を追って潰していく構成なので、写経しながら読むと理解が定着しやすい作りです。
Part 2：攻撃の監視と対応（第7〜10章）
「いずれ必ず侵入される」という前提
Part 2は、著者が2000年代半ばに行っていた実験の話から始まります。パッチを当てていないWindows XPをファイアウォールなしでインターネットに直結し、侵害されるまでの時間を計測する、というものです。
結論は明快で、インターネットに接続されたシステムは例外なく攻撃を受ける。だから防御だけでなく、検知と対応の能力が必要になります。
ロギングパイプラインの5層設計
第7章のロギングパイプラインは、本書の中でも設計として汎用性が高い部分です。
[収集レイヤー] 各コンポーネントからログイベントを生成・収集
↓
[ストリーミングレイヤー] イベントをキャプチャしてルーティング
↓
[分析レイヤー] 内容を検査し、異常を検出してアラートを発報
↓
[ストレージレイヤー] アーカイブ
↓
[アクセスレイヤー] 開発者・運用者がログを参照
このパイプラインが強力なのは、異常検知を実行できる単一のトンネルを提供するからです。各コンポーネントに個別の検知ロジックを持たせるより、モデルとしてはるかにシンプルになります。
一方で著者は、すべてのログを収集・分析することは現実的でないとも明言しています。データ量的に保存が非現実的だからです。何を残し、何を捨てるかの選択こそが設計であり、DevOpsパイプラインの特定の部分に重点を置く、という割り切りが示されます。
侵入検知：攻撃者の4ステップ
第9章では、侵入がたどる典型的な流れを4段階に整理しています。
- ペイロードの投下 — 目立たない程度に小さいバックドアやマルウェアを標的サーバへ設置する
- C2チャネルの確立 — 外向きの通信で指令サーバと接続する（IRC、HTML本文への埋め込み、DNSのTXTレコードなど）
- 横展開 — ネットワーク内をスキャンし、価値あるターゲットへ移動する
- データの持ち出し — C2と並行するチャネルで情報を外部へ送出する
この各ステップに対して、3種類の監視手段が対置されます。
| 手段 | 対象 | 特徴 |
|---|---|---|
| IDS（侵入検知システム） | ネットワークトラフィック | ギガバイト級のトラフィックをリアルタイム検査。C2の検出に有効 |
| 接続監査（NetFlow） | ネットワーク接続の記録 | 低レベルアクセスが得られないIaaS環境での代替手段 |
| システム監査（auditd） | システムコール | ホスト内部の挙動を追跡。攻撃者が踏みやすい |
IaaS環境では、オンプレのように全トラフィックをミラーリングできないケースが多いため、NetFlowによる接続監査を代替として位置づけている点が実践的でした。
インシデント対応の6フェーズ
第10章はケーススタディ形式で、架空の組織で起きた侵害への対応を追体験する構成です。プレイブックは6つのフェーズで構成されます。
準備 → 特定 → 封じ込め → 根絶 → 復旧 → 教訓
このフレームワーク自体はNISTなどでも見慣れたものですが、本書の価値は「DevOpsの道具立てをどう活かすか」を具体的な物語の中で示している点にあります。Infrastructure as Codeで環境を再構築できることが、根絶と復旧のフェーズでどれほど効くか。ここは通常のインシデント対応文献とは違う読み味があります。
Part 3：リスク評価とセキュリティの成熟（第11〜13章）
個人的に、本書で最も価値があると感じたのはこのパートです。
なぜリスク管理が必要になるのか
Part 1では、たった1つの請求書サービスを守るために10章近くを費やしました。しかし組織は成長します。パイプラインは増え、サービスは増え、インシデントも増える。すべてに同じ密度の対策を打つことは不可能です。
リスク管理とは、限られた予算と人員を「最も重要な問題」に割り当てるためのツールである、というのが著者の定義です。
CIAトライアドと「4段階ルール」
情報セキュリティの基本モデルであるCIAトライアド（機密性・完全性・可用性）が改めて解説されますが、興味深いのは分類レベルを必ず4段階（偶数）にするという主張です。
理由は認知バイアスです。選択肢が奇数だと、人は中央を選びがちである（センターステージ効果）。4段階にすることでレベル2とレベル3のどちらかを選ばざるを得なくなり、各レベルの意味を意識的に考えるようになります。
Mozillaでの機密性レベルの例：
| レベル | 名称 | 対象 |
|---|---|---|
| 1 | 公開 | 世界と共有できるデータ |
| 2 | スタッフ機密 | 組織内全員と共有できるデータ |
| 3 | ワークグループ機密 | 特定チームのみが扱えるデータ |
| 4 | 特定個人のみ | データ所有者が許可した個人のみ |
「フレームワークに数学を注ぎ込もうとすればするほど使いにくくなる」という一文もあり、精緻さより運用可能性を優先する姿勢が一貫しています。
影響の3領域
リスクの影響は、財務・評判・生産性の3領域で測定します。
財務 — 最も定量化しやすい領域です。損失額でレベルを切ります（10万ドル未満=低、100万ドルまで=中、1000万ドルまで=高、それ以上=最大、など）。
評判 — 定量化が難しいため、「どこまで報道されるか」を代理指標にします。SNSでの個別の苦情なら中、専門メディアが取り上げるなら高、全国紙・テレビなら最大、といった具合です。
生産性 — 「停止する期間」×「影響を受けるグループの規模」で測ります。全従業員の10%未満を小規模グループ、それ以上を大規模グループと定義し、小規模が1日／大規模が数分なら低、といったマトリクスを作ります。
著者は「すべてを財務リスクとして分類したくなるが、それではリスクの緩和方法についての議論が痩せる」と警告しています。バッテリー爆発は評判リスク、工場の安全問題は生産性リスク。第一段階を正しく特定することが、対策の選択肢を広げます。
STRIDEとDREAD
脅威モデリングにはSTRIDE、脆弱性の測定にはDREADを使います。
STRIDE（脅威の分類）
| 頭文字 | 脅威 |
|---|---|
| S | なりすまし（Spoofing） |
| T | 改ざん（Tampering） |
| R | 否認（Repudiation） |
| I | 情報漏洩（Information disclosure） |
| D | サービス拒否（Denial of service） |
| E | 権限昇格（Elevation of privilege） |
DREAD（脆弱性の定量化） — 被害の可能性／再現性／悪用可能性／影響を受けるユーザー／発見可能性を各1〜10で採点し、平均を取ります。
リスクは R = 脅威 × 脆弱性 × 影響 として定義されます。ただし著者自身が「これらのモデルはどれも完璧ではない」とコラムで断っており、厳密な数式ではなく議論を促進する道具として位置づけている点は誠実だと感じました。
RRA（迅速なリスク評価）
Part 3の白眉は、Mozillaが実際に運用しているRRA（Rapid Risk Assessment）フレームワークです。
従来型のリスク評価（FMECAなど）は数週間かかり、完了する頃にはソフトウェアが何バージョンも進んでいる。DevOpsの速度では機能しません。そこでRRAは、1プロジェクトあたり30分〜1時間で完了するよう設計されています。
RRAは4つの構成要素からなります。
1. 情報収集
サービス名、説明、対象ユーザー、そしてサービスオーナーを記録します。オーナーはセキュリティの最終責任者であり、リスクをどう扱うかを決める唯一の人物です。副次的な効果として、インシデント発生時に「このサービスの責任者は誰か」を即座に特定できるようになります。
2. データディクショナリの構築
サービスが扱う情報を洗い出し、機密性レベルを付与します。請求書サービスの例では、顧客請求書=特定個人のみ、DB認証情報=ワークグループ機密、総収益=スタッフ機密、ソースコード=公開、といった具合です。
3. リスクの特定と測定
機密性・完全性・可用性の3軸 × 評判・生産性・財務の3領域 = 9つのマスを埋めます。ここに20分以上かかる場合は、評価対象のスコープが広すぎるサインだ、という判断基準まで示されています。
4. 推奨事項の作成
特定されたリスクの緩和策を優先順位付きでまとめます。理想は「エンジニアリングチームが評価の過程で自らギャップに気づき、既に解決策を議論している」状態であり、その場合セキュリティチームは推奨事項を書く必要すらありません。
RRAの実施例で示される結論も示唆的です。請求書サービスにおいて最大のリスクは「機密性」ではなく「完全性」でした。請求書が誰にも気づかれずに改ざんされれば、請求の信頼性が失われ、キャッシュフローが枯渇して組織が崩壊しうる。
セキュリティ担当者は機密性を何よりも優先する傾向がある
という著者の自己批判は、耳が痛い指摘だと思います。この演習を行わなければ、本当に組織を危険にさらす問題ではなく、優先度の低い問題の修正に資源を注いでしまう。
リスクの受け入れ・拒否・委任
すべての推奨事項を実装できることは稀です。サービスオーナーは3つの選択肢を持ちます。
- 受け入れる — 緩和作業は行わず、結果を組織を代表して引き受ける。課題管理システムに文書化する
- 拒否する — 許容レベルまで低減する対策を実施する
- 委任する — 第三者に運用を委ね、リスクごと移転する
そして、リスク記録は課題追跡システム（JIRA、GitHub Issues等）に紐づけることが強調されます。多くのリスク管理が失敗するのは、リスク追跡が組織の日常のトリアージ作業と切り離されているからだ、という分析です。製品の新機能と同じ枠組みで管理し、エンジニアがロードマップ内で緩和作業を追える状態にする。ここは実装より運用設計の話であり、非常に納得感がありました。
セキュリティテストと3年計画
第12章では、社内テスト（脆弱性スキャン、ファジング、静的コード解析、構成監査）、外部監査・レッドチーム、バグバウンティの3方向が整理されます。特に社内テストはCI/CDへ統合し、SDLCの一部にすることが前提とされています。
第13章は、継続的セキュリティを組織に定着させるための3年モデルで締めくくられます。成熟には年単位の時間がかかるという前提に立ち、段階的な計画として示されている点が現実的です。
設計・アーキテクチャの観点から
本書を読み終えて、設計者として持ち帰りたいと感じた原則を挙げます。
1. テスト可能性が要件の質を決める
セキュリティ要件をテストとして書けるところまで具体化する。これは非機能要件全般に適用できる規律です。「可用性を高める」ではなく「9をいくつ並べるか」を決めるのと同じ構造です。
2. 制御は製品の内側に実装する
アプリケーションの外側にセキュリティを構築すると、制御がアプリの実際の挙動を認識できず見落としが生まれる。さらにチーム間に不信の文化を作る。著者は「エンジニアリングチームが所有していないセキュリティ戦略は長続きせず、時間とともに劣化する」と述べています。所有権の委譲までを設計に含める、という視点です。
3. 単一のトンネルに集約する
ロギングパイプラインの設計思想は、横断的関心事の扱い方の一般解でもあります。各コンポーネントに検知ロジックを分散させるのではなく、単一の経路に集めて一箇所で判断する。
4. 情報を中心に据える
「CPUを盗まれることは情報の窃取ではないのでは」という疑問に対し、著者は明確に否定します。インフラのあらゆるコンポーネントは情報を扱うために設計されており、DoSは情報へのアクセスを遮断し、乗っ取られたサーバは処理した情報の完全性保証を失う。資産の棚卸しを機器ではなく情報から始める、という発想の転換です。
5. 軽量な評価を高頻度で回す
3週間かけて完璧な評価を1回やるより、1時間の評価を全プロジェクトで回す。DevOpsの思想をそのままリスク管理に持ち込んだ形であり、本書で最も再現性の高い提案だと思います。
読むうえでの注意点
本書は執筆から時間が経っているため、以下は補足しながら読む必要があります。
- AWSのサービス構成 — 具体的なコンソール操作やサービス名は現行と異なる部分があります。概念は有効ですが、手順はそのまま再現できません
- コンテナ環境の前提 — Kubernetesがこれほど支配的になる前の記述であり、コンテナのセキュリティは別途補完が必要です
- サプライチェーン — 第6章の署名・整合性の議論は先見的ですが、SLSAやSBOMといった現在の枠組みは登場しません
- OWASP Top 10 — 参照されているバージョンは最新版と異なります
逆に言えば、これらは「ツールの層」の話であり、継続的セキュリティという設計思想、TDSの規律、RRAの運用設計は、そのまま現在の現場に適用できます。むしろ道具が変わっても残る部分だけを抽出して読むと、価値が際立つタイプの本です。
まとめ
『Securing DevOps』は、セキュリティを「後から被せる制約」から「製品に組み込まれた機能」へと転換するための実践書です。
- Part 1 は、CI/CDにセキュリティテストを織り込むTDSの実装
- Part 2 は、ロギングパイプラインと侵入検知による監視と対応
- Part 3 は、RRAによる軽量なリスク評価と、組織の成熟プロセス
技術書としては第7章のロギングパイプライン設計、組織論としては第11章のRRAが特に読み応えがあります。とりわけRRAは、明日から自分のチームで試せる粒度まで具体化されており、この章だけでも読む価値があると感じました。
セキュリティ専任者がいない組織で、それでも安全にサービスを運営したい。そういう立場のエンジニアにとって、本書は現実的な出発点を与えてくれるはずです。
参考
- Julien Vehent, Securing DevOps: Security in the Cloud, Manning Publications
- サンプルコード: https://securing-devops.com/code
- OWASP Top 10: https://owasp.org/www-project-top-ten/
- Mozilla Rapid Risk Assessment: https://infosec.mozilla.org/guidelines/risk/rapid_risk_assessment