このテキストは、Salesforce の自動翻訳システムを使用して翻訳されました。アンケートに回答して、このコンテンツに関するフィードバックを提供し、次に何を表示するかをお寄せください。

Salesforce Data 360 は、企業が顧客データを大規模に接続、ハーモナイズ、有効化する方法を変革します。しかし、その真の強みは、データがライフサイクル全体でいかに安全に管理されているかにあります。このセキュリティリファレンスアーキテクチャは、Data 360 環境を保護するための実用的なエンドツーエンドのブループリントを提供します。これは、デフォルトで最小権限、ゼロトラスト設計、ガバナンスという基本原則によって達成されます。 Data 360 のセキュリティは、その基礎において共有責任モデルです。Salesforce は、ISO 27001、SOC 2、一般データ保護規則 (GDPR) などのグローバル標準に従って、インフラストラクチャ、ネットワーク、暗号化サービス、プラットフォーム、コンプライアンス、およびアプリケーション自体を保護します。Salesforce システム管理者は、アクセスの定義、プライバシーの適用、インテグレーションの管理を行って、プラットフォーム内の組織のデータを保護します。これには、必要なアクセス権のみを付与する強力な ID およびアクセス管理 (IAM) の実装、2 要素認証 (2FA) の適用、最小権限の原則の遵守、企業および規制要件の遵守が含まれます。 Data 360 Governance は、これらの責任レイヤーを接続し、セキュリティとコンプライアンスの一貫性を確保します。これにより、ロール、ポリシー、権限、データ処理ルールが定義され、取り込みから有効化までのプロセス全体で継続的に適用されます。データ系統、メタデータ分類、同意認識は、すべてのオブジェクトとプロセスに組み込まれています。これにより、ガバナンスが手動監視機能から運用コントロールプレーンに変換されます。 Salesforce は、企業がデータポスチャ、プライバシー設定、インテグレーション境界に関する完全な権限を保持できる、弾力的でコンプライアンスに準拠した基盤を提供します。これらを組み合わせることで、すべてのデータセット、ポリシー、ユーザー アクションを追跡可能で一貫性があり、Trustで固定できるセキュリティとガバナンスのファブリックが作成されます。 Data 360 のセキュリティは静的制御以外にも拡張されています。これは、データライフサイクルのすべてのフェーズに組み込まれています。データは取り込まれた瞬間から、エンタープライズポリシーに基づいて暗号化、検証、分類されます。統合および強化されると、説明責任を確保するためにメタデータの系統と同意属性が保持されます。ビジネスまたは AI で使用するためにインサイトを有効化すると、暗号化されたチャネル、強力な認証と承認、ポリシー対応ガバナンス、同意適用によって送信フローが保護され、取り込みから有効化までデータの信頼、コンプライアンス、セキュリティが維持されます。

Salesforce Data 360は、グローバル運用のための安全でコンプライアンスと拡張性に優れた基盤を提供する、SalesforceのHyperforceアーキテクチャに基づいて完全に構築されたクラウド ネイティブのデータ プラットフォームです。

  • Hyperforceは、セキュリティとコンプライアンスをアドオンではなく組み込み機能として提供します。Salesforce のプラットフォームとアプリケーション全体で緊密に統合された共通の基盤制御セットが提供され、インフラストラクチャからアプリケーション環境まで、すべてのレイヤーがセキュリティ、プライバシー、コンプライアンスを中核として設計されています。
  • Data 360は、堅牢なアクセス制御、暗号化、およびコンプライアンス フレームワークをHyperforceの基盤制御から直接継承します。
  • このセキュアなデフォルトモデルは、脆弱性を最小限に抑え、信頼できる準拠データサービスの提供を簡素化します。
  • Data 360は、分離、パフォーマンス、マルチ テナントのセキュリティを確保する統合クラウド プラットフォームであるHyperforce上でホストされる専用の機能ドメイン内で実行されます。
  • Data 360 ではマイクロサービスアーキテクチャが使用され、すべてのサービスが Kubernetes を介してコンテナ化およびオーケストレーションされます。
  • Zero Trustの原則を適用して、Istioサービス メッシュは安全なサービス間通信を管理し、トラフィック管理、オブザーバビリティ、ポリシー適用を提供します。
  • Data 360 サービスは、Salesforce で管理される仮想プライベートクラウド (VPC) を使用してプロビジョニングおよび運用され、分離、効率的な制御、最適化された内部ネットワーキングを実現します。
  • このアーキテクチャは水平スケーラビリティをサポートしているため、Data 360 はペタバイト規模のデータ処理ワークロードを確実に処理できます。
  • Data 360 では、Salesforce CRM アプリケーションや他のデータソースと統合するための明確に定義された API が公開されています。
  • ファーストパーティ (1P) 組織と Hyperforce ベースの Salesforce CRM 組織の両方をサポートしているため、環境間の幅広い互換性が確保されています。
  • Data Cloud One では、複数の Salesforce CRM 組織を 1 つの Data 360 インスタンスに接続できます。

Salesforce Data 360内のセキュリティは、共有責任モデルに基づいて動作します。このフレームワークは、Amazon Web Services(AWS)、Microsoft Azure、Google Cloudなどの主要なクラウド プロバイダーでも使用されています。 このモデルは明確な境界を定義します。Salesforceはクラウドセキュリティを担当し、お客様はクラウドのセキュリティを担当します。この違いを理解して運用することは、耐障害性、コンプライアンス、セキュリティに優れたデータエコシステムを維持するために不可欠です。 Data 360 セキュリティの共有責任モデル

Salesforce は、Data 360 プラットフォームとそのグローバルインフラストラクチャの整合性を確保し、維持する責任があります。具体的な動作は次のとおりです。

  • **物理的および環境的なセキュリティ:**HyperforceはAWSインフラストラクチャでホストされ、Amazonはアクセス制御、監視、環境保護を通じてグローバル データセンターの保護を委任されています。
  • **ネットワークと境界の防御:**転送中 (TLS 1.2 以上) および保存中のすべてのトラフィック (AES-256) の分散サービス拒否 (DDoS) の軽減、侵入検知、暗号化。
  • **プラットフォームの強化とパッチ管理:**継続的な脆弱性管理、パッチリリース、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 組織は「すべて拒否」状態になり、最初のリリースからTrustの原則が適用されます。

以前の環境では、オンボーディングを迅速化するために、顧客は「すべて許可」という権限のあるモデルを継承していました。これは便利な反面、偶発的な露出過剰や設定ミスによるリスクを生み出していました。 新しいデフォルトのセキュア アーキテクチャでは、このアプローチが逆になります。

  • 暗黙的なアクセス権を持つユーザーまたはシステムはありません。
  • すべての権限が明示的に付与されている必要があります。
  • データアクセス、インテグレーション、およびガバナンスコントロールは 0 日目から適用されます。 これにより、意図的に最小限の権限が適用されるため、誤って情報が漏洩したり、権限がエスカレーションされたりするリスクが大幅に軽減されます。

