MNTSQ社内勉強会 #2 PdMも知っておきたいSaaS事業のセキュリティ.pdf

Transcript

1. PdMも知っておきたい
 SaaS事業のセキュリティ
 MNTSQ Product Management 社内勉強会 2022.03.25 #2
2. MNTSQ 2 今日のお話：
 • SaaS事業を運営する際につきものの
 「セキュリティ」について、セオリーを一望したいです
 • また、僭越ながら
 「筆者が実体験したセキュリティインシデント」を紹介します
 ◦ ※書いて大丈夫そうなもの２件をセレクトしました

3. MNTSQ 3 こんなにある！SaaS事業のセキュリティ業務
 A. 品質管理 - SLA: Service Level Agreement - QA: Quality Assurance B. セキュリティ対策 - セキュリティポリシー - ISMS: Information Security Management System - 脆弱性診断 C. 保守体制 - システム監視 - ヘルプデスク

4. MNTSQ 4 A. 品質管理
 • 「製品が期待通り利用できるか」の話 • 「可用性（システムダウンしていない）」と「品質（正しく動く）」の観点がある - SLA: Service Level Agreement - 「サービス品質」ついての提供者ー利用者間の合意書 - 元々は通信業界のもの。「通信品質が〜を下回った場合の補償〜」 　- Webサービスでは「ダウンタイム／レスポンスタイム」に置き換えられる - サポート体制のすり合わせが含まれる場合もある - QA: Quality Assurance - 品質保証。「製品が仕様通りに動く（＝バグがない）」の精度 - RT: Regression Test （回帰テスト）を行う - 全ての機能を一通り操作し、挙動がおかしくなった箇所を見つけ出す

5. MNTSQ 5 B. セキュリティ対策
 • 「システムの不正利用についての対策」の話 • 不正利用とは？ ◦ 金銭的被害／情報漏洩、改ざん／ なりすまし、踏み台／業務妨害 ◦ SaaSはクライアントの業務に組み込まれるため、信用失墜に直結し得る - セキュリティポリシー - 運営側のセキュリティ方針をまとめたもの - toBの場合「セキュリティチェックシート」の形ですり合わせる形が多い - ISMS: Information Security Management System - 組織の情報統制についての取り組み（＝文書化、遵守、監査） - ITシステムの話ではなく、組織（スタートアップの場合、ほぼ会社）の話 - 「定義したISMSをちゃんと運営しています」という認証を受けるのが常套 - 「ISMSの内容が高い水準かどうか」は別の話であることに注意 - 脆弱性診断 - システム上の脆弱性を洗い出す（および対応する）ことが目的 - セオリーでは「定期診断」と「スポット診断」で実施される
6. MNTSQ 6 C. 保守体制
 • 「なにかあったときの対応」の話 • 当然、手厚いほどコストがかかる - システム監視 - 24×365 が基本 - 異常発生 -> 機械検知 -> 担当へ通知 の流れ - 担当へ通知された場合どうするか、の運用整備が肝心 - 判断／緊急対応作業、告知／報告 - 24H使われるサービスの場合：即時復旧が求められる - 日中のみ使われるサービスの場合：比較的余裕あり（※朝までまだ時間ある） - ヘルプデスク - 営業時間内対応 - 24H対応オプションありのサービスもある（Upselling） - カスタマーサポート ／ カスタマーサクセス の住み分けと混在 - ハイタッチ ／ ロータッチ ／ テックタッチ ／ コミュニティタッチ の使い分け
7. MNTSQ 7 まとめ
 • 全部を完璧には対応できない ◦ SaaS事業者は「セキュリティ事業者」ではない • しかし障害は起こせない ◦ 特に「情報漏洩」は事業／会社の存続に関わる • 「何を優先し、何を後回しにするか」の判断が必要 ◦ そのためにも、正しい情報と知識を揃える 

8. MNTSQ 8 ケーススタディ

9. MNTSQ 9 ケーススタディ１：セキュリティインシデント (1/2)
 • 「会員制のポイント保有サイト（toC）」があった ◦ ポイント＝実質の貨幣価値がある ◦ 会員制＝個人情報を登録する ◦ バックヤードで他企業とのデータ連携あり • Webサイトのログイン画面を、立ち上げ当時のまま数年間使用していた • 定期脆弱性診断を「対外姿勢のために」実施していた ◦ 指摘内容を適切に対応していなかった 

10. MNTSQ 10 ケーススタディ１：セキュリティインシデント (2/2)
 • ログイン画面にブルートフォース攻撃を受けた ◦ 異常検知の仕組み／体制を後回しにしていた ◦ 祝、土、日の３日間、攻撃を受け続け、千件以上が攻撃成功 ◦ 運営組織が検知したのは月曜午前（＝翌営業日） • 結果的に、千件超の個人情報漏洩、数百万円のポイント盗難が発生 ◦ 盗難されたポイントは、運営組織で補填 ◦ 個人情報の漏洩による信用失墜の方が被害が大きかった ◦ 実被害者、および全会員へのサポート ◦ 連携企業への報告 ◦ 親会社への報告 ◦ まる一週間のサービス停止、および突貫のシステム対応
11. MNTSQ 11 ケーススタディ２：保守レベルの読み誤り　(1/2)
 • とある事業者にて、社内向け業務システムを運営していた • 社内での評判が良かったので、他社にも販売することにした ◦ toB_SaaS化 • 当初、クライアントは平日日中帯にのみSaaSを利用していた ◦ 保守レベルも平日日中帯のみ（＝エンジニアチーム対応）を想定 • クライアントの幅を広げた ◦ その中に「フリーランスメンバーが24H365D働く業種」があった ◦ 利用開始後に発覚

12. MNTSQ 12 ケーススタディ２：保守レベルの読み誤り　(2/2)
 • なし崩し的に「24H保守対応」の状況が発生 ◦ エンジニアチームに直接負荷がかかる ◦ 保守体制を24H化するにはコスト／期間がかかる ◦ SaaS費用に保守費を後出しで転嫁するのは難しい • 最終的に「身動きの取れない状態」に陥った ◦ 夜間障害の対応でエンジニアチームが疲弊 ◦ クレーム対応でカスタマーサポートが疲弊 ◦ 新規機能開発（顧客個別案件）が進められない状態に

13. MNTSQ 13 最後に：
 • 事故を賢く避けよう
 • 障害の優先度とボーダーラインを設定しよう
 • 予防策を立て、実施しよう
 • 起きた場合の想定を立てよう
 • 事業の状況を正確に把握しよう