信頼

Salesforce では、Trust が最大の価値です。これは、プラットフォームのすべてのアーキテクチャ上の決定の基礎となります。アーキテクトにとっては、Trustは独自のパートナーシップによって実現されます。Salesforceは、独自のプラットフォームを構築するためのインフラストラクチャ、メタデータ、およびツールである安全なコンプライアンス プラットフォームを提供し、お客様はその基盤に依存する安全なソリューションを設計します。

このパートナーシップは、Shared Responsibility Model (共有責任モデル) という、セキュリティ責任を明確に区別するフレームワークによって運営されます。

• Salesforceは、インフラストラクチャ、パッチ適用、コンプライアンス認定など、プラットフォームのセキュリティを担当します。
• お客様は、構成、アクセス制御、カスタムコード、データガバナンスなど、プラットフォーム上のセキュリティを担当します。

このディビジョンはアーキテクチャの説明責任を定義するため、不可欠です。Salesforce は、何千もの組織がインフラストラクチャを共有するマルチテナントアーキテクチャを運用しています。このプラットフォームは、インフラストラクチャレベルで強力なセキュリティ保護を提供します。アーキテクチャに関する意思決定によって、特定のソリューションが関係者の信頼を得られるかどうかが決まります。

Shared Responsibility Model (共有責任モデル) では、物理的なセキュリティ、ネットワーク保護、プラットフォームのパッチ適用、インフラストラクチャの暗号化がユーザーに代わって処理され、安全なソリューションの設計を担当できます。これにより、ID およびアクセス管理、データ保護、インテグレーションセキュリティ、安全な開発方法、コンプライアンスと規制の遵守、インシデント対応機能などの基盤上に構築された安全なソリューションの設計に集中できます。

設計中にTrustを怠ると、技術的負債が複合します。暗号化戦略がない場合、規制が変更されるとコストのかかる改善になります。管理されていないインテグレーションは、ログイン情報が侵害されると脆弱性になります。最初から Trust を構築する方が、後で Trust を改良するよりも一貫してコストが低くなります。

Trustは、一貫して連携する4つのアーキテクチャ ディメンションにまたがっています。

• セキュリティ管理でシステムとデータを保護
• ID 管理でアクセスを管理
• プライバシー慣行はユーザーエージェンシーを尊重
• コンプライアンスフレームワークが規制義務を満たす

4つのディメンションすべてを考慮して設計するアーキテクトは、透明性、制御、復元性を通じてTrustを獲得および維持するソリューションを作成します。

エージェント時代には、Trust はエージェントが操作する信頼済みコンテキストにまで拡張されます。信頼済みコンテキストとは、エージェントが明確な ID と権限の境界を使用して管理および検証されたデータにアクセスすることを意味します。これにより、AI システムはセキュリティ、監査可能性、コンプライアンスを維持しながら、ユーザーに代わって推論とアクションを実行できます。信頼済みコンテキストの設計は、Agentic Enterprise アーキテクチャの基本です。

この柱により、すべての Salesforce ソリューションが依存するプラットフォームセキュリティベースラインが確立されます。Agentic Trustの柱は、プロンプト インジェクション、アクション ガバナンス、推論時にエージェントがアクセスできるデータなど、自律エージェントに固有のリスクに対応するために、そのベースラインを基盤としています。まずベースラインを設計し、次にAgentic Trustガイドラインを使用してエージェント固有の制御を階層化することが重要です。

この柱は、他のフレームワークの懸念事項と深く関連しています。

• 信頼性は、攻撃に耐え、侵害から回復するインフラストラクチャに依存します。
• Operational Excellenceには、安全な導入パイプラインとインシデント対応機能が必要です。
• 公平性のためには、データとアルゴリズムによる意思決定の透明性と倫理的な処理が必要です。

これらの柱が組み合わさって、組織が最も機密性の高い運用でTrustできる、統合されたソリューション重視のアプローチが形成されます。

共有責任モデルでは、SalesforceとアーキテクトはTrustを維持するためにそれぞれの責務を果たす必要があります。それぞれの側で確保する必要があるものを詳しく見てみましょう。

Salesforce は、プラットフォームとそのグローバルインフラストラクチャのセキュリティ保護に責任を負います。これには次のものが含まれます。

• データセンターのアクセス制御、監視、環境の保護
• Hyperforceの場合、基盤となるクラウド プロバイダー(インスタンスに応じてAWS、Azure、Google Cloudなど)は、代理の責任で物理データセンターのセキュリティを処理します。Salesforce Infrastructure and Sub-processors ドキュメントには、各サービスのプロバイダーとサブプロセッサーが記載されています。

• DDoS 保護や脅威検知などのネットワーク層セキュリティ制御
• 転送中および保存中のトラフィックの暗号化 (TLS 1.2+) (通常は AES-256)

• Salesforceによる脆弱性対応とプラットフォームパッチの導入(セキュリティアドバイザリの詳細については、security.salesforce.comを参照してください)
• オペレーティングシステムとインフラストラクチャのセキュリティ管理

• **認定と証明:**Salesforceは、SOC 1/2/3、ISO 27001/27017/27018、FedRAMP認証(範囲は商用マルチテナント プラットフォームではなくGovernment Cloud PlusとMuleSoft Government Cloud)、PCI DSSレベル1の検証を管理しています。
• 規制サポート: これは、BAA(Business Associate Agreement)またはGDPRコンプライアンス プログラムを含むHIPAA対象サービスに適用されます。
• 詳細については、Trust.salesforce.comおよびcompliance.salesforce.comを参照してください。

• **テナント分離アーキテクチャ:**共有のメタデータ駆動型カーネルは、すべての組織のデータとメタデータを組織IDでパーティション分割します。そのため、両方の組織が共有インフラストラクチャで実行されていても、ある組織が別の組織のレコードにアクセスすることはできません。カーネルは、管理する必要がある設定ではなく、クエリごとに分離を適用します。
• 保存時およびバックアップ インフラストラクチャの**インフラストラクチャ レベル暗号化:**基本プラットフォーム ライセンスにはClassic Encryptionが含まれます(AES-128ではカスタム テキスト フィールドのみが用意されています)。Shield Platform Encryptionには、個別のライセンスが必要です(AES-256では、独自の鍵を使用でき、標準およびカスタム フィールド、ファイル、添付ファイルが提供されます)。

これらの制御により、プラットフォームのセキュリティ、信頼性、コンプライアンスが維持されます。

データ、設定、および運用プロセスを保護する責任はお客様にあります。

• **IDと統合:**シングルサインオン(SSO)と多要素認証(MFA)では、ユーザーのIDを検証する必要があります。
• アクセス制限: 技術的には、IP範囲とログイン時間帯によって、ID の接続方法と接続時間が制限されます。
• Principle of Least Privilege (PoLP): PoLP を使用して、個々の職務を実行するために必要なロール、プロファイル、権限セットにのみアクセス権を付与します。
• ライフサイクル管理: ユーザーライフサイクル管理とアクセスの再認定ガイドラインを実践します。

• データ分類、マスキング、オブジェクト/項目/レコードレベルセキュリティの使用
• CRUD 権限と共有ルールを適用する
• 実証済みの戦略を所有、テスト、リリースして、組織のデータを復元し、データの損失や破損の復旧を確実に制御できるようにします。

• API 認証 (OAuth 2.0 や JWT など) と指定ログイン情報を使用します。
• PoLP 権限セットを使用して専用のインテグレーションユーザーを有効にし、各インテグレーションのアクセス権の範囲を設定し、人間のユーザーとは別に監査できるようにします。
• エンドポイントと外部システム検証を保護します。

• イベント監視、監査履歴、セキュリティ情報およびイベント管理 (SIEM) インテグレーションを使用します。
• インシデント対応手順とセキュリティレビューに従います。

• 安全なカスタム・コード（ApexやLightningなど）と入力規則を使用します。
• Apexをユーザー・モードで実行し、オブジェクト、フィールド、共有の権限をコードで適用します。
• インジェクション防止と安全な開発方法に従います。

• ソリューションコンプライアンス体制を維持する。
• プライバシー/同意管理とデータ保持ポリシーに従います。

コラボレーションが必要な職務もあります。

• セキュリティインシデント対応: 双方が検出および対応活動に参加します。
• 脆弱性管理: Salesforce はプラットフォームにパッチを適用し、アーキテクトはカスタムコードにパッチを適用します。
• セキュリティ監視: プラットフォームで生成されたセキュリティシグナルをアーキテクトの分析と組み合わせます。
• コンプライアンス認定: Salesforceはプラットフォーム(Government CloudのSOC、ISO、FedRAMPなど)を認定します。アーキテクトは、そのプラットフォーム上に構築されたもの(カスタムオブジェクト、コード、インテグレーション、構成)を、認定された体制内で所有し、監査でコンプライアンスの証拠を提供します。
• ID 統合: Salesforce は、アーキテクトの ID プロバイダーが発行するアサーションを信頼します。アーキテクトは、プロバイダーのセキュリティを確保し、プロバイダーと Salesforce の信頼関係を維持します。
• 鍵の管理: BPO(Bring Your Own Key)暗号化を使用して、Salesforceが暗号化サービスを実行し、アーキテクトがデータを保護する鍵素材の生成、循環、取り消しを行います。

このドキュメントのすべての設計原則、トピックセクション、チェックリスト項目は、アーキテクトとしての責任を表します。Shared Responsibility Model は、Salesforce Platform で Trust を達成するために設計および設定する必要がある内容をまとめます。

この境界は規制義務にまで及びます。Salesforce はプラットフォームの認定と証明を維持し、インフラストラクチャを侵害から保護します。アーキテクトは、データおよび管轄区域に付属する義務 (適用される法律、データの分類方法、データを管理する保持ルールと同意ルール、管理下にあるデータの侵害の検出および報告方法など) に責任を負います。管轄区域や経時的に変化する可能性があるため、アーキテクトはリリースの規制に対して、これらの義務の背後にある具体的な数値 (保持期間や通知期限など) を決定する必要があります。

次の原則を使用して、プラットフォームのセキュリティに関するアーキテクチャ上の意思決定をガイドします。

