SOC2取得の全体像

SOC2ゆるミートアップ - SOC2取得済み企業LT会 - イベントページ https://security-compliance.connpass.com/event/366743/

イベントレポート https://note.primenumber.co.jp/n/n94d2792bf5be

Transcript

1. 2025/10/1 SOC2 ゆるミートアップ SOC2取得の全体像 株式会社スマートラウンド 山原 崇史(@shonansurvivors)
2. 自己紹介 株式会社スマートラウンド 執行役員VP of Reliability 山原 崇史 (やまはら たかし)　 経歴等 ・金融系SIer → 銀行 → ベンチャー数社 → 現職 ・SRE / コーポレートIT / セキュリティの領域を担当 ・2023〜2025 Japan AWS Top Engineers 社外コミュニティ活動 ・AWS Startup Community (aws-startup-community.connpass.com) ・Security Compliance Lounge (security-compliance.connpass.com) @shonansurvivors
3. 会社および事業紹介 株式会社スマートラウンド ・2018年設立 ・従業員数約45名のスタートアップ ミッション スタートアップが可能性を 最大限に発揮できる世界をつくる プロダクト「smartround」 ・スタートアップ導入数 7,000社 ・投資家導入数 4,300人 さらなる取り組み（子会社にて） 未上場株式のセカンダリー取引の プラットフォーム実現に向けて準備中
4. セキュリティへの取り組み SOC2 Type2報告書 米国公認会計士協会（ AICPA）の定めるトラストサービス規準に基づき、セキュリティ・可用性・処理の完 全性・機密保持・プライバシーに関する内部統制の適切性および有効性を監査法人が作成した報告書 にてご確認いただけます。 ISO/IEC 27001（ISMS認証） 情報セキュリティマネジメントシステムに関する国際標準規格である ISO/IEC 27001(ISMS)の認証を取 得しています。ISMS委員会やマネジメント（経営層）レビュー、内部監査等を定期的に実施し、情報セ キュリティの向上に組織全体で取り組んでいます。 AWS認定ソフトウェア AWSのパートナーソリューションアーキテクトによるレビュー (FTR)を通過し、セキュリティ・信頼性・運用 上の優秀性に関して AWSのベストプラクティスに従っていることが確認された AWS認定ソフトウェアと なっています。
5. 本日共有したいこと 現状 • SOC2を解説した情報はWebで検索すれば様々見つかります • ただし、それらは監査法人やコンサルタントの目線のことが多い 共有したいこと • 現場の情シス / コーポレートIT、開発・運用エンジニア目線での、 SOC2取得の全体像 お断り • 発表者のSOC2取得経験は所属1社のみなので、観点に抜け漏れや偏りがある可能性があります • また、所属はSaaS企業であり、データセンター（※）における SOC2取得の知見はありません ※さくらインターネットさんなどがデータセンターの領域でSOC2を取得済み
6. アジェンダ 1. SOC2概要 2. SOC2取得の全体像 3. 個別詳細 4. おわりに
7. 1. SOC2概要 • クラウドサービス提供企業が、自社サービスの監査を監査法人に依頼 • 監査結果は報告書にまとめられ、サービスを利用検討中・利用中の企業が参照する 1. 自社サービスの 監査を依頼 2. サービスを監査 監査 報告書 3. 報告書の提供を 依頼 監査法人 クラウドサービス 提供企業 サービス 利用検討中・利用中 の企業 監査 報告書 4. 報告書を提供 5. 報告書を見て セキュリティ を評価 監査 報告書
8. 2. SOC2取得の全体像 職種・役割をベースに、各対応事項を登壇者が独自に分類 横断的なもの 情シス / コーポレートIT 開発・運用エンジニア 人事・労務 ・ポリシー作成と同意取得 ・データ分類 ・リスクアセスメント ・NWセキュリティ ・アクセス管理 ・ベンダー管理 ・インシデント対応訓練 ・災害復旧訓練 ・事業継続訓練 ・経営陣へのリスク報告 ・サービスの利用規約 ・プライバシーポリシー ・資産（機器）管理 ・PC等のセキュリティ ・セキュリティ教育 ・エンジニア職務記述書 ・(サービスの)データ保護 ・(サービスの)データ維持 ・暗号化 ・バックアップ ・ロギングと監視 ・バージョン管理 ・セキュアコーディング ・コードレビュー ・テスト ・脆弱性管理 ・ペネトレーションテスト ・組織図 ・従業員評価プロセス ・雇用契約書
9. 3. 個別詳細 1. ポリシー作成と同意取得 2. 自社サービスのセキュリティ実装 3. アクセス管理 4. データ分類 5. リスクアセスメント　 6. ベンダー管理 7. インシデント対応/災害復旧/事業継続訓練 8. 取締役会へのリスク報告 9. サービス利用規約とプライバシーポリシー 10. 資産（機器管理）とPC等のセキュリティ 11. セキュリティ教育 12. 脆弱性管理 13. ペネトレーションテスト 14. 人事・労務領域 ・本発表では、1〜3までは詳細に説明します ・4以降は概要かつ時間が足りないため説明はスキップします ・スキップした項番は後ほど資料をご確認ください 🙏
10. 3.1 ポリシー作成と同意取得 ポリシーとは、社内のセキュリティ方針を定めた 文書で、社内規程に相当するもの ※ここでは、社外に公開するプライバシーポリシーや情報セキュリティ方針は含みません 取り扱うテーマ ・アクセス管理 ・パスワード ・データ分類 ・データ保護 ・データ維持 ・バックアップ ・暗号化 ・ロギングと監視 ・資産管理 ・NWセキュリティ ・情報セキュリティ ・情報システム利用 ・リスク管理 ・ベンダー管理 ・ソフトウェア開発 ・変更管理 ・脆弱性管理 ・インシデント対応 ・事業継続計画 ・災害復旧計画 等
11. ポリシーをどう作成するか • SOC2の規準自体は抽象的で、これを元に ゼロから自分たちでポリシーを作成するのは困難 • 支援コンサルや支援ツールから提供される テンプレートをカスタマイズして使うのが現実的 • セキュリティ関連の社内規程が既にある場合は、それらを使えば良い（足りない部分は追記する）
12. ポリシー作成後に行うこと • 役員や従業員にポリシーを読んでもらい、ひとりひとり内容に同意してもらう ◦ Webサービスの利用規約に同意してもらうのと同じようなイメージ ☑ • 開発関連ポリシーはエンジニアにだけ同意してもらうなど、 ポリシーごとに対象を絞って構わない
13. 登壇者がこだわったところ • テンプレートそのままだと、会社のカルチャーや慣習からかけ離れたものとなってしまう • 従業員にとって違和感の大きいものを読ませて同意取得したくはないので 極力カスタマイズした • ただし量が多いので、 100%納得行くまでカスタマイズするのは 時間がいくらあっても足りない • ポリシーは年次での見直しも求められるので、継続的に改善していく
14. これからSOC2取得を目指す方へアドバイス • 必要に応じて各ポリシーに関わる職種に参画してもらうこと ◦ 例えば、SOC2推進担当者となったあなたが情シス / コーポレートITだったら... 👉ソフトウェア開発ポリシーの作成には、開発エンジニアに参画してもらう • 実態にそぐわない、運用しづらいポリシーが出来上がってしまうことを防ぐ
15. 3.2. 自社サービスのセキュリティ実装 以下の線で囲った範囲を「自社サービスのセキュリティ実装」と総称することとします 横断的なもの 情シス / コーポレートIT 開発・運用エンジニア 人事・労務 ・ポリシー作成と同意取得 ・データ分類 ・リスクアセスメント ・NWセキュリティ ・アクセス管理 ・ベンダー管理 ・インシデント対応訓練 ・災害復旧訓練 ・事業継続訓練 ・経営陣へのリスク報告 ・サービスの利用規約 ・プライバシーポリシー ・資産（機器）管理 ・PC等のセキュリティ ・セキュリティ教育 ・エンジニア職務記述書 ・(サービスの)データ保護 ・(サービスの)データ維持 ・暗号化 ・バックアップ ・ロギングと監視 ・バージョン管理 ・セキュアコーディング ・コードレビュー ・テスト ・脆弱性管理 ・ペネトレーションテスト ・組織図 ・従業員評価プロセス ・雇用契約書
16. ざっくり2領域に分類 • NWセキュリティ • データ保護 • データ保持 • 暗号化 • バックアップ • ロギングと監視 • バージョン管理 • セキュアコーディング • コードレビュー • テスト インフラや運用寄りの領域 ソフトウェア開発ライフサイクル寄りの領域
17. インフラや運用寄りの領域 クラウドプロバイダのベストプラクティス （※）に沿ってセキュリティを高めると、 SOC2準拠に近づく テーマ 対応事項の例 NWセキュリティ パブリック/プライベートサブネット分割、 FW、TLS、WAF、IDS/IPS、等 データ保護/維持/暗号化 ブロックパブリックアクセス、マルウェア検知、バージョニング、暗号化、鍵管理、等 バックアップ バックアップ、定期的なリストアテストの実施、等 ロギングと監視 監査ログを始めとする各種ログ取得、ログやメトリクスの監視とアラート、等 ※AWSであれば、Security Hub CSPMなどで求められる内容
18. ソフトウェア開発ライフサイクル寄りの領域 ポリシー化（規程化）した 組織のソフトウェア開発ルールに沿ってしっかりと運用し、証跡も残す テーマ 対応事項の例 ・バージョン管理 ・VCS（GitHub等）を使用してコードを管理する ・ブランチやタグのルールを整備し、運用する 等 ・セキュアコーディング ・コードレビュー ・テスト ・セキュリティの観点を含むコードレビューの標準を定め、運用する ・コードレビューの承認や CIの合格を必須とする ・本番リリースまでの適切なタイミングで QAを実施する 等
19. 3.3. アクセス管理 前提 • 以下の両面を考える必要がある ◦ 顧客からの、自社クラウドサービスへのアクセス ◦ 従業員からの、業務・開発・運用等で利用する各システムへのアクセス やること • 顧客にはセキュアな認証方式や、権限のオプション（例：管理者 /担当者等）を用意する • 従業員についてはセキュアな認証方式の利用や最小権限原則のほか、 アカウントを適切に管理する
20. アカウント管理の深掘り 特に重視されること • 退職などに伴うアカウントの削除 （Offboarding） • 定期的なアカウントの棚卸し （Access Review） 対応のポイント • やるべきことを文書化 し、適時に漏れなく実施 し、その証跡を確実に残す
21. 3.4. データ分類 やること • 情報資産を重要度に応じて分類（※）し、適切に取り扱う ※公開、社外秘、機密、など ISMSとの関連性 • ISMSで既に実施しているのであれば、それをもって実施済みとすることは可能かもしれない ◦ ISO / IEC 27001 附属書Aの以下に相当 ▪ 5.12 情報の分類 ▪ 5.13 情報のラベル付け
22. 3.5. リスクアセスメント やること • 自組織のリスクを洗い出し、発生可能性と影響度からリスクスコアを付ける • リスクの高いものから優先的に対応を検討する（リスク回避 /軽減/移転/受容 等） ISMSとの関連性 • ISMSで既に実施しているのであれば、それをもって実施済みとすることは可能かもしれない ◦ ISO / IEC 27001 箇条8.2 情報セキュリティリスクアセスメント に相当 • ただし、ISMSで実施しているリスクアセスメントが全社的な ITだけにフォーカスし、 SOC2対象の自社サー ビスの開発や運用に触れられてないのであれば、追加的に実施すべき
23. 3.6. ベンダー管理 やること • 自社サービスの開発や運用に関わるベンダーのリスクを管理する ◦ ここでのベンダーの例としては以下のようなもの（サードパーティといった方が適切か） ▪ インフラ：AWS、Azure、Google Cloud、Cloudflare、さくらのクラウド、等 ▪ 監視：Datadog、New Relic、Mackerel、等 ▪ バージョン管理：GitHub、GitLab、Azure DevOps、等 ▪ メールサービス：SendGrid、Mailgun、等 • 新規導入検討時および導入後は定期的に以下を実施 ◦ 自社セキュリティポリシーを満たしているかチェック ◦ ベンダーをリスクアセスメント（停止時影響や、預けている情報資産の重要度などを考慮） ◦ ベンダーがSOC2を取得済みであれば、その SOC2報告書をレビューする
24. 3.7. インシデント対応/災害復旧/事業継続訓練 やること • 定期的にインシデント対応訓練、災害復旧訓練、事業継続訓練を行う • 訓練の目的や参加者の習熟度合いに応じて実施形式を選択 ◦ ウォークスルー（手順や計画を順番に確認） ◦ 机上演習（シナリオに基づき議論、検討） ◦ シミュレーション（本番相当環境などの実際のシステムを使って模擬的に行う）など ISMSとの関連性 • ISO / IEC 27001 附属書A 5.30 事業継続のためのICTの備えに相当
25. 3.8. 取締役会へのリスク報告 やること • 取締役会規則に、定期的にセキュリティリスクとその軽減戦略について協議を行う旨を規定する • 上記規定に沿って、定期的に会を実施する • 会の議事録には決定事項やアクションアイテムを記載する ISMSとの関連性 • ISMSで既に実施しているのであれば、それをもって実施済みとすることも可能と思われる ◦ ISO / IEC 27001 箇条9.3 マネジメントレビューに相当 • ただし、会では全社的な ITだけでなくSOC2対象の自社サービスの開発や運用に充分に触れるべき • なお、ISMSでの「トップマネジメント」は必ずしも取締役（会）であることまでは求められていないので、その 点でSOC2の方が実施のハードルは高い
26. 3.9. サービス利用規約とプライバシーポリシー やること • 自社サービスの利用を開始するユーザーから利用規約とプライバシーポリシーへの同意を取得する • 利用規約とプライバシーポリシーを定期的に見直す ◦ 改定有無を検討する機会を定期に設けることが大切で、改定そのものは必須ではない • プライバシーに関する問い合わせや苦情の受付窓口を設ける • そもそも論として、プライバシーに関しては個人情報保護法を遵守する ISMSとの関連性 • プライバシーについては、 ISO / IEC 27001 附属書Aの以下に相当 ◦ 5.34 プライバシー及び個人識別可能情報（ PII）の保護
27. 3.10. 資産（機器管理）とPC等のセキュリティ やること • MDMなどでPC等のデバイスを管理する • PC等のデバイスに関連するセキュリティ向上施策を行う ◦ アンチマルウェア、ストレージ暗号化、無操作後のスクリーンロック、等 ISMSとの関連性 • ISMSで既に実施しているのであれば、それをもって実施済みとすることも可能と思われる ◦ ISO / IEC 27001 附属書Aの以下に相当 ▪ 6.7 リモートワーク、7.9 構外にある資産のセキュリティ ▪ 8.1 利用者エンドポイント機器、 8.7 マルウェアに対する保護、等
28. 3.11. セキュリティ教育 やること • 入社時点やその後に定期的に、従業員のセキュリティ意識を向上させるための研修やテストを行う ISMSとの関連性 • ISMSで既に実施しているのであれば、それをもって実施済みとすることも可能と思われる ◦ ISO / IEC 27001 箇条7.2 力量や、附属書A 6.3 セキュリティ意識向上、教育及び訓練 に相当 • ただし、開発エンジニア向けのセキュアコーディングのトレーニングは、このセキュリティ教育とは別枠で 実施するべき
29. 3.12. 脆弱性管理 やること • 外部から脆弱性情報を収集する • 組織が利用するITリソースの脆弱性を検出し、評価する • Criticalは何日以内、Highは何日以内に対応、といったポリシーを定め、対処する ISMSとの関連性 • ISMSで既に実施しているのであれば、それをもって実施済みとすることは可能と思われる ◦ ISO / IEC 27001 A 8.8 技術的ぜい弱性の管理 に相当 • ただし、全社的なITだけにフォーカスし、 SOC2対象の自社サービスに触れられてないのであれば、追加 的に実施すべき
30. 3.13. ペネトレーションテスト やること • 独立した第三者機関によるペネトレーションテスト（※）を、定期的に、またはインフラやアプリケーションの 重大な変更後に実施する ※ ペネトレーションテストの定義や考え方は、以下の資料が参考になります • LAC WATCH 脆弱性診断とペネトレーションテストの使い分け ◦ https://www.lac.co.jp/lacwatch/service/20201112_002314.html • IPA 脆弱性診断内製化ガイド p14 コラム ～脆弱性診断とペネトレーションテストはどう違うの？～ ◦ https://www.ipa.go.jp/jinzai/ics/core_human_resource/final_project/2025/Vulnerability-assessment.html
31. 3.14. 人事・労務領域 やること • 経営陣などの上級管理層は、組織を適切に構成、管理する • 経営陣などの上級管理層は、人員を適切に育成、評価する • これらを示す証跡として以下を求められる可能性あり ◦ 組織図、雇用契約書テンプレート、従業員評価プロセス、エンジニア職務記述書、等 ISMSとの関連性 • ISMSで既に実施しているのであれば、それをもって実施済みとすることは可能かもしれない ◦ ISO / IEC 27001 附属書A 6. 人的管理策 に相当
32. おわりに SOC2取得にあたり、どのようなことをやれば良いのかのイメージを伝えることはできたでしょうか？ 本発表内容、本資料が SOC2取得を目指す際の参考になれば幸いです。
33. JOIN US! jobs.smartround.com