おれさまラボ

実際に手を動かして理解を深めるブログ。

読書メモ:Building Secure & Reliable Systems - Chapter 3

はじめに

GoogleのSRE本第3弾『Building Secure & Reliable Systems』に関する読書メモです。今回は Chapter 3 を読んでみました。ここから第2部に入り、Googleで行われている具体的な仕組みの紹介となっていきます。

Chapter 2 のメモはこちらからどうぞ。

Chapter 3

できることなら、システムを開発する初期段階からセキュリティと信頼性について考慮すべきところではありますが、実際には既存のシステムに対して、どうすればよりセキュリティを高められるか、どうすればより信頼性を高められるかという悩みを解決する仕組みをあとから追加することがほとんどです。

ここではまず、"Safe Proxy" と呼ばれる、Google で実際に使われる仕組みについて紹介されています。

Zero Touch Prod

Zero Touch Prodとは、Googleにおけるすべての変更作業を、自動化、ソフトウェアによる事前検証、エンジニアによる緊急オペレーションのいずれかとするプロジェクトのことだそうです。

この後紹介するプロキシの仕組みはZero Touch Prodを実現する要素のひとつです。Googleによれば、このプロジェクト(仕組み)によって、~13%程度のシステム障害を未然に防ぐことができたとされています。

Safe Proxy とは

Safe Proxy は既存のシステムを変更することなく、権限の最小化を実現し、プロキシを介して行われるすべてのオペレーションの監査、システムリソースへのアクセス制御、人為的ミスを防止する仕組みを提供します。

Google のシステムでは、クライアントとシステムの間に Safe Proxy が介在します。そのため、クライアントがアプリケーションと通信したい場合、クライアントは実際にはアプリケーションではなく Safe Proxy と通信することになります。

Safe Proxy にて、認証・認可が行われた後、Safe Proxy からシステムの間の通信は Remote Procedure Call(RPC)によって行われます。また、Safe Proxy を介す通信はすべて記録され、いつ、誰が、何をしたのかが分かるようになっています。

Safe Proxy を使うメリット

  • 機微な情報へのアクセスに対して、Multi-party Authorizationを導入できる
  • いつ、誰が、何をしたのか監査できる
  • システム再起動を行う場合にはレート制限をかけるなどレート制限の仕組みを入れることで、障害時の影響を最小化できる
  • サードパーティシステムとのコンパチビリティをプロキシで担保できる
  • セキュリティと信頼性をプロキシで担保することで、継続的な改善活動を行いやすい

Safe Proxy を使うデメリット

  • 維持コストが嵩む
  • 単一障害点(Single Point of Failure/SPOF)となりうる

→ 冗長構成を組むことが前提となる

  • アクセス制御が自らの首を締めることに繋がる

→ ポリシーテンプレートや設定の自動生成の仕組みを作ることで回避する

  • 攻撃ポイントとなる

→ Safe Proxy には特権を持たせないことで、万が一侵入されてもシステムに攻撃がしかけられないようにする

  • Safe Proxy を介してでしか接続できない(システムに直接接続することができない)

→ 万が一の場合は緊急のアクセス経路を設けるなど、仕組みを用意することで回避する

Google Tool Proxy

GoogleではCLIが一般的で、Googlerたちは独自のCLIツールをしばしば用います。それらのツールは便利である反面、セキュリティや信頼性を脅かす可能性も秘めています。

たとえばパラメータを誤ってシャットダウンコマンドをシステム全体に対して送ってしまうと、大障害につながります。また、悪意を持った人間が意図的にシステムをダウンさせるコマンドを送ってしまう可能性も秘めています。

これらのリスク回避のため、Googleでは Tool Proxy という仕組みを用意しています。

簡単なシステム概要図を以下に示します。

               +--> External Approve
              /
Client --> Tool Proxy --> command --> system

Tool Proxy を使うには、事前にユーザー権限や対象のシステム、実行するコマンドをポリシーとして定義し、以下のようなコマンドを実行するそうです。

$ tool-proxy-cli --proxy_address <proxy_role> <command>

実行したコマンドは RPC 通信で Tool Proxy へと送られ、権限やコマンド内容のチェックを受けます。コマンドがセンシティブなもの(たとえばshutdown)であれば、追加の multi-party authorization が必要となり、それらをクリアできればコマンドがシステム上で実行されるようになっているそうです。

まとめ

第3章ではSafe ProxyとGoogle Tool Proxyが紹介されました。

Safe Proxyを使うことで、既存システムに手を加えることなくセキュリティと信頼性の強化が可能となり、費用対効果に優れたやり方といえます。

また、GoogleではTool Proxyを使うことで、より安全に変更作業を行う事ができるようになっていることがわかりました。

ここでは既存システムにフォーカスが当たりましたが、本来はセキュリティと信頼性はシステム開発時から考慮されるべきことであり、そのためのアプローチはこれ以降の章で語られることとなるそうです。

以上