Salesforce Shield Platform Encryption：高度なデータセキュリティとコンプライアンスを実現するアーキテクチャ設計

日付:

背景とアプリケーションシナリオ

現代のデジタル時代において、企業はかつてないほど多くの機密データを収集・処理しており、同時にデータ漏洩のリスクや厳格化するデータプライバシー規制（GDPR、HIPAA、CCPAなど）への対応が喫緊の課題となっています。Salesforceプラットフォームは、標準で堅牢なセキュリティ機能を提供していますが、データベースに保存されたデータ（data at rest）のさらなる保護が必要となるケースがあります。特に、高度なコンプライアンス要件や内部セキュリティポリシーを満たすためには、標準のセキュリティ機能だけでは不十分な場合があります。

ここで登場するのがSalesforce Shield Platform Encryption (SPE)（セールスフォース・シールド・プラットフォーム・エンクリプション）です。これは、Salesforceの標準暗号化機能（例えば、特定の標準フィールドタイプ向けに提供される暗号化テキストフィールドなど）ではカバーしきれない、より広範なデータタイプに対して、プラットフォームレベルでの保存データ暗号化を提供する機能です。SPEは、お客様のデータがSalesforceデータベースに保存される際に暗号化を施し、承認されたユーザーがアクセスする際に透過的に復号化されるように設計されています。

Salesforceアーキテクトの視点から見ると、SPEの導入は単なる技術的な実装を超え、組織全体のデータセキュリティ戦略とコンプライアンスフレームワークの重要な一環となります。以下に、SPEが特に有効なアプリケーションシナリオを挙げます。

  • 個人識別情報 (PII: Personally Identifiable Information): 顧客の名前、住所、社会保障番号、メールアドレスなど、漏洩した場合に個人に重大な損害を与える可能性のあるデータ。
  • 保護医療情報 (PHI: Protected Health Information): 医療記録、診断結果、治療履歴など、HIPAAなどの規制に準拠する必要がある医療業界のデータ。
  • 金融口座情報: クレジットカード番号、銀行口座番号など、PCI DSS（Payment Card Industry Data Security Standard）などの金融規制に準拠する必要があるデータ。
  • 機密性の高い契約詳細や知的財産: 企業秘密、M&A関連情報、製品設計情報など、企業競争力に直結するデータ。
  • 特定の業界規制: SOX（Sarbanes-Oxley Act）、FedRAMPなどの政府関連規制、その他の地域のデータ保護法への対応。

これらのシナリオでは、データが「保存中（at rest）」の状態でも暗号化されていることが、セキュリティとコンプライアンスの両面で極めて重要になります。SPEは、これらの要件を満たすための強力なソリューションを提供します。

原理説明

Salesforce Shield Platform Encryptionは、エンベロープ暗号化 (Envelope Encryption)という概念を用いてデータを保護します。これは、データ自体を直接、顧客が管理するキーで暗号化するのではなく、データを暗号化するためのデータキーを、さらに別のマスターキーで暗号化するという二重の暗号化構造を指します。

具体的には、以下の主要な要素が連携して機能します。

  1. データ暗号化キー (Data Encryption Key): 各レコード、または特定のフィールドのデータを暗号化するために使用される一意のキーです。Salesforceはこのデータ暗号化キーを、フィールドごとに生成し、テナントシークレット (Tenant Secret)と呼ばれるキーで暗号化します。
  2. テナントシークレット (Tenant Secret): お客様が管理する暗号化キーであり、データ暗号化キーを保護するために使用されます。このテナントシークレットは、Salesforceのキー管理サービス (Key Management Service)を通じて生成および管理されます。お客様はSalesforceが生成したキーを使用することも、Bring Your Own Key (BYOK)（お客様自身のキーを持ち込む）オプションを使用して独自のキーマテリアルを導入することも可能です。
  3. マスターシークレット (Master Secret): Salesforceが管理する最高レベルのキーであり、お客様のテナントシークレットを暗号化するために使用されます。このマスターシークレットは、高セキュリティなハードウェアセキュリティモジュール（HSM: Hardware Security Module）内に保管され、厳重に管理されます。

このエンベロープ暗号化の仕組みにより、お客様のデータはテナントシークレットで保護され、そのテナントシークレット自体もSalesforceのマスターシークレットで保護されるため、多層的なセキュリティが実現されます。

キー管理 (Key Management)

