更新スケジュールについては、こちらを参照してください。

安全なシステムは、組織の関係者とデータを保護します。セキュアなアーキテクチャでは、ユーザー ID を検証し、必要な情報のみへのデータアクセスを制限し、データ侵害を防止します。

Salesforce は、Customer Trust とデータ セキュリティを優先します。Salesforce Platform はプライバシーとセキュリティを確保します。リアルタイムのシステム パフォーマンスおよびセキュリティ情報は、Salesforce Trustで入手できます。

組織と顧客データを保護することは、セキュアな Salesforce ソリューションを構築するための基礎となります。Salesforce アーキテクトは、Salesforce の組み込みセキュリティ機能を利用して組織と顧客データを保護する責任を負います。これらの決定を行うときは、地理的分布、業種、会社の業務手順、顧客のデータ型を考慮します。

組織のセキュリティ、セッションのセキュリティ、データセキュリティの 3 つの領域に焦点を絞ることで、ソリューションのセキュリティを強化できます。

組織のセキュリティでは、検証済みの承認されたユーザーのみがシステムにアクセスでき、必要な機能とデータのみにアクセスできるようにすることで、不正なアクセスからシステムを保護します。

組織のセキュリティに問題があることを示す兆候には、次のようなものがあります。

• ユーザーを有効化または無効化するアドホックプロセス
• ユーザーまたはシステムロールの変更の承認を更新する手順が明確でない
• ユーザーセキュリティを正しく割り当てるための個人の組織的な Knowledge への依存
• 確立されたセキュリティフレームワークや業界のベストプラクティスに適合できない
• 構造化データガバナンスフレームワークとサポートポリシーがない

認証と承認に焦点を絞ることで、Salesforce 組織のより適切なセキュリティ制御を構築できます。

認証は、システムにアクセスしようとしているユーザーの ID を検証する、セキュリティとアクセス管理に不可欠です。これは、人間のユーザー (従業員、顧客) と自動化されたユーザー (外部システム、インテグレーション) の両方に適用され、各ユーザー種別に特定の認証スキームが必要です。組織内のすべての Salesforce エントリポイントで安全なアクセスを確保するには、さまざまな認証方法を設定する必要があります。

Salesforce で安全な認証フローを作成する

• **人格ではなく個人に基づいて Salesforce ユーザーを作成します。**Salesforce の組み込み監査機能は、各ユーザーアカウントがプラットフォームにアクセスする 1 人の個人に対応している場合に最も効果的です。共有ユーザーアカウントを使用すると、これらの監査の有効性が低下し、セキュリティの脆弱性がさらに発生し、アカウント侵害の潜在的な影響がエスカレーションし、効果的な認証スキームを作成する機能が複雑になります。これには、インテグレーションユーザーのユーザーアカウントも含まれます。
• 安全な UI ベースのアクセスシナリオ。ほとんどの人間のユーザーは、Salesforce 組織にある種の UI ベースのアクセス (ログインアクセスと呼ばれることが多い) を必要とします。Salesforce では、次のログインシナリオに対していくつかの保護レイヤーが提供されます。
  • **パスワードポリシー。**サイバー犯罪者は多くの場合、ユーザー名とパスワードを狙ってアプリケーションへの不正アクセスを取得します。パスワード ポリシーの設定は、ログイン アクセスを保護するための基本的なステップですが、Salesforce ではユーザーごとにポリシーを上書きできるため、これだけでは不十分であることに注意してください。
  • 多要素認証 (MFA)。Salesforce では、すべての UI ベースのユーザーログインに MFA が必要です。MFA は、ユーザー名とパスワードを正常に入力した後で追加の ID 形式または要素を入力するようにユーザーに要求することで、ログイン情報の漏洩やブルートフォース攻撃に対する重要な防御策を提供します。この追加要素は通常、モバイルデバイス、セキュリティキー、生体認証マーカーなどの物理的な形式を取ります。
  • シングルサインオン (SSO)。SSO シナリオでは、ユーザーは組織のアプリケーション全体で 1 セットのログイン情報のみを使用します。システムへのアクセスは一元的にプロビジョニングおよび管理されるため、セキュリティが向上します。Salesforce は、SSO シナリオでサービスプロバイダーまたは ID プロバイダーとして機能できます。SSO 実装の停止や問題に対処できるように、一部またはすべてのシステム管理者が Salesforce に直接ログインできるようにします。
  • **ログイン後のステップ。**一部の使用事例では、システムにアクセスする前にユーザーが追加の手順を実行する必要がある場合があります。カスタムログインフローを実装して、次の追加プロセスステップでユーザーをガイドできます。例として、次のようなものがあります。
    • 契約条件への同意
    • ログイン検出とパスワードなしのログインシナリオの使用
    • ユーザーあたりの同時 Salesforce セッション数を制限して、セッションベースの攻撃の可能性を減らす (「セッションセキュリティ」を参照)。
    • ジオフェンスサービスへの接続
