この記事の目的
GoogleのSRE本（第3巻） を個人的に和訳したので、その要点をまとめメモとして残しています。
第1部：前書き
- ユーザーにとって、信頼性とセキュリティに関する機能はあって当然のもの
- 信頼性とセキュリティが正しく機能している場合、ユーザーはそれらを気にも留めない
- セキュリティと信頼性がどの組織にとっても最優先事項であるべき
第1章：セキュリティと信頼性の共通領域
パスワードと電動ドリル
-
Googleで起きたパスワードマネージャーの障害を例にしている
- パスワードマネージャーを復帰させるのに、セキュリティ上の対策により阻害され、電動ドリルを持ち出すまでに至った
信頼性とセキュリティを両方備えたシステムを構築するのは困難
上記障害の例では、障害を引き起こしたのは負荷に関する戦略ミス（信頼性）であるが、セキュリティ面の対策によりその回復を遅らせてしまった
セキュリティとプライバシーの共通領域
- セキュリティとプライバシーは密接した関係である
- 多くの場合、セキュリティへの対策は同時にプライバシーを守ることにもつながる
信頼性とセキュリティ：設計上の考慮事項
信頼性のリスクは本質的には悪意のないものから生じる（ハードウェアの劣化など）
セキュリティリスクは悪意を持った攻撃者より生じる（脆弱性への攻撃など）
-
敵がいない場合、システムはフェイルセーフ（オープン）になることが多い
- セキュリティ的には脆弱性である
信頼性とセキュリティのトレードオフ：冗長性
- 冗長性は信頼性を高めるが、攻撃領域も増やす
- 攻撃者は成功するために一つのパスで脆弱性を見つければ良い
信頼性とセキュリティのトレードオフ：インシデント管理
- 冗長性のインシデントに対しては、多くの視点を以って迅速に対応することが有効
- セキュリティのインシデントでは攻撃者に復旧手段を教えないために、知る必要のある情報のみ共有される
- 大量のシステムログはシステムの復旧を早めるのに役立つ
- ログの中身が攻撃者にとって有用な情報源となる可能性がある
機密性、完全性、可用性（CIAトライアド）
- これらは信頼性とセキュリティの両方に関連する
- 信頼性の問題がセキュリティの問題につながることもある
- 航空機のスタックマイクがパイロットの会話をブロードキャストしたケースなど
- DDoSは信頼性とセキュリティの両方の領域に属する
- トラフィックの急増が悪意を持っているかどうかの判断がつきにくい
信頼性とセキュリティの共通領域
信頼性とセキュリティはシステムの設計段階で発現する特性であり、設計の初期段階から考慮に入れる必要がある
システムの変更の影響を受けやすい特性であるため、継続的な注意、テストが必要となる
双方に影響する要因
不可視性
- 問題が起きない限り、ほとんど認識されない
- 信頼性とセキュリティの目標の一つに、顧客とパートナーとの信頼を構築することがある
- 情報は可能な限り明確で具体的に、わかりやすく顧客とパートナーに開示する
アセスメント
- リスクベースアプローチで、ネガティブなイベントに対するコスト、予防時のコストと発生時の対応コストを見積もることは可能
- ネガティブなイベントが起きる確率について、信頼性とセキュリティそれぞれ別々に測る必要がある
- 個々のコンポーネント間での障害に対する影響を分離できる場合、信頼性についてリスクを推論し、対応を検討することは可能
- セキュリティについては、システムの設計と実装の分析を要し、敵対的テストによって、システムの耐性、攻撃検知能力、攻撃の潜在的リスクを評価できる
シンプルさ
- システムをシンプルに保つのはシステムの信頼性とセキュリティ、両方を検証しやすくするのに最も有効な手法
- シンプルであれば、攻撃領域を減らし、予期しないシステムの相互作用の確率を減らし、人がシステムを理解し推論するのお容易
- 同時に、対応者が障害原因を迅速に把握、対応し平均修復時間（MTTR）を短縮できる
システムの成長
- システムの成長（新機能の追加、規模の変更、インフラの高度化）は、システムを複雑にする
- 進化する攻撃に対応するため、システムが複雑化する可能性
- リリーススピードのために開発のみに注力し、技術的負債がたまるリスク
- 小さくて無害に見える変更も、蓄積することで信頼性とセキュリティに予期せず問題を引き起こす
回復性
- 負荷はシステムへのリクエストの量と処理負荷の平均との関数
- リクエスト量を減らし、処理負荷を下げることで、システムの復元力を高める
- コンポーネントに冗長性と障害ドメインを組み込んで、要求を再ルーティングすることで障害の影響を制限できる
- システムが複雑化すると、システム全体の安全性を保証することは容易ではなくなる。下記が有効
- 多層防御：複数の冗長な防御メカニズムによって構成される
- 個別障害ドメイン：権限の区分化、資格情報の範囲を制限することで実装する
- 悪意を持ったインサイダーに対しては下記に記す対策が有効
- 最小特権の原則：職務を遂行するために必要な最小限のレベルのアクセス権限のみをユーザーに与えること
- マルチパーティ認証（MPA）：機密性の高い操作は特定の従業員によるレビューと承認なしではできない
- 悪意のないヒューマンエラーの防止にも有効
設計から製品化までの留意事項
- 設計が強固であり、適切なコードレビューを行っても、使用するフレームワークやライブラリが脆弱性を生む可能性がある
- デプロイする前に、一般的なシナリオと信頼性とセキュリティを検証するエッジケースを通して、構築したシステムが設計意図に沿ったものであることを保証する
- エッジケース例：負荷テスト、ファジング、暗号化ライブラリの検証など
- カナリアデプロイやゆっくりとしたローリングアップデートですべてのユーザーのデータが破壊されることを防ぐ（信頼性）
- コードレビューで悪意を持ったインサイダーが本番環境に有害なバイナリを導入することを防ぐ
システムとログ調査
- 完璧な信頼性とセキュリティを実現することは、通常実用的でなかったり、費用がかかりすぎたたりする
- 防御メカニズムが失敗することを想定し、失敗を検知して回復する計画を立てることも必要
- 適切なログ記録は障害の検出と対策を行う基盤となる
- ログは完全で詳細である方が優れているが、大規模システムではログの量がコストとなり、効果的な分析が困難となる
- ログ自体が攻撃者の魅力的な情報源とならないよう、認証資格情報や個人識別情報といった機密は含めない
インシデント対応
-
障害はすぐに重大化する（最悪の場合、数分でビジネスを破壊する）可能性があるため、迅速に対処する必要がある
- 十分にリハーサルされた協力体制と、適切なインシデント管理が必要
-
インシデント対応の組織化は困難
- 組織が小さい場合、対応者がインシデントを発見するまでに時間を要するリスク
- 組織が大きい場合：24時間365日、違うタイムゾーン間で協働する必要がある
- チーム間で状態を維持し、シフトの交代時にインシデント状況を引き継ぐ
- セキュリティインシデントは、なるべく多くの要人を巻き込もうとする力と、Need-to-knowに基づく制約（多くの場合、法的であったり、規制による要件）との間で調整が必要になる
- 最初のセキュリティインシデントは氷山の一角である可能性もあり、会社の枠を超えて法的機関が関与する可能性もある
-
インシデント対応のために、明確な指揮系統に加え、堅実なチェックリスト、プレイブック、およびプロトコルを用意する
- 例：Googleのインシデント管理（IMAG）
-
インシデント対応がない間は、下記に記す活動を行う
- プロセス、インフラの改善
- システム障害をシミュレートし、対応を義務付ける
- 防衛力のテスト、新たな脆弱性の特定
回復
- 通常、セキュリティインシデントからの回復には脆弱性を修正するためにシステムにパッチを適用する必要がある
- パッチを適切なメカニズムを通してできるだけ素早く提供することは、脆弱性を素早く修正することには有効だが、多くの障害を引き起こすバグやパフォーマンス（つまり信頼性）の問題を生むリスクがある
- 脆弱性が有名であったり深刻な場合、それを悪用される前に素早く修正する必要性がある
- 上記のリスクを避けて、脆弱性が悪用されてでもじっくり修正する（信頼性を優先）か、リスクを承知の上で素早く充てる（セキュリティを優先）かは、リスク評価とビジネス上の決定に帰着する
- 信頼性を損なわず必要な変更・更新を迅速に展開し、大規模なシステムダウンを引き起こす潜在リスクを検知できる復旧方法は重要である
- すべてのマシンの現在の望ましい状態を定義する
- システムのデグレードを防止する
まとめ
- 信頼性とセキュリティは、開発速度のために犠牲になりがちであり、後から修正するにはコストが必要になる
- プロジェクトのリスクプロファイルを念頭に置いておく
- 例えば、証券取引所や反体制派のコミュニケーションプラットフォームを運営することと、動物保護区のWebサイトを運営することは大きく異なる