SPEにおけるキー管理 (Key Management)は非常に重要です。アーキテクトは、キーの生成、保存、ローテーション、破棄に関する戦略を慎重に設計する必要があります。

  • キーローテーション (Key Rotation): セキュリティのベストプラクティスとして、定期的なキーのローテーションが推奨されます。新しいキーで暗号化されたデータには新しいテナントシークレットが適用され、古いデータも徐々に新しいキーで再暗号化されます。これにより、万一キーが侵害された場合のリスクが軽減されます。
  • キーの破棄 (Key Destruction): 不要になったテナントシークレットは安全に破棄できます。キーが破棄されると、そのキーで暗号化されたデータは永久にアクセス不可能になります。これは、特定の規制（例：忘れられる権利）に対応する際に重要な機能です。
  • BYOK (Bring Your Own Key): お客様が独自のキーマテリアルをSalesforceにアップロードしてテナントシークレットとして使用するオプションです。これにより、キーに対する管理と制御のレベルが向上しますが、キーのライフサイクル管理はお客様自身の責任となります。

暗号化の透過性 (Transparency of Encryption)

SPEの重要な特徴は、その透過性 (Transparency)です。データが暗号化されていても、適切な権限を持つユーザーや統合システムは、通常のSalesforceのインターフェースやAPIを通じてデータにアクセスできます。データが要求されると、Salesforceプラットフォームは、関連するテナントシークレットとマスターシークレットを使用して自動的にデータを復号化し、ユーザーに表示します。ユーザーは、データが暗号化されていることを意識することなく操作できます。

ただし、この透過性にはいくつかの制約が伴います。例えば、暗号化されたフィールドに対するSOQL/SOSLクエリ、レポート、検索機能、ワークフロー、検証ルールなどは、暗号化されていないフィールドとは異なる振る舞いをしたり、一部機能が制限されたりする場合があります。これらの影響を理解し、アーキテクチャ設計に組み込むことが成功の鍵となります。

APIとApexによる暗号化の利用

Salesforce Shield Platform Encryptionは、主に保存データ（data at rest）の暗号化を提供するものであり、Apexコード内でデータを直接暗号化または復号化するためのAPIを提供するものではありません。プラットフォームがユーザーの権限に基づいて自動的に暗号化と復号化を処理するため、Apex開発者は通常、暗号化されていることを意識せずにデータにアクセスできます。

つまり、ApexやAPIを通じて暗号化されたフィールドにアクセスする場合、以下の挙動になります。

  • ユーザーが「View Encrypted Data」（暗号化されたデータを表示）権限を持っている場合、Apexは復号化されたフィールドの値を受け取ります。
  • ユーザーが「View Encrypted Data」権限を持っていない場合、Apexはマスクされたフィールドの値（テキストやメールフィールドの場合）またはnull（日付、数値、その他のフィールドタイプの場合）を受け取ります。

このため、特定のカスタムロジックやインテグレーションを設計する際には、この透過性と権限によるデータの可視性の違いを考慮する必要があります。特に、クエリの挙動は重要です。

SOQL/SOSLクエリへの影響

暗号化されたフィールドに対するSOQL（Salesforce Object Query Language）やSOSL（Salesforce Object Search Language）クエリにはいくつかの制限があります。

  • WHERE句での利用: 暗号化されたフィールドは、等値比較（=）でのみ使用でき、LIKE、STARTS WITH、CONTAINS、範囲指定（<, >, <=, >=）などの演算子は使用できません。
  • ORDER BY句での利用: 暗号化されたフィールドをORDER BY句で使用することはできません。
  • インデックス: 暗号化されたフィールドは、選択性が低くなる傾向があり、標準のインデックスが効率的に機能しない場合があります。これにより、クエリのパフォーマンスに影響が出る可能性があります。

Salesforceアーキテクトは、これらのクエリ制限を考慮して、カスタム検索機能やレポート機能の設計を行う必要があります。

コード例：暗号化されたフィールドのSOQLクエリ

以下のApexコードは、Shield Platform Encryptionによって暗号化されていると仮定される「取引先責任者（Contact）」オブジェクトの「メール（Email）」フィールドをクエリする方法を示します。このコード自体が暗号化や復号化を行うわけではありません。Salesforceプラットフォームがユーザーの権限に基づいて透過的に処理する様子を示します。

// Salesforce Shield Platform Encryptionで暗号化されていると仮定される
// ContactオブジェクトのEmailフィールドをクエリするApexコードの例です。
// このコードは開発者コンソールで匿名実行としてテストできます。