• **すべてのレイヤーに Zero Trust を適用します。**ネットワークの場所、ユーザーの習熟度、またはシステムの発生源に基づいて Trust を想定しないでください。データレイヤー、アプリケーションレイヤー、インテグレーションレイヤー、インフラストラクチャレイヤーで認証、承認、暗号化を使用して、すべてのアクセス要求を明示的に検証します。マルチテナントアーキテクチャでは、インフラストラクチャを数千の組織と共有するため、ソリューションを実行するネットワークは信頼できる境界ではありません。各要求は、発信元を信頼するのではなく、独自のメリット (ID、承認、コンテキスト) で検証します。
• **デフォルトで最小権限を付与します。**各ユーザー、インテグレーション、自動化プロセスの目的を果たすために必要な最小限のアクセス権を付与します。最も制限の厳しい設定 (非公開組織の共有設定 (OWD) と最小限の権限) から開始し、文書化したビジネス要件に基づいて慎重に拡張します。4 階層アクセスモデル (組織 → オブジェクト → 項目 → レコード) を使用して、各階層で上の階層をさらに制限します。
• **多層防御を実装します。**1 つの制御に障害が発生してもシステム全体が侵害されないように、複数のセキュリティ制御をレイヤー化します。予防制御 (操作をブロックする CRUD/FLS 適用やトランザクションセキュリティポリシーなど)、探偵制御 (イベント監視など)、応答制御 (トランザクションセキュリティのステップアップ認証と通知など) を組み合わせます。隣接するレイヤーが失敗する可能性があるかのように各レイヤーを設計します。項目レベルセキュリティでは、共有ルールが許容範囲を超えている場合でもデータが保護されます。
• **設計によってセキュリティを統合します。**脅威モデリング、セキュリティ要件、制御検証を、初期概念から継続的な進化までのすべてのアーキテクチャフェーズに統合します。構築を開始する前に、スプーフィング、改ざん、否認、情報公開、サービス拒否、権限昇格 (STRIDE) の脅威モデリングを実行します。セキュリティは、テクノロジーの選択と設計に関する意思決定を形作ります。
• **自動化にセキュリティを組み込みます。**自動化されたパイプライン、設定テンプレート、プラットフォームのデフォルトにセキュリティコントロールを組み込みます。CI/CD の Salesforce Code Analyzer は、リリース前に脆弱性を検出します。コードとしての設定では、セキュリティベースラインが適用されます。組み込みセキュリティにより、一貫性が確保され、ソリューションの複雑さに応じてセキュリティを拡張できます。
• **プライバシーに配慮した設計。**初期のアーキテクチャフェーズからプライバシーの原則を組み込みます。データの最小化 (必要なデータのみを収集する)、目的の制限 (職務ごとのアクセスの制限)、同意管理 (目的固有の詳細な同意の適用)、データ主体の権利 (アクセス、修正、消去、可搬性のワークフローを規制タイムライン内で完了できるようにする) を考慮した設計。
• **トレーサビリティを考慮した設計。**異常の検出に依存する前に、すべての結果アクションを事後に帰属させて再構築できるようにします。データ、権限、および設定への変更が監査履歴、項目履歴、イベントログに確実に取り込まれ、それらのレコードが改ざんされにくいストレージに保持されるようにします。トレーサビリティは、検出、フォレンジック、説明責任の前提条件です。記録されなかった内容は調査できません。
• **インシデント対応の設計。**イベント監視による検出可能性と、トランザクションセキュリティポリシーによるリアルタイム介入を考慮して設計します。文書化した手順と分離境界を使用して迅速に対応できるようにします。バックアップ機能とフォレンジック保存でリカバリをサポートします。机上演習と侵害シミュレーションで回答をテストします。

アーキテクトは、Salesforce が提供するプラットフォームでソリューションを保護する責任を負います。

Salesforce とやりとりするワークロードは、コアプラットフォーム (インテグレーションサービス、カスタムアプリケーション、ヘッドレスクライアント) の外部で実行されることが多くなっています。このパターンを加速するために、Salesforce ではプラットフォームの機能を API、ツール、コマンド (Salesforce Headless 360 など) として公開しています。これらのアプリケーションを操作するユーザーに関係なく、アーキテクトは、Salesforceと会うTrust境界を所有し、認証方法、保持するIDと権限、保持する秘密、境界を超えるデータを決定します。

以下の原則は、コンテナ化されたインテグレーションプラットフォーム (MuleSoft CloudHub など) に適用されます。

外部クライアントが指定ユーザーとして認証されると、Salesforce のプラットフォームセキュリティモデルが自動的に適用されます。つまり、オブジェクト権限、項目レベルセキュリティ、および共有ルールは、ブラウザーの場合と同じように適用されます。ユーザーごとの認証では、すべてのコールがその個人の権限の範囲になり、監査履歴が保持されます。つまり、ユーザーのトークンを取り消すと、クライアントの代理としての権限がすぐに失われます。特定のユーザーに対して作業が行われるすべての場所で、共有サービスアカウントよりも優先されます。

境界は防御的に設計してください。これは、多くのユーザーのトークンを保持しているクライアントが Trust を集中させ、攻撃者にとって価値の高いプロキシになるためです。つまり、盗まれた 1 つの OAuth トークンが、クライアントがサービスを提供するすべてのユーザーのデータにアクセスする可能性があります。これは仮説ではありません。2025 年の Salesloft ドリフトインシデントでは、攻撃者が OAuth トークンを盗み、それを使用して数百の組織の Salesforce データにアクセスしました。

• **ユーザー ID を伝播します。プールしないでください。**ユーザーごとの認証または OAuth 2.0 トークン交換を使用して、サービスホップ間でユーザーの ID を伝達します (「エージェント ID と認証」を参照)。これにより、侵害の範囲がすべてのユーザーではなく 1 人のユーザーのコンテキストに限定されます。
• **OAuth クライアントログイン情報と更新トークンをプライマリターゲットとして扱います。**管理シークレットストアに保存したり、頻繁に循環させたり、即時取り消し用の設計を管理したりします。プロキシされた攻撃者を示す異常なパターンの API 使用状況を監視します。
• **両側の範囲を最小化します。**外部クライアントアプリケーション (ECA) の OAuth 範囲とインテグレーションユーザーの Salesforce 権限を機能に必要な最小限に制約し、侵害されたクライアントが関連しないデータにピボットしないようにします。
• **外部クライアント アプリケーションを使用して境界を管理します。**ECA は、外部アプリケーションの認証方法、許可されるフロー、適用される範囲を定義します。ECA に対して新しいインテグレーションを設計します (「認証アーキテクチャ」を参照)。

クライアントがエージェントユーザーまたはインテグレーションユーザーとして実行されている場合、これらの ID は、多くの場合、Salesforce のアクセス制御を尊重しない外部システムに対して、高められたコンテキストで動作できます。そのため、上記の権限と監視の規則を使用することで、権限が制限されます。

コンテナ化されたプラットフォームでインテグレーションを実行する場合、コンテナレベルの分離はそれ自体がセキュリティ制御とみなされます。つまり、各アプリケーションは、アプリケーション間でランタイムやメモリが共有されていない専用のコンテナで実行されます。

この分離により、次のことが可能になります。

• テナント境界の適用: 侵害されたアプリケーションは、同じ環境を共有する隣接するアプリケーションのデータやリソースにアクセスできません。各コンテナには、独立したファイルシステムとプロセススペースがあります。ファイアウォールと TLS 設定を使用してネットワークを分離し、許可されるデフォルトではなく送信トラフィックを明示的に制限します。
• **多層防御:**コンテナの分離により、アプリケーション レベルの制御を超えるセキュリティ レイヤーが追加されます。アプリケーションコードに脆弱性があっても、コンテナの境界によって爆発半径が制限されます。
• コンプライアンスのセグメンテーション: 規制対象のワークロード (PCI や HIPAA など) を専用のコンテナに隔離することで、非準拠のワークロードとの混在を防止できます。

マルチアプリケーション環境を設計しているアーキテクトは、コンテナの分離を利用して職務とセキュリティドメインを分離する必要があります。カード所有者データを処理する金融サービスインテグレーションは、同じ環境内でもマーケティングインテグレーションとは別のコンテナで実行する必要があります。

コンテナ間トラフィックは暗号化する必要があり、規制フレームワークで両側の認証が必要とされる場合は、相互 TLS (mTLS) を適用する必要があります。

仕組み:

• 必要に応じて、着信接続の省略可能な相互 TLS (mTLS) を有効にするように TLS コンテキストを設定します。
• クライアント証明書認証でプラットフォームレベルの SSL を使用して、プラットフォームサービスとレプリカ間の通信を保護します。
• 規制フレームワークで必要な場合に mTLS を有効にするように TLS コンテキストを設定します。
• ライフサイクルと取り消しが一元化されるように、プラットフォームの証明書ストアで証明書を管理します。
• コンテナ間の不正なトラフィックを防止するネットワーク分離境界を適用します。

プラットフォームレイヤーでトラフィックを暗号化することで、転送中のデータの多層防御が実現します。アプリケーション層の HTTPS が誤って設定されていても、コンテナトラフィックは暗号化されたままです。

VPN を介してオンプレミスシステムに接続するコンテナは、転送中のデータを保護するために設計する必要があります。

• **トンネル暗号化:**コンテナとオンプレミス システム間のすべてのトラフィックを暗号化された VPN トンネルを介してルーティングします。これは、アプリケーション層の TLS に関係なく適用されます。多層防御により、機密データの暗号化が二重に行われます。
• **ネットワーク セグメンテーション適用:**VPN トンネル ポリシーにより、オンプレミス ネットワーク コンテナが到達できるネットワークが制限されます。侵害されたコンテナは、VPN で許可されたネットワークを超えて未承認の内部システムに転送できません。
• **コンプライアンス証拠:**VPN暗号化は、クラウド環境との間で送受信されるデータを保護するための受け入れられているメカニズムの1つです。HIPAA、PCI-DSS、または SOX 統制をレビューする監査人は、ハイブリッドインテグレーションで転送中の文書化された暗号化を期待しています。

アーキテクトは、最小権限のネットワークアクセスを適用する VPN ポリシーを設計する必要があります。マーケティングインテグレーションコンテナは、VPN 経由で内部財務システムに到達可能である場合でも、内部財務システムに転送しないでください。

バニティ ドメイン(インテグレーションAPIのカスタムURLなど)では、アーキテクトはTLS証明書をTrustアンカーとして管理する必要があります。

バニティ ドメイン(インテグレーションAPIのカスタムURLなど)では、アーキテクトがTLS証明書をTrustアンカーとして管理する必要があります。

• 証明書ライフサイクル自動化: 証明書の自動更新とリリースを実装します。証明書の期限が切れると Integration Trust が壊れます。クライアントは証明書検証エラーで接続を拒否します。
• 証明書失効計画: セキュリティインシデントの証明書の循環手順を設計します。侵害された非公開鍵では、すべての地域で証明書の迅速な再発行とリリースが必要です。
• 暗号スイート設定: 古い TLS 設定 (TLS 1.0/1.1 および弱い暗号) はコンプライアンス監査に失敗します。TLS 1.2+ (最小要件) を適用し、証明書とクライアントの設定を組織のセキュリティポリシーに合わせます。
• 証明**書透明性ログ:**最新のTLS証明書は、CA(認証機関)によって公開CT(証明書透明性)ログに送信されます。各 CT ログは、CA が X.509v3 拡張機能を介して証明書に埋め込む、ロギングの暗号証明である署名済み証明書タイムスタンプ (SCT) を返します。アーキテクトは、crt.sh や自動アラートなどのサービスを使用して、ドメインに対する不正な証明書の発行に関する CT ログを監視する必要があります。

証明書の管理ミスは Trust ポスチャに直接影響します。

• Expired certificates: 停止として表示される認証エラーの原因となります。更新ワークフローを開始できるようにするには、有効期限の 30 日以上前にアラートを送信することを監視に含める必要があります。
• **自己署名証明書：**外部クライアントの Trust Chain を解除します。本番インテグレーションでは、信頼できる認証機関 (CA) によって署名された証明書が必要です。
• ワイルドカード証明書の無秩序な増加: ワイルドカード証明書の範囲が広すぎる (*.company.com など) ため、侵害された場合に大きなブラスト半径が作成されます。インテグレーションドメインごとに範囲の狭い証明書が優先されます。

