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

日付:

背景と応用シナリオ

現代のビジネス環境において、データは最も価値ある資産の一つです。しかし、その価値と同時に、データ漏洩や不正アクセスといったリスクも増大しています。特に、GDPR (一般データ保護規則)、CCPA (カリフォルニア州消費者プライバシー法)、日本の改正個人情報保護法など、世界中のデータ保護規制はますます厳格化しており、企業は顧客の機密情報を保護するための高度なセキュリティ対策を講じる責任を負っています。

Salesforce は、プラットフォームレベルで様々なセキュリティ機能を提供していますが、その中でも特に強力なデータ保護ソリューションが Shield Platform Encryption です。これは、Salesforce に保存されている「保存データ (Data at Rest)」を暗号化するためのアドオン製品です。Salesforce の標準機能にも「項目 (テキスト) の暗号化 (Classic Encryption)」が存在しますが、Shield Platform Encryption はそれをはるかに超える広範かつ堅牢な暗号化機能を提供します。

Salesforce アーキテクトとして、私たちは単に機能を有効化するだけでなく、それがビジネスプロセス、システムパフォーマンス、そして全体的なエンタープライズアーキテクチャにどのような影響を与えるかを深く理解する必要があります。Shield Platform Encryption の導入は、以下のようなシナリオで特に重要となります。

規制コンプライアンスの遵守

金融サービス業界 (FISC 安全対策基準、PCI DSS)、医療・ライフサイエンス業界 (HIPAA)、公共部門など、特定の規制要件を持つ業界では、PII (Personally Identifiable Information - 個人識別情報) や PHI (Protected Health Information - 保護対象保健情報) などの機密データを暗号化することが法的に義務付けられている場合があります。Shield は、これらのコンプライアンス要件を満たすための強力なツールとなります。

社内セキュリティポリシーの強化

法規制だけでなく、企業の内部セキュリティポリシーや顧客との契約において、最高レベルのデータ保護が求められるケースがあります。Shield を導入することで、データベースレベルでの不正アクセスやデータ窃盗のリスクを最小限に抑え、「Defense in Depth (多層防御)」のセキュリティ戦略を実現できます。

顧客信頼の獲得

顧客データの保護に真摯に取り組む姿勢を示すことは、企業のブランド価値と顧客からの信頼を高める上で不可欠です。Shield Platform Encryption のような高度なセキュリティ対策を導入していることは、企業のセキュリティ意識の高さを証明する強力な証となります。

原理説明

Shield Platform Encryption のアーキテクチャを理解する上で最も重要なのは、その鍵管理の仕組みと、データがどのように暗号化・復号されるかのプロセスです。これは、他の暗号化ソリューションとは一線を画す、Salesforce 独自の高度なアプローチを採用しています。

鍵の階層構造 (Key Hierarchy)

Shield は、複数の鍵を階層的に使用してデータを保護します。この階層構造により、セキュリティと管理の柔軟性が大幅に向上します。

1. Master Secret (マスターシークレット):
最上位に位置する鍵で、Salesforce によって厳重に管理されています。これは、リリースごとに生成され、Hardware Security Module (HSM - ハードウェアセキュリティモジュール) と呼ばれる専用の物理デバイス内に安全に保管されます。私たち顧客や Salesforce の従業員でさえ、この Master Secret に直接アクセスすることはできません。

2. Tenant Secret (テナントシークレット):
これは、各 Salesforce 組織 (テナント) ごとに顧客自身が生成・管理する鍵です。Salesforce 管理者が組織内で生成するか、後述する BYOK を使用してアップロードします。この Tenant Secret は Master Secret によって暗号化されてデータベースに保存されます。テナントシークレットの管理（生成、有効化、ローテーション、破棄）は、顧客の責任範囲となります。

3. Data Encryption Keys (DEKs - データ暗号化鍵):
実際に個々のデータを暗号化・復号するために使用される鍵です。DEK は、Master Secret と現在の Tenant Secret から派生して生成されます。この DEK が、標準項目、カスタム項目、ファイル、添付ファイルなどのデータを直接暗号化します。DEK はアプリケーションサーバーのキャッシュに安全に保持され、ユーザーが暗号化されたデータにアクセスする際に透過的に使用されます。

この階層的なアプローチにより、万が一 Tenant Secret が危殆化した場合でも、新しい Tenant Secret を生成・有効化（鍵のローテーション）することで、新しいデータは新しい DEK で保護されるようになります。また、Tenant Secret を破棄すると、それに紐づく DEK も無効となり、データは永久に復元不可能になります。これは非常に強力な機能であると同時に、慎重な運用が求められる点です。

BYOK (Bring Your Own Key)