• 安全な API ベース アクセス シナリオ。すべてのユーザーが Salesforce 組織の API ベースのアクセスを要求できます。Salesforce では、API ベースのシナリオに対して次のような保護レイヤーが提供されます。
  • API アクセスコントロール。API アクセス制御を使用しない場合、組織に接続アプリケーションが導入されていなくても、有効なログイン情報セットを持つすべてのユーザーが任意のアプリケーションを活用して組織に接続できます。データアクセス制御は引き続き適用されますが、ユーザーは制御されていない方法で情報にアクセスできました。たとえば、システム管理者の承認なしに、アプリケーションを使用して大量のデータをダウンロードしたり、破損した情報をアップロードしたりすることができます。
  • API Only 権限。Salesforce で API 限定ユーザー権限を設定できます。権限セットの一部としてこれを自動化ユーザーまたはインテグレーションユーザー人格に割り当てて、UI ベースのアクセスを完全にブロックします。
  • 証明書とキー。証明書と鍵により、Salesforce は、承認された企業または会社からの要求であることを検証できます。Salesforce で SSO を使用する場合は、証明書とキーを設定する必要があります。
  • 接続アプリケーション。Salesforce で接続アプリケーションを設定すると、必要な認証プロトコル、認証範囲、セッションの動作など、Salesforce への外部システムアクセスを 1 つの定義で制御できます。
  • 指定ログイン情報。指定ログイン情報を使用すると、Salesforce 内の 1 つの定義で外部アクセス ポイントと認証プロトコルを制御できます。Apex、外部サービス、および Salesforce Connect データソースからのコールアウトの認証を安全に定義および管理するために使用できます。
• Agentforce Agent ユーザー認証。Salesforce 上に構築された Agentforce エージェントは、実際のユーザーと同様に管理可能な権限を持つエージェントユーザーオブジェクトを使用します。エージェントを設定するときは、アクセスをエージェントが果たす役割に合わせて慎重に調整し、データアクセスをエンドユーザーにサービスを提供するために必要なアクセスのみに制限します。同様に、エージェントは公開アクションと非公開アクションの両方で設定できます。非公開アクションの場合、エンドユーザーを検証して認証し、エージェントコンテキストに対応付けます。これにより、エージェントはエンドユーザーのアクセス制御内で偽装および操作を行い、セキュリティと Trust を維持できます。

次のパターンとアンチパターンのリストは、Salesforce 組織での適切な (および劣悪な) 認証アーキテクチャを示しています。これらを使用して、構築前に設計を検証したり、さらなる改善の機会を特定したりできます。

Salesforce で使用できる認証ツールについての詳細は、「Tools Relevant to Secure (セキュリティに関連するツール)」を参照してください。

認証では、ユーザーがアクセスできる機能、機能、データ、および認証後にこれらのリソースを使用して実行できるアクションを定義します。認証制御は人間のユーザーのみを対象とするのではなく、Agentforce Agent ユーザー (特に、認証されていないエンドユーザーにサービスを提供するエージェント) に合わせて調整する必要があります。

組織で認証できるユーザーの制限は重要な最初のステップですが、強力な認証と堅牢な認証を組み合わせることも重要です。適切な承認制御がないと、ユーザーはレコードを作成、編集、削除したり、ビジネスや関係者に有害な方法でシステム機能にアクセスしたりする可能性があります。承認管理が不十分な場合、システムが使いづらくなる可能性もあります。ユーザーがシステム内で実行できる操作を制御することで、より高いレベルの Trust を促進し、システムとユーザーの両方を保護できます。

Salesforce の安全な認証スキームを作成する

