はじめに
Google の SRE 本 第3弾「Building Secure & Reliable Systems」を読み始めました。英語ですが、電子版は無料で公開されているので、興味がある方はぜひ読んでみてください。
※ネタバレ含みますので、自分で読みたいって方はそっ閉じしてください。
Building Secure & Reliable Systems とは
Google の SRE 経験値に基づいて、どうすればセキュアで信頼性の高いシステムを作れるのかという問いに対するノウハウを集めた本です。
以下リンクから PDF や EPUB を入手できます。
📰：Google - Site Reliability Engineering
Introduction
セキュリティエンジニアリングの Vice President である Royal Hansen 氏と SRE シニアディレクターである Michael Wildpaner 氏による前説、そして本書の前書きと続きます。
ここでは、DevOps、DevSecOps、SRE を組織に適用していくこと大切さが説かれていました。個人的にいい言葉だなと思ったのは「セキュリティと信頼性はみんなの責任」という一文です。セキュリティチームだけがセキュリティのことを考えてもだめだし、セキュリティチームが信頼性のことを考えなくてもだめ。セキュリティと信頼性はみんなで作り上げないといけないという強いメッセージを感じました。
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), system administrators, and security engineers.
上記のとおり、本書は対象読者を広くとっています。さまざまな立場からのさまざまな経験談、ベストプラクティスが語られますが、それらを読むときにはその役職、立場になりきって読むのがおすすめだそうです。想像力を働かせて、その立場からどうやったらシステムを改善できるのか考えると良いそうです。
もうひとつ、大切なことを述べていて、もちろん本書はさまざまなデータに基づいて Google としてのベストプラクティスを書いてはいるけれど、組織によってカルチャーが違うからそのまま自分の組織に適用できるとは思わないようにという忠告があります。ここに書いてあることを咀嚼して、何を自組織に取り入れれば良いか考えましょう、という指針を与えてくれています。
最後に、過去に出ている2冊の SRE 本（Google - Site Reliability Engineering）を読んでからの方が良いのかな？という疑問に対して「理解の補強にはなると思うけど、読んでなくても大丈夫」といった感じで書いてくれています。なので、いきなりこの本から読み始めても大丈夫です。
Chapter 1
第1章は 2012年9月27日に Google で発生した衝撃的な大規模障害からはじまります。ざっくりまとめると、ゲスト Wi-Fi のパスワード変更に起因する大量の認証リクエストにシステムが耐えきれずダウンしてしまったという障害です。ロードバランサーによるトラフィック迂回では復旧せず、障害はエンジニアにエスカレーションされました。
障害が発生したパスワードマネージャは過去5年間障害が発生したことがなく、さらにサポートはベストエフォートでの対応となっていました。そういうわけで、対応したエンジニアは障害対応経験がありませんでした。
エンジニアはシステム再起動を試みましたがなぜか再起動できません。このエンジニアは、再起動にはハードウェア・セキュリティ・モジュール（HSM）スマートカードが必要であることを知らなかったためです。スマートカードは世界中の Google の複数の金庫に保管されていますが、残念ながらこのエンジニアがいるニューヨークオフィスにはありませんでした。
エンジニアはオーストラリアの同僚に連絡して対処してもらおうとしましたが、金庫のパスワードを手元に持っていなかったため開けることができませんでした。
続いてカルフォルニアの同僚に助けを求めたところ、金庫からスマートカードを取り出して再起動を試みることができました。
しかし、なぜか再起動できません。
「カルフォルニアのスマートカードが悪いのかもしれない」。オーストラリアのエンジニアは金庫を強行突破して、オーストラリアにあるスマートカードを取り出す必要があると判断しました。1時間後、パワードリルを使って金庫を破ったオーストラリアのエンジニアが再起動を試みましたが、これも失敗しました。
最終的に再起動に成功するまでにはさらに1時間を要しました。エラーが発生した原因はカードの表裏を逆にしてカードリーダーに差し込んでいたことでした。
この障害からわかったことは、セキュリティと信頼性のバランスは難しいということです。セキュリティを強固にすること（この例ではHSMを利用したこと）で利便性が損なわれ（この例では世界のどこかの金庫の中にあるスマートカードが再起動に必要だった）、結果として長時間に渡ってシステムをダウンさせることに繋がる可能性があるということを肝に銘じねばなりません。
その他にも、さまざま大切なお話が書かれています。ここではすべてに触れることはしませんが、一部抜粋しておきます。
- トラブル時だけでなく日頃のコミュニケーションマジ大事
- システムはシンプルな方がいい。攻撃点を減らすだけでなく人が理解しやすいってことが大事
- 構築後に変更が発生しないシステムは稀で、新機能、インフラの変化、セキュリティの理由でシステムに手を入れなきゃいけないことがある。変更を加えるとシステムというやつは複雑化し、複雑性は、テストしても見逃すバグを生み出し、大障害を引き起こす
- ログ、大事。でも適切に取るの難しいし金もかかる。まずは障害検知できるログを、次にセキュリティログをとることを検討すると良い。ただ、セキュリティログにはセンシティブな情報含まれるから注意。
- 脆弱性のためにパッチ当てなきゃいけないけど、パフォーマンス落ちたりリソース食ったりすることあるからそのリスク評価と判断をクイックにするの難しいよね。
そして、第1章の締めに「自分の組織に合わせて、自分の頭で考えろよ」とイントロダクションで指摘されたことがもう一度書いてありました。とても大事なことのようなので、忘れないようにして以降も読み進めたいと思います。
おわりに
ぼちぼちマイペースに読んでいこうと思います。
以上
