はじめに
GoogleのSRE本第3弾『Building Secure & Reliable Systems』に関する読書メモです。今回は Chapter 5 を読んでみました。自分の理解を噛み砕いて書いているので、しっかり本意を理解したい方は原書を読むことをおすすめします。
Chapter 4 のメモはこちらからどうぞ。
第5章ではリスクベースでアクセスを分類し最小権限を強制するためのベストプラクティスが紹介されています。
ディストピア
理想的な世界では、システムを利用するひとはみな善人で、安全にミスなく仕事をします。しかし実際は、そんな理想郷は存在しません。エンジニアがミスしてシステムの可用性に影響を及ぼしたり、意図せずアカウントが漏洩したり、悪意を持った攻撃者がシステム内の情報を狙っているかもしれません。
In other words—to quote an SRE maxim—hope is not a strategy."
自分がシステムに対して悪いことをしようと思ったら何ができるか想像してみれば、さまざまな可能性が見えてきます。そのため、想像しうる攻撃による影響を最小化または排除するようにシステムを設計することが推奨されます。
最小特権の原則とその実装
最小特権の原則は、現実世界でシステムのセキュリティを強化し、信頼性を維持するのに役立つ考え方です。最小特権はシステムを構成する人間、自動化されたタスク、および個々のマシンなどシステムに関わるすべてのユーザーに適用され、すべての認証認可に対して最小特権が適用されるべきです。できれば ambient authority (ルートログインなど)を持たないように設計することが推奨されます。
Google は、BeyondCorp プログラムを通じて、大規模なゼロトラストネットワーキングモデルの実装に成功しています。インターネットよりも会議室の方が信頼されるなんて状況はもはやありえません。BeyondCorp の考え方では、たとえ会議室からの接続であっても、システムの利用には追加の認証・認可が必要となります。
最小特権の原則は、すべてのデータアクセスとアクションに適用されることが理想です。しかし、最小特権の原則を遵守するあまり、生産性に影響を及ぼすようであれば迷惑な話です。実装を検討する際には、生産性、セキュリティ、および信頼性のバランスがとれた運用を目指すよう心がけましょう。
リスクベースの認証・認可
追加の認証・認可について、もう少し深堀りしておきます。データやアクションはシステムの性質によって大きく異なるものです。そのため、すべてのアクセスを同じように扱うことは厳禁とされます。BeyondCorp が行う認証・認可は、ALL or NOTHING ではなく、影響度、セキュリティリスク、重要度に基づいた「リスクベースの分類」に基づいた認証・認可の仕組みです。BeyondCorp では、このようなリスクベースの認証・認可を、発生するすべてのアクセスに対して行います。
どのようにリスクを分類するかは、システムの規模や複雑性によって変わってきます。なので、一概にこの分類をすれば良いよ言えるものではありません。本書では以下のようなリスク分類を行っていました。
リスクの分類できたら、それぞれにどのようなアクセス制御をかけるか検討する必要があります。
- 誰がアクセス権をもつか
- どの程度厳重に管理されるべきか
- アクセスのタイプは読取か、書込か、その両方か
- インフラの管理はどうか など。
最小特権のベストプラクティス
Make each API endpoint do one thing well.
ひとつの API に複数の機能をもたせてはいけません。これは UNIX 哲学（Make each program do one thing well.）に似ていますね。
本書の中でも何度も登場しますが、複雑なシステムは人間が理解することが難しく、そのことが原因で事故やバグ、脆弱性が生まれます。API をつくるときにも、シンプルさを忘れてはいけないということです。
もうひとつのベストプラクティスは、ユーザーインターフェースの API に加えて、管理用の API にも注意することです。システム管理者やシステム自身が使うものだからといって手を抜いて良いものではありません。
たとえば、対話型セッションを script (ロギングできるコマンド)で取得するだけでは不十分です。攻撃者は Vim のセッション内から対話型コマンドを実行するなどの方法で bash history に残らないようにする術を知っています。
ユーザーインターフェース同様、シンプルかつセキュリティや信頼性にコミットしたつくりが推奨されます。
最小特権を実現するコンセプト
その他に、以下2つのコンセプトが紹介されていました。
ゼロタッチ
ゼロタッチ（zero-touch）とは、プロダクト環境から人間を排除することで、安全性・可用性を高めるアプローチのことを指します。このアプローチには、大規模な自動化と新しい安全なAPI、弾力性のある malti-party 承認システムが必要です。
緊急用アカウント
緊急用アカウントを意味する Breakglass という考え方は、ガラスを割って火災報知器の緊急ボタンを押す行動に由来しています。最小特権を実装すると、不測の事態の際に管理者が何もできないという状況に陥りかねません。たとえば、認証機能に問題が発生した場合、誰もシステムを救えなくなってしまいます。
そのような事態を回避する緊急のアクセス経路（認証システムを完全に迂回する経路）を用意しておくことで、不測の事態に対処できます。
以上
