# Building Secure & Reliable Systems Chap.1

- イベントページ
- [READING.4 #技術書を英語で読む会](https://reading.connpass.com/event/189804/)
- [技術書を英語で読む会の雑談メモリンク集](https://hackmd.io/@gkzz/H1fdY9jOP)
- [Building Secure &Reliable Systems](https://static.googleusercontent.com/media/landing.google.com/en//sre/static/pdf/Building_Secure_and_Reliable_Systems.pdf)

## Chapter 1. The Intersection of Security and Reliability

### written by @gkzz
- ソフトウェアエンジニアリングにおいて、信頼性はセキュアであることを内包するものであると思っていたが、2つを追求し続けることは難しいということが意外。火事の例などを読み進めて、なるほどと感じた。
- Reliabilityを追求することは、`fail-safe`, `fail-opened`
- e.g. 火事が起きたら脱出するための非常出口を残す
- Securityであることを追求することは`fail-secure`, `fail-closed`
- e.g. 火事が起きたら脱出するための非常出口を絶ち、火事の影響範囲を広げないようにする
- ReliabilityとSecurityの類似点として、`Simplicity`と記載されていて、「暗号技術入門 秘密の国のアリス」で、以下のように書かれていたことを思い出した。
- 良い暗号とは暗号の強度を測定できるもの。(誰にも解けない暗号はなく、強度が測定できないほうがよくない)
- 歴史的に暗号はいつか破られるものだから、暗号技術は公開し、実装技術を高めあったほうがよい。公開されている暗号技術を採用したほうがよい。

- 以下の記述を読んで、関連していそうな`Chapter 16. Disaster Planning`と`Chapter 17. Crisis Management`は気になった。

> As discussed in Chapters 16 and 17, (略) Frequent offensive security exercises test our defenses and help identify new vulnerabilities. Google employs IMAG even for small incidents, which further prompts us to regularly exercise emergency tools and processes.

- cf. [SRE の教訓 : Google におけるインシデント管理とは](https://cloud.google.com/blog/ja/products/gcp/incident-management-at-google-adventures-in-sre-land)

### written by @fujiwara
- 「Reliability Versus Security: Design Considerations」のトレードオフの例がわかりやすかった。
- 「Redundancy」と「Incident Management」。冗長性を増せば、攻撃者にとっては攻撃面が広がり、システムとしてのリスクが増す。
- Prefaceの以下の記載の通り、Chapter 2「Understanding Adversaries」も読んでおきたい。
- 攻撃者のプロファイリング、手法の解説をしているので基礎知識や他のChapter前提の確認になっているはず。
> We recommend you start with Chapters 1 and 2, and then read the chapters that most interest you.

### written by @y-wat
- ReliabilityとSecurityの関係がトレードオフというのは理解できない。「冗長性が脆弱性を増やす」というよりは実装量が増えれば脆弱性ポイントも増えるという一般的な話であって、ReliabilityとSecurityの対立構造とまで言う必要は無いと感じた。それを言うならセキュリティ用の実装だって脆弱性ポイントの増加として追求できてしまう。
- 「どこまでやるか(or やりきるか)」って、つまるところ費用対効果に落ち着くんでしょうか？もしくは中の人の技術的な限界?
- 皆さんの現場にSREってあります？企業間で職務内容に違いがどれくらい有るのか知りたい。
- Loggingとリカバリ戦略について皆さんの考えとか実装を聞いてみたい

### written by @genboku
- ACM Queueの[Debugging Incidents in Google's Distributed Systems](https://queue.acm.org/detail.cfm?id=3404974) を読み返してる
- Reliability and Securityの項目で `Evolution` の項目が特に気に入ったというか気になった。変わらないシステムは存在しない。どんな塩漬けシステムであっても、周辺環境の変化により単純に機器故障時の代えがないってことですら信頼性を下げていくわけで、そこに対して繰り返し繰り返し信頼性、セキュリティが変わらないことを最低限確認し続けるにはどうすればいいのだろうって思う。
- 一口に言えばリグレッションテストと称されるのだろうけど、その間口はあまりにも広い。
- [テストを自動化するのをやめ、自動テストを作ろう](https://speakerdeck.com/tsuemura/tesutowozi-dong-hua-surufalsewoyame-zi-dong-tesutowozuo-rou)

# Notes

`Cascading failure`
- noun
- meaning: A cascading failure is a process in a system of interconnected parts in which the failure of one or few parts can trigger the failure of other parts and so on. Such a failure may happen in many types of systems, including power transmission, computer networking, finance,
- sources: [wiki/Cascading_failure](https://en.wikipedia.org/wiki/Cascading_failure)

`vulnerability`
- noun
- meaning: the quality or state of being exposed to the possibility of being attacked or harmed, either physically or emotionally.
- e.g.: "conservation authorities have realized the vulnerability of the local population"

`Faile-safe`
- meaning: In engineering, a fail-safe is a design feature or practice that in the event of a specific type
of failure, inherently responds in a way that will cause minimal or no harm to other equipment, to the environment or to people.
`Unlike inherent safety to a particular hazard, a system being "fail-safe" does not mean that failure is impossible or improbable, but rather that the system's design prevents or mitigates unsafe consequences of the system's failure.`
That is, if and when a "fail-safe" system fails, it remains at least as safe as it was before the failure.[1][2] Since many types of failure are possible, failure mode and effects analysis is used to examine failure situations and recommend safety design and procedures.
`Some systems can never be made fail-safe, as continuous availability is needed. Redundancy, fault tolerance, or contingency plans are used for these situations` (e.g. multiple independently controlled and fuel-fed engines).
- sources: [wiki/Fail-safe](https://en.wikipedia.org/wiki/Fail-safe)

# Sources
- Building Secure &
Reliable Systems

- [pdf](https://static.googleusercontent.com/media/landing.google.com/en//sre/static/pdf/Building_Secure_and_Reliable_Systems.pdf)

- [O'reilly](https://learning.oreilly.com/library/view/building-secure-and/9781492083115/)
- [Amazon](https://www.amazon.co.jp/dp/1492083127)

# discord

【本日の雑談】

・ReliabilityとSecurityの関係がトレードオフ？
・皆さんの現場のSREはある？その役割は？情シス兼務？セキュリティ部門は？
・オレオレロギングポリシーと情報の秘匿性、デバッグの在り方
・データの整合性（マスター）とその文脈で出てくるロギングの期待される役割
・GCPはjsonを突っ込めばよいのでラク（BigQuery）？
・cloud watchのlogging、監査系のauditが合わさったcloud loggingを使っている。マッチしたものの行き先を指定できる。
・ロギングの粒度は気にしなくてよい。
Cloud Logging
https://cloud.google.com/logging?hl=ja
・Cloud Loggingで障害が出た場合、後続の処理が続かない
・対策は二重でログを出力するようにするしかないか
・ログを残す場所としての野良データベースが存在してしまう
・「東証システム障害」は分散システムだと乗り切れたのか

【リンク集】

・本当は恐ろしい分散システムの話
https://www.slideshare.net/kumagi/ss-81368169

・テストを自動化するのをやめ、自動テストを作ろう
https://speakerdeck.com/tsuemura/tesutowozi-dong-hua-surufalsewoyame-zi-dong-tesutowozuo-rou
↑リグレッションテスト
テスト駆動開発ではない

・SRE の教訓 : Google におけるインシデント管理とは
https://cloud.google.com/blog/ja/products/gcp/incident-management-at-google-adventures-in-sre-land

・Facebook Engineering
https://engineering.fb.com/data-center-engineering/fault-tolerance-through-optimal-workload-placement/

・[AWS GameDay] DevOpsエンジニアが全員退職した会社の新入社員としてAWS環境の運用・改善をしてきました
https://dev.classmethod.jp/articles/aws-gameday-report-20200829/

・How to Run a GameDay
https://www.gremlin.com/community/tutorials/how-to-run-a-gameday/

・アーキテクチャ大全のサンプル
indeed
https://gist.github.com/ryuseikurata/ee8597c61e68cbf706744ff12ea72581

・Netflix tech blog データストア
https://netflixtechblog.com/delta-a-data-synchronization-and-enrichment-platform-e82c36a79aee

・DevSecOps Days Tokyo。
https://devsecops-days-tokyo.com/