コンテナのリリース地域は、データレジデンシーとコンプライアンスの要件に準拠する必要があります。

• **GDPRデータ レジデンシー:**GDPRでは、EU(欧州連合)から出国する個人データを適切に保護する必要がありますが、EUへの導入は義務付けていません。EU リージョンにインテグレーションをリリースすると、コンテナのコンピューティングとデータ処理が規制範囲内に保たれます。これは、この要件を満たす最も直接的な方法です。EU 域外で発生した移転は、妥当性判断、標準契約条項 (SCC)、または拘束力のある企業ルール (BCR) の下で引き続き許容されます。
• データローカライズ法: データのローカライズが義務付けられている国には、ロシア (連邦法 152-FZ およびストレージの義務付け) と中国 (CIIO の PIPL/CSL) があります。これらの国では、国内でのコンテナの導入が必要な場合があります。インドのDPDP Act of 2023では、一般的な国内ストレージ義務を負わないブラックリスト アプローチを採用しています。データ転送は、政府の通知で特に制限されていない限り、どの国でも許可されます。アーキテクトは管轄区域固有の規制を理解する必要があります。
• 国境を越えるデータ転送メカニズム: 複数の地域への導入が必要であるが、データが国境を越える必要がある場合、アーキテクトは SCC、BCR、またはその他の法的転送メカニズムを実装する必要があります。
• コンプライアンス認定の調整: コンテナのリリース地域は Salesforce コンプライアンス認定と一致する必要があります。FedRAMP で承認されたワークロードには、米国地域への導入が必要です。HITRUST 認定インテグレーションの場合、リリース地域が有効な HITRUST 証明範囲内にあることを確認する必要があります。

地域ごとの導入の決定は、規制コンプライアンスに直接影響するアーキテクトの責任です。財務チームは、SOX で制御されるインテグレーションの米国のみのリリースを義務付けることができます。ヘルスケアチームは、個人健康情報 (PHI) を処理するために HITRUST 認定地域を必要とする場合があります。

コンテナには、ログイン情報、API キー、暗号化キーへのアクセス権が必要です。アーキテクトは、漏洩を防止する秘密管理プロセスを設計する必要があります。

• No hardcoded secrets: コンテナにリリースされるアプリケーションコードまたは設定ファイルに認証情報を埋め込みません。プラットフォームで管理されるシークレットストアを使用します。
• プラットフォーム管理シークレットインジェクション: 実行時にプラットフォームの管理ストアから (ファイルシステムに保持するのではなく) シークレットを解決し、ログイン情報を保持する設定値を保護対象としてマークして、ログやコンソールに公開されないようにします。
• 秘密の循環: 循環した秘密を適切に処理するようにインテグレーションを設計します。OAuth トークンの更新パターン、API キーの循環ワークフロー、およびデータベースパスワードの変更でコンテナの再リリースが必要ないようにする必要があります。
• 最小権限の秘密アクセス: コンテナの機能に必要な秘密にのみアクセス権を付与します。マーケティングインテグレーションは、同じ環境を共有している場合でも、財務システムのログイン情報にアクセスしないでください。

公開された秘密は、一般的なインテグレーションセキュリティインシデントです。アーキテクトは、コードレビュー、ログ、エラーメッセージ、および監視ダッシュボードからログイン情報を漏洩することなく存続できる秘密の処理プロセスを設計する必要があります。

Salesforce 境界のアプリケーションは、コンプライアンスログ要件を満たす監査イベントを生成します。

• 要求/応答ログ: API 要求、応答、およびルーティングの決定を記録します。コンプライアンスチームは、これらのログを使用してアクセス監査を行い、誰がいつどのデータにアクセスしたかを判断します。
• **エラーおよび例外ログ:**セキュリティ イベント(認証失敗、承認拒否、無効な証明書など)をコンテナのログに記録します。SIEM インテグレーションにより、リアルタイムのセキュリティ監視が可能になります。
• ログ保持ポリシー: アーキテクトは規制要件を満たす保持期間を設定する必要があります。これらの最小値は規制によって設定され、フレームワークによって異なり、時間の経過と共に変更されるため、ハードコード値ではなく、管理規制に対して各数値を検証する適切に管理されたコンプライアンスソースから取得する必要があります。
• ログの暗号化とアクセス制御: 監査ログには機密メタデータが含まれている場合があります。保存時にログを暗号化し、承認されたセキュリティ/コンプライアンス担当者のみにアクセス制御する必要があります。ログが不十分な場合、インシデントの調査が妨げられ、コンプライアンス監査に失敗します。アーキテクトは、ログの詳細度 (パフォーマンスへの影響やストレージコストなど) とコンプライアンスおよびセキュリティ調査のニーズのバランスを取る必要があります。

脅威モデリングは、その前後で個別のステップを実行するのではなく、ソリューションの設計に含める必要があります。理由となる候補設計が見つかったら、すぐにその潜在的な脅威をモデル化し、設計の進化に合わせてモデルを再確認して、セキュリティがアーキテクチャを刷新するのではなく、アーキテクチャを形成するようにします。Salesforce がインフラストラクチャセキュリティ (ネットワーク保護、OS 強化、脆弱性管理など) を管理する場合、設定、インテグレーション、カスタムコードでアプリケーション層のリスクを特定する必要があります。STRIDE フレームワーク (スプーフィング、改ざん、否認、情報開示、サービス拒否、権限昇格) を、次の Salesforce 固有の脅威ベクトルに適用します。データがシステム、ネットワーク、または権限レベルを横断するTrust境界を特定します。

STRIDE フレームワークを次の Salesforce 固有の脅威モデリングの考慮事項に適用します。

• 複数組織データ フローでは、各クロスで明示的な認証と承認を必要とする追加のTrust境界が作成されます。
• 外部インテグレーションではAPIとミドルウェアが使用されるため、プラットフォームのセキュリティ制御をバイパスする攻撃ベクトルが発生する可能性があります。
• カスタムApexおよびLightningコンポーネントでは、インジェクション、XSS、アクセス制御の適用に安全なコーディング分析が必要です。
• Experience Cloud サイトは、認証されていないユーザーや認証が軽いユーザーに攻撃対象を広げます。
• サードパーティおよびISVコード(たとえば、管理パッケージ、AgentExchangeリスト、接続アプリケーション、サードパーティ コネクタ、クライアント側のJavaScriptライブラリ、エージェントがコールする外部AIサービス)は、インストール時または実行時にTrust境界を通過するサプライ チェーン ベクトルです。

サードパーティおよび ISV コードは Trust Boundary の一部

管理パッケージまたは AgentExchange リストは、付与した権限で組織内で実行されるため、インストールした瞬間のセキュリティ体制になります。AppExchange または AgentExchange に到達する前に Salesforce Security Review でリストされた各パッケージが確認されます。このゲート以降はすべてユーザが所有します。

• 独自のデータ分類とリスク状況に対するパッケージの評価
• 文書化された機能に必要な最小限の権限を付与する
• パブリッシャーのリリースで最新の状態を維持する
• また、独自のコードに適用するのと同じイベント監視および監査コントロールを使用して、その活動を監視します。

ソリューションスタックのすべてのレイヤーでセキュリティ制御を適用します。1 つのレイヤーを侵害すれば、システム全体が公開されないことに注意してください。

上下のレイヤーが失敗する可能性があるかのように各レイヤーを設計します。複数の独立したコントロールが復元力を生み出します。

Zero Trust は、ネットワークの位置または以前の認証状態に基づく暗黙的な Trust を排除します。すべての要求は個別に認証および承認される必要があります。

ゼロトラストの適用先:

• MFA、セッションポリシー、コンテキストに基づく条件付きアクセス (IP、デバイス、時刻、動作など) による継続的な検証によるユーザーアクセス
• すべてのコールでの OAuth トークン検証、証明書ベースの相互 TLS、IP 許可リスト登録によるインテグレーション接続
• 明示的な認証によるシステム間通信。信頼できる内部システムにも適用されます。
• コールコンテキストに関係なく、すべてのクエリおよび操作で CRUD および FLS を適用してデータアクセス

セキュリティアセットインベントリはセキュリティ設計の入力です。最初に列挙した攻撃対象領域に対してのみ脅威のモデル化、最小限の権限の適用、監視を行うことができるため、セキュリティ関連のアセットの追跡は、セキュリティに関連する設計上の決定事項に従います。これは、Operational Excellence でカバーされる運用設定管理 (運用の安定性のために組織設定のバージョン管理や設定ドリフトの検出など) とは異なります。つまり、どの資産にセキュリティリスクがあり、なぜセキュリティリスクがあるかという懸念は狭くなります。

機密データを保存するカスタムオブジェクト、外部システムインテグレーション、公開 API、特権アカウント、本番アクセス許可、権限が昇格したインストール済みパッケージなど、すべてのセキュリティ関連アセットの現在のインベントリを管理します。

セキュリティ資産インベントリには次のものを含める必要があります。

