Salesforce アーキテクトが指南する Shield Platform Encryption 戦略的活用ガイド

Salesforce アーキテクトとして、皆様の Salesforce 環境における最も重要な資産、すなわち「データ」をいかに保護するかという課題に日々向き合っています。近年、GDPR (一般データ保護規則) や CCPA (カリフォルニア州消費者プライバシー法) といったデータ保護規制はますます厳格化しており、企業は顧客の信頼を維持し、コンプライアンスを遵守するために、これまで以上に高度なセキュリティ対策を求められています。この記事では、Salesforce が提供する最高レベルのデータ保護ソリューションである Shield Platform Encryption (シールドプラットフォーム暗号化) について、アーキテクトの視点からその戦略的な活用法を徹底的に解説します。

背景と応用シナリオ

Salesforce は、標準で強力なセキュリティ機能を提供していますが、特定の業界（金融、医療、公共など）や、極めて機密性の高い個人情報 (PII) や保護医療情報 (PHI) を扱う企業にとっては、もう一段階上のデータ保護レイヤーが必要となる場合があります。Shield Platform Encryption は、まさにこの「保存時の暗号化 (Encryption at Rest)」を実現するためのアドオン製品です。

単にデータを暗号化するだけでなく、企業のコンプライアンス要件を満たし、内部および外部の脅威からデータを保護するための包括的なフレームワークを提供します。アーキテクトとして、私たちは Shield Platform Encryption を単なる機能として捉えるのではなく、企業のセキュリティアーキテクチャ全体における重要な構成要素として位置づける必要があります。

主な応用シナリオ

コンプライアンス遵守: HIPAA、PCI DSS、GDPR などの規制要件で求められるデータ暗号化基準を満たす。
機密データの保護: 個人識別情報 (PII)、財務情報、知的財産など、漏洩した場合にビジネスに甚大な影響を与えるデータを保護する。
内部脅威からの防御: システム管理者であっても、暗号化されたデータへの直接的なアクセスを制御し、データの不正な閲覧や持ち出しリスクを低減する。
顧客との信頼構築: 顧客データを最高レベルのセキュリティで保護していることを示し、ブランドの信頼性を向上させる。

原理説明

Shield Platform Encryption のアーキテクチャは、多層的な鍵管理モデルに基づいています。このモデルを理解することは、そのセキュリティ強度と運用方法を把握する上で不可欠です。

鍵階層モデル

Shield の暗号化は、以下の3つの鍵から構成される階層構造になっています。

Master Secret (マスターシークレット): Salesforce が管理する、リリースごとに更新される最上位の鍵です。この鍵は安全な場所に保管されており、顧客が直接アクセスすることはありません。
Tenant Secret (テナントシークレット): お客様自身が生成し、管理する組織固有の鍵です。これは Shield Platform Encryption の心臓部であり、お客様がデータの暗号化を完全にコントロールできる根拠となります。この Tenant Secret は、Salesforce には保存されず、お客様がダウンロードして安全に保管する必要があります。
Data Encryption Key (データ暗号化キー): Master Secret と Tenant Secret を Key Derivation Function (KDF - 鍵導出関数) に通すことで生成されます。実際にレコードの各項目を暗号化・復号化するために使用されるのは、このデータ暗号化キーです。この仕組みにより、Salesforce の従業員でさえも、お客様の Tenant Secret なしにはデータを復号化できないという強力なセキュリティが担保されます。

また、より高度なセキュリティ要件を持つお客様のために、Bring Your Own Key (BYOK - 鍵の持ち込み) という選択肢も提供されています。これにより、お客様は自社のハードウェアセキュリティモジュール (HSM) で生成した鍵を Salesforce にアップロードし、Tenant Secretとして利用できます。これは、鍵のライフサイクルを完全に自社で管理したい場合に最適なソリューションです。

確率的暗号化と確定的暗号化