このモデルには、技術的な影響と行動的な影響の両方があります。

  • チームはアクセスモデルを意図的に計画し、権限をコンプライアンスとビジネスの境界に合わせる必要があります。
  • ガバナンスは、後付けではなく組み込みの設計要件になります。
  • データの所有権と説明責任は最初から定義されます。 従来の Data 360 組織が引き続き [すべて許可] で運用されている場合、システム管理者はセキュリティのモダナイズや Data 360 成熟度プログラムの重要なステップである新しいベースラインに合わせて手動で設定を厳格化する必要があります。

デフォルトのアクセスをゼロにして明示的なポリシー定義を要求することで、Salesforce Data 360はエンタープライズ データ セキュリティの基本的な進化であるTrust-by-Designを確立します。 このアプローチにより、次のことが保証されます。

  • 不正アクセスやデータ漏洩のリスクを最小限に抑えます。
  • ガバナンスフレームワークは、任意ではなく構造的に適用されます。
  • 企業は、さまざまな環境でより予測可能、監査可能、かつ復元性の高いセキュリティ体制を実現できます。 本質的に、セキュリティはユーザーが追加する機能ではなくなります。これは、開始する基盤です。

Salesforce Data 360のIAM(Identity and Access Management)は、防御の最初で最も重要なレイヤーです。プラットフォームにアクセスできるユーザーと、プラットフォーム内で 1 回実行できるアクション制御します。適切に実装された IAM フレームワークは、企業が顧客データを保護し、業務の整合性を確保するために必要とする唯一の強力な制御です。

認証により**、Digital Trust**が確立され、Salesforce Data 360にアクセスするすべてのユーザー、サービス、外部システムが正当なものであるかどうかが確認されます。

Data 360 では、 SAML 2.0、OpenID Connect (OIDC)、または System for Cross-domain ID Management (SCIM) を使用した Microsoft Entra ID (Azure AD)OktaPing Identity などのエンタープライズグレードの ID プロバイダー (IdP) を使用した 統合認証 がサポートされます。 この統合により、企業 ID ライフサイクルが Salesforce に直接拡張されます。従業員が入社、異動、退職すると、アクセス権が自動的に調整され、孤立した取引先が減り、コンプライアンスの準備が向上します。

シングルサインオン(SSO)を使用すると、ユーザーは会社のログイン情報を使用して一度認証すると、個別のパスワードなしでSalesforceアプリケーションへの安全なアクセスが可能になります。これにより、ログイン情報の疲労が軽減され、パスワードの再利用やフィッシングによるリスクが最小限に抑えられます。

ID プロバイダー (IdP) は、多要素認証 (MFA)、条件付きアクセス、リスクベースの制御を適用して、認証に関する意思決定を行う唯一の機関となります。認証は、1つのイベントから、ユーザーの行動やコンテキストに応答する継続的なTrust評価に進化します。 統合認証には次の機能があります。

  • **一元的なポリシー適用:**認証標準は、すべての Salesforce 環境で 1 か所で管理されます。
  • **エンド・ツー・エンドのトレーサビリティ:**統合監査履歴では、すべてのアクションが検証済み ID にリンクされます。
  • **人間中心の環境:**スムーズで安全なログインプロセスにより、チームはログイン情報ではなくインサイトに集中できます。

ユーザーが検証されると、認証によってユーザーがアクセス、表示、または変更できる内容を定義します。機密データを保護し、最小限の権限を適用する運用境界を設定します。 **PoLP(最小権限の原則):**すべてのユーザーとシステムには、職務に必要な権限のみが付与され、それ以上の権限は付与されません。この原則により、侵害されたログイン情報や設定ミスによる潜在的な損害が大幅に制限されます。 **ロールベースのアクセス制御 (RBAC):**Salesforce Data 360 では、権限セットと権限セットグループを使用して、ビジネスロールに応じたきめ細かな機能を割り当てます。次に例を示します。

  • データエンジニアは、「Data 360 Architect」権限セットを使用して取り込みパイプラインと変換を管理できます。
  • マーケティングアナリストはハーモナイズデータを照会できますが、「Data 360 有効化マネージャー」権限セットを使用してモデルを変更することはできません。
  • 有効化マネージャーは送信キャンペーンを実行できますが、Data 360 有効化マネージャー権限セットを使用してソースデータにアクセスすることはできません。 アクセス権は一元管理され、監査可能であるため、データライフサイクル全体で説明責任を果たすことができます。Entra ID、Okta、Ping Identity などの IdP と統合すると、アクセスポリシーは SCIM プロビジョニングと SAML/SSO 統合を介してシームレスに企業全体に拡張されます。

Salesforce には、職務の分離と ISO 27001 などの業界標準への準拠のためのベストプラクティスをカプセル化した定義済みの権限セットが用意されています。

ロール 主な責任 アクセス設計原則
システム管理者 環境の設定、プロビジョニング、設定 基盤となるデータセットへのアクセス権なし — システムとデータ制御の分離を確保
Data 360 Architect データの取り込み、変換、ID 解決、モデリング データ公開境界を維持するためにデータの有効化を実行できない
Data 360 Activation Manager セグメントの作成、チャネル管理、有効化 データモデルへの参照のみアクセス権。変更権限なし
Data 360 ユーザー 分析とインサイトを消費する 参照のみ、変更権限なし
Data 360 One ユーザー コンパニオン組織を介した組織間アクセス 共有スペース権限と範囲設定済みアクセスポリシーにより管理

