はじめに
本書はGoogleのSREチームが著した、セキュリティと信頼性を統合的に扱う一冊です。
タイトルに「設計・実装・保守」と書かれているとおり、ソフトウェアライフサイクルのあらゆるフェーズを網羅した構成になっています。「セキュリティはセキュリティ専任チームがやるもの」という認識を崩し、全エンジニアが当事者であると繰り返し主張している点が本書の骨格です。
邦題：セキュアで信頼性のあるシステム構築 ― Google SREが考える安全なシステムの設計、実装、保守（オライリー・ジャパン）
原題：Building Secure and Reliable Systems（O'Reilly）
本書の構成
全5部・22章で、以下のように整理されています。
| 部 | テーマ | 章 |
|---|---|---|
| 第Ⅰ部 | 入門資料 | 1〜2章 |
| 第Ⅱ部 | システムの設計 | 3〜10章 |
| 第Ⅲ部 | システムの実装 | 11〜15章 |
| 第Ⅳ部 | システムの維持 | 16〜18章 |
| 第Ⅴ部 | 組織と文化 | 19〜21章 |
第Ⅰ部 入門資料
1章 セキュリティと信頼性が交わるところ
本書の主張を一言で表すなら「セキュリティと信頼性は別物ではない」です。
冒頭のエピソードが秀逸で、GoogleのWi-Fiパスワード変更告知メールを起点に社内パスワードマネージャーが連鎖障害を起こし、最終的に電動ドリルで金庫をこじ開けるまでサービスが復旧しなかった顛末が語られます。信頼性の問題（ロードバランシング不足）がセキュリティ対策（HSM・スマートカード要件）によってリカバリを難しくした、という複合例です。
セキュリティと信頼性はどちらも CIAトライアド（機密性・完全性・可用性）を軸にしており、視点の違いは「悪意ある攻撃者を想定するか否か」だけです。本章では両者に共通する設計上の特性も整理されています。
- 不可視性：うまく機能しているときほど目に見えない
- 単純さ：シンプルな設計はアタックサーフェスを狭め、障害時の理解を助ける
- 弾力性：多層防御と独立した障害ドメインで「爆風半径（blast radius）」を制限する
- 進化：無害に見える小さな変更が大きな障害を引き起こしうる
2章 攻撃者に対する理解
攻撃者を「外部の悪意ある第三者」に限定せず、インサイダーリスクも含めて体系的に整理しています。動機・能力・手口を理解することが、適切な脅威モデリングの前提であると説いています。
第Ⅱ部 システムの設計
3章 ケーススタディ：セーフプロキシ
既存システムに手を入れず、プロキシを挟むことでセキュリティ・信頼性の要件を後付けした事例です。「理想はゼロから組み込むことだが、現実は既存システムへの追加がほとんど」という認識のもと、段階的なアプローチを示しています。
4章 設計上のトレードオフとインセンティブ
機能要件と非機能要件は必ずしも相反しないという立場を取り、「速度のためにセキュリティを犠牲にする」という自然な傾向を批判的に検討しています。技術的負債として先送りにするコストが後になっていかに高くつくかが、具体例とともに示されます。
5章 アイデンティティ、認可、アクセス制御の設計
最小権限の原則とマルチパーティ認可が本章の柱です。どちらも新しい概念ではありませんが、Google規模での実装例を交えながら重要性を改めて整理しています。sudo のようなきめ細かな権限制御や、地理的スコープを持つクレデンシャルの設計が取り上げられています。
6章 システムの理解とメンタルモデル
不変条件とメンタルモデルを通じてシステムを分析・理解する手法を説明しています。アタックサーフェスを最小化するには、独立して推論できる小さく単純なサブシステムに責任を分離することが重要だと述べています。
7章 変化に適応するためのシステム設計
短期・中期・長期の変更に対応するためのプラクティスを示しています。「複雑さは不用意に蓄積される」という認識のもと、著名な障害事例で危険性を具体化しています。
事例1：OpenSSL脆弱性
2行の削除が乱数生成器のシード値をプロセスIDのみに縮小させ、約2年後に発見されるまで総当たり攻撃に対して脆弱な状態になっていました。
事例2：YouTubeダウン（2018年）
ロギング粒度の改善を目的とした「無害に見える変更」が、プロダクション環境でのメモリ不足からカスケード障害を引き起こし、全世界で1時間以上のダウンにつながりました。
8章 弾力性を担保する設計
弾力性（Resilience）を「深刻な機能不全や中断に耐える能力」と定義し、品質低下モードでもサービスを維持し続けるための戦略を示しています。多層防御（defense in depth）と独立した障害ドメインの組み合わせが基本的な処方箋です。
9章 リカバリを想定した設計
障害後の修復を前提にした設計思想を扱います。「リカバリできるように設計する」という姿勢は、テスト戦略やデプロイ戦略とも密接に関連しており、後続章への橋渡しになっています。
10章 サービス拒否攻撃の緩和
DoS/DDoS攻撃はセキュリティと信頼性の両方にまたがる領域です。意図的な攻撃と正規トラフィックのスパイクは「被害者からは区別がつかない」という前提のもと、サービススタックの各レイヤーでの緩和策を解説しています。
第Ⅲ部 システムの実装
11章 ケーススタディ：パブリックに信頼できるCAの設計・実装・維持
GoogleがパブリックCAを社内で構築・運用するに至った経緯と、そこで直面したセキュリティ要件を詳細に説明しています。「既製品ではなくカスタムを選ぶ判断」の思考プロセスが参考になります。
12章 コードの記述
フレームワークを活用してシステムをシンプルに保つことの重要性を改めて主張しています。安全性・信頼性に関わる多くの考慮事項を同時に念頭に置くのは難しいため、共通フレームワークとライブラリで「問題のクラスごと」に対処する戦略が示されます。
13章 コードのテスト
負荷テスト・ファジング・静的解析などを組み合わせたテスト戦略を解説しています。「実際に構築したシステムが設計意図と合致しているという確信を得る」ためにテストが存在するという観点は、セキュリティ目線が加わることで通常のQAとはやや異なる位置づけになります。
14章 コードのデプロイ
カナリアリリースやスローロールアウトなど、デプロイ手法そのものがセキュリティリスクを制限できるという視点を示しています。適切にレビューされたコードのみを受け付けるデプロイシステムにより、悪意のあるバイナリのプッシュリスクを軽減できると述べています。
15章 システムの調査
デバッグ用アクセス許可とログのセキュリティ要件（PII不含など）のバランスをどう取るかを扱います。ログは完全かつ詳細であるほど優れているが、量が多大なコストをもたらし、ログ自体が攻撃者の標的になる、という緊張関係が整理されています。
第Ⅳ部 システムの維持
16章 インシデント対応の準備
インシデント対応チームの設置、事前準備、計画のテストを扱います。Googleがサンフランシスコ大地震を想定して対応計画を作成した事例が取り上げられています。
17章 危機管理
Googleの IMAG（Incident Management at Google） プログラムが詳しく解説されます。米国政府のICS（インシデントコマンドシステム）をモデルにした対応体制で、「知らないサービスアカウントがクラウドプロジェクトに追加されていた」というリアルな発見事例を軸に展開します。
18章 リカバリとその後
大規模フィッシング攻撃などへの対処を例に、「攻撃者の排除・現在の被害の緩和・長期的な変更実施」の三者間のトレードオフを検討しています。リカバリ中の監査証跡を残すことの重要性も強調されています。
第Ⅴ部 組織と文化
19章 ケーススタディ：Chromeのセキュリティチーム
Googleで最初に専任セキュリティチームを設置したプロダクトであるChromeの事例です。「セキュリティはプロダクトの中核をなす原則」という立場がChromeの設計全体に貫かれており、チームがどう組成・運営されてきたかを解説しています。
20章 役割と責任の理解
「誰がセキュリティと信頼性に責任を持つのか」という問いに対して、本書は明確に**「全員」**と答えます。セキュリティ専門家の役割は専門技術を実装しベストプラクティスを考案することであり、実行責任を引き受けることではないという整理がなされています。
21章 セキュリティと信頼性の文化の構築
健全なシステムは技術とプロセスだけでは成り立たず、文化の設計原則も必要だという主張で締めくくられます。組織全体がセキュリティと信頼性に投資していなければ、エンジニアリングの実践は効果を発揮しないとしています。
総評
| 観点 | 評価 |
|---|---|
| 読者層 | 設計フェーズから関わるエンジニア全般、SRE、EMに特にフィット |
| 強み | セキュリティと信頼性を統合する視点の一貫性、Google規模の実践事例 |
| 弱み | ケーススタディ章はGoogle文脈への依存が高く汎用性を感じにくい箇所あり |
| コード例 | 少なめ。ハンズオン志向の読者には物足りないかもしれない |
本書の強みは、設計・実装・運用・組織という複数の軸を「セキュリティと信頼性の統合」という一本の軸で貫いている点にあります。SREとしての運用視点、セキュリティエンジニアとしての脅威モデリング視点、そして組織・文化設計の視点が一冊に収まっており、「システムを長期にわたって安全に動かし続けるとはどういうことか」を総合的に考える地図として機能します。