Product Security Summit 2024 Yappli

Transcript

1. マルチプロダクト化に伴うプロダクトセキュリ ティの転換とチャレンジ Product Security Summit 2024
2. 2018年に株式会社ヤプリへジョイン QAの立ち上げやテスト自動化推進などを経てSREを担当 現在はプロダクトセキュリティに限らず、全社のセキュリティ強 化をミッションとして各種取り組みを推進 自己紹介 望月　真仁 (もちづき　まさひと)
3. 単一プロダクトを育ててきたヤプリが、新たにYappli CRMをロー ンチしてマルチプロダクトを取り扱うようになり、発生した課題と取 り組みを紹介する 本日の話
4. 課題 取り扱う情報の重要性 実装・構築者の違い トレーサビリティ オブザーバビリティ 新たなクライアント層 セキュリティ要求
5. 最初は新しい事業における産みの苦しみや、スピード重視の別側 面かと考えた 考察
6. いやマルチプロダクトになったことによる問題ではなく、そもそもの 事業拡大に伴う組織課題ではないか🤔 仮説
7. 推進者が決まる まず最初に セキュリティ推進者：私
8. 各領域との連携 アプリケーション • Webアプリケーションの脆弱性対策 • Mobileアプリケーションの脆弱性対策 • セキュアコーディング支援 • ペネトレーションテスト・静的解析 サービス・インフラ • AWSのセキュリティ対策 • Google Cloudのセキュリティ対策 • 脆弱性診断・ペネトレーションテスト • 開発用SaaSのセキュリティ対策 SOC/CSIRT/PSIRT • セキュリティ監視・SIEM • アラート検知・インシデント対応 • フォレンジック • 社内外窓口 情報セキュリティ • 全社用SaaSのセキュリティ対策 • 社内ネットワークのセキュリティ対策 • ISMS・Pマークの運用 • セキュリティチェックシート対応 サーバー・フロント ・iOS・Androidエンジニア SRE SRE →セキュリティエンジニア コーポレートIT(情シス) セキュリティ推進者 →セキュリティエンジニア
9. サイクルを回す 具体的なアプローチ 共有 議論 可視化 対策 仕組み化 振り返り 分析
10. フレームワークを利用して、現状を振り返って分析する • ✅ フレームワークを併用する ◦ ISMS、CIS Controls v8、AWS Well-Architected Framework ◦ 例えば権限管理で、あるフレームワークでは OKとなるが、別フレームワークでは NGとなる ◦ フレームワークの特性、適用範囲等をうまく組み合わせる • ✅ プロダクト軸・組織軸など多角的に評価する ◦ Yappliではできているが、Yappli CRMではできていない ◦ 開発部ではできているが、営業部ではできていない ◦ 脆弱な箇所を狙われないよう全体のベースアップを意識する • ✅ 複数名でやる ◦ ある人はできていると言い、またある人はできてないと言う ◦ 各人の視界・持っている情報をすり合わせて、組織としての共通認識を持つ 振り返り・分析
11. ツール・サービスを利用して、セキュリティ状況を可視化する • ✅ なるべく自社リソースを使わない ◦ CSPM、SIEM、EDR等を導入して自動でリアルタイムに情報更新する ◦ 貴重なセキュリティエンジニアが重要な業務に集中できる環境 • ✅ マニュアルの観点も取り入れる ◦ 第三者による脆弱性診断を受ける ◦ セキュリティエンジニアによる社内視点でのテストもする ◦ ベンダーナレッジ・社内ドメイン知識・セキュリティトレンド等の様々な観点を組み合わせる • ✅ セキュリティダッシュボードを作る（To Be） ◦ セキュリティチームの定例で毎回チェックする ◦ 非セキュリティエンジニアでも組織のセキュリティ状況がイメージできる 可視化
12. 共有・議論 同じ目線で議論できるよう、日頃から継続的な共有を意識する • ✅ エンジニアが集まる技術共有会でセキュリティコンテンツを提供する ◦ ランサムウェアとは何か ◦ 脆弱性情報(CVSS)の見方〜緊急対応が必要な可能性があるのはどんなとき？〜 ◦ 脆弱性診断〜結果とかもろもろ〜 • ✅ Shisho Cloudを活用したコミュニケーション ◦ 検出結果に対して「どのようなリスクがあるのか」「どう対処すれば良いのか」をインフラエンジニア とセキュリティエンジニアが同じ言葉で話せる ◦ SREとセキュリティエンジニアのギャップを埋める「コミュニケーションツール」として Shisho Cloudを活用 • ✅ 振り返り資料を元にサービス・ツールベンダーのエンジニアと議論する ◦ 専門的な立場から運用やセキュリティ向上のアドバイスももらえる（知らなかったが実は有用な機能 があった等） ◦ 自社の課題解決に繋がるリリースがあった際や、他社事例の紹介などをしてもらいやすい
13. エンジニアによるセキュリティ対策を後押ししながら、組織全体としてもセキュリティを日 常的に意識ための仕掛けをする • ✅ 上位レイヤーへ定期的にレポートする ◦ 週次で部長レイヤー以上にインシデント・ヒヤリハット発生状況を報告している ◦ ISMS・プライバシーマークの各イベント・内部監査等をうまく活用する • ✅ 相談窓口を設置してアピールする ◦ セキュリティ組織が元々なかった関係もあり、相談先が明確になって知ってもらうことで様々な相談 が来るようになった ◦ 反対にそれまではプロジェクトや個人に閉じてセキュリティの判断がされるリスク • ✅ セキュリティとプライバシーの間を埋める ◦ 明確な線引きが難しいケースもあって間にボールが落ちやすい ◦ 法務・セキュリティチームで定例 MTGを設けて、お互いの問い合わせ共有や相互アドバイスをして いる 対策・仕組み化
14. まとめ ヤプリはマルチプロダクト化→事業拡大に伴うセキュリティ課題に 立ち向かうため • セキュリティの推進者を明確に定めて • 振り返り・分析→可視化→共有・議論→対策・仕組み化のサイ クルを継続的に回し • 組織全体でセキュリティを考えていく土台を作っている