#### Salesforce: クラウドのセキュリティ
Salesforce は、Data 360 プラットフォームとそのグローバルインフラストラクチャの整合性を確保し、維持する責任があります。具体的な動作は次のとおりです。
* **物理的および環境**的なセキュリティ:HyperforceはAWSインフラストラクチャでホストされ、Amazonはアクセス制御、監視、環境保護を通じてグローバル データセンターの保護を委任された責任で担当します。
* **ネットワークおよび境界**防御: 転送中および保存中のすべてのトラフィック(TLS 1.2以上)に対する分散型サービス拒否(DDoS)の軽減、侵入検知、暗号化(AES-256)。
* **プラットフォーム強化およびパッチ管理:** 継続的な脆弱性管理、パッチ導入、OSレベルセキュリティのベースライン化。
* **コンプライアンスと認定:** SOC 1/2/3、ISO 27001、ISO 27017、ISO 27018 などの標準、および GDPR などのフレームワークの準備状況に対する継続的な監査。
これらの制御により、Data 360 プラットフォームの安全性、信頼性、コンプライアンスが維持されるため、顧客はインフラストラクチャの防御ではなくビジネスロジックとデータ管理に集中できます。
#### 顧客: クラウドのセキュリティ
お客様は、Salesforce Data 360 組織内のデータ、設定、および運用プロセスを保護する責任があります。アカウンタビリティの主要な領域は次のとおりです:
* **IDおよびアクセス管理(IAM):** ロールを定義し、多要素認証(MFA)とシングルサインオン(SSO)を適用し、最小権限の原則を適用します。
* **データガバナンス:** 機密データを分類し、必要に応じてマスキングを適用し、オブジェクトレベル、項目レベル、およびレコードレベルのアクセス制御を適用します。
* **インテグレーションセキュリティ:** 指定ログイン情報と外部ログイン情報を使用して、OAuth 2.0、JSON Web トークン JWT、およびその他の認証標準を介した API アクセスを管理します。
* **監視と対応:** イベントの監視と監査履歴を使用して、ログをセキュリティ情報およびイベント管理 (SIEM) システムに転送し、高度な脅威検出を行います。
Salesforce は安全な基盤を提供しますが、お客様は設定、制御、警戒を通じて実際のセキュリティ体制を決定します。
#### 人間中心の責任
セキュリティは単なる技術的な構造ではなく、組織の規律です。Salesforce Data 360 のデータ保護は、アーキテクチャチーム、運用チーム、ガバナンスチーム間のコラボレーションによって実現されます。
**企業は次のことを行う必要があります。**
* 使用されていないアカウントや権限が過剰なアカウントを継続的にレビューして廃止します。
* ポリシーをコードおよび CI/CD パイプラインとして使用して適用を自動化します。
* 不正なデータの有効化や持ち出しなどのインシデントをシミュレーションする机上演習を実施し、対応準備を強化します。
Data 360 の有効性は、機能だけでなく、顧客がどれだけ責任を持って運用するかによって規模が拡大します。
#### セキュアバイデフォルト：プロアクティブなセキュリティに対する姿勢
Salesforce Data 360 では、事後対応型の制御から予防設計への移行という、デフォルトでセキュアな考え方を採用しています。後でオープンにして厳格化する代わりに、すべての新しい Data 360 組織は「すべて拒否」状態で開始され、最初の展開からゼロトラストの原則が強制されます。
#### 事後対応型制御から予防的な設計へ
以前の環境では、オンボーディングを迅速化するために、顧客は "Allow All" モデルを引き継いでいました。これは便利な反面、偶発的な露出過剰や設定ミスによるリスクを生み出していました。
新しいセキュアバイデフォルトのアーキテクチャでは、このアプローチを逆転させます。
* 暗黙的なアクセス権を持つユーザーまたはシステムはありません。
* すべての権限が明示的に付与されている必要があります。
* データアクセス、インテグレーション、およびガバナンスコントロールは 0 日目から適用されます。
これにより、意図的に最小限の権限が適用されるため、誤って情報が漏洩したり、権限がエスカレーションされたりするリスクが大幅に軽減されます。
#### 運用面およびガバナンス面への影響
このモデルには、技術面および行動面の両方に影響があります。
* チームはアクセスモデルを意図的に計画し、権限をコンプライアンスとビジネスの境界に合わせる必要があります。
* ガバナンスは、後付けではなく組み込みの設計要件になります。
* データの所有権と説明責任は最初から定義されます。
従来の Data 360 組織が引き続き \[すべて許可] で運用されている場合、システム管理者はセキュリティのモダナイズや Data 360 成熟度プログラムの重要なステップである新しいベースラインに合わせて手動で設定を厳格化する必要があります。
#### Trust by Design (設計による信頼)
デフォルトでアクセスをゼロにし、明示的なポリシー定義を要求することで、Salesforce Data 360 は企業データセキュリティにおける基礎的な進化である Trust by Design を確立します。
このアプローチにより、次のことが保証されます。
* 不正アクセスやデータ漏洩のリスクを最小限に抑えます。
* ガバナンスフレームワークは、任意ではなく構造的に強制されます。
* 企業は、さまざまな環境でより予測可能、監査可能、かつ復元性の高いセキュリティ体制を実現できます。
本質的に、セキュリティはもはや自分で追加する機能ではなく、最初に導入する基盤です。
## ID およびアクセス管理: データへのゲートウェイ
**Salesforce Data 360**のIAM(Identity and Access Management)は、防御の最初で最も重要なレイヤーです。プラットフォームにアクセスできる**ユーザー**と、プラットフォーム内で 1 回実行できるアクション**を**制御します。適切に実装された IAM フレームワークは、企業が顧客データを保護し、業務の整合性を確保するために必要とする唯一の強力な制御です。
### 認証: 「自分らしさ」の検証
認証により**、Digital Trust**が確立され、Salesforce Data 360にアクセスするすべてのユーザー、サービス、外部システムが正当なものであるかどうかが確認されます。
### 統合 ID 管理
Data 360 では、[**Microsoft Entra ID (Azure AD)**](https://learn.microsoft.com/en-us/entra/identity/saas-apps/salesforce-tutorial)、[**Okta**](https://help.okta.com/en-us/content/topics/provisioning/salesforce/sfdc-provision.htm)、[**Ping Identity**](https://docs.pingidentity.com/configuration_guides/salesforce/config_saml_salesforce_pf.html) などのエンタープライズグレードのIDプロバイダ（IdP）と、[**SAML 2.0**](https://help.salesforce.com/s/articleView?id=xcloud.sso_saml.htm&type=5)、OpenID Connect（[**OIDC**](https://help.salesforce.com/s/articleView?id=xcloud.sso_provider_openid_connect.htm&type=5)）、またはSystem for Cross-domain Identity Management（[**SCIM**](https://help.salesforce.com/s/articleView?id=xcloud.identity_scim_overview.htm&type=5)）を利用した**フェデレーテッド認証**をサポートしています。
この統合により、企業 ID ライフサイクルが Salesforce に直接拡張されます。従業員が入社、異動、退職すると、アクセス権が自動的に調整され、孤立した取引先が減り、コンプライアンスの準備が向上します。
### シングルサインオン (SSO)
[**シングルサインオン(SSO)**](https://help.salesforce.com/s/articleView?id=xcloud.sso_about.htm&type=5)を使用すると、ユーザーは会社のログイン情報を使用して一度認証すると、個別のパスワードなしでSalesforceアプリケーションへの安全なアクセスが可能になります。これにより、ログイン情報の疲労が軽減され、パスワードの再利用やフィッシングによるリスクが最小限に抑えられます。
### 適応型および条件付きアクセス
ID プロバイダー (IdP) は、多要素認証 (MFA)、条件付きアクセス、リスクベースの制御を適用して、認証に関する意思決定を行う唯一の機関となります。認証は、一度のイベントから、ユーザーの行動やコンテキストに応じた継続的な信頼評価へと進化します。
統合認証には次の機能があります。
* 一元的な**ポリシー適用:** 認証標準は、すべてのSalesforce環境で1か所で管理されます。
* **エンド ツー エンドのトレーサビリティ:**統合された監査履歴により、すべてのアクションが検証済みのIDにリンクされます。
* **人間中心環境:**円滑で安全なログイン プロセスにより、チームは認証情報ではなくインサイトに集中できます。
### 認証: 「What You Can Do (できること)」の定義
ユーザーが検証されると、認証によってユーザーがアクセス、表示、または変更できる内容を定義します。機密データを保護し、最小限の権限を適用する運用境界を設定します。
**Principle of Least Privilege (PoLP):** すべてのユーザーとシステムには、職務に必要な権限のみが付与されます。それ以上の権限は付与されません。この原則により、侵害されたログイン情報や設定ミスによる潜在的な損害が大幅に制限されます。
**ロールベースアクセス制御(RBAC):** Salesforce Data 360は、権限セットと権限セットグループを使用して、ビジネスロールに応じたきめ細かな機能を割り当てます。次に例を示します。
* データエンジニアは、「Data 360 Architect」権限セットを使用して取り込みパイプラインと変換を管理できます。
* マーケティングアナリストはハーモナイズデータを照会できますが、「Data 360 有効化マネージャー」権限セットを使用してモデルを変更することはできません。
* アクティベーションマネージャーは送信キャンペーンを実行できますが、Data 360 アクティベーションマネージャー権限セットを使用してソースデータにアクセスすることはできません。
アクセス権は一元管理され、監査可能であるため、データライフサイクル全体で説明責任を果たすことができます。Entra ID、Okta、Ping Identity などの IdP と統合すると、アクセスポリシーは SCIM プロビジョニングと SAML/SSO 統合を介してシームレスに企業全体に拡張されます。
### Data 360 の標準ロールと権限について
Salesforce には、職務の分離と ISO 27001 などの業界標準への準拠のためのベストプラクティスをカプセル化した定義済みの権限セットが用意されています。
| ロール | 主な責任 | アクセス設計原則 |
|---|---|---|
| システム管理者 | 環境の設定、プロビジョニング、設定 | 基盤となるデータセットへのアクセスなし — システムとデータ支配の分離を確保 |
| Data 360 Architect | データの取り込み、変換、ID 解決、モデリング | データ公開境界を維持するためにデータの有効化を実行できない |
| Data 360 Activation Manager | セグメントの作成、チャネル管理、有効化 | データモデルへの参照のみアクセス権。変更権限なし |
| Data 360 ユーザー | 分析とインサイトを利用する | 参照のみ、変更権限なし |
| Data 360 One ユーザー | コンパニオン組織を介した組織間アクセス | 共有スペース権限と範囲設定済みアクセスポリシーにより管理 |
### コントロールプレーンとしてのガバナンス
Data 360 は、ガバナンスファーストモデルに基づいて設計されており、取り込みからインサイトの有効化まで、すべてのデータインタラクションがポリシー対応で監査可能、かつコンプライアンスを確保します。ガバナンスは中央コントロールプレーンとして機能し、ライフサイクル全体でデータを検出、分類、保護する方法を管理します。
この統合コントロールプレーンにより、次のことが可能になります。
* **データ アクセスはコンテキスト**に応じて許可されます。適切なポリシーに基づいて適切なユーザーのみが適切なデータに対してアクションを実行できます。
* **ガバナンスはセマンティック レイヤー**と運用レイヤーの両方に組み込まれ、データのモデル化方法と保護方法の一貫性が確保されます。
* ** Zero Trust と Least Privilege** の原則が適用されます。つまり、ID、コンテキスト、ポリシーは、アクセス権を付与する前にリアルタイムで評価されます。
このアーキテクチャにより、Salesforce Data 360 はガバナンスを静的な権限管理から動的なポリシー主導のオーケストレーションレイヤーに変換します。コンテキストに継続的に適応し、設計によってコンプライアンスを適用し、企業規模で信頼を維持するものです。
### データスペースを使用した論理データの分離
マクロレベルでは、データスペースによってエンタープライズデータドメインが論理的に分離され、マルチブランド、マルチリージョン、またはマルチテナントの運用モデルを持つ組織は、1 つの統合プラットフォーム内でデータを管理できます。データスペースは、ビジネスドメイン (セールス、マーケティング、カスタマーサクセスなど) または規制や地理的境界 (EU、AMER、APAC など) に合わせることができるため、基盤となるデータプラットフォームを断片化することなく、ガバナンスとアクセス制御で組織の業務とコンプライアンスの構造を反映できます。
* 各データスペースは仮想境界として機能し、ユーザーまたはチームが参照または操作できるデータ収集を定義します。
* データスペース内のアクセス権は明示的に付与され、暗黙的な権限やデータ表示の交差汚染がなくなります。
* これにより、所有権の統合が可能になります。各ビジネスユニットは、一元的な監視とコンプライアンスを維持しながら、ドメインを個別に管理できます。
設計上、データスペースはガバナンスの第1層を提供し、企業データセット全体の構造的な明確さとアカウンタビリティを確立します。
### RBAC から ABAC へ: コンテキスト認証への移行
Salesforce Data 360 では、RBAC と ABAC は異なる補完的な役割を果たし、プラットフォームの異なるレイヤーで適用されます。
RBAC は主にプラットフォームと機能へのアクセスに使用されます。データスペース、プロセス作成、管理機能、ツールアクセスなど、Data 360 の構造と機能にアクセスできるユーザーを管理します。RBAC は、権限と権限セットを使用して実装されます。たとえば、特定の有効な機能を使用してデータスペースへのユーザーアクセス権を割り当てます。
ABAC はデータアクセスの適用に使用されます。ABAC ポリシーは、オブジェクトレベルセキュリティ (OLS)、項目レベルアクセス、行レベル制約など、誰がどのデータオブジェクトおよび属性にアクセスできるかを決定する責任をすべて負っています。これらの決定は、実行時にアクション、ユーザー属性、リソース属性を評価することで動的に行われます。
ABAC では、権限はモデルの一部のままですが、アクセス権はロールのみではなくポリシー自体によって決定されます。ポリシーでは、ビジネスユニット、地域、データの機密性、使用目的、アクセスを許可または拒否する規制の制約などのコンテキストを評価します。
次に例を示します。
* RBAC を使用すると、ユーザーは Data 360 データスペースと分析機能にアクセスできます。
* ABAC は、同じユーザーが特定の顧客データセットを参照できるかどうか、表示できる行、マスキングまたは制限される属性を決定します。
この明確な分離により、Data 360 は安全にスケールできます。
* RBAC は、プラットフォームの機能とワークフローへのアクセスを制御します。
* ABACは、コンプライアンス、レジデンシー、データ保護の要件に合わせて、きめ細かなポリシー・ベースのデータ・アクセスを実現します。
これらを組み合わせることで、プラットフォーム権限とデータ認証ロジックを混同することなく、管理されたデータの民主化が可能になります。
基本的に、RBAC は権限の割り当てに基づいてアクセス権を適用し、ABAC はコンテキストに基づいて権限を評価します。つまり、アクション、ユーザー、リソース属性を組み合わせて、Salesforce Data 360 全体で適応性のあるきめ細かなアクセス制御を実現します。
### ABAC: 多層セキュリティ階層
Salesforce Data 360 のきめ細かなアクセス制御の中心となるのは、属性ベースのアクセス制御 (CEDAR ポリシー言語に基づく ABAC) です。
静的なロール ベースの権限とは異なり、ABACはアクセスを要求している*ユーザー*、アクセスしようとしている*内容*、*条件*を動的に評価し、すべてのデータのやり取りがエンタープライズ ポリシーとTrust Boundaryに準拠するようにします。
#### 動的ポリシー評価
Data 360 の ABAC エンジンは、次の 3 つのコア属性種別の組み合わせに基づいてアクセスの決定を評価します。
* **ユーザー属性:** 部門、場所、クリアランスレベル
* **データ属性:** 分類、機密性 (PII、PHI、財務データ)、データスペース
この柔軟でポリシー主導のモデルにより、ユーザーロール、データ分類、または運用条件の変化に応じて適用を自動的に適応させることができます。これは、大規模で分散した規制対象の企業にとって不可欠です。
#### Salesforce Data 360 の ABAC アーキテクチャコンポーネント
Salesforce Data 360 は、ポリシー主導のデータガバナンスの業界のベストプラクティスに準拠した標準ベースの属性ベースのアクセス制御 (ABAC) アーキテクチャを実装しています。次の 3 つの主な機能コンポーネントで構成されます。
* **PIP(ポリシー情報ポイント) - ポリシー、強化されたメタデータ、分類:**
* エンタープライズデータを管理するデータアクセス、分類、マスキング、保持、使用ポリシーなど、ポリシー定義自体を格納します。
* タグ、分類、ビジネスコンテキスト、エンドツーエンドの系統など、強化されたメタデータを維持します。
* LLM および ML 駆動の分類を使用して、機密データ (PII.Email、PII.Phone、PHI など) を自動的にタグ付けします。
* タグの伝搬により、データ系統 (DLO → DLO → DMO) に沿って分類が自動的に流れます。
* 変換全体で機密性とコンプライアンスを維持します。
* **Policy Decision Point（PDP）**：PDP は、CEDAR ポリシーを解釈する決定エンジンです。
* PEP (ユーザー ID、要求メタデータ) からのコンテキスト入力と PIP からの参照属性を取り込みます。
* ポリシーを確定的に評価して、一貫性があり、説明可能で、拡張可能なアクセス決定を行います。
* リアルタイム評価と一括評価の両方がサポートされ、大規模環境でもパフォーマンスと精度が確保されます。
* **ポリシー適用ポイント (PEP)**: PEP は、実行時に承認の決定が適用される場所です。
* API、UI クエリ、CRM 強化、GenAI 取得拡張生成 (RAG) パイプラインなど、すべてのインタラクションチャネルでデータアクセス要求を代行受信します。
* PDP の結果をすぐに適用し、すべてのクエリと取得がエンタープライズアクセスポリシーに準拠するようにします。
PIP、PDP、PEP の3要素によって分散ガバナンスファブリックが形成され、すべての Data 360 本サービスおよびアクセスモードにおいて、一貫したポリシーベースの制御が実現されます。
重要なのは、Data 360 の [ABAC](https://help.salesforce.com/s/articleView?id=data.c360_a_policy_based_governance_dg.htm&type=5) が設定されており、構築されていないことです。アーキテクトは、カスタムコントロールプレーンや適用ロジックを組み立てません。代わりに、統合ガバナンスファブリックとして連携して動作する 3 つのネイティブアーキテクチャコンポーネントを入力して接続します。
実装は、データを分類し、ポリシーを定義して、プラットフォームで自動的に適用するという単純な手順に従います。一度設定すると、アクセス制御は手動プロセスや手順プロセスではなくシステムの動作になります。
この分散ガバナンスファブリックにより、すべてのチャネルで**一貫したポリシー強制**が実現され、Data 360 全体で統合された Trust 境界が形成されます。
#### 複数レベルのポリシー適用
Data 360 の ABAC フレームワークでは、階層化されたアクセス境界がサポートされているため、オブジェクトレベルだけでなく、特定の項目やレコード内でもデータが保護されます。
* **オブジェクトレベルセキュリティ (OLS)**: アクセス制御の最も外側の境界。
データレークオブジェクト (DLO) やデータモデルオブジェクト (DMO) などのデータ構造全体へのアクセスを管理します。
例: *顧客*オブジェクトへのアクセス権の付与を行うが、*トランザクション*へのアクセス権は付与しない。
* **項目レベルセキュリティ (FLS)**: オブジェクト内の特定の項目へのアクセスを制御します。
例: マーケティングユーザーは顧客名を表示できますが、クレジットカード番号や国民 ID の表示は制限されます。
* **レコードレベルセキュリティ (RLS)**: 最も詳細な制御レイヤー。
ユーザーが表示または変更できるデータセット内の個々のレコードを決定します。
例: 地域マネージャーは、割り当てられた地域に関連付けられた顧客データにのみアクセスできます。
* **動的データマスキング (DDM):** リアルタイムのデータ保護を有効にします。ABAC を補完する DDM は、基盤となるデータセットを変更することなく、機密情報をポリシーに基づいて難読化します。クエリ時に、DDM はユーザーロール、コンテキスト、またはコンプライアンスルールに基づいて PII などの項目や財務データを自動的にマスキングします。
* 機密データは、UI ビュー、API、AI ワークフロー全体で保護されます。
* すべての消費レイヤーで一貫したマスキングを確保することで、データ漏洩のリスクを軽減します。
* 監査可能性を維持します。マスクされたすべてのクエリは、Data 360 のガバナンスフレームワーク内で記録され、追跡できます。
このアーキテクチャにより、アクセス制御が静的権限モデルから動的なコンテキスト対応ポリシーファブリックに変換されます。RBAC の構造的なシンプルさと ABAC のコンテキストの深さを組み合わせることで、Salesforce Data 360 は次のことを実現します。
* 取り込み、ハーモナイゼーション、及び有効化にわたって一貫したポリシーを適用します。
* データ、役割、コンプライアンスのニーズに応じて進化する適応型ガバナンス。
* 取り込みからAIの有効化まで、データライフサイクル全体にわたる統合された信頼境界。
#### Salesforce Platform との緊密な統合
Salesforce Data 360 のガバナンスモデルは Salesforce Platform 内にネイティブに組み込まれており、運用データと分析データの両方にわたって統合されたセキュリティ、コンプライアンス、およびアクセス制御を実現します。SalesforceのコアIDおよびアクセス管理機能(IDフェデレーション、権限セット、一元化されたポリシー作成、プラットフォーム暗号化など)を継承することで、Data 360は並列ガバナンス スタックを導入することなく、一貫したTrustポリシーをクラウド全体に適用します。プラットフォームでは、分離、承認、系統を個別の懸念事項として処理するのではなく、データライフサイクル全体にわたる単一の実行対応信頼ファブリックに統合します。
構造レベルでは、このガバナンスファブリックは、3つの補完層が連携して機能することで形成されます。
* **データスペース**: データの分離と規制区分のための明確な論理境界を確立
* **属性ベースアクセス制御 (ABAC)**。ID、目的、データ属性に基づいて、コンテキストに応じたきめ細かな承認判断が可能
* **セマンティックな系統**: データの取り込みからインサイトおよび有効化への移行時に、ビジネス上の意味、機密性、トレーサビリティを維持します。
これらを組み合わせることで、アクセスの決定が説明可能で、適用が自動的に行われ、コンプライアンスが遡及的ではなく継続的であるガバナンスモデルが作成されます。その結果、ガバナンスが制限要因や後付けではなくなるプラットフォームが実現します。代わりに、有効化レイヤーになり、アーキテクトは、Trust、プライバシー、規制の要件がシステム自体によって確実に適用されるようにデータ製品とAI主導のワークフローを設計できます。
この構成的アプローチにより、企業データは、使用可能であるだけでなく、責任を持って活用可能となり、透明性、セキュリティ、または支配が損なわれることなく、インサイト、有効化、およびオートメーションをスケールでサポートします。
## データライフサイクルの保護: 取り込みから有効化まで
AI 主導の企業の時代では、データの保護は 1 回限りのイベントではなく、情報がエコシステムに入った瞬間からビジネスや AI で使用するために有効化されるまで情報を保護する継続的なプロセスです。
Salesforce Data 360は、データライフサイクルのすべてのフェーズにセキュリティとガバナンスの支配を組み込み、取り込みからインサイトの有効化までデータの整合性、機密性、信頼が維持されるようにします。
### 保護の基盤: 保存中および転送中の暗号化
Salesforce Data 360 の保護モデルの中核となるのは、使いやすさや拡張性を損なうことなく、保存中および転送中のデータを保護できる透過的で高性能な暗号化フレームワークである Platform Encryption for Data 360 です。
#### 保存時の暗号化: ストレージレイヤーセキュリティ
Data 360データレークに保持されるデータは、**ストレージ階層で自動的に暗号化**されるため、物理的なアクセスや不正アクセスが発生しても、データを読み取ることはできません。主な機能は次のとおりです。
* **透過的なデータレーク暗号化:** データレークに保持されるすべてのデータは、顧客が管理するキー値（CMK）を使用してストレージ階層で暗号化されます。これにより、物理ストレージへの不正アクセスが発生しても、データは読み取り不能のままになります。
* **顧客が管理**する鍵(CMK): 金融サービス、医療、政府機関など、規制対象の業界にとって重要な機能である暗号化鍵を完全に制御できます。CMK は、GDPR、HIPAA、ISO 27001 などの規制要件に直接準拠し、詳細な監査、制御、データ主権の証明を可能にします。
* **外部鍵管理(EKM):**Data 360のプラットフォーム暗号化の機能である外部鍵管理では、顧客のAWS KMSアカウントに保存されている鍵を使用して、Data 360のデータを暗号化できます。これにより、Data 360 のデータをより安全に保護しながら、柔軟性を高めることができます。
* **Bring your own Key (BYOK):** CMKとECMを基盤とするData 360では、顧客が独自の鍵素材をSalesforce内に直接アップロードして、保存データと検索インデックスを暗号化できるようになりました。この機能強化により、顧客が AWS KMS でキーを作成または管理しなくても、PII、機密データ、専有データの保護が強化されます。
* **キーのローテーションとライフサイクル管理:** キーのローテーションは適切に処理されます。新しいデータは新しい鍵で暗号化され、古いデータは元の鍵で暗号化されたままであるため、ダウンタイムやパフォーマンスの低下を回避できます。この循環メカニズムにより、業務を中断することなくコンプライアンスを強化できます。
#### トランスポート中の暗号化: ネットワークレベルセキュリティ
Data 360 サービス、API、コネクタ間で転送されるすべてのデータは、トランスポート層セキュリティ (TLS) 1.2 以上を使用して保護され、移動中のエンドツーエンドの暗号化が提供されます。
これにより、次のことが保証されます。
* 転送中にデータを傍受または変更することはできません。
* Salesforce サービス、信頼済みコネクタ、および顧客エンドポイント間の通信は非公開で検証可能です。
* セキュリティは、取り込みパイプライン、ハーモナイゼーション プロセス、有効化ワークフロー、外部APIインテグレーションにわたって一貫して拡張されます。
Salesforce Data 360 は、顧客が管理する保存時の暗号化と転送中の継続的な暗号化を組み合わせることで、外部攻撃と内部インフラストラクチャの脅威の両方から顧客データを保護する多層防御アーキテクチャを構築します。
### Data 360 でのシステム間インテグレーション (データインテグレーション) の保護
暗号化とアクセス制御により Salesforce Data 360 内のデータは保護されますが、システム全体でのデータ移動の保護も同様に重要です。最新の企業は、Salesforce、分析プラットフォーム、外部 API、データレイク間で機密データが流れるマルチクラウドおよびハイブリッド環境で運用されています。
これに対応するために、Salesforceは、指定ログイン情報（NC）と外部認証情報（EC）を中心とした安全な統合フレームワークを設計し、安全な接続のためのポリシー駆動型、ゼロトラストに沿った基盤を提供しています。
#### Salesforce のセキュアなインテグレーションフレームワーク
Salesforceは、NC(指定ログイン情報)とEC(外部ログイン情報)を中心とした堅牢な**[安全な統合](https://developer.salesforce.com/docs/platform/named-credentials/guide/get-started.html)**フレームワークを構築しています。これらを組み合わせることで、コードや設定の秘密を公開することなく、ログイン情報の複雑さを抽象化し、最小限の権限でのアクセスを適用し、すべてのインテグレーションで一貫した認証管理が可能になります。
このフレームワークは、セキュリティの複雑さを抽象化し、ベスト プラクティスを適用して、Salesforceの**Zero Trust**と**設計別セキュリティ**の原則に準拠した、すべての外部接続のポリシー ベースの**コントロール プレーン**を確立します。
##### 指定ログイン情報
指定ログイン情報 (NC) は、Salesforce のセキュアなインテグレーション アーキテクチャの基盤です。外部エンドポイントとその認証パラメーターを定義する宣言型の一元的なメカニズムが提供されるため、Apexコードや構成ファイルでユーザー名、パスワード、トークンなどの機密性の高いログイン情報をハードコードする必要はありません。代わりに、開発者とシステム管理者は指定ログイン情報の別名 (SnowflakeConnector_NC など) を参照するだけで、Salesforce が自動的に基礎となる認証と接続管理を処理します。
**アーキテクチャとセキュリティのメリット:**
* **シンプルなメンテナンス:** NC は、外部エンドポイント URL と認証パラメータを 1 つの管理レコードに統合します。更新（エンドポイントの変更や認証情報のローテーションなど）では、NCレコードの変更のみが必要で、環境間でコードやフローを再リリースする必要はありません。
* **セキュリティの強化:** 認証情報は Salesforce の暗号化された秘密のストアに安全に保存されるため、コードリポジトリ、構成ファイル、ログでの漏洩を防止できます。認証プロセス自体は実行時に自動的に管理されるため、人為的ミスや漏洩のリスクが軽減されます。
**コンプライアンスの遵守:** ビジネスロジックからログイン情報を分離することで、**GDPR、HIPAA、PCI DSS**などのデータ保護規制へのコンプライアンスがシンプルになります。監査人は、外部データアクセスが企業のセキュリティおよびガバナンスポリシーに準拠していることを簡単に検証できます。
* **リモートサイト設定のバイパス:** NC を使用すると、リモートサイト設定に関する従来の要件が不要となり、特に大規模または複数の環境での企業向け実装において、設定と展開が合理化されます。
#### 外部ログイン情報
外部ログイン情報 (EC) は、Salesforce が外部サービスに接続するときに使用する認証プロトコルとフローを定義します。つまり、「認証方法」に効果的に回答します。1 つの EC を同じ認証種別を共有する複数の NC で再利用できるため、設定の再利用と一貫したセキュリティ適用を促進できます。
**サポートされる認証プロトコル:**
* OAuth 2.0 (すべてのバリエーションをサポート)
* JWT (JSON Web トークン)
* 基本認証
* AWS 署名 v4
* カスタム認証
* 認証なし (オープン API または公開エンドポイントの場合)
外部認証情報と指定ログイン情報は、明確な役割分担に基づいて設計されています。外部ログイン情報では、認証方法を定義します。つまり、外部システムに接続するための認証プロトコル、トークン種別、更新動作を指定します。一方、指定ログイン情報は、接続する場所 (エンドポイント URL とその接続で使用する外部ログイン情報) を定義します。この設計により、認証ロジックとエンドポイント設定が分離された状態が維持されるため、Salesforce はさまざまなインテグレーションプロトコルを安全にサポートしながら、企業全体で一貫した一元的なログイン情報管理を維持できます。
### How Data 360 Connectors Leverage This Framework → Data 360 コネクタでこのフレームワークを活用する方法
Data 360 のユーザーインターフェースは基礎となる設定の多くを抽象化しますが、指定ログイン情報と外部ログイン情報フレームワークは、内部的にはネイティブコネクタとデータストリームによって頻繁に使用されます。つまり、管理者がガイド付き UI を使用して単に「データ接続を追加」している場合でも、Data 360 はバックグラウンドでこの標準化されたセキュリティモデルを適用します。
アーキテクチャ上の影響:
* **統合セキュリティ モデル:**外部データベース、AWS S3、エンタープライズAPIのいずれのコネクタでも、指定ログイン情報と外部ログイン情報で適用されるのと同じ暗号化、認証、鍵管理標準を利用できます。
* **Developer Abstraction:** 開発者とシステム管理者は、認証フローやログイン情報の循環を手動で処理する必要はありません。Salesforce はトークンのライフサイクル、有効期限、更新を自動的に管理します。
* **一貫したポリシー適用:** このフレームワークにより、すべてのコネクタが一貫した認証、監査、およびログポリシーに準拠することができます。これは、規制対象の業界での大規模なマルチソース取り込みに不可欠です。
* **将来を見据えた拡張性:**Salesforceが認証スタックを強化すると(たとえば、新しいOAuthフローやFIDO2標準をサポートするため)、リファクタリングや再導入を行うことなく、これらの改善が自動的にすべてのコネクタに反映されます。
### Data 360 コネクタのセキュリティとガバナンス
Salesforce Data 360 には、さまざまなソースからのデータインテグレーションを合理化する、豊富な標準コネクタスイートが用意されています。これにより、企業はデータを効率的に統合して活用できるようになります。Salesforce には、ネイティブ Salesforce コネクタ、クラウドストレージコネクタ、データベースコネクタ、アプリケーションコネクタ、API コネクタなど、複数のコネクタ種別が用意されています。提供されるコネクタに加えて、ゼロ ETL ツールもサポートされています。Salesforce コネクタを使用すると、Sales Cloud、Service Cloud、Marketing Cloud などの Salesforce 製品と Data 360 をシームレスに統合できます。 さらに、Amazon S3、Google Cloud Storage、Azure Data Lake などのクラウドストレージプロバイダーへのさまざまなコネクタが提供されています。Snowflake、Redshift、BigQuery などのデータベース用の事前作成済みコネクタにより、企業は既存のデータウェアハウスを Data 360 にリンクできます。さらに、Data 360 には、Google 広告、Facebook 広告、その他のマーケティングプラットフォームなど、さまざまなサードパーティアプリケーションや API 用のコネクタが用意されています。柔軟性を高めるために、Data 360 は MuleSoft や Informatica などの ETL ツールと統合されています。
#### データセキュリティおよび Salesforce Data 360 コネクタ
Salesforce Data 360 内に保存されているデータのセキュリティは、Data 360 に関連する多くの会話で重視されています。多層防御セキュリティアプローチに対する Salesforce の取り組みの一環として、Data 360 環境にデータを取り込む方法の保護も同様に重要です。
Salesforce は、企業がさまざまなデータエコシステム (多くの場合、複数のクラウドプラットフォーム、ストレージソリューション、分析ツールにまたがる) で事業を展開していることを認識しています。Data 360 コネクタは、これらの環境間のブリッジとして機能します。このコネクタにより、Salesforce の高いセキュリティ標準を維持しながら、安全で拡張性が高く効率的なデータインテグレーションが可能になります。これらのコネクタにより、整合性やプライバシーを損なうことなくシームレスなデータフローを実現できます。
Data 360 コネクタセキュリティの 3 つの必須コンポーネントは次のとおりです。
* **認証/承認マッピング**: 安全なアクセス管理は、データセキュリティの基本です。さまざまなクラウドコネクタでは、さまざまな認証および承認メカニズムを使用して、ユーザーアクセスを検証および制御します。認証ではユーザーまたはシステムが正当なエンティティであることが確認され、承認では付与されるアクセスレベルが定義されます。Salesforce は、可能な限りコネクタが業界標準を活用するようにしています。
* **ゼロコピー(ZETL)機能**の相互運用性: データの複製には、セキュリティと運用上の課題があります。また、不要なストレージコスト、データの不整合、リスクの増大も伴います。Salesforce のゼロ抽出、変換、読み込み (ZETL) アプローチにより、物理的なデータレプリケーションを必要とせずに、プラットフォーム間でリアルタイムのデータ共有を実現できます。つまり、データは元の環境内に残したまま、処理、レポート、分析のために引き続きアクセスできます。さらに、これにより攻撃対象領域が大幅に減少し、データレジデンシー法への潜在的なコンプライアンスも強化されます。
* **データ統合サポート**: 今日のマルチクラウド環境では、不要なデータを移動することなく、包括的なデータアクセスが必要です。Data 360 コネクタ統合データモデルでは、ファイルベースとクエリベースの両方のデータ統合がサポートされているため、企業は外部データソースをリアルタイムで活用できます。Salesforce のコネクタは、構造化データベース、半構造化ログ、または非構造化ファイルへのアクセスのいずれであっても、ライフサイクル全体にわたってデータのセキュリティを確保します。
Salesforce は、インテグレーションを使用しても、データセキュリティとコンプライアンスの複雑さに対処するのに必要な透明性を顧客に提供することを目指しています。AWS S3、Google Cloud Storage、Snowflake、その他のプラットフォームと統合する場合でも、Data 360コネクタは重要なビジネス データに対するTrust、透明性、制御を確保するように設計されています。
##### Salesforce Data 360 コネクタのセキュリティと認証の対応付け
| コネクタ種別 | 接続種別のサポート | プライマリ認証種別 | 主要なセキュリティ面とメモ |
|---|---|---|---|
| Salesforce CRM | N/A (内部) | セッションベース (内部) | Salesforce の堅牢な内部 ID およびアクセス管理 (IAM) モデルを使用します。すべてのデータは、Salesforce インフラストラクチャ内で転送中および保存中に暗号化されます。 |
| Marketing Cloud Engagement | 公開インターネットのみ | OAuth 2.0、ユーザー名/パスワード | 安全な認証には、標準 OAuth 2.0 プロトコルが使用されます。データは、公開インターネットを介して転送中 (TLS) に暗号化されます。 |
| B2C Commerce | 公開インターネットのみ | OAuth 2.0 | 標準 OAuth 2.0。 データ転送にセキュアなパブリックインターネットプロトコル (TLS) を使用します。 |
| Web & モバイルアプリケーション | 公開インターネットのみ | API キー、OAuth 2.0 | API (取り込み API、ストリーミング API) を介して取り込まれるデータ。セキュリティは、API キー管理と標準 Web プロトコルによって管理されます。 |
| Amazon S3 | プライベートコネクト & 公開 | IAM ロール、外部認証情報 | AWS PrivateLink をサポートしてセキュアなプライベート接続を実現します。公開接続では、安全なログイン情報が使用されます。データは転送中および保存時に暗号化されます (S3 では顧客が管理するキーが省略可能)。 |
| Snowflake | プライベートコネクト & 公開 | OAuth 2.0、非公開鍵認証、ユーザー名/パスワード | VPC プライベート接続 (AWS PrivateLink) をサポートします。安全な認証方法でパブリック接続を使用できます。Snowflake 内で顧客鍵を使用してデータを暗号化できます。 |
| Amazon Redshift | プライベートコネクト & 公開 | ユーザー名/パスワード、IAM 認証 | プライベート接続 (AWS PrivateLink) をサポートします。パブリック接続では、標準のセキュリティのベストプラクティスが使用されます。 |
| Microsoft Azure (ストレージ/SQL) | 公開インターネットのみ | SAS トークン、OAuth 2.0、ユーザー名/パスワード | 接続では、認証にセキュアな SAS トークンまたは OAuth が使用されます。データは暗号化チャネル (TLS) を介してパブリックインターネットを経由します。 |
| Google Cloud Storage (GCS) | 公開インターネットのみ | OAuth 2.0、サービスアカウント | 接続は安全な OAuth 2.0 に依存します。 データは暗号化チャネル (TLS) を介して公衆インターネットを通過します。 |
| MuleSoft (API) | 公開インターネットのみ | OAuth 2.0、API キー | API を使用して接続します。セキュリティは、MuleSoft Anypoint Platform を介して実装された標準 API 認証と堅牢なガバナンスポリシーによって管理されます。 |
| フェーズ | メカニズム | セキュリティ/ガバナンス管理 |
|---|---|---|
| 有効化設定 | Data 360 有効化設定で定義 | 指定ログイン情報と外部認証情報による保護 |
| データの準備 | DMOから絞り込みおよび結合 | 同意およびプライバシーメタデータが適用されます |
| アウトバウンド転送 | TLS／プライベートコネクトで暗号化 | ポリシーの適用と認証情報の抽象化 |
| 外部配信 | SFTP / クラウドストレージ / API | アクセス制御および監査可能な配信 |
すべての通信は、プライベート IP アドレスとルーティング不可能なネットワークパスを使用して AWS バックボーン内に保持されるため、転送中のデータが傍受されるリスクがなくなり、厳しいエンタープライズおよび規制のセキュリティ要件を満たすことができます。
このアーキテクチャにより、次のことが保証されます。
* **インターネット漏洩ゼロ:** データが AWS プライベートネットワークから持ち出されることはありません。
* **プライベート IP 通信:**トラフィックは外部で分離され、アドレス指定不能のままです。
* **コンプライアンスの整合:** ISO 27001、SOC 2、FedRAMPなどのセキュリティ基準を満たしています。
#### プライベート相互接続: クラウド間のセキュリティの拡張
マルチクラウド環境で業務を行う顧客をサポートするために、Salesforce はプライベートインターコネクトを使用して同じセキュリティ原則を AWS 以外にも拡張しています。この機能により、Data 360 と Azure または Google Cloud でホストされているデータレイク間のクロスクラウドプライベート接続が可能になり、プライベートルーティング、インターネットトラバースゼロ、暗号化されたバックボーンのみのトラフィックが同じ保証で維持されます。
2 つのアーキテクチャリリースモデルを使用できます。
* **顧客が管理**する相互接続: Azure ExpressRoute、Google Cloud Interconnect、Equinix Fabric などの既存のプライベートネットワーク回線を Data 360 VPC に直接統合します。
* **Salesforce管理型インターコネクト:** Salesforce はクロスクラウドリンクをプロビジョニングおよび管理し、ターンキーセットアップのために、顧客の対象クラウド環境にプライベートサービスエンドポイントを公開します。
### Secureing the Gates: Salesforce Data 360 の API セキュリティ機能
エンタープライズデータを統合する強力なプラットフォームである Salesforce Data 360 は、堅牢な多層セキュリティ制御で構築されています。顧客にとって、API セキュリティの管理は包括的なデータ保護戦略の重要な部分であり、アクセスの制御、インテグレーションの管理、使用状況の監視を効果的に行うことができます。
Salesforce Data 360 内で API セキュリティを設定、制御、管理するためにお客様が使用できる主要な機能を次に示します。
#### 主要な API セキュリティ機能と特長
お客様は、いくつかの組み込み Salesforce 機能を活用して、Data 360 インスタンスへの安全な API アクセスを確保できます。
##### 1\. 堅牢な認証と承認 (OAuth 2.0)
Salesforce では、Data 360 API に対して厳格な認証を義務付けており、OAuth 2.0 が標準および推奨プロトコルです。
* **接続アプリケーション**: 外部アプリケーションへのアクセスを管理する接続アプリケーションを作成および設定します。これは、Data 360 取り込み API とクエリ API へのアクセスを認証し、許可するための主な仕組みです。
* **OAuth 範囲**: システム管理者は、最小権限の原則に従って、必要な最小限の権限を要求する特定の OAuth 範囲 (cdp_ingest_api、api など) を定義できます。
* **多要素認証(MFA)**: Salesforce Authenticatorおよびその他のMFAソリューションを適用して、重要なセキュリティレイヤーを追加し、検証済みのユーザーのみがAPIログインなどを使用してシステムにアクセスできるようにします。
##### 2\. 詳細なアクセス制御と権限
顧客は、データにアクセスできるユーザーやアプリケーション、そして実行できるアクションを細かく制御できます。
* **APIアクセス制御(機能)**: Salesforceサポートによって有効化されたこの機能を使用すると、管理者はAPIへのアクセスに使用できる接続アプリケーションを明示的に承認できます。未承認のアプリケーションはすべて自動的にブロックされるため、不正なデータ抽出のリスクが大幅に軽減されます。
* **権限セットとプロファイル**: システム管理者は、ユーザープロファイルまたは専用の権限セットを使用して「API の有効化」権限を割り当てることで、API アクセスを管理します。これにより、ユーザーは職務に関連するアクセス権のみを持つことができます。
* **ロールベースアクセス制御(RBAC)**: Data 360内で、お客様はロールベースのアクセス制御ポリシーを作成して管理し、データアクセスレベル(オブジェクト、項目、レコードレベルセキュリティ)を定義できるため、プラットフォーム全体の一貫性と制御を確保できます。
* **専用のインテグレーションユーザー**: ベストプラクティスとして、インテグレーション用に特定の「API 限定」ユーザーを作成し、システム管理者アカウントを使用するのではなく、API コールに必要な権限のみに制限することをお勧めします。
##### 3\. ネットワークセキュリティコントロール
* **IPホワイトリスト/ログインIP範囲**: APIアクセスを、定義された信頼できるIPアドレスの範囲に制限できます。未承認の IP アドレス範囲からのログイン試行は拒否されるか、検証が促される可能性があります。
* **プライベート コネクト**:AWS PrivateLink上に構築されたこの機能を使用すると、管理者はエンドポイントを公開インターネットに公開することなく機密データを管理できるため、公開されているエンドポイントに対する攻撃のリスクを排除できます。
* **送信中および保存**中の暗号化: すべてのデータは送信中および保存中に暗号化され(TLSを使用)、機密情報が傍受された場合でも不正アクセスから保護されます。
##### 4\. 監視、監査、ガバナンス
セキュリティにとって可視性は重要です。Salesforce には、API 活動を監視および監査するための広範なツールが用意されています。
* **イベント監視**: API コールやログイン試行など、さまざまなイベントをほぼリアルタイムで追跡します。顧客はこのデータを監査に使用し、トランザクション セキュリティポリシーを作成できます。
* **セキュリティセンター**: この機能は、すべての Salesforce 組織のセキュリティの健全性、コンプライアンス、およびガバナンスの評価指標を 1 つの統合されたビューで表示し、監視と管理を簡素化します。
* **項目監査履歴**: 顧客がログインと項目履歴を追跡し、設定変更を監視して、監査とデータ保持のコンプライアンス義務に対処できるようにします。
* **データ ガバナンス機能**:データのタグ付けと分類、ポリシーの適用、動的データ マスキングにより、APIを介してアクセスするものを含め、すべてのデータ タッチポイントに一貫したガバナンス ポリシーが適用されます。
#### API セキュリティの設定と管理: カスタマージャーニー
1. Enable Core Controls (コアコントロールを有効化): まず、MFA や IP 制限などの組織の共有設定を有効にします。
2. API アクセスコントロールを要求: Salesforce サポートにケースを登録して、組織で「API アクセスコントロール」機能を有効にします。
3. 接続アプリケーションの設定: インテグレーションごとに特定の接続アプリケーションを作成し、必要な OAuth 範囲を定義して、承認されたプロファイル/権限セットに割り当てます。
4. Implement Least Privilege (最小権限の実装): すべてのインテグレーションユーザーに「API 限定」権限があり、データアクセスが最小限であることを確認します。
5. 監視と監査: イベント監視およびセキュリティセンターを定期的に使用して、API の使用状況を確認し、異常を検出して、脆弱性評価を実行します。
6. ベストプラクティスの適用: 常に TLS を適用し、更新トークンを安全に保存し、セッション ID を循環し、データ入力を検証します。
これらの堅牢で顧客が設定できる機能を活用することで、企業は Salesforce Data 360 内のすべての API インタラクションで安全でコンプライアンスに準拠した環境を維持できます。
### コンプライアンス、監査、継続的な監視
#### サービスの可用性とデータレジデンシー
Salesforce Data 360 は、地理的に分散されたリリースモデルを使用して、グローバルなデータの居住性と主権の要件を満たすように設計されています。現在、このサービスは、米国、カナダ、ブラジル、ドイツ、インド、オーストラリア、日本など、複数の規制地域で利用できます。
データレジデンシーは、各顧客のコア組織インスタンスを最も近い対応する Data 360 地域インスタンスに対応付けることで決定されます。たとえば、米国またはカナダにあるコア組織は米国リージョン内の Data 360 インスタンスとペアになり、欧州連合内のコア組織はドイツでホストされているインスタンスに対応付けられます。同様に、インド、オーストラリア、ニュージーランド、シンガポールのコア組織は、インドでホストされている Data 360 インスタンスに関連付けられます。
SalesforceのHyperforceインフラストラクチャはこのモデルの基盤であり、地理的データの制御、セキュリティの分離、規制へのコンプライアンスの基盤となります。Hyperforceは、メタデータ、バックアップ、派生データセットなどの顧客データを、定義された地域の境界内に保持します。このアーキテクチャにより、企業は APAC と EMEA の各地域で、GDPR、FFIEC、HIPAA、地域のプライバシー保護法などのデータレジデンシーとコンプライアンス要件を満たすことができます。
Salesforceは、進化するグローバル プライバシー基準、地域のコンプライアンス要件、主権あるデータ管理に対するお客様の期待に合わせて、Data 360の可用性をさらにHyperforceリージョンに拡張し続けています。
#### 規制コンプライアンス イネーブルメント
Salesforce Data 360 は、GDPR や CCPA などの厳しいグローバルプライバシーおよび規制要件を企業が満たすことができるように設計されています。このプラットフォームは、データアクセス、エクスポート、削除 (「忘れられる権利」) などのデータ主体の権利 (DSR) を管理するネイティブ機能を提供し、ライフサイクル全体で個人データのコンプライアンス対応を保証します。
コンプライアンスの最終責任は顧客が負うことになりますが、Salesforce は CCPA などの規制に基づく認定「サービスプロバイダー」として業務を行い、組織がコンプライアンスフレームワークを効率的かつ大規模に実装するためのプラットフォームレベルの管理、セキュリティ保証、契約メカニズムを提供します。
#### 基盤 Trust: 認証および証明
Trust は Salesforce プラットフォームの礎であり、その信頼は独立した検証によって得られます。Salesforce は、顧客データの保護と最高水準のクラウドセキュリティの維持に対する継続的な取り組みを示す、グローバルセキュリティ認定および証明の広範なポートフォリオを保持しています。
これらの認定は単なるチェックボックスではなく、Salesforce のセキュリティ制御、プロセス、インフラストラクチャの強度と一貫性を検証する厳格な定期的な監査を表します。これらが組み合わさって、Salesforceの基盤となるTrustモデルを形成しています。
**主な認証および証明は次のとおりです。**
* **ISO/IEC 27001:** Salesforceの包括的な情報セキュリティ管理システムを検証します。
* **ISO/IEC 27017:**クラウド固有のセキュリティ制御のベスト プラクティスを確立します。
* **ISO/IEC 27018:**クラウドでのPII(個人識別情報)の保護に重点を置いています。
* **SOC 1、SOC 2、および SOC 3:** Salesforce のセキュリティおよびプライバシー管理の設計と運用の有効性を確認する独立したレポート。
* **PCI DSS:** 支払カード情報を安全に処理および保存します。
* **FedRAMP 高 & DoD 影響レベル 4:** 機密ワークロードを管理する米国連邦政府機関が使用するために Salesforce Government Cloud を認定します。
この包括的な認定セットを維持することで、Salesforce は、データがプラットフォーム上で管理され、グローバルなコンプライアンスおよびセキュリティの期待を満たし、しばしばそれを上回ることを保証する信頼感を顧客に提供します。
### 表示の最大化: Salesforce Data 360 でのログ記録、監視、オブザーバビリティ
急速に変化する今日のデジタル環境では、顧客データを全方位から把握することも重要ですが、同様に重要なのは、そのデータを管理するプラットフォームを全方位から把握することです。Salesforce Data 360 には、堅牢なロギング、監視、オブザーバビリティ機能が組み込まれており、顧客はデータの品質、セキュリティ、パフォーマンスを確保できます。
これらのツールは、事後対応型の問題解決からプロアクティブな管理への移行を支援し、Data 360 実装をスムーズかつ効率的に実行します。
#### プロアクティブな脅威の検出と対応
セキュリティは予防で終わりではなく、警戒しながら進化します。常に変化する脅威の状況では、Salesforce は高度なプラットフォーム監視機能と顧客が管理するレビュープロセスを組み合わせて、プロアクティブで継続的な保護を確保します。
Salesforce には、可視性と脅威検知のための強力なネイティブツールが用意されています。
* **監査履歴の設定**では、管理上の変更の完全な履歴が取得されるため、チームは設定やポリシーの更新を追跡できます。
* **イベント監視**では、ユーザーの行動、APIアクティビティ、データ アクセス パターンに関する詳細なインサイトが提供されます。このテレメトリは、**SIEM(セキュリティ情報**およびイベント管理)ソリューションとシームレスに統合して、一元的な分析と関連づけを行うことができます。
#### 1\. イベントモニタリング: 組織の鼓動
Salesforce Shield製品の一部であるイベント モニタリングは、Data 360固有のアクションなど、Salesforce組織の詳細なユーザー アクティビティとシステム パフォーマンス データを追跡する中央ハブです。分析のために、さまざまな「イベント」をログファイルとオブジェクトに取り込みます。
* **イベントログファイル (ELF):** ユーザーアクティビティとシステムイベントの詳細な詳細を提供し、少し遅れて (1 時間ごとまたは 1 日ごと) ダウンロードできます。API または \[イベントログファイル] ブラウザーから最大 30 日分のデータにアクセスできます。長期保存用にエクスポートすることもできます。
* **リアルタイムイベント監視:** リアルタイムイベントをプラットフォームイベントとしてストリーミングすることで、ほぼリアルタイムで活動を監視および検出できます。これはセキュリティとパフォーマンスにとって不可欠であり、必要に応じてすぐに対応できます。
* **Data 360 固有イベント:**イベント モニタリングには、Lightning ページ ビュー、Lightning インタラクション、Data 360 ページおよびデータに関連するレポート イベントなど、Data 360 の使用状況に固有のイベント タイプが含まれます。
* **外部ツールとの統合:** Salesforce は、Splunk、Datadog、New Relic、Sumo Logic などの一般的なサードパーティ監視ソリューションとのシームレスな統合を促進します。これらのプラットフォームにストリーミングまたはエクスポートすることで、技術スタック全体の統合的な監視が可能になります。
#### 2\. パフォーマンスの監視と最適化
Data 360 実装のパフォーマンスを理解することは、優れたユーザーエクスペリエンスの鍵となります。
* **Lightning Usage アプリケーション:**この組み込みアプリケーションでは、Lightning Experience のデータ 360 ページのパフォーマンス評価指標 (ページ読み込み時間 (EPT) やブラウザーのパフォーマンスなど) が集計ビューに表示されます。
* **カスタムレポートおよびダッシュボード:** Event Monitoring Plus という無料の CRM Analytics テンプレートアプリケーションの使用を含め、Data 360 オブジェクトとイベント監視データを使用してカスタムレポートおよびダッシュボードを作成できます。これらの視覚化により、トレンドを特定し、パフォーマンスのボトルネックをすばやく特定できます。
しかし、テクノロジーだけでは不十分です。真のレジリエンスを実現するには、自動検出と人によるレビューの連携が必要です。自動化されたアラートはリアルタイムで異常を示す可能性がありますが、多くの場合、有効なユーザーによる低速で不正なデータの持ち出しなど、微妙な脅威や長期的な脅威は、定期的な監査とトレンド分析によって特定できます。
Salesforce はテレメトリ、監査ログ、インテグレーションフックを提供します。顧客はプロセスの厳格さ、運用ケイデンス、コンテキスト固有のインテリジェンスをもたらします。これらを組み合わせることで、**多層防御モデル**が形成されます。自動化、分析、手動監視を組み合わせて、インシデントになる前に脅威を検出、調査、対応します。
### 情報に基づいた意思決定の促進: Salesforce Data 360 のレポート、ダッシュボード、評価指標、通知
Salesforce Data 360 は、顧客データを統合するだけでなく、そのデータをインテリジェントでアクション可能なものにします。この価値提案の中核となるのは、堅牢なレポート、強力なダッシュボード、インサイトに富んだ評価指標、リアルタイム通知機能です。これらのツールを使用すると、使い慣れた Salesforce 環境内で、データの健全性の監視、パフォーマンスの追跡、統合データに基づくアクションの自動化をすべて行うことができます。
#### レポートとダッシュボード: データ視覚化ハブ
Salesforce のネイティブのレポートおよびダッシュボード機能は Data 360 にシームレスに拡張され、プラットフォームを離れることなく統合データを視覚化および分析できます。
#### 統合データに基づく Data 360 レポートの作成
さまざまなソースからの統合データや計算済みインサイトなど、Data 360 に保存されているデータに関する標準レポートとカスタムレポートを作成できます。
* **標準およびカスタムレポートタイプ:** Data 360 では、データストリーム、セグメント、有効化、ID 解決、計算済みインサイトなど、Data 360 オブジェクト専用の新しいレポートタイプが導入されています。これにより、標準の Salesforce レポートビルダーを使用して統合データを照会できます。
* **詳細分析:** レポートでは最大 10 行のグルーピングがサポートされるため、顧客の属性とトレンドをより詳細に区分して詳細に分析できます。
* **数式と概要:** 行レベルの数式と集計項目を活用して、各レコードまたはレコードグループを評価し、1つのレポート内で詳細な評価指標と集計の概要を追跡できます。
#### 全体像を捉えるための動的なダッシュボード
ダッシュボードでは、Data 360 実装全体の主要な総計値とトレンドが視覚的に表示されます。
* **統合ビュー:** 複数のData 360レポートのデータを統合したり、Data 360レポートを標準のCRMレポートと組み合わせたりして、業務と顧客インサイトの全体像を1つのダッシュボードで把握できます。
* **カスタマイズ可能ウィジェット:** さまざまな種類のグラフ (棒グラフ、折れ線グラフ、円グラフ、ゲージグラフなど) とテーブルを使用して、レポートデータを効果的に表示します。
* **リアルタイムインサイト:** ダッシュボードを更新して最新情報を提供し、データ主導の迅速な意思決定を支援します。
#### 評価指標と KPI: 成功の測定
Data 360 では、ビジネス目標に関連する重要業績評価指標 (KPI) を定義して追跡できます。これらは次の方法で生成できます。
* **計算済みインサイト:** 大量のバッチで処理されたデータを使用して、強力な評価指標を作成します。たとえば、「Average Customer Lifetime Value (平均顧客生涯価値)」や「Total Active Contract Revenue (有効な契約収益の合計)」などの総計値を計算し、レポートやダッシュボードでディメンションや基準として使用します。
* **ストリーミングインサイト:** ストリーミングソースのデータをほぼリアルタイムで処理し、Web サイトやモバイルエンゲージメントデータなどの時系列集計を構築します。これらのメトリクスは、すぐにオーケストレーションやデータアクションを実行できます。
#### 通知とアラート: 最新情報とプロアクティブな対応
Salesforce には、Data 360 内の重要なイベントやデータの変更を確実に把握するための強力な自動化機能と通知機能があります。
* **フローベースの通知:** データストリーム、セグメント、有効化などのデータ 360 オブジェクトのイベントに基づいてアクションをトリガーし、通知を送信するようにプロセスフローを設定できます。
* **カスタムアラート:** 特定の条件を満たしたときにメールをトリガーしたり、Salesforce 通知ベルに表示したりするカスタム通知を作成します。たとえば、データストリームが失敗した場合、ID 解決ルールでエラーが発生した場合、主要な指標が特定のしきい値を超えた場合にアラートを受信できます。
* **イベント通知サービス(ENS):** 開発者にとって、APIファーストのイベント通知サービスでは、特定のイベントが発生したときに外部システムで通知を受信できるため、テクノロジースタック全体でシームレスな統合とリアルタイムの反応が可能になります。
* **データアクション:** ストリーミングインサイトに基づいて、データアクションをトリガーできます。データアクションは、アラートの送信、プラットフォームイベントの呼び出し、Web フックを介した他の SaaS アプリケーションとの統合を行うように設定できます。
Salesforce Data 360 のお客様は、これらの包括的な機能を活用して、データエコシステムを効果的に監視し、主要な評価指標を視覚化して、タイムリーなアラートを受信し、プロアクティブなエンゲージメントと優れた運用性を実現できます。
### 企業導入のための戦略的レコメンデーション
Salesforce Data 360 を企業規模で採用するには、技術的なイネーブルメント以上のものが必要です。それには、慎重でセキュリティ優先のアーキテクチャが求められます。次の戦略的レコメンデーションは、CTO と企業アーキテクトが Data 360 展開のすべてのレイヤーに Trust、耐障害性、コンプライアンスを構築するためのロードマップを提供します。
* **「セキュア**バイデザイン」アプローチの実装: セキュリティは後付けではなく、基礎とする必要があります。Salesforce のデフォルトの*「すべて拒否」*ポリシーから開始し、必要に応じてアクセス権を明示的に付与します。データを取得または有効化する前に、ガバナンス、ポリシー、アクセスフレームワークを定義します。初日からセキュリティを構築することで、隠れた情報漏洩のリスクを排除し、長期的なコンプライアンスを簡素化します。
* **堅牢なIDおよびアクセス管理(IAM)戦略の適用:**統合SSOでIDを一元化し、多要素認証(MFA)を適用してログイン情報侵害を軽減します。ログイン IP アドレスの制限によってアクセスを制限し、Salesforce の ID プロバイダー (IdP) 機能を使用して、ユーザーおよびインテグレーション全体でエンドツーエンドの説明責任を確立します。統合された IAM レイヤーにより、運用の複雑さが軽減され、認証表面が強化されます。
* 最小権限の**原則の適用:** 利便性ではなく精度のためにロールを設計します。Salesforce の標準権限セットを職務分掌の基盤として使用し、ユーザーが必要な情報にのみアクセスできるようにします。権限の過剰なカスタマイズを避ける — 逸脱が発生するたびに、メンテナンスオーバーヘッドが増加し、意図しないアクセスのリスクが高まります。
* 多層データガバナンスフレームワーク**の確立:** データスペースを使用してビジネスユニットまたはブランド別にデータを分離し、オブジェクトレベル、項目レベル、およびレコードレベルセキュリティ (OLS、FLS、RLS) を使用して属性ベースのアクセス制御 (ABAC) を適用します。動的データマスキングを使用して、分析やユーザビリティを損なうことなく、機密情報をリアルタイムで保護します。この階層化されたモデルにより、ドメイン間でデータの規模を拡大してもガバナンスの一貫性が維持されます。
* 暗号化と安全な統合の**戦略的活用:** 機密性の高いワークロードの場合、顧客が管理する鍵を使用したプラットフォームの暗号化(CMK)を導入して、暗号化ライフサイクルの主権を維持します。指定ログイン情報とプライベートコネクトを使用して、すべてのシステム間インテグレーションを保護します。これにより、ハードコードされた秘密が排除され、すべてのトラフィックが非公開、コンプライアンス、監査可能のままになります。
* **継続的な**セキュリティ運用プログラムの構築: セキュリティは設定だけで終わりではなく、運用の規律によって強化されます。イベントログとアクセス履歴の定期的な監査レビューで自動監視を補完します。異常の特定、脅威の調査、コンプライアンスの検証を行うための専用のセキュリティオペレーション (SecOps) 機能を確立します。目標は、早期発見、迅速な対応、姿勢の継続的な改善です。
### Path Forward: Building a Resilient, Trusted Data 360 (進むべき道: 耐障害性の高い信頼できるデータ 360 の構築)
安全でインテリジェントな企業への移行は、単なる展開で完結するものではなく、規律、設計、そして信頼によって進化していきます。Salesforce Data 360 はアーキテクチャの基盤を提供しますが、真の価値は、組織がセキュリティ、ガバナンス、インテリジェンスを 1 つの統合された動きとして運用することで現れます。
企業は、Data 360を別のデータ プラットフォームとしてではなく、単一のガバナンス フレームワークでデータ、AI、カスタマー エンゲージメントを接続する安全で構成可能なTrustレイヤーとしてアプローチする必要があります。*セキュア バイ デザイン*の理念を採用し、すべてのレイヤーに最小限の権限を適用し、すべてのデータ フローにプライベート接続を拡張することで、組織はコンプライアンスをチェックボックスから競争優位性に変換します。
次のステップは、継続的なモダナイゼーションです。監査の自動化、ポリシーの適用、暗号化ライフサイクル管理を日常業務に組み込みます。企業がエージェント型、AI駆動のアーキテクチャへ進化するにつれて、今日データを保護する原則は、明日のAIガバナンスの中核を担い、すべてのモデル、エージェント、及び意思決定が説明可能で、ポリシーに基づいて適切に管理される仕組みとなります。
最終的には、信頼がデジタル・トランスフォーメーションの新しい通貨となります。Salesforce Data 360 を使用すると、企業はデータエコシステムを自信を持って拡張できます。すべてのバイト、すべての接続、そしてすべてのインサイトが、確固たる信頼のもとで保護され、管理され、有効化されることが保証されます。
## 著者について
**Krishna Chalamasandra**は、情報セキュリティ テクノロジーとコンプライアンスで25年以上の経験を有する経験豊富なサイバーセキュリティ エキスパートです。Salesforceでは、顧客の信頼できるアドバイザーとして、CISO組織内のSecurity and Compliance Customer Trust機能の主要なリーダーを務めています。以前は、Cisco に 10 年間在籍し、IAM、ネットワークセキュリティ、PKI のセキュリティアーキテクチャを主導し、ISO 27001、SOC 1 ～ 3、PCI、FedRAMP、FIPS 140-2 などの主要な認証を推進しました。 また、Novell に 8 年以上在籍し、インフラストラクチャレベルの制御を実装し、世界中の規制対象の顧客向けの複雑なセキュリティレビューをサポートしました。
**Yugandhar Bora**は、Salesforceのソフトウェアエンジニアリングアーキテクトで、Data & Intelligence Applicationsプラットフォーム内のデータアーキテクチャを専門としています。データガバナンスと統合データモデルに焦点を絞ったエンタープライズアーキテクチャレビューボード (EARB) イニシアチブを主導しながら、自動化プラットフォームプロビジョニングソリューションに貢献しています。