『Building Secure & Reliable Systems』を読み、 SRE とセキュリティについて考える
『Building Secure & Reliable Systems』は Google による SRE Books の3冊目に位置づけられており、タイトル通りセキュリティにフォーカスされている。 SRE とセキュリティの関わり方について問題意識があったので、軽くではあるが読んでみた。
最初に自身の問題意識を具体化して書いておくと、以下のような点である。
- SRE はセキュリティの責任主体となるべきなのか？
- 仮にそうだとすれば、 SRE のスキル範囲が少々広すぎやしないだろうか？
- SRE が守るべき「信頼性」の中にセキュリティも含まれるのか？
- なんとなく「そうだろう」という思いはあったが、きちんと考えられていない
- SRE のプラクティスの中で、セキュリティをどう取り扱っていくべきか？
セキュリティは誰の責任か
文中の表現を借りれば、本書は SRE book や SRE workbook では触れられていなかった、 SRE におけるセキュリティへの関わり方をまとめた1冊にあたる。ただ、必ずしも SRE だけに向けられた内容ではないし、ましてや SRE がセキュリティに関する最終責任を担うべきだ、といった論調でもない。
本書で繰り返されているのは、セキュリティはすべての人の責任であるということだ。専任の専門家だけではなく、すべての人がセキュリティの確保に携わるべきだとしており、 Preface においては対象読者について以下のように書かれている。
Because security and reliability are everyone’s responsibility, we’re targeting a broad audience: people who design, implement, and maintain systems. We’re challenging the dividing lines between the traditional professional roles of developers, architects, Site Reliability Engineers (SREs), systems administrators, and security engineers.
信頼性とセキュリティの共通点
本書では「セキュリティ」という概念を、 SRE における「信頼性」の概念と似た性格のものとして取り扱っている。いずれもソフトウェア開発において、速度を優先するというエクスキューズによって軽視される場合が多く、サービスが順調に運用されているうちは、不可視なものになりがちだ。しかしながら、サービスの成熟後に見直しを掛けることは困難であり、信頼性もセキュリティも、設計初期の段階から考慮するのが望ましい。
このような似た性格を負っているため、 SRE が有する信頼性確保に関するプラクティスを、セキュリティ施策にも応用できる。例えばインシデント発生を的確に検出するためには、いずれも可観測性の向上や、適切なロギングが欠かせない。実際にインシデントが発生した場合に備えた、危機対応手順を整備しておくことも必要になる。「100% 完全な状態」というのが不可能というのも両者の共通項であり、本書の中では言及がないが、 SLO の考え方をセキュリティに適用することもまた可能だろう。 eureka による Security / AuditabilityをSREチームの成果指標に加えた話 - Speaker Deck では、実際にセキュリティ関連の指標を SLI として取り入れた例が紹介されている。
セキュリティ専門家の必要性
先ほど「セキュリティはすべての人の責任である」という一節に触れたが、これは専門的なセキュリティエンジニアが必要ないということを意味しているわけではない。Chapter 20. Understanding Roles and Responsibilities において、セキュリティに誰が取り組むべきかという点に関してより踏み込んだ解説がされている。
信頼性とセキュリティが性格的に似ている、というアナロジーに今一度頼ろうと思うが、信頼性に関しても SRE だけが集中的に担うものではなく、「すべての人」が意識するべきであり、開発ライフサイクルに組み込むべきだというのが SRE book などで書かれていることだ。しかし、だからと言って SRE が必要ないわけではなく、信頼性確保のスペシャリストの立場から、開発者の作業に協力していくことになる。セキュリティエンジニアについても同様に、微妙な判断を迫られる場面などにおいて専門的見地が必要になるとしている。
では、セキュリティエンジニアを組織内のどこに配置するか。これに関してはいくつかのパターンが紹介されているが、興味を引かれたのは中央に独立したセキュリティチームを置くパターンだ。これによりセキュリティを犠牲にしてローンチを急いでしまうような場面において牽制が働くわけだが、当然ながら開発速度低下が懸念される。そこで各チームにはセキュリティチャンピオンと呼ばれるポジションを設け、セキュリティチームとのコラボレーションを促進する役割を務めることで、開発速度とセキュリティ双方のバランシングを行う。
ちなみに、この「セキュリティチャンピオン」という概念を僕は初めて知ったが、本書が初出というわけではないようで、2014年に 開発チームのなかに「セキュリティチャンピオン」を作れ――AppSec APAC 2014から | 日経クロステック（xTECH） で言及されていたりする。開発チームのセキュリティ意識を向上させる上でも、非常に良い施策ではないだろうか。
Impression
冒頭に書いた通り、僕の問題意識の発端はセキュリティの「責任主体」の所在にあったのだが、本書はそれを「全員」と言い切っていて目が覚めた思いがした。当然ながら、本書でも書いているように、専門のセキュリティエンジニアを雇い、微妙な問題などについて最終的なジャッジを下してもらえる状態を作ることがベストではある。ではあるが、高い専門性を持ったセキュリティエンジニアは国内の転職市場では不足しがちではあるし、自身でスキルを高めて、カバー可能な範囲のセキュリティには積極的に責任を負っていく姿勢が必要なのだろうと覚悟できた。
なお、 SRE がセキュリティの最終責任を担う組織体系として、国内では mixi の事例を SRE NEXT 2020で、SREとセキュリティに関するお話をします | by Isao Shimizu | mixi developers | Medium で見かけた。専門家が不在である際に、最終責任をどこに担わせるかは組織によるだろうが、 SRE はその有力候補にはなり得るだろうと認識している。ただ、やはり SRE のカバースキルが広すぎる結果にはならないか？という懸念はある。タスクとしては担いつつ、可能であればスキル面は外注するといった方策も考えられるかもしれない。
また、そもそもの話として、セキュリティ上の問題でサービスが停止したりすることがあれば、それは信頼性指標（多くの場合可用性など）を損ねる結果にも繋がってくる。そのため SRE は結局のところ、セキュリティと無関係でいられる道理はない。先に挙げた eureka の例のように、セキュリティに関する指標（例えば検知される脆弱性の数 x 個以内）を SLI として採用してしまうのも1つの手かもしれない。信頼性確保のための仕組みを開発サイクルの中に組み込んでいくための SRE のノウハウは、セキュリティに関しても極めて有効なはずだ。この点、メルカリによる DevSecOpsとは何か — 導入する組織が増加している理由 | メルカリエンジニアリング なども参考になる。
組織や文化面の問題意識から読んだため、このエントリーでもそういった記述に関して中心に取り上げたが、本書では設計、実装、保守・運用の各フェーズにおけるより具体的なプラクティスも豊富に盛り込まれている。繰り返し書いてきた通り、ポジションを問わずあらゆる人におすすめできる1冊だと感じた。