この構造的な権限の分離により、ISO 27001 や SOC 2 などのフレームワークの職務分離 (SoD) 要件に合わせて、1 つのロールでデータライフサイクル全体を制御できなくなります。 Data 360 標準権限セットは、新機能が使用可能になるたびにリリースごとに自動的に更新されます。一方、カスタム権限セットは自動的に更新されないため、セキュリティの脆弱性が生じたり、きめ細かく管理しないと機能しなくなったりします。

  • **Automatic Policy Evolution:**Salesforce では、プラットフォームリリースの一環として標準権限セットのメンテナンスと更新を行っています。新機能が導入されると、権限セットが自動的に調整されるため、管理オーバーヘッドが軽減され、設定のずれが解消されます。
  • **攻撃対象領域の削減:**詳細なアクセス境界により、データの不正使用や不注意による権限のエスカレーションを防止できます。
  • **監査とコンプライアンスの準備状況:**標準化されたロールにより、証明が簡素化され、監査や規制レビュー時に企業がアクセス制御を容易に示すことができます。
  • **拡張性の高いガバナンス:**管理者は、SCIM プロビジョニングと SAML/SSO フェデレーションを使用して、これらのロールを Okta や Microsoft Entra ID などのエンタープライズ IAM システムに直接マッピングできるため、Data 360 と広範なエンタープライズエコシステムの両方で統合されたセキュリティ体制が保証されます。
  • **標準ロールの採用:**コピーやカスタマイズではなく Salesforce の標準権限セットを使用して、リリース全体で自動更新と一貫した権限モデルを確保する
  • **Enterprise IAMとの統合:**SCIM または ID 統合を使用してアクセスプロビジョニングを一元化し、すべての ID の表示とライフサイクル制御を維持します。
  • **定期的なアクセスレビューの実施:**定期的なアテステーションプロセスを実装して、権限の劣化を検出し、機能要件と一致していることを確認します。
  • **ジャスト・イン・タイム・アクセスの適用:**機能の向上については、Zero Trustの原則に従って、自動的に期限切れになる一時的な権限を付与します。 IAM は、人間の ID、システムアクセス、データガバナンスを接続するコントロールプレーンです。Salesforce Data 360は、統合認証、きめ細かな認証、継続的に進化する権限モデルを通じて、ゼロトラストを適用するためのツールを企業に提供します。ただし、その真の有効性は、組織がこれらの統制をどのように運用しているかにかかっています。つまり、1つの目標(妥協のないData Trust)に基づいて、人、プロセス、テクノロジーを調整しているのです。

今日のエンタープライズデータエコシステムでは、ガバナンスはもはや制約ではなく、信頼できるインテリジェンスを実現する主要な要素です。アーキテクトにとっては、俊敏性と制御性、オープンアクセスと確実なコンプライアンスのバランスが定義されます。 Salesforce Data 360 (Data 360) は、この原則をコアとして設計されています。GovernanceとTrustはレイヤーを追加するものではなく、アーキテクチャのファブリックそのものに組み込まれています。取り込みやハーモナイゼーションから有効化、AI主導のインサイトまで、データ ライフサイクルの各フェーズは、エンタープライズ全体でデータの分類、保護、アクセス、責任ある使用の方法を定義する統合ガバナンス コントロール プレーンの下で動作します。 Data 360ガバナンス モデル

Data 360 は、ガバナンスファーストモデルに基づいて設計されており、取り込みからインサイトの有効化まで、すべてのデータインタラクションがポリシー対応で監査可能、かつコンプライアンスを確保します。ガバナンスは中央コントロールプレーンとして機能し、ライフサイクル全体でデータを検出、分類、保護する方法を管理します。 この統合コントロールプレーンにより、次のことが可能になります。

  • データ アクセスはコンテキストに応じて許可されます。適切なポリシーに基づいて適切なユーザーのみが適切なデータに対してアクションを実行できます。
  • ガバナンスはセマンティック レイヤーと運用レイヤーの両方に組み込まれ、データのモデル化方法と保護方法の一貫性が確保されます。
  • ** Zero Trust と Least Privilege** の原則が適用されます。つまり、ID、コンテキスト、ポリシーは、アクセス権を付与する前にリアルタイムで評価されます。 このアーキテクチャにより、Salesforce Data 360 はガバナンスを静的な権限管理から動的なポリシー主導のオーケストレーションレイヤーに変換します。コンテキストに継続的に適応し、設計によってコンプライアンスを適用し、エンタープライズ規模でTrustを維持するものです。

マクロレベルでは、データスペースによってエンタープライズデータドメインが論理的に分離され、マルチブランド、マルチリージョン、またはマルチテナントの運用モデルを持つ組織は、1 つの統合プラットフォーム内でデータを管理できます。データスペースは、ビジネスドメイン (セールス、マーケティング、カスタマーサクセスなど) または規制や地理的境界 (EU、AMER、APAC など) に合わせることができるため、基盤となるデータプラットフォームを断片化することなく、ガバナンスとアクセス制御で組織の業務とコンプライアンスの構造を反映できます。

  • 各データスペースは仮想境界として機能し、ユーザーまたはチームが参照または操作できるデータ収集を定義します。
  • データスペース内のアクセス権は明示的に付与され、暗黙的な権限やデータ表示の交差汚染がなくなります。
  • これにより、所有権の統合が可能になります。各ビジネスユニットは、一元的な監視とコンプライアンスを維持しながら、ドメインを個別に管理できます。 設計上、データスペースはガバナンスの第 1 層を提供し、エンタープライズデータセット全体の構造的な明確さと説明責任を確立します。 <img style="border:1px solid #e5e5e5;margin:2rem 0rem"

src="https://a.sfdcstatic.com/developer-website/prod/images/architect/data_360_security_architecture/data_360_dataspace.png" alt="Data 360 データスペース" />

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 全体で適応性のあるきめ細かなアクセス制御を実現します。

Salesforce Data 360 のきめ細かなアクセス制御の中心となるのは、属性ベースのアクセス制御 (CEDAR ポリシー言語に基づく ABAC) です。 静的なロール ベースの権限とは異なり、ABACはアクセスを要求している_ユーザー_、アクセスしようとしている_内容_、_条件_を動的に評価し、すべてのデータのやり取りがエンタープライズ ポリシーとTrust Boundaryに準拠するようにします。

Data 360 の ABAC エンジンは、次の 3 つのコア属性種別の組み合わせに基づいてアクセスの決定を評価します。

  • ユーザー属性: 部門、場所、クリアランスレベル
  • データ属性: 分類、機密性 (PII、PHI、財務データ)、データスペース この柔軟でポリシー主導のモデルにより、ユーザーロール、データ分類、または運用条件の変化に応じて適用を自動的に適応させることができます。これは、大規模で分散した規制対象の企業にとって不可欠です。 <img style="border:1px solid #e5e5e5;margin:2rem 0rem"

src="https://a.sfdcstatic.com/developer-website/prod/images/architect/data_360_security_architecture/attribute_based_access_control.png" alt="属性ベースのポリシー制御" />

