ミクシィのSREがセキュリティに貢献する理由：特集：「DevSecOps」実現を支えるSRE（2）

サイトの信頼性向上のためにSREの導入が進んでいる。ではSREを導入した企業では具体的にどのようなことに取り組んでいるのか。2020年1月に開催された「SRE NEXT 2020」でミクシィの清水勲氏が語った。

[タンクフル，＠IT]

　サイトの信頼性向上のために、運用の自動化や障害対応、パフォーマンス管理などに取り組む「Site Reliability Engineering」（SRE）を導入する企業が増えている。そんな中、SREがセキュリティに貢献する動きが広まりつつあるという。2020年1月に開催された「SRE NEXT 2020」で登壇したミクシィの清水勲氏の講演内容を要約してお伝えする。

「DevOps」と「SRE」の関係性

ミクシィ 清水勲氏

　SREの基礎知識として、まず清水氏がよく見聞きするという「DevOpsとSREの違い」について「その説明はGoogleのWebサイトに掲載されている」と引用して解説した。それによると、「DevOpsをオブジェクト指向におけるインタフェースと捉えると、クラスSREはDevOpsの実装である」「SREには、DevOpsのインタフェースの部分に限らない追加のプラクティスと推奨事項が含まれる」「より良いソフトウェアをより早く提供するために組織の障壁を打破するように設計された親密なものである」という（参考）。

　「つまり、SREとDevOpsは、ソフトウェアの開発と運用で競合する別々の物ではない。DevOpsが全てを含んでいるというよりは、DevOpsという概念をベースにSREが新しいプラクティスを追加しているといえる」（清水氏）

SREがセキュリティに取り組む背景

　では、なぜSREがセキュリティに貢献しているのか。その背景にあるのが信頼性とセキュリティの共通点だ。

　SREは取り組みの中で、レイテンシやスループット、可用性などのSLI（Service Level Indicator：サービスレベルインジケーター）を利用してSLO（Service Level Objective：サービスレベル目標）という数値を設定する。

　例えば、SLOとして99.95％の可用性を設定したサービスの場合、30日間で許容される停止時間は21.9分になる。この時間はエラーバジェット（Error Budget：エラー予算）という指標として管理され、サービス停止に応じて「エラーバジェットをどれくらい消費したか」を判断する。

　このエラーバジェットによって、SREが取り組む内容は変化する。エラーバジェットを使い切っていなければ、サービスに新たな機能を実装したり、堅牢（けんろう）なサービス作りに時間を割り当てたりする。一方で、エラーバジェットを超えるような場合、システムの可用性を阻害する原因を特定し、改善させていく必要がある。

　可用性を下げる原因は、劣化によるハードウェア故障、オペレーションエラー、情報伝達のミス、バグの混入、外部からの攻撃などさまざま考えられる。ハードウェアであれソフトウェアであれセキュリティであれ、サービスの可用性を下げる原因に応じた知識が必要になる。

　つまり、SLOやエラーバジェットなどを用いてサービスの信頼性に取り組むSREが、それらの指標を用いてセキュリティにも取り組むことで、どれだけセキュリティにコストをかければいいのか、セキュリティ対策をどう進めればよいのかなどの道筋を立てやすいというわけだ。

　「世界中で開催されているSREに関するカンファレンス『SREcon』では、セキュリティをテーマにした講演が採択されている他、2020年に発売が予定されているGoogleのエンジニアが執筆した『Building Secure & Reliable Systems』は信頼性とセキュリティをテーマにプラクティスをまとめているなど、SREとセキュリティが関連するテーマとして取り上げられています」（清水氏）

『Building Secure & Reliable Systems』のダウンロードページ

　『Building Secure Reliable Systems』の早期リリース版は、セキュリティと信頼性の共通項について「信頼性とセキュリティはソフトウェアやシステムのライフサイクルに必要不可欠な存在」「信頼性やセキュリティを両立したシステムを後から実装することは難しく、設計段階で考慮できていることが望ましい。一方で信頼性もセキュリティも問題が起きていないとコストをかけない領域で、問題が起きてから始めて深刻になる」などを挙げている。