Shield Platform Encryption を設計する上で最も重要な決定事項の一つが、暗号化タイプの選択です。Shield は2種類の暗号化スキームを提供しており、それぞれに特性とトレードオフが存在します。

Probabilistic Encryption (確率的暗号化): これは最も安全な暗号化方式です。同じ平文（元のデータ）を暗号化しても、毎回異なる暗号文が生成されます。これは Initialization Vector (IV - 初期化ベクトル) と呼ばれるランダムなデータを暗号化プロセスに加えることで実現されます。その結果、暗号文から元の値を推測することが極めて困難になりますが、代償として、暗号化された項目を SOQL の WHERE 句でフィルタリングしたり、レポートでグルーピングしたりすることはできません。

Deterministic Encryption (確定的暗号化): この方式では、同じ平文は常に同じ暗号文に変換されます。これは静的な IV を使用するためです。これにより、SOQL の WHERE 句で完全一致による絞り込みが可能になるなど、プラットフォーム上での機能性が大幅に向上します。ただし、暗号文のパターンから元のデータの分布が推測される可能性があるため、確率的暗号化に比べると理論上のセキュリティ強度はわずかに低下します。確定的暗号化には、大文字と小文字を区別する (Case-Sensitive) オプションと、区別しない (Case-Insensitive) オプションがあります。

アーキテクトとしては、項目の用途（フィルタリングやレポートでの使用頻度）とデータの機密レベルを天秤にかけ、最適な暗号化タイプを項目ごとに選択する戦略的な判断が求められます。

サンプルコード

Shield Platform Encryption は主に宣言的な設定で有効化しますが、その影響は Apex や SOQL などの開発コンポーネントに直接及びます。特に、確定的暗号化された項目をクエリする方法を理解しておくことは重要です。

以下のコードは、取引先責任者オブジェクトの `Email` 項目が確定的暗号化 (大文字・小文字を区別) で暗号化されている場合の SOQL クエリの例です。

/*
 * Email項目が確定的暗号化スキームで暗号化されていると仮定します。
 * このような場合、WHERE句で等価演算子（=）やIN演算子を使用した
 * フィルタリングが可能です。
 *
 * このクエリは、指定されたメールアドレスに完全に一致する取引先責任者を
 * 検索します。この操作は、Salesforceのデータベース内で安全に実行され、
 * アプリケーションサーバーにデータが渡される前にフィルタリングが完了します。
 */
List<Contact> encryptedContacts = [
    SELECT Id, Name, Email
    FROM Contact
    WHERE Email = 'j.doe@universalcontainers.com'
];

// 取得したレコードの件数を出力
System.debug('Found ' + encryptedContacts.size() + ' matching contacts.');

for(Contact c : encryptedContacts) {
    // ユーザーが「暗号化されたデータの表示」権限を持っている場合、
    // Email項目は自動的に復号化されて表示されます。
    // 権限がない場合、この項目はマスクされた値（例: '************'）
    // として返されます。
    System.debug('Contact Name: ' + c.Name + ', Email: ' + c.Email);
}

コードに関する重要な注意点:

このクエリが機能するのは、`Email` 項目が確定的暗号化されている場合のみです。確率的暗号化された項目は、WHERE 句で使用することはできません。
`LIKE` 句、`STARTS WITH` 句、`CONTAINS` 句などの部分一致検索や、`>`、`<` などの不等号を使用したフィルタリングは、暗号化された項目に対してはサポートされていません。
`ORDER BY` 句を使用して暗号化された項目でソートすることもできません。

注意事項

Shield Platform Encryption の導入は、システムのアーキテクチャに広範な影響を与えます。導入を計画する際には、以下の点に細心の注意を払う必要があります。

権限管理

暗号化されたデータを扱うためには、2つの重要な権限セットがあります。

Manage Encryption Keys (暗号化キーの管理): Tenant Secret の生成、アップロード、ローテーション（定期的な更新）を行う権限です。この権限は、ごく少数の信頼できるシステム管理者にのみ付与すべきです。
View Encrypted Data (暗号化されたデータの表示): 暗号化された項目を復号化して表示する権限です。ビジネス要件に基づき、必要最小限のユーザープロファイルや権限セットにのみ割り当ててください。この権限を持たないユーザーには、データはマスクされて表示されます。

