Chatwork Creator's Note

ビジネスチャット「Chatwork」のエンジニアとデザイナーのブログです。

ビジネスチャット「Chatwork」のエンジニアとデザイナーのブログです。

読者になる

プロダクトセキュリティ部のマネージャを卒業しました

卒業式にアルバムを見ながら学生時代を振り返って泣いている男子学生のイラストです。

こんにちは!Chatwork株式会社 プロダクト本部 副本部長の田中(@tan_yuki)です。

(まずは宣伝が入ります )

2022/10/07(金) に、弊社 Chatwork が主催するオンラインカンファレンス『Chatwork Product Day 2022』が開催されます 🎉 興味のある方はぜひ、参加してください。

lp.chatwork.com

(宣伝おわり )

最初に、タイトルに「卒業」と書いていますが、退職したわけではありません。 最近までプロダクトセキュリティ部という部署のマネージャを兼任していたのですが、別の方に引き継ぎ、私はプロダクトセキュリティ部から卒業しました。もともと自分で立ち上げたチームでもあり、いろいろと感慨深いものがあります。

ひとつの区切りとして、今回はこれまでどのような活動をしていったのかをまとめます。どうセキュリティチームを立ち上げて、何をしてきたのか?の軌跡をつらつらと書いていきます。

プロダクトセキュリティ部が発足するまで

少しだけ昔話をします。

Chatworkがサービスとしてローンチされたのは2011年です。サービスとしては10年以上継続して運営していることになります。 リリース初期の頃から考えると、サービス規模・組織規模・ユーザー数、とてつもない成長をしています。

さらに、2019年9月にマザーズ上場をしています。 上場する前からも、サービスの影響度から社会的責任は強く感じていたのですが、上場というイベントを経過し、その責任の度合いがさらに増した感覚がありました。

そこで、気になっていたことの一つが "セキュリティ" です。

このころ、海外からサイバー攻撃と思われるリクエストが続いており、頻度が増してきていました。 調査や防御施策を現場エンジニアに対応してもらっていたのですが、どうしても片手間な対応にならざるを得ません。 彼らもチームのミッションがあるので、そちらが優先になることは仕方のないことでした。

開発組織の外にセキュリティを見る組織はあったのですが、どちらかというとコーポレートセキュリティが中心なため、プロダクトに対するセキュリティ施策は開発側が見ている状況でした。

このような状況により、プロダクトに特化したセキュリティ部隊の必要性を痛感しており、2020年に私から提案して立ち上げました。

詳しい話は下記ブログにもまとめているので読んでみてください。

creators-note.chatwork.com

その後、どんな活動をしていったか?

最初は私含めて社員2名でスタートしました。

立ち上げたはいいものの、2人とも専門分野はセキュリティではなく、セキュリティについての深い造詣はありません。 専門家の人に話を聞きたいよね、ということで、セキュリティコンサルの方にアドバイスをいただきながら施策を進めていくことにしました。

運良く、私の知人の紹介で、今のチームや課題感にフィットしたセキュリティコンサルの方と契約でき、定期的に相談できる環境を作ることができました。

最初は組織のセキュリティに関するリスクがどれくらいあるかを把握し、課題をリストアップしました。 その後は、リスクや組織としての重要度など、いくつかの観点から優先度を決めて対応していきました。

具体的な対応施策

具体的には、以下のような施策を実施していきました。

  • 定期的な全体のセキュリティスキャンの実施(外部ベンダーの選定)
    • 現在では年1回 セキュリティスキャンをするような運用を構築できました
  • プロダクトに関する情報資産の重要度の分類
    • 上記に基づく、極秘情報の取り扱いに関する取り決め
  • ログ要件
  • 暗号化要件
  • プロダクトセキュリティ相談所の設置
    • エンジニアから気軽にセキュリティの相談ができるような場所の提供
  • etc...

上記施策を対応するにあたって、プロダクトセキュリティチームが門番にならないことを意識していました。

