Chatwork株式会社

業種：SaaS

事業概要：業務の効率化と会社の成長を目的としたメール・電話・会議に代わるビジネスコミュニケーションツール「 Chatwork 」を提供

従業員数：247名（2021年10月末日時点）

2000年に創業した Chatwork は、メール・電話・会議に代わるビジネスコミュニケーションツール「 Chatwork 」を提供し、343,000社（2021年12月末日時点）に導入されています。 Chatwork では、セキュリティ対策として脆弱性管理クラウド yamory を導入し、プロダクトの安全性を強化しています。yamory 導入の経緯、活用状況について、プロダクト本部 副本部長 兼 プロダクトセキュリティ部マネージャーである田中佑樹様、およびプロダクトセキュリティ部の新沼孝之様にお話をうかがいました。

💡 課題背景

• 手動で脆弱性管理をしていたため、手間も時間もかかっていた
• 脆弱性有無の判別が人の知識に依存、属人化していた
• 利用しているソフトウェアを把握できず、重大な脆弱性を見過ごす可能性があった

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

• ダッシュボードが非常に見やすくシンプルで、何をすべきかわかりやすい
• Jira へのタスク連携ができ、既存の業務プロセスとの親和性が高かった
• 自動的かつ網羅的に脆弱性リスクを可視化でき、属人性の問題を解決できた
• オートトリアージ機能で、一次トリアージを自動化できた
• Log4j の脆弱性（ Log4Shell ）対策も、横断検索機能で影響調査できた

🖥 活用シーン

• GitHub スキャンとコマンドラインスキャンを活用、定期的にスキャンしている
• プロダクトセキュリティ部で週に一度 yamory のアラートを確認し、対応指示している

セキュリティ対策を担当する専門の部署を設立

――お二人の役割を教えてください。

田中氏：
プロダクト本部の副本部長として組織開発や採用などを行っています。また、プロダクトセキュリティ部を立ち上げてマネージャーを兼任しており、セキュリティの向上に取り組んでいます。

新沼氏：
yamory の検知状況の確認などを行うほか、プロダクトセキュリティ部として2週間単位で実施しているスクラムで、セキュリティ施策に関するタスクを担当しています。

――現在のセキュリティ組織体制とその経緯について教えてください。

田中氏：
プロダクトセキュリティ部という、プロダクトに関するセキュリティの向上をミッションにしている部署があります。マネージャーである私を含めて3人体制ですが、2人は鹿児島にいますので、 Chatwork によるチャットと Web 会議でコミュニケーションをしています。

それまでセキュリティ専門の組織がなかったため、各部署が個別にセキュリティ対応を行っていました。しかし、それではどうしても片手間になってしまいます。サイバー攻撃を受けたとしても、主体的にレスポンスを行うチームがいない状況が続いていたわけです。

この状況に対し、経営層を含めて漠然とした不安を感じており、私としても何か重大な事故が起こってからでは遅いという思いがありました。そのためまずは専任をたててしっかりとセキュリティの課題に対して向き合おうと思い、プロダクトセキュリティ部を立ち上げました。そして、社内でセキュリティ業務に関心のある人を募ったところ、新沼さんが手を挙げてくれました。それが始まりです。

新沼氏：
もともとは SRE というインフラのチームに所属していたのですが、プロダクトセキュリティ部の設立のお話を聞いて、セキュリティに興味がありましたし、力になりたいと考えて立候補しました。

田中氏：
セキュリティ専門のチームができたことで、 Chatwork のセキュリティ向上に貢献できているという実感があります。これまでは開発メンバーが自分で考えてセキュリティを担保せざるを得ない状況でした。やっと相談先ができたことで、開発メンバーも安心感を得られたのではないかと思っています。

――プロダクトのセキュリティ対策について、どのように優先順位を設定したのでしょうか。

田中氏：
何も軸がない状態で始まりましたので、まずは社内にあるプロダクトとそこに存在するセキュリティリスクを把握することから始めました。具体的には、脆弱性診断やツールによるスキャンを定期的に実施し、リスク管理や運用を定義しました。これにより社内のリスクの棚卸しができ、戦略的に動けるようになりました。

長期的な視点では、指針を決めて戦略を立て、それに沿って効果を考えながら投資をしていくことを目指しています。短期的な視点では、スクラムの枠組みを採用し、基本的に私がプロダクト・オーナー、新沼さんがスクラムマスターとして動くようにしています。

