サイボウズ株式会社

業種：SaaS

事業概要：グローバル展開する国産グループウェアの先駆けとして、「kintone」「サイボウズ Office」「Garoon」「メールワイズ」などを展開

従業員数：969 名（連結・2021 年 12 月末現在）

「チームワークあふれる社会を創る」という企業理念のもと、チームワーク支援のグループウェアを開発するサイボウズは、2011 年ごろから会社としてセキュリティへの取り組みを進めてきました。独自に運営する脆弱性報奨金制度などをはじめ、国内でも先進的なセキュリティへの取り組みを続ける同社の大塚様・長友様にお話をうかがいました。

💡 課題背景

• グローバルな SaaS サービス提供者として脆弱性管理を重要視しており、自社水準を満たし工数を削減できるツールを探していた

🙌 導入の決め手・導入効果

• 完全手動で行っていた脆弱性管理の工数は、毎月 45 人日→ 10 人日程度と大幅に減少
• プロダクトチームが自発的に yamory を新プロジェクトに導入するほどの使い勝手の良さ
• OSS の脆弱性管理につきものの迅速さや正確さといったプレッシャーから開放され、負担が楽になった

🖥 活用シーン

• kintone などのプロダクトに加え、GitHub で公開しているプラグイン・カスタマイズのサンプルリポジトリまで、幅広く yamory のスキャンを活用
• プロダクトチーム側も yamory の導入によって、リリースごとに手動で行っていたセキュリティチームへの OSS アップデートの報告を自動化
• OSS の脆弱性管理を通じて、透明性の高いセキュリティ水準を提供

2011年の「Cy-SIRT（サイサート）」が、セキュリティ組織の本格スタート

――お二人の自己紹介をお願いいたします

大塚氏：
PSIRT で、kintone とモバイル製品のセキュリティを担当しています。

長友氏：
私は Garoon と、グローバル向けの販売管理システムを担当しています。

――サイボウズでは、SaaS サービスとしては国内でもかなり早くセキュリティチームを結成していたのが印象的でした。組織としてどういった意思決定があったのでしょうか？

大塚氏：
2006 年頃より、脆弱性情報の問い合わせに対して適切に対応ができていなかった体制を見直し、脆弱性情報の専用窓口を設置することを含めた社内外の対応フローができ始めました。その後、2011 年にクラウドサービス「cybozu.com」のリリースをきっかけに、全社のセキュリティを取りまとめる役割を持った仮想組織として「Cy-SIRT（サイサート）」が発足。さらに 2013 年に発生したできごとをきっかけに、セキュリティポリシーの見直しやレポートラインの整備など、セキュリティ関連の改善活動が本格化していきます。

同時に、品質保証部の中で脆弱性診断を専門に実施するセキュリティチームが発足。並行してサイボウズ全体のセキュリティ強化をミッションとした会議体もスタートしました。

複数の取り組みが活発化する中でセキュリティチーム内の役割分担を明確にしようという機運が高まり、2017 年から既存のセキュリティ組織を PSIRT / CSIRT にわけ、現在に至ります。

――それぞれどういった役割を担当されているんですか？

大塚氏：
CSIRT では、社内のセキュリティ教育や、端末を紛失した際のインシデント対応などを行っています。PSIRT は、プロダクトのセキュリティ検証、OSS の脆弱性管理、外部のセキュリティベンダーに委託する監査の管理、脆弱性報奨金制度の運用、開発チームとのディスカッションなどをメインに、新卒入社エンジニア向けのセキュリティトレーニングなども実施しています。脆弱性が改修された際に、エンドユーザー向けに行う情報提供もしています。

――外部に脆弱性情報を公開しているんですね

大塚氏：
Garoon など、オンプレミスでサービスを使っていらっしゃる方もいるので注意喚起は重要です。また、セキュリティの活動の一環として脆弱性情報を公開していくことそのものが、サイボウズの透明性を広く知らせることにつながる点にメリットがあると思っています。

PSIRT の活動は、脆弱性を見つけるのが最終ゴールではなく、いかにユーザーにサイボウズ製品を安心して利用していただくかなので、そのゴールを達成するために限られた工数の中でどこに注力するのか考え、日々活動しています。

脆弱性対策を支える 3 つの柱

――脆弱性対策を複数の観点で行っているのは、とても珍しいですね

大塚氏：
クラウド製品は 3 つの観点から実施しています。社内での検証、社外に委託している監査、外部専門家の知識を取り入れるための脆弱性報奨金制度の 3 つです。社外の監査結果は、サイト上を通じて外部公開していますし、脆弱性を認識したら、社内でトリアージを行い、改修時期の検討をします。また、必要に応じて公的機関に連絡しています。

長友氏：
まったく同じバージョンについて社内・社外の両方で脆弱性診断を行うことがありますが、結果が同じことはほとんどないのが意外というか、とてもおもしろいです。やはり、複数の視点を組み合わせることが重要なのだなと感じています。

――パブリッククラウド側のセキュリティはどのように見ていますか？

パブリッククラウドについては、開発チームや社内で知識のあるメンバーを中心に日ごろから検討し相談を重ねています。加えて外部のセキュリティ監査会社による診断も定期的に実施していますね。

yamory 導入以前は、毎月 45 人日かけて手動で OSS 管理台帳を作っていた

――すでにかなり厚く脆弱性対策をやっていたように思えるのですが、yamory を導入したきっかけは何かありましたか？

