アイデンティティとアクセスを超えて:現代のSalesforceエコシステムにおける信頼の理解

長年にわたり、Salesforceのセキュリティ対策といえば、主に次のようなおなじみの質問に答えることが中心でした: 誰がアクセス権を持っていますか? そのユーザーにはどのような権限がありますか?

アイデンティティおよびアクセス管理は、今なお Salesforce セキュリティにおける最も重要な基礎の 1 つであり、これらの問いの重要性が揺らぐことはありません。

しかし、Salesforce は進化を遂げてきました。

現代の Salesforce 環境は、Web ブラウザを介して操作する人間のユーザーだけで構成されているわけではありません。現在のビジネスワークフローには、人と並んで協働する AI エージェント、自動化プロセス、API、各種連携機能、外部アプリケーション、接続されたプラットフォームが不可欠となっています。組織が Agentforce、Headless Toolkit、および AI 補助によるビジネスプロセスの導入を進める中で、信頼を行使するのは人間のユーザーだけではなくなりました。

現代における課題は、「誰が Salesforce にアクセスでき、何をすることが許可されているか」を判別することだけにとどまりません。組織は現在、何が信頼されているのか、その信頼がどのように確立され、接続されたシステム全体にどのように拡張され、最終的にビジネスの成果にどのような影響を与えるのかを深く理解する必要があります。

信頼とは何か?

信頼については、認証や認可と並んで議論されることが少なくありません。

ユーザーが認証され、アプリケーションが認可され、OAuth 接続が承認され、権限セットが割り当てられます。

これらはいずれも重要なセキュリティコントロールですが、それ自体が信頼そのものを意味するわけではありません。

信頼とは、人、システム、情報、および接続されたサービスが予期した通りに動作し、ビジネスワークフロー内で頼りにできるという確信のことです。

サポート担当者が顧客情報に依拠する場合でも、連携機能が API を介してデータを交換する場合でも、あるいは AI アシスタントが Salesforce レコードを要約する場合でも、それぞれがこの信頼の上に成り立っています。

信頼関係

信頼関係は、ビジネスワークフローの一部が、意図通りに動作または機能することを参加者、システム、サービス、コントロール、または情報源に依拠している場合に常に存在します。その依拠は、アイデンティティ、情報、権限、セキュリティ、あるいはビジネスプロセスの正しい実行に関連する場合があります。

  • Salesforce はユーザーを正確に認証するために Microsoft Entra ID に依拠しています。
  • カスタマーサービス担当者は、正確な推奨事項を生成するために Agentforce に依拠しています。
  • Agentforce は、完全かつ最新の顧客情報を提供するために Data Cloud に依拠しています。
  • 顧客は、アップロードされたドキュメントを安全に取り扱うために Experience Cloud に依拠しています。
  • 組織は、本来のビジネス目的のためだけに Salesforce へアクセスすることを承認された連携機能に依拠しています。

信頼関係の構造

信頼関係とは、単に「何かに依拠できるかどうか」を決定すること以上の意味を持ちます。また、それに対して何を期待するか、その依拠が適用されるコンテキスト(文脈)、およびその関係の境界を定義するものでもあります。

責任は何に依拠しているかを定義し、スコープはその信頼がどこに適用されるかを定義し、境界はその制限を定義します。これらが一体となって、信頼関係がどのように動作すべきかを記述する一貫した方法を提供します。

例:

  • 信頼関係: サポート担当者が Agentforce に依拠する。
  • 責任: 顧客への回答案を作成する。
  • スコープ: 顧客サポートのケースのみ。
  • 境界: 顧客に対して直接回答を送信してはならない。

ワークフローやテクノロジーが進化するにつれて、信頼関係の動作方法も変化する可能性があります。ガバナンスは、その信頼関係が本来のビジネス目的を今も反映しているか、あるいは変更もしくは撤回すべきかを判断するのに役立ちます。

信頼関係は前提条件の上に成り立っている

すべての信頼関係は、1 つ以上の前提条件によって支えられています。これらの前提条件には、ユーザーが善意で行動すること、情報が正確であり続けること、連携機能が予期した通りに動作すること、AI システムが目的を適切に解釈すること、そして接続されたサービスが意図された境界内で動作することが含まれます。

従来の人間中心の環境では、これらの前提条件の多くは暗黙の了解として維持されていました。なぜなら、人間は予期せぬ挙動に疑問を持ち、状況の変化に適応し、文脈に応じた判断を下すことができるからです。自律型システムに多くの業務が委任されるようになるにつれ、テクノロジー、ワークフロー、およびビジネス目標が変化した際に評価できるよう、重要な前提条件を明確に定義する必要性が増しています。