• 社外秘データまたは制限データを含むカスタムオブジェクトおよび項目
• インテグレーションエンドポイントと認証メカニズム
• 高度な権限 (「すべてのデータの編集」、「すべてのデータの参照」、「ユーザーの管理」など) を持つユーザー
• API 限定インテグレーションユーザーとその権限範囲
• 外部クライアントアプリケーション (ECA) とその OAuth 範囲、および組織にまだ存在する従来の接続アプリケーション
• インストールされた AgentExchange パッケージとその権限付与
• Experience Cloud サイトとその認証および外部共有モデル
• 高度な共有モードを使用するカスタム Apex クラス
• 従来のクラスには特に注意してください。API バージョン 66.0 以前でコンパイルされ、共有宣言を省略したコードは、デフォルトで「共有なし」に設定されます (たとえば、実行ユーザーのレコードアクセス権をスキップするシステムモード)。API バージョン 67.0 (Summer '26) 以降、省略された宣言はデフォルトで「共有あり」になり、データベース操作はユーザーモードで実行されます。ただし、既存のクラスは v67.0 (またはそれ以降) で再コンパイルされるまで古い動作を維持するため、以前のバージョンから継承された宣言されていないクラスはサイレント昇格のままです。

最小限の権限を適用する ID 制御を設計および設定する責任は各自にあります。

PoLP を使用してコントロールを適切に設計および設定する方法を詳しく見てみましょう。

Salesforce は、組織、オブジェクト、項目、レコードの 4 つの異なるレイヤーでアクセス制御を適用します。4 つのレイヤーをすべて意図的に活用するソリューションを設計する必要があります。コアアクセス制御は許可ベースです。つまり、アクセス権は追加的であり、レコードにアクセスするにはユーザーがすべてのレイヤーでアクセス権を付与する必要があります。コアプラットフォームには汎用的な「上書きを許可しない」ルールがないため、対象を絞った拒否を適用して、すでに付与されている広範な権限へのアクセスを取り消すことはできません。

上位レイヤーを許可すると、制限のコストはかかりませんが、労力は増えます。組織の共有設定やオブジェクト権限を早期に広げるには、項目レベルセキュリティと共有設定を使用して、本来許可されるべきでないアクセス権を取り戻す必要があります。

制限ルールとミュート権限は、アクセス権を除外する 2 つの組み込み例外ですが、それぞれが狭い範囲 (レコードレベルの絞り込みの制限ルールと権限セットグループ内で付与された権限へのミュート) で、汎用的な拒否レイヤーではありません。

機密データを含むオブジェクトの OWD を [非公開] に設定します。OWD を公開/参照のみ (公開/参照・更新可能はおろか公開/参照のみ) に開放すると、レコードが広く公開され、重要なアーキテクチャの再構築を行うことなく、後からアクセスを制限する機能が失われます。成熟した組織で最も一般的なTrust債務は、初期実装時に設定された許容 OWD に起因します。

レコードレイヤーは、多くの場合共有ピラミッドとして表示される grant-then-restrict モデルに従います。OWD は制限ベースラインを設定し、ロール階層、共有ルール、共有の直接設定により、そこから上位へのアクセス権が開放されます。2 つのコントロールでは、アクセス権を付与するのではなく、フローを反転してアクセス権を剥奪します。どちらも意図的に設計する価値があります。

• 制限ルールでは、ユーザーがすでにアクセス権を持つレコード内で表示できる内容が絞り込まれるため、広範なオブジェクトアクセス権を持つユーザーには、引き続きルールで許可されているサブセットのみが表示されます。
• ミュート権限では、権限セットグループ内の特定の権限が減算されるため、再利用可能なグループからアクセス権をアセンブルし、特定の母集団が持っていてはならない権限を削除できます。
• 付与ベースのレイヤーのみでは、アクセス権を過剰にプロビジョニングするか、多数の狭い権限セットに断片化しなければならない場合に、これらのルールを適用します。

プラットフォーム要件として Salesforce で義務付けられているユーザーインターフェースを使用して本番環境にログインするすべてのユーザーに MFA (多要素認証) を適用します。この要件は API 限定アクセスには拡張されません。JWT ベアラーフローまたはクライアントログイン情報フローを使用するインテグレーションは除外されるため、代わりに証明書管理と IP 制限でこれらのインテグレーションを保護する必要があります。MFA 要件を特権操作に拡張します。

SSO (シングルサインオン) では、SAML 2.0 または OpenID Connect プロトコルが推奨されます。セキュリティと使いやすさのバランスを取るようにセッションポリシーを設定します。

• セッションタイムアウト: ユーザーの権限レベルに適したセッションタイムアウトを設定します (権限の高いアカウントのタイムアウトを短くすると、無人セッションによるリスクが軽減されます)。
• IP 制限: 管理プロファイルおよびインテグレーションユーザーに制限を適用します。
• ログイン時間: サービスアカウントを予想される業務時間に制限します。
• **デバイスの有効化:**Salesforceのネイティブ デバイスの有効化(認識されないデバイスからのログインのID検証)を利用し、高権限アカウントのMFAおよびIP制限を追加します。Native Device Trust ポスチャは、外部 ID プロバイダーを介して適用されます。
• セッション IP ロック: 盗取されたセッション ID が別のネットワーク ロケーションから再生されないように、セッションをそのセッションの送信元の IP アドレスにロックします。これによりセキュリティが強化されますが、モバイルユーザーにとって摩擦が生じ、自動インテグレーションが壊れる可能性があります。ロックが実行できない場合は、補償制御として [すべての要求でログイン IP アドレスの制限を適用] を使用して、プロファイルレベルで [厳格なログイン IP アドレスの制限] を適用します。
• 高保証セッション: 機密性の高い操作 (レポートへのアクセスや IP 範囲の管理など) では、[セッションセキュリティレベルポリシー] と [アクセスポリシー] を使用して高保証セッションセキュリティレベルを要求し、通常のログインだけでは影響の大きいアクションにはアクセスできないようにします。Lightning Experience では、MFA の再入力を求めることで標準セッションを高保証に引き上げることはできません。そのため、このポリシーの範囲は、標準セッションのユーザーが昇格を促されるのではなく、ゲート操作からブロックされることを考慮して設定します。
• セッション cookie 保護: スクリプトがセッション ID の cookie を参照できないように HttpOnly 属性を要求し、セッションを最初に使用したドメインにロックして、セッションハイジャックを鈍くします。
• インテグレーションユーザーの API 限定アクセス: 「API 限定ユーザー」権限を使用してインテグレーションアカウントとサービスアカウントを API 限定認証に制限し、ユーザーインターフェースからログインできないようにします。新規ビルドの場合、Salesforce インテグレーションユーザーライセンスで [Minimum Access - API Only Integrations (最小アクセス - API 限定インテグレーション)] プロファイルを割り当てます。Spring '24 以降プロビジョニングされた組織では、古い Salesforce API 限定システムインテグレーションプロファイルを使用できないため、非推奨プロファイルではなく、現在のプロファイルに基づいて新しいインテグレーションを設計します。

API 認証の場合、インテグレーションパターンに適した OAuth 2.0 フローを選択します。

• JWT ベアラーフロー: インテグレーションユーザーとして実行されるサーバー間インテグレーションで使用します (証明書ベース、信頼済み環境で推奨)。
• **Web サーバーフロー (**認証コード、PKCE を使用): ユーザー認証が必要な Web アプリケーションや、特定のユーザーコンテキストを維持する必要があるサーバー間インテグレーション (ブラウザーのプロンプトが繰り返されないようにサーバー側で更新トークンを保存) で使用します。
• **Make Authorization-Code Flow Replay-Safe:**傍受された認証コードを要求元クライアント以外のユーザーが利用できないように PKCE を適用し、更新トークンを循環して (使用のたびに新しい認証コードを発行し、以前の認証コードを無効にして)、盗まれた更新トークンの有効期間を狭めます。廃止されたトークンの再利用は、侵害を意味します。
• ヘッドレス ID 認証コードおよびログイン情報フロー (PKCE を使用): これは、特定のユーザーのコンテキストで実行する必要がある、本当にヘッドレスでブラウザーのないクライアントに使用します。リダイレクトベースの Web サーバーフローでは、これらのクライアントが持っていないブラウザーを前提としています。
• **デバイスフロー (ヘッドレスデバイス用):**2025 年 8 月 28 日以降、Salesforce はデフォルトの Salesforce CLI 接続アプリケーションの OAuth 2.0 デバイスフローを完全にブロックしています。CLI および CI/CD ツールを使用する場合は、代わりに Web サーバーフロー (sf org login web) または JWT ベアラーフロー (sf org login jwt) を使用します。

ユーザー名とパスワードフローは使用しないでください。Summer '23 以降に作成された組織では Salesforce によってデフォルトでブロックされ、このフローの廃止計画が公開されました。まだユーザー名とパスワードフローに依存している既存のインテグレーションは、移行を繰延技術的負債として処理するのではなく、今すぐ JWT ベアラーフローまたはクライアントログイン情報フローに移行する必要があります。

これらのフローは、インテグレーションを表すアプリケーション登録で設定されます。Spring '26 以降、Salesforce ではその登録を接続アプリケーションから外部クライアントアプリケーション (ECA) に移行します。新しい接続アプリケーションの作成はデフォルトで無効になっており、ECA は新しいインテグレーションを設計するための構造です。既存の接続アプリケーションはインストールされたままですが、組織が移行されると認証が処理されなくなるため、インテグレーションで認証する方法を監査するときは、接続アプリケーションを永続的なモデルとして扱うのではなく、移行を考慮してください。

認証フローの選択に加えて、接続するアプリケーションごとに異なるガバナンスを作成します。

• インテグレーションごとに 1 つの登録: 新しいインテグレーションごとに専用の外部クライアントアプリケーションを登録して、既存のインテグレーションごとに個別の接続アプリケーションを登録します。1 つの広範な登録を複数で共有する代わりに、各インテグレーションで必要な OAuth 範囲のみに範囲を絞り、専用の登録により、各インテグレーションのアクセス権を個別に監査および取り消し可能にします。
• アクセスを明示的に事前承認 (推奨): 外部クライアントアプリケーションの [許可されているユーザー] ポリシーを「管理者が承認したユーザーは事前承認済み」に設定すると、ユーザーは自己承認ではなく、プロファイルと権限セットを使用してアクセス権が付与されます。システム管理者が [設定] で直接設定します。これは、接続できるユーザーを決定するための Salesforce の推奨制御です。
• **APIアクセス制御(**許可リストベースの厳格な管理): より厳格な管理のために、APIアクセス制御では、管理者が承認したユーザーは許可リストに登録された接続アプリケーションのみに制限されます。有効化するには、Salesforce カスタマーサポートへの要求が必要なため、セルフサービス設定として処理するのではなく、そのステップを中心に設計してください。

コード、設定ファイル、またはバージョン管理に認証情報を組み込んではいけません。指定ログイン情報と外部ログイン情報を使用して、循環機能で認証を一元管理します。

従来のユーザー認証とは異なり、エージェントには個別の ID モデルが必要であり、適切なモデルはエージェントが従業員と外部ユーザーのどちらに対応するかによって異なります。ID を正しく設計することはエージェントセキュリティの基盤であり、エージェントがアクセスできるデータと、エージェントがアクセスできるアクションを決定します。

内部エージェントと外部エージェントを詳しく見てみましょう。nts。

• 従業員エージェント (内部): ログインしているユーザーのコンテキスト内でタスクを実行します。このエージェントは、そのユーザーのライセンス、権限セット、項目レベルセキュリティ、および共有ルールを継承するため、個別のエージェント ID はプロビジョニングされず、既存のセキュリティフレームワークによってエージェントが実行できる操作が決まります。
• 顧客エージェント (外部): 公開チャネルを介してやりとりし、公開サイトのゲストユーザーではなく、専用のエージェントユーザー (特別なインテグレーションユーザー) として実行します。専用のインテグレーションユーザーとして実行すると、エージェントはバックエンドアクションを実行し、データにアクセスできます (認証されていないゲストプロファイルではアクセスできません)。ただし、明示的な最小権限で制限されます。カスタマーエージェントを作成するときは、最小限のアクセス権で新しいエージェントユーザーをプロビジョニングし、そのアクションに必要な特定の権限のみを付与します。

エージェントの作業が複数のサービスにまたがる場合、共有 ID またはゲスト ID にフォールバックするのではなく、各サービスホップでユーザーの ID を伝播します。Salesforce OAuth 2.0 トークン交換フローでは、次の処理がサポートされます。

クライアントがユーザーの既存のIDプロバイダー・トークンを提示し、Apexトークン交換ハンドラーがそれをSalesforceユーザーに対応付けてSalesforceアクセス・トークンを発行すると、元のユーザーのコンテキストはサービス・アカウントに折りたたまれるのではなく要求に従います。エージェントのユーザー ID を使用して異常な行動を検出するイベントモニタリングでエージェントの活動を監視します。

適切なモデルの選択は、接続を開始するユーザーと作業を実行する必要があるコンテキストによって異なります。

一般的な接続シナリオは、次のように推奨される方法に対応付けられます。

管理レポートグラフではなく、データアクセスのニーズ (他のユーザーが所有するレコードへのアクセスをユーザーに要求) に基づいてロール階層を設計します。ロール階層の深さは、追加のアクセス権を付与しないレベルを追加するのではなく、実際のデータアクセスリレーションに従うようにします。これは、各レベルで共有計算のオーバーヘッドが追加されるためです。これは、非公開 OWD 設定と大量のデータを使用する組織ではより加重される考慮事項です。

権限セットと権限セットグループは、柔軟で追加的なアクセスを提供することで、プロファイルを急増させる必要性を減らします。プロファイルではなく、権限セットと権限セットグループを使用して機能的なアクセス権を付与します。これにより、アクセス権の追加と監査が可能になります。ログイン時間と IP 制限に加えて、ページレイアウトの割り当て、レコードタイプのデフォルト、アプリケーションの表示を制御するプロファイルは引き続き必要です。プロファイルは、排除する構造ではなく、アクセスモデルの耐久性のある部分として扱います。

トランザクションセキュリティポリシーはベースラインの一部ではなく、コア認証モデルを補完するアドオン機能です。上記の ID、ロール、プロファイル、権限セット、および共有コントロールは、すでにそれ自体でセキュアな認証体制を確立しており、トランザクションセキュリティはその上にリアルタイムのコンテキスト評価を追加します。通常のパターンを超える一括データダウンロード、予期しない地域からのログイン、変更期間外の権限変更など、異常な動作を検出してブロックするポリシーを設定します。

セキュリティ管理には、アーキテクチャ上責任のある可用性のトレードオフがあります。IP 制限の範囲が広すぎると、ネットワークの変更中に正当なユーザーがロックアウトされる可能性があります。また、トランザクションセキュリティポリシーを過度に積極的に調整すると、有効なビジネス活動がブロックされる可能性があります。そのため、これらの制御の範囲を実際のリスクに限定し、適用する前に監視のみモードにして、制御が誤作動した場合のガラスの穴を設計します。

役割: ロール階層の設計、権限セットの作成、トランザクションセキュリティポリシーの設定を行います。

従来のロールベースのアクセス制御) では、ユーザーのロールに基づいて権限が付与されます。ABAC (属性ベースのアクセス制御) は、データ、ユーザー、コンテキストの属性に基づいて承認を判断します。

