# SRS chapter6 Design for Understandability
PDF: https://static.googleusercontent.com/media/landing.google.com/en//sre/static/pdf/Building_Secure_and_Reliable_Systems.pdf
At: [【オンライン】Building Secure and Reliable Systems輪読 #3](https://layerx.connpass.com/event/182209/)

## Agenda
- 自己紹介(30秒)
- Chapter6 のまとめのまとめ（3分）
- Chapter6 のまとめ（7分）
- Discussion(15分)
- Discussion であげてみたい質問
- @chaspy の感想

## 自己紹介
Lead Software Engineer, Site Reliability Engineering at Quipper
Twitter: https://twitter.com/chaspy_
chaspy.me

## Chapter6 のまとめのまとめ（3分）
* 信頼性とセキュリティその両方に Understandability は重要
* 既知の Mental Model で理解可能にするために、コンポーネントをセキュリティ境界で分割しろ
* フレームワークを使え

## Chapter6 のまとめ（7分）
* Understandability: 理解性（理解可能性）の重要性について説く
* 信頼性とセキュリティ両方とも、Understandability はそのリスクを減らすために貢献する
* Decreases the likelihood of security vulnerabilities or resilience failures
* 変更を加えるとき、それが複雑で理解が難しければ、間違った変更を行うリスクが常に存在する
* Facilitates effective incident response
* 障害対応時の迅速で正確な対応をするためにも、システムの複雑さはそれを妨げる
* Increases confidence in assertions about a system’s security posture
* システムのアサーションに自信を持つ：つまり複雑なシステムはそれを困難にする
* システムには必ず不確実性が含まれるが、理解しにくいシステムでは要求されたシステム特性を満たしているかを検証することが難しい
* System Invariants / 不変性
* どのように環境が変わっても、誤った振る舞いをしても、常に真である性質のこと
* 簡単に言えばセキュリティ要件のこと
* これを満たしてなければ脆弱性があると言える
* そしてそれを満たしているかを検証することにはコストがかかる
* Analyzing Invariants
* システムがある不変性を満たしていない場合の潜在的な害と、実際にそれを検証するための労力にはトレードオフの関係がある
* そのいい感じの着地点を探るために、Understandability という観点でアプローチする
* Mental Models
* メンタルモデル: システムの振る舞いなどを理解するためにコンポーネントなどをモデリングしたもの
* High Level Architecture とか Architecture Diagram 的なやつだと思っている
* High Understandability -> 単純でよく知られている Mental Model として現すことができる
* Design Pattern みたいな名前がついて既知のものがあれば理解しやすくなることは体感としてもわかる
* Designing Understandable Systems / 実際に Design する具体的な方法
* Complexity Versus Understandability
* 管理されてない複雑さが1番の敵
* 逆に言えば管理されていれば良いとも言える
* Gmail の例をあげ、Simple な Mental model で理解できる複数のコンポーネントが合わさって理解可能である
* つまり"複雑さを管理する" => 適切な粒度でコンポーネントを分割する
* Breaking Down Complexity
* "適切な粒度でコンポーネントを分割する" 結構難しい
* 分割はそのコンポーネントそのものもあるが、インターフェースを考慮する必要がある
* Centralized Responsibility for Security and Reliability Requirements
* 要件ごとにコンポーネントを分割するアプローチを取る
* そうすると、レビュー時でも、そのコンポーネントだけを見れば良い
* 各コンポーネントが独自に実装する場合、すべてレビューしなければならず、漏れる
* この章で繰り返し言われている Framework や Library を使えということ
* セキュリティと信頼性の要件に対する責任を一元化することの2つの利点
* システムの理解性の向上
* 検証するためにレビュアは一箇所だけ見れば良い
* 結果として得られるシステムが実際に正しいものである可能性が高まる
* アプリケーション内の要件の実装が不正確であったり、欠落している可能性を排除できる
* 最初に検証する際にコストがかかるが、将来的にはすべてに適用できるため償却できる
* System Architecture
* 引き続き適切に分割されたコンポーネントとしてシステムを設計していく話
* システム間のインターフェースを考慮することが大事
* なるべく入力を一切信頼しないでいいようにしたほうがいい
* 暗黙の保証条件があると、壊れやすくなる
* Understandable Interface Specifications
* 引き続きインターフェースの話
* Prefer narrow interfaces that offer less room for interpretation
* 解釈の余地が少ないインターフェース
* API surface を理解可能であるべき、あるいはツールがサポートしているか
* そういうフレームワークを選ぶべき
* Prefer interfaces that enforce a common object model
* 共通のオブジェクトモデルを強制するインターフェースを好む
* 同一のメンタルモデルを適用できるから理解が楽
* Pay attention to idempotent operations
* 冪等だいじ
* クライアントは迷ったらリトライすればいい
* Understandable Identities, Authentication, and Access Control
* ここからはセキュリティ観点で System Architecture を考えていく
* どのリソースがどのリソースにアクセス・操作できるかを知る必要がある
* Identifier Properties that Benefit Both Security and Reliability
* Have understandable identifiers
* 無意味な数字の文字列とか理解しづらい
* 変更でミスる可能性もある
* Be robust against spoofing(なりすまし)
* なりすましできないようにしようね
* Have nonreusable identifiers / 再利用できない識別子を持つ
* 何かの理由で退職したアカウントが別のひとに割り当てられたりすると危険
* Authentication and transport security
* すべてのエンジニアがこれらのトピックのすべてを深く理解することを期待するのは妥当ではありません。
* むしろ、エンジニアは抽象化や API を理解できるようになるべきです。
* Google の Application Layer Transport Security (ALTS) のようなシステムは、アプリケーションに自動サービス間認証とトランスポートセキュリティを提供します。
* これも結局フレームワーク使えという話
* Access control
* これも結局フレームワーク使えという話
* Small TCBs and strong security boundaries
* 脆弱性の影響を分離できる単位でコンポーネントを分離すべき
* TCB: Trusted Computing Base
* Software Design
* Using Application Framework
* はい
* Understanding Complex Data Flows
* 長くてよくわからんかった。。。
* Considering API Usability
* セキュア・バイ・コンストラクション API ってなんだろ
* フレームワーク使うといいよという話

## Discussion(15分)
* 発表内容で質疑とか
* その他参加者から面白いと思った部分を言ってもらったりとか

## Discussion であげてみたい質問

## @chaspy の感想
* 一般的なシステムデザイン・アーキテクチャデザインはセキュリティのためにも使えるんだなーと思った
* 基本的にフレームワークにのっかれ一辺倒で笑った、でもその通りだと思う
* 素早くソフトウェアのバージョンをアップデートし続けられることが大事
* 英語技術書久しぶりに読みました、30ページのこの章だけでもかなりしんどかった。
* ただ、確実に今インストールしておくべき内容だと思うのでこの勉強会を使ってキャッチアップしていきたいです
* 貴重な機会ありがとうございます！

---
以下原文メモあるいは翻訳

# Understandability: 理解可能性を高める
* SLO を達成することを考える場合、対象のシステムに対する理解が必要
* 高負荷時の挙動を理解することは簡単でも、特別に細工された入力が行われたときの挙動を理解することは難しい
* システムのライフサイクルのステージごとの Understandability Model を紹介

## Why Is Understandability Important?
* Decreases the likelihood of security vulnerabilities or resilience failures
* 変更を加えるとき、それが複雑で理解が難しければ、間違った変更を行うリスクが常に存在する
* Facilitates effective incident response
* 障害対応時の迅速で正確な対応をするためにも、システムの複雑さはそれを妨げる
* Increases confidence in assertions about a system’s security posture
* システムのアサーションに自信を持つ：つまり複雑なシステムはそれを困難にする
* システムには必ず不確実性が含まれるが、理解しにくいシステムでは要求されたシステム特性を満たしているかを検証することが難しい

### System Invariants
* システムの不変性 - どのように環境が変わっても、誤った振る舞いをしても、常に真である性質のこと
* 悪意のある攻撃、ハードウェアの障害など直接制御できないものも含まれる
* 望ましいプロパティが不変であることを判断するために、システム分析をする
* 望ましいセキュリティと信頼性のプロパティの具体例(翻訳より)
- システムの永続的なデータストアにアクセスできるのは、認証された適切な権限を持ったユーザだけです。
- システムの永続データストア内の機密データに対するすべての操作は、システムの監査ポリシーに従って監査ログに記録される。
- システムの信頼境界外から受信したすべての値は、インジェクション脆弱性が発生しやすい API (SQL クエリ API や HTML マークアップを構築するための API など) に渡される前に、適切に値付けまたはエンコードされています。
- システムのバックエンドが受け取るクエリの数は、システムのフロントエンドが受け取るクエリの数に比例します。
- システムのバックエンドがあらかじめ決められた時間後にクエリへの応答に失敗した場合、システムのフロントエンドは、例えば、近似的な答えで応答することで、優雅に劣化します。
- コンポーネントへの負荷がそのコンポーネントの処理能力を超えている場合、カスケード障害のリスクを減らすために、そのコンポーネントはクラッシュするのではなく、オーバーロードエラーを提供します。
- システムは、指定されたシステムのセットからのみRPCを受信することができ、指定されたシステムのセットにのみRPCを送信することができます。

* この望ましい状態ではないことをシステムが許可している - すなわち不変ではない場合、セキュリティ上の弱点・脆弱性があることを意味する

### Analyzing Invariants
* システムがある不変性を満たしていない場合の潜在的な害と、実際にそれを検証するための労力にはトレードオフの関係がある
* テストの実行、ソースコードを読んでバグを見つける努力はできるが、高い信頼性にはつながらない
* この章ではその実用的な中間点を、理解可能性という明確な目標を持ってシステムを設計することで、システムが特定の不変量を持っていることを示す
* テストと検証の詳細は13章

### Mental Models

* 高度に複雑なシステムは、人間が全体的な方法で推論することが困難である
* エンジニアはシステムを理解するとき、メンタルモデルを用いる
* ハイレベルアーキテクチャ・ダイアグラム的なやつだと思ってる
* 複雑なシステムの場合、複数のメンタルモデルを重ねて使う
* メンタルモデルには限界がある
* 異常時にどう振る舞うかを予測することは困難になる
* 具体例
* システムが攻撃を受けている場合、ある負荷の閾値を超えると異なる方法で応答するかもしれない
* Memory Pressure が仮想メモリやヒープ・ガベージコレクタのレベルでスラッシングを起こし、追加の負荷に追いつけなくなる
* この状態でシステム分析を行うとき、通常時のモデルと異なる振る舞いをしていることを認識しない限り、トラブルシューティングは難しい（誤解してしまう）
* 新しいコンポーネントを大規模システムに追加する場合、自然発生的なメンタルモデルは、既存の類似したサブシステムに対して人々が形成してきたメンタルモデルと一致しているべき
* 通常時と異常時に、既知のメンタルモデルが適用可能であるべき

## Designing Understandable Systems

システムを理解しやすくし、時間の経過とともに進化するシステムの理解可能性を維持するための具体的な方法を議論します。まず、複雑さの問題を考えます。

### Complexity Versus Understandability

* 理解しやすさの最大の敵は、管理されていない複雑性(Unmanaged Complexity)
* Google は実際に10億行以上のコードをホストし、何万人のエンジニアを雇用している
* 固有の機能が複雑なシステムの例として Gmail がある
* 以下の機能を提供している(翻訳)
- 複数のフロントエンドと UI (デスクトップ Web、モバイル Web、モバイルアプリ)
- サードパーティの開発者がアドオンを開発できるいくつかの API
- インバウンドとアウトバウンドの IMAP および POP インターフェース
- クラウドストレージサービスと統合された添付ファイル処理
- ドキュメントやスプレッドシートなど、さまざまな形式の添付ファイルのレンダリング
- オフラインで利用可能な Web クライアントとその下にある同期化インフラ
- スパムフィルタリング
- 自動メッセージ分類
- フライトやカレンダーイベントなどの構造化された情報を抽出するシステム
- スペルチェック
- スマートリプライとスマートリプライ
* これらの機能を持っているので、持たないシステムよりは複雑ですが、複雑性のために Produ t Manager に機能の削除を要求することはできないでしょう
* そういった場合でも、複雑さの管理に取り組めば十分に高い信頼性で価値を発揮し続けることができる
* 理解しやすさのために、システム設計を構造化し、システムの複雑さを区分けする必要がある
* 残りのセクションでは、管理されてない複雑さの一般的な原因と、それに対応する理解性の定価、複雑さを制御下に維持し、システムをより理解しやすくするのに役立つ設計パターンを調査する
* >複雑さを管理し、理解力を養うことを目的とした一般的なソフトウェア設計技術に非常に沿ったものです。また、John Ousterhout氏の『ソフトウェアデザインの哲学』(Yaknyam Press, 2018)のような、システムやソフトウェアデザインに関する一般的なテキストを参照するのもよいでしょう。
* [A Philosophy of Software Design (English Edition) Kindle Edition](https://www.amazon.co.jp/dp/B07N1XLQ7D/ref=dp-kindle-redirect?_encoding=UTF8&btkr=1)

### Breaking Down Complexity

* 複雑なシステムのすべての側面を理解するためには、大規模なメンタルモデルを内在化し、維持する必要があります。
* システムをより小さな構成要素から構成することで、より理解しやすくします
* サブシステムのプロパティを確立したり、サブシステムのプロパティをシステム全体のプロパティに結合したりすることは難しい
* これらはコンポーネント間のインターフェイスと信頼関係の性質に依存する

### Centralized Responsibility for Security and Reliability Requirements
* 基本的に、セキュリティ要求はすべてのコンポーネントに適用されることになる
* この場合、共通機能の責任を集中化されたコンポーネントに移すことができる
* RPC サービスフレームワークなど
* こうすれば、個々のアプリケーションが個別に実装する必要もないし
* セキュリティ担当者はレビューで全てのコンポーネントを確認しなくて良い
* 負荷がかかったときのカスケード障害を回避するために、リクエストはタイムアウトと deadline に従うべき
* retry のロジックは安全なメカニズムに従うべき
* これらのポリシーを実装するために、単一のアプリケーションが実装した場合、大障害を起こすことがある
* リトライ機構をライブラリとして一元化（集中化）してしまえばポリシーの実装漏れはなくなる
* セキュリティと信頼性の要件に対する責任を一元化することの2つの利点
* システムの理解性の向上
* 検証するためにレビュアは一箇所だけ見れば良い
* 結果として得られるシステムが実際に正しいものである可能性が高まる
* アプリケーション内の要件の実装が不正確であったり、欠落している可能性を排除できる
* 最初に検証する際にコストがかかるが、将来的にはすべてに適用できるため償却できる

## System Architecture
* システムをレイヤーとコンポーネントに構造化することは、複雑性を管理するための重要なツールです
* システムをどの単位で分割するかは慎重に考える必要がある
* あまりに緊密に結合されているコンポーネントは、モノリシックなシステムと同じように理解することが難しくなる
* 理解しやすさのためには、コンポーネント自体と同じぐらい、コンポーネント間の境界やインターフェースに注意を払わなければならない
* 外部環境からの入力は信頼に値しないし、それらの入力に何の仮定もおけないことを理解する
* 対照的に、内部の下位レイヤーのコンポーネント呼び出しを信頼に値するものとして扱い、APIに関するドキュメント化された制約ないに収まるように利用したいこともある
* そのような依存関係がある場合、その正しい動作が API 呼び出し元によって保証された何らかの条件などを確認しなければならなくなります
* つまり、システム全体を理解するために、システム全体の API のすべての呼び出しを理解する必要がある
* そのため、呼び出し元への保証された事前条件は少ない方が良い

### Understandable Interface Specifications

* 構造化されたインターフェース、一貫したオブジェクトモデル、冪等な操作はシステムの理解に貢献する
* Prefer narrow interfaces that offer less room for interpretation
* 解釈の余地が少ないインターフェースを好む
* サービスはさまざまなモデルやフレームワークを使用してモデルを公開することができる
* RESTful HTTP with JSON with OpenAPI
* gRPC
* Thrift
* W3C Web Services (XML/WSDL/SOAP)
* CORBA
* DCOM
* gRPC や Thrift を使用するサービスは、サポートする各 RPC メソッドの名前と、そのメソッドの入出力のタイプを定義します
* 対照的にフリーフォームの RESTful サービスは、任意の HTTP リクエストを受け入れるかもしれませんが、アプリケーションコードはリクエストボディが期待される構造を持つ JSON オブジェクトであることを評価します
* ユーザ定義型をサポートするフレームワークは、相互参照や適合確認のような機能のためのツールを簡単に作成し、API surface（仕様？）の発見性と理解性を向上させます
* このようなフレームワークは通常、時間の経過とともに API surface をより安全に進化させることを可能にします
* 例えば OpenAPI には API のバージョニング
* gRPC インターフェースを宣言する Protocol Buffer は下位互換性を維持するためにどのようにメッセージ定義をするかのガイドラインが文章化されている
* 対照的に、自由形式の JSON 文字列に基づいて構築された API は、実装コードやコアとなるビジネスロジックを検査しない限り、理解することが難しい場合がある
* このような制約がないアプローチは、セキュリティや信頼性のインシデントにつながる可能性がある
* クライアントとサーバが独立して更新された場合、RPC ペイロードの解釈が異なる可能性があり、クラッシュするかもしれない
* 明示的な API 仕様がないために、サービスのセキュリティ姿勢を評価することが難しくなる
* API 定義にアクセスできない限り、Istiop Authorization Policy のような認証フレームワークに記述されているポリシーをサービスが実際に露出している surface を相関させるための自動セキュリティ監査システムを構築するのは難しいだろう
* Prefer interfaces that enforce a common object model
* 共通のオブジェクトモデルを強制するインターフェースを好む
* 複数の種類のリソースを管理するシステムでは、Kubernetes で使用されているモデルのように、共通オブジェクトモデルの恩恵を受けることができます
* 各リソースタイプを個別に扱うのではなく、共通のオブジェクトモデルを使用することで、エンジニアはシステムに尾大部分を理解するための単一のメンタルモデルを使用することができる
* 例えば
* システム内の各オブジェクトは、事前に定義された一連の基本プロパティ（不変量）を満たすことを保証することができます。
* システムは、あらゆるタイプのオブジェクトをスコープ、注釈、参照、およびグループ化するための標準的な方法を提供することができます。
* 操作は、すべてのタイプのオブジェクトに対して一貫した動作を行うことができます。
* エンジニアは、ユースケースをサポートするためにカスタムのオブジェクトタイプを作成することができ、組み込みのタイプに使用するのと同じメンタルモデルを使用して、これらのオブジェクトタイプについて再確認することができます。
* >Google provides general [guidelines for designing resource-oriented APIs](https://cloud.google.com/apis/design/resources).
* Pay attention to idempotent operations
* 冪等な操作に気を払う
* 複数回同じ操作を適用した時、同じ結果が得られること
* 分散システムでは、操作が順番通りに行われなかったり、操作完了した後のサーバの応答がクライアントに届かない可能性があるため、冪等性は重要
* 冪等であれば、クライアントは成功した結果を受け取るまで再試行できる
* 冪等でなければ、サーバをポーリングするなどのアプローチが必要になる場合もある
* 冪等性はエンジニアのメンタルモデルにも影響を与える
* API の実際の動作と期待される動作の間に不一致があると、信頼できない結果や不正確な結果につながる可能性がある
* クライアントがデータベースにレコードを追加したいとき、リクエストは成功したが接続がリセットされたためレスポンスが配信されないとする。もしクライアントがその操作が冪等であると知っていれば再実行するが、そうでない場合重複したレコードを作成してしまう
* 非冪等な操作が必要な場合もあるが、冪等な操作はシンプルなメンタルモデルを導く
* 冪等であればいつ処理が行われたか追跡する必要がなく
* 成功したことを知るまで試し続けることができる
* uuid などの識別子をクライアントに要求すれば、2回目以降は重複していることをサーバが応答することができる

### Understandable Identities, Authentication, and Access Control
* 理解可能なアイデンティティ、認証、およびアクセス制御
* リソースが機密性が高いものである場合、どのリソースに誰がアクセス可能かを識別できる必要がある
* 決済システムの監査人は、どの内部の人間が顧客の個人情報にアクセスできるか知る必要がある
* 一般的には、特定のリソースへの特定のエンティティのアクセスを制限する認可およびアクセス制御ポリシーがある
* この特定のアクセスが発生した場合、ログに記録して、分析可能にする
#### Identities
* Identity とはエンティティに関連する属性または識別子の集合
* Credential は指定されたエンティティの Identity を保証する
* Credential には単純なパスワード、X.509 証明書、OAuth2 Token など
* Credential は通常、定義された認証プロトコルを使用して送信され、アクセス制御システムがリソースにアクセスするエンティティを識別するために使用する
* エンティティを識別子、それを識別するためのモデルを選択することは複雑になる可能性がある
* システムが人間のエンティティ（顧客と管理者の両方）をどのように識別するかを推論することは比較的簡単だが、大規模なシステムでは人間のエンティティだけでなく、すべてのエンティティを識別できる必要がある
* 大規模なシステムはマイクロサービスの集合で構成されることが多い
* データベースサービスは、定期的に下位レベルのディスクサービスにスナップショットしたいかもしれない
* ディスクサービスは、データベースサービスがスナップショットする必要のあるデータのために十分なディスククォータを持つことを保証するために、クォータサービスを呼び出したいかも
* 食品を注文するフロントエンドサービスの場合（略）
* アクティブエンティティとは、システム内で相互に作用する人間、ソフトウェアコンポーネント、ハードウェアコンポーネントのセットのこと

#### Identifier Properties that Benefit Both Security and Reliability
* 一般的に、Identity と Authentication サブシステムは Identity と Identitty を表現する Credential を提供する
* 意味のある Identity とは
* Have understandable identifiers
* 人間は Identifer が何を・誰を意味しているのが、外部リソースを参照することなく理解できる必要がある
* 例えば 24245223のような数字は理解可能ではありません
* 一方 `widget-store-frontend-prod` のような文字列は特定のワークロードを識別します
* ACL が人間が読める名前ではなく任意の文字列である場合、ACL を修正する際に間違いを犯す可能性が高くなる
* 悪意のある意図は、人間が読める識別子でもより明白だが、ACLの管理者は正当に見える識別子を使用する攻撃者を防ぐために、識別子が追加されたときに注意8 する必要がある
* Be robust against spoofing(なりすまし)
* この品質をどのように維持するかは、Credential の種類（password, token, certificate) および Identity を行う認証プロトコルによって異なる
* 例えば、clear-text(平文？)で使用されるユーザ名/パスワードまたは Bearer token は簡単になりすましが可能である
* TPM のようなハードウェアモジュールによってバックアップされ、TLS セッションで使用する秘密鍵を使用する証明書を詐称することはより難しいでしょう
* Have nonreusable identifiers / 再利用できない識別子を持つ
* あるエンティティで識別子を使用した後は、その識別子を再利用してはいけません。
* 例えば、ある企業のアクセス制御システムでメールアドレスを識別子として使用しているとします。特権を持つ管理者が退職した後、新しい従業員に管理者の古いメールアドレスが割り当てられた場合、その従業員は管理者の権限の多くを引き継ぐ可能性があります。

---
>従来のネットワークセキュリティの慣行では、アクセス制御とロギング、監査（ファイアウォールルールなど）の両方の主要な識別子としてIPアドレスを使用することがあります。残念ながら、最新のマイクロサービスシステムでは、IP アドレスには多くの欠点があります。IP アドレスは安定性とセキュリティを欠いており（簡単になりすましができる）、サービスを識別したり、システム内での特権レベルをモデル化したりするのに適した識別子を提供していません。最初のうちは、マイクロサービスはホストのプール上に配置され、複数のサービスが同じホスト上にホストされます。ポートは時間の経過とともに再利用されたり、さらに悪いことに、ホスト上で実行されているさまざまなサービスによって、任意に選択されたりする可能性があるため、ポートは強力な識別子を提供していません。マイクロサービスはまた、異なるホスト上で実行されている異なるインスタンスにサービスを提供することもあり、IPアドレスを安定した識別子として使用することはできません。
---

* アクセス制御と監査のメカニズムの品質は、システムで使用される識別子とその信頼関係の関連性に依存します。
* システム内のすべてのアクティブなエンティティに意味のある識別子を付けることは、セキュリティと信頼性の両方の観点から、理解しやすくするための基本的なステップです。
* セキュリティの面では、識別子は誰が何にアクセスできるかを判断するのに役立ちます。
* 信頼性の面では、識別子は、CPU、メモリ、およびネットワーク帯域幅などの共有リソースの使用を計画し、強制するのに役立ちます。
* 組織全体の ID システムは、共通のメンタルモデルを強化し、全従業員がエンティティを参照する際に同じ言語で話すことができることを意味する。
* 同じ種類のエンティティに対して競合する ID システム（例えば、グローバル・エンティティとローカル・エン ティティのシステムが共存している）を持つことは、エンジニアや監査人にとって理解が不必要に複雑になる。
* 第 4 章のウィジェット注文の例の外部支払処理サービスと同様に、企業は ID サブシステムを外部化することができる。
* OpenID Connect（OIDC）は、特定のプロバイダがアイデンティティをアサートできるようにするフレームワークを提供する。
* 組織は、独自の ID サブシステムを実装するのではなく、受け入れるプロバイダを構成するだけの責任があります。
* しかし、すべての依存関係と同様に、考慮すべきトレードオフがあります。この場合、このモデルのシンプルさと、信頼できるプロバイダのセキュリティと信頼性のロバスト性との間で考えなければなりません。

#### Example: Identity model for the Google production system.
うーん飛ばそうかなあ

いや大事っちゃ大事かなあ

あとにしよう

#### Authentication and transport security

* 認証とトランスポート・セキュリティは複雑な分野であり、暗号、プロトコル設計、オペレーティング・システムなどの分野に関する高度な知識を必要とします。
* すべてのエンジニアがこれらのトピックのすべてを深く理解することを期待するのは妥当ではありません。
* むしろ、エンジニアは抽象化や API を理解できるようになるべきです。
* Google の Application Layer Transport Security (ALTS) のようなシステムは、アプリケーションに自動サービス間認証とトランスポートセキュリティを提供します。
* このようにして、アプリケーション開発者は、認証情報がどのようにプロビジョニングされているのか、あるいは接続上のデータを保護するためにどの暗号アルゴリズムが使用されているのかを気にする必要はありません。
* アプリケーション開発者のメンタルモデルは単純です。
* アプリケーションは、意味のある identity として実行されます。
* マシン上の特権プロセスは、通常、そのマシンの identity として実行されます。
* オーケストレーションフレームワークを使用してワークロードとしてデプロイされたアプリケーションは、通常、環境と提供されたサービス (myservice-frontend-prod など) に固有のワークロード identity として実行されます。
* ALTS は、ゼロ設定のトランスポートセキュリティを有線で提供します。
* 一般的なアクセス制御フレームワーク用の API は、認証済みのピア情報を取得します。
* ALTS や類似のシステム、例えば Istio のセキュリティモデルは、真正性とトランスポートセキュリティをわかりやすい方法で提供します。
* インフラストラクチャのアプリケーション間のセキュリティ姿勢がシステム的なアプローチを使用しない限り、それを推論することは困難であるか、不可能です。
* 例えば、アプリケーション開発者が、使用するクレデンシャルの種類と、これらのクレデンシャルがアサートするワークロードの identity について、個々に選択をしなければならないとします。
* アプリケーションが認証を正しく実行していることを検証するために、監査者は、アプリケーションのコードをすべて手動で読む必要があります。
*
* このアプローチはセキュリティ上良くありません。コードの一部は、監査されていないか、正しくない可能性があります。

#### Access control

* フレームワークを使用して、受信サービス要求に対するアクセス制御ポリシーを成文化して実施することは、グローバルシステムの理解性を向上させるという正味のメリットがあります。
* フレームワークは、共通の知識を強化し、ポリシーを記述する統一された方法を提供するので、エンジニアのツールキットの重要な部分となります。
* フレームワークは、ワークロード間のデータ転送に関わる複数の識別情報など、本質的に複雑な相互作用を扱うことができます。例えば、図 6-1 は次のように示しています。
* 3 つの ID として実行されているワークロードのチェーン。Ingress」、「Frontend」、「Backend」の 3 つの ID として実行されるワークロードのチェーン
* 認証された顧客がリクエストを行う図
* チェーンの各リンクについて、フレームワークは、ワークロードと顧客のどちらがリクエストの権限を持っているかを判断できなければならない。
* また、どのワークロード ID が顧客に代わってデータを取得することを許可されているかを決定できるように、ポリシーも十分に表現できなければなりません。
* この固有の複雑さを把握するための統一された方法があれば、大多数のエンジニアはこれらの制御を理解することができます。
* もし各サービスチームが同じ複雑なユースケースを扱うための独自のアドホックなシステムテンプレートを持っていたら、理解することは困難になるでしょう。
* フレームワークでは、宣言的なアクセス制御ポリシーの指定と適用に一貫性が求められます。
* このような宣言的で統一された性質により、エンジニアはインフラストラクチャ内のサービスやユーザデータのセキュリティ暴露を評価するためのツールを開発することができます。
* もしアクセス制御ロジックがアプリケーションコードレベルでアドホックに実装されていたとしたら、そのようなツールを開発することは基本的に不可能でしょう。

(Security Boundaries)

飛ばす！
たぶんセキュリティ境界...ある操作をするコンポーネント複数が同じマシンに同居している場合、それぞれに権限を与えたりしたりして脆弱性リスクもあがるよみたいな話なんではと思っている
trusted computing base(TCB)

#### Small TCBs and strong security boundaries
* アプリケーションをマイクロサービスに分割することで、設計のセキュリティを向上させることができます。
* このアーキテクチャでは、各マイクロサービスはアプリケーションの機能の一部を自己完結的に処理し、データを独自の別個のデータベースに格納します。
* これらのマイクロサービスは RPC を介して相互に通信し、たとえ呼び出し元が別の内部マイクロサービスであっても、すべての着信リクエストは必ずしも信頼できるものではないとして扱います。
* マイクロサービスを使用して、図 6-3 に示すようにアプリケーションを再構築することができます。
* モノリシックなサーバの代わりに、ウェブアプリケーションのフロントエンドと、製品カタログと購買関連の機能のための個別のバックエンドを持つようになりました。
* Web フロントエンドは、データベースに直接問い合わせることはなく、代わりに適切なバックエンドに RPC を送信します。
* 例えば、フロントエンドはカタログ内のアイテムを検索したり、特定のアイテムの詳細を取得したりするために、カタログバックエンドにクエリを送信します。
* 同様に、フロントエンドは購買バックエンドにRPCを送信して、ショッピングカートのチェックアウトプロセスを実行します。
* この章で先に説明したように、バックエンドのマイクロサービスとデータベースサーバーは、呼び出し元を認証し、許可されたワークロードにリクエストを制限するために、ALTS のようなワークロード ID とインフラストラクチャレベルの認証プロトコルに依存することができます。
* この新しいアーキテクチャでは、住所データのセキュリティポリシーのための信頼されたコンピューティング基盤は、購買バックエンドとその データベース、およびそれらに関連する依存関係だけで構成されています。
* 攻撃者は、カタログバックエンドの脆弱性を利用して支払いデータを取得することはできません。
* その結果、この設計は、主要なシステムコンポーネントにおける脆弱性の影響を制限します(これについては、第8章で詳しく説明します)。

#### Security boundaries and threat models

* トラステッドコンピューティングベースのサイズと形状は、保証したいセキュリティ特性とシステムのアーキテクチャに依存します。
* システムのコンポーネントの周りに破線を引いて、それを TCB と呼ぶことはできません。
* コンポーネントのインターフェースと、それがシステムの残りの部分を暗黙的に信頼する方法を考えなければなりません。
* 私たちのアプリケーションでは、ユーザーが自分の配送先住所を表示したり更新したりすることができるとします。
* 購買バックエンドは配送先住所を処理するので、そのバックエンドは、ウェブフロントエンドがユーザーの配送先住所を取得して更新できるようにするRPCメソッドを公開する必要があります。
* 購買バックエンドがフロントエンドにユーザーの配送先住所の取得を許可している場合、ウェブフロントエンドを侵害した攻撃者は、このRPCメソッドを使用して、すべてのユーザーの機密データにアクセスしたり、変更したりすることができます。
* 言い換えれば、購買バックエンドがランダムな第三者を信頼するよりもウェブフロントエンドを信頼している場合、ウェブフロントエンドはTCBの一部となります。
* あるいは、購買バックエンドは、特定の外部ユーザーリクエストのコンテキストでリクエストを認証する、いわゆるエンドユーザーコンテキストチケット(EUC)をフロントエンドに提供することを要求することができる。
* EUCは、与えられたリクエストに関連付けられた認証クッキーやトークン(例えばOAuth2)などの 外部向けクレデンシャルと引き換えに、中央の認証サービスによって鋳造される内部の短期チケットである。
* バックエンドが有効なEUCを持つリクエストに応答してのみデータを提供する場合、 フロントエンドを侵害した攻撃者は、任意のユーザーのEUCを取得することができないため、 追跡しているバックエンドに完全にアクセスすることはできない。
* 最悪の場合、攻撃中にアプリケーションを積極的に使用しているユーザの機密データを取得してしまう可能性があります。
* このセキュリティモデルでは、ウェブオリジン（サーバの完全修飾ホスト名にプロトコルとオプションのポートを加えたもの）がトラストドメインを表します。
* 与えられたオリジンのコンテキストで実行されているJavaScriptは、そのコンテキストに存在する、またはそのコンテキストで利用可能なあらゆる情報を観察または修正することができます。
* 対照的に、ブラウザは、同一オリジンポリシーと呼ばれるルールに基づいて、異なるオリジン間のコンテンツやコードへのアクセスを制限します。
* 私たちのウェブフロントエンドは、https://widgets.example.com のような単一のウェブオリジンから UI 全体を提供しているかもしれません。
* これは、例えば、カタログ表示 UI の XSS 脆弱性15 を介してオリジンに注入された悪意のあるスクリプトが、ユーザーのプロファイル情報にアクセスし、そのユーザーの名前でアイテムを「購入」できる可能性があることを意味します。
* このように、Web セキュリティの脅威モデルでは、TCBAddressData は再び Web フロントエンド全体を含んでいます。
* このような状況は、システムをさらに分解して、追加のセキュリティ境界線（この場合は、ウェブの起源に基づいて）を設けることで解決できます。
* 図 6-4 に示すように、2 つの別個の Web フロントエンドを運用することができます。
* 1 つはカタログ検索とブラウジングを実装し、https://widgets.example.com でサービスを提供するもので、もう 1 つは購入プロファイルとチェックアウトを担当する別個のフロントエンドで、https://checkout.example.com でサービスを提供します。
* カタログ UI の XSS などの Web 脆弱性は、決済機能を侵害することはできません。

#### TCBs and understandability

* セキュリティ上の利点以外にも、TCBとセキュリティ境界線はシステムの理解を容易にします。
* TCBとして認定されるためには、コンポーネントがシステムの残りの部分から分離されていなければなりません。
* コンポーネントは、明確に定義されたクリーンなインタフェースを持っていなければならず、TCBの実装の正しさを分離して推論することができなければなりません。
* コンポーネントの正しさがそのコンポーネントの制御外の仮定に依存している場合、そのコンポーネントは定義上TCBではありません。
* TCBはそれ自体が故障領域であることが多く、バグやDoS攻撃、その他の運用上の影響に対してアプリケーションがどのように振る舞うかを理解することが容易になります。
* 第8章では、システムをコンパートメント化することの利点をより深く論じています。

## Software Design

* 大規模なシステムをセキュリティ境界で区切られたコンポーネントに構造化した後も、与えられたセキュリティ境界内のすべてのコードとサブコンポーネントについて推論する必要がありますが、これはまだ大規模で複雑なソフトウェアであることが多いです。
* このセクションでは、モジュール、ライブラリ、API などの小さなソフトウェアコンポーネントのレベルで不変量を再確認できるようにソフトウェアを構造化するためのテクニックについて説明します。

### Using Application Framework

* 前述したように、フレームワークは再利用可能な機能の断片を提供することができます。
* あるシステムには、認証フレームワーク、認可フレームワーク、RPC フレームワーク、オーケストレーションフレームワーク、モニタリングフレームワーク、ソフトウェアリリースフレームワークなどがあるかもしれません。
* これらのフレームワークは、多くの柔軟性を提供することができますが、多くの場合、柔軟性が高すぎることもあります。
* フレームワークの可能なすべての組み合わせや設定方法は、アプリケーション開発者やサービス開発者、サービスオーナー、SREs、DevOps エンジニアなど、サービスを扱うエンジニアにとっては圧倒されてしまうかもしれません。
* Google では、このような複雑さを管理するために、アプリケーション フレームワークと呼ばれる高レベルのフレームワークを作成することが有用であることに気付きました。
* これをフルスタックフレームワークやバッテリーを含むフレームワークと呼ぶこともあります。
* アプリケーションフレームワークは、機能の個々の部分のためのサブフレームワークの標準的なセットを提供し、適切なデフォルト設定と、すべてのサブフレームワークが連携して動作することを保証します。
* アプリケーションフレームワークは、ユーザーがサブフレームワークのセットを選択して設定する手間を省きます。
* 例えば、アプリケーション開発者がお気に入りのRPCフレームワークを使って新しいサービスを公開するとします。
* 彼らは、好みの認証フレームワークを使って認証を設定しますが、認証やアクセス制御を設定するのを忘れています。
* 機能的には、新しいサービスは正常に動作しているように見えます。
* しかし、認証ポリシーがなければ、アプリケーションは危険なほど安全ではありません。認証されたクライアント(例えば、システム内のすべてのアプリケーション)は、最小特権の原則(第5章を参照)に違反して、この新しいサービスを自由に呼び出すことができます。
* このような状況は、深刻な安全性の問題を引き起こす可能性があります。
* 例えば、サービスによって公開されているメソッドの一つが、呼び出し元がデータセンタ内のすべてのネットワークスイッチを再構成できるようにすることを想像してみてください。
* アプリケーションフレームワークは、すべてのアプリケーションが有効な認証ポリシーを持っていることを保証し、明示的に許可されていないすべてのクライアントを許可しないことで安全なデフォルトを提供することで、この問題を回避することができます。
* 一般的に、アプリケーションフレームワークは、アプリケーション開発者とサービスオーナーが必要とするすべての機能を有効にし、設定するための意見のある方法を提供しなければなりません。
* リクエストのディスパッチ、リクエストの転送、期限の伝搬
* ユーザ入力のサニタイズとロケール検出
* 認証、認可、データアクセスの監査
* ロギングとエラー報告
* ヘルス管理、モニタリング、診断
* クォータの実施
* ロードバランシングとトラフィック管理
* バイナリと構成のデプロイメント
* 統合、プレリリース、ロードテスト
* ダッシュボードとアラート
* 容量計画とプロビジョニング
* 計画されたインフラストラクチャの停止の処理
* アプリケーションフレームワークは、モニタリング、アラート、ロードバランシング、容量計画のような信頼性に関連した懸念事項に対処します(第12章参照)。
* このように、アプリケーションフレームワークは、複数の部門にまたがるエンジニアが同じ言語を話すことを可能にし、それによってチーム間の理解力と共感力を高めることができます。

### Understanding Complex Data Flows

* 多くのセキュリティプロパティは、システムを流れる値についてのアサーションに依存しています。
* 例えば、多くのウェブサービスは様々な目的で URL を使用しています。
* 最初は、システム全体で URL を文字列として表現することは、単純で簡単なように思えます。
* しかし、アプリケーションのコードやライブラリは、URLがよく形成されているという暗黙の仮定をしたり、URLがhttpsのような特定のスキームを持っているという仮定をしたりするかもしれません。
* そのようなコードは、仮定に違反する URL で起動することができれば、そのようなコードはインコレクトされます (そして、セキュリティバグを抱えている可能性があります)。
* 言い換えれば、信頼できない外部の呼び出し元からの入力を受け取る上流のコードは、正しく適切な検証を適用するという暗黙の前提があるということです。
* しかし、文字列型の値は、それが整形されたURLを表すかどうかについての明示的なアサーションを持たない。
* 文字列」型自体は、値が特定の長さの文字列またはコードポイントであることを示すだけである(詳細は実装言語に依存する)。
* 値のプロパティに関する他の仮定はすべて暗黙のうちに行われます。
* したがって、下流のコードの正しさについて推論するには、上流のすべてのコードを理解し、そのコードが実際に必要な検証を行っているかどうかを理解する必要があります。
* 大規模で複雑なシステムを流れるデータのプロパティに関する推論は、値を特定のデータ型として表現し、その型契約が目的のプロパティを規定していることで、より扱いやすくすることができます。
* より理解しやすい設計では、下流のコードは URL を基本的な文字列型ではなく、形の良い URL を表す型（例えば Java クラスとして実装されています）として消費します17。
* 例えば、Url.parse(String) ファクトリ関数は、実行時の検証を行い、Url のインスタンス（整形された URL を表す）を返すか、エラーを通知するか、整形されていない値に対して例外を投げるかのいずれかを行います。
* この設計では、URL を消費するコードを理解し、その正確さが整形されているかどうかに依存するコードを理解することで、すべての呼び出し元を理解し、適切な検証を行うかどうかを理解する必要がなくなりました。
* 代わりに、2 つの小さな部分を理解することで、URL の使用を理解することができます。
* 第一に、Url 型の実装を分離して調べることができます。
* Url 型のすべてのコンストラクタが整形を保証しており、型のすべてのインスタンスが型の文書化された契約に適合していることが保証されていることを観察することができます。
* そして、Url 型の値を消費するコードの正しさについて、推論の前提として型の契約（つまり、整形性）を使用して個別に推論することができます。
* このように型を使用することで、読み込んで検証しなければならないコードの量を大幅に減らすことができるので、理解を助けることができます。
* 型がなければ、URL を使用するすべてのコードと、プレーンな文字列形式でそのコードに URL を通過的に渡すすべてのコードを過小評価しなければなりません。
* URL を型として表現することで、Url.parse() (および同様のコンストラクタやファクトリ関数) 内でのデータ検証の実装と、Url の最終的な用途だけを理解する必要があります。
* 単に型のインスタンスを渡すだけのアプリケーション・コードの残りの部分を理解する必要はありません。
* ある意味では、型の実装はTCBのように振る舞います-それは "all URLs are well-formed "プロパティのみを担当します。
* しかし、一般的に使用されている実装言語では、インターフェイス、型、モジュールのカプセル化機構は通常セキュリティ境界を表していません。
* したがって、モジュールの内部を、モジュール外のコードの悪意のある動作に耐えるTCBとして扱うことはできません。
* これは、ほとんどの言語では、モジュール境界の「外側」にあるコードは、それにもかかわらず、モジュールの内部状態を変更することができるからです（例えば、反射機能を使用したり、型キャストを介して）。
* 型カプセル化により、モジュールの動作を分離して理解することができますが、周囲のコードが悪意のない開発者によって書かれたものであり、コードが危殆化されていない環境で実行されているという仮定のもとでのみ、モジュールの動作を理解することができます。
* これは実際には合理的な前提です。通常、組織やインフラストラクチャレベルの制御（レポシトリーアクセス制御、コードレビュープロセス、サーバのハードニングなど）によって保証されています。
* しかし、この仮定が真実ではない場合、セキュリティチームは、結果として生じる最悪のシナリオに対処する必要があります（「パートIV」を参照してください）。
* 型を使用して、より複雑なプロパティを推論することもできます。
* 例えば、インジェクションの脆弱性(XSSやSQLインジェクションなど)を事前に発散させるには、入力が受信されてからインジェクションが発生しやすいAPIに渡されるまでの間のある時点で、外部からの入力や潜在的に悪意のある入力を適切に検証したり、エンコードしたりすることに依存します。
* アプリケーションにインジェクション脆弱性がないことを保証するには、外部入力からいわゆるインジェクションシンク（すなわち、十分に検証されていないかエンコードされた入力が提示された場合にセキュリ ティ脆弱性が発生しやすい API）へのデータの受け渡しに関与するすべてのコードとコンポーネントを理解する必要があります。
* このようなデータフローは、典型的なアプリケーションでは非常に複雑になる可能性があります。
* 値がフロントエンドで受信され、マイクロサービスバックエンドの 1 つ以上のレイヤーを通過し、データベースに保持され、その後読み返されてインジェクションシンクのコンテキストで使用されるというデータフローはよく見られます。
* このようなシナリオにおける一般的な脆弱性は、いわゆるストアド XSS バグで、信頼されない入力が、適切な検証やエスケープを行わずに、持続的なストレージを経由して HTML インジェクションシンク（HTML テンプレートやブラウザサイドの DOM API など）に到達するというものです。
* 大規模なアプリケーションにまたがるすべての関連するフローを合理的な時間内にレビューして理解することは、たとえツールを装備していたとしても、一般的に人間の能力をはるかに超えています。
* このようなインジェクション脆弱性を高度に確実に防止する効果的な方法の 1 つは、SQL クエリや HTML マークアップのようなインジェクションシンクコンテキストで使用しても安全であることが知られている値を区別するために型を使用することです18
* SafeSql や SafeHtml のような型のコンストラクタやビルダー API は、そのような型のすべてのインスタンスが、対応するシンクコンテキスト（例えば、SQL クエリ API や HTML レンダリングインギングコンテキスト）で使用しても本当に安全であることを保証する責任があります。
* これらのAPIは、潜在的に信頼されていない値の実行時の検証と、正しく構成されたAPI設計の組み合わせにより、型の契約を確実にします。
* コンストラクタは、本格的な HTML バリデータ/サニタイザや、テンプレートに補間されたデータにコンテキスト依存のエスケープやバリデーションを適用する HTML テンプレートシステムなど、より複雑なライブラリに依存することもあります
* シンクは、適切な型の値を受け入れるように変更されます。
* 型契約は、その値が対応するコンテキストで使用しても安全であることを示しており、これにより、型付きAPIは構造上安全になります。
* シンクは基本的な型（文字列など）の値を受け取ることもできますが、この場合、シンクのインジェクション・コンテキストでの値の安全性については何も仮定してはいけません。
* その代わりに、シンク API は、実行時に値が安全であることを確認するために、必要に応じてデータの検証やエンコーディングを行う責任を負います。
* この設計では、型の実装と型安全なシンク API を理解するだけで、アプリケーション全体に SQL インジェクションや XSS の脆弱性がないというアサーションをサポートすることができます。
* また、型のインスタンスを生成するために、型のセーフ・バイ・コンストラクション・ビルダーを使用するアプリケーション・コードを理解したり、レビューしたりする必要もありません。
* 第12章では、このアプローチについて詳しく説明します。

### Considering API Usability

* API の採用と使用が組織の開発者とその生産性に与える影響を考慮することは良いアイデアです。
* API の使用が煩雑であれば、開発者は採用に時間がかかったり、消極的になったりします。
* セキュア・バイ・コンストラクション API には、コードをより理解しやすくし、開発者がアプリケーションのロジックに集中できるようにするという二重のメリットがありますが、同時に、セキュアなアプローチを組織の文化に自動的に組み込むこともできます。
* 幸いなことに、セキュアバイコンストラクション API が開発者にとって純利益となるようなライブラリやフレームワークを設計することが可能な場合が多く、同時に、セキュリティと信頼性の文化を促進することもできます (第 21 章)。
* 理想的には、開発者がすでに慣れ親しんでいる確立されたパターンやイディオムに沿ったセキュアな API を採用することで、開発者は API の使用に関連するセキュリティ不変量の確保に責任を負わなくて済むという利点を得ることができます。
* 例えば、文脈的に自動エスケープするHTMLテンプレートシステムは、テンプレートに補間されたすべてのデータの正しい検証とエスケープのために完全に責任を負います。
* これはアプリケーション全体にとって強力なセキュリティの不変性であり、テンプレートがどのような(潜在的に悪意のある)データであっても、そのようなテンプレートのレンダリングがXSSの脆弱性をもたらすことがないことを保証するからです。
* 同時に、開発者の視点では、コンテキスト的に自動エスケープするHTMLテンプレートシステムを使用することは、通常のHTMLテンプレートを使用するのと同じようなものです。

#### Example: Secure cryptographic APIs and the Tink crypto framework

## Conclusion

* 信頼性とセキュリティは、理解しやすいシステムから、深く絡み合った形で利益を得ることができます。
* 信頼性」は「可用性」と同義として扱われることがありますが、この属性は実際には、システムの重要な設計上の保証である可用性、耐久性、セキュリティの不変性のすべてを維持することを意味しています。
* 理解可能なシステムを構築するための第一の指針は、明確で制約のある目的を持つコンポーネントでシステムを構築することです。
* これらのコンポーネントのいくつかは、信頼されたコンピューティングベースを構成し、セキュリティリスクに対処する責任を集中させることができます。
* また、これらのコンポーネントの中や間で、望ましい特性（セキュリティ不変性、アーキテクチャの回復力、データの耐久性など）を 実現するための戦略についても議論しました。
* これらの戦略には以下のようなものがあります。
* 狭く、一貫性のあるタイプ化されたインタフェース
* 一貫性のある慎重に実装された認証、認可、およびアカウンティング戦略
* アクティブなエンティティへのアイデンティティの明確な割り当て（それがソフトウェアのコ ンポーネントであれ人間の管理者であれ）
* コンポーネントがベストプラクティスに一貫して従うことを保証するために、セキュリティの不変性をカプセル化したアプリケーショ ンフレームワークライブラリとデータ型
* 最も重要なシステムの動作が誤動作している場合、システムの理解力が、短期間のインシデントと長引くディスアスタ ーの違いを生むことがあります。
* SRE は、業務を遂行するために、システムのセキュリティの不変性を認識していなければなりません。
* 極端なケースでは、セキュリティの影響でサービスをオフラインにしなければならず、セキュリティのために可用性を犠牲にしなければならないこともあります。

## Words
* nefarious
* maliciously
* holistic way
* fidelity