Building Secure and Reliable Systems 読書メモ - Chapter 1 & 2

f:id:muziyoshiz:20200430014145p:plain:w320

今月中旬に、Google SRE による SRE 本の3冊目 "Building Secure and Reliable Systems" が無償公開されました。

www.publickey1.jp

以下のサイトから PDF, EPUB, MOBI 形式でダウンロードできます。過去の2冊は HTML で公開されていますが、今回は電子書籍のデータ形式での公開のようです。

landing.google.com

日本語版は、もし出版されたとしても2年後くらいになりそうなので、僕もそろそろ重い腰を上げて読み始めました。

導入にあたる Part I（Chapter 1 & 2）まで読み終わったので、ここまでの読書メモと感想を書いておきます。久しぶりに洋書読んでて結構疲れたので、自分への動機づけのために、今後、何章か読むたびに読書メモを書いていこうと思います。

読書メモ

以下、内容に関する僕の理解と、僕が特に重要と思った箇所のメモです。また、一部はメモに加えて、原文を引用しています。

あくまで内容の一部ですし、まだ全部読み終わってないので誤解も多いと思います。気になったキーワードがあったら原著をあたってください。

Foreword by Royal Hansen (Vice President, Security Engineering)

SRE モデル（DevOps の SRE-like version）が一般的になるにつれ、SRE が取り組んでいる問題領域は、同様の原動力をセキュリティの問題にももたらすのではないかと気づいた。いくつかの組織はこの2つを "DevSecOps" と呼ばれるアプローチに統合している。

SRE と security engineer には似たところが多い。SRE はチーム間を結びつけるモデル（error budget などのこと？）を作ったが、security engineer にも同様のものが必要。Hansen 氏とその同僚は、セキュリティは first-class であるべきと主張してきた。大企業内でのセキュリティに対するアプローチはこの20年間で劇的に変わった。

SRE が信頼性をソフトウェアのライフサイクルに組み込んだように、セキュリティもソフトウェアのライフサイクルに組み込むことが重要と思う。

Foreword by Michael Wildpaner (Senior Director, Site Reliability Engineering)

Site Reliability Engineering と Security Engineering はシステムの可用性を保つことに関係している。セキュリティインシデントはユーザーの信頼を壊し、システムの可用性を壊す。システムセキュリティは SRE の心の常にトップを占める。

Gmail の SRE テックリードの一人だったときに、SRE が、悪い設計や悪い実装によるセキュリティへの悪影響を防ぐ最後の壁として働くのを目にした。

Google の SRE に関する過去の2冊の書籍は、信頼性とセキュリティの交点（intersection of reliability and security）についての詳細は触れなかった。本書はそのギャップを埋め、セキュリティに特化したトピックにも紙面を取っている。

Preface

本書の目的は、セキュリティと信頼性に特化した実践者からの、システム設計、実装、およびメンテナンスに関する知見を提供すること。

We argue that everyone should be thinking about the fundamentals of reliability and security from the very beginning of the development process, and integrating those principles early in the system lifecycle.

私達は、すべての人々がその開発プロセスの初期から、信頼性とセキュリティの基盤について考え、それらの原則をシステムライフサイクルに統合すべきと強く考えている。

Because security and reliability are everyone’s responsibility, we’re targeting a broad audience: people who design, implement, and maintain systems. We’re challenging the dividing lines between the traditional professional roles of developers, architects, Site Reliability Engineers (SREs), systems administrators, and security engineers.

セキュリティと信頼性は全員の義務であるという考えから、本書は広い範囲の読者を対象としている。私達は従来の役割の線引き（開発者、アーキテクト、SRE、システム管理者、セキュリティエンジニア）を超えた話をしようとしている。自分のいまの立場とは関係なく、それぞれの立場に立って読んでみてほしい。

Chapter 1 と 2 を最初に読み、そのあとはあなたが最も興味を持った章を読むことをお勧めする。

Chapter 1. The Intersection of Security and Reliability

Google で2012年に起きた、社内システムの障害の事例。ある WiFi パスワード変更の告知がきっかけで、社内向けのパスワードマネージャ（数年前に作られたまま放置状態）に想定外の高負荷がかかりダウン。その信頼性の低さに反して、サーバ再起動のためのセキュリティが厳重で、最終的に金庫を電動ドリルで開けて HSM を取り出す羽目になった。

セキュリティと信頼性は、真に信用に足るシステムの重要な構成要素だが、セキュリティと信頼性の両方を満たすシステムを作るのは難しい。共通点もあるが、設計時に考慮すべき点は異なる。両者の微妙な連携が崩れると予想外の結果が生じる。

信頼性を上げるための設計が、セキュリティに影響する。トレードオフがある。冗長性を上げると攻撃対象が増える。インシデント対応のためにログの情報量を増やすと、ログも攻撃の対象になりうる。

Both security and reliability are concerned with the confidentiality, integrity, and availability of systems, but they view these properties through different lenses. The key difference between the two viewpoints is the presence or lack of a malicious adversary.

セキュリティと信頼性は、いずれも CIA（機密性、完全性、可用性）に関係するが、悪意ある攻撃者を想定するかどうか、という点が大きな違い。

