View a markdown version of this page

自然言語でのポリシーの記述 - Amazon Bedrock AgentCore
概要例ポリシーの効果認可セマンティクスポリシーの要素ポリシーの例条件構文条件の組み合わせ一般的な落とし穴

自然言語でのポリシーの記述

AgentCore のポリシーは、ポリシーオーサリングサービスを通じて行われた推論リクエストを処理するために、地理的な最適なリージョンを自動的に選択します。これにより、利用可能なコンピューティングリソース、モデルの可用性を最大化し、最高のカスタマーエクスペリエンスを実現できます。データはリクエストが発生したリージョンにのみ保存されますが、入力プロンプトと出力結果はそのリージョン外で処理される場合があります。すべてのデータは Amazon の安全なネットワーク経由で暗号化されて送信されます。

AgentCore のポリシーは、次のように、推論リクエストをリクエストが発生した地理的領域内の利用可能なコンピューティングリソースに安全に転送します。

  • 欧州連合を起点とする推論リクエストは、欧州連合内で処理されます。

  • 米国を起点とする推論リクエストは、米国内で処理されます。

  • APAC を起点とする推論リクエストは、APAC 内で処理されます。

概要

Cedar は正確なアクセスコントロールを提供しますが、正式な構文を学習する必要があります。NL2Cedar を使用すると、次のことが可能になります。

  1. 自然言語での書き込み認可要件

  2. Cedar 構文に自動的に変換する

  3. 生成されたポリシーが要件と一致することを確認する

注記

自然言語ポリシーの生成には、デプロイされた AgentCore Gateway とポリシーエンジンが必要です。このサービスは AgentCore Gateway スキーマを使用して有効な Cedar ポリシーを生成します。セットアップ手順については、AgentCore のポリシーの開始方法」を参照してください。

注記

自然言語には柔軟性がありますが、セキュリティには精度が不可欠です。ポリシーは明確であいまいでない必要があります。

例

前のセクションの返金ポリシーは、自然言語で表現できます。

自然言語:

返金額が 500 USD 未満の場合、ユーザー名が「refund-agent」のプリンシパルに返金の処理を許可します。

Cedar に変換します。

permit(
  principal is AgentCore::OAuthUser,
  action == AgentCore::Action::"RefundTool___process_refund",
  resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/refund-gateway"
)
when {
  principal.hasTag("username") &&
  principal.getTag("username") == "refund-agent" &&
  context.input.amount < 500
};

ポリシーの効果

認可ポリシーには、許可と禁止の 2 つの効果があります。

許可ポリシー

許可ポリシーは、ユーザーができることを指定します。

  • 「返金処理をユーザーに許可する」

  • 「決定を承認するロールディレクターを持つユーザーに許可する」

  • 「スコープが admin:write のユーザーにカバレッジの更新を許可する」

禁止ポリシー

禁止ポリシーは、ユーザーができないことを指定します。

  • 「機密性の高いモデルへのユーザーのアクセスをブロックする」

  • 「下級アンダーライターによる決定の承認を拒否する」

  • 「リスク検証が保留中の場合にユーザーに返金の処理を禁止する」

認可セマンティクス

Cedar がポリシーを評価する方法を理解することは、効果的な認可ルールを記述するために不可欠です。Cedar は 3 つの基本原則に従います。

  • デフォルトでは、すべてが拒否されます - アクションを明示的に許可するポリシーがない場合、自動的にブロックされます

  • Forbid always wins - 禁止ポリシーが一致した場合、許可ポリシーも一致してもアクセスは拒否されます

  • 少なくとも 1 つの許可が必要 - アクセスを許可するには、少なくとも 1 つの許可ポリシーが一致している必要があり、禁止ポリシーは一致できません

すべてデフォルトで拒否された場合に禁止ポリシーを使用するのはなぜですか?