• 最小権限の原則に従います。ユーザーに ToDo に必要な権限のみを割り当てることで、最小権限 (PoLP) の原則を受け入れます。この原則に従うには、詳細でモジュール化された権限セットを設計します。これにより、権限セットグループを使用した高度なアクセス制御が可能になり、ミュートや有効期限の設定などの権限を正確に管理できます。システムの機能単位をビジネス機能に合わせて、詳細な権限と有効な権限セットグループを定義します。権限は、Salesforce のメタデータアクセスに適用されます。Salesforce データアクセスの PoLP の設定についての詳細は、「共有と表示」を参照してください。
• **ユーザーアクセスは、個人ではなく人格の観点から考えます。**個々のユーザーの観点から認証 (またはセキュリティ全般) を考慮すると、システムを拡張および進化させることはできません。代わりに、ユーザーのグループを表す人格を設計して管理します。セキュアな Salesforce ソリューションでは、認証に個人を使用し、認証に人格を使用します。個別の人格のセキュリティ設定を定義することで、セキュリティモデルのアクセス権と権限を詳細に制御できるため、長期的にリファクタリングする必要が最小限に抑えられます。定義するセキュリティ人格を設計標準とドキュメントに含めます。
• **権限セットと権限セットグループを使用して、メタデータへのユーザーアクセスを制御します。**権限セットと権限セットグループは、ユーザーがアクセスできるメタデータとそのメタデータで実行できる操作を制御します。Salesforce メタデータについての詳細は、「メタデータとデータ」を参照してください。権限セットと権限セットグループを使用して、アプリケーションの割り当て、機能ライセンスの有効化、管理パッケージアクセス、システム権限、CRUD アクセス、項目レベルのアクセスを設定します。このアクセス権を設計標準とドキュメントに含めます。
• 組織の共有設定 (OWD) と共有を使用して、ユーザーのデータアクセスを制御します。データとメタデータは Salesforce では別個のエンティティであり、それぞれに個別のアクセス制御が必要です。OWD と組み込み共有ツールを使用して、Salesforce データ (個々のレコード、ファイル、ドキュメント) のアクセス権を設定します。詳細は、「データセキュリティ」を参照してください。
• **OAuth 範囲を使用して、接続アプリケーションのアクセスを制御します。**接続アプリケーションを設定するときに、アプリケーションユーザーが Salesforce リソースに対して持つ範囲またはアクセス権限を定義します。OAuth トークンの管理についての詳細は、「セッション管理」を参照してください。
• **インテグレーションごとに 1 人の Salesforce ユーザーを作成します。**最小権限の原則に従うには、インテグレーションごとに一意の Salesforce インテグレーションユーザーを作成します。これにより、特定のデータアクセスを割り当てて、操作の制御を改善し、トランザクションのトレーサビリティを確保し、潜在的なセキュリティ侵害の影響を最小限に抑えることができます。
• **すべてのエージェントユーザーに対して PoLP を使用して一意のアカウントを実装します。**各 Agentforce Agent ユーザーは一意であり、複数のエージェントで再利用しないでください。これらのアカウントの権限は、最小権限の原則に厳密に従う必要があります。エージェントユーザーが実行するアクションは、Salesforce 内の高度なセキュリティコンテキストで、または Salesforce のアクセス制御が適用されない外部システムに対して動作する場合があります。これにより、アクションが機密情報にアクセスしたり、ユーザーに開示したりする可能性があります。
• **プロファイルの使用を最小限に抑え、プロファイル外のアクセス制御を移行します。**プロファイルを使用すると、ログイン IP 範囲、ログイン時間、従来の Salesforce Classic ユーザー インターフェイスに固有の機能(具体的には、デフォルトのレコード タイプとページ レイアウトの割り当て)へのアクセスを制限できます。現在プロファイルにあるその他の機能は、権限セットおよび権限セットグループの同等の機能に移行する必要があります。Salesforce Classic UI 機能に関連付けられたプロファイルの機能は、修復の対象にする必要があります。

次のパターンとアンチパターンのリストは、Salesforce 組織での適切な (および不適切な) 認証方法を示しています。これらを使用して、構築前に設計を検証したり、さらなる改善の機会を特定したりできます。

Salesforce から入手できる認証ツールについての詳細は、「Tools Relevant to Secure (セキュリティに関連するツール)」を参照してください。

次の表に、組織で検索 (または作成) するパターンと、回避または修正の対象となるアンチパターンの選択を示します。

✨ パターン & アンチパターンエクスプローラーで、組織のセキュリティに関するより多くのパターンを検出します。

セッションとは、ユーザーに関連付けられた一定期間の一連の要求と応答です。ユーザーが Salesforce に対して正常に認証されると、セッションが開始されます。セッションセキュリティとは、セッションの干渉やハイジャックを阻止して不正アクセスやデータ侵害を防止するようにシステムを設定する方法です。

