Design for Recovery
副題: Building Secure and Reliable Systems Ch9 #sre #srs 止まってはいけないシステム :
https://gyazo.com/227d11d56ade75865602e920956c5cb2
Resumption within two hours (two-hour RTO)
An FMI should design and test its systems and processes to enable the safe resumption of critical operations within two
hours of a disruption and to enable itself to complete settlement by the end of the day of the disruption, even in the case of extreme but plausible scenario
https://gyazo.com/0380ba16a720bb1a5373af112975214e
https://gyazo.com/35949a0330525449627afa9fb6153c6a from BIS (bank for international settlements)
BIS: 1930年に設立された中央銀行相互の決済をする組織。通貨価値と金融システムの安定を目的として中央銀行の政策と国際協力を支援している
というわけで、システムは不安定になります。国際機関おすみつきです。
東証の話は、そもそも可用性が重要なんでしたっけ?ってポイントもあります
不安定から安定にするのが「回復」であり、本章のテーマです。
安定性を毀損する要因は? (What Are We Recovering From?)
Random Errors
システム内だけでなく、天災や大規模NWも含む
例: 証券会社がつながっている証券取引所の障害
Accidental Errors
過失
SW Erros
Accidental Errosが遅延して発現するエラー
Malicious Actions
故意・悪意ある
回復設計の原則 (Design Principles for Recovery)
更新メカニズムは最速を目指し、ポリシーで安全性を担保しよう(Design to Go as Quickly as Possible (Guarded by Policy))
回復: 状態変更をすること
まずはシステム状態(state of the system)を変更できる更新メカニズムを作ろう
そのあとに、ポリシーやリスクに応じた制御機構のパラメたを追加しよう
緊急時の変更は、通常時の変更のパラメタを変えたレベルのものにしよう(tuned up to max)
例: codepipelineのinstance sizeを大きくしたり
例: 承認をスキップできるようにしたり
Googleの例:
https://gyazo.com/f23cad0e955e25bfbf77cf085e2ddd02
時間に依存したデータシステムには要注意(Limit Your Dependencies on External Notions of Time)
回復するときに、時間に依存したデータがあるとまずいかもよ...
(本当はもっと書いてあるので、詳しいことは本書で確認!)
ロールバックのトレードオフ(Rollbacks Represent a Tradeoff Between Security and Reliabillity)
変更によりインシデントが発生した場合、ロールバックしたくなるが、パッチが適用されてないバージョンであることもある
では、どのロールバックならいいか?
成熟度1: deny list
成熟度2: Security Version Numbers (SVN), Min Acceptable Security Version Number (MASVN)
成熟度3: 署名鍵と鍵の更新
deny listはだんだんfatになる。SVNとMASVNで最低限許容できるバージョンを指定する。
denyリストは一次的に使い、svn/masvnにとりこんでいく
MASVNはコンポーネントでグローバルな値と、リリース内の値がある。リリースの値は、リリース時にグローバルな値を入れたもの
SVNはサービス内にしかない。SVNはグローバルなMASVNと同じ値kあそれ以上
isPatchUpdate Allowed = Release(svn) >= Coponentstate(msvn)
https://gyazo.com/dbdd5a677d7cfac74ec2532b23ac0ade
署名鍵と更新
リリースごとに新しい鍵ペアをつくるっぽい,,,?
失効メカニズム
中央集権的なメカニズムにして、Revocation listを配布するのがよい
中央集権にしない場合、それを監視と自分でやることになるけどいいのか?
バイトレベルで状態をしりたい(Know Your Itended State, Down to Bytes)
ホスト管理、ファームウェア管理
バックアップはプライマリのストレージと同レベルで
継続的な検証とテスト設計(Design for Testing and Continuous Validation)は難しい
緊急時のアクセス (Emergency Access)
とはいっても、通常アクセスが全くできないこともある
足を撃ち抜いたとき?
十分なテストをしていれば発生しないのか
それでもミスをする、ミスをしたときの被害が甚大であるなら用意はしておくべき
ここ数週間でGSuiteやOffice365が落ちたけど、果たして3時間アクセスできないのは「緊急」か?
メールシステムやファイルストレージは?
SSOとしては?
冗長性の話なので、SSOの代替に、別IdPのSSOというのはなし
バイパス可能なアカウントを容易しておく
例: GSuiteはadmin権限はSSOできない
例: Azure ADはMFAの対象から外す事が可能
緊急時用のコミュニケーションチャネル
Slackが壊れた場合 -> Google hangoutを使うなど
緊急時を通常時のものと大きく変えると、「習慣化」が難しい
親しくし、平常時の特定の期間でも利用できるようにする
例: on-callでは緊急時プロトコルで通常業務をするなど
文書化はしましょう!
Unexpected Benefits(スルー)
Conclusion