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

　「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項目をチェックすることができる。

　上記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