システムのすべてのユーザー活動はセッションのコンテキスト内で発生するため、セッションの開始方法、セッション中に実行できること、ユーザーが使用する (および使用する) デバイス、疑わしいセッション動作や異常なセッション動作を検出して対処する方法を考慮することが重要です。

Salesforce でセッションセキュリティを構築するには、セッション管理、デバイスアクセス、脅威の検出と対応という 3 つの鍵に焦点を当てます。

セッションは、ユーザーが正常に認証され、Salesforce へのアクセス権が付与されたときに開始されます。これらのセッションにより、プラットフォームは特定の要求と応答を特定のユーザーに関連付けることができます。

HTTPS プロトコルは、フロントエンドクライアントと Salesforce Platform 間の通信を容易にします。クライアントには、ブラウザー、モバイルアプリケーション、ローカルアプリケーションなどが含まれます。HTTPS はステートレスなプロトコルです。つまり、すべての通信は個別であり、以前または将来の通信とは無関係です。

このステートレスなアプローチにより、ネットワーク通信が高速化され、パケット間のリンクの切断によるエラーが排除されます。ただし、Web アプリケーションには、複数の要求と応答のやり取りで各ユーザーの ID やその他の関連情報を追跡する方法がまだ必要です。Salesforce は、ほとんどの Web アプリケーションと同様に、セッションとトークンを使用してこれを実現します。

• セッションにより、Salesforce は要求と応答をユーザーに関連付けることができます。ユーザーが認証されると、プラットフォームはセッション ID をクライアントアプリケーションに送信します。この ID には、ユーザーの要求 (データの移動、検索、送信など) が含まれます。
• トークンを使用すると、ユーザーおよび接続アプリケーションは ID を 1 回検証するだけで、それ以降は一意のアクセストークンを使用できます。トークンの有効期限は制限され、特定のリソースへのアクセスのみが許可されます（アクセスレベルの設定についての詳細は、「認証」を参照してください）。トークンを使用すると、ユーザーがログインしなくても、承認されたリソースにアクセスできます。

セッションとトークンが適切に保護されていない場合、悪意のある人物がセッションとトークンを妨害し、ユーザーになりすましたり、システムで悪意のあるコードを実行したりする可能性があります。

Salesforce の安全なセッション管理を構築する

• Salesforce でセッション種別がどのように分類されるかを理解します。承認済みセッション種別を特定してセキュリティユーザー人格に対応付け、ドキュメントに記録します。
• **セッションの発信方法とセッション トラフィックの送信先を制御します。**さまざまなユーザー人格が開始できるセッションの種類を特定したら、未承認のソースまたはコンテキストから発生するセッションをブロックするコントロールを設定します。Salesforce では、次のようなセッションの開始元とトラフィックを制御する方法がいくつか用意されています。
  • 組み込みセッション保護。Salesforce では、クロスサイトスクリプティング、クロスサイト要求フォージェリ、コンテンツ盗聴、クリックジャックなど、セッションベースの悪意のある活動に対する組織全体の保護が自動的に有効になります。これらの保護は無効にしないでください。無効にできない保護もあります。
  • ドメインと IP 範囲。すべての Salesforce 組織で[私のドメイン]がデフォルトで有効になっており、Salesforce アクセス用の会社固有のサブドメインが作成されます。[私のドメイン] を使用して、組織に関連付けられた名前をカスタマイズまたは変更できます。さらに、Salesforce では Experience Cloud サイトやその他のアプリケーションページの追加ドメイン設定をサポートしています。注意:ユーザーが会社のファイアウォールの内側から Salesforce にアクセスする必要がある場合、必要なドメインをファイアウォールの許可リストに追加します。ログイン IP アドレスと信頼済み IP アドレスを設定して、Salesforce への受信ログイン要求とセッション要求を制御できます。
  • ログイン時間。特定のユーザー 人格が勤務時間を設定している場合、定義されたログイン時間外に Salesforce にアクセスするユーザー 人格を制限できます。