Salesforce Data 360 は、ポリシー主導のデータガバナンスの業界のベストプラクティスに準拠した標準ベースの属性ベースのアクセス制御 (ABAC) アーキテクチャを実装しています。次の 3 つの主要な機能コンポーネントで構成されます。

  • PIP(ポリシー情報ポイント) - ポリシー、強化されたメタデータ、分類:
  • エンタープライズデータを管理するデータアクセス、分類、マスキング、保持、使用ポリシーなど、ポリシー定義自体を格納します。
  • タグ、分類、ビジネスコンテキスト、エンドツーエンドの系統など、強化されたメタデータを維持します。
  • LLM および ML 駆動の分類を使用して、機密データ (PII.Email、PII.Phone、PHI など) を自動的にタグ付けします。
  • タグの伝搬により、データ系統 (DLO → DLO → DMO) に沿って分類が自動的に流れます。
  • 変換全体で機密性とコンプライアンスを維持します。
  • Policy Decision Point (PDP) は、CEDAR ポリシーを解釈する決定エンジンです。
  • PEP (ユーザー ID、要求メタデータ) からのコンテキスト入力と PIP からの参照属性を取り込みます。
  • ポリシーを確定的に評価して、一貫性があり、説明可能で、拡張可能なアクセスの決定を行います。
  • リアルタイム評価と一括評価の両方がサポートされ、大規模環境でもパフォーマンスと精度が確保されます。
  • Policy Enforcement Point (PEP) は、実行時に承認の決定が適用される場所です。
  • API、UI クエリ、CRM 強化、GenAI 取得拡張生成 (RAG) パイプラインなど、すべてのインタラクションチャネルでデータアクセス要求を代行受信します。
  • PDP の結果をすぐに適用し、すべてのクエリと取得がエンタープライズアクセスポリシーに準拠するようにします。 PIP と PDP と PEP の 3 つの組み合わせにより、分散ガバナンスファブリックが形成され、すべての Data 360 サービスとアクセスモードに一貫したポリシーベースの制御が適用されます。 重要なのは、Data 360 の ABAC が設定されており、構築されていないことです。アーキテクトは、カスタムコントロールプレーンや適用ロジックを組み立てません。代わりに、統合ガバナンスファブリックとして連携して動作する 3 つのネイティブアーキテクチャコンポーネントを入力して接続します。 実装は、データを分類し、ポリシーを定義して、プラットフォームで自動的に適用するという単純な手順に従います。一度設定すると、アクセス制御は手動プロセスや手順プロセスではなくシステムの動作になります。 この分散ガバナンス ファブリックにより、すべてのアクセス チャネルで一貫したポリシーを適用し、Data 360全体で統合されたTrust境界を作成できます。

Data 360 の ABAC フレームワークでは、階層化されたアクセス境界がサポートされているため、オブジェクトレベルだけでなく、特定の項目やレコード内でもデータが保護されます。

  • オブジェクトレベルセキュリティ (OLS):アクセス制御の最外境界。 データレークオブジェクト (DLO) やデータモデルオブジェクト (DMO) などのデータ構造全体へのアクセスを管理します。 例:Customer オブジェクトへのアクセス権の付与。ただし、_トランザクション_へのアクセス権の付与は不可。
  • 項目レベルセキュリティ (FLS):オブジェクト内の特定の項目へのアクセスを制御します。 例:マーケティングユーザーは顧客名を表示できますが、クレジットカード番号や国民 ID の表示は制限されます。
  • レコードレベルセキュリティ (RLS) ―最も詳細な制御レイヤー。 ユーザーが表示または変更できるデータセット内の個々のレコードを決定します。 例:地域マネージャーは、割り当てられた地域に関連付けられた顧客データにのみアクセスできます。
  • **動的データマスキング (DDM) ―**リアルタイムのデータ保護を有効にします。ABAC を補完する DDM は、基盤となるデータセットを変更することなく、機密情報をポリシーに基づいて難読化します。クエリ時に、DDM はユーザーロール、コンテキスト、またはコンプライアンスルールに基づいて PII などの項目や財務データを自動的にマスキングします。
  • 機密データは、UI ビュー、API、AI ワークフロー全体で保護されます。
  • すべての消費レイヤーで一貫したマスキングを確保することで、データ漏洩のリスクを軽減します。
  • 監査可能性を維持します。マスクされたすべてのクエリは、Data 360 のガバナンスフレームワーク内で記録され、追跡できます。 <img style="border:1px solid #e5e5e5;margin:2rem 0rem"

src="https://a.sfdcstatic.com/developer-website/prod/images/architect/data_360_security_architecture/attribute_based_access_control_in_action.png" alt="属性ベースのポリシー制御の動作" />

このアーキテクチャにより、アクセス制御が静的権限モデルから動的なコンテキスト対応ポリシーファブリックに変換されます。RBAC の構造的なシンプルさと ABAC のコンテキストの深さを組み合わせることで、Salesforce Data 360 は次のことを実現します。

  • 取り込み、ハーモナイゼーション、有効化にわたって一貫したポリシーを適用します。
  • データ、ロール、コンプライアンスのニーズに応じて進化する適応型ガバナンス。
  • 取り込みからAIの有効化まで、データ ライフサイクル全体にわたる統合されたTrust Border。

Salesforce Data 360 のガバナンスモデルは Salesforce Platform 内にネイティブに組み込まれており、運用データと分析データの両方にわたって統合されたセキュリティ、コンプライアンス、およびアクセス制御を実現します。SalesforceのコアIDおよびアクセス管理機能(IDフェデレーション、権限セット、一元化されたポリシー作成、プラットフォーム暗号化など)を継承することで、Data 360は並列ガバナンス スタックを導入することなく、一貫したTrustポリシーをクラウド全体に適用します。プラットフォームでは、分離、承認、系統を個別の懸念事項として処理するのではなく、データ ライフサイクル全体にわたる単一の実行対応Trustファブリックに統合します。 構造レベルでは、このガバナンス ファブリックは、3 つの補完レイヤーが連携して機能することで形成されます。

  • データスペース: データの分離と規制区分のための明確な論理境界を確立
  • 属性ベースアクセス制御 (ABAC)。ID、目的、データ属性に基づいて、コンテキストに応じたきめ細かな承認判断が可能
  • セマンティックな系統: データの取り込みからインサイトおよび有効化への移行時に、ビジネス上の意味、機密性、トレーサビリティを維持します。 これらを組み合わせることで、アクセスの決定が説明可能で、適用が自動的に行われ、コンプライアンスが遡及的ではなく継続的であるガバナンスモデルが作成されます。その結果、ガバナンスが制限要因や後付けではなくなるプラットフォームが実現します。代わりに、有効化レイヤーになり、アーキテクトは、Trust、プライバシー、規制の要件がシステム自体によって確実に適用されるようにデータ製品とAI主導のワークフローを設計できます。 この構成的アプローチにより、透明性、セキュリティ、制御を犠牲にすることなく、大規模でインサイト、有効化、自動化をサポートすることで、エンタープライズデータを使用できるだけでなく、責任をもってアクションを実行できるようになります。