List<Contact> contacts = [
    SELECT Id, FirstName, LastName, Email
    FROM Contact
    WHERE Email != null // 暗号化されたフィールドは、null値と比較することができます
    LIMIT 5
];

System.debug('--- Shield Platform Encryptionが適用されたEmailフィールドを含むクエリ結果 ---');
System.debug('※ 結果は、現在のユーザーに「View Encrypted Data」権限があるかどうかに依存します。');

if (contacts.isEmpty()) {
    System.debug('クエリに一致する取引先責任者が見つかりませんでした。');
} else {
    for (Contact c : contacts) {
        // 現在のユーザーが「View Encrypted Data」権限を持っている場合、Emailは復号化された値で表示されます。
        // 権限がない場合、Emailはマスクされた値（例: *****）またはnullとして表示されます。
        System.debug('Contact ID: ' + c.Id + 
                     ', Name: ' + c.FirstName + ' ' + c.LastName + 
                     ', Email: ' + c.Email);
    }
}

// 注意事項：
// 1. このApexコードは、暗号化自体を管理するものではありません。
//    暗号化はSalesforceプラットフォームによってバックグラウンドで透過的に処理されます。
// 2. 暗号化されたフィールドをWHERE句で使用する場合、等値比較（=）はサポートされますが、
//    部分一致検索（LIKEなど）や範囲検索（>, <など）はサポートされません。
// 3. ユーザーのセキュリティ設定（プロファイルまたは権限セット）で
//    「View Encrypted Data」権限が付与されているかを確認してください。
//    この権限がない場合、APIやApex経由でのアクセスでも、テキストフィールドはマスクされ、
//    その他のフィールドタイプはnullとして表示されます。

この例では、ごく通常のSOQLクエリを使用していますが、その結果の表示がユーザーの権限によって変化する点がShield Platform Encryptionの透過性の特徴です。アーキテクトは、カスタムコンポーネントやインテグレーションが、この暗号化されたデータの挙動を正しく処理し、セキュリティ要件を満たしているかを確認する責任があります。

注意事項

Salesforce Shield Platform Encryptionは強力なセキュリティ機能ですが、導入にはいくつかの重要な考慮事項があります。アーキテクトは、これらの要素を包括的に評価し、システム全体への影響を最小限に抑えるよう設計する必要があります。

パフォーマンスへの影響 (Performance Impact)

  • クエリと検索のパフォーマンス: 暗号化されたフィールドに対するSOQL/SOSLクエリ、レポート、検索のパフォーマンスが低下する可能性があります。特に、等値比較以外の条件での検索や、大量のデータに対するクエリでは顕著です。これは、暗号化により標準のインデックスが効率的に使用できなくなるためです。
  • レコードの保存と更新: レコードの保存時や更新時に暗号化・復号化の処理が追加されるため、わずかにパフォーマンスに影響が出る可能性があります。

機能制限 (Feature Limitations)

暗号化されたフィールドには、以下の機能制限が適用されます。

  • フィールドタイプ: 数式項目、自動採番項目、外部IDとして設定されたフィールドは暗号化できません。
  • ユニークフィールドと外部ID: 暗号化されたフィールドはユニーク属性を持つことができません。また、外部IDとして使用することもできません。これは、外部システムとの統合設計に影響を与えます。
  • 検索とレポート: ワイルドカード検索、部分文字列検索、範囲クエリはサポートされません。レポートのフィルタリングや集計機能にも制限が生じる場合があります。
  • ワークフロー、プロセスビルダー、フロー: 暗号化されたフィールドは、条件式や更新アクションの入力として使用できない場合があります。
  • 検証ルールと承認プロセス: 暗号化されたフィールドを検証ルールや承認プロセスの条件式で使用することは制限されます。
  • メールテンプレート: 暗号化されたフィールドの値は、標準のメールテンプレートやLightningメールテンプレートの差し込み項目として表示できません。
  • Salesforce Connect: Salesforce Connect（外部データソース）の外部オブジェクト上のフィールドは暗号化できません。
  • Salesforce DX: スクラッチ組織の作成やデータローディングにおいて、暗号化されたフィールドの挙動を理解しておく必要があります。

