エンタープライズアーキテクトのためのSalesforce Shield Platform Encryption徹底解説

背景と応用シナリオ

Salesforce 架构师 (Salesforceアーキテクト) の視点から、今日のデジタル環境における最も重要な課題の一つは、データのセキュリティとコンプライアンスの確保です。企業が顧客の信頼を維持し、GDPR (一般データ保護規則)、HIPAA (医療保険の相互運用性と説明責任に関する法律)、CCPA (カリフォルニア州消費者プライバシー法) といった厳格な規制要件を遵守するためには、堅牢なデータ保護戦略が不可欠です。Salesforceは標準で基本的なセキュリティ機能を提供していますが、機密性の高いデータを扱う大企業や特定業界では、より高度な保護レベルが求められます。

ここで登場するのが Shield Platform Encryption (シールドプラットフォーム暗号化) です。これは、Salesforceのデータベース内に保存されているデータ、すなわち「data at rest (保存時データ)」を暗号化するためのプレミアムサービスです。標準の暗号化が特定の種類のカスタムテキスト項目に限定されるのに対し、Shield Platform Encryptionは標準項目、カスタム項目、ファイル、添付ファイルなど、はるかに広範なデータを対象とすることができます。

応用シナリオは多岐にわたります：

金融サービス： 口座番号、社会保障番号(SSN)、取引履歴などの個人識別情報(PII)や財務情報を保護します。
医療・ライフサイエンス： 患者のカルテ、診断情報、保険情報などの保護された医療情報(PHI)をHIPAA要件に準拠した形で保護します。
公共部門： 市民の機密データや法執行に関する情報を保護し、政府の規制を遵守します。
小売業： 顧客の連絡先情報、購買履歴、ロイヤリティプログラムのデータなど、マーケティング活動や顧客サービスに使用される機密情報を保護します。

アーキテクトとしてShield Platform Encryptionを評価する際、単に「データを暗号化する」という機能だけでなく、それがビジネスプロセス、システムパフォーマンス、インテグレーション、そして全体的なセキュリティ体制にどのような影響を与えるかを総合的に考慮する必要があります。

原理説明

Shield Platform Encryptionのアーキテクチャは、多層的な鍵管理モデルに基づいており、セキュリティと管理の柔軟性を両立させています。このモデルを理解することは、効果的な導入計画を立てる上で極めて重要です。

鍵階層 (Key Hierarchy)

Shieldは、階層的な鍵派生アーキテクチャを採用しています。これにより、鍵の漏洩リスクを最小限に抑え、効率的な鍵のローテーション（定期的な更新）を可能にします。

Master Secret (マスターシークレット): Salesforceが安全なハードウェアセキュリティモジュール(HSM)内で管理する最上位の鍵です。四半期ごとにリリースに合わせて更新されます。顧客はこの鍵に直接アクセスすることはできません。
Tenant Secret (テナントシークレット): これはお客様が管理する鍵です。Salesforce組織ごとに生成され、お客様は鍵のライフサイクル（生成、有効化、ローテーション、破棄）を完全にコントロールできます。このテナントシークレットとマスターシークレットが組み合わされて、最終的なデータ暗号鍵が派生します。
Data Encryption Key (データ暗号化鍵): 実際にデータを暗号化および復号化するために使用される鍵です。テナントシークレットから派生し、使用後はメモリから破棄されるため、データベース内に平文で保存されることはありません。

このアーキテクチャの最大の利点は、BYOK (Bring Your Own Key - 独自の鍵を持ち込む) をサポートしている点です。これにより、企業は自社のセキュリティポリシーに従って、自社で生成・管理するテナントシークレットをSalesforceにアップロードできます。鍵の管理責任を自社で持つことで、コンプライアンス要件をより厳格に満たすことが可能になります。

暗号化スキームの種類

Shield Platform Encryptionは、暗号化する項目に対して2種類の暗号化スキームを提供しており、アーキテクトはセキュリティ要件と機能要件のトレードオフを考慮して選択する必要があります。