簡単な例えで考えてみましょう。

休暇中に留守にする間、信頼できる隣人に予備の鍵を渡すと想像してください。物理的な鍵は単なるアクセスの手段に過ぎません。

信頼関係は、合意した通りに留守中の自宅を見守ってくれると隣人に依拠したときに確立されます。

責任は、観葉植物に水を与え、郵便物を回収し、その後に玄関の鍵を締めることです。

スコープは、あなたが休暇で留守にしている間、かつ自宅の手入れのためのみです。

境界は、他の目的で鍵を使用したり、あなたの許可なく世帯外の第三者に鍵を渡したりしてはならないということです。

この信頼関係は、いくつかの前提条件に依存しています。たとえば、隣人が鍵を複製しないこと、自分の世帯以外の第三者に渡さないこと、自宅の手入れ以外の目的で使用しないことなどを前提としています。

ここで、隣人が最近あなたに無断で鍵の複製を作成して別の隣人に渡していたこと、あるいは鍵が盗まれていたことが判明したと想像してください。

取り決めの当初の条件自体は変わっていませんが、あなたが入手できる情報が変わりました。何が起きたかを知ることで、信頼関係を支えていた前提条件の 1 つ以上に疑問を投げかける新たな証拠が得られたことになります。

結果として、あなたは鍵を回収する、鍵を交換する、あるいは代わりに別の人にアクセス権を与えるといった決定を下すことになります。

同じ原則がデジタルシステムにも当てはまります。認証情報が盗まれたり、連携機能が侵害されたりした場合でも、「認可された参加者のみが機密情報にアクセスすべきである」という根本的な期待は変わっていません。そうではなく、そのインシデントによって、信頼関係を支えていた前提条件を揺るがす新たな証拠がもたらされたのです。したがって、ガバナンスによってアクセス権を取消し、認証情報をローテーションし、権限を厳格化し、検証を追加し、あるいは新たなガードレールを導入することになります。

信頼の確立

信頼は、人、システム、サービス、コントロール、または情報源がビジネスワークフロー内で頼りにされたときに確立されます。

接続アプリケーションを承認する、連携機能に Salesforce へのアクセス権を付与する、ユーザーに権限を割り当てる、あるいは特定タスクの実行を AI エージェントに許可するなど、明確な決定によって信頼が確立される場合もあります。その他のケースでは、ビジネスプロセス、契約上の合意、組織のポリシー、または長年の運用慣行を通じて、より暗黙的に信頼が確立されます。

例:

  • 顧客レコードを同期するために接続アプリケーションが承認される。
  • 顧客への回答案を作成するために AI エージェントが認可される。
  • サードパーティの連携機能が Salesforce と情報を交換することが許可される。
  • 顧客が Experience Cloud を通じてサポートリクエストを送信することが許可される。

一度確立された信頼関係は、参加者の責任、スコープ、および境界を定義します。それらの特性は、ワークフローが変化した際に信頼関係を評価するための基準となります。

信頼の継承

信頼が元の関係内だけに留まることは滅多にありません。そうではなく、接続されたシステム、サービス、およびビジネスワークフローを通じて自然に拡張していきます。

先ほどの隣人の例えをもう一度考えてみましょう。

あなたは留守中、隣人に予備の鍵を託して信頼しました。もしその隣人が同じ鍵を使って配偶者に水やりを頼んだ場合、あなたの信頼は当初の関係を超えて拡張したことになります。あなたは隣人の配偶者を直接信頼したわけではありません。代わりに、あなたの信頼は元々隣人と確立した関係を通じて拡張(継承)されたのです。

これが信頼の継承です。

現代のビジネスワークフローも同様のパターンを示します。

Agentforce が Data Cloud から顧客情報を取得する際、その推奨事項の品質と正確性は Data Cloud 自体だけでなく、その情報を生成した上流のシステム、連携機能、およびビジネスプロセスにも依存します。したがって、Agentforce のワークフローはそれらの上流の参加者から継承された信頼に依存していることになります。

このパターンは AI ワークフローに限ったものではありません。アイデンティティプロバイダー、OAuth 認可、API、サードパーティ連携、接続サービス、およびソフトウェアサプライチェーンを通じて信頼が拡張するすべての場所で見られます。たとえば、パッケージリポジトリ、ソフトウェアパブリッシャー、またはビルドパイプラインに置かれた信頼は、下流のシステムやワークフローによって継承される可能性があります。

