最大の顧客は進む準備が整っています。セキュリティレビューが始まり、購入者は質問紙を送りますが、1 つのアイテムが契約を凍結させるのは「SOC 2 報告をご提供ください」という質問です。
組織はその時点でSOC 2 認定とは何であるかを探し始めます。通常、バッジ、シンプルなパス、チェックリストを期待しますが、実際には証明手続き、証拠要求、ソフトウェアを迅速に配信することがアウディットのストーリーになることを実際に実行することになります。
SaaS とモバイルチームにとって、難しい部分は用語を学ぶことではなく、開発フローを構築することです。エンジニアが code をマージする、シークレットを回転させる、コントラクターをオンボードする、毎週更新を実行するなど、開発フローが監査可能なままになるようにすることです。
目次
- SOC 2 認定の重要性
- 信頼できる 5 つの基準を理解する
- SOC 2 Type I と Type II 報告の違い
- SOC 2 検査プロセスをナビゲートする
- 実践におけるSOC 2 コントロール
- SOC 2、ISO 27001、HIPAA の比較
- SOC 2 の準備チェックリスト
SOC 2 認定とはなぜ重要か
多くのチームは、販売プロセスで初めてSOC 2に遭遇します。設計計画の時ではなく。
パターンはよく見られます。顧客は製品を愛している、技術のチャンピオンは乗り気ですが、セキュリティは顧客データがシステムに入る前に独立した保証を求めます。現在のレポートがある場合、レビューは速くなります。ない場合は、取引は遅くなるか、立ち往生します。 そのため、「SOC 2 認定とはなぜ重要か」というフレーズは商業的に重要です。ただし、用語は少し間違っています。 SOC 2は正式な認定ではありません。 それがAICPAによって定義された検証と報告の基準であり、出力はAICPAのCPAの連携会社から出る監査人の報告書であり、合格または不合格の証明書ではありません。Vantaの検証と認定の区別の解説を参照してください。買い手がそれを求める理由 SOC 2 認証基準 SOC 2 検証.
検証と報告の基準
Vantaの検証と認定の区別の解説
その製品が規制されたワークフロー、顧客レコード、管理ツール、または内部ビジネスデータと触れ合う場合、より大きな意味を持ちます。 速いペースで進むチームは、SaaS、クラウドインフラ、Web3コンポーネント、AI機能を組み合わせたモダンスタックのセキュリティとベンダーリスクのより広い視野が必要です。 そのより広い視野のため、 BlocsysのWeb3とAIの洞察 は、外部委託と新興技術の選択肢が運用リスクに与える影響を枠組みにするため、役立ちます。
顧客はSOC 2を要求することはほとんどありません。 しかし、信頼できる運用習慣を持つための構造化された方法が必要です。
エンジニアリングが早くから関与する理由
これは、創業者やGRC問題だけのものではありません。 エンジニアリングは、多くの基礎となる証拠を所有しています。 Pull Requestの承認、アクセス制御、インシデント対応レコード、ログカバレッジ、エンドポイントセキュリティ、変更チケット、ベンダーマネジメントなど、すべては、ある時点で現れます。
あなたのチームが実践的な出発点を求めている場合、Capgoの 開発チーム向けのセキュリティ記事 は、コンプライアンスの期待が実際の製品配信の中でどのように現れるかを示すための有用な枠組みを提供します。 重要な点は単純です: SOC 2は、最初はセールス要件として始まりますが、維持することはエンジニアリングの専門分野になります。
信頼できるサービス5つの基準を理解する
SOC 2は 5つの信頼できるサービス基準。家を守るための保護と信頼の層を想像してください。1つの層はドアを閉じることを確認します。もう1つの層は電気が続くことを確認します。もう1つの層は配達が正しく行われることを確認します。残りの層は機密情報を誰が見ることができるかと、個人情報をどのように扱うかを制御します。
セキュリティ セキュリティは常に必要です。残りの4つはサービスが何を行うかと、顧客に何を約束するかによって決まります。
VantaによるSOC 2の概要 に記載されている通り、5つの基準はセキュリティ、可用性、処理の正確性、機密性、プライバシー 、で, with セキュリティは基本的な要素.
セキュリティはドアや窓の鍵です。システムやデータを不正なアクセスや不正利用から保護する制御をカバーします。
信頼の5つの基準
実際の開発チームは、この基準を、以下のような作業を通じて確認することが多い。
- アイデンティティ制御 SSO、MFA、ロールベースのアクセス、およびジョイナー・ムーバー・リーバー プロセス
- セキュアな変更管理 レビューされたプルリクエスト、デプロイアプロバル、ロールバックパス
- 監視と対応 ログ、警告、インシデントハンドリング、およびポストインシデントフォローアップ
- 資産とエンドポイントの規制 ノートブック、生産システム、管理ツールは統制されている
顧客データを扱う場合、セキュリティは基準運用成熟度の基準となる。チームが code を配信する方法と最も密接に関連している。
サービスに依存する4つの基準
可用性 システムの稼動と利用の可否を確認し、提供されたコミットメントに従ってシステムを稼動させるかどうかを確認します。顧客がアップタイムの約束、サポートウィンドウ、バックアップの実践、またはディザスタリカバリの期待に依存している場合、この基準は迅速に関連性が高まります。 ‘アプリケーションは稼動するべきだ’ ということではなく、意図的にリザイアンスを管理することの重要性を証明することです。
処理の完全性 処理の完全性は、システムがデータを完全に、正確に、正しい順序で処理する必要がある場合に重要です。請求プラットフォーム、取引システム、ワークフローエンジン、統合など、データ処理の完全性が顧客向けのエラーに影響する場合には、この基準はより重要になります。
機密性 機密性は、必ずしも個人データではない敏感情報に焦点を当てています。契約書、内部ビジネスファイル、クレデンシャル、顧客エクスポート、または独自のデータセットなどを考慮してください。暗号化、データ分類、保持規則、制限されたアクセスなどがここで重要です。
アプリレベルデータハンドリングを実施しているチーム向けのCapgoのガイドです。 handling user data in Capacitor apps プライバシー
プライバシー SOC 2 認定とは何か ビジネス向けデータプライバシーに関する専門ガイダンス データプライバシーに関するビジネス向けの専門家のガイダンス
実用的なルール: 重要なように思える基準を追加しないでください。 その代わりに、サービス、契約、チームが実際に証拠で裏付けることができる主張に合ったものを含めます。
SOC 2 Type I と Type II のレポートの違い
SOC 2 認定の概念についての混乱の多くは、レポートのタイプから生じています。 チームは「SOC 2 が必要です」と言いますが、1 つのバージョンしかないと想像しています。 しかし、実際にはありません。 買い手は、どちらかを持っているかどうかを気にしていることが多く、それは非常に異なることを意味します。 簡単な方法で考えると Type I または Type II
レポートのいずれかを意味します。 対象言語":"日本語","ページパス":"/ja/blog/what-is-soc-2-certification/","保護されたトークン":["Live Update","Cloudflare","Capacitor","GitHub","Capgo","code","API","SDK","CLI","npm","bun"],"アイテム":[{"テキスト":"スナップショット対ビデオ"},{"テキスト":"SOC 2 Type I vs Type II レポートの解説"},{"テキスト":"スナップショット対継続的な証拠"},{"テキスト":"A"},{"テキスト":"Type I"},{"テキスト":"レポートは、特定の日付におけるコントロールの設計が適切であるかどうかを時点で評価します。答えは、特定の日付における会社が適切なコントロールを備えていたかどうかというより狭い質問です。"},{"テキスト":"Type II"},{"テキスト":"レポートはさらに進みます。通常、6 か月から 1 年間の期間を対象に、コントロールが効果的に機能したかどうかを評価します。"},{"テキスト":"6 か月から 1 年間"},{"テキスト":"、これは、"},{"テキスト":"Fractional CISO の Type 1 と Type 2 の説明"}]}.
アイテム":[{"テキスト":"スナップショット対ビデオ"},{"テキスト":"SOC 2 Type I vs Type II レポートの解説"},{"テキスト":"スナップショット対継続的な証拠"},{"テキスト":"A"},{"テキスト":"Type I"},{"テキスト":"レポートは、特定の日付におけるコントロールの設計が適切であるかどうかを時点で評価します。答えは、特定の日付における会社が適切なコントロールを備えていたかどうかというより狭い質問です。"},{"テキスト":"Type II"},{"テキスト":"レポートはさらに進みます。通常、6 か月から 1 年間の期間を対象に、コントロールが効果的に機能したかどうかを評価します。"},{"テキスト":"6 か月から 1 年間"},{"テキスト":"、これは、"},{"テキスト":"Fractional CISO の Type 1 と Type 2 の説明"}]}]}
A Type I report is a point-in-time assessment of whether your controls are designed appropriately. It answers a narrower question: on a specific date, did the company have suitable controls in place?
A Type II reportはさらに進んでいます。 その報告は、通常の期間内に、実際に機能したかどうかを評価します。 アイテム":[{"テキスト":"スナップショット対ビデオ"},{"テキスト":"SOC 2 Type I vs Type II レポートの解説"},{"テキスト":"スナップショット対継続的な証拠"},{"テキスト":"A"},{"テキスト":"Type I"},{"テキスト":"レポートは、特定の日付におけるコントロールの設計が適切であるかどうかを時点で評価します。答えは、特定の日付における会社が適切なコントロールを備えていたかどうかというより狭い質問です。"},{"テキスト":"Type II"},{"テキスト":"レポートはさらに進みます。通常、6 か月から 1 年間の期間を対象に、コントロールが効果的に機能したかどうかを評価します。"},{"テキスト":"6 か月から 1 年間"},{"テキスト":"、これは、"},{"テキスト":"Fractional CISO の Type 1 と Type 2 の説明"}]}]}SOC 2 認証である Type 1 と Type 2 の違い.
その差は、エンジニアリングチームの作業方法を変える。
ここでは、簡単な方法で説明します。
| レポートの種類 | それを考えてみてください | それが証明すること |
|---|---|---|
| タイプI | 一時点のスナップショット | 制御は特定の時点で適切に設計されている |
| タイプII | 動画 | 制御は監査期間中に効果的に動作した |
動画の説明は、ステークホルダーが2つを混同している場合に、数分間かかるかもしれません。
買い手が実際に気にするのはどれ?
タイプIはまだ役に立つことができます。プロセスの初期段階で、セールスとセキュリティチームに実際のものを共有できるので、会社が非公式なセキュリティ慣行を超えたことを示すことができます。
しかし、成熟した買い手は通常、タイプIを中間信号として扱い、最終的な目的地ではありません。アクセスレビューが予定どおり行われ、変更が一貫して承認され、インシデントがプロセスに従って追跡され、処理されたことを示す証拠が必要です。
タイプIのレポートは、システムが1日のうちに整理されたように見えたことを示します。タイプIIのレポートは、チームが数ヶ月間整理されたことを示します。
高速化されたSaaSおよびモバイルチームにとって、これが鍵の区別です。タイプIIは、規則を実行することを強制するため、単に文書化するのではなく、規則を実行することを強制します。
SOC 2 検査プロセスを導く
SOC 2 は、単一のイベントとして扱うと圧倒感を感じるが、実際には、異なる所有者が取り組むワークストリームのシーケンスです。セキュリティ、エンジニアリング、IT、HR、法務、運営全てが、各自の役割で貢献します。ワークストリームを段階的に分割し、証拠の所有権を早期に割り当てるチームが、SOC 2 をうまく取り扱います。
ここでも、期待が現実的になる必要があります。 A-LIGNのSOC 2 ガイドによると, タイプIは2から4週間かかります, タイプIIは6から12か月かかります最終レポートは一般的に 12 か月程度有効, Audit は通常、 20,000 ドルから 150,000 ドル以上 範囲、複雑さ、企業規模に応じて
実際のプロセスをみる
チームは、以下の流れで進むことが多い
-
環境の範囲を定義する
製品、システム、人、ベンダー、信頼性サービス基準を含む、どのものが対象かを決定する。このステップは行政的なもののように見えるが、どれだけの証拠が必要か、そして監査人が調査するエンジニアリングシステムを決定する -
準備と差分分析
現在の実践と必要な制御を比較する。比較中、チームは通常のギャップを発見する: 弱いオフボーディング、不一致の PR 承認、非公式のインシデントハンドリング、欠落したアクセスレビュー、未記録のバックアップ、または不十分なベンダーレコード。 -
改善作業
ポリシーが書かれ、システムが強化され、ワークフローが整理され、責任者が割り当てられます。この部分は、機能を構築することよりも魅力が少ないことが多いですが、審査が成功または失敗するのはここです。 -
正式な審査活動
監査人は、資料を確認し、人々にインタビューし、制御をテストします。タイプIIを目指している場合は、このステージも観察期間中の証拠によって決まります。 -
継続的なメンテナンス
報告書は永続的ではありません。一般的には1年間有効なので、チームはシステムを稼働させ続けなければなりません。単に1回のレビュー周期を乗り越えるだけではありません。
チームが通常で困る場所
一般的な失敗モードは、チームがセキュリティツールが不足していると思っていることではありません。実際は、正常なエンジニアリング活動をきれいな、レビュー可能な証拠に変えることができないことです。
いくつかの例:
- プルリクエストは存在しますが、承認は一貫していません。
- シークレットは安全に保存されていますが、誰がアクセスを確認し、いつ確認したかを示すことができません。
- インシデントは責任を持って処理されていますが、記録はチャットやチケットシステムに散在しています。
- 監視は存在しますが、警告の所有権やエスカレーションルートは記載されていません。
CI/CD重視のチームにとって、シークレットの管理は最初に検査される場所の1つです。Capgoの記事 CI/CDパイプライン内でのシークレットの管理 CI/CDパイプライン内でのシークレットの管理は、悪い習慣に陥る容易な場所を固めるための実践的なガイドです。
実践におけるSOC 2コントロールの見本
SOC 2 認証の実践例
A developer ships a hotfix on Tuesday night. By Thursday, a prospect asks for the latest SOC 2 report, and the auditor wants proof that production changes were reviewed, approved, and traceable. The code is fine. The problem is whether the team can show how it moved.
正常なデリバリ中に証拠を生成する変更管理
正常なデリバリ中に証拠を生成する変更管理は、簡単に説明でき、簡単に検査できます。
チームがこの領域を固める前に、生産性の修正は直接マージ、非公式の承認、チャット、CIログ、誰かの記憶に散らばったリリースノートで行われていました。システムはまだ安定していますが、証拠は弱く不一致です。
プロセスが整理された後、コントロールは通常以下のようになります:
__CAPGO_KEEP_0__の変更
- codeの変更 各 pull request
- 各 pull request 作成者以外の人がレビュー
- 各デプロイ CI/CD のビルドレコードとコミット履歴にマップ
- 各緊急修正 例外パスに従い、インシデント後に文書化されたレビュー
これらの制御は、監査に加えて、インシデントのレビューを短縮し、ロールバックの決定を早めるだけでなく、生産環境に到達したものについて議論を減らします。
速度の犠牲はエッジです。週に更新を実施する SaaS とモバイルのチーム、特に、更新を週に実施するチームには、エンジニアが停止して手動で監査ノートを書くことを強制しないように、証拠が現在のままになるプロセスが必要です。四半期末に手動でクリーンアップが必要な場合、ワークフローはずれます。
リリース重視のアプリチームはこの問題にすぐに直面します。Web の変更、バックエンドの変更、機能フラグ、モバイルの更新チャネルはすべて異なるスケジュールで進むことができます。制御目標は同じです: リリースを承認したのは誰か、どのアーティファクトが送信されたか、どこに送信されたか、そしてロールバックするにはどうすればいいかを証明することです。
チームの変化が耐えるアクセス制御と監視
アクセス制御は気付かずに失敗することがあります。元請け契約者がクラウドアクセスを維持する。エンジニアが生産問題のために管理権限を取得し、6 か月間維持する。共有資格が残っているのは、忙しいスプリント中のリスクを感じるため削除することがリスキーだと感じるからです。
SOC 2制御はこの領域では簡単です:
- ロールベースのアクセス 生産性の特権は必要な人だけに制限されます
- プロビジョニングとオフボード 承認フローに従って明確な記録
- アクセスレビュー 定期的なスケジュールで行われ、権限が正当化されなくなった場合に削除される
- SSOとMFA アカウントリスクを低減し、アカウント所有権を証明しやすくします
監査人は、権限が「一般的に制限されている」ことを気にしません。監査人は、チームが監査期間中に誰がアクセスを取得したか、誰が承認したか、そしていつ再検証されたかを示すことができることを確認します。
監視は同様に機能します。ログだけでは十分ではありません。チームには、名前の付いたアラートオーナー、定義された重大度レベル、そしてチケットまたはインシデントレコードを生成するレスポンスパスが必要です。そうでない場合、制御は単なる良好な意図だけになります。
アプリチームにとって、ストレージの決定もここで現れます。製品アーキテクチャは、コンプライアンス証拠に影響を与えるからです。機密データがデバイス上で保存され同步される場合、チームは保護方法とアクセス制限方法を説明する必要があります。この実用ガイドは アプリチーム向けのセキュアなデータベースストレージ 実装の詳細を示すことで、監査人にエンジニアリングチームが明確にすることを求めることが多い
高速なチームは、codeを発行し、証拠を収集する作業を同じワークフロー内で行うことで、コンプライアンスを維持する
ほとんどのSOC 2ガイドは、実際の運用状況を省略している。難しいのは、コントロールを書くことではなく、製品、チーム、リリースプロセスが変化するにつれて真実を維持することだ
SOC 2、ISO 27001、HIPAAの比較
チームは、SOC 2を単独で評価することはほとんどない。顧客がSOC 2を要求し、企業がISO 27001を要求し、医療分野の顧客がHIPAAを要求することがある。フレームワークは、精神的に重なり合っているが、異なる問題を解決する
フレームワークの違い
SOC 2は、特に北米向けのSaaSベンダーが利用するサービス組織向けのフレームワークである。買い手は、CPAによる監査レポートを受け取ることができる。設計と、選択した信頼性サービス基準に基づくコントロールの、Type IIの場合の実行効率性についての情報を提供する
ISO 27001は、より広範な情報セキュリティマネジメントフレームワークである。国際的に認知されている。企業は、グローバルに認知されている標準を求める場合や、正式なマネジメントシステムを構築したい場合に、ISO 27001を目指すことが多い。実際には、異なる地域の顧客が異なる保証モデルを要求するため、両方のSOC 2とISO 27001が必要になることもある
HIPAAは両方とも異なります。一般用途の信頼レポートではありません。ソフトウェア企業向けのものではなく、保護された健康情報に関連する米国の法的および規制枠組みです。製品が保健データをカバーされた使用例で処理する場合、HIPAAはブランド選択ではありません。法的運用環境の一部です。
ここでは実用的な視点を示します。
| フレームワーク | 焦点 | 地理的範囲 | 業界 |
|---|---|---|---|
| SOC 2 | サードパーティによるサービス組織制御の検証 | サービス組織制御に関する第三者証明 | 北米でよく使用される |
| ISO 27001 | ISO 27001 | 国際 | 業界横断 |
| HIPAA | 健康情報の保護と取り扱い | 米国 | 医療と医療関連サービス |
誤解を招くのは、すべての状況でそれらを代用することです。そうではないのです。買い手がSOC 2レポートを求めている場合、ISO 27001は総合的な信頼性を高めるのに役立ちますが、必ずしもその具体的な要求を満たすわけではありません。保護された健康情報を取り扱っている場合、SOC 2はHIPAAの義務を置き換えるものではありません。
SOC 2の準備状況チェックリスト
始めるには、もう一つの巨大なスプレッドシートは通常必要ではありません。代わりに、短いリストの決定が「SOC 2を取得するべきだ」という実際のプロジェクトに変えることができます。
実践的な開始リスト
-
範囲の定義
範囲を明確に選択してください。範囲が曖昧な場合、証拠の収集が混乱する可能性があります。 -
適切な基準を選択してください。 セキュリティは必須です。残りのものは、サービスが提供するものと、顧客に約束するものを反映するものでなければなりません。
-
明確な責任者を割り当ててください。
誰かがアクセスレビュー、インシデント対応記録、ベンダーマネジメント、エンドポイント制御、ポリシーマイナンス、そして監査調整を所有する必要があります。共有責任は、個人の所有権が明確である場合にのみ機能します。 -
準備ができていると話す前に、ギャップアセスメントを実行してください。
内部で弱いオフボーディング、欠落している承認、文書化されていないプロセスを発見する方が、監査調査中に発見する方が良いでしょう。 -
証拠の収集を標準化してください。
システムを使用して、持続可能な記録を残すことができます。チケット管理、アイデンティティ管理、エンドポイントツール、ソース管理、CIプラットフォーム、警告ツールはすべて、後で取得できるアーカイブを生成する必要があります。 -
第三者リスクをレビューしてください。
ベンダーはあなたの物語の一部になります。クラウドプラットフォーム、認証プロバイダー、サポートツール、分析システム、更新インフラストラクチャはすべて、最低限のレビューが必要です。 -
チームにワークフローを学習させるのではなく、ポリシーを学習させるのではなく、チームを訓練してください。
リリース、ホットフィックス、オンボーディング、インシデントハンドリングの際に、承認されたパスがどのように動作するかを知る必要がある。
SOC 2認定をISO指向されたプログラムと関連付けるチームがいる場合 F1Groupのセキュリティソリューション セキュリティプログラムは、顧客の要件が成熟すると、1つのフレームワークを超えて拡大することがよくあります。F1Groupのセキュリティソリューションは、SOC 2認定を実現するための実装レベルのコントロールを実現するための参考点となります。
アプリの頻繁なアップデートを通常のストアリリースサイクル外で配信する場合、リリースの統制をスコープに含めることを最初から行うことが推奨されます。Capgoの CapacitorアプリのOTAセキュリティチェックリスト __CAPGO_KEEP_0__アプリを配信するチームがリリース証拠、ロールバックパス、更新の統制をより厳密に制御する必要がある場合、__CAPGO_KEEP_0__は評価されるべきです。
Capacitorは、エンジニアリングチームに署名されたライブアップデート、ターゲットロールアウト、リリースの観察性を管理するための構造化された方法を提供します。これにより、SOC 2の期待が実際のデプロイ速度と一致する場合、継続的なコンプライアンスが容易になります。 Capgo マーティン・ドナディュー