1. Probabilistic Encryption (確率的暗号化):
これはデフォルトで最も安全なスキームです。同じ平文データであっても、暗号化するたびに異なる暗号文が生成されます。これは初期化ベクトル(IV)を使用するためです。セキュリティレベルは非常に高いですが、その代償として、暗号化された項目をSOQLの`WHERE`句での絞り込み、`ORDER BY`でのソート、`GROUP BY`での集計などに使用できなくなります。レポートやリストビューでのフィルタリングも不可能です。

2. Deterministic Encryption (確定的暗号化):
このスキームでは、同じ平文データは常に同じ暗号文に変換されます（同じテナントシークレットを使用している限り）。これにより、SOQLの`WHERE`句で完全一致（= や IN）による絞り込みが可能になります。レポートやリストビューでのフィルタリングもサポートされます。ただし、暗号文のパターンから元のデータに関する情報が漏洩する可能性があるため、確率的暗号化に比べてセキュリティレベルは若干低下します。確定的暗号化には、大文字と小文字を区別する (Case-Sensitive) スキームと区別しない (Case-Insensitive) スキームがあります。

アーキテクトとしての重要な判断は、「その項目はフィルタリングや検索の要件があるか？」という点です。要件がなければ常に確率的暗号化を選択し、必要な場合にのみ、リスクを評価した上で確定的暗号化を選択するべきです。

サンプルコード

Shield Platform Encryptionは主に宣言的な設定（ポイント＆クリック）で有効化するため、Apexコードで直接暗号化プロセスを制御することはありません。しかし、開発者やインテグレーションエンジニアが暗号化されたデータを扱う際には、その挙動を理解しておく必要があります。特に、確定的暗号化された項目のクエリ方法が重要です。以下のコードは、確定的暗号化（大文字と小文字を区別）で暗号化された取引先責任者の「SSN__c」というカスタム項目をSOQLで照会する例です。

// このコードは、確定的暗号化スキームで暗号化された
// 取引先責任者オブジェクトのカスタム項目「SSN__c」（社会保障番号）を
// SOQLクエリで検索する例を示しています。

// 検索するSSNの値を定義します。
// 確定的暗号化（大文字・小文字を区別）の場合、完全に一致する文字列でなければ
// レコードを見つけることはできません。
String ssnToFind = '123-456-7890';

// SOQLクエリを実行します。
// WHERE句で暗号化された項目「SSN__c」を直接指定できます。
// これは、この項目が「確定的暗号化」で設定されているため可能です。
// もし「確率的暗号化」で暗号化されていた場合、このクエリはエラーにはなりませんが、
// データベースレベルでインデックスが使用できないため、一件もレコードを返しません。
List<Contact> matchingContacts = [
    SELECT Id, FirstName, LastName, Email, SSN__c 
    FROM Contact 
    WHERE SSN__c = :ssnToFind
];

// 検索結果を確認します。
if (matchingContacts.isEmpty()) {
    // レコードが見つからなかった場合の処理
    System.debug('SSNが ' + ssnToFind + ' の取引先責任者は見つかりませんでした。');
} else {
    // レコードが見つかった場合の処理
    for (Contact c : matchingContacts) {
        // System.debugで出力されるSSN__cの値は、このコードを実行しているユーザーが
        // 「暗号化されたデータの表示」権限を持っている場合に限り、復号化された平文で表示されます。
        // 権限がない場合、項目はマスクされて表示されます（例：'************'）。
        System.debug('ID: ' + c.Id + ', Name: ' + c.FirstName + ' ' + c.LastName + ', SSN: ' + c.SSN__c);
    }
}

⚠️ 上記のコード例は、Salesforce Developerドキュメントの概念に基づいており、確定的暗号化フィールドがSOQLの `WHERE` 句でどのように機能するかを示しています。これは公式ドキュメントでサポートされている動作です。

注意事項

Shield Platform Encryptionは強力なツールですが、導入には慎重な計画が必要です。アーキテクトとして、以下の制限事項とトレードオフを十分に理解し、ステークホルダーに説明する責任があります。

機能上の制限