ほとんどの要件で、コア共有モデルではアクセス権が完全に表現されます。レコードごとの共有では表現できないデータ分類に従う必要がある場合は、専用の ABAC にアクセスします。Data 360 ABAC では、タグとアノテーションを使用してこれを実現します。

Data 360 ABAC は次の方法で動作します。

• データ オブジェクトに適用されるタグ(PII(個人識別情報)、金融タグ、医療タグ、社外秘タグなど)に基づいてアクセス ルールを定義するタグ ベースのポリシー。
• アノテーションはデータオブジェクトに適用され、ポリシーベースの承認の決定をサポートします。
• 詳細ガバナンス ポリシーを有効にするには、新規および既存の組織を明示的に削除する必要がある、デフォルトの**「すべて許可**」ポリシー。

アーキテクチャ上の主な用途は、データ分類の適用です。分類階層が ABAC の適用を促進する方法については、「データ保護とプライバシー」の「データ分類」を参照してください。

このレベルの粒度で運用コストが発生します。コア共有では、「このレコードを表示できるユーザーとその理由」という質問に答えます。ABAC は、調査可能な小さなルールセット (OWD、ロール階層、共有ルール) から回答を取得します。一方、ABAC は、データタグ、ユーザー属性、コンテキストの組み合わせから評価時に回答を取得するため、ポリシーとタグが蓄積されるにつれて、効果的なアクセスの理由付けや監査が難しくなります。

設計要件として監査可能性を適用します。タグを一貫して適用し、適用される分類に合わせてポリシーセットを小さくして名前を付け、ユーザーが特定のレコードに到達した理由を再構築する機能を保持します。所有権ベースのモデルの一般的な置き換えとして処理するのではなく、レコード単位の共有では表現できない分類駆動のケース用に ABAC を予約します。

システム管理者、インテグレーションユーザー、自動化プロセス取引先など、権限が昇格した取引先を特定して保護します。これらのアカウントは、攻撃者にとって価値の高い標的です。

重要な影響のある取引先に高度な制御を適用します。

• 耐フィッシング性 MFA が必要
• ログイン IP 範囲を既知の管理場所に制限する
• ログインアラートと権限変更通知の有効化
• 組織のリスク許容度とコンプライアンス要件によって頻度が決まる高権限取引先の文書化した証明を使用して、定期的なアクセスレビューを実施する
• 緊急時アクセスと使用後の監査のためのガラス破損手順の維持

インテグレーションおよびサービスアカウントの場合:

• OAuth フローを適用し、ユーザー名パスワードフローを適用しない
• IP 制限を適用
• ログイン情報の循環スケジュールの実装
• イベント監視による異常な API 使用パターンの監視

責任: 重要な取引先の特定、高度な制御の適用、四半期ごとのレビューの実施。

適切な初期アクセス権をユーザーに付与し、ロールの進化に応じて権限を調整し、アクセス権が不要になった場合に迅速にプロビジョニング解除する自動化プロセスを設計します。

ID プロバイダーからのプロビジョニングを自動化するために、System for Cross-domain Identity Management (SCIM) を実装します。SAML または OpenID Connect ジャストインタイムプロビジョニングは、最初のログイン時にユーザーを作成する代替方法ですが、ユーザーのプロビジョニングは解除されません。つまり、SCIM はライフサイクルのバックボーンであり、選択肢ではありません。

ID ライフサイクルには次のものが含まれます。

• プロビジョニング: HR システムイベントによってトリガーされる職務に一致するベースラインアクセス権を持つアカウントを作成します。
• アクセスの調整: ロールの拡張に応じて追加の権限を付与し、ロールの変更に応じて権限を取り消す。
• 定期的な再認定: 四半期ごとにアクセス権を確認して検証します。
• プロビジョニング解除: 雇用が終了したとき、またはロールに Salesforce アクセス権が必要なくなったときに、すぐにアクセス権を取り消します。

マネージャーがチームの権限を定期的に確認および検証するときに、アクセス権の再証明プロセスを実装します。レビュー頻度は、リスクとコンプライアンスの要件に基づきます。

責任: SCIMの実装、プロビジョニングワークフローの設計、四半期ごとの再認定の実施。

データを複数の組織に分割することは、純粋にコストまたはレジデンシーに関する決定とみなされることがあります。アーキテクチャ的には、これはセキュリティのトレードオフであり、ガバナンスの結果はアクセス設計に属します。

分離が主なメリットです。別々の組織では、データセット間の境界線が最も強くなります。集合的な共有モデルとクロステナント権限の組み合わせはありませんが、それらを要求する管轄区域には明確な規制線があります。この同じ境界によってガバナンスが分断されます。1 つの組織内で 1 回のみ維持する必要があるすべてのアクセス制御 (権限セット設計、ロール階層、重要影響アカウントの堅牢化、状態チェックのベースライン、イベント監視、SIEM の相関関係など) が組織ごとに適用されるようになりました。つまり、すべての組織で一貫性を維持する必要があります。ある組織で権限が厳格化され、別の組織で権限が欠落すると、攻撃者が見つけて悪用できる不整合が生じるため、組織間のドリフトによって独自の攻撃対象領域が作成されます。組織間インテグレーションでは、以前は存在しなかった認証済みTrust境界が追加されます。各組織間インテグレーションは、保護および監視する必要がある接続です。

そのため、組織を分割する前に、分離報奨金をガバナンスの乗数と加重することが重要です。1 つの組織内でハードローカライズの要求や顧客の契約上の隔離の要件をどうしても満たすことができない場合に備えて、マルチ組織を予約します。採用する場合、アクセスモデル、監視、設定のベースラインを最初からすべての組織で同じように適用するように設計する必要があります。

責任: 複数組織の決定は、コストだけでなくセキュリティのトレードオフとして扱います。マルチ組織が必要な場合、アクセス制御、監視、状態チェックのベースラインをすべての組織で一貫して適用し、組織間インテグレーションをTrust境界として保護します。

データの分類、暗号化の設定、プライバシー制御の設計は各自の責任で行います。

データとプライバシーを適切に保護する方法を詳しく見てみましょう。

データを適切に分類するには、データを把握する必要があります。アーキテクチャの全体的なタスクは、ビジネスドメインを理解し、保持するデータ、その意味、機密データの保存場所をカタログ化するデータ辞書を維持することです。最初に識別したデータのみを分類 (保護) できます。

適切な保護制御を促進するデータ分類スキームを確立します。分類表示ラベルは、それ自体では何も保護しません。これは、適用するコントロールへの入力であるため、割り当てるすべての分類を具体的な暗号化、アクセス、保持、または監視の決定に対応付ける必要があります。データモデリング中に行われる分類の決定は、暗号化要件、アクセス制御、保持ポリシー、コンプライアンス義務に直接影響します。

Salesforce では、組織の規制要件とビジネスニーズに合わせて調整できるフレームワークを提供する 4 階層スキームを使用します。多くの企業は、業界標準に準拠した同様のモデル (ISO 27001 や NIST など) を使用しています。具体的な実装には、コンプライアンス義務 (HIPAA、PCI DSS、GDPR、業界規制など) とビジネスコンテキストを反映する必要があります。

項目レベルで分類を適用します。1 つの取引先レコードには、公開項目 (会社名など)、社外秘項目 (会社の収益など)、制限項目 (社会保障番号など) を含めることができます。項目レベルセキュリティには、次の違いが反映されている必要があります。

分類は、割り当てたタグを読み取り、アクセスルールを適用する属性ベースのアクセス制御によって適用できるようになります。これは、OWD と共有ルールを補完するメタデータ駆動型レイヤーです。

ABAC を分類スキームに合わせると、プラットフォームは次のことができます。

• [**制限あり]**または[**社外秘]**のタグが付けられたデータへのアクセスは、オブジェクトごとに管理される共有ルールではなく、分類自体から制限します。
• 経時的なレコードの分類の変化に応じてアクセス権を調整します。規制対象として新たにタグ付けされたレコードは、手動ルールの変更なしでより厳格なアクセスを継承します。
• 1 つの承認決定で、データ属性 (分類や機密性など) をユーザー属性 (部署や許可など) やコンテキスト (時間や場所など) と組み合わせます。

このスキームに合わせて ABAC ポリシーを設計し、フィールドを [制限あり] として分類することで、共有ルールを個別に管理するのではなく、そのアクセス制御を促進し、適用を分類に固定します。

責任: 分類スキームの定義、データモデラーのトレーニング、設計時の項目の分類、コントロールの設定、およびタグによる適用を促進するための分類階層への ABAC ポリシーの調整を行います。

開始まず、プラットフォームがすでに各組織に提供している情報を使用します。保存データはデフォルトで暗号化されます。Hyperforceは、Salesforceが所有および管理する1つの鍵でストレージ ボリューム全体を保護するボリューム レベルの暗号化を適用します。このベースラインは常にオンで、ソリューションに対して透過的ですが、(項目ごとではなく) ボリュームレベルで機能するため、鍵のライフサイクル内で暗号化および制御するものの選択はプラットフォームに依存します。

そのベースラインでコンプライアンス、契約、データ分類の義務を果たすことができない場合は、Shield Platform Encryptionを使用します。具体的には、ボリュームレベルの暗号化では提供されない次の 3 つのうちのいずれかが必要な場合です。

• 鍵素材を自分で生成、循環、取り消しできるように鍵ライフサイクルを制御
• 保存時に暗号化する標準項目、カスタム項目、ファイル、添付ファイルの選択
• Salesforce がデータにアクセスできないようにする機能。

