Salesforce Shield Platform Encryption: データセキュリティとコンプライアンスへの詳細ガイド

日付:

背景と適用シナリオ

現代のビジネス環境において、データは最も価値のある資産の一つです。同時に、顧客データ、特に個人識別情報 (Personally Identifiable Information - PII) や財務情報などの機密データを保護することは、企業の信頼性と存続に関わる最重要課題となっています。GDPR (EU一般データ保護規則)、CCPA (カリフォルニア州消費者プライバシー法)、そして日本の改正個人情報保護法 (APPI) といった各国のデータ保護規制は、企業に対して厳格なデータ管理とセキュリティ対策を義務付けています。

Salesforceは世界中の多くの企業で利用されており、そのプラットフォーム上には膨大な量の機密データが保存されています。標準機能として提供されるセキュリティ機能に加え、さらに高度なデータ保護要件を満たすために開発されたのが Salesforce Shield です。Salesforce Shield は、イベントモニタリング、項目監査履歴、そして本稿の主題である Shield Platform Encryption (シールドプラットフォーム暗号化) の3つの主要なサービスで構成されています。

Shield Platform Encryption は、Salesforce内に保存されているデータ (data at-rest) を強力な暗号化アルゴリズムで保護するアドオンサービスです。これにより、データベースレベルでの不正アクセスやデータ漏洩が発生した場合でも、データの内容を解読されるリスクを大幅に低減できます。具体的な適用シナリオは以下の通りです。

  • PIIの保護: 氏名、住所、電話番号、社会保障番号、マイナンバーなど、規制対象となる個人情報を暗号化する。
  • 医療・健康情報の保護: HIPAA (医療保険の相互運用性と説明責任に関する法律) などに準拠するため、患者の診断情報や治療履歴といった機密性の高いデータを保護する。
  • 金融情報の保護: クレジットカード番号の一部、口座情報、取引履歴など、PCI DSS (ペイメントカード業界データセキュリティ基準) などの要件に対応するためにデータを暗号化する。
  • 企業の内部情報保護: M&A情報、人事評価、研究開発データなど、社外秘の重要情報を保護する。

Shield Platform Encryption の最大の特徴は、データを暗号化しつつも、検索、入力規則、ワークフロールールといったSalesforceの主要なプラットフォーム機能を可能な限り維持できる点にあります。これにより、セキュリティを強化しながらも、ビジネスプロセスへの影響を最小限に抑えることが可能です。

原理説明

Shield Platform Encryption のセキュリティモデルは、多層的な鍵管理アーキテクチャに基づいています。これにより、堅牢性と柔軟性を両立しています。

鍵階層 (Key Hierarchy)

データの暗号化と復号は、以下の鍵階層を通じて行われます。

  1. Master Secret (マスターシークレット): Salesforce がハードウェアセキュリティモジュール (Hardware Security Module - HSM) 内で安全に保持・管理する最上位の鍵です。四半期ごとにリリースに合わせて更新されます。この鍵に直接アクセスすることは誰にもできません。
  2. Tenant Secret (テナントシークレット): 各Salesforce組織（テナント）ごとに生成・管理される鍵です。組織の管理者がUIを通じて、またはAPIを利用して生成・管理（ローテーションや破棄）します。このテナントシークレットは、顧客が管理する鍵ライフサイクルの中心となります。
  3. Data Encryption Key (データ暗号化キー - DEK): Master Secret と Tenant Secret を組み合わせて派生し、最終的に個々のデータ（項目、ファイル、添付ファイルなど）を暗号化するために使用される鍵です。DEKは直接管理されることはなく、必要に応じて動的に生成・破棄されるため、セキュリティがさらに向上します。

この階層構造により、万が一 Tenant Secret が侵害された場合でも、Master Secret が保護されているため、即座にデータが危険に晒されることはありません。また、顧客は自身の Tenant Secret を管理することで、データへのアクセスをコントロールする権限を持つことができます。

鍵管理オプションとして、Salesforceが生成・管理するテナントシークレットを利用する方法に加え、顧客自身が鍵素材を生成しSalesforceにアップロードする Bring Your Own Key (BYOK) モデルもサポートされています。BYOKを利用することで、企業は自社のセキュリティポリシーに準拠した鍵管理を徹底できます。

暗号化の種類

Shield Platform Encryption では、暗号化する項目に対して2種類の暗号化スキームを選択できます。これは、セキュリティ要件とプラットフォームの機能性とのトレードオフを考慮して設計されています。