AI 主導の企業の時代では、データの保護は 1 回限りのイベントではなく、情報がエコシステムに入った瞬間からビジネスや AI で使用するために有効化されるまで情報を保護する継続的なプロセスです。 Salesforce Data 360は、データ ライフサイクルのすべてのフェーズにセキュリティとガバナンスの制御を組み込み、取り込みからインサイトの有効化までデータの整合性、機密性、Trustが維持されるようにします。

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 と EKM を基盤とする Data 360 では、顧客が独自の鍵素材を Salesforce 内に直接アップロードして、保存データと検索インデックスを暗号化できるようになりました。この機能強化により、顧客が AWS KMS で鍵を作成または管理しなくても、PII、機密データ、機密データ、専有データの保護が強化されます。
  • **鍵の循環とライフサイクル管理:**キーの循環は適切に処理されます。新しいデータは新しい鍵で暗号化され、古いデータは元の鍵で暗号化されたままであるため、ダウンタイムやパフォーマンスの低下を回避できます。この循環メカニズムにより、業務を中断することなくコンプライアンスを強化できます。

Data 360 サービス、API、コネクタ間で転送されるすべてのデータは、トランスポート層セキュリティ (TLS) 1.2 以上を使用して保護され、移動中のエンドツーエンドの暗号化が提供されます。 これにより、次のことが保証されます。

  • 転送中にデータを傍受または変更することはできません。
  • Salesforce サービス、信頼済みコネクタ、および顧客エンドポイント間の通信は非公開で検証可能です。
  • セキュリティは、取り込みパイプライン、ハーモナイゼーション プロセス、有効化ワークフロー、外部APIインテグレーションにわたって一貫して拡張されます。 Salesforce Data 360 は、顧客が管理する保存時の暗号化と転送中の継続的な暗号化を組み合わせることで、外部攻撃と内部インフラストラクチャの脅威の両方から顧客データを保護する多層防御アーキテクチャを構築します。

暗号化とアクセス制御により Salesforce Data 360 内のデータは保護されますが、システム全体でのデータ移動の保護も同様に重要です。最新の企業は、Salesforce、分析プラットフォーム、外部 API、データレイク間で機密データが流れるマルチクラウドおよびハイブリッド環境で運用されています。 これに対応するために、SalesforceはNC(指定ログイン情報)とEC(外部ログイン情報)を中心とした安全な統合フレームワークを設計し、安全な接続のためのポリシー ベースのゼロ トラスト連携基盤を提供しています。

Salesforceは、NC(指定ログイン情報)とEC(外部ログイン情報)を中心とした堅牢な**安全な統合フレームワークを構築しています。これらを組み合わせることで、コードや設定の秘密を公開することなく、ログイン情報の複雑さを抽象化し、最小限の権限でのアクセスを適用し、すべてのインテグレーションで一貫した認証管理が可能になります。 このフレームワークは、セキュリティの複雑さを抽象化し、ベスト プラクティスを適用して、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 はさまざまなインテグレーションプロトコルを安全にサポートしながら、企業全体で一貫した一元的なログイン情報管理を維持できます。

Data 360 のユーザーインターフェースは基礎となる設定の多くを抽象化しますが、指定ログイン情報と外部ログイン情報フレームワークは、内部的にはネイティブコネクタとデータストリームによって頻繁に使用されます。つまり、管理者がガイド付き UI を使用して単に「データ接続を追加」している場合でも、Data 360 はバックグラウンドでこの標準化されたセキュリティモデルを適用します。 アーキテクチャ上の影響:

  • **統合セキュリティモデル:**外部データベース 、AWS S3、エンタープライズ API のいずれのコネクタでも、指定ログイン情報と外部ログイン情報で適用される同じ暗号化、認証、鍵管理標準を利用できます。
  • **開発者の抽象化:**開発者とシステム管理者は、認証フローやログイン情報の循環を手動で処理する必要はありません。Salesforce はトークンのライフサイクル、有効期限、更新を自動的に管理します。
  • **一貫したポリシーの適用:**このフレームワークにより、すべてのコネクタで一貫した認証、監査、ログポリシーが遵守されます。これは、規制対象の業界での大規模なマルチソース取り込みに不可欠です。
  • **将来を見据えた拡張性:**Salesforce が認証スタックを強化すると (たとえば、新しい OAuth フローや FIDO2 標準をサポートするため)、リファクタリングや再リリースを行うことなく、これらの改善が自動的にすべてのコネクタに反映されます。

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 内に保存されているデータのセキュリティは、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 認証と堅牢なガバナンスポリシーによって管理されます。

データ ライフサイクルの最後のフェーズである_データの有効化_では、Salesforce Data 360内の統合および強化された顧客プロファイルが、パーソナライズされたマーケティング、分析、エンゲージメント オーケストレーションなどのダウンストリーム アプリケーション用に外部システムに安全に配信されます。 このフェーズは_、インサイト_から_アクション_への移行を表します。そのため、データの整合性、プライバシーのコンプライアンス、Trustの維持に最も責任があります。

送信データ転送の保護

Data 360 は、管理された暗号化されたパスを介して安全なアウトバウンド接続を適用します。すべての有効化対象 (SFTP、Amazon S3、Microsoft Azure Blob、Google Cloud Storage、広告ネットワークなど) は、Salesforce の指定ログイン情報と外部ログイン情報フレームワークを介して認証される安全な接続定義を使用して設定し、ログイン情報やエンドポイントがプレーンテキストで公開されないようにする必要があります。 アーキテクチャのセキュリティ管理:

  • **暗号化されたチャネル:**すべての送信データ転送は TLS で暗号化されたチャネルを介して行われるため、転送中の機密性と整合性が確保されます。
  • **認証情報の抽象化:**送信エンドポイントでは指定ログイン情報が使用され、Salesforce の暗号化された秘密ストアと、すべての API キーと認証トークンの一元管理が活用されます。 これにより、設定ファイルやフロー定義の機密情報が公開されないようにします。
  • **アクセスガバナンス:**有効化対象は、範囲設定済み権限を持つ特定のインテグレーションユーザーにバインドできるため、送信イベントの詳細なアクセス制御と完全な監査が可能になります。
  • **ネットワークセキュリティ:**高セキュリティ環境では、送信接続をプライベートコネクトリンクに制限して、データ有効化トラフィックが公開インターネットを通過するのではなく、プライベート AWS または Azure ネットワーク内に保持されるようにします。
Data 360 有効化フロー
フェーズ メカニズム セキュリティ/ガバナンス管理
アクティベーション設定 Data 360 有効化設定で定義 指定ログイン情報と外部ログイン情報による保護
データの準備 DMO からの絞り込みと結合 適用される同意およびプライバシーメタデータ
アウトバウンド転送 TLS/プライベートコネクトで暗号化 ポリシーの適用とログイン情報の抽象化
外部配信 SFTP / クラウドストレージ / API アクセス制御された監査可能な配信