より高度な鍵管理が求められる企業向けに、Shield は BYOK (Bring Your Own Key - 顧客提供の鍵) 機能を提供しています。これにより、企業は自社のインフラストラクチャで生成した Tenant Secret を Salesforce にアップロードして使用することができます。

BYOK のプロセスは以下の通りです。

  1. Salesforce から公開鍵と証明書をダウンロードします。
  2. 企業は、自社の HSM や鍵管理システムを使用して 256 ビットの Tenant Secret を生成します。
  3. 生成した Tenant Secret を Salesforce からダウンロードした公開鍵で暗号化します。
  4. 暗号化された Tenant Secret と証明書を Salesforce にアップロードします。

BYOK を採用することで、企業は Tenant Secret のライフサイクル（生成から破棄まで）を完全に自社の管理下に置くことができます。これにより、規制当局や監査人に対して、鍵の管理が独立して行われていることを証明でき、最高レベルのコンプライアンス要件を満たすことが可能になります。アーキテクトとしては、BYOK を導入するかどうかは、企業のセキュリティポリシー、コンプライアンス要件、そして鍵管理の運用能力を総合的に評価して決定する必要があります。

示例コード

Shield Platform Encryption は主に宣言的な設定（ポイント＆クリック）で有効化されるため、それを実装するための特定の Apex コードは存在しません。しかし、開発者やアーキテクトにとって重要なのは、暗号化が有効になった項目が Apex や SOQL でどのように振る舞うかを理解することです。

暗号化されたデータは、適切な権限（「暗号化されたデータの表示」権限）を持つユーザーがアクセスした場合、アプリケーション層で自動的に復号されます。つまり、Apex コード内で特別な復号処理を記述する必要はありません。

以下の SOQL クエリの例は、暗号化されたカスタム項目 `Social_Security_Number__c` を持つ `Contact` オブジェクトを照会するものです。 

// このコードは developer.salesforce.com の SOQL と SOSL のリファレンスに基づいています。
// Shield Platform Encryption が有効な環境でのクエリの動作を示します。

// 取引先責任者 (Contact) オブジェクトから特定の社会保障番号を持つレコードを検索します。
// Social_Security_Number__c は Shield Platform Encryption で暗号化されていると仮定します。
// このクエリを実行するユーザーは「暗号化されたデータの表示」権限を持っている必要があります。

List<Contact> contacts = [
    SELECT Id, Name, Social_Security_Number__c
    FROM Contact
    WHERE Social_Security_Number__c = '123-456-7890' // 決定的な暗号化が有効な場合、完全一致検索はサポートされます。
];

for (Contact c : contacts) {
    // ユーザーが適切な権限を持っていれば、Social_Security_Number__c の値は
    // Apex 上では平文 (復号された状態) としてアクセスできます。
    // 特別な復号メソッドを呼び出す必要はありません。
    System.debug('Contact Name: ' + c.Name);
    System.debug('SSN: ' + c.Social_Security_Number__c);
}

注釈： 上記のコードは、`Social_Security_Number__c` 項目で「決定的 (Deterministic)」な暗号化スキームが選択されている場合にのみ正しく動作します。Shield には2つの暗号化スキームがあります。

  • 決定的暗号化 (Deterministic Encryption): 同じ平文は常に同じ暗号文に変換されます。これにより、`WHERE` 句での完全一致フィルタリングが可能になります。ただし、暗号文のパターンから元の値を推測されるわずかなリスクがあります。
  • 確率的暗号化 (Probabilistic Encryption): 同じ平文でも、暗号化するたびに異なる暗号文が生成されます。これはセキュリティレベルが最も高い方式ですが、`WHERE` 句でのフィルタリングはできません。

アーキテクトは、項目の用途（レポートや検索でフィルタリングする必要があるか）とセキュリティ要件を天秤にかけ、適切な暗号化スキームを選択する必要があります。

注意事項

Shield Platform Encryption は非常に強力なツールですが、その導入はシステム全体に影響を及ぼすため、アーキテクトは以下の制約と注意点を十分に理解しておく必要があります。

機能上の制限

暗号化は、Salesforce プラットフォームの一部の機能と互換性がありません。これらを考慮せずに導入を進めると、既存のビジネスプロセスが停止する可能性があります。

  • SOQL/SOSL: 暗号化された項目は、`ORDER BY`、`LIKE`、`STARTS WITH`、`CONTAINS` などの句では使用できません。また、集計関数 (`COUNT`, `SUM` など) の多くもサポートされません。これにより、レポート、リストビュー、カスタム検索機能が大幅に制限される可能性があります。
  • 数式項目とワークフロールール: 暗号化された項目を数式で直接参照したり、ワークフロールールの評価条件として使用したりすることはできません。
  • レポートとダッシュボード: レポートのグルーピングやフィルタリングで暗号化項目を使用する際には厳しい制限があります。
  • 一意性制約: 暗号化された項目に `Unique` 制約を適用することはできません。
  • 項目タイプの変更: 一度暗号化を有効にした項目は、そのデータ型を変更することができません。