制限されたデータと、明示的な規制鍵管理義務 (HIPAA、PCI DSS、GDPR など) 下にあるデータは通常トリガーです。ベースラインでは、他のすべてのインフラストラクチャ レベルの保護がすでにカバーされています。

Shield Platform Encryptionは、フィールド レベルで暗号化し、クエリ性のためにセキュリティを犠牲にする2つのスキームを提供します。

確率的暗号化は強力なデフォルトのスキームですが、暗号化されるフィールドは検索条件、並び替え、集計関数 (MAX()、MIN()、COUNT_DISTINCT() 関数など) では使用できません。

確定的暗号化では、レポート、リスト ビュー、および SOQL WHERE 句（大文字と小文字を区別しないまたは大文字と小文字を区別する）の完全一致フィルタリングが有効になります。これは、同じプレーンテキストで常に同じ暗号文が生成されるためです。

デフォルトでは確率的スキームで暗号化し、絞り込みまたは並び替えが必要な特定の項目には確定的暗号化を予約することをお勧めします。数式項目の参照、レポート集計、SOQL 操作への影響を含め、データモデリング設計時にこれらのトレードオフを評価します。

顧客が制御する鍵には、2 つの異なる形式があります。

• **BYOK(Bring Your Own Key)**を使用すると、独自の暗号化ライブラリ、エンタープライズ キー管理システム、またはハードウェア セキュリティ モジュールを使用して、Salesforceの外部でキー素材を生成し、プラットフォームに提供できます。
• キャッシュのみの鍵サービスでは、データ暗号化鍵は制御する鍵サービスに保持されます。Salesforce は、保存するのではなく、オンデマンドで取得します。

どちらのフォームでも、各自のスケジュールで鍵素材を循環および破棄できます。鍵素材を破棄すると、保護したデータが復元できなくなります。これは、定期的ではなく、強力で意図的な制御です。鍵の循環と取り消しの手順を文書化することも重要です。

すべてのインテグレーションで TLS 1.2 以降を使用する必要がありますが (Salesforce プラットフォームで適用されます)、制限付きデータを処理するインテグレーションでは証明書ベースの相互認証を実装する必要があります (独自の設定を使用)。

**責任:**プラットフォームのボリューム レベルのベースラインで十分な場所と、Shield Platform Encryptionのコンプライアンス、契約、または分類の義務の対象となる場所を決定し、暗号化スキームを選択し、顧客が制御する鍵戦略を選択して運用し、機密性の高いインテグレーション用の証明書ベースの認証を実装します。

本番以外の環境で、制限されたデータが Sandbox に取り込まれないようにする戦略を使用して機密データを保護します。

• 部分 Sandbox コピーでは、Sandbox の更新から制限付きデータが除外されます。
• データマスキングルールでは、データの特性を保持するパターンを使用して Sandbox の機密項目値を混同します。
• 合成データ生成は、本番データを必要としない開発環境に適用されます。
• Sandbox テンプレートでは、各 Sandbox 種別に含めるオブジェクトと項目を定義します。

コンプライアンステストの設計はアーキテクチャ上の責任です。現実的な特性を持つ合成データに基づいて開発サイクルとテストサイクルを構築することで、チームは規制対象データを本番境界内に留めながら本番同様の条件で検証できます。

役割: Sandbox戦略の設計、Data Maskルールの設定、模擬テストデータの生成を行います。

アーキテクチャ上の決定により、ユーザーのプライバシーを尊重するソリューションを設計します。

• データの最小化: 述べたビジネス目的にのみ必要なデータを収集します。「このデータを必要とするアーキテクチャ上の決定は何か?」と尋ねて、項目を追加するたびに異議を唱えます。最も安全なデータは、収集しないデータです。
• 目的の制限: 技術的に目的の制限を適用するデータアクセスパターンを設計します。権限セットと共有ルールを使用して、職務の目的に基づいてデータへのアクセスを制限します。たとえば、マーケティングユーザーは、職務で必要とされる場合を除き、サポートケースの詳細にアクセスしないでください。
• 同意管理: マーケティング、分析、および省略可能なデータ処理の同意追跡を個人レベルで実装します。統合システム間で伝達される同意取り消しワークフローを設計します。つまり、同意は詳細で目的に固有です。
• データ主体の権利: アクセス要求 (データコピーの提供など)、修正 (不正確なデータの修正など)、消去 (法的に許可されているデータの削除など)、可搬性 (機械で判読可能な形式へのエクスポートなど) のワークフローを作成します。これらのワークフローは、各管理フレームワークで課される回答期限内に完了するように設計します。これらの期限は管轄区域によって異なりますが、定期的に修正されるため、1 つの値をハードコードするのではなく、管理規制に照らしてワークフローの SLA をパラメーター化し、各期間を確認することが重要です。

責任: 最小限のデータモデルの設計、目的別のアクセスの設定、同意ワークフローの実装、データ主体の権利の自動化の構築を行います。

データレジデンシーは、プロビジョニング前に行うアーキテクチャ上の意思決定であり、後から切り替える設定ではありません。Hyperforceは地域への導入が可能ですが、Salesforceが導入を行う地域のみが存在し、プロビジョニング時に組織のレジデンシーが固定されます。各データカテゴリが存在する必要がある場所を設定し、適切な地域が使用可能かどうかを確認し、合法的に国境を越えるデータ転送メカニズムを設計する責任があります。

デフォルトで国内ストレージを使用するのではなく、開始する前にレジデンシー義務を分類することが重要です。

• **ローカライズが必須。**一部の管轄区域では、特定のデータが国境内にとどまることが義務付けられています (規制対象セクターのみに適用される場合もあります)。Salesforce が国内リージョンで稼働していない場合、ネイティブストレージだけでは要件を満たすことができないため、そのデータに対してデータレジデンシーオーバーレイまたは別の組織が必要です。このリストは変更される可能性があるため、管理規制に対する具体的な義務を確認することが重要です。
• **説明責任ベースのフレームワーク。**ほとんどの体制では、ローカライズが義務付けられません。適切な越境移送メカニズムを備えた地域のハブによって満たされます。このような場合は、遅延を最小限に抑え、コンプライアンスを簡略化するリージョンに基づいて判断します。

データが国境を越えるときに重要なのは、設定前の認識です。つまり、どの移行がどのような法的根拠に基づいて行われるかを把握し、データがエンドツーエンドで管理されるようにアクセス権を設計します。それらが存在する場所では、妥当性の判断は最も摩擦の少ないものです。拘束力のある企業ルール (BCR) と標準契約条項 (SCC) は、残りのほとんどの移行に対応します。明示的な同意は、最後の手段としてのみ使用します。

転送メカニズムと制限のあるレコードアクセス (非公開 OWD や目的範囲の共有など) を組み合わせて、許容される転送の範囲が広すぎないようにします。ドキュメントデータフローの対応付けにより、各データカテゴリの発生元、移行先、および場所が示されます。規制や地域での対応状況が変更されたときに、規制を再確認します。

**責務:**データ カテゴリごとにレジデンシー義務を分類し、プロビジョニング前に地域での可用性を確認し、越境フローの転送メカニズム(適切性、BCR/SCC)を選択し、データ フロー マップを文書化します。

プラットフォームが提供するコンプライアンス体制を維持するソリューションは、各自の責任で設計してください。

このガイダンスは方向性があります。規制要件は、管轄区域や経時的な変化によって異なります。リリースの規制 (適用される法令、監督機関、Salesforce コンプライアンスドキュメントなど) に対して特定の義務を常に検証する必要があります。

Salesforceでは、SOC 2 Type II、ISO 27001、FedRAMP(Government Cloud製品向け)、HIPAA、PCI DSS、地域の認定など、広範なコンプライアンス認定を維持しています(Trust.salesforce.comおよびCompliance.salesforce.comで入手可能)。これらの認定は、プラットフォームインフラストラクチャと共有サービスに関する Salesforce の責任を対象とします。

プラットフォーム認定によってコンプライアンスの負担が軽減されますが、アーキテクチャ上の責任は排除されません。カスタム オブジェクト、Apex コード、インテグレーション、および設定は、プラットフォームで提供されるコンプライアンス体制を維持する必要があります。

責任: コンプライアンス体制を維持するソリューションを設計し、アーキテクチャが規制要件をどのように満たしているかを文書化します。

• 保護された健康情報（PHI）が含まれるすべてのフィールドで Shield Platform Encryption を有効にします。
• HIPAAコンプライアンスについては、HIPAAの記録管理要件を満たすために、保存ポリシーを使用して項目監査履歴を有効にします。管理規制に対して現在の期間を確認します。
• 不正な PHI アクセスパターンを検出するようにイベント監視を設定します。
• アクセス制御、監査ログ、送信セキュリティなど、HIPAA セキュリティルールで要求されるすべての技術的保護を実装します。

• 権限セット設計を使用して職務分離 (SoD) を実装し、単一ユーザーが金融取引を作成および承認できないようにします。
• PCI 環境では、PCI DSS コンプライアンスの範囲を最小限に抑えるために、完全な主取引先番号 (PAN) を Salesforce に保存しないでください。
• 可能な場合は、支払ゲートウェイトークン化を使用します。

• GDPRとLGPDの場合、目的固有の詳細なオプトイン同意を取得する同意管理を設計します。
• CCPA/CPRA はオプトアウトモデルに従います。個人情報の販売や共有をオプトアウトするための明確なメカニズムを、詳細な目的に基づく同意ではなく提供します。
• 各フレームワークの回答期限内に完了し、管理規制に照らして確認済みのデータ主体の権利ワークフローを作成します。
• 同意の有効期限が切れたときにデータを消去するデータ保持の自動化を実装します。

• 規制対象の政府ワークロードには Salesforce Government Cloud を使用します。
• Salesforce 設定に対応付けられた NIST 800-53 コントロールを実装します。
• 政府の SIEM インフラストラクチャに転送されるイベントモニタリングを使用して継続的な監視を有効にします。

ユーザーの責任: 規制要件に基づいて、Shield、項目監査履歴、職務の分離、同意管理、データ保持を設定します。

データ保護とプライバシーの規制は管轄区域によって大幅に異なるため、特定の義務はすぐに変更されるため、このレベルでは国ごとのテーブルではなく意思決定が必要です。

2つのアーキテクチャ レバーはレジデンシーと越境移送です。これらは、[データ保護]と[プライバシー]でカバーされます。

これらの規制に準拠するには、次の要件を満たす必要があります。

• 各データカテゴリが存在する必要がある場所を分類する
• プロビジョニング前に適切なリージョンが存在することを確認する
• 国境を越えるデータの法的移行メカニズムを設計します。

決定フレームワークについての詳細は、「データレジデンシーと主権」を参照してください。

これ以外のすべては、特定の時点における数値とみなされます (管轄区域で使用される同意モデル、データ主体の要求の期限、違反後の規制当局または影響を受ける個人への通知期間、監査レコードの最小保持期間など)。これらの数値は規制によって設定され、フレームワークごとに異なり、規制当局のスケジュールで修正されます。

ここではハードコードしないでください。リリースの規制 (または規制を引用する維持されたコンプライアンスソース) に基づいて次のステップを決定し、運用フットプリントの最も厳しい期間に合わせて設計の規模を決定する必要があります。