機能的な制約

暗号化は、Salesforce プラットフォームの一部の機能に制約を及ぼします。これらを事前に把握し、代替案を検討することがアーキテクトの役割です。

サポートされない項目: 一部の標準項目や、複合項目（住所など）、数式項目などは暗号化できません。
SOQL とレポート: 前述の通り、WHERE 句や ORDER BY 句での使用に大きな制約があります。特にレポートやダッシュボードの要件を詳細に確認し、確定的暗号化で対応できるか、あるいは要件自体を見直す必要があるかを判断しなければなりません。
自動化ロジック: 暗号化された項目は、ワークフロールールの条件や、数式項目、入力規則、重複ルールなどで直接参照することができません。これらのロジックは、暗号化されていない別の項目を利用するなどの回避策が必要です。
インテグレーション: 外部システムと API 連携を行っている場合、インテグレーションユーザーが「暗号化されたデータの表示」権限を持っていなければ、API 経由で取得されるデータは暗号化されたまま（またはマスクされた状態）になります。これは連携先のシステムで問題を引き起こす可能性があるため、事前の影響調査と設計が不可欠です。

パフォーマンスへの影響

データの暗号化・復号化プロセスには、わずかながらサーバーの処理オーバーヘッドが伴います。ほとんどのユースケースでは体感できるほどの遅延は発生しませんが、大量のデータを一括で処理するバッチ処理や、複雑なクエリを実行する Visualforce ページなど、パフォーマンスが重視される箇所については、サンドボックス環境で十分な性能テストを実施することを強く推奨します。

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

Shield Platform Encryption は、Salesforce 上の機密データを保護するための非常に強力なツールです。しかし、その力を最大限に引き出し、意図しない副作用を避けるためには、戦略的な計画と設計が不可欠です。最後に、Salesforce アーキテクトとして推奨するベストプラクティスを以下にまとめます。

脅威モデリングとデータ分類の実施: 「何を」「なぜ」暗号化するのかを明確に定義します。すべてのデータを暗号化するのではなく、ビジネスインパクトとリスク評価に基づいて、本当に保護が必要なデータのみを対象とします。
暗号化タイプの戦略的選択: 各項目について、検索、フィルタリング、レポートの要件を精査し、セキュリティと機能性のバランスを考慮して確率的暗号化と確定的暗号化を使い分けます。
厳格な鍵管理ポリシーの策定: Tenant Secret のバックアップ手順、保管場所、鍵のローテーションサイクルを文書化し、厳格に運用します。Tenant Secret を紛失すると、関連するデータは二度と復元できなくなるため、これは最も重要なプロセスです。
サンドボックスでの徹底的なテスト: 本番環境に適用する前に、Full Sandbox などの環境で、暗号化が既存のビジネスプロセス、インテグレーション、カスタムコードに与える影響を徹底的にテストします。
ステークホルダーへの影響周知: 暗号化によって生じる機能的な制約（例：レポートでの絞り込みができない）について、開発者、システム管理者、そしてビジネスユーザーに至るまで、すべての関係者に事前に情報共有し、理解を得ることがプロジェクト成功の鍵です。
多層防御 (Defense in Depth) の実践: Shield Platform Encryption はセキュリティの一つの層に過ぎません。項目レベルセキュリティ、プロファイル、権限セット、Transaction Security Policy など、他の Salesforce セキュリティ機能と組み合わせることで、より堅牢なセキュリティアーキテクチャを構築します。

適切な計画と設計をもって Shield Platform Encryption を導入することで、皆様の Salesforce 環境は、コンプライアンス要件を満たし、顧客の信頼を勝ち取るための強固なセキュリティ基盤となるでしょう。

にゃんこのSalesforce日記

このブログを検索