具体的には、セキュリティに関する課題をバックログとして順番に対応したり、バックログリファインメントというイベントでバックログを整理してタスクを洗い出し、対応する。これを2週間に1回のスプリントで回しています。

脆弱性管理の手動運用による属人化が課題

――プロダクトセキュリティ部が抱えていた課題について教えてください。

新沼氏：
プロダクトの脆弱性情報の管理に課題を抱えていました。というのも、当時は JVN や JVN iPedia を RSS で購読しスプレッドシートに転記、週次で確認して対応可否を判断するという手作業の運用でした。

しかも、プロダクトセキュリティ部のメンバーの得意分野が人により異なっているので判断が属人化してしまうという課題もありました。使用しているソフトウェアやバージョンも把握できていなかったので、まずは重要な脆弱性情報に絞り、それを取り逃さないようにする運用となっていました。

―― yamory を導入することになったきっかけについて教えてください。

新沼氏：
2021年の1月末に「オートトリアージ機能のある脆弱性管理ツールがある」という情報が社員から共有されました。それが yamory だったのです。ちょうど課題を洗い出していた時期だったので、「これは良さそうだ」と思い、グループチャットで共有しました。

yamory についてさらに調べた結果、解決したい課題と yamory が持っている機能がマッチしていました。ただ、選定ポイントとして「運用に乗るかどうか」を懸念しており、それは田中さんも同じ認識でした。 そこで、しっかりと運用していけそうか、トライアルをすることで詳細を確かめました。その結果、懸念が払拭できたため導入を決定しました。

自動的かつ網羅的に脆弱性リスクを可視化、属人化問題を解決

―― yamory 導入の決め手や、導入後の効果・メリットについて教えてください。

田中氏：
yamory は、脆弱性を自動的に網羅してくれて、重要なものを絞り込んでリストアップしてくれることが大きなメリットでした。特にオートトリアージ機能は、重要度を独自のアルゴリズムで得点をつけて可視化し、その根拠も確認できますから yamory だけで一次トリアージが完結します。

また、社内では Jira を利用していたので、 Jira と連携登録できる機能があることも決め手の一つになりました。既存の運用や業務プロセスとの親和性が高く、運用に乗るイメージがつきました。

新沼氏：
ダッシュボードが非常に見やすいことも決め手の一つになりましたね。優先度を色分けして表示してくれるので、一目でざっくりと状況を把握でき、今何をすべきかがわかります。

また、今後のロードマップで、 OS レベルやコンテナイメージなどもトータルで見ることができるようになること、競合のサービスと比較して現実的な金額だったことも決め手になりました。

実際に導入した効果としては、脆弱性情報を手動で収集して重要度を判断していた業務が自動化され、属人化の問題を解消できました。次に、色と数値で重要度を可視化してくれるのでトリアージが非常に便利になりました。以前に挙がっていた課題は、 yamory で解決できたと考えています。

今後はもっと社内に働きかけて yamory のプレゼンスを上げていき、全てのプロジェクトに yamory を導入するなど、各チームの活用度を上げて完全に定着するような運用にしていきたいですね。

加えて、プロダクトセキュリティ部では、週に1回の運用の中で挙がった yamory に関する要望をまとめて、御社にフィードバックとして送っています。それをちゃんと機能開発して、反映していただいていることは非常に嬉しく思っています。

――昨年末にありました Log4j の脆弱性（ Log4Shell ）対策で yamory を活用できましたか？

新沼氏：
はい、 Log4j の脆弱性（ Log4Shell ）対策でも yamory を活用させていただきました。 Log4j はさまざまなソフトウェアに内在していて間接依存も多く検知が困難です。しかし、 yamory では間接依存の脆弱性も検知でき、横断検索機能で脆弱性のある Log4j の存在の有無を確認することができます。 yamory で網羅的にこの脆弱性の存在有無を確認でき、非常に助かりました。
※ yamory を利用した Log4Shell の対策はこちらをご参考ください。

定期的に yamory でスキャン、セキュリティ部でリスクを確認

――現在の活用状況について教えてください。

田中氏：
実際の運用は、 CI に組み込むかどうかといった細かい設定方法を含めて、現場に任せています。 GitHub リポジトリスキャンで定期チェックを行っているチームが多い印象です。 Scala の一部、 Android はコマンドラインスキャンを CI に組み込んでやっています。

