ベンダー選定では、セキュリティ能力の検証が特に難しい項目です。本稿ではSOC 2の5つのTrust Services Criteria、Type IとType IIの時間軸の違い、そして自社のリスク判断のためにレポートで確認すべき項目を整理します。
クラウドサービスやツールを調達するとき、セキュリティ能力は最も検証しにくい項目の一つです。機能は試用でき、価格も比較できますが、社内で権限をどう管理しているか、事故時にどう対応するか、データをどの拠点に置いているかは、1回のデモでは分かりません。
SOC 2レポートは、まさにこの点を確認するためのものです。製品の使いやすさを評価するのではなく、より本質的な問いに答えます。つまり、サービス組織がセキュリティ関連の統制を、自ら説明しているとおりに実際に運用しているかどうかです。
監査対象は製品ではなく組織
SOC 2（System and Organization Controls 2）は、American Institute of Certified Public Accountantsがサービス組織向けに策定した監査基準です。レポートは独立した会計事務所が発行し、監査意見が示されます。Unqualified Opinionは、監査期間全体を通じて統制システムが有効に運用されていたことを意味し、この種の監査では最も強い結論に当たります。
監査は5つのTrust Services Criteriaを軸に行われます。Securityは必須で、残り4項目は事業の性質に応じて選択されます。
| 基準 | 主な確認内容 |
|---|---|
| セキュリティ | 不正アクセスや侵入の防止 |
| 可用性 | 約束どおりサービスが安定稼働すること |
| 処理の完全性 | データを正確・完全・適時に処理すること |
| 機密性 | 機密情報の暗号化とアクセス範囲の制限 |
| プライバシー | 個人情報の収集、利用、最終的な廃棄 |
Type IとType IIの違いは時間軸
ここは特に混同しやすく、レポートの価値を判断するうえでも重要な違いです。
Type Iは、ある特定時点での統制設計を監査します。簡単に言えば、ルールや統制が妥当に設計されているかを見るものです。Type IIは、一定期間にわたって統制がどのように運用されたかを監査します。観察期間は通常6～12か月で、日常業務、コード変更、人員変更を追跡し、サンプルによる証拠確認も行います。
前者は統制の仕組みを文書化しているか、後者は過去数か月にわたり毎日その仕組みに従っていたかを示します。そのため「SOC 2に合格した」と聞いたら、まずType IなのかType IIなのかを確認する必要があります。
ISO 27001との関係
両者はよく並べて語られますが、位置付けは異なります。SOC 2は会計事務所が発行し、顧客向けの保証レポートとして統制の説明やテスト結果を含みます。北米顧客のB2B調達におけるデューデリジェンスでよく使われます。ISO 27001は認証機関が認証し、組織の情報セキュリティマネジメントシステムに重点を置きます。主な成果物は証明書で、国際的な通用度はより高い傾向があります。
両方を取得しているサービス事業者も少なくありませんが、矛盾ではありません。ISO 27001はマネジメントシステムが包括的に構築されていることを示し、SOC 2 Type IIは統制が実際に運用されていることを示します。リスクを判断するうえでは、後者のほうが通常、より多くの具体情報を提供します。
レポート入手後に確認すべきこと
サービス事業者は通常、秘密保持契約の下でレポートを提供します。読む際に見落としてはいけないポイントがいくつかあります。
まず監査範囲を確認します。どの製品、どのデータセンター、どの事業ラインが対象なのか、それが実際に利用する部分と一致しているかを見ます。範囲外の部分について、このレポートは何も証明しません。
次に対象期間を確認します。期間は連続しているか、直近の完全なサイクルを含んでいるかが重要です。2年前のレポートだけでは、現在の状態は分かりません。
続いてExceptionsを確認します。ここは多くの場合、最も情報量の多い部分です。どの統制が有効に機能しなかったのか、影響範囲はどこまでか、是正計画はあるのかが記載されます。例外があるからといって、直ちに利用できないという意味ではありません。重要なのは、それが自社のリスクエクスポージャーに関係するか、是正内容が明確で進捗が追われているかです。
最後に、自社の要件へ戻ります。データの可用性が重要なのに、レポートがセキュリティしか対象にしていないなら、知りたいことには答えていません。これは見落とされがちな点です。数百ページのレポートでも、すべてのページが自社の利用シナリオに関係するわけではありません。
認証では代替できない部分
セキュリティ認証が示すのはサービス事業者側の管理水準であり、自社の利用方法がルールに適合していることを証明するものではありません。
アカウント管理を例にすると、事業者自身のセキュリティ体制が監査に耐えられるとしても、権限をどう割り当てるか、環境をどう設定するか、各プラットフォーム上でどのように操作するかは、それぞれのルールに従う必要があります。認証が答えるのは、相手側でデータが適切に扱われているかどうかであり、自社の操作が適切かどうかではありません。
環境分離と明確なアクセス境界は、この種の監査で繰り返し重視されます。各環境を独立した単位にし、アカウント間でセッションやデータが混ざらないようにすることは、本質的には同じ考え方です。ただし実装するのは利用者側です。PurpleMarkは環境分離のレイヤーで、この種の機能を提供します。
本稿は監査基準に関する知識の説明のみを目的としています。具体的なレポート内容と適用範囲については、サービス事業者が提供する正式なレポートを確認してください。