権限管理 (Permission Management)

  • 「View Encrypted Data」権限: 暗号化されたフィールドの復号化された値を見るためには、ユーザーまたは統合システムに「View Encrypted Data」権限が付与されている必要があります。この権限は非常に強力であるため、最小特権の原則 (Principle of Least Privilege)に基づき、厳格に管理されるべきです。

キー管理 (Key Management)

  • テナントシークレットの管理: キーローテーションのスケジュール、BYOKを使用する場合のキーのライフサイクル管理、キーのバックアップとリカバリ戦略を策定する必要があります。キーが失われた場合、そのキーで暗号化されたデータは永久にアクセス不可能になるリスクがあります。
  • 監査ログ: キーの変更、生成、破棄などのキー管理操作は、セキュリティ監査のためにログに記録されるべきです。

既存の統合とカスタム開発への影響 (Impact on Integrations and Custom Development)

  • API連携: 外部システムからのAPIアクセスも、「View Encrypted Data」権限の有無によってデータがマスクされるか復号化されるかが決まります。統合ユーザーの権限設計は極めて重要です。
  • AppExchangeアプリ: インストール済みのAppExchangeアプリが暗号化されたフィールドとどのように連携するかを確認し、必要に応じてベンダーと調整する必要があります。
  • カスタム検索とレポート: 既存のカスタムApexコードやVisualforceページ、Lightning Webコンポーネントが暗号化されたフィールドを使用している場合、クエリの制限に合わせて修正が必要になる可能性があります。

テスト戦略 (Testing Strategy)

  • 包括的なテスト: SPEの導入後、ユーザーエクスペリエンス、レポート、統合、カスタム開発が期待通りに機能するかを徹底的にテストする必要があります。特に、「View Encrypted Data」権限の有無によるデータの表示差異を検証することが重要です。
  • パフォーマンスベンチマーク: 暗号化前と後で、主要なクエリやレポートのパフォーマンスを比較し、許容範囲内であることを確認します。

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

Salesforce Shield Platform Encryptionは、組織の最も機密性の高いデータをSalesforceプラットフォーム上で保護するための、非常に効果的なツールです。しかし、その導入は単なる技術的な設定に留まらず、広範な計画と慎重なアーキテクチャ設計を必要とします。

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

  • データ分類の実施 (Data Classification): 最初に、どのデータが本当に暗号化を必要とするのかを特定します。すべてのデータを暗号化する必要はなく、機密性レベルに基づいて優先順位をつけます。過度な暗号化は、パフォーマンスや機能に不必要な影響を与える可能性があります。
  • 綿密な影響分析 (Comprehensive Impact Analysis): SPEを導入する前に、既存のビジネスプロセス、レポート、統合、カスタム開発、およびユーザーエクスペリエンスへの影響を詳細に評価します。機能制限とパフォーマンスへの影響を明確に理解することが不可欠です。
  • キー管理戦略の策定 (Key Management Strategy): テナントシークレットの生成、保存、ローテーション、破棄に関する明確なポリシーと手順を確立します。BYOKを使用する場合は、その責任とプロセスを詳細に定義します。
  • 段階的な導入 (Phased Rollout): SPEの導入は、一度にすべてのフィールドに適用するのではなく、制御された段階的なアプローチで実施することを検討します。これにより、予期せぬ問題を早期に特定し、リスクを軽減できます。
  • 最小特権の原則の適用 (Apply Principle of Least Privilege): 「View Encrypted Data」権限は、本当に必要とするユーザーと統合システムのみに付与します。この権限の過剰な付与は、暗号化の価値を損ないます。
  • 堅牢なテスト計画 (Robust Testing Plan): 暗号化が有効になった後、システム全体が意図した通りに機能し、ユーザーエクスペリエンスが損なわれていないことを確認するための包括的なテスト計画を作成し実行します。
  • 継続的な監視と監査 (Continuous Monitoring and Auditing): 暗号化されたデータのアクセス、キー管理操作、システムのパフォーマンスを継続的に監視し、セキュリティ監査を実施します。
  • ユーザーと開発者へのトレーニング (Training for Users and Developers): 暗号化されたデータの取り扱い方、特に機能制限について、関係者全員が理解していることを確認します。

Shield Platform Encryptionの導入は、Salesforceエコシステム全体のセキュリティ態勢を強化する上で大きな一歩となります。技術的な専門知識だけでなく、組織のセキュリティポリシー、コンプライアンス要件、そしてビジネスニーズとの整合性を考慮した、戦略的なアプローチが成功には不可欠です。

コメント

コメントを投稿