長友氏：
以前は本当にしんどかったんです。yamory 導入以前は、毎月 45 人日かけて手動で OSS 管理台帳の作成や更新、OSS そのものの更新情報の確認をしていました。

具体的には、リリースごとにプロダクトチームから OSS の利用一覧をもらい、それを元に管理台帳を作って RSS を登録し、日々アップデート情報などを監視していました。加えてライセンスの確認や EOL のチェックもあります。かなり時間がかかっていましたね。

プロダクトチームにとっても、バージョンごとに OSS の利用状況を報告をしていくのは大変面倒だったのではないでしょうか。

――その手間をなるべく小さくしたいというのが、最初の課題意識だったんですね

長友氏：
ツールを導入しようといろいろ検討していたんですが、yamory という製品を使ってみたら思った以上にいいねという話になりまして。

まだ当時はβ 版だったんですが、一番さっと使えて、なおかつ安定感がある。ドキュメントも充実していたので、「ここを見てください」といえばエンジニア側で導入できました。それでもわからない不明点や要望などは、yamory の担当者さんにしっかり相談にのっていただけたのが本当に良かったなと思います。

特殊な要件も多かったので、マッチするツールが見つけられていなかったので、yamory はまさに「自分たちに使いやすい製品だ」という実感がありました。

工数はおよそ 1/4 に。何より嬉しかったのは、脆弱性管理のプレッシャーから楽になったこと

長友氏：
もちろん工数が 1/4 に削減できたという数値的なメリットもありましたが、個人的には何よりも毎週、迅速に、正確に情報を確認して開発チームに連絡するというプレッシャーから開放されたことが本当に嬉しかったです！

それまでは、先ほどお話したとおり開発チームがリリースするたびに OSS の一覧を出力してセキュリティチームに送り、われわれが前回ファイルとの差分をひとつひとつ見ていくという工程を踏んでいたので…

――それはどちらのチームも大変そうです

長友氏：
本当に、本当にしんどかったです。それでも、脆弱性管理はどれだけしんどくても絶対に手を抜けない部分なので、ただやり続けるほかなかった。手動で頑張ろうとするとどれだけ大変かということを身を持って知りました。

もう yamory がない状態に戻りたくはないですね。また手動に戻るとなったら、「ちょっと考えさせてください」って言うと思います（笑）

――導入時の壁はありましたか？

長友氏：
PSIRT だけでなく、開発チームにとっても工数を削減できるサービスだったので、エンジニアが自発的に yamory を取り入れる形で社内に広がっていきました。現在はプロダクト以外にも、GitHub で公開しているサンプルプラグインなどでも yamory が活用されています。

yamory を利用するかは製品ごとに判断してよいとしているのですが、yamory がないとエンジニアがリリースのたびに自力で OSS 一覧やアップデート状況をセキュリティチームに送る必要が出てくるので、yamory を利用することが普通になってきていますね。PSIRT としては、待っていれば使ってくれる状況でとても嬉しいです。

β 版から使い続けているユーザーとして、yamory に期待していることはたくさんある

――サイボウズ様からは、相談や日頃のお打ち合わせでカジュアルにご要望をいただくことも多いです

長友氏：
そうですね！対応している言語をもっと増やしてほしいですし、パッケージ管理ツールで管理していないライブラリを手動で登録できるようになるのも期待しています。また、EOL やコミュニティが活発でないなどの理由でアップデートのないプロダクトについての監視はまだ自前でやっているので、何らかの方法で通知してくれたりするといいなと思っています。

また、これはサイボウズ独特かもしれませんが、チーム間の垣根がないので、他のチームの脆弱性対応状況が見れたらよいなと思っています。開発チームから実際にそういう声があがっているんですよね。

――社内で同じ脆弱性に対応した際の過去ログが参照できるのは、とても便利そうですね！

yamory には開発チームごとに脆弱性の対応状況を管理・メモできるステータス機能がすでにありますし、全社横断でライブラリの管理をできるセキュリティチーム機能もすでに存在しています。なので、ぜひ実現お願いしたいです。

大塚氏：
yamory を見れば、今取り組む脆弱性対策がわかり、次に見るべき脆弱性もわかり、他のチームでどういった対策が取られているかがわかる。そんな状態になったらいいなと思います。

小さく始めればつらくない。ツールを活用しつつ、少しずつ拡大して、気づいたら「全社で脆弱性管理を行えた」状態にしよう

――最後に、脆弱性管理に悩んだり、管理そのものに踏み切れない企業へメッセージやアドバイスはありますか？

長友氏：
個人的には、 OSS を使っているなら、それらの利用状況は必ず把握すべきである、という感覚です。一方で、取り組むのはとても大変で工数やコストがかかるという感覚も、過去の経験からよくわかります。

しんどいのに効果が見えにくい。だからといって手を抜けば、いざインシデントが起こった際に大変になる、それが脆弱性管理です。

だから、まずは小さい範囲から取り組むのがおすすめです。小さい範囲の成功体験を少しずつ積み重ねて、最終的に気づいたら全社で脆弱性管理ができている、という状態を目指していくのがベストなんじゃないかと思っています。yamory ならそれができるし、実際にサイボウズでは大きく助けられています。

大塚氏：
脆弱性がないシステムにするのはやはり難しい。減らすことはできてもゼロにはならないのが、まさに脆弱性「管理」という言葉に現れているのだと思います。会社ごとに工数や制限はあると思いますが、世の中にはプラクティス集のようなドキュメントもありますし、yamory のようなツールもあるので、有効に活用して徐々に守れる範囲を広げていくのがいいですね。

――ありがとうございました