• セッションレベルセキュリティの強化が必要な活動を制御します。デフォルトでは、セッションには標準と高保証の 2 種類のセキュリティレベルを設定できます。これらのセキュリティレベルを使用して、ユーザーがレポートやダッシュボードへのアクセス、Salesforce 組織のセキュリティ設定の管理などの活動を実行できるようにする方法と実行できないようにする方法を制御します。セッションレベルのセキュリティポリシーでは、ユーザーが操作を実行するために高保証セッションの確立を要求したり、機密操作の実行をブロックしたりする場合があります。
• セッションベースの権限の追加が必要な活動を制御します。Salesforce では、セッションベースの権限の有効化がサポートされ、特定のセッション中にユーザーが権限の昇格やアクセス権の付与を一時的に許可できます。セッションベースの権限は、フローまたは Salesforce API で有効化および無効化できます。
• タイムアウトによる無効なユーザーセッションの管理。無効なセッションを終了することは、セッションセキュリティの管理の重要な部分です。これにより、たとえば、ユーザーがブラウザータブで Salesforce セッションを開いたままにして別のアプリケーションで作業している場合や、ユーザーのモバイルデバイスが Salesforce にログインしていて無人の場合にシステムを保護できます。Salesforce のデフォルトのセッション無操作タイムアウトは 2 時間です。セッションの無操作タイムアウトレベルを増減できますが、タイムアウトの増減は、説得力のある十分な根拠に基づいて行う必要があります。
• **トークン設定を使用して接続アプリケーションセッションを管理します。**接続アプリケーションを設定するときに、接続アプリケーションを使用して Salesforce にアクセスするユーザーに付与される範囲 (認証レベル) も定義します。この範囲は、接続アプリケーションのユーザーが正常に認証された後に発行される OAuth トークンを使用してセッションレベルで適用されます。トークンの有効期間は、トークン更新ポリシーを使用して制御できます。組織管理者は、必要に応じてユーザーごと、または組織ごとにトークンを手動で取り消すことができます。

次のパターンとアンチパターンのリストは、Salesforce 組織での適切な (および不適切な) セッション管理を示しています。これらを使用して、構築前に設計を検証したり、さらなる改善の機会を特定したりできます。

Salesforce から入手できるセッション管理ツールについての詳細は、「Tools Relevant to Secure (セキュリティに関連するツール)」を参照してください。

現在のコンテキストでは、デバイスとは、デスクトップワークステーション、ノートパソコン、タブレット、携帯電話など、個人が Salesforce にアクセスするために使用する電子機器を指します。

ポータブルデバイスを使用すると、ユーザーはどこからでも柔軟に Salesforce にアクセスできます。ただし、この利便性により、悪意のあるアクターにさらなる攻撃ベクトルがもたらされる可能性があります。これらの脅威ベクトルは、公共の場所で肩を並べてログイン情報を盗む単純な戦術から、デバイスにマルウェアをインストールしたり、偽の公衆 Wi-Fi ネットワークを作成してデータ送信を傍受したりするより高度な方法まで多岐にわたります。このため、デバイス (特にポータブルデバイス) のセキュリティ保護は、システム全体のセキュリティにとって不可欠です。

Salesforce のデバイスアクセスを保護する

• Salesforce 提供のモバイルアプリケーションソリューション。Salesforce にアクセスする必要があるモバイルデバイスのユーザーに、iOS および Android で使用可能な公式の Salesforce アプリケーションを使用してもらいます。ビジネスニーズにカスタムモバイルソリューションが必要な場合は、安全な認証および承認方法を提供する Salesforce Mobile SDK を使用する必要があります。
• モバイルデバイスの使用をセッション管理に組み込みます。セッションセキュリティレベル、セッションタイムアウト、その他のセッションコンテキスト制御では、モバイルデバイスでのユーザーからの予想されるアクセスを考慮する必要があります。Salesforce へのアクセスを許可するデバイスと許可しないデバイス、およびモバイルセッションにアクセスできるユーザーの種類を検討します。セキュリティ人格ドキュメントにモバイルアクセス標準を含めます。このトピックについての詳細は、「セッション管理」を参照してください。
• **モバイルデバイス管理 (MDM) テクノロジーを使用して、デバイスレベルのセキュリティを補完します。**iOS および Android 用の Salesforce アプリケーションは、多くの一般的な MDM スイートと互換性があります。任意の MDM ソリューションを使用して、ユーザーデバイスの Salesforce アプリケーションの追加のアクセス制御を設定できます。
• **モバイルアプリケーション管理 (MAM) テクノロジを使用してアプリケーションレベルのセキュリティを補完します。**MAM テクノロジーは、モバイルデバイスでのアプリケーションレベルの制御をサポートします。Salesforce では、Salesforce モバイルアプリケーション用の有料MAM アドオンを提供しています。

次のパターンとアンチパターンのリストは、Salesforce 組織での適切な (および不適切な) デバイス管理を示しています。これらを使用して、構築前に設計を検証したり、さらなる改善の機会を特定したりできます。

