最小権限のコントロールを適用する
学習の目的
この単元を完了すると、次のことができるようになります。
- 最小権限の原則を定義する。
- ID、権限、ツール設計がどのように連携して、ヘッドレスアクセスを制限するのか説明する。
- エージェントのアクセスや機能を制限できる領域を見極める。
前の単元では、ヘッドレスサーフェスを利用しても、Salesforce のセキュリティを回避できるわけではないことを学びました。最小権限の原則を併用すれば、セキュリティ保護がさらに強化されます。
原則 2: 最小限のアクセス権から始める
最小権限の原則とは、それぞれのユーザー、アプリケーション、エージェントに、そのタスクの遂行に必要なアクセス権のみを付与し、それ以上は与えないことです。安全な設計の出発点は、「このユーザーが実務で必要となる最小限の権限またはアクセス権は何か?」と自問することです。 枝葉を剪定することで木が強くなるのと同様に、アクセスや権限を見直すことでヘッドレスアーキテクチャが強化されます。
ID:「誰か」を判断する
まず、ID を確認します。つまり、「誰が何をできるのか」を見極めます。この概念は、『2001 年宇宙の旅』という映画で描かれていました。HAL という AI が、Dave という人間のユーザーとやり取りをしています。Dave があるアクションを指示すると、HAL は有名なセリフを返します。「申し訳ありません、Dave。それはできないのです。」 人間が AI と音声でやり取りするこのヘッドレスエクスペリエンスの場面では、Dave の ID に基づいてアクションやアクセスを制限するように AI がプログラミングされていました。つまり、HAL が何にアクセスでき、Dave がどのデータを要求できるかは、司令官が決定していました。
AI を設計するときは、エンドユーザーが誰なのか、それが人間なのか別のシステムなのかを考慮します。ユーザーコンテキストに基づく設計では、エンドユーザーの Salesforce へのアクセス権を維持し、尊重することが重視されます。たとえば、2 人のサービス担当者が内部のエージェントに同じ質問をしても、レコードへのアクセス権が異なれば、受け取る結果も異なることがあります。インテグレーションユーザーに基づく設計では、専用のアカウントに割り当てられた権限が使用されます。たとえば、内部のあるエージェントが別のエージェントとやり取りする必要があるとします。エージェントごとに実行できる操作を制限するために、インテグレーションユーザー権限セットを使用するのが適切な場合があります。
機密性とアクセス
次に、データの機密性と、データアクセスによる潜在的な影響を分析します。データを影響度に応じて、低 (緑)、中 (黄)、高 (赤) に分類します。HAL が Dave の特定のアクションの実行を阻止したように、ユーザーごとに付与するアクセス権や実行できるアクションを決定します。たとえば、データを表示、作成、削除できるかどうかを決定します。
一般に、フルアクセス権を付与するのではなく、ユースケースに必要な機能のみを公開するようにします。たとえば、ある銀行では、サービスエージェントに対し、ケースの状況と優先度のみを返す参照のみの操作を公開しています。この銀行は、承認済みの機能から支払項目を除外するという方法で、API レイヤーで最小権限の原則を適用しています。この設計により、エージェントが悪意のある指示を受け取っても、機密データにアクセスすることができません。ここで、アクセス権と関連するアクションを決定する際のガイドラインをご紹介します。
- ユースケースでデータを変更する必要がない場合は、参照のみのアクセス権から開始する。
- タスクに必要なオブジェクト、項目、レコードのみを返す。
- 広範または漠然としたリクエストではなく、的を絞った具体的なクエリを実行する。
- 広範な編集権限を付与するのではなく、タスクに応じた明確で限定的なアクションを選ぶ。
- 参照のみの設計がテストされ、承認された場合にのみ、更新アクセス権を追加する。
監視とガードレール
上記の情報 (データの機密性、ID、アクセス権) に基づいて、アクションに応じたガバナンスコントロールを決定します。そのうえで、重大な影響を及ぼすアクションについては、意図的に制約や確認ステップを組み込みます。すべての更新アクションで、承認されたリクエスト実行者、変更の対象となる具体的なレコードや項目を明確に定義すると共に、有効な入力値も含める必要があります。さらに、設計で必要なビジネス条件、確認や承認の要否、リクエストの重複を防止する方法、可能な場合にアクションをログ記録、監視、取り消す方法を明示する必要があります。
段階的な権限の原則を適用し、アクションの潜在的な影響度に合わせて、制約や確認ステップを組み込みます。ユースケースによっては、エージェントが変更を行う必要のある場合があります。こうしたアクションは、参照操作よりも厳格な保護を必要とします。機密性に基づいて影響度を選択し、ID とアクセス権に応じたガバナンスルールを定め、最後に必要な監視を決定します。元に戻すことができない操作や機密性が高い領域については、承認済みの設計に強力な認証、独立した検証、復旧コントロールが組み込まれている場合を除き、エージェントがそうしたアクションを実行できないようにすることをお勧めします。
影響 | ガバナンス | 例 |
|---|---|---|
影響度: 低 |
| 口座残高の照会といった日常的なリクエストについては、アシスタントが参照のみのシンプルな情報を提示できます。複雑な技術的コマンドや追加権限は必要ありません。 |
影響度: 中 |
| 身に覚えのないクレジットカードの請求に関するお客様からの問い合わせなど、金融上の一般的な異議申し立てについては、アシスタントが取引の詳細を確認して解決策を提案します。ただし、人間の担当者がそのロジックを検討し、最終的なアクションを承認する必要があります。 |
影響度: 高 |
| お客様が利用限度額の大幅な引き上げを求めた場合など、機密性の高いリクエストについては、そのアクションで正式な承認フローがトリガーされ、処理を進める前にスーパーバイザーの承認が必要になります。 |
各フラッシュカードをクリックすると、それぞれの領域で確認すべき質問とベストプラクティスが表示されます。
反復的にテストする
各自のユースケースでアクセスを管理し、リスクを抑える方法を特定したら、次はテストして反復的に改善していきます。最小権限アクセスのテストとは、権限のないリクエストが適切に拒否されることを確認することです。テスト環境または Sandbox 環境で、実際的なユーザー権限を使用してこうしたテストを実行し、結果を記録して、必要なときに再テストできるようにします。テストは必ず実際のエンドユーザーの ID を使用して行います。管理者アカウントは使用しないでください。また、カスタム Apex コードでセキュリティコントロールが明示的に適用されていることを確認します (必要に応じてサポートを依頼してください)。Salesforce の権限は、システムから出力されるデータのみを対象とし、外部のサードパーティツールがそのデータをどのように使用するかは対象外です。ChatGPT をはじめとする外部のモデルやベンダーを含め、Salesforce 内外のデータのライフサイクル全体を評価することが重要です。Salesforce から必要最小限のデータのみを提供し、外部ベンダーのポリシーを分析して理解しておけば、システム間のデータの受け渡しに対する安心感を高めることができます。
次のステップ
この単元では、最小権限の原則を適用して、よりセキュアなヘッドレスエクスペリエンスを構築する方法を見てきました。適切なユーザーを特定する方法、機密性に基づいてデータを分類する方法、各タスクの影響度に応じて人間の監視レベルを設定し、段階的に権限を実装する方法を学習しました。アクセス範囲を限定し、スマートなガードレールを設けることで、AI エージェントの効率性を維持しながら、データを保護するための強固な基盤を築きました。次の単元に進み、ヘッドレスアクティビティの監視、潜在的な問題の調査、信頼性が変化した場合のセキュリティの管理について詳しく見ていきましょう。