継承された信頼は、既存の関係の影響を新しい参加者、情報、システム、またはワークフローへと拡張します。各拡張を個別に見た場合、これらの依存関係は明確ではないかもしれません。時間を経るにつれて、組織は、元々の信頼が確立された際には意識して検討されなかった信頼関係に、システムやワークフローが依存していることに気付く場合があります。

信頼がますます緊密に接続されるエコシステム全体へと拡張する中で、組織は単に信頼がどこで最初につくられたかを理解するだけでなく、継承された信頼関係を可視化できるよう努めるべきです。

信頼の行使

信頼は行動を通じて行使されます。API リクエスト、AI による推奨事項、自動化されたワークフロー、顧客とのインタラクション、およびビジネス上の意思決定はすべて、信頼関係を行使し、実際のビジネス成果に影響を与える可能性があります。

例:

  • AI エージェントが顧客のリクエストを自動的に承認する。
  • 人によるレビューなしで、自動化プロセスが数百件のレコードを更新する。
  • 連携機能が別のプラットフォームと顧客情報を同期する。
  • サポート担当者が AI によって生成された推奨事項に基づいて回答を送信する。

これらの信頼関係は、ワークフローの初期段階で確立された前提条件に依存しています。それらの前提条件が有効であり続ける限り、信頼によって組織は効率的に運用を行い、業務を自動化し、人とテクノロジーにわたるコラボレーションをスケールさせることができます。しかし、前提条件が成り立たなくなった場合、信頼はまったく同じ効率の良さで意図しない結果を生み出す可能性があります。

AI エージェントは、操作された情報に基づいて、自信を持って誤った推奨事項を生成してしまう可能性があります。侵害された連携機能が、正当な OAuth 権限を持ったまま動作し続ける可能性があります。自動化されたワークフローは、送信されたすべての情報は安全に使用できると前提しているため、悪意のある顧客コンテンツをそのまま処理してしまう可能性があります。

これらの例では、信頼関係を支える前提条件が成立しなくなっているにもかかわらず、ワークフローは設計通りに動作し続ける可能性があります。正しく実行されたからといって、その結果が得られた成果として適切であり続けるとは限りません。

また、隣人の予備の鍵を使用するたびに「当初の取り決めがまだ有効かどうか」についての新しい情報が得られるのと同様に、それぞれの実行処理は、信頼関係を支える前提条件を強化または揺るがす証拠を提供することになります。

これらを総合することで、ビジネスワークフロー全体で信頼がどのように定義され、支えられ、拡張され、行使されるかを記述することができます。

なぜこれが重要なのか

近年の Salesforce におけるセキュリティインシデントは、ビジネスワークフローを侵害するために、必ずしも Salesforce 自体の脆弱性を攻撃する必要はないことを示しています。代わりに、攻撃者は委任された権限、侵害された連携機能、接続アプリケーション、信頼されたサードパーティ、あるいはソーシャルエンジニアリングを介して信頼関係を標的にし、目的を達成するケースが増えています。

関与しているアイデンティティは正当かもしれません。権限も正確に割り当てられているかもしれません。API も完全に設計通り機能しているかもしれません。しかし、それらの信頼関係が行使される方法が、もはや組織の意図と合致していない可能性があるのです。

これこそが、現代の Salesforce チームが直面している課題です。

アイデンティティは「誰が、または何が参加しているか」を確立するのに役立ち、アクセス権は「何をすることが許可されているか」を定義します。しかし、どちらか一方だけでは、ビジネスワークフロー全体で依拠がどのように機能しているか、あるいはその中で信頼がどのように確立され、継承され、行使されているかを説明することはできません。

信頼の可視化

信頼が存在することを認識することは、最初のステップに過ぎません。次の課題は、それらの信頼関係を可視化することです。

アーキテクチャ図やセキュリティインベントリは、システム、アイデンティティ、権限、連携機能、およびその他のコンポーネントについての有用な可視性を提供します。しかし、あるテクノロジーが存在していることを知っているだけでは、ビジネスがそれにどのように依拠しているかを説明できるとは限りません。

AI アシスタント、連携機能、またはアプリケーションが特定のタスクのために作成され、適切に管理されている場合であっても、それらを取り巻くワークフローは、テクノロジー単体では捉えきれない特定の情報、前提条件、境界、および期待される成果に依存している可能性があります。

トラストマッピングは、人、システム、情報、およびサービス間の依拠関係と、それらの関係を支える前提条件を明確にすることで、このワークフローのコンテキストを付け加えます。

次の記事では、Salesforce ビジネスワークフロー全体の信頼関係を発見し、それらを支える前提条件を表面化させ、効果的なトラストガバナンスの基礎を提供する体系的なアプローチである「トラストマッピングフレームワーク」についてご紹介します。