Salesforce から入手できるデバイス管理ツールについての詳細は、「Tools Relevant to Secure (セキュリティに関連するツール)」を参照してください。

脅威検知は、悪意のある活動を示している可能性があるシステム内の行動パターンを特定するプロセスです。これには、ダウンロードされるデータ量が平均を超えている場合や、ユーザーが平均よりも短い期間内に複数のレコードの機密データを含む項目を変更した場合などがあります。脅威への対応には、自動セッションの有効期限、アラート、その他の通知を含めることができます。

脅威検知の目標は、潜在的な問題をできるだけ早く特定して対応することです。リアルタイムの脅威検知に基づいてアクションを実行することで、悪意のある行動を追跡から阻止できます。Salesforce は、アドオンまたは Salesforce Shield の一部としてリアルタイムイベント監視を提供します。機密性の高いアプリケーションがある場合や、堅牢なリアルタイムの脅威検知および対応機能が必要な場合、次のいずれかのソリューションを使用します。

Salesforce ソリューションの効果的な脅威検知および対応戦略を構築する

• 組み込み監査機能。Salesforce には、組織への変更を追跡および監査するのに役立つさまざまな組み込みツールが用意されています。たとえば、監査履歴設定では、管理アクションの監査履歴を表示できます。Salesforce では、デフォルトで項目レベルの変更が一定期間追跡されますが、項目履歴管理を有効化して、項目の変更を UI で最大 18 か月間、API で最大 24 か月間表示できます。また、項目監査履歴を有効化して、項目レベルの変更に関する監査履歴を無期限に保持できます (データを手動で削除するまで)。
• 定期的な監査レビュー。リアルタイムの脅威検知で見逃される可能性のある異常な変更を特定するには、監査が不可欠です。正当なアクセス権を持つユーザーが長期にわたって毎日少数のレコードを一貫して削除するシナリオを考えてみます。このユーザーは、有効なログイン情報を持ち、レコードを削除する適切な権限を持っており、大量のレコードを一度に削除していないため、活動がリアルタイムの脅威として検出される可能性はほとんどありません。ただし、ユーザー活動レポートを確認する監査チームは、1 人のユーザーが経時的に過剰にレコードを削除しているこの傾向を明確に特定できるため、簡単に対処できます。ガバナンス ポリシーの一環として、ログイン履歴、ユーザー セッション アクティビティ、接続アプリケーションの使用状況を監査する定期的な間隔を設定します。
• **脅威対応戦略を作成し、セキュリティポリシーに含めます。**次の内容をカバーする脅威対応戦略を作成します。
  • 脅威対応種別定義(アラートや自動化など)と関連する関係者グループ。メッセージまたはアラートの設計についての詳細は、「エラーと通知」を参照してください。
  • 脅威とみなされる可能性があるリアルタイムの変更または活動の特定のカテゴリと、各カテゴリに関連付けられた対応種別
  • すべての自動脅威対応 (トークンの取り消し、セッションの終了、ユーザーアカウントの無効化、リソースへのアクセスのブロックなど) と自動化トリガーの明確なリスト

イベント監視では、リアルタイムの脅威の検出と対応を有効にすることで、この原則を適用するために必要なデータが提供されます。トランザクションセキュリティでは、会社のポリシーベースのアクションが適用され、イベント種別では、経時的なユーザーおよびアプリケーションアクセスの監視がサポートされます。

Salesforce のネイティブ脅威検知サービスは、統計モデルと機械学習モデルを使用して疑わしい行動を識別します。このサービスは、サイバー攻撃や疑わしいデータアクセスから保護する特定のイベントを生成します。

トランザクションセキュリティでは、組織で発生する主要なイベントを捕捉し、会社のポリシーベースのアクションを適用するフレームワークが提供されるため、セキュリティがさらに強化されます。これにより、イベント監視がロギングツールから自動セキュリティ防御の重要なコンポーネントに変わります。

以下のパターンとアンチパターンのリストは、Salesforce 組織での適切な (および不適切な) 脅威の検出と対応を示しています。これらを使用して、構築前に設計を検証したり、さらなる改善の機会を特定したりできます。

Salesforce から入手できる脅威の検出、アラート、対応の自動化ツールについての詳細は、「Tools Relevant to Secure」を参照してください。

次の表に、組織で検索 (または作成) するパターンと、回避または修正の対象となるアンチパターンの選択を示します。

✨ パターン & アンチパターンエクスプローラーで、セッションセキュリティのその他のパターンを検出します。