「これをしたらだめ」「あれをするな」ではなく「こういった考え方でやっていきましょう」というガイドラインになるように徹底しました。 ルールをガチガチに作って守ることを強制してしまっては、チームの主体性がなくなってしまい、自分たちでセキュリティについて向き合わなくなるのではないか?と考えたからです。 「セキュリティはセキュリティチームに任せよう」という思想ではなく、チームが主体的にセキュリティを考えてくれるよう意識しました。

そのため、セキュリティに関するガイドラインを作るときはWhyを厚めに書くことを意識しました。Chatworkには "ADR(Architectural Decision Records)" を書いていこうという文化が一部にあり、そちらを模倣してチーム内でも活用していました。

ADRの例

ADRとはなにか?については下記の豆蔵さんのブログ記事がわかりやすかったので参照してみてください。

developer.mamezou-tech.com

現在のプロダクトセキュリティ部

もともとは、先程も書いたとおり私含めて2名のみのチームだったため、部署化はしていなかったのですが、セキュリティの運用業務を対応してくれるアシスタントポジションの方に1名入っていただき、合計3名になったタイミングで部署化しました。

その後、なんとセキュリティに造詣の深い、セキュリティつよつよ人材の採用に成功し、4名のチームになりました。

この、セキュリティに強い方の採用が決定できたことをきっかけに様々なことが進み始めました。

いままでは、チームにセキュリティバックグラウンドがあるわけではなかったので、なにか意思決定するにしても、そこまで自信をもって決定できなかったり、セキュリティコンサルの方に都度相談したりしていました。 そういった状況が、チーム内で自信をもって意思決定できたり、施策が多く回せるようになりました。 彼が持っている知見をチームや開発チーム全体に還元することで、組織全体もセキュリティに強くなった気がします。

今後のプロダクトセキュリティ部

体制が整いつつある、という状況ではあるのですが、まだまだやりたいことに対して人が足りていない状況です。

特に、今後はプロダクトセキュリティだけでなく、会社全体のセキュリティについて考えていく必要があると考えています。 いまはプロダクトセキュリティ、コーポレートセキュリティがチームとして分かれていますが、それが適切なのかどうか?など組織についても考えることがあります。

プロダクトセキュリティに閉じた話だけでも、まだ我々はシフトレフトなセキュリティ体制はできておらず、都度都度セキュリティチームが関わりながら外から支援する形になっています。 今後はもっと各開発チームと深く関わっていき、設計段階からセキュリティについても考えられるような体制を作っていきたいと考えています。

ゆくゆくは、DevSecOpsのような体制を構築していくことを目指していきたいです。

マネージャを卒業する背景

私がなぜマネージャを卒業するのか?ですが、単純に私の役目がもう終わったかなと感じたためです。

プロダクトセキュリティ部は私がいなくてもほぼ自走していける組織だと思っていますし、実際に最後の方は、ほぼピープルマネジメント業務のみをやっている状態でした。 このような強い組織をつくれたことは、私としても非常によい経験になりました。メンバーの方々にとても感謝しています。

最後に、言いたいこと

なんだかまとまりのない文章になってしまいました。とにかく、私がお伝えしたかったことは以下です。

  • 組織立ち上げに必要なのは情熱と覚悟のみ(あと、経営側の理解)
  • ラッキーパンチではあるが、採用難易度が高いセキュリティ人材を採用ができた
  • ラッキーパンチができたのも「プロダクトセキュリティ部」という箱があったおかげ

セキュリティという組織機能は程度の差はあれ、どんな組織にも必須の機能だと考えています。 ただ、セキュリティ人材は現状取り合いの状況で、人材の確保、組織の立ち上げは非常に難易度の高いものとなっているはずです。

今回のブログが、セキュリティ組織を立ち上げたいと思っている人たちの参考になれば幸いです。

...また、採用も募集中です。 Chatworkでは、中小企業のビジネスを支えるビジネスチャットツール「Chatwork」のセキュリティ確保にむけて一緒に挑戦してくれる仲間を募集中です。

hrmos.co

その他、全方面で採用募集中です!ご応募お待ちしております。

recruit.chatwork.com

カジュアル面談も受け付けております!TwitterのDMより気軽にお声がけください。