SREに求められる大前提、ミクシィでの取り組み

　ではそもそもSREには何が求められるのだろうか。清水氏はミクシィでの事例を基に、SREが企業内で果たすべき役割とその大前提を説明した。

　「SREのあるべき姿は、組織内のさまざまなチームと連携して課題に取り組むことです。SREだけで取り組むのではなく、ビジネスチーム、QAチーム、開発チームなどと率先してコミュニケーションを図り、連携していくことが大切でしょう」

　清水氏は組織内のチームとのコミュニケーションの原則として以下のルールを取り上げた。

• 開発チームなど、他チームとの間に壁を作らない
• （責任やスコープを）押し付け合わない
• 冷静にしっかりと議論する
• お互いの状況を理解し合う
• ビジネスや事業にとって優先すべきかどうか話し合う

　ではこうした前提を元に、SREができることは何だろうか。清水氏はセキュリティにも貢献するミクシィのSREが取り組んでいることとして、以下を取り上げた。それぞれ見ていこう。

• 開発チームへのヒアリング
• Infrastructure as Code（IaC）
• ログ収集と探索
• アップデート
• モニタリング、定期レポート
• ポストモーテム

開発チームへのヒアリング

　1つ目は、開発チームへのヒアリングだ。清水氏のチームは、新機能や新サービスを公開する際、どのようなライブラリを利用するのか、機能の内部に秘匿情報を保持していないかどうか、ユーザー管理においてパスワードを平文で保存していないかどうかといったことを細かく開発チームにヒアリングし、SREが考えるセキュリティ要件を満たしてもらうような開発を促しているという。

Infrastructure as Code

　2つ目は、SREが取り組むべきことの一つとしても挙がる、運用のコード化だ。

　「インフラの構築を手作業で進める運用は、属人的になりがちです。変更管理や設定に関するドキュメントが抜け漏れれば、問題も起きやすい。そうしたことが起きないよう、TerraformなどのIaCを支援するツールを活用したり、コードレビュー後に手作業ではなくCI（継続的インテグレーション）ツールと連携させてデプロイしたりすることが、セキュリティ対策にもつながります」

ログ収集と探索

　3つ目はSREでもセキュリティでも基本的で、かつ重要なログ収集と探索だ。

　「そのアクセスが正常なのか異常なのか脅威なのか判定するにはログが必要です。一方で、ログの量はコストに影響しやすいため『役に立つかは分かりませんが、取りあえずログに含めました』というのもよくありません。不要なログがないかを定期的にチェックする他、クラウドサービスのログ機能もできるだけ有効化し、それらのログを収集、検索できるSaaSの利用を検討すべきでしょう」

アップデート

　4つ目は、アップデートだ。アプリケーションに依存するライブラリはもちろん、OS、データベース（DB）、Webサーバなどのミドルウェア、モニタリングのためのエージェントソフトウェア、Kubernetesクラスタ、Helmチャート、Terraformなど、アップデートが必要なものは多岐にわたる。

　「アップデート対応は、永遠の悩みです。これらのアップデートを放置して『前回アップデートしたのは2年前』というような状況は危険です。アップデート後の変化に追従できないかもしれません。アップデートを自動化できる仕組みを用意する必要があるでしょう」

モニタリング、定期レポート

　5つ目はモニタリング、定期レポートだ。

　「アクセスがスパイクした際に、それがユーザー数の増加によるものなのか、悪意あるユーザーによる攻撃なのかは普段からモニタリングしていないと分かりません。異常ということを把握するためにもやっておくべきでしょう」

ポストモーテム

　6つ目は、ポストモーテムだ。障害や問題が発生した際に事象や対応を記録し、関係者間で振り返りができるようにする仕組みだ。

　「取り上げた施策の中でも最も大切なことです。私たちのチームではポストモーテムを書く頻度を上げていて、障害や問題の大きさにかかわらず積極的にポストモーテムを作成するのが大切だと考えています」