禁止ポリシーは、特定のアクションを誤って許可しないようにします。より広範な許可ポリシーを記述した場合でも、禁止ポリシーが優先され、アクセスがブロックされます。

シナリオの例: 

// Broad permit policy - allows all users to view model results
permit(
  principal is AgentCore::OAuthUser,
  action == AgentCore::Action::"ModelAPI___view_results",
  resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/model"
);

// Forbid policy - blocks access to high-sensitivity results
forbid(
  principal is AgentCore::OAuthUser,
  action == AgentCore::Action::"ModelAPI___view_results",
  resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/model"
)
when {
  context.input.sensitivity == "high"
};

結果: ユーザーは機密性の低い結果と中程度の結果を表示できますが (許可が適用されます）、機密性の高い結果は常にブロックされます (許可の禁止）。

禁止ポリシーは、次の目的で使用します。

  • 決して上書きしてはならない明示的なセキュリティ制限

  • コンプライアンス要件

  • 緊急シャットダウン

  • より広範な許可ポリシーに対する例外の作成

ポリシーの要素

認可ポリシーには、次の 3 つの主要な要素が必要です。

  1. 誰が - アクションを実行できるユーザーまたはロール

  2. 内容 - 使用できるオペレーションまたはツール

  3. When - 条件または制約

プリンシパル仕様

プリンシパルは、ポリシーが適用されるユーザー、ロール、またはグループを識別します。

柔軟な式:

  • 「ユーザーに返金エージェントを許可する」

  • 「ユーザー名の refund-agent をユーザーに許可する」

  • 「 Insurance-agent ロールを持つユーザーは...」

  • 「returns:write スコープを持つユーザーには、次の権限が付与されます。」

  • 「すべてのユーザーは...」

ID について具体的に説明します。

不完全: ❌ 「500 USD 未満の返金の処理を許可する」

完了: ✓ 「返金エージェントが 500 USD 未満の返金を処理することを許可する」

アクション仕様

「What」は、ポリシーが制御するオペレーション、ツール、またはアクションを識別します。

柔軟なアクション動詞:

  • 「返金の処理をユーザーに許可する」

  • 「返金処理を許可する」

  • 「ユーザーはアプリケーションを作成できます」

  • 「監査ログの表示を承認する」

ツールについて具体的に説明します。

あいまい：❌「ユーザーにモデルへのアクセスを許可する」

クリア: ✓ 「データサイエンスチームに分析モデルへのアクセスを許可する」

条件仕様

「When」は、ポリシーが適用される状況を指定します。

柔軟な条件式:

  • 「... 金額が 500 USD 未満の場合」

  • 「... リージョンが米国、CA、または英国の場合」

  • 「... 承認ステータスがapproved-by-manager」

  • 「... リスクスコアが送信された場合」

条件を正確に記述してください。

あいまい：❌「金額が妥当な場合に転送を許可する」

精度: ✓ 「金額が 10,000 USD 未満の場合に転送を許可する」

ポリシーの例

次の例は、明確なプリンシパル、アクション、条件を使用して自然言語ポリシーを構築する方法を示しています。

例 1: シンプルなユーザーベースのポリシー

金額が 500 USD 未満の場合に、返金処理をユーザーに許可します。

要素:

  • 対象者: ユーザー refund-agent

  • 内容: 返金の処理

  • 場合: 金額が 500 USD 未満

例 2: 複数の条件でロールベース

カバレッジタイプが責任または衝突であり、ポリシーがアクティブな場合に、ロール insurance-agent を持つユーザーにカバレッジの更新を許可します。

要素:

  • 誰が: ロール insurance-agent を持つユーザー

  • 内容: カバレッジの更新

  • 場合: カバレッジタイプが責任または衝突であり、かつポリシーがアクティブな場合

例 3: スコープベースのアクセス

リージョンが EU ではなく、製品が対象である場合に、スコープ travel:book を持つユーザーにフライト予約の作成を許可します。

要素:

  • 対象者: スコープ travel:book を持つユーザー

  • 内容: フライトの予約を作成する

  • 場合: リージョンが EU ではなく、製品が対象である場合

例 4: 制約のあるすべてのユーザー

データ機密性が低または中であり、結果タイプがリスクスコアである場合、すべてのユーザーにモデル結果の表示を許可します。

要素:

  • 対象者: すべてのユーザー

  • 内容: モデルの結果を表示する

  • 場合: データ機密性が低または中であり、結果タイプがリスクスコア

条件構文

条件は、ポリシーがあいまいになることがよくあります。明確でテスト可能な条件を記述する方法は次のとおりです。

数値比較

良い例:

  • 「金額が 500 USD 未満の場合」

  • 「カバレッジ金額が 500 万未満の場合」

  • 「クレームが 10,000,000 USD を超える場合」

  • 「乗客数が正確に 2 の場合」

曖昧な用語は避けてください。

  • ❌ 「量が少ない場合」

  • ❌ 「カバレッジが高い場合」

文字列マッチング

完全一致:

  • 「リージョンが米国の場合」

  • 「支払い方法がクレジットカードの場合」

  • 「ステータスが承認されたとき」

複数のオプション:

  • 「リージョンが米国、CA、英国の場合」

  • 「決定タイプを承認または参照するとき」

パターンマッチング:

  • 「E メールに @example.com が含まれている場合」

  • 「スコープに admin:write が含まれている場合」

否定:

  • 「リージョンが EU でない場合」

  • 「分類が制限されていない場合」

ブール条件

直接チェック:

  • 「製品が対象となる場合」

  • 「リスクスコアが送信されるタイミング」

  • 「速達配送がリクエストされた場合」

否定:

  • 「製品が対象外の場合」

  • 「リスクスコアが送信されない場合」

フィールドの存在

必須フィールド:

  • 「理由が指定された場合」

  • 「アプリケーション ID が存在する場合」

  • 「返却日が指定されている場合」

条件の組み合わせ

実際のポリシーでは、多くの場合、複数の条件が必要です。クリア論理コネクタを使用します。

AND ロジック (すべて True である必要があります)

「and」、「also」、「additionally」、「while」、「with」などの単語を使用します。

例:

リージョンが米国で、製品が適格で、リージョンがアクティブである場合にアプリケーションを許可します。

OR ロジック (少なくとも 1 つは true である必要があります)

「or」、「alternatively」、「 either」などの単語を使用します。

例:

クレームが 10,000,000 USD を超える場合、またはリスクレベルが高いか重大である場合、承認を許可します。

複雑なロジック

複雑な条件の場合は、明確な構造を使用します。

例:

ワークフローステージがレビュー完了または承認され、コンプライアンスステータスが渡され、権限がマネージャーまたはディレクターである場合に、確定を許可します。

一般的な落とし穴

自然言語ポリシーを記述するときは、これらの一般的な間違いを避けて、Cedar 構文に正しく変換されるようにします。

間違い 1: 曖昧なプリンシパル

不良: 「返金ツールへのアクセスを許可」

良い: 「返金ツールへのアクセスをユーザーに許可する」

誤り 2: あいまいなアクション

悪い: 「データへのアクセスをユーザーに許可する」

良い: 「ユーザーに患者レコードの表示を許可する」

ミス 3: 主観的な条件

悪い: 「金額が妥当な場合に転送を許可する」

良い: 「金額が 10,000 USD 未満の場合に転送を許可する」

ミス 4: 条件が見つからない

不良: 「スコープが admin:write のユーザーにカバレッジの更新を許可する」

良い: 「ポリシーがアクティブで、カバレッジタイプが責任または衝突である場合に、スコープ admin:write を持つユーザーにカバレッジの更新を許可する」

誤り 5: 不明瞭なロジック

不良: 「A または B と C の場合に許可する」

良い: 「 (A または B) と C を許可する」または「A または (B および C) を許可する」