Weitere ähnliche Inhalte Ähnlich wie Building secure and reliable systems #3 4 (20) Kürzlich hochgeladen (12) 2. CHAPTER3 : CASE STUDY: SAFE PROXIES
安全なプロキシを利⽤することで信頼性やセキュリティに関連する課題を解決できることの紹介
プロキシはロギングとマルチパーティ認証をシステムに追加する1つの⽅法であり、システムの安全性
と信頼性を⾼めるのに役⽴つ。
このアプローチは、既存のシステムでは費⽤効果の⾼いオプションで、パートIIで説明されている他の
設計原則と組み合わせると、はるかに弾⼒性がある。 第4章で説明するように、新しいプロジェクトを
開始する場合は、ロギングおよびアクセス制御モジュールと統合するフレームワークを使⽤してシステ
ムアーキテクチャを構築するのが理想的。
3. SAFE PROXIES IN PRODUCTION ENVIRONMENTS
● ⼀般に、プロキシは新しい信頼性とセキュリティの要件に対処する⽅法を提供する。実装されたシ
ステムに⼤幅な変更を加える必要はない。
● 既存のシステムを変更するのではなく、プロキシを使⽤するだけで、システムに直接接続されてい
たはずの接続をルーティングできる
● 悪意のある攻撃者や善意のあるメンバのミスを防げる
● Googleでは、システムへのSSH接続を確⽴せずに、安全なプロキシを使⽤してリスクのあるコマ
ンドを確認、承認、および実⾏
● これらのプロキシを使⽤して、問題をデバッグするためのきめ細かなアクセスを許可したり、マシ
ンの再起動をレート制限したりできる。 安全なプロキシは、ネットワーク間の単⼀のエントリポ
イントであり、次のことを可能にする主要な⼿段
すべてのオペレーションを監査
リソース のアクセス制御
⼈的ミスから本番を保護
● Googleが評価したすべての機能停⽌の約13％は、ゼロタッチ製品で防⽌または軽減できたと推定
5. SAFE PROXIES IN PRODUCTION ENVIRONMENTS
● プロキシは次のものを提供
マルチパーティ認証（MPA）2を実施する中⼼的なポイントであり、機密データとやり取りするリ
クエストのアクセス決定を⾏う。
特定のリクエストがいつ、誰によって実⾏されたかを追跡できる管理使⽤監査
レート制限。システムの再起動などの変更が徐々に有効になり、ミスの爆発範囲を制限できる可能
性がある。
プロキシの追加機能を使⽤してコンポーネント（変更できない）の動作を制御する、クローズドソ
ースのサードパーティターゲットシステムとの互換性
継続的な改善の統合。中央プロキシポイントにセキュリティと信頼性の強化を追加
6. SAFE PROXIES IN PRODUCTION ENVIRONMENTS
● デメリットもある。
● メンテナンスと運⽤のオーバーヘッドに関して、コストが増加
● 単⼀障害点。複数のインスタンスを実⾏して冗⻑性を⾼めることにより、この状況を緩和。
● アクセス制御のポリシー設定。これ⾃体がエラーの原因になる可能性がある。デフォルトで安全な
テンプレートまたは⾃動⽣成設定を提供することにより、ユーザーが正しい選択を⾏うようにガイ
ドする。このようなテンプレートまたは⾃動化を作成するとき、私たちはパートII全体を通して提
⽰された設計戦略に従う。
● 攻撃者が制御できる中央マシン。前述のポリシー構成では、システムがクライアントのIDを転送
し、クライアントに代わってアクションを実⾏する必要がある。プロキシの役割ではリクエストが
実⾏されないため、プロキシ⾃体は⾼い権限はない。
● 変更への抵抗。本番システムに直接接続したい場合。このようなトピックについては、第21章で
詳しく説明。
7. GOOGLE TOOL PROXY
● Google社員は、コマンドラインインターフェース（CLI）ツールを使⽤して管理操作の⼤部分を実
⾏
● これらのツールの⼀部は潜在的に危険（たとえば、特定のツールはサーバーの電源を切ることがで
きる。すべてのCLIツールを追跡し、⼀元化されたロギングを確実に実⾏し、機密性の⾼いアクシ
ョンがさらに保護されていることを確認することは困難で費⽤がかかる。）
● この問題に対処するために、Googleはツールプロキシを作成。これは、指定されたコマンドライ
ンをforkとexecを介して内部的に実⾏する汎⽤RPCメソッドを公開するバイナリ。
● すべての呼び出しはポリシーによって制御され、監査のためにログに記録され、MPAを要求する機
能があります。ツールプロキシを使⽤すると、ゼロタッチ製品の主な⽬標の1つを達成できる。つ
まり、⼈間が直接製品にアクセスできないようにすることで、製品をより安全にします。エンジニ
アはサーバー上で直接任意のコマンドを実⾏することはできない。代わりにTool Proxyに連絡する
必要がある。
8. CHAPTER4 : DESIGN TRADEOFFS
多くの場合、機能要件と信頼性要件＆セキュリティ要件は相対⽴してバランスをとることが難しい。
この章では信頼性要件とセキュリティ要件を初期段階から検討することの重要性について解説
ー機能要件、信頼性要件、セキュリティ要件の関連
ートレードオフが発⽣する例（決済サービス、マイクロサービス）
ー信頼性要件、セキュリティ要件を初期段階から盛り込むことに関する議論
10. FEATURE REQUIREMENTS
● ユースケース、ユーザーストーリー、ユーザージャーニー
● サービスまたはアプリケーションの主要な機能を識別し、ユーザーが特定のタスクを実⾏する⽅法
または特定のニーズを満たす⽅法（ユーザーとサービスまたはアプリケーションの間の⼀連の対
話）
● 通常設計上機能要件が主要な推進要因になる（私の解釈︓ユーザーのニーズは機能要件に現れが
ち）
● 様々な要件は時にトレードオフを伴うので、重要な要件は別途管理するのがおすすめ
● また、多くの要件はサービスまたはアプリ全体に適⽤され、ユーザージャーニーには現れてこない
○ 例︓アプリのUIは以下の要件を満たす必要がある
共通のデザインガイドラインに準拠
アクセシビリティガイドラインに準拠
プライバシーポリシーとToS(Terms of Service)のリンクフッターに表⽰
12. RELIABILITY AND SECURITY AS EMERGENT PROPERTIES OF SYSTEM
DESIGN ERGENROPERTIES （信頼性要件）F SYSTEM
● サービス全体をマイクロサービスなどのコンポーネントに分割する⽅法
● サービスの可⽤性と依存関係の可⽤性/信頼性の関係（サービスバックエンド、ストレージ、およ
び基盤となるプラットフォームなど）
● コンポーネントが通信に使⽤するメカニズム（RPC、メッセージキュー、イベントバスなど）、要
求のルーティング⽅法、および負荷分散と負荷制限の実装と構成⽅法
● 単体テスト、エンドツーエンドの機能テスト、⽣産準備レビュー（PRR）、負荷テスト、および同
様の検証アクティビティが、開発および展開ワークフローにどのように統合されているか
● システムの監視⽅法、および利⽤可能な監視、メトリック、およびログが、異常および障害の検出
と対応に必要な情報を提供しているかどうか
13. RELIABILITY AND SECURITY AS EMERGENT PROPERTIES OF SYSTEM
DESIGN ERGENROPERTIES （セキュリティ要件）
● ⼤規模なシステムをサブコンポーネントに分解する⽅法、およびそれらのコンポーネント間の信頼
関係
● アプリケーションが開発される実装⾔語、プラットフォーム、およびアプリケーション/サービス
フレームワーク
● セキュリティの設計と実装のレビュー、セキュリティテスト、および同様の検証アクティビティを
ソフトウェアの開発と展開のワークフローに統合する⽅法
● セキュリティアナリストやインシデントレスポンダーが利⽤できるセキュリティモニタリング、監
査ログ、異常検出、その他のツールの形式
14. EXAMPLE：GOOGLE DESIGN DOCUMENT
● 以下のような標準項⽬を含むデザインドキュメントのテンプレート化
● ステークホルダーからのFBを開発前に収集、セキュリティデザインレビューも⾏う
○ スケーラビリティ（システム規模、データ増加率、トラフィック増加率、どのようにスケールするか、
現在のシステムの状況は︖）
○ 冗⻑性と信頼性（データの損失や⼀時停⽌にどう対応するか、どのような影響があるか、バックアップ
対象、バックアップ⽅法、リストア⽅法、部分的な障害の復旧⽅法を含む）
○ 依存関係（他のシステムが利⽤できない時の影響、名前解決や時刻同期なども忘れずに︕）
○ データの完全性（どうやって完全性をチェックするか、どのデータ損失を検出すべきか、損失から検出
までの時間的猶予、復旧⽅法）
○ SLA（サービス稼働を監視、保証する仕組み、どこまでを保証できるか）
○ セキュリティとプライバシー（潜在的脅威と考えられる影響、対応⽅法、既知の脆弱性）
15. BALANCING REQUIREMENTS
● 既存システムに信頼性要件とセキュリティ要件を追加する際のコスト
○ セキュリティと信頼性に関する設計項⽬のいくつかは基本的なもの（例えばNoSQLを選ぶかRelational
Databaseを選ぶか、モノシリックかマイクロサービスかのような基本的なアーキテクチャ選択と本質的
に類似）
○ 通常、これらのセキュリティや信頼性に関連するデザインを既存システムに後から追加することは難し
い（⼤規模な設計変更やリファクタリングが必要）
○ さらに後から変更する場合はよりコストや時間がかかる上に、多くがセキュリティインシデントなど緊
急性の⾼い事象に紐づいて要求されるため時間的制約が⼤きい
○ その変更によって追加の⽋陥を⽣むリスクもある
○ これらの議論はSREとセキュリティチームを巻き込んで設計の初期段階に⾏うべき︕
16. EXAMPLE: PAYMENT PROCESSING
● 部品をコンシューマに販売するオンラインシステム（Web/モバイルでカタログから注⽂できる）
のケース
● セキュリティと信頼性の考慮
決済機能はセキュリティと信頼性の重要な考慮が必要。名前、住所、カード番号など。PCI-DSSなどの規制への対応やそれらのデー
タがダメージを受けた場合の対応の検討。場合によってはこのセキュリティインシデントはビジネスの存続にも影響し、実際に廃業
したケースも）
● 機密情報を扱うための３rd Party利⽤
これらのリスクを軽減するために機密情報を保持せず ３rd Partyの決済サービスを利⽤することも多い
● ⻑所
セキュリティ専⾨家を外部に持つ
データ侵害のリスク低減
コンプライアンス要件の簡略化
データ保持の開発コスト削減
● コストと技術以外のリスク
SW利⽤料⾦、開発コスト、ベンダー管理、ベンダー⾃信が毀損されるリスク
● 信頼性リスク
依存関係が追加される
● セキュリティリスク
ベンダーのセキュリティレベルの評価
18. EXAMPLE: MICROSERVICES AND THE GOOGLE WEB APPLICATION
FRAMEWORK
● 主要な⽬標︓⼤規模組織向けのアプリとサービスの開発と運⽤の効率化
● コードが様々なコーディングガイドラインやベストプラクティスに確実に準拠するようにした
● フレームワーク開発チームは設計及び実装のフェーズ全体でSREとセキュリティチームと連携し要
件が組み込まれていることを確認した
● 同時に監視など⾃動化できる機能を盛り込んだ