Data 360 のセキュリティは、技術的な制御だけでなく、ポリシー対応ガバナンスにまで拡張されています。有効化の瞬間、SalesforceのData 360 Trust Layerによって、お客様の同意とプライバシーポリシーが自動的に適用され、対象データのみが外部のデスティネーションと共有されます。 主な機能:

  • 同意対応データフロー 360 では、データが有効化される前に「共有不可」、「販売不可」、「メールオプトアウト」などの同意フラグが評価されます。これらの同意条件に違反するレコードは、送信データセットから自動的に除外されます。
  • 規制の調整:これらのポリシー適用は、GDPR、CCPA、HIPAA などのグローバルプライバシーフレームワークに準拠しており、コンプライアンスを下流の適用に依存するのではなく、データ有効化プロセスに直接組み込みます。
  • 自動系統設定および監査:各送信有効化イベントは、ソース DMO、同意状況、送信先の詳細を含む完全なデータ系統メタデータで記録されます。これにより、規制当局や内部ガバナンスチームの監査に対応したレポートを作成できます。 Salesforce Data 360 には、取り込みから保存、インテグレーション、有効化まで、データライフサイクル全体にわたってセキュリティ、ガバナンス、プライバシーコントロールが組み込まれており、すべてのフェーズで顧客データの暗号化、ポリシーへの準拠、信頼性が維持されます。プラットフォームの暗号化、指定ログイン情報および外部ログイン情報、同意認識の有効化を統合することで、Data 360は、ソースからビジネスの有効化までデータの整合性、機密性、コンプライアンスを保護するエンドツーエンドのZero Trustアーキテクチャを提供します。

セキュリティ意識の高い多くの企業 (特に規制の厳しい業界や公共セクター) にとって、インターネットが制限されたデータ環境はコンプライアンスとサイバーセキュリティ戦略のコアコンポーネントです。このような分離により、外部への漏洩を最小限に抑えることができますが、お客様が管理するデータ レイクへの安全なアクセスを必要とするSalesforce Data 360とAgentforceの統合の課題も発生します。 ほとんどのエンタープライズデータレイクは、AWS、Microsoft Azure、Google Cloud などのハイパースケーラープラットフォームにあります。Salesforce Data 360 は AWS インフラストラクチャで動作するため、他のクラウドでホストされている顧客環境に安全に接続するには、パブリックインターネットをバイパスする非公開のクロスクラウドネットワークパスが必要です。

Data 360は、AWS PrivateLinkを介してプライベートのクラウド内接続を提供し、トラフィックを公開インターネットに公開することなく、Data 360とお客様が管理するデータソース(Snowflake(AWSでホストされている)、Redshift、S3などのサービス)間の安全な直接アクセスを可能にします。 Data 360 プライベートリンク接続 すべての通信は、プライベート 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 はクロスクラウドリンクをプロビジョニングして管理し、すぐに設定できるように顧客の対象クラウド環境にプライベートサービスエンドポイントを公開します。

エンタープライズデータを統合する強力なプラットフォームである Salesforce Data 360 は、堅牢な多層セキュリティ制御で構築されています。顧客にとって、API セキュリティの管理は包括的なデータ保護戦略の重要な部分であり、アクセスの制御、インテグレーションの管理、使用状況の監視を効果的に行うことができます。 Salesforce Data 360 内で 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) Authenticatorやその他のMFAソリューションを適用して、重要なセキュリティ レイヤーを追加し、検証済みのユーザーのみがAPIログインを使用してシステムにアクセスできるようにします。
2.詳細なアクセス制御と権限

顧客は、データにアクセスできるユーザーとアプリケーション、および実行できるアクションを詳細に制御できます。

  • API アクセスコントロール (機能) サポートによって有効化されると、管理者は API へのアクセスに使用できる接続アプリケーションを明示的に承認できます。未承認のアプリケーションはすべて自動的にブロックされるため、不正なデータ抽出のリスクが大幅に軽減されます。
  • 権限セットとプロファイル:システム管理者は、ユーザープロファイルまたは専用の権限セットを使用して「API の有効化」権限を割り当てることで、API アクセスを管理します。これにより、ユーザーは職務に関連するアクセス権のみを持つことができます。
  • ロールベースのアクセス制御 (RBAC) 360 内で、ユーザーはロールベースのアクセス制御ポリシーを作成して管理し、データアクセスレベル (オブジェクト、項目、レコードレベルセキュリティ) を定義できるため、プラットフォーム全体の一貫性と制御を確保できます。
  • 専用のインテグレーションユーザー:ベストプラクティスとして、インテグレーション用に特定の「API 限定」ユーザーを作成し、システム管理者アカウントを使用するのではなく、API コールに必要な権限のみに制限することをお勧めします。
3.ネットワークセキュリティコントロール
  • IP ホワイトリスト/ログイン IP 範囲:顧客は、API アクセスを定義済みの信頼できる IP アドレスの範囲に制限できます。未承認の IP アドレス範囲からのログイン試行は拒否されるか、検証が促される可能性があります。
  • プライベートコネクト PrivateLink 上に構築されたこの機能により、管理者はエンドポイントを公開インターネットに公開することなく機密データを管理できるため、公開されているエンドポイントに対する攻撃のリスクを排除できます。
  • 転送中および保存中の暗号化:すべてのデータは転送中および保存中に暗号化され (TLS を使用)、傍受された場合でも機密情報が不正アクセスから保護されます。
4.監視、監査、ガバナンス

