セキュアで信頼性のあるシステム構築 ―Google SREが考える安全なシステムの設計、実装、保守

9章リカバリを想定した設計

執筆：Aaron Joyner、Jon McCune、Vitaliy Shipitsyn

協力：Constantinos Neophytou、Jessie Yang、Kristina Bennett

　複雑なシステムには必ず信頼性の問題があるもので、攻撃者はシステムに障害を発生させるか、そうでなくても意図された機能から逸脱させることを明示的に試みます。プロダクト開発では早い段階で、そうした障害を予測し、その後の避けられないリカバリプロセスについて計画しておく必要があります。

　本章では、レート制限やバージョン番号管理の使用といった戦略について検討します。システムを健全な状態に戻すことができるものの、セキュリティ脆弱性を改めて持ち込むことにもなりかねない、ロールバックや失効の仕組みのトレードオフについても深く掘り下げます。どのようなリカバリのアプローチを選択する場合も、システムが戻る必要のある状態と、その既知の良好な状態に既存の手法ではアクセスできない場合の対処方法を知っておくことが重要です。

　現代の分散システムでは、意図しないエラーと悪意がある故意のアクションの両方に起因する、さまざまな種類の障害が発生します。エラーの累積、まれな障害モード、攻撃者による悪意のあるアクションにさらされた場合、最も安全で弾力性の高いシステムであっても人間が介入してリカバリしなければなりません。

　障害が発生したか侵害されたシステムを安定した安全な状態にリカバリするという行為は、思いもよらない形で複雑になる可能性があります。例えば、不安定なリリースのロールバックは、セキュリティ脆弱性を改めて持ち込むかもしれません。セキュリティ脆弱性にパッチを適用する目的で新しいリリースをロールアウトすると、信頼性の問題が発生するかもしれません。こうしたリスクの高い緩和対策には、さらに微妙なトレードオフもたくさんあります。例えば、変更をデプロイする速度の判断では、迅速なロールアウトのほうが攻撃者との競争に勝てる可能性は高くなるものの、その変更について実行できるテストの量が限られることにもなります。その結果、安定性に関して重大なバグがある新しいコードを広範にデプロイしてしまうことにもなりかねません。 ...