セキュリティ対策をやり遂げられる組織
熊野多聞氏：「Co3で支えるペパボのセキュリティ対策」をお話しします。サブタイトルは3つの要素があり、所属メンバーがそれぞれの要素について、リレー形式でお話しします。どうぞよろしくお願いします。
では本日のアジェンダです。
セキュリティ対策室のミッションは、以下のとおりです。情報セキュリティ基本方針とは、いわゆるセキュリティポリシーのことです。この中でアンダーラインと太字で示した「文化形成、技術的仕組みをリードする」がGMOペパボ株式会社のカルチャーを表したセキュリティ対策だと思っています。
どのようなメンバーで構成されているかですが、2021年2月現在（※取材当時）、CTO、CISOで取締役の栗林が管掌しています。その下にマネージャーとして私がいて、エンジニアの伊藤、森田と、基本的には3名で活動しています。技術士の力武先生（@jj1bdx）には、技術顧問として参画してもらっています。
軽く自己紹介をします。熊野と申します。2007年にインフラエンジニアとして入社して、各サービスのインフラを担当していました。当時はまだオンプレミスサーバーで運用していたため、データセンターでのキッティングやサーバー構築、運用や保守が主な業務でした。
そして2015年ですね。OpenStackを用いたプライベートクラウド基盤へ移行するときにマネジメント職へ転向しました。2018年からは、現在所属するセキュリティ対策室でマネジメントの推進などをやっています。
ではセキュリティ対策をやり遂げる組織についてお話しします。やり遂げる組織は「Completely」とも非常に関係が深いので、そこについてお話をします。Co3（セキュリティ対策室の方針、Communication ・Completeness ・Continuous）の1つである「Completely」ですが、「対策を完了させること」と定義しています。対策とは、脆弱性の修正を完了させたり、インシデントを収束させたりすることです。
セキュリティの対応はいろいろありますが、例えばインベントリ管理をするために「〇〇のサービスを出してください」と言ったときに、「ここは出てないね」となると、そこに穴があるかどうかもわかりません。そういったことにならないように、一つひとつの施策を完了させることが1つの大きな目的です。
セキュリティ施策は年月とともに変化する
次にセキュリティ対策を実施する会社の全体像を説明したいと思います。GMOペパボには複数のサービスがあり、それぞれのサービスに数名ずつ開発者が所属しています。そのほかにはあきちゃん（菅原千晶氏）から発表があったSREチームや、インフラエンジニアのチームがあって、協業してサービスを作って運用しています。サービスとして一番長い「ロリポップ！」は2001年にリリースしているので、2021年で20年目になります。
一番新しいサービスは「カラーミーリピート」でこれは2018年にリリースしています。
サービス設計時のセキュリティ対策は年月とともに当然変化します。これは長く続くサービスであれば、より顕著に表れます。「変化」とは、運用が長いことで改善が少しずつ行われて、頑健性のあるサービスになることもありますし、反対に陳腐化してしまってメンテナンスが難しくなることもあると思います。
一方で、新しいサービスには新しい技術がどんどん導入されるので、まだ発見されていないセキュリティホールへの不安があり、セキュリティーホールが発見された場合には早急な対応が必要となります。サービス開発時期によっては、技術スタックの選択の幅が広くあります。例えば開発言語や、フレームワーク、OSのディストリビューション、ミドルウェアなどは、サービスの数と続いている年数に比例してどんどんと幅が広くなります。
GMOペパボには、10年以上続くサービスからリリースして数年のサービスまで、規模や関わる人々の数などさまざまなものがあることを理解してもらえたかと思います。
これはセキュリティ対策室設置前の対策をどのように行っていたかというのを表している図です。それぞれの事業部門の開発メンバーが、セキュリティ対策と開発を同時に行っていました。セキュリティの専任のメンバーがどこかにいるのかというと、この図ではどこにも存在していません。
セキュリティはアプリケーションだけではなく、エンドポイント端末や、インフラレイヤーなどでも実施しますが、以前はこの図の通り横断する組織で実施していました。
セキュリティ対策室発足後はどのように変わったかというと、この赤線のとおり横断して見られるようになりました。ただし、セキュリティ対策を実施するメンバーに大きな変更はありません。それでもなぜ横断した組織が必要かというと、事業部ごとに判断を行っていたセキュリティ対策に、共通した判断基準や支援をして、このデコボコだったセキュリティの強度を均一にするためです。
一番低いところから漏れていくので、それを合わせましょうと横断的な組織が作られています。
ターニングポイントは2018年のセキュリティインシデント
次にGMOペパボのセキュリティ対策の年表です。インフラチームがOSを見て、ミドルウェアを設置するという対策がありましたが、2018年にターニングポイントとなるセキュリティインシデントが発生しました。
これを機に変わっていくわけですが、ハートブリードのような大きな脆弱性があった場合、共通の対策をすることもあります。ただし、基本的には事業部ごとで行っていました。2018年のターニングポイントがなければ、もしかしたら各サービスで、それぞれ対応するのがもう数年続いていたかもしれません。もしくは、今も続いていたかもしれません。
ターニングポイント後に、我々がどのように変わってきたかという、約3年の足跡です。2018年の1月にインシデントが発生して、同様の事象が他サービスで起こらないように統制を取る組織が必要となり、3月に組織を発足しました。同年12月にインシデント再発防止策の作成が完了し、第三者委員会の確認をもって2019年2月に実施完了のお知らせを出しています。
ここでいったん、インシデントの対応は終わるんですが、そこから継続してサービスをやっていくためには、脆弱性のような一過性の対策だけではなく、継続して行うべき新しい活動指標が必要になるだろうということになりました。その1つがインシデントハンドリング手法の標準化です。情報セキュリティインシデントは、初動の遅れにより影響が拡大する傾向があるので、インシデントの発見やインシデントハンドリングの重要性は高いです。
今お話ししたインシデントハンドリングのパートについては、次の伊藤（伊藤洋也氏）から発表します。
今までのセキュリティの工程は、リリース前のチェックやリリース後の運用の中で見つけるのが主だったのですが、インシデントがそもそも起こらないようにするために、前工程に持ってくるシフトレフトを採用しました。2020年には、シフトレフトが掲げられて、DevSecOpsを活動の中心にしましょうとなりました。
お互いにインシデント対策の弱いところを認識する
DevSecOpsとは何かを我々の解釈で説明したいと思います。真ん中の白い六角形があります。これはDevOpsのモデルの1つです。違う表現をしている図も多々あるかと思いますが、いろいろな要素を削って我々の解釈のDevOpsとご理解ください。
それを取り巻く緑の六角形がセキュリティコンポーネントです。例えば、一番上の白い六角形に「Code」がありますが、これはそのままコードを書くという意味です。この「コードを書く」には3つのセキュリティコンポーネントが紐づいています。マッピングをすることで、「だから必要ですよね」と各サービス開発者との相互理解を深めています。
マッピングの次には、それを実現するツールが必要になります。ベンダーが提供するツールを使ったり、OSSを活用したりすると思いますが、我々セキュリティ対策室のおもしろみの1つとして、自社でツールを開発するところがあるかと思います。ツールの紹介は、ここでは割愛します。
ツールを作って、環境を用意しただけだとまだ不十分で、漏れることがあります。「ツールを提供したからやれるよね」では終わりにせず、「それらを活用しているよね」というところまで持っていくのが、我々の「Completely」＝「完了する」です。
次にセキュリティ対策組織をマネジメント視点から見た発見と課題です。攻撃やセキュリティ事故の危険には常にさらされていると思ってください。対策が弱いところから発露します。1つのサービスが頑健であっても、情報セキュリティインシデントが発生すると会社全体に影響が出ます。セキュリティに関わるエンジニアだけでなく、主要部門のエンジニアが寄り添って弱いところをお互いに認識して対策を理解することが必要です。
対策を押し付けるのではなく、実行するために必要なことを一緒に考えるのが先ほどのDevSecOpsのマッピングに紐づいています。発見者のミスで引き起こされたインシデントであっても、その発見と報告に感謝することで隠ぺい体質にならない文化形成をすることが必要だと感じています。インシデントは小さなことから大きな問題に発展するため、業務の手を止めて確認することが必要ですが、そこには経営メンバーを含む全従業員の理解が必要です。
サブタイトルのCo3は、「協力してやり遂げる」「継続的に行う」を表す言葉で、セキュリティ対策室メンバーの行動指針となっています。セキュリティマネジメントの体制や考え方についてはそれらの実践、基礎を構築している伊藤さんにバトンタッチをしたいと思います。
（次回へつづく）