パフォーマンスへの影響

データの暗号化・復号処理には、わずかながら CPU リソースを消費します。Salesforce はこのオーバーヘッドを最小限に抑えるように設計されていますが、大量のデータを扱うバッチ処理や複雑なトランザクションでは、パフォーマンスへの影響が観測される可能性があります。導入前には、サンドボックス環境で十分なパフォーマンステストを実施することが不可欠です。

インテグレーションの課題

API を介して Salesforce から外部システムにデータを送信する場合、データは自動的に復号されて送信されます。つまり、エンドツーエンドの暗号化を実現するためには、連携先のシステム側でデータを再度暗号化し、通信経路 (HTTPS/TLS) も保護する必要があります。ETL ツールやミドルウェアを介したデータ連携のアーキテクチャ全体で、データの保護を再評価する必要があります。

鍵管理の重要性

「Not your keys, not your data」という言葉があるように、鍵の管理は顧客の最も重要な責任です。

  • 鍵のローテーション: 定期的に Tenant Secret をローテーション（新しい鍵を生成して有効化）するポリシーを策定し、実行する必要があります。これにより、万が一鍵が漏洩した際の影響を最小限に抑えることができます。
  • 鍵のバックアップ: Tenant Secret は必ず安全な場所にエクスポートし、バックアップを保管してください。
  • 鍵の破棄: Tenant Secret を破棄すると、その鍵で暗号化されたデータは二度と復元できません。この操作は、データを意図的に永久にアクセス不能にする場合にのみ、細心の注意を払って実行する必要があります。この操作を実行できる権限は、厳格に管理されなければなりません。

コスト

Salesforce Shield は、Platform Encryption、Event Monitoring、Field Audit Trail の3つの製品からなるバンドルであり、ライセンスコストは高額です。導入にあたっては、投資対効果 (ROI) を明確にし、コンプライアンス要件やセキュリティリスクの低減といったビジネス価値を経営層に提示する必要があります。

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

Salesforce Shield Platform Encryption は、最高レベルのデータ保護とコンプライアンス遵守を実現するための、エンタープライズ向けの強力なソリューションです。しかし、その導入は単なる技術的な作業ではなく、ビジネス全体に影響を与える戦略的な決定です。Salesforce アーキテクトとして成功裏に導入を導くためには、以下のベストプラクティスを推奨します。

  1. データ分類の実施 (Data Classification):
    組織内の全てのデータを暗号化する必要はありません。まずは、PII、財務情報、知的財産など、真に保護が必要な機密データは何かを特定するデータ分類を実施します。「何を」「なぜ」暗号化するのかを明確にすることが、最初のステップです。

  2. 脅威モデリング分析 (Threat Model Analysis):
    Shield Platform Encryption がどの脅威（例：データベースからの物理的なメディア窃盗）を緩和し、どの脅威（例：適切な権限を持つ悪意のある内部ユーザーによるデータ閲覧）は緩和しないのかを正確に理解します。これにより、他のセキュリティ対策（項目レベルセキュリティ、IP 制限、多要素認証など）と組み合わせた多層防御戦略を策定できます。

  3. 影響分析と徹底的なテスト:
    暗号化を計画している項目が、どのレポート、Apex クラス、Visualforce ページ、連携プロセスで使用されているかを徹底的に洗い出します。その上で、Full Sandbox などの本番に近い環境で、すべてのビジネスプロセスが期待通りに動作するかを関係部署と連携してテストします。特に、パフォーマンスへの影響には注意を払ってください。

  4. 堅牢な鍵管理ポリシーの策定:
    技術的な導入作業と並行して、鍵管理に関するガバナンスポリシーを策定します。誰が鍵を生成・ローテーションする権限を持つのか、ローテーションの頻度はどうするか、鍵のバックアップはどこに保管するのか、緊急時の対応手順はどうするか、といった運用ルールを文書化し、関係者全員に周知徹底します。

  5. ステークホルダーとの早期連携:
    法務、コンプライアンス、情報セキュリティ、そして事業部門の各ステークホルダーをプロジェクトの初期段階から巻き込みます。Shield の導入目的、機能的制約、そして運用上の責任分界点を共有し、組織全体の合意を形成することが、プロジェクトの成功に不可欠です。

Shield Platform Encryption は、正しく計画し、導入・運用すれば、企業のデータセキュリティ体制を劇的に向上させる強力な武器となります。アーキテクトの役割は、その力とそれに伴う責任を深く理解し、ビジネス価値を最大化する形でこのソリューションを導くことです。

コメント

コメントを投稿