1. Probabilistic Encryption (確率的暗号化)

最も強力な暗号化方式です。同じ平文（暗号化前のデータ）を複数回暗号化しても、毎回異なる暗号文（暗号化後のデータ）が生成されます。これにより、暗号文のパターンから元のデータを推測することが極めて困難になります。しかし、その強力さゆえに、暗号化された項目をSOQLのWHERE句での絞り込み条件として使用したり、レポートでグルーピングしたりすることはできません。セキュリティが最優先される、自由記述形式の項目（説明項目など）に適しています。

2. Deterministic Encryption (確定的暗号化)

同じ平文を暗号化すると、常に同じ暗号文が生成される方式です。確定的暗号化には、大文字と小文字を区別するもの (case-sensitive) と区別しないもの (case-insensitive) の2つのバリエーションがあります。この方式の最大の利点は、暗号化された項目をSOQLのWHERE句で完全一致条件として使用できることです。これにより、暗号化された取引先責任者のメールアドレスでレコードを検索する、といった操作が可能になります。ただし、確率的暗号化と比較すると、暗号文の頻度分析などによってデータパターンが推測されるリスクがわずかに高まります。一意性が高い識別子（メールアドレス、社員番号など）で、かつ検索要件がある項目に適しています。

示例コード

Shield Platform Encryption は主に宣言的な設定（ポイント＆クリック）で有効化しますが、開発者はApexを通じて、ある項目が暗号化されているかどうかを動的に確認する必要があります。例えば、特定のロジックを暗号化項目に対してのみ実行したい場合や、SOQLクエリを構築する際にフィルタリング可能か否かを判断する場合などです。Salesforce の Schema クラスと DescribeFieldResult クラスを使用することで、項目の暗号化ステータスをプログラムで取得できます。

以下のApexコードは、取引先 (Account) オブジェクトの「取引先名 (Name)」項目と「電話 (Phone)」項目が暗号化されているかどうかを確認する公式のサンプルです。

// Schemaクラスを使用して、取引先オブジェクトの項目定義のマップを取得します。
Map<String, Schema.SObjectField> fieldMap = Schema.SObjectType.Account.fields.getMap();

// マップから「Name」項目のSObjectFieldトークンを取得し、その詳細情報 (DescribeFieldResult) を取得します。
Schema.DescribeFieldResult nameFieldResult = fieldMap.get('Name').getDescribe();

// 同様に、「Phone」項目の詳細情報を取得します。
Schema.DescribeFieldResult phoneFieldResult = fieldMap.get('Phone').getDescribe();

// DescribeFieldResultのisEncrypted()メソッドを呼び出して、項目が暗号化されているかどうかのBoolean値を取得します。
// このメソッドは、Shield Platform Encryptionによって暗号化が有効になっている場合にtrueを返します。
Boolean isNameEncrypted = nameFieldResult.isEncrypted();
Boolean isPhoneEncrypted = phoneFieldResult.isEncrypted();

// 結果をデバッグログに出力します。
// Shield Platform Encryptionの設定画面でこれらの項目を暗号化した場合、ログにはtrueが表示されます。
System.debug('取引先名 (Account Name) は暗号化されていますか？ ' + isNameEncrypted);
System.debug('電話 (Account Phone) は暗号化されていますか？ ' + isPhoneEncrypted);

このコードを利用することで、開発者は実行時に項目のメタデータを確認し、暗号化の状態に応じた適切な処理分岐を実装できます。例えば、isEncrypted() が true で、かつ確定的暗号化スキームが使われている項目でなければSOQLのWHERE句に含めない、といった動的なクエリ生成が可能です。

注意事項

Shield Platform Encryption は非常に強力なツールですが、導入にあたってはいくつかの重要な制約と注意点を理解しておく必要があります。これらを無視すると、既存のビジネスプロセスやシステムのパフォーマンスに深刻な影響を与える可能性があります。

権限

  • 暗号化キーの管理: 「アプリケーションのカスタマイズ」および「暗号化キーの管理」権限を持つ管理者のみが、テナントシークレットの生成、ローテーション、エクスポート、破棄といった操作を行えます。これらの権限は慎重に割り当てる必要があります。
  • 暗号化されたデータの表示: 「暗号化されたデータの表示」権限を持つユーザーのみが、暗号化されたデータを復号して表示できます。この権限がないユーザーには、データはマスクされて表示されます。