設計に含まれる耐久性のあるアーキテクチャの結果を次に示します。

• 1 桁の日数で測定されるデータ主体-要求の期限は、アドホックな手動プロセスでは達成できないため、期限の短い管轄地域で業務を行う場合は DSR 履行を自動化する必要があります。受入には Experience Cloud、ケース追跡には Service Cloud、検出にはプライバシーセンター、履行にはフローを使用します。
• 侵害通知期間は即興では厳しいため、侵害対応ワークフローを事前に作成する必要があります。イベント監視の異常ルール、事前に割り当てられたロール、事前作成された規制機関とデータ主体の通知、フットプリント内の最も厳しい期限を想定したエスカレーションパスを決定します。通常、個々の通知は高リスクの判断によってトリガーされるため、ワークフローにリスク評価を含める必要があります。
• 管轄区域によっては、監査ログの国内での保持が義務付けられているか推奨されている場合があります (最小数年)。そのため、SIEM の保持をフットプリント内で最も長く設定し、ログが管轄区域外に出る可能性があるかどうかを確認する必要があります。

**責任:**データ保護とプライバシーに従ってレジデンシーと移行を設計し、DSRと侵害対応のワークフローをフットプリントの最も厳しい期限まで自動化し、このガイドに記載されている値ではなく、ガバナンス規制に照らして管轄区域固有のすべての数値を確認します。

特定の時点での監査準備ではなく、継続的なコンプライアンス検証を行うように設計します。

• セキュリティ状態チェックでは、Salesforceセキュリティ ベースラインに対して構成を評価し、リスク スコアを提供します。定期的にチェックを実行して、Salesforce セキュリティベースラインの推奨事項へのコンプライアンスを監視します。80% 以上のスコアを維持する ([非常に良い] または [良い] 帯域)。
• Event Monitoringは、ユーザー アクティビティ、APIコール、認証イベント、データ アクセス パターンに関する詳細なログを取得します。イベント ログ ファイルを外部SIEMにルーティングして、ネイティブ保存制限を超える長期保存を実現します。
• トランザクションセキュリティでは、リアルタイムでポリシーに対してイベントが評価され、イベントをブロックしたり、MFA の増加を要求したり、ポリシー違反を通知したりできます。

リリースパイプラインのコンプライアンスチェックを自動化して、リリースで権限モデルが弱まったり、監査設定が無効になったり、非準拠の設定が導入されたりしていないことを確認することが重要です。

**責務:**状態チェックを四半期ごとに実行し、イベント監視をSIEMに転送し、トランザクションセキュリティポリシーを設定し、CI/CDでのコンプライアンス検証を自動化します。

コンプライアンス要件、調査ニーズ、保持義務に基づく監査履歴戦略を設計します。

規制対象環境では、外部 SIEM インテグレーションを使用してイベントモニタリングを実装し、ログの長期保持とシステム間の相関関係を実現します。規制による記録管理要件の対象となるすべての制限付き項目と社外秘項目を対象とする項目監査履歴ポリシーを設計します。

担当: 機密項目の項目監査履歴の有効化、イベント監視の SIEM への転送、トランザクションセキュリティポリシーの設定を行います。

後付けではなく、開発全体でセキュリティを統合する責任があります。

可能な限り早い開発フェーズでセキュリティプラクティスを統合します。アーキテクチャフェーズでの脅威モデリングにより、設計レベルの脆弱性を回避します。機能要件と共に取得されたセキュリティ要件により、セキュリティを後付けのように扱うことはできません。

セキュリティ上の欠陥は、設計フェーズや開発フェーズではなく本番環境で発見されると、修正にかなりのコストがかかります。アーキテクチャレビュー中に見つかった設計レベルセキュリティの欠陥は、1 回の会話で修正できる場合があります。ただし、本番環境で同じ欠陥が見つかった場合、アーキテクチャの再構築、データの移行、コンプライアンスの修正、潜在的な侵害の通知が必要になります。

そのため、デルは次の点に焦点を当てたシフト左のセキュリティを実践しています。

• 設計確定前の脅威モデリング
• ユーザーストーリーのセキュリティ要件
• 開発者向けの安全なコーディングトレーニング
• IDE に統合されている静的分析
• セキュリティに重点を置いたコードレビュー
• CI/CD でのセキュリティテストの自動化
• 本番リリース前のセキュリティ検証

責任: 脅威モデリングの実施、開発者のトレーニング、Code Analyzer の CI/CD への統合、セキュリティ意識の高いコードレビューの義務付けを行います。

Salesforce コンテキストの一般的な脆弱性に対する防御策を設計することが重要です。Salesforceの2025 OWASP Top 10への対応付けを詳しく見てみましょう。

• A01:2025 - Broken Access Control: すべての Apex データ アクセスで CRUD と項目レベル セキュリティ (FLS) をプログラムで適用します。
  • API バージョン 67.0 以降では、Apex はデフォルトでユーザーコンテキストで実行されます。つまり、コードの実行時に現在のユーザーの権限と FLS が適用されます。
    • WITH SECURITYENFORCED が削除されたため、コンパイルエラーが発生します。既存の用途を WITH USER_MODE に置き換えます。プラットフォームでは、標準 UI でアクセス権が適用されます。
  • API バージョン 66.0 以前では、システムモードがデフォルトです。SOQL クエリでは WITH USERMODE、DML 操作では Security.stripInaccessible() を使用します。
• A01:2025 - クライアント側データ API: Lightning データサービスと UI API は、実行ユーザーの FLS、CRUD、共有を自動的に適用するため、それらに基づいて構築されたコンポーネントはデフォルトで最小限の権限を継承します。
  • この保護は、コンポーネントがカスタム Apex をコールすると失われます。命令型 Apex は、ユーザーモードで実行された場合にのみアクセスを適用します。したがって、共有なしで宣言されたクラスは、モデルを無視して移動するエスケープハッチとして機能します。
  • データ アクセスにはLightningデータ サービスとUI APIを使用します。
  • コンポーネントからの命令 Apex コールごとに CRUD、FLS、および共有を再アサートする必要があります。
• A02:2025 - Security Misconfiguration: Health Check を使用してセキュリティベースラインから設定ドリフトを監視します。
  • Experience Cloud サイトでのゲストユーザーアクセスを無効にします (文書化したビジネス上の理由で明示的に必要とされる場合を除きます)。
• A05:2025 - インジェクション: 2025 インジェクションカテゴリには、SOQL/SOSL インジェクションとクロスサイトスクリプティング (XSS) が含まれます。
  • クエリインジェクションでは、すべての動的クエリにバインド変数を使用します。ユーザー入力を直接クエリ文字列に連結しないでください。プラットフォームのパラメーター化されたクエリメカニズムにより、正しく使用した場合にインジェクションのリスクが排除されます。
  • SOQL または SOSL インジェクションの範囲は、クエリ条件を広げることで通話者が到達できないレコードまたは項目を開示する参照です。これらの言語では、書き込みが個別の DML 操作で実行される間、データを参照するため、クエリでオブジェクト権限と項目権限が適用されていない場合、アクセス制御と機密性のリスクが生じます。
  • XSS の場合、Lightning Web コンポーネントは LWC レンダリング エンジンを介して自動的に保護します。
  • Aura コンポーネントと Visualforce では、動的コンテンツを表示するときにプラットフォームのエンコード関数 (HTMLENCODE、JSENCODE、URLENCODE など) を適用する必要があります。

責任: カスタムコードでの CRUD/FLS の適用、エンコード関数の適用、バインド変数の使用、設定ドリフトの監視を行います。

すべてのフェーズでセキュリティゲートを使用して CI/CD パイプラインを設計します。開発速度に合わせてセキュリティを拡張するには、セキュリティを自動化する必要があります。

パイプラインセキュリティフェーズを詳しく見てみましょう。

• ソース制御では、必要なコードレビューを含むブランチ保護ルールが使用されます。メインブランチへの直接コミットや署名済みコミットはありません。
• 静的分析では、PMD、ESLint、RetireJS が組み込まれた Salesforce Code Analyzer を使用して、インジェクション、XSS、および安全でないパターンを検出します。
• セキュリティスキャンでは、SATツールと秘密の検出を使用して、ログイン情報の確定と依存関係の脆弱性のスキャンを防止します。
• 権限の検証では、権限の拡張に関するアラートを送信するセキュリティ ベースラインに対して、自動比較技術を使用して権限の変更を確認します。
• リリース ゲートでは、権限を拡張する変更に対してセキュリティ チームの承認が必要な重要なセキュリティ発見事項でリリースが中断されます。
• リリース後モニタリングでは、リリース後の異常な動作に関するイベントモニタリングアラートが使用されます。

責任: Code Analyzer を CI/CD に統合し、ブランチの保護を設定し、リリースゲートを実装し、権限を自動的に検証します。

包括的なセキュリティテストには、さまざまな脆弱性クラスに対応する複数の手法が含まれます。各戦略を詳しく見てみましょう。

• 静的分析では、開発者 IDE ですぐにフィードバックを得るために、CI/CD パイプラインで自動化ゲートとして Salesforce Code Analyzer が実行されます。静的分析では、アプリケーションを実行せずにソースコードの脆弱性を特定します。
• ペネトレーション テストでは、信頼できないユーザーに公開されているカスタム アプリケーション(特にExperience Cloudサイトと公開API)に対してペネトレーション テストを実施します。
  • AppExchange および AgentExchange セキュリティレビューでは、静的分析レポートが常に必要です。
  • ソリューションでサードパーティの Web アプリケーションまたはサービスを統合する場合、動的スキャンレポート (侵入テスト) が必要です。
  • ペネトレーションテストでは、ライブアプリケーションに対する攻撃者の手法がシミュレートされます。
• セキュリティ重視単体テストでは、異なる権限プロファイルを持つユーザーとして実行することでアクセス制御の適用を検証する Apex テストを作成します。CRUD/FLS 適用によって不正アクセスがブロックされることを確認することが重要です。
• 連動関係スキャンでは、AgentExchange パッケージと JavaScript ライブラリの既知の脆弱性を監視します。インストール済みパッケージのセキュリティアドバイザリを登録することが重要です。

担当: Code Analyzer の実行、侵入テストの実施、セキュリティ単体テストの作成、連動関係のスキャンを行います。

Salesforce のセキュリティおよびデータインシデント対応では、侵害、不正アクセス、悪意のあるデータ破壊の検出、阻止、復旧に重点が置かれています。インシデント対応チームは、隣接する責務を持つ 2 つの隣接する柱と連携します。

• Operational Excellenceは、インシデント管理の運用マシン(重要度階層、オンコールのローテーション、エスカレーション、インシデント後のレビューなど)を対象とします。
• 信頼性には、バックアップや災害復旧戦略など、RTOおよびRPO目標に対する可用性リカバリが含まれます。

アーキテクトは、セキュリティインシデントの検出可能性、対応、復旧を設計する責任があります。

検出可能性は、明示的に設計する必要があるアーキテクチャ品質です。包括的な監視を行わない場合、セキュリティインシデントが長期間検出されない可能性があります。

複数のチャネルで検出を実装することが重要です。