セキュリティにとって可視性は重要です。Salesforce には、API 活動を監視および監査するための広範なツールが用意されています。

  • イベント監視 コールやログイン試行など、さまざまなイベントをほぼリアルタイムで追跡します。顧客はこのデータを監査に使用し、トランザクションセキュリティポリシーを作成できます。
  • セキュリティセンター:この機能により、すべての Salesforce 組織のセキュリティの健全性、コンプライアンス、およびガバナンスの総計値を 1 つの統合されたビューで確認でき、監視と管理が簡素化されます。
  • Field Audit Trail:顧客がログイン履歴と項目履歴を追跡し、設定変更を監視して、監査とデータ保持のコンプライアンス義務に対処できるようにします。
  • データ ガバナンス機能:データのタギングと分類、ポリシーの適用、動的データマスキングが含まれ、API を使用してアクセスするものを含め、すべてのデータタッチポイントに一貫したガバナンスポリシーが適用されます。
  1. コアコントロールの有効化:まず、MFA や IP 制限などの組織の共有設定を有効にします。
  2. API アクセスコントロールの要求 サポートにケースを登録して、組織で「API アクセスコントロール」機能を有効にします。
  3. 接続アプリケーションの設定:インテグレーションごとに特定の接続アプリケーションを作成し、必要な OAuth 範囲を定義して、承認されたプロファイル/権限セットに割り当てます。
  4. 最小権限の実装:すべてのインテグレーションユーザーに「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はSalesforceプラットフォームの基盤であり、そのTrustは独立した検証によって獲得されます。Salesforce は、顧客データの保護と最高水準のクラウドセキュリティの維持に対する継続的な取り組みを示す、グローバルセキュリティ認定および証明の広範なポートフォリオを保持しています。 これらの認定は単なるチェックボックスではなく、Salesforce のセキュリティ制御、プロセス、インフラストラクチャの強度と一貫性を検証する厳格な定期的な監査を表します。これらが組み合わされて、Salesforce の基盤 Trust モデルのバックボーンが形成されます。 主な認定および証明は次のとおりです。

  • **ISO/IEC 27001:**Salesforce の包括的な情報セキュリティ管理システムを検証します。
  • **ISO/IEC 27017:**クラウド固有のセキュリティ制御のベストプラクティスを確立します。
  • **ISO/IEC 27018:**クラウドでの個人識別情報 (PII) の保護に焦点を当てています。
  • SOC 1、SOC 2、SOC 3Salesforce のセキュリティおよびプライバシー管理の設計と運用の有効性を確認する独立したレポート。
  • **PCI DSS:**支払カード情報を安全に処理および保存します。
  • **FedRAMP High & DoD Impact Level 4:**機密ワークロードを管理する米国連邦政府機関が使用するために Salesforce Government Cloud を認定します。 この包括的な認定セットを維持することで、Salesforce は、データがプラットフォーム内で管理され、グローバルなコンプライアンスとセキュリティの期待に応えている (そして多くの場合、それを上回る) という信頼性を顧客に提供します。

急速に変化する今日のデジタル環境では、顧客データを全方位から把握することも重要ですが、同様に重要なのは、そのデータを管理するプラットフォームを全方位から把握することです。Salesforce Data 360 には、堅牢なロギング、監視、オブザーバビリティ機能が組み込まれており、顧客はデータの品質、セキュリティ、パフォーマンスを確保できます。 これらのツールは、事後対応型の問題解決からプロアクティブな管理への移行を支援し、Data 360 実装をスムーズかつ効率的に実行します。

セキュリティは予防で終わりではなく、警戒しながら進化します。常に変化する脅威の状況では、Salesforce は高度なプラットフォーム監視機能と顧客が管理するレビュープロセスを組み合わせて、プロアクティブで継続的な保護を確保します。 Salesforce には、可視性と脅威検知のための強力なネイティブツールが用意されています。

  • 監査履歴の設定では、管理上の変更の完全な履歴が取得されるため、チームは設定やポリシーの更新を追跡できます。
  • イベント監視では、ユーザーの行動、APIアクティビティ、データ アクセス パターンに関する詳細なインサイトが提供されます。このテレメトリは、SIEM(セキュリティ情報およびイベント管理)ソリューションとシームレスに統合して、一元的な分析と関連づけを行うことができます。

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 などの一般的なサードパーティ監視ソリューションとのシームレスな統合を促進します。イベントモニタリングデータをこれらのプラットフォームにストリーミングまたはエクスポートして、技術スタック全体で監視することができます。

Data 360 実装のパフォーマンスを理解することは、優れたユーザーエクスペリエンスの鍵となります。

  • **Lightning Usageアプリケーション:**この組み込みアプリケーションでは、Lightning Experience の Data 360 ページのパフォーマンス評価指標 (ページ読み込み時間 (EPT) やブラウザーのパフォーマンスなど) の集計ビューが提供されます。
  • **カスタムレポートおよびダッシュボード:**Event Monitoring Plus という無料の CRM Analytics テンプレートアプリケーションの使用を含め、Data 360 オブジェクトとイベント監視データを使用してカスタムレポートとダッシュボードを作成できます。これらの視覚化により、トレンドを特定し、パフォーマンスのボトルネックをすばやく特定できます。 しかし、テクノロジーだけでは不十分です。真のレジリエンスを実現するには、自動検出と人によるレビューの連携が必要です。自動化されたアラートはリアルタイムで異常を示す可能性がありますが、多くの場合、有効なユーザーによる低速で不正なデータの持ち出しなど、微妙な脅威や長期的な脅威は、定期的な監査とトレンド分析によって特定できます。 Salesforce はテレメトリ、監査ログ、インテグレーションフックを提供します。顧客はプロセスの厳格さ、運用のケイデンス、コンテキスト固有のインテリジェンスを提供します。これらを組み合わせることで、多層防御モデルが形成されます。自動化、分析、手動監視を組み合わせて、インシデントになる前に脅威を検出、調査、対応します。

Salesforce Data 360 は、顧客データを統合するだけでなく、そのデータをインテリジェントでアクション可能なものにします。この価値提案の中核となるのは、堅牢なレポート、強力なダッシュボード、インサイトに富んだ評価指標、リアルタイム通知機能です。これらのツールを使用すると、使い慣れた Salesforce 環境内で、データの健全性の監視、パフォーマンスの追跡、統合データに基づくアクションの自動化をすべて行うことができます。

Salesforce のネイティブのレポートおよびダッシュボード機能は Data 360 にシームレスに拡張され、プラットフォームを離れることなく統合データを視覚化および分析できます。

さまざまなソースからの統合データや計算済みインサイトなど、Data 360 に保存されているデータに関する標準レポートとカスタムレポートを作成できます。

  • **標準およびカスタムレポートタイプ:**Data 360 では、データストリーム、セグメント、有効化、ID 解決、計算済みインサイトなど、Data 360 オブジェクト専用の新しいレポートタイプが導入されています。これにより、標準の Salesforce レポートビルダーを使用して統合データを照会できます。
  • **詳細分析:**レポートでは、最大 10 行のグルーピングがサポートされるため、顧客の属性とトレンドをより詳細にセグメンテーションして詳細に分析できます。
  • **数式と概要:**行レベルの数式と集計項目を活用して、各レコードまたはレコードグループを評価し、1 つのレポート内で詳細な総計値と集計の概要を追跡できます。

ダッシュボードでは、Data 360 実装全体の主要な総計値とトレンドが視覚的に表示されます。

  • **統合ビュー:**複数の Data 360 レポートのデータを統合したり、Data 360 レポートと標準 CRM レポートを 1 つのダッシュボードで混在させたりして、業務と顧客インサイトの全体像を把握できます。
  • **カスタマイズ可能なウィジェット:**さまざまな種類のグラフ (棒グラフ、折れ線グラフ、円グラフ、ゲージグラフなど) とテーブルを使用して、レポートデータを効果的に表示します。
  • **リアルタイム・インサイト:**ダッシュボードを更新して最新情報を提供し、データ主導の迅速な意思決定を支援します。