データセキュリティとは、不正アクセス、破損、意図しない削除からデータを保護する手段です。データセキュリティには、転送中および保存中のデータの保護が含まれます。

強力なデータセキュリティにより、システムへの不正アクセスによるリスクと潜在的な損害を最小限に抑えます。データセキュリティが不十分な場合、システムはデータ侵害に対して脆弱になり、顧客や会社に重大な影響を及ぼす可能性があります。したがって、データの保護は、安全なアーキテクチャを構築するための基本です。

データセキュリティを強化するには、まず Salesforce 内で何がデータとみなされるか、およびその分類を明確に理解します。Salesforce 組織内に保存されている個々のレコード、ファイル、ドキュメントは、そのデータです。メタデータとデータの違いについての詳細は、「Salesforce アーキテクチャの基本」を参照してください。

暗号化の使用だけでなく、共有と表示に重点を置くことで、Salesforce ソリューションでより強力なデータセキュリティを構築できます。

注意:データ セキュリティを設計するときは、データ プライバシーとアーカイブおよびパージを考慮してください。これらの概念はどちらもソリューション全体のデータ セキュリティに影響します。

機密性 (公開、内部、機密、制限付きなど) に基づいて、Salesforce Platform 内に保存されているすべてのデータを識別および分類します。各データ型の処理方法と保護方法の概要を示す明確なデータ分類ポリシーを定義します。項目レベルセキュリティ、暗号化、データマスキングなどの適切なセキュリティ制御を実装して、ポリシーを適用し、機密データを不正アクセスや漏洩から保護します。これらの分類と統制がビジネスおよびコンプライアンス要件と一致していることを確認するために、定期的に確認および監査します。

共有と表示には、Salesforce 内のデータへのユーザーアクセスを制御するシステムの設定が含まれます。共有と表示によってユーザーがアクセスできる個々のレコードが制御されますが、これらの設定だけでは、特定のレコードでユーザーが実行できる操作や、そのレコード内のどの特定の項目が表示されるかは最終的に制御されません。データ操作を実行する権限 (CRUD など) は、メタデータアクセス制御を介してユーザーに割り当てられます。メタデータアクセス制御は、個々のオブジェクトおよびフィールドレベルでユーザーに設定できます。詳細は、「承認」を参照してください。

Agentforce アクションでは、通常は直接アクセスできない認証済みユーザーと匿名ユーザーの両方にデータを公開できます。Agentforce エージェントを作成するときは、エージェントに割り当てられたすべてのアクションを慎重に検討して文書化してください。アクションごとに、次のことを理解する必要があります。

• アクションでアクセスできるデータ。
• アクションが実行されるセキュリティコンテキスト。
• アクションに、エージェントセッションに機密データや制限されたデータを組み込むことができる Knowledge 取得機能やその他の機能があるかどうか。

Salesforce で効果的な共有と表示を設定する

• 有意義な職務に関する設計アクセス。ユーザー人格を実行するビジネス機能に対応付けるセキュリティマトリックスを作成します。このテンプレートを基盤として使用して、共有と表示を設計します。有意義なビジネス機能の特定についての詳細は、「機能単位」を参照してください。
• **最小権限の原則を適用する最もシンプルなパスを選択します。**共有および表示スキームの設計に最小権限の原則を適用する場合は、最もわかりやすい方法で実行します。過剰なデータ制限と共有スキームは、システムのメンテナンス性、拡張性、適応性に関するダウンストリームの問題を引き起こす可能性があります。代わりに、Salesforce の柔軟な階層化されたデータ共有を利用して、データレベルでユーザーアクセスの詳細なルールを設定します。
• **ビジネスで機密データを扱う場合を除き、内部組織の共有設定 (OWD) を [公開/参照のみ] に設定し、[非公開] を使用します。**OWD は、データレベルでユーザーに付与する「最小」権限のレベルを制御します。OWD のレベルより下のアクセスを制限することはできません。非公開 OWD は、すべての使用事例で理想的に見えますが、多くの場合、企業全体のユーザーは、複雑な共有スキームを介して、より権限の高い OWD を誤って複製してしまう可能性があります。また、非公開 OWD を使用すると、ユーザーが重複データを作成する可能性があります。データ量と親子または所有権の歪みによっては、共有の適用 (および再適用) が完了するまでに非常に時間がかかる場合があります。非公開の OWD では、これがさらに悪化します。OWD は CRUD 権限と項目レベルの表示を制御しないことに注意してください。OWD がビジネスニーズによって正当化される場合にのみ [非公開] を選択します。多くの場合、そのような正当化はコンプライアンスに関連します。
• より大きなアクセスを許可するやむを得ないビジネス上の理由がない限り、外部組織の共有設定 (OWD) を [非公開] に設定します。外部 OWD は、Experience Cloud サイトやポータルなどから Salesforce データにアクセスするユーザーに適用されます。これにより、内部ユーザーと外部ユーザーに別々の OWD ベースラインを設定し、さまざまな種別の「最小」権限を許可できます。外部ユーザーの OWD は常に [非公開] に設定します。よりオープンなレベルの例外は、ビジネスニーズによって明確に正当化する必要があります。