　清水氏によると、ポストモーテム作成の注意点は以下の通りだ。

• ポストモーテムはセキュリティに限定したものではない
• サービスへの影響の有無にかかわらず、積極的に作成する
• ポストモーテムの作成者を称賛する文化を作る
• ポストモーテムの内容について責めたり、批判したりしない
• SRE以外（できるだけ上位の役職者がよい）も巻き込んで定期的にポストモーテムを振り返り、改善を続けることを理想とする

　ポストモーテムに記載することは「問題があった」「システムが少しだけ落ちた」といったことから始めても構わないという。「作成するコストや手間も発生しますが、ポストモーテムの作成者を称賛する文化を作り上げることが大切です。誰もポストモーテムを作成しなかったり、ポストモーテムを作成したがらなかったりする企業文化で、セキュアなシステムを構築／維持していくことはできません」（清水氏）とした。

クラウドを活用する際に、SREが取り組むべきセキュリティ対策

　多くの企業がクラウドを活用している背景を踏まえ、清水氏は「クラウドを活用する際にSREが取り組むべきセキュリティ対策」について、AWS（Amazon Web Services）を活用するミクシィでの実践例を基に説明した。

　「クラウドの基盤自体はセキュアに守られており、信頼しても問題はない。しかし、そのクラウドの上に構築する部分は『自分たちでセキュリティを構築し、その責任を持つべき』だ」と強調。クラウドベンダーと、クラウドを利用する企業との「責任共有モデル」という考え方があることを示し、「自社が使用しているクラウドに、どのようなコンセプトがあるのかを確認しておくことが大切だ」と説明した。

　AWSは「AWS Well-Architected Framework」というツールを用意している。これはAWSでシステムを構築する上で、さまざまな要素に対してベストプラクティスとなるようなガイドラインをまとめたものだ。AWS Well-Architected Frameworkでは、セキュリティについて以下の5項目をチェックすることができる。

1. アイデンティティー管理とアクセス管理
2. 発見的統制
3. インフラストラクチャ保護
4. データ保護
5. インシデント対応

　上記5項目の視点から11個のチェックリストが用意されている。「全ての項目を今すぐクリアさせる必要はありません。自分たちがチェックしておきたいと考えた項目から、確認して実践すればいい」と清水氏は語る。

「AWS Well-Architected Framework」のWebサイト

　ミクシィの導入事例のように、SREが考えなければならないこと、やらなければならないことは多い。清水氏は「SREという立場で考えていくと、セキュリティについて貢献できることはたくさんあります。オンプレミスやクラウドにあるハードウェア管理はどうなっているか、サービスの問題を発見しやすい環境が構築できているかどうかなど、セキュリティに早い段階から貢献することで、企業の機会損失につながるような被害も減らすことができます。やるべきことは多いのでソフトウェアによる自動化も進めていきましょう」と語り、講演を締めくくった。

特集：「DevSecOps」を支えるSRE

ユーザーに素早く価値を提供しつつセキュアなサービスを運用していく上では「DevSecOps」の考え方が欠かせない。そのような中でGoogleが実践、提唱している「Site Reliability Engineering」（SRE）という役割の導入が、Webテクノロジー企業の間で進んでいる。サービスの信頼性向上をミッションとして改善を行うSREにサービスのセキュリティ部分を担当させる動きもある。一方で、限られたリソースの中でSREを実践することは容易ではない。SREが成果を果たすためには、複数の目標／方針を定め、インシデント対応はもちろん、ロギング、サービス監視、インフラのコード化、運用自動化など並行して取り組んでいく必要があるためだ。日常業務に加えて、自動化に向けた取り組み、そして企業によってはセキュリティへの対応などすべきことは多い。SREを実践している企業は、SREの考え方をどうデザインして実践し、SRE実践に当たって抱えた課題にどう取り組んでいるのか。インタビューや事例を通じて俯瞰（ふかん）してみよう。

特集：「DevSecOps」実現を支えるSRE