機能上の制限

  • SOQL/SOSL: 暗号化された項目は、SOQLクエリの一部機能が利用できなくなります。ORDER BY, LIKE, STARTS WITH, CONTAINS 句では使用できません。また、集計関数 (COUNT, SUM, MAXなど) の対象にもできません。確定的暗号化された項目のみ、WHERE句での完全一致検索 (= または IN) が可能です。
  • レポートとダッシュボード: レポートのグラフ作成やダッシュボードのコンポーネントで、暗号化された項目をグルーピング（集計）の軸として使用することはできません。
  • 数式項目と入力規則: 暗号化された項目を数式で参照すると、数式が期待通りに動作しない場合があります。特に、暗号化された値は常に異なる文字列として評価されるため、数式内での文字列操作や比較は避けるべきです。
  • インデックス: 確定的暗号化された項目に対しては、データベースインデックスを作成できますが、パフォーマンスへの影響を考慮する必要があります。
  • 暗号化対象外: 一部の標準項目（例: Name 項目の一部、Forecast 関連項目など）、メタデータ、Chatterフィードなどは暗号化の対象外です。

APIとインテグレーション

外部システムとAPI連携している場合、注意が必要です。API経由でSalesforceから取得したデータは、通常は復号された状態で返されます（アクセスユーザーが必要な権限を持っている場合）。しかし、外部システムがSalesforceにデータを送信する際、その項目が暗号化されていることを意識する必要はありません。データはSalesforce側で自動的に暗号化されます。ただし、外部のデータウェアハウスなどにデータをエクスポートする場合、エクスポートされたデータは暗号化されたままです。これを復号するには、別途復号処理を実装するか、暗号化されていないデータをエクスポートする仕組みを検討する必要があります。

キー管理の責任

特にBYOKモデルを採用する場合、鍵の生成、保管、バックアップ、破棄といったライフサイクル管理の全責任は顧客側にあります。もしテナントシークレットを紛失または破棄した場合、その鍵で暗号化されたデータは永久に復元できなくなります。 これは事業継続性に直結する極めて重要なリスクであり、厳格な管理体制の構築が不可欠です。

まとめとベストプラクティス

Salesforce Shield Platform Encryption は、Salesforceプラットフォーム上に保存された機密データを保護し、厳格なコンプライアンス要件を満たすための強力なソリューションです。多層的な鍵管理アーキテクチャと、ビジネス要件に応じて選択可能な暗号化スキームを提供することで、セキュリティと機能性のバランスを取ることができます。

しかし、その強力さゆえに、導入は慎重な計画と影響評価を伴うべきプロジェクトです。以下に、導入を成功させるためのベストプラクティスを挙げます。

  1. データ分類の実施: まず最初に、組織内のどのデータが機密情報であり、暗号化が必要かを特定します。すべてのデータを暗号化するのではなく、PIIや財務情報など、真に保護が必要なデータに絞り込むことが重要です。これにより、パフォーマンスへの影響と管理コストを最小限に抑えられます。
  2. 適切な暗号化スキームの選択: 各項目に対して、ビジネス要件を精査し、Probabilistic Encryption と Deterministic Encryption のどちらを選択するかを決定します。検索やレポートでの絞り込みが必要な場合は Deterministic を、そうでなければより強力な Probabilistic を選択します。
  3. 厳格なキー管理ポリシーの策定: テナントシークレットのライフサイクル（生成、バックアップ、定期的なローテーション、破棄）に関する明確なポリシーを策定し、文書化します。特にキーのバックアップは、災害復旧計画の重要な一部です。
  4. 徹底的なテスト: 本番環境に適用する前に、必ず完全なSandbox環境で暗号化を有効にし、すべてのビジネスクリティカルなプロセス、レポート、インテグレーション、カスタムコードが期待通りに動作するかを徹底的にテストします。特に、SOQLクエリやApexトリガの動作確認は必須です。
  5. ユーザーと管理者へのトレーニング: 暗号化による影響（例：一部の検索機能が使えなくなることなど）について、関連するすべてのユーザーと管理者に周知し、トレーニングを実施します。

Shield Platform Encryption は、単なる技術的な機能ではなく、組織全体のデータガバナンス戦略の中核をなすものです。これらのベストプラクティスに従い、計画的に導入を進めることで、Salesforceプラットフォームの価値を最大限に引き出しながら、最も重要な資産であるデータを確実に保護することが可能になります。

コメント

コメントを投稿