各チームごとにアカウントが発行されており、プロダクトセキュリティ部のメンバーは全員、全チームの脆弱性を確認できるようにしています。また、プロダクトセキュリティ部の定常業務として週に1回 yamory が検知した脆弱性の棚卸しを実施しており、緊急度に応じて Jira でチケット管理しながらチームへ脆弱性対応の依頼をしています。

Chatwork ではバグバウンティも運用しており、その報告のトリアージや、海外からの攻撃のログを調査し IP ブロックなどの対策も一緒にしています。いずれはチームごとにセキュリティ担当者をつけて、横串で状況を見て全体最適のセキュリティ施策を講じていくようにしたいですね。

このほかにも、主要なプロダクトに関しては年に1回大規模な脆弱性診断を実施しています。また、コーポレート側の主導でリスクアセスメントも年に1回実施しており、これにはプロダクト側のメンバーも参加して、そこで出てきたプロダクトに関するセキュリティリスクは、私たちのチームで順次対応していく運用となっています。

yamory 導入の意図や運用フローをしっかり伝える

――現場へのツール導入が進まないことが、セキュリティ担当者の悩みの一つです。セキュリティ施策を進める上での課題や、それをどう乗り越えたのか教えてください。

田中氏：
これまでにいいツールだと思って導入しても、利用が広がらないケースを何回も経験してきました。そのため、ツールを導入する際には導入後の運用ルールをしっかりと定義し、説明会や勉強会を開催して現場の理解を得るようにしています。

yamory の導入の際にも、どのような機能があってどのような効果を見込めるか、何を目指したいのか、また運用フローについても説明しました。なるべく現場に負担がかからない形の運用フローを事前にプロダクトセキュリティ部側で設計し、それらを勉強会という形で共有できたことも、受け入れられやすかった要因の一つと考えています。

そのため、yamory に関してはすんなりと理解してもらえて、反発もありませんでした。これは、現場でも脆弱性対策の重要性を感じていたためだと思います。導入後もネガティブな意見はありません。

今後 yamory に期待すること

―― yamory に対して、今後望んでいることを教えてください。

新沼氏：
ライブラリレベルでは yamory で対応できていますが、プロダクションで使用しているミドルウェアでスキャンが難しいものに関して、バージョン管理、脆弱性の有無、OSレベルでの脆弱性検査は、まだ JVN などの情報をもとにアクションを決めている状態です。ここの分野でも yamory のようなツールを使って脆弱性を管理できることが理想と考えています。yamory のダッシュボード上で全て完結できるようになると嬉しいですね。

田中氏：
Chatwork は k8s（Kubernetes）を使ってアプリケーションサービスを運用していますので、コンテナ技術も広く浸透しています。一方で、コンテナ周りのセキュリティは世の中でもあまり出ていない領域だと感じています。yamory には、ぜひコンテナスキャンなどのコンテナに関する機能を追加していただきたいと期待しています。また Linux 以外では、Chatwork は AWS 上の Elastic Redis などを使っていますので、その辺りも集約して管理できるようになるといいですね。

企業に合った方法を考える専任担当者が重要

――最後に、脆弱性対策や脆弱性管理に悩んでいる担当者に向けてアドバイスやメッセージをお願いします。

田中氏：
セキュリティと運用はセットだと考えています。yamory を使って「どのようにセキュリティを向上させたいのか」ということと、「どういう組織にしたいのか」ということはセットです。企業はそこも意識しながら、セキュリティと付き合っていくのがいいと考えています。

僕たちも悩みながらチームを作って、yamory を導入して、やっとしっかりした脆弱性対策ができるようになりました。そこで感じたのは、「やるぞ」という気概がないと難しいということです。脆弱性対策をやらないという選択肢はないと思いますので、一定の工数は割くという認識は必要だと思います。それぞれの企業に合ったやり方があるはずだと思うので、まずそれを考える人が必要です。会社、部署としてセキュリティ専任の人を立てることがスタートだと思います。

新沼氏：
多分、私が今回 yamory を「いいな」と感じたことが導入につながる大きなモチベーションになったと思います。これを使えば課題を解決できるのではないか、明るい未来がありそうだと直感的に感じました。そのモチベーションが運用を設計して社内に展開することにつながりました。魅力を感じたサービスに共感をする人を少しずつ増やして、巻き込んでいく。それをいかにうまくできるかが、浸透させるポイントだと思います。

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