セキュリティと信頼性は、いずれもシステムの設計から現れる特性である。いずれもシステムの設計初期から考慮しなければならないが、一見無害に思える変更で容易に壊れてしまう。その他にもいくつかの共通点がある。

Invisibility
- いずれもうまく行っているときは目に見えず、問題が生じたときだけ目につく
- いずれも、損なった場合の損害が大きい
Assessment
- いずれも悪影響が起きたときのコストを評価する必要があるが、セキュリティの方はその評価が更に難しい
Simplicity
- いずれも、システム設計をできるだけシンプルに保つことで達成しやすくなる
Evolution
- 市場の要求に答えるための機能追加などによりシステムは徐々に複雑になり、その影響は読みづらい
- セキュリティに関しては攻撃手段も日々進化する
Resilience
- システムが複雑になるにつれ、システムが回復性を持つと証明することは難しくなっていく
- Defense in depth（多重防御、縦深防御）、Distinct failure domains（障害の影響範囲の明確化）、The princeple of least privilege（最小限の権限の原則）などで脅威による影響を狭める
From Design to Production
- 本番へのデプロイ後も設計を維持する必要がある。コードレビューや共通フレームワークの活用、テスト、デプロイのためのシステムでそれを助ける
Investigating Systems and Logging
- セキュリティと信頼性を完全に維持することは難しいため、それが崩れたときに検知する仕組みが必要
- 検知のためにはログは多く、詳細なほどいいが、コストや情報漏えいのリスクとのトレードオフがある
Crisis response
- Google は Incident Management at Google (IMAG) と呼ばれるプログラムに体系化している。IMAG はアメリカ政府の Incident Command System (ICS) をモデルにしている
- ある危機が起きてから次の危機が起こるまでには長いインターバルがあるため、その間にスキルとモチベーションを維持するために Disaster Recovery Testing program (DiRT) を定期的に実行している。内部システム障害をシミュレートし、チームでの対処を強制する
Recovery
- 障害からの復旧は迅速に行いたいが、全体に同時にデプロイすると、新たな不具合や脆弱性も同様に全体へデプロイされる危険がある
- 変更を段階的にデプロイし、問題が起きたらすぐ発見できる仕組みが必要

Chapter 2. Understanding Adversaries

実際の攻撃者の分類についての詳細な解説。古典的なイメージのハッカーから離れて、実際の攻撃者、国家的な組織や犯罪者などについて詳しく知ることで、防御について考えることができる。

また、インサイダー（内部関係者）によるリスクにかなりのページを割いている。悪意あるインサイダーだけでなく、操作ミスなどによる影響もここに含む。Table 2-1. General categories of insiders and examples と Table 2-2. Framework for modeling insider risk はこのテーマについて話すときの必須資料になりそう。

インサイダーへの対策として、以下のコンセプトを取り上げている。これらは3章以降で詳しく説明される。

Least privilege
Zero trust
Multi-party authorization
Business justifications
Auditing and detection
Recoverability

攻撃者について理解するために、攻撃方法についての知識を得る方法を紹介している。

セキュリティファームによる threat intelligence（脅威情報）
- 攻撃者やマルウェアの分析レポート、Indicators of compromise (IOCs)
Cyber Kill Chain (TM)
- 攻撃者の行動を、攻撃者が最終的な目標達成までに取るステージという形で理解するためのフレームワーク
攻撃方法をカタログ化したフレームワーク
- Tactics, Techniques, and Procedures (TTP) のカタログ
- ATT&CK framework

著者らが見出した、リスクを評価する上での心構え。

You may not realize you’re a target. （自分たちが狙われる明確な理由はなさそうでも、他の攻撃の土台としてターゲットになりうる）
Attack sophistication is not a true predictor of success. （複雑な攻撃方法を気にするより、基本的な攻撃方法から対処せよ）
Don’t underestimate your adversary. （攻撃者があなたにかける労力を過小評価するな）
Attribution is hard. （攻撃者を特定しようとはせずに、攻撃者の取りうる行動、TTP への対処に集中せよ）
Attackers aren’t always afraid of being caught. （攻撃者は国をまたぐことも多く、もし特定できても逮捕は難しい）

ここまでの感想

自分の経験上も SRE とセキュリティって強い関連性があると思います。たいていの会社ではセキュリティエンジニアって希少で、セキュリティ上の問題が起こると SRE は必ず何らかの形で動くことになるんじゃないでしょうか？

本書の序文でもセキュリティエンジニアについて言及されていましたが、ここまで読んだ限りでは、ここから SRE とセキュリティエンジニアの連携の話が始まるのか、SRE がセキュリティエンジニアの役割を兼ねる話が始まるのかはよくわかりませんでした。あと、いわゆる情シスとの関係ってどうなんでしょう？　Chapter 3 以降で詳しい話が出てくると思うので、この先が楽しみです。

本書は全体的に具体例が多く、読んでいて飽きないです。ただ、その分、読んでいると余計なことをいろいろ考えてしまいます。

特に、Chapter 1 の冒頭にあるパスワードマネージャの障害の話。勝手な想像ですけど、最初はなにかの片手間で作ったようなシステムが、いつの間にか全社で使われるようになって、あとから社内監査で文句を言われてセキュリティが強化された、とかですよねきっと……。具体例があるあるすぎて、つい我が身を振り返ってしまいます。