Data 360 では、ビジネス目標に関連する重要業績評価指標 (KPI) を定義して追跡できます。これらは次の方法で生成できます。

  • **計算済みインサイト:**大量のバッチで処理されたデータを使用して、強力な評価指標を作成します。たとえば、「Average Customer Lifetime Value (平均顧客生涯価値)」や「Total Active Contract Revenue (有効な契約収益の合計)」などの総計値を計算し、レポートやダッシュボードでディメンションや基準として使用します。
  • **ストリーミングインサイト:**ストリーミングソースのデータをほぼリアルタイムで処理し、Web サイトやモバイルエンゲージメントデータなどの時系列集計を作成します。これらの総計値は、すぐにオーケストレーションとデータアクションを促進できます。

Salesforce には、Data 360 内の重要なイベントやデータの変更を確実に把握するための強力な自動化機能と通知機能があります。

  • **フローベースの通知:**データストリーム、セグメント、有効化などの Data 360 オブジェクトのイベントに基づいてアクションをトリガーし、通知を送信するようにプロセスフローを設定できます。
  • **カスタムアラート:**メールをトリガーするか、特定の条件を満たしたときに Salesforce 通知ベルに表示されるカスタム通知を作成します。たとえば、データストリームが失敗した場合、ID 解決ルールでエラーが発生した場合、主要な指標が特定のしきい値を超えた場合にアラートを受信できます。
  • **イベント通知サービス (ENS):**開発者の場合、API ファーストイベント通知サービスを使用すると、特定のイベントが発生したときに外部システムで通知を受信できるため、技術スタック全体でシームレスなインテグレーションとリアルタイムの反応が可能になります。
  • **データアクション:**ストリーミングインサイトに基づいて、データアクションをトリガーできます。データアクションは、アラートの送信、プラットフォームイベントの呼び出し、Web フックを介した他の SaaS アプリケーションとの統合を行うように設定できます。 Salesforce Data 360 のお客様は、これらの包括的な機能を活用して、データエコシステムを効果的に監視し、主要な評価指標を視覚化して、タイムリーなアラートを受信し、プロアクティブなエンゲージメントと優れた運用性を実現できます。

Salesforce Data 360 をエンタープライズ規模で採用するには、技術的なイネーブルメント以上のものが必要です。慎重なセキュリティ優先のアーキテクチャが必要です。次の戦略的推奨事項は、CTOとエンタープライズ アーキテクトがData 360導入のすべてのレイヤーにTrust、耐障害性、コンプライアンスを構築するためのロードマップを提供します。

  • **「設計によるセキュリティ保護」アプローチの実装 :**セキュリティは、後付けではなく、基本にする必要があります。Salesforce のデフォルトの_「すべて拒否」_ポリシーから開始し、必要に応じてアクセス権を明示的に付与します。データを取得または有効化する前に、ガバナンス、ポリシー、アクセスフレームワークを定義します。初日からセキュリティを構築することで、隠れた情報漏洩のリスクを排除し、長期的なコンプライアンスを簡素化します。
  • **堅牢なIAM(Identity and Access Management)戦略の適用 ―**統合 SSO で ID を一元化し、多要素認証 (MFA) を適用してログイン情報のセキュリティ侵害を軽減します。ログイン IP アドレスの制限によってアクセスを制限し、Salesforce の ID プロバイダー (IdP) 機能を使用して、ユーザーおよびインテグレーション全体でエンドツーエンドの説明責任を確立します。統合された IAM レイヤーにより、運用の複雑さが軽減され、認証表面が強化されます。
  • **最小権限の原則の適用 ―**利便性ではなく精度のためにロールを設計します。Salesforce の標準権限セットを職務分掌の基盤として使用し、ユーザーが必要な情報にのみアクセスできるようにします。権限の過剰なカスタマイズを避ける — 逸脱が発生するたびに、メンテナンスオーバーヘッドが増加し、意図しないアクセスのリスクが高まります。
  • **多層データガバナンスフレームワークの確立:**データスペースを使用してビジネスユニットまたはブランド別にデータを分離し、オブジェクトレベル、項目レベル、レコードレベルセキュリティ (OLS、FLS、RLS) を使用して属性ベースのアクセス制御 (ABAC) を適用します。動的データマスキングを使用して、分析や操作性を損なうことなく、機密情報をリアルタイムで保護します。この階層化されたモデルにより、ドメイン間でデータの規模を拡大してもガバナンスの一貫性が維持されます。
  • **暗号化と安全なインテグレーションの戦略的な活用 :**機密ワークロードの場合、顧客が管理する鍵を使用したプラットフォームの暗号化 (CMK) をリリースして、暗号化ライフサイクルの主権を維持します。指定ログイン情報とプライベートコネクトを使用して、すべてのシステム間インテグレーションを保護します。これにより、ハードコードされた秘密が排除され、すべてのトラフィックが非公開、コンプライアンス、監査可能のままになります。
  • **継続的なセキュリティ・オペレーション・プログラムの構築:**セキュリティは設定だけで終わりではなく、運用の規律によって強化されます。イベントログとアクセス履歴の定期的な監査レビューで自動監視を補完します。異常の特定、脅威の調査、コンプライアンスの検証を行うための専用のセキュリティオペレーション (SecOps) 機能を確立します。目標は、早期発見、迅速な対応、姿勢の継続的な改善です。

安全でインテリジェントなエンタープライズへの移行は、導入で終わりではありません。導入は、規律、設計、Trustによって進化します。Salesforce Data 360 はアーキテクチャの基盤を提供しますが、真の価値は、組織がセキュリティ、ガバナンス、インテリジェンスを 1 つの統合された動きとして運用することで現れます。 企業は、Data 360を別のデータ プラットフォームとしてではなく、単一のガバナンス フレームワークでデータ、AI、カスタマー エンゲージメントを接続する安全で構成可能なTrustレイヤーとしてアプローチする必要があります。_セキュア バイ デザイン_の理念を採用し、すべてのレイヤーに最小限の権限を適用し、すべてのデータ フローにプライベート接続を拡張することで、組織はコンプライアンスをチェックボックスから競争優位性に変換します。 次のステップは、継続的なモダナイゼーションです。監査の自動化、ポリシーの適用、暗号化ライフサイクル管理を日常業務に組み込みます。企業がエージェント型の AI 駆動型アーキテクチャに進化するにつれ、現在のデータを保護する同じ原則が将来の AI ガバナンスのバックボーンを形成することになります。これにより、すべてのモデル、エージェント、意思決定が説明可能で、ポリシーを認識し、設計に従っているようになります。 最終的には、Trustがデジタル トランスフォーメーションの新しい通貨になります。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) イニシアチブを主導しながら、自動化プラットフォームプロビジョニングソリューションに貢献しています。