--- schema_version: "1" id: 9f112758d7db59ea14e6d131751b1ee89854943d1b6829c0954551899368c379 title: データ保護パターン collection: architect version: current locale: ja-jp portal_url: https://docs.salesforce.com/architect/current/ja-jp/well-architected/guides/trust-data-protection-patterns.md canonical_url: https://architect.salesforce.com/docs/architect/ja-jp/well-architected/guide/trust-data-protection-patterns.html source_site: architect.salesforce.com content_type: documentation content_hash: c86694c191b377018a873a5548a6dee6bca346fc138c29614b1e5aa7af8f6f78 products: - 適切に設計されたフレームワーク - Architect Site Content Repo --- # データ保護パターン
Well-Architected [Trust](/docs/architect/ja-jp/well-architected/guide/trust.html)の詳細 → [データ保護とプライバシー](/docs/architect/ja-jp/well-architected/guide/trust.html#data-protection-and-privacy) ## データ分類 **パターン** | 参照すべき場所 | 外観 | | --- | --- | | データ分類スキーム | ✅ レベル (公開、内部、社外秘、制限付き) で文書化した分類スキーム
✅ 分類レベルごとの提供事例
✅ 規制義務に準拠した分類スキーム (HIPAA、PCI DSS、GDPR)
✅ 設計時に一貫して分類を適用するようにトレーニングされたデータモデラー
✅ 遡及的ではなく、データモデリングプロセスの一部として分類された新しい項目 | | 項目レベルの分類 | ✅ オブジェクトレベルだけでなく項目レベルで適用される分類
✅ 1 つのオブジェクト内の項目の分類が異なる場合がある
✅ 項目レベルセキュリティで分類の違いを反映
✅ 未分類のデータはデフォルトで最高の適切な保護レベルに設定されます。
✅ 分類によって保護コントロール (暗号化、アクセス、保持) を促進 | | カスタムオブジェクトとカスタム項目 | ✅ すべてのカスタムオブジェクトにドキュメント化されたデータ分類がある
✅ \[社外秘] または \[制限あり] に分類される機密項目 (給与、SSN、PHI、支払データ)
✅ 公開として文書化されている公開項目 (会社名、Web サイト)
✅ 項目の説明で取得される分類メタデータ
✅ コードレビューとARBでレビューされた分類 | | 標準オブジェクト | ✅ 分類スキームに対して評価される標準オブジェクト項目
✅ \[制限あり]標準項目でShield Platform Encryptionが有効
✅ \[社外秘] 標準項目に適用される項目レベルセキュリティ
✅ 機密標準項目の公開を防ぐために絞り込まれたレポートとリストビュー | | インテグレーションデータ | ✅ 実装前に分類されたインテグレーションを流れるデータ
✅ 外部システムデータの機密性を評価して文書化
✅ 制限されたデータを処理するインテグレーションエンドポイントは証明書ベースの認証を使用します
✅ システム境界を越えて保持されるデータ分類 | | コンプライアンス対応付け | ✅ 特定され、\[制限あり] とマークされた HIPAA PHI 項目
✅ 可能な場合は Salesforce で PCI カード所有者データを避ける — 範囲を削減するために支払ゲートウェイ経由でトークン化します。保存する必要がある場合は、PCI DSS コントロールの \[暗号化カスタム項目] を使用します。
✅ 特定されプライバシー管理の対象となるGDPR個人データ
✅ 分類され職務分掌の対象となる SOX 財務データ | **アンチパターン** | 参照すべき場所 | どんな悪い感じか | | --- | --- | | 均一保護 | ⚠️ 機密性に関係なく、すべての項目に同じ保護が適用されます。
⚠️ 価値の低いデータは過保護 (リソースを浪費)、価値の高いデータは過保護
⚠️ PHI または支払カードデータと同じ扱いの公開会社情報
⚠️ 分類の正当性なしに「安全のために」暗号化されたすべての項目 | | 遡及的分類 | ⚠️ 本番へのリリース後に分類されたデータ
⚠️ 設計レビューではなくコンプライアンス監査で検出された機密データ
⚠️ セキュリティインシデント後にのみ分類されたデータ
⚠️ 開発中は「分類は後で考えます」がデフォルト | | オブジェクトレベルのみの分類 | ⚠️ 項目の感度が異なる場合に均一に分類されたオブジェクト全体
⚠️ 機密項目の項目レベルセキュリティなしで付与されるオブジェクトレベルのアクセス権
⚠️ 同じ分類が想定されている取引先または取引先責任者オブジェクトのすべての項目
⚠️ 混合機密オブジェクトの唯一のアクセス制御として使用されるオブジェクト権限 | | 部族のKnowledge | ⚠️ 分類が文書化されていない、主要ユーザーのKnowledgeにのみ存在する
⚠️ 開発者はどの項目が機密であるかを「知っている」だけでよかった
⚠️ すべてのデータモデラーがアクセスできる書面による分類スキームがない
⚠️ 分類トレーニングを受けていない新規チームメンバーのオンボーディング | ## 暗号化 **パターン** | 参照すべき場所 | 外観 | | --- | --- | | 保存時の暗号化 | ✅ Hyperforceですべてのデータをインフラストラクチャ レベルで暗号化
✅ 制限付きデータに対するShield Platform Encryptionの有効化
✅ クエリと一意性の要件に基づいて選択された暗号化スキーム (確率的、確定的、大文字と小文字を区別する確定的)
✅ データモデル設計時に評価される暗号化のトレードオフ | | Shield Platform Encryption戦略 | ✅ ほとんどの \[制限] 項目で使用される確率的暗号化 (すべてのクエリ操作をサポート)
✅ WHERE 句の完全一致または一意性を必要とする項目に使用される確定的暗号化
✅ ビジネスロジックで大文字と小文字の区別が重要な場合に使用される大文字と小文字を区別する確定的
✅ 本番リリース前に暗号化された項目の動作をテスト
✅適切に処理された暗号化フィールドへの数式フィールドの参照 (必要に応じて Apex に移行) | | 鍵の管理 | ✅ 鍵の循環手順の文書化と自動化
✅ ディザスタリカバリ訓練中にテストされた主要な破壊シナリオ
✅ 明示的な鍵制御を必要とするコンプライアンスが評価された顧客管理鍵 (BYOK)
✅ 文書化されている主要な取り消し手順
✅ コンプライアンス要件に従って管理される暗号化鍵ライフサイクル | | 転送中の暗号化 | ✅ すべてのインテグレーションで TLS 1.2 以上が必要
✅ 制限付きデータを処理するインテグレーションの証明書ベースの相互認証
✅ プロトコルのダウングレードを防止するために Experience Cloud サイト用に設定された HSTS ヘッダー
✅ TLS 証明書の有効期限の監視と自動更新の設定
✅ 弱い暗号とプロトコルが無効 | | コードと設定 | ✅ コード、設定ファイル、またはバージョン管理に組み込まれていないログイン情報
✅ 認証を一元管理するために使用する指定ログイン情報と外部ログイン情報
✅ アーキテクチャに組み込まれたログイン情報の循環機能
✅ 指定ログイン情報はコードから認証を抽象化するため、コードを変更することなく更新できます。 | | AppExchange パッケージ | ✅ インストール前に評価されたパッケージセキュリティ要件
✅ ビジネス上正当な場合にのみパッケージにアクセスできる暗号化項目
✅ イベントモニタリングで監視されるパッケージデータアクセスパターン
✅ 拡張レビューの対象となる制限されたデータへのアクセスが必要なパッケージ | **アンチパターン** | 参照すべき場所 | どんな悪い感じか | | --- | --- | | 評価なしの暗号化 | ⚠️ テストなしですべての項目で確率的暗号化が有効
⚠️ 暗号化された項目を集計できないために本番で重要なレポートが失敗することが判明した
⚠️ 影響を理解していない数式項目ソースで暗号化が有効になっている
⚠️ 確定的暗号化に切り替えずに暗号化された SOQL LIKE クエリで使用される項目 | | 組み込みログイン情報 | ⚠️ コード、カスタム設定、またはバージョン管理に埋め込まれたログイン情報
⚠️ ApexクラスでハードコードされたAPIキー、パスワード、証明書
⚠️ ソース制御リポジトリにコミットされたログイン情報
⚠️ 暗号化されていないカスタムメタデータまたはカスタム設定に保存されているログイン情報 | | 弱いプロトコルまたは従来のプロトコル | ⚠️ TLS 1.0 または 1.1 が使用可能 (非推奨で脆弱)
⚠️ JWT ベアラーが使用可能な場合に許可されるユーザー名パスワード OAuth フロー
⚠️ 本番インテグレーションで受け入れられる自己署名証明書
⚠️ 「インテグレーションを機能させるために」証明書検証が無効になっています | | 鍵管理なし | ⚠️ Shield Platform Encryption が鍵の循環手順なしで有効化されている
⚠️ 鍵の破棄シナリオが文書化されていない
⚠️ 顧客が管理する鍵のコンプライアンスを評価しないで使用されるデフォルトの鍵
⚠️ 鍵の循環と取り消しの手順がテストされていない | | 過剰暗号化 | ⚠️ 公開または内部分類データが暗号化され、メリットのないコストが追加される
⚠️ Shield Platform Encryptionがすべての項目で有効化され、不必要に複雑になる
⚠️ BYOK はコンプライアンスで必要でない場合に使用されます (運用オーバーヘッドが追加されます)。
⚠️ データ分類が妥当でない場合の暗号化の義務付け | ## データマスキング **パターン** | 参照すべき場所 | 外観 | | --- | --- | | Sandbox 戦略 | ✅ 制限されたデータが開発環境やテスト環境に入らない
✅ Sandbox の部分的なコピーでは、制限されたオブジェクトと項目は除外されます。
✅ Sandbox テンプレートでは、環境種別ごとに含めるオブジェクトと項目を定義します。
✅ 本番同様のデータを必要とするSandbox用に設定されたData Mask | | Data Mask ルール | ✅ Data Maskルールにより、データの特性を維持しながら機密フィールドを難読化
✅ パターンで参照整合性を維持 (同じ入力で同じマスク出力を生成)
✅ メールアドレスはマスクされますが、テストでは有効な形式のままです。
✅ 電話番号はマスクされますが、有効な形式のままです。
✅ 相対リレーションを一貫して維持して移行された日付
✅ 現実的な範囲でランダム化された数値項目 | | 合成データ | ✅ 開発環境では合成データ生成を使用
✅ 合成データは現実的な特性を持ち、効果的なテストが可能
✅ 開発に本番データが不要
✅ 開発パイプラインでのテストデータ生成の自動化 | | 本番以外の環境 | ✅ 個人の開発者組織にコピーされない本番データ
✅ 画面キャプチャとデモでは、マスクされたデータまたは合成データが使用されます。
✅ トレーニング環境では、合成データまたはマスキングされた本番データが使用されています。
✅ \[Business Use Only (ビジネス用途のみ)] 分類に制限された本番以外のデータへのコントラクターとベンダーのアクセス | **アンチパターン** | 参照すべき場所 | どんな悪い感じか | | --- | --- | | Sandbox の本番データ | ⚠️ 開発用のマスクされていない本番データで更新された Full Sandbox
⚠️ 利便性のために Developer Sandbox にコピーされるデータの制限
⚠️ 開発者に本番データ Sandbox への広範なアクセス権を付与
⚠️ 機密データで更新された Sandbox 「実際のデータを使用するとテストが容易になる」 | | 合成データなし | ⚠️ すべてのテストでのみ使用される本番データ
⚠️ 開発環境での合成データ生成なし
⚠️ 合成代替法を評価しない前提の「実際のデータが必要」
⚠️ 生成を自動化できる場合に作成される手動テストデータ | ## プライバシー バイ デザイン **パターン** | 参照すべき場所 | 外観 | | --- | --- | | データの最小化 | ✅ 記載のビジネス目的に必要なデータのみを収集
✅ 項目を追加するたびに、「このデータを必要とするアーキテクチャ上の決定は何か?」という課題に直面します。
✅ 収集目的で使用されなくなったデータの削除
✅ ビジネス上の理由なく明確にマークされ、必須ではない省略可能な項目
✅ 「すべてを永久に保持する」のではなく、法的根拠に沿った履歴データの保持 | | 目的の制限 | ✅ 権限セットにより、職務の目的に基づいてデータアクセスを制限
✅ マーケティングユーザーは、文書化された正当性がない限りサポートケースの詳細にアクセスできません。
✅ 営業ユーザーは、職務で必要でない限りカスタマーサービス履歴にアクセスできません。
✅ 部門間のデータアクセスには明示的な承認と監視が必要
✅ 権限セットの説明に記載されているデータアクセス目的 | | 同意管理 | ✅ マーケティング、分析、省略可能な処理のために個人レベルで取得された同意
✅ 同意はバイナリの包括的な同意ではなく、詳細 (目的固有)
✅ 同意の取り消しワークフローが統合システムに反映
✅タイムスタンプ、バージョン、メカニズムで追跡される同意決定
✅ 同意UIでユーザーの同意を明確に説明 | | データ主体の権利 | ✅ アクセス要求ワークフローでは、リリースの規制セットのデータコピーが期限内に提供されます。
✅ 監査履歴で不正確な情報を修正する修正ワークフロー
✅消去ワークフローでは、法的に許可されている場合(保持義務が考慮)にデータが削除されます。
✅ 可搬性ワークフローでは、機械で判読可能な形式でデータがエクスポートされます。
✅ タイムラインを検証するために定期的にテストされるデータ主体の権利ワークフロー
✅ ワークフローの自動化により、規制タイムラインの一貫性を確保 | | プライバシー管理 | ✅ ポリシーだけでなく技術的にも適用されるプライバシー管理
✅ 共有ルールで目的の制限を実装
✅ 項目レベルセキュリティで機密属性を保護
✅ 監査履歴でプライバシー関連のイベントを取得
✅ CI/CDパイプラインで検証されたプライバシーコントロール | **アンチパターン** | 参照すべき場所 | どんな悪い感じか | | --- | --- | | すべて収集 | ⚠️ 「可能なすべてのデータを収集する、いつか必要になるかもしれない」アプローチ
⚠️ ビジネス目的が文書化されていない項目の追加
⚠️ 保持の正当性なく無期限に保持されるデータ
⚠️ 項目を必須にして収集される省略可能なデータ | | ブランケット同意 | ⚠️ すべての目的での 1 つの「同意する」同意
⚠️ マーケティング同意とサービス提供を 1 つのチェックボックスで組み合わせる
⚠️ 目的が分離可能な場合、すべて同意するか、まったく同意しないか
⚠️ 20ページの契約条件に記載されている同意 | | Policy without enforcement (適用のない保険契約) | ⚠️ プライバシーポリシーは、技術的に適用されない理想的な慣行を説明します。
⚠️ 不適切なデータアクセスを防止するためのユーザートレーニング
⚠️ 技術的な管理を実装せずに文書化されるプライバシーの原則
⚠️ 監視および検証なしで想定されたポリシーコンプライアンス | | 手動データ主体要求 | ⚠️ 手動の IT チケットで処理される GDPR/CCPA 要求には数か月かかる
⚠️ アクセス、修正、消去、可搬性に関する手順が文書化されていない
⚠️ リリースの管理規制セットの要求完了期間が欠落している
⚠️ 監査で見つかったワークフローが存在しないことを要求 | | 過剰なデータ共有 | ⚠️ 目的を正当化することなく部門間で広範なデータアクセスを許可
⚠️ サポートケースの詳細へのマーケティングによるアクセス権
⚠️ 文書化する必要のないカスタマーサービス履歴へのアクセスが営業に許可される
⚠️ 個人データを含むオブジェクトに使用される公開/参照・更新可能 OWD | ## データレジデンシー **パターン** | 参照すべき場所 | 外観 | | --- | --- | | Hyperforceの地域展開 | ✅ Hyperforce リージョンでプロビジョニングされ、データレジデンシー要件を満たしている組織
✅ データの保存と処理は、必要な地理的境界内で行われます。
✅プロビジョニング前に文書化および検証された地域要件
✅ 必要に応じてマルチ組織アーキテクチャで対応するマルチリージョン要件 | | データフローの対応付け | ✅ データフローは、データの発生源、移行先、および場所を示すドキュメントを対応付けます。
✅ 規制に照らして特定および評価された国境を越えたデータ転送
✅ 国際送金の標準契約条項または拘束力のある企業ルール
✅ ストレージの場所だけでなく、レジデンシー コンプライアンスのために評価されるデータ トランジット パス | | データレジデンシー範囲 | ✅ データ ストレージの場所(どのHyperforceリージョンか)
✅ データ処理場所 (計算領域)
✅ バックアップストレージの場所
✅ ログと監査履歴の保存場所
✅ 国境を越えたデータ移動で評価されるインテグレーション通過経路 | | 複数組織アーキテクチャ | ✅ 1 つの組織で規制要件を満たすことができない場合に使用される複数組織アーキテクチャ
✅ データに適した地域でプロビジョニングされた各組織
✅ インテグレーションパターンはデータレジデンシーの制約を尊重
✅ ADR で文書化されている運用の複雑さのトレードオフ | | コンプライアンス検証 | ✅ 管轄区域ごとに文書化されるデータレジデンシー要件
✅ Hyperforceの選択はプロビジョニング前に要件に対して検証済み
✅ 定期的な監査により、必要な範囲内にデータが残っていることを確認
✅ 居住規制の変更がアーキテクチャ審査のトリガーになる | **アンチパターン** | 参照すべき場所 | どんな悪い感じか | | --- | --- | | レジデンシー監視 | ⚠️ コンプライアンス監査中に発見されたデータレジデンシー違反
⚠️ 地域要件を評価しないでプロビジョニングされた組織
⚠️ データロケーション規制を考慮しない「クラウドはクラウド」を想定
⚠️ 居住義務を確認せずに追加された管轄 | | レジデンシーを無視した乗り継ぎ | ⚠️ 通過パスが無視される間、保管場所のみが考慮される
⚠️ コンプライアンス境界外の地域を介して転送されるデータ
⚠️ 非準拠地域で使用されるインテグレーションミドルウェア
⚠️ プライマリデータとは異なるリージョンに保存されているバックアップ | | 不要なマルチ組織 | ⚠️ Hyperforce リージョンを使用する 1 つの組織で十分な場合に使用される複数組織アーキテクチャ
⚠️ 規制の必要性のない運用の複雑さ、ライセンスコスト、インテグレーションオーバーヘッド
⚠️ 特定のコンプライアンス要件のない「安全のため」のマルチ組織の実装
⚠️ データ分類とアクセス制御で十分な場合にデフォルトで使用されるマルチ組織 |