次のパターンとアンチパターンのリストは、Salesforce 組織での共有と表示が適切 (および不適切) であることを示しています。これらを使用して、構築前に設計を検証したり、さらなる改善の機会を特定したりできます。

Salesforce の共有および表示ツールについての詳細は、「Tools Relevant to Secure (セキュリティに関連するツール)」を参照してください。

暗号化は、読み取り可能なデータを解読不可能なエンコード形式に変換します。暗号化されたデータは、鍵を使用して復号化したり、元の形式に変換したりできます。そのため、暗号化は、保存中および転送中のデータを保護するための最も効果的な方法の 1 つであり、権限のないユーザーがデータにアクセスした場合でもデータを読み取ることができません。

Salesforce ソリューションで暗号化を適切に使用するように設計する

• **転送中のデータは常に適切に暗号化してください。**Salesforce では、Salesforce サポートブラウザで実行されるすべてのセッションに TLS を採用し、HTTPS を使用した発信通話が特定のセキュリティ標準を満たしていることを要求します。プラットフォーム API でもデフォルトで HTTPS が使用されます。また、Salesforce Experience Cloud サイトまたはポータルとその関連 Salesforce 組織間で送信されるデータは、デフォルトで転送中に暗号化されます。Salesforce の組み込みメールサービスを使用する場合、Salesforce がメールの送信および送信試行に使用するトランスポート層セキュリティ (TLS) にはデフォルトレベルがあります。明確なビジネス上の理由がない限り、少なくとも組織の設定がデフォルト設定より低くならないようにする必要があります。データの分類と機密性に基づいて、AWS Direct Connect または Salesforce Private Connect を介して Salesforce へのプライベートネットワーク接続を活用することを検討してください。これにより、データが公開インターネットを通過するのではなく、ユーザーアクセスとインテグレーションの両方でプライベートネットワーク接続を介して安全に転送されます。
• **ビジネスで必要な場合は、保存データを暗号化します。**Salesforce では、保存データを暗号化する方法がいくつか用意されています。
  • HyperforceHyperforceを使用する組織では、データは保存時に暗号化されます。暗号化は、Salesforce によって組織で管理されます。独自の暗号化鍵を作成 (または破棄) することはできません。
  • Salesforce Shield。Salesforce Shieldでは、Salesforce 組織の保存データを、アプリケーション レイヤーやデータベース レイヤーなどの追加レイヤーで暗号化できます。Shield では、堅牢な [Bring Your Own Key (BYOK)] オプションを含め、テナントの暗号化鍵の完全な管理機能を使用できます。非構造化データ (ファイル、添付ファイル、検索インデックス、行動など) を暗号化することもできます。Hyperforce ベースのインスタンスでは、外部鍵マネージャーを使用するオプションが用意されているため、独自の AWS KMS を使用できます。この機能を使用すると、Salesforce に保存されているデータの暗号化と復号化に使用される暗号化鍵を KMS 内で完全に制御できるため、セキュリティが強化され、組織のコンプライアンス要件に対応できます。

以下のパターンとアンチパターンのリストは、Salesforce 組織での暗号化の適切な (および不適切な) 使用を示しています。これらを使用して、構築前に設計を検証したり、さらなる改善の機会を特定したりできます。

Salesforce から入手できる暗号化ツールについての詳細は、「Tools Relevant to Secure (セキュリティに関連するツール)」を参照してください。

次の表に、組織で検索 (または作成) するパターンと、回避または修正の対象となるアンチパターンの選択を示します。

✨ パターン & アンチパターンエクスプローラーで、データセキュリティに関するより多くのパターンを見つけます。

Salesforce Well-Architected の関連性の維持にご協力ください。このコンテンツに関するフィードバックをいただくためのアンケートにご協力ください。また、今後の展望についてもお聞かせください。