SOQL/SOSL: 暗号化された項目は、`LIKE`演算子、`STARTS WITH`、`CONTAINS`などの部分一致検索では使用できません。また、`ORDER BY`句でのソートや、`GROUP BY`、`COUNT(DISTINCT)`などの集計関数にも使用できません。
数式とワークフロー: 暗号化された項目を数式項目、ワークフロールール、入力規則で直接参照すると、予期しない動作をする可能性があります。暗号化された値は常にマスクされた状態で評価されるためです。
レポートとダッシュボード: 確定的暗号化を使用しない限り、暗号化された項目でレポートをグループ化したり、フィルタリングしたりすることはできません。
インデックス: データベースインデックスは暗号化されていないデータに対して作成されるため、暗号化された項目に対するクエリのパフォーマンスは、非暗号化項目に比べて低下する可能性があります。確定的暗号化では限定的なインデックスが利用できますが、それでもパフォーマンスへの影響は考慮すべきです。
インテグレーション: 外部システムがAPI経由でSalesforceからデータを取得する場合、APIユーザーが「暗号化されたデータの表示」権限を持っていればデータは自動的に復号化されて渡されます。しかし、権限がない場合はマスクされたデータが返されるため、インテグレーションの動作に影響を与える可能性があります。

権限管理

「View Encrypted Data (暗号化されたデータの表示)」権限が、暗号化されたデータを復号化して表示するための鍵となります。この権限は非常に強力であるため、最小権限の原則に従い、本当に必要なユーザー（例えば、カスタマーサービスの上級担当者や人事担当者など）にのみ付与するべきです。この権限を不用意にシステム管理者に割り当てると、暗号化の目的が損なわれる可能性があります。

鍵管理の責任

テナントシークレットの管理は、お客様の責任です。鍵をローテーションするポリシーを策定し、定期的に実行する必要があります。また、テナントシークレットを破棄すると、その鍵で暗号化されたデータは永久に復元できなくなります。これは「暗号シュレッディング」と呼ばれ、データの完全消去が必要な場合に意図的に使用されることもありますが、誤って実行すると壊滅的な結果を招きます。鍵のバックアップと、破棄プロセスの厳格な管理が不可欠です。

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

Shield Platform Encryptionは、Salesforceプラットフォーム上で最高レベルのデータ保護を実現するための、エンタープライズグレードのソリューションです。しかし、その導入は単なる技術的な作業ではなく、ビジネス要件、コンプライアンス、システム全体のアーキテクチャを考慮した戦略的な決定です。

Salesforceアーキテクトとして推奨するベストプラクティスは以下の通りです。

データ分類の実施: 最初に、組織内のどのデータが機密情報であり、暗号化が必要かを特定します。すべてのデータを暗号化するのではなく、規制や社内ポリシーで要求される最も重要なデータに絞り込むことで、パフォーマンスへの影響と管理の複雑さを最小限に抑えます。
適切な暗号化スキームの選択: 原則として、セキュリティが最も高い確率的暗号化をデフォルトとします。フィルタリングやレポート要件がビジネス上必須である項目に限り、リスクを評価した上で確定的暗号化を選択します。
厳格な鍵管理ポリシーの策定: 誰が鍵を管理し、どのくらいの頻度でローテーションし、どのようにバックアップし、どのような承認プロセスで破棄するかを明確に定義したポリシーを文書化し、徹底します。BYOKを利用する場合は、その鍵生成・保管インフラのセキュリティも重要です。
サンドボックスでの徹底的なテスト: 本番環境に導入する前に、必ずFull Sandboxなどの環境でShield Platform Encryptionを有効にし、すべての主要なビジネスプロセス、レポート、ダッシュボード、インテグレーション、Apexコード、Visualforceページが期待通りに動作するかをテストします。特にパフォーマンスへの影響を測定することが重要です。
権限の最小化: 「暗号化されたデータの表示」権限の付与は厳格に管理します。ユーザーの役割に基づいて、本当にそのデータへのアクセスが必要な担当者にのみ権限を割り当てます。
継続的な監視と監査: イベントモニタリングなどを活用し、誰が暗号化されたデータにアクセスしたか、鍵の管理操作がいつ行われたかを監視・監査する体制を整えます。

これらのプラクティスに従うことで、Shield Platform Encryptionの強力なセキュリティ機能を最大限に活用し、ビジネスを保護しながら、Salesforceプラットフォームの価値を最大化するアーキテクチャを構築することが可能になります。

にゃんこのSalesforce日記

このブログを検索