• Event Monitoringは、ログイン、レポートとデータのエクスポート、権限の変更、APIコールを含む未加工のイベント ログを取得します。異常なイベントを特定する必要があります。これには、検出ロジックを決定するために設定したログに加えて、トランザクションセキュリティポリシーまたは SIEM の相関関係が必要です。
• トランザクションセキュリティポリシーは、リアルタイムでイベントを評価し、疑わしいアクションをブロックします。これらのポリシーを設定する必要があります。
• 監査履歴の設定では、プラットフォームで提供される管理上の変更を追跡しますが、監視する必要があります。
• カスタム アプリケーション ロギングは、実装する必要がある Apex のセキュリティ関連イベントを取得します。

イベントモニタリングログを SIEM プラットフォームに転送して、エンタープライズセキュリティテレメトリと相関させます。疑わしいパターンを検出するアラートルールを設計すると同時に、行動のベースラインによって偽陽性を最小限に抑えます。

**役割:**イベント監視をSIEMにルーティングし、トランザクションセキュリティポリシーを設定し、カスタムログを実装し、動作ベースラインを確立します。

インシデントが発生する前にインシデント対応をサポートするアーキテクチャ上の意思決定を文書化することが重要です。

• 分離境界は、重要なビジネス機能を中断することなく、侵害されたコンポーネントを分離するソリューションを設計します。権限セットの取り消し、IP 制限の変更、セッションの終了を設定して、迅速な分離機能を提供 する必要があります。
• フォレンジック保存では、イベント監視を使用して詳細な活動ログを提供します (プラットフォーム機能)。項目監査履歴では、設定に基づいてデータ変更履歴が保持されます。攻撃者がアーキテクチャを変更できないようにログを不変ストレージに転送します。
• リカバリ手順には、一般的なインシデント種別のテスト済みリカバリプロセスが文書化されています。バックアップの整合性を定期的に検証することが重要です。セキュリティインシデントシナリオでは、目標復旧時間 (RTO) と目標復旧時点 (RPO) を把握する必要があります。
• コミュニケーションワークフローは、インシデント中に機能する通知メカニズム(侵害される可能性のあるシステムに依存しない帯域外通信チャネル、事前作成済みテンプレート、エスカレーション手順など)を設計します。
• 脆弱性開示チャネルは、公開 Experience Cloud サイト用です。これにより、RFC 9116 security.txt 標準で公開されている開示ポリシーを使用して、セキュリティの問題を外部の研究者に文書化して監視できます。多くの場合、外部レポートはインシデントの最初のシグナルであるため、担当するアーキテクチャの一部としてこの受入パスを確立することが重要です。

責任: 分離手順の文書化、不変の外部ストレージへのログの転送、四半期ごとのリカバリ手順のテスト、帯域外通信の確立、公開サイトの脆弱性開示チャネルの公開を行います。

Salesforce では、プラットフォーム固有のシナリオに対応する機能を準備することが重要です。

• 侵害されたユーザ アカウントは、Event Monitoring のログイン異常（予期しない場所、異常な時刻、新しいデバイスなど）によって検出されます。アカウントが侵害された場合は、ユーザーを凍結し、ログイン情報を強制的にリセットし、[設定] 監査履歴とデータアクセスログを確認して侵害期間を決定します。
• 一括データ持ち出しは、Event Monitoring レポートのエクスポートと API データアクセス量の異常によって検出されます。データの持ち出しが発生したら、すぐにセッションを取り消し、権限を制限し、影響を受けるレコードと分類レベルを特定します。
• 不正なコードリリースは、リリース監視と [設定変更] によって検出されます。未承認のコードがリリースされたら、すぐにリリースをロールバックし、侵害されたリリースログイン情報からすべての変更を監査します。
• 権限のエスカレーションは、[設定] [監査履歴] 監視で、承認された変更期間外の権限の変更を検出します。権限のエスカレーションが発生したら、エスカレーションされた権限をすぐに取り消し、アクセス権が昇格して実行された活動を監査します。

各自の責任: プラットフォーム固有のシナリオの対応手順を文書化し、各シナリオを検出するように監視を設定し、机上の課題で手順をテストします。

インシデント後、アーキテクチャの改善に重点を置いた、判断不要のインシデント後レビューを実施することが重要です。何が起きたか、既存のコントロールがインシデントを防止または検出できなかった理由、将来のリスクを軽減するためにどのようなアーキテクチャの変更が必要かを文書化する必要があります。

インシデント後のレビューの目的:

• インシデントタイムラインと攻撃者の手法を判断します。
• インシデントを有効にした制御エラーを特定します。
• インシデントで明らかになったアーキテクチャ上の弱点をすべて文書化します。
• リスク低減に基づく修復に優先度を付けます。
• チーム全体で教訓を共有します。
• 検出ルールと応答手順を更新します。

インシデント総計値を経時的に追跡して、平均検出時間 (MTTD)、平均応答時間 (MTTR)、影響範囲を判断することが重要です。

責任: インシデント後レビューをタイムリーに実施し、ADRの改善点を文書化し、MTTDとMTTRのトレンドを追跡し、得られた教訓を共有します。

このチェックリストは、アーキテクチャのレビュー時、本番リリース前、および継続的な評価のために定期的に使用します。各項目は、Salesforce アーキテクトとしての責任を表します。

共有責任

• Salesforce で保護されているすべてのもの (インフラストラクチャ、プラットフォーム、コンプライアンス認定など) を文書化します。
• 保護する必要があるすべてのもの (設定、アクセス、カスタムコード、データガバナンスなど) を文書化します。
• 共有責任領域 (インシデント対応、脆弱性管理、監視など) を特定します。
• 関係者と実装チームに責任をできるだけ明確かつ簡潔に伝えます。

セキュリティアーキテクチャ

• 構築を開始する前に、STRIDE 手法を使用して脅威モデリングを完了します。
• データ、アプリケーション、ID、インテグレーションレイヤーで多層防御コントロールを適用します。
• すべてのアクセス要求に明示的な検証を要求するゼロ信頼の原則を実装します。
• 機密データ、インテグレーション、API、特権アカウントを対象とする現在のセキュリティ資産インベントリを維持します。
• 脅威分析や制御の正当性など、セキュリティアーキテクチャに関する意思決定を ADR で文書化します。
• プール トークンではなくユーザーごとのIDを伝達することで、Salesforce Trust境界でヘッドレス クライアントと代理クライアントを保護します。
• 外部クライアントアプリケーションを使用して、OAuth ログイン情報を保存、循環、および最小権限範囲で保存します。
• コンテナ化されたインテグレーションの場合、セキュリティ境界としてコンテナの分離を適用し、コンテナ間およびハイブリッド VPN トラフィックを mTLS で暗号化し (フレームワークで必要な場合)、リリース地域をデータレジデンシーおよびコンプライアンス認定に合わせます。

ID およびアクセス管理

• 機密データを含むオブジェクトの OWD を [非公開] に設定します。
• 広範な参照アクセス権が文書化されている要件のオブジェクトに対して [公開/参照のみ] を予約します。
• すべての本番 UI アクセスに MFA を適用し、特権アカウントのハードウェアセキュリティキーを適用します。JWT ベアラーまたはクライアントログイン情報を使用する API のみのインテグレーションは除外されます。
• 強力な IdP 認証を使用する SAML 2.0 または OpenID Connect を使用して SSO を実装します。
• すべての API 認証に OAuth 2.0 (JWT ベアラー推奨) を使用します。埋め込みログイン情報に OAuth 2.0 は使用しないでください。
• 文書化されている最小権限要件に基づく権限セットを使用してアクセス権を付与します。
• 重要な影響のある取引先に高度な制御を適用します (IP 制限、ログインアラート、定期的なアクセスレビューなど)。
• 組織のリスク許容度とコンプライアンス要件によって頻度が決まる高権限取引先の文書化された証明を使用して、定期的なアクセスレビューを実施します。
• SCIM プロビジョニングと 90 日間の休眠アカウント検出を使用して、ID ライフサイクルを自動化します。
• ログインユーザーのコンテキストで従業員エージェントを実行し、顧客エージェント専用の最小権限のエージェントユーザーをプロビジョニングします。公開サイトのゲストユーザーに対しては、絶対に実行しないでください。
• エージェントインスタンス識別子とボット定義識別子を使用して、エージェント認証用の JWT を実装します。
• データ分類と一貫したメタデータタギング標準に準拠する ABAC ポリシーを定義します。

データ保護とプライバシー

• すべてのデータを分類し、各分類レベルに適した保護制御を適用します。
• ドキュメント化された鍵管理を使用して**、「制限**されたデータの Shield Platform Encryption」を有効にします。
• 制限付きデータの証明書ベースの認証とのすべてのインテグレーションで TLS 1.2+ を要求する。
• マスキングまたは除外によって**、制限さ**れたデータが本番以外の環境に入らないようにします。
• 目的ごとの詳細な追跡と取り消しワークフローを使用して同意管理を実装します。
• 各管理フレームワークの応答期限内に完了するデータ主体の権利ワークフローを作成します。これらは、業務フットプリントの最も厳しい期間に合わせてサイズを設定し、各数値が管理規制に対して確認される、管理されたコンプライアンスソースから管轄区域ごとにパラメーター化する必要があります。
• データレジデンシー要件を文書化し、Hyperforce リージョンのアライメントを検証します。

コンプライアンスと法令順守

• 業界の規制要件を満たすプラットフォーム認定を検証します。
• ネイティブ保持制限を超える保持については、SIEM ルーティングを使用したイベント監視を有効にします。
• 制限された項目を対象とするように項目監査履歴を設定し、保持が規制の最小要件を満たすようにします。
• セキュリティ状態チェックスコアを 80% 以上 ([非常に良い] または [良い] 帯域) に保ち、例外があれば文書化します。
• 重大な違反時に破損した CI/CD パイプラインのコンプライアンス検証を自動化します。
• トランザクションセキュリティポリシーを実装して、リアルタイムで異常を検出して対応します。

安全な開発ライフサイクル

• 設計フェーズ (大規模な構築投資を行う前) で脅威モデリングを実行します。
• すべてのApex環境でCRUD/FLSを適用します。
• API バージョン 67.0 以降では自動ユーザーモード適用を使用し、API バージョン 66.0 以前では WITH USERMODE または stripInaccessible() を使用します。
• API バージョン 67.0 で削除された WITH SECURITYENFORCED は使用しないでください。
• 重要な所見によってリリースがブロックされた場合、CI/CD で Salesforce Code Analyzer を実行します。
• 本番でのすべての変更について、セキュリティ意識の高いレビュー担当者によるコードレビューを要求します。
• すべての公開アプリケーションと Experience Cloud サイトで侵入テストを実行します。
• SOQL、SOSL、HTML コンテキスト全体でインジェクションを防止するすべてのユーザー入力を検証してサニタイズします。

セキュリティインシデント対応

• 行動ベースラインを使用して疑わしいパターンを検出するようにイベント監視アラートルールを設計します。
• フォレンジック保存のためにログを変更不可能な外部ストレージに転送します。
• プラットフォーム固有のシナリオのインシデント対応手順を文書化してテストします。
• ADR を使用して、責任のないインシデント後レビューを実行し、アーキテクチャの改善を取得します。
• MTTD および MTTR 評価指標を追跡して、検出と応答のギャップを特定します。

適切に構築されたフレームワークに関するフィードバックを共有する。