Salesforce Shield Platform Encryption: アーキテクトが解説するデータセキュリティの深層

日付:

Salesforce アーキテクトとして、エンタープライズレベルの Salesforce 環境におけるセキュリティとコンプライアンスの設計を担当しています。今日のデジタル時代において、データは最も価値のある資産の一つであり、それを保護することは企業の信頼性と存続に不可欠です。特に、個人情報保護法、GDPR、HIPAA、PCI DSS といった厳格な規制に対応するためには、堅牢なデータ保護戦略が求められます。本記事では、Salesforce が提供する最も強力なデータ保護機能の一つである Shield Platform Encryption について、アーキテクトの視点からその背景、仕組み、実装上の考慮事項、そしてベストプラクティスを深く掘り下げて解説します。

背景と応用シナリオ

Salesforce は標準で多くのセキュリティ機能を提供していますが、特定の業界や規制要件を満たすためには、より高度なデータ保護レイヤーが必要となる場合があります。Shield Platform Encryption は、Salesforce に保存されているデータ（"Data at Rest"、保存データ）を暗号化するためのプレミアムサービスです。

従来の「項目レベルのセキュリティ」や「オブジェクトレベルのセキュリティ」がユーザーのアクセス権を制御するのに対し、Platform Encryption は、たとえデータベースに直接アクセスされたとしても、データそのものを読み取り不可能にすることで、情報漏洩のリスクを根本的に低減させます。これは、内部不正や、万が一の物理的なデータメディアの盗難といったシナリオにおいても、データを保護するための最後の砦となります。

主な応用シナリオ：

  • PII (Personally Identifiable Information, 個人を特定できる情報) の保護： 顧客の氏名、住所、電話番号、社会保障番号など、個人を特定できる機密情報を保護し、プライバシー規制に準拠します。
  • PHI (Protected Health Information, 保護対象保健情報) の管理： 医療・ヘルスケア業界において、患者の医療記録や保険情報などを HIPAA の要件に従って保護します。
  • 金融情報の保護： 金融サービス業界において、口座番号や取引履歴などの機密性の高い顧客データを保護し、PCI DSS などのコンプライアンス要件を満たします。
  • 知的財産 (IP) の保護： 製造業やテクノロジー企業において、製品の設計情報や研究開発データといった企業秘密を保護します。

原理説明

Shield Platform Encryption のアーキテクチャを理解することは、その導入を成功させるための鍵となります。その核心は、堅牢な鍵管理階層にあります。

鍵管理アーキテクチャ

Shield Platform Encryption は、階層的な鍵管理モデルを採用しています。これにより、セキュリティと管理の柔軟性が両立されています。

  1. Master Secret (マスター秘密)： Salesforce が管理する最上位の鍵です。リリースごとに生成され、HSM (Hardware Security Module, ハードウェアセキュリティモジュール) と呼ばれる物理的に保護された専用ハードウェア内で厳重に保管されます。顧客がこの鍵に直接アクセスすることはありません。
  2. Tenant Secret (テナント秘密)： 各 Salesforce 組織（テナント）に固有の鍵であり、顧客自身が生成・管理します。このテナント秘密は、組織の管理者が Salesforce の UI を通じて生成し、必要に応じてローテーション（定期的な更新）やエクスポート（バックアップ）が可能です。この「顧客が鍵を管理する」という点が、Shield の大きな特徴です。さらに、BYOK (Bring Your Own Key, 独自の鍵の持ち込み) 機能を利用すれば、顧客が自社で生成した鍵を Salesforce にアップロードして使用することも可能です。
  3. Data Encryption Key (データ暗号化鍵)： 実際にデータを暗号化・復号するために使用される鍵です。テナント秘密とマスター秘密から派生して生成されます。この鍵は直接ユーザーに公開されることはなく、実際の暗号化処理はアプリケーションサーバー内で透過的に行われます。

この階層構造により、万が一データセンターからデータが漏洩したとしても、攻撃者はデータ、データ暗号化鍵、テナント秘密、マスター秘密のすべてを入手しない限り、データを復号することは極めて困難になります。

暗号化の種類

Shield Platform Encryption は、要件に応じて2種類の暗号化スキームを提供します。アーキテクトは、セキュリティ要件と業務要件のトレードオフを考慮して、どちらを選択するかを決定しなければなりません。

  • Probabilistic Encryption (確率的暗号化)： 最も強力な暗号化方式です。同じ平文（暗号化前のデータ）を複数回暗号化しても、毎回異なる暗号文（暗号化後のデータ）が生成されます。これにより、暗号文のパターンから元の値を推測することを防ぎます。しかし、その性質上、暗号化された項目をレポートの絞り込み条件や SOQL の WHERE 句で使用することはできません。セキュリティを最優先する場合のデフォルトの選択肢です。
  • Deterministic Encryption (確定的暗号化)： 同じ平文を暗号化すると、常に同じ暗号文が生成されます。これにより、レポート、リストビュー、SOQL の WHERE 句などで、暗号化された項目に対する完全一致の絞り込み（フィルタリング）が可能になります。例えば、「取引先責任者のメールアドレス」など、一意の値で検索する必要がある項目に適しています。ただし、暗号文の頻度分析などに対して確率的暗号化よりも脆弱であるため、フィルタリングが必須要件である場合にのみ限定的に使用するべきです。大文字と小文字を区別する、または区別しない、の2つのバリエーションがあります。

どの項目にどの暗号化スキームを適用するかは、データ分類と業務影響を入念に分析した上で決定する必要があります。

サンプルコード

Shield Platform Encryption は主に宣言的な設定（ポイント＆クリック）で有効化しますが、開発者やインテグレーターはその影響を理解しておく必要があります。特に、確定的暗号化された項目を Apex や SOQL でどのように扱うかは重要なポイントです。

以下の Apex コードは、確定的暗号化された項目と確率的暗号化された項目に対するクエリの違いを示しています。

確定的暗号化項目に対するSOQLクエリ

取引先責任者オブジェクトのカスタム項目「SSN__c」（社会保障番号）が確定的暗号化で暗号化されていると仮定します。この場合、= 演算子を使用した完全一致での検索が可能です。

// SSN__c is a custom field on the Contact object and is encrypted with Deterministic Encryption.
// This query is supported and will return matching records.
// The Salesforce platform handles the encryption/decryption transparently for this specific use case.

try {
    String socialSecurityNumber = '123-45-6789';
    List<Contact> contacts = [
        SELECT Id, FirstName, LastName, SSN__c 
        FROM Contact 
        WHERE SSN__c = :socialSecurityNumber
    ];

    if (contacts.isEmpty()) {
        System.debug('No contact found with the specified SSN.');
    } else {
        for (Contact c : contacts) {
            // The value of c.SSN__c will be automatically decrypted when accessed in Apex.
            System.debug('Found Contact: ' + c.FirstName + ' ' + c.LastName);
        }
    }
} catch (QueryException e) {
    System.debug('An error occurred during the SOQL query: ' + e.getMessage());
}

確率的暗号化項目に対するサポートされないクエリ

一方、取引先オブジェクトの標準項目「Description」（説明）が確率的暗号化で暗号化されているとします。この項目に対して LIKE 演算子のような部分一致検索を実行しようとすると、エラーが発生します。

// The standard Description field on the Account object is encrypted with Probabilistic Encryption.
// The following query using the 'LIKE' operator is NOT supported for probabilistically encrypted fields.
// Executing this code will result in a QueryException.

try {
    String keyword = '%confidential%';
    // This line will throw a 'QueryException: field 'Description' can not be filtered in a query call'
    // or a similar error because LIKE is not a supported operator for this encryption scheme.
    List<Account> accounts = [
        SELECT Id, Name 
        FROM Account 
        WHERE Description LIKE :keyword
    ];

    System.debug('Found ' + accounts.size() + ' accounts.');

} catch (QueryException e) {
    // The exception will be caught here.
    System.debug('Error: Querying a probabilistically encrypted field with an unsupported operator is not allowed.');
    System.debug('Exception details: ' + e.getMessage());
}

この例が示すように、アーキテクトは開発チームに対し、どの項目がどのスキームで暗号化されており、どのようなクエリがサポートされているかを明確に伝える必要があります。これらの制約を考慮せずに開発を進めると、本番環境で予期せぬエラーが発生する可能性があります。

注意事項

Shield Platform Encryption は強力なツールですが、その導入は慎重な計画を要します。アーキテクトとして、以下の点を必ず考慮に入れるべきです。

権限管理

  • 「暗号化鍵の管理 (Manage Encryption Keys)」権限： テナント秘密の生成、ローテーション、破棄といったライフサイクル管理を行うための権限です。ごく少数の信頼できる管理者にのみ付与するべきです。
  • 「暗号化されたデータの表示 (View Encrypted Data)」権限： この権限を持たないユーザーには、暗号化された項目はマスクされて表示されます。業務上、暗号化されたデータを閲覧する必要があるユーザープロファイルにのみ付与します。Principle of Least Privilege (最小権限の原則) を徹底してください。

パフォーマンスへの影響

データの暗号化・復号処理には、わずかながらサーバーサイドの処理オーバーヘッドが伴います。通常、ユーザーが体感できるほどの遅延は発生しませんが、数百万件規模のデータに対する一括処理、複雑なレポート、または API を介した大量のデータ連携などでは、パフォーマンスへの影響が顕在化する可能性があります。導入前にパフォーマンステストを実施することが不可欠です。

機能的な制限

これが最も重要な考慮事項です。暗号化された項目は、Salesforce プラットフォームの一部の機能と互換性がありません。

  • SOQL/SOSL： ORDER BY、LIKE、STARTS WITH、CONTAINS といった演算子は、暗号化された項目に対して使用できません。
  • レポートとダッシュボード： 暗号化された項目を基準としたグループ化や並び替えはサポートされていません。
  • 数式項目と入力規則： 確率的暗号化された項目を数式内で参照することはできません。
  • カスタムインデックス： 暗号化された項目にデータベースのカスタムインデックスを作成することはできません。これにより、大規模なデータセットに対するクエリのパフォーマンスが低下する可能性があります。
  • その他： リードの取引開始、ケース割り当てルール、メール-to-ケースなど、特定の自動化プロセスで暗号化項目を参照する場合、予期せぬ動作を引き起こす可能性があります。

これらの制限事項を事前に洗い出し、既存のビジネスプロセスやカスタマイズへの影響を評価し、必要であれば代替案（例えば、暗号化しない別の項目をワークフローのトリガーに使うなど）を設計する必要があります。

鍵の管理

テナント秘密の管理は、組織のセキュリティ担当者の重大な責任です。テナント秘密を紛失または破棄した場合、その鍵で暗号化されたデータは永久に復元不可能になります。必ず、テナント秘密を生成した直後に安全な場所にエクスポートし、オフラインで保管してください。また、定期的な鍵のローテーションポリシーを策定し、実行することもコンプライアンス上重要です。

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

Shield Platform Encryption は、Salesforce 内の機密データを保護し、厳しいコンプライアンス要件を満たすための非常に効果的なソリューションです。しかし、その導入は「スイッチを入れるだけ」の単純な作業ではありません。アーキテクトとして、その影響を多角的に分析し、戦略的に導入を計画する必要があります。

ベストプラクティス：

  1. 必要なものだけを暗号化する： 全ての項目を暗号化するのではなく、データ分類を実施し、法規制や社内ポリシーで保護が義務付けられている真に機密性の高いデータのみを暗号化の対象とします。過剰な暗号化は、不必要なパフォーマンス低下と機能制限を招きます。
  2. 適切な暗号化スキームを選択する： フィルタリングが業務上の必須要件でない限り、常にセキュリティ強度の高い確率的暗号化を選択します。確定的暗号化は、必要最低限の項目にのみ適用します。
  3. 鍵管理戦略を策定する： 鍵の生成、ローテーション、バックアップ、破棄に関する明確なポリシーと手順を定義します。テナント秘密のバックアップは、物理的にも論理的にも安全な場所に保管してください。
  4. 徹底的にテストする： 本番環境に展開する前に、完全な Sandbox 環境で、暗号化がビジネスプロセス、カスタムコード、レポート、インテグレーションに与える影響をすべてテストします。特に、機能制限に関連する部分は重点的に確認してください。
  5. 関係者を教育する： 管理者、開発者、そしてエンドユーザーに対し、暗号化によって検索やレポートの動作がどのように変わるかを事前に説明し、トレーニングを実施します。
  6. 継続的に監視する： Salesforce が提供する「暗号化統計」や「データ分類メタデータ」を活用し、組織の暗号化カバレッジやデータ感度レベルを定期的に監査・監視します。

Shield Platform Encryption を正しく設計・導入することで、Salesforce プラットフォームの信頼性をさらに高め、顧客と社会からの信頼を確固たるものにすることができます。アーキテクトの役割は、この強力な機能をビジネスの成功と持続可能性に繋げるための道筋を示すことです。

コメント

コメントを投稿