翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# 一時ポリシーの例
このセクションのポリシーは、同じセッションの前半ですでに何が起こったかを決定します。これにより、支払いの前に承認を要求したり、古いアクセス許可を期限切れにしたり、実行合計の上限を設定したり、失敗後にアクションをブロックしたりできます。これらのいずれかを決定するのに十分な情報が 1 つのリクエストに保持されることはありません。
すべての例では、[例のリソース設定で説明されているリファレンスゲートウェイを承認します](example-policies-reference.md)。テンポラルイベントスキーマ、演算子、セッション IDs、クォータ、リージョンの可用性については、[「テンポラルポリシー](policy-temporal.md)」と[「テンポラルポリシーの作成](policy-temporal-authoring.md)」を参照してください。
## これらの例を使用する前に
一時的なポリシーが期待どおりに動作するかどうかは、4 つの点によって決まります。
**セッション ID が必要です**
一時履歴は、名前を付けたセッションに限定されます。最初のリクエストから始まるすべてのリクエストで、 `x-amzn-bedrock-agentcore-policy-session-id`ヘッダーにセッション ID を送信します。ゲートウェイは生成せず、エンジンが一時ポリシーを保持している場合、セッション ID のないリクエストは検証に失敗します。
**許可されたアクションのみが`response`イベントになります**
アクションは、ポリシーが許可して完了した場合にのみ`response`イベントを記録します。拒否アクションは代わりに`error`イベントを記録します。したがって、次の各例では、`permit`前提条件アクションにもプレーンが必要です。そうしないと、前提条件は拒否され、 として記録されず`response`、一時的な条件は一致しません。すべての例では、 がそれをペアリングすることを許可します。
** `eventResource: resource` は必須です**
すべての述語には`eventResource: resource`、一致したイベントをポリシーのスコープ内のリソースに結び付ける を含める必要があります。省略すると、 で拒否されます`temporal predicates do not constrain the matched event to the current request’s resource`。書き込む必要はありません`sessionId`。イベントスキーマは、すべての述語を現在のセッションにスコープします。
**順序付き比較には整数が必要で、等価性は必要ではない**
`temporal { }` ブロック内では、2 種類の比較で異なるタイプを使用できます。
+ **順序付け** — `<`、`⇐`、`>`、 `>=` — には両側`integer`に が必要です。でポリシーを作成すると、 `decimal`または `string`は拒否されます`comparison requires numeric operands on both sides`。
+ 等**価 — **`==`と `!=` — は、両側が同じタイプである限り、任意のタイプで機能します。これは相関関係が使用するものです。 `input.claimId`との照合は、サポートされている 2 つの文字列`context.input.claimId`を比較します。
したがって、一時ポリシーが**合計またはしきい値**に必要とする値を としてモデル化します`integer`。そのため、リファレンスゲートウェイは、これらの例が集計するツールの金額を整数のマイナーユニットで示しています。要約には同じ要件と独自のメッセージがあります。 `integer` には 要約`sum`が必要です。詳細については、[「条件のパラメータタイプ](example-policies-reference.md#example-policies-types)」を参照してください。
## 同じクレームに対して事前の承認が必要です
**目的:** セッションの前半で承認されたクレームに対してのみ支払いを許可するため、エージェントが作成したクレーム ID に対して支払いを行うことはできません。
`::response` 述語は、完了した と一致します`approve_claim`。を現在のリクエストの `output.claimId`と関連付けること`context.input.claimId`は、支払いをその特定の承認に結び付けるものです。相関関係がなければ、セッション内の承認によって請求に対する支払いが認可されます。
```
permit (
principal,
action == AgentCore::Action::"InsuranceAPI___disburse_payment",
resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance-gw-a1b2c3d4e5"
)
when temporal {
formerly within 1h AgentCore::Action::"InsuranceAPI___approve_claim"::response{
eventResource: resource,
output.claimId: context.input.claimId
}
};
```
**重要**
`output.*` フィールドは、ターゲットがツールの出力スキーマを宣言する場合にのみ`response`イベントに存在します。多くのターゲットはそうではありません。例えば、Lambda ターゲットは一般的に入力のみを宣言し、イベントには `eventPrincipal`、`eventResource`、`input.*`、`requestId`、および のみが含まれます`sessionId`。
イベントが宣言しないフィールドに名前を付けると、サービスはポリシーを拒否し、エラー**は**利用可能なものを一覧表示します。
```
predicate `AgentCore::Action::"MyTarget___verify_purchase"::response` mentions field
`output.orderId`, which is not declared on that event (declared fields: eventPrincipal,
eventResource, input.orderId, requestId, sessionId)
```
そのリストを使用して、関連付けることができる内容を確認します。出力フィールドが存在しない場合は、共有**入力**フィールドに関連付けます。 は、前のツールで何も返すことなく、2 `input.claimId: context.input.claimId` つの呼び出しを同じクレームに結び付けます。
この 2 つは同等ではないため、意図的に選択してください。入力相関は、前の呼び出しが**リクエスト**した内容と一致し、出力相関は**返した**内容と一致します。ルールが、前のツールが生成した値、つまり承認 ID、計算された量に依存している場合、出力相関のみが適用され、ターゲットは出力スキーマを宣言する必要があります。
これをプレーン許可と組み合わせると、承認が許可されて記録されます。
```
permit (
principal,
action == AgentCore::Action::"InsuranceAPI___approve_claim",
resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance-gw-a1b2c3d4e5"
);
```
| セッションのリクエストシーケンス | 決定 |
| --- | --- |
| `disburse_payment` 事前の承認なし | DENY |
| `approve_claim` クレームの場合は 、同じクレーム`disburse_payment`の場合は 。 | 許可 |
| `approve_claim` 1 つのクレームの場合は 、別のクレーム`disburse_payment`の場合は | DENY |
## 前提条件となるアクションを要求する
**目的:** 誰かがセッションでそのステータスを調べた後にのみ、クレームの承認を許可します。
一致とは、前提条件が**試行**されているだけで、成功していない`::request`ことを意味します。の許可とペアリングします`get_claim_status`。
```
permit (
principal,
action == AgentCore::Action::"InsuranceAPI___approve_claim",
resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance-gw-a1b2c3d4e5"
)
when temporal {
formerly within 5m AgentCore::Action::"InsuranceAPI___get_claim_status"::request{
eventResource: resource
}
};
```
## 最近、**成功**した前提条件が必要です
**目的:** 過去 5 分間にステータスルックアップ**が完了した**場合にのみ承認を許可し、古いルックアップはアクセス許可の付与を停止します。
前の例からの変更は `::response`の代わりに行われ`::request`、「試行されました」と「成功しました」の違いです。ウィンドウの長さは、成功に必要な最新の状態を設定します。成功すると、アクセス許可は前提条件が再度実行されるまで経過します。
```
permit (
principal,
action == AgentCore::Action::"InsuranceAPI___approve_claim",
resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance-gw-a1b2c3d4e5"
)
when temporal {
formerly within 5m AgentCore::Action::"InsuranceAPI___get_claim_status"::response{
eventResource: resource
}
};
```
| セッションのリクエストシーケンス | 決定 |
| --- | --- |
| `approve_claim` 完了したルックアップの前に | DENY |
| ルックアップが完了し、ウィンドウ`approve_claim`内 | 許可 |
| `approve_claim` ウィンドウが経過した後 | DENY |
## アクションが実行される回数の上限
**目的:** セッションの 5 分間の範囲で、最大 3 つの支払いを許可します。
`count` は、承認されているリクエストを含む一致するイベントをウィンドウにカウントするため、ウィンドウの 4 番目の呼び出しが最初に拒否されます。`exists (n: Long)` アグリゲートはカウントをキャプチャするため、`n > 3`フィルターでテストできます。集計には の左側に括弧が必要です`==`。の許可と組み合わせると、`disburse_payment`呼び出しは制限まで許可されます。
```
forbid (
principal,
action == AgentCore::Action::"InsuranceAPI___disburse_payment",
resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance-gw-a1b2c3d4e5"
)
when temporal {
exists (n: Long).
(count for (t: Timepoint).
where (formerly within 5m (AgentCore::Action::"InsuranceAPI___disburse_payment"::request{ eventResource: resource } && tp(t)))) == n
&& n > 3
};
```
**重要**
これはセキュリティコントロールではありません。呼び出し元はセッション ID を指定し、新しいセッションを開始してカウントをリセットできるようにします。これを使用して、協調セッション内の動作を形成します。例えば、自分のセッション ID を制御する発信者に制限を適用しないように、ループエージェントを停止します。詳細については、[「セキュリティに関する考慮事項](policy-temporal.md#policy-temporal-security)」を参照してください。
## 実行合計の上限
**目的:** 5 分以内に合計 3,000.00 になるまで支払いを許可し、その後停止します。
`sum` は、現在のリクエストを含む一致するイベントに名前付き入力フィールドを追加するため、しきい値を超えるリクエストは拒否されます。上限が 300,000 セント、支払いが 100,000 の場合、最初の 2 つは許可され、3 つ目は拒否されます。
```
forbid (
principal,
action == AgentCore::Action::"InsuranceAPI___disburse_payment",
resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance-gw-a1b2c3d4e5"
)
when temporal {
exists (total: Long).
(sum amt for (amt: Long), (t: Timepoint).
where (formerly within 5m (AgentCore::Action::"InsuranceAPI___disburse_payment"::request{ eventResource: resource, input.amountCents: amt } && tp(t)))) == total
&& total >= 300000
};
```
2 変数ドメイン `for (amt: Long), (t: Timepoint)`が必要です。 `amt`は合計される値であり、タイムポイントを`t`区別するため、同じ量の 2 つの支払いは 1 つの支払いに重複排除されるのではなく、2 回カウントされます。
**注記**
`amountCents` はツールスキーマ`integer`の であり、これがこのポリシーを機能させるものです。`sum` 集計には整数和が必要で、 の順序比較には両側に整数`total`が必要なため、スキーマが として宣言するフィールドは、このような上限を駆動`number`できません。これらの例が依存する型ルールについては、これらの[例を使用する前に](#example-policies-temporal-before)「」を参照してください。
## 各承認を 1 回の使用に適したものにする
**目的:** 承認ごとに 1 つの支払いを許可します。支払い後、新しい承認が必要です。
`since` オペレーターは、右側のアンカーがウィンドウ内でいつ発生したかを保持し、その後、左側の条件が継続的に保持されます。「」と書かれています。過去 1 時間以内に承認が完了し、それ以降の支払いは完了していません。承認後の最初の支払いで消費されます。
```
permit (
principal,
action == AgentCore::Action::"InsuranceAPI___disburse_payment",
resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance-gw-a1b2c3d4e5"
)
when temporal {
!AgentCore::Action::"InsuranceAPI___disburse_payment"::response{ eventResource: resource }
since within 1h AgentCore::Action::"InsuranceAPI___approve_claim"::response{ eventResource: resource }
};
```
否定された側`::response`でのマッチングが不可欠です。承認されているリクエストはまだレスポンスを生成していないため、それ自体はブロックされません。`::request`一致すると、すべての支払い自体が拒否されます。
| セッションのリクエストシーケンス | 決定 |
| --- | --- |
| `approve_claim`、次に `disburse_payment` | 許可 |
| 新しい承認`disburse_payment`がない 1 秒 | DENY |
| 新しい `approve_claim`、次に `disburse_payment` | 許可 |
**注記**
`response` イベントは、呼び出しが完了した直後に記録されます。支払いを発行する前に、承認が戻るのを待ちます。詳細については、[「以前のレスポンスに依存するアクションの順序付け](policy-temporal.md#policy-temporal-response-delay)」を参照してください。
## クールダウンを適用する
**目的:** 完了から 1 分以内に同じアクションが繰り返されないようにします。
この条件は、 が承認するのと同じアクションを指します。 `::response` はこれを安全にします。現在のリクエストにはレスポンスがまだないため、それ自体には一致しません。で記述`::request`された現在のリクエストは独自のイベントと一致し、アクションは完全に禁止されます。詳細については、[「自己参照条件には現在のリクエストが含まれます](policy-temporal.md#policy-temporal-self-referential)」を参照してください。
```
forbid (
principal,
action == AgentCore::Action::"InsuranceAPI___disburse_payment",
resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance-gw-a1b2c3d4e5"
)
when temporal {
formerly within 1m AgentCore::Action::"InsuranceAPI___disburse_payment"::response{
eventResource: resource
}
};
```
## 無効にされていない前提条件が必要
**目的:** 承認中に支払いを許可し、後でステータスレビューのためにクレームが再開された場合はアクセス許可を取り消します。
これは one-time-useと同じ形状ですが、否定されたアクションは承認されているアクションとは異なり、「承認を消費する」が「承認を無効にする」になります。`approve_claim` と の両方の許可を付与します`get_claim_status`。
```
permit (
principal,
action == AgentCore::Action::"InsuranceAPI___disburse_payment",
resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance-gw-a1b2c3d4e5"
)
when temporal {
!AgentCore::Action::"InsuranceAPI___get_claim_status"::response{ eventResource: resource }
since within 5m AgentCore::Action::"InsuranceAPI___approve_claim"::response{ eventResource: resource }
};
```
| セッションのリクエストシーケンス | 決定 |
| --- | --- |
| `disburse_payment` 承認前 | DENY |
| `approve_claim`、次に `disburse_payment` | 許可 |
| `get_claim_status` が発生し、 `disburse_payment` | DENY |
| 新しい `approve_claim`、次に `disburse_payment` | 許可 |
## 一連のアクションを順番に要求する
**目的:** シーケンスステータスの検索、承認、支払いが必要です。
リンクごとに 1 つのポリシーがあり、チェーンはその構成から出現します。チェーンを開始できるように、最初のアクションにプレーン許可を付与します。順不同で試行されたステップは、前提条件が完了するまで拒否されます。
```
// Link 1: approve only after a completed status lookup
permit (
principal,
action == AgentCore::Action::"InsuranceAPI___approve_claim",
resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance-gw-a1b2c3d4e5"
)
when temporal {
formerly within 5m AgentCore::Action::"InsuranceAPI___get_claim_status"::response{ eventResource: resource }
};
// Link 2: disburse only after a completed approval
permit (
principal,
action == AgentCore::Action::"InsuranceAPI___disburse_payment",
resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance-gw-a1b2c3d4e5"
)
when temporal {
formerly within 5m AgentCore::Action::"InsuranceAPI___approve_claim"::response{ eventResource: resource }
};
```
## 任意の順序で 2 つの前提条件が必要です
**目的:** 支払いは、ステータス検索と承認の両方が完了した後に、どちらの順序でも許可します。
で結合された 2 つの`formerly`条件には両方`&&`が必要であり、どちらも順序を制限しません。これにより、1 つのポリシーに含まれる可能性のある 3 つの時間演算子のうち 2 つが使用されます。
```
permit (
principal,
action == AgentCore::Action::"InsuranceAPI___disburse_payment",
resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance-gw-a1b2c3d4e5"
)
when temporal {
formerly within 1h AgentCore::Action::"InsuranceAPI___get_claim_status"::response{ eventResource: resource }
&& formerly within 1h AgentCore::Action::"InsuranceAPI___approve_claim"::response{ eventResource: resource }
};
```
## 2 つのアクションを相互に排他的にする
**目的: **2 分以内に、支払いまたはクレームの削除のいずれかを許可しますが、両方は許可しません。
除外には 2 つの対称ポリシーが必要です。1 つのポリシーは 1 つの順序のみをブロック`forbid`します。マッチング`::request`とは、1 つのアクションを**試行**するだけで、完了するのを待たずにもう 1 つのアクションをブロックすることを意味します。
```
// Forbid deletion if a disbursement was requested within 2m
forbid (
principal,
action == AgentCore::Action::"InsuranceAPI___delete_claim",
resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance-gw-a1b2c3d4e5"
)
when temporal {
formerly within 2m AgentCore::Action::"InsuranceAPI___disburse_payment"::request{ eventResource: resource }
};
// Forbid disbursement if a deletion was requested within 2m
forbid (
principal,
action == AgentCore::Action::"InsuranceAPI___disburse_payment",
resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance-gw-a1b2c3d4e5"
)
when temporal {
formerly within 2m AgentCore::Action::"InsuranceAPI___delete_claim"::request{ eventResource: resource }
};
```
## しきい値のイベント数を要求する
**目的:** 少なくとも 2 つの支払いが完了した後にのみ、クレームの削除を許可します。
現在のリクエストのクレーム`input.claimId`に関連付けると、セッション内のすべての支払いをカウントするのではなく、そのクレームにカウントが絞り込まれます。
```
permit (
principal,
action == AgentCore::Action::"InsuranceAPI___delete_claim",
resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance-gw-a1b2c3d4e5"
)
when temporal {
exists (n: Long).
(count for (t: Timepoint).
where (formerly within 5m (AgentCore::Action::"InsuranceAPI___disburse_payment"::response{ eventResource: resource, input.claimId: context.input.claimId } && tp(t)))) == n
&& n >= 2
};
```
**注記**
`count` は個別の発信者ではなくイベントをカウントします。1 つのプリンシパルが一致するすべてのイベントを生成するのを停止するものがないため、「2 つの異なるユーザーによって承認された」を表現することはできません。マルチパーティー承認の場合は、ポリシーの外部で区別を関連付け`eventPrincipal`るか、適用します。
## 以前の拒否後にアクションをブロックする
**目的:** セッションの承認試行が拒否された後、セッションの支払いを停止します。
`error` イベントは、拒否または失敗したリクエストを記録するため、 `::error`はポリシーが以前の失敗にどのように反応するかを示します。これを のプレーン許可と組み合わせる`disburse_payment`と、通常の条件下で許可されます。
```
forbid (
principal,
action == AgentCore::Action::"InsuranceAPI___disburse_payment",
resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance-gw-a1b2c3d4e5"
)
when temporal {
formerly within 3m AgentCore::Action::"InsuranceAPI___approve_claim"::error{
eventResource: resource
}
};
```
これは便利な封じ込めパターンです。エージェントが持っていないアクセス許可を調べると、試行を続けるのではなく、機密性の高いアクションから切り離されます。
## 一時的な条件、ガードレール条件、リクエスト条件を組み合わせる
**目的:** セッションの過去 24 時間のファイリングが 3 回未満で、クレームの説明に銀行の詳細がなく、発信者が制限付きロールでない場合、発信者にクレームの申請を許可します。
3 つの条件タイプはすべて 1 つのポリシーで構成され、 が適用される`permit`にはすべての 句が を保持している必要があります。`temporal` ブロックは上限を適用し、`when`ブロックはコンテンツをスクリーンし、`unless`ブロックはロールを除外します。各 は個別に評価されます。
```
permit (
principal is AgentCore::OAuthUser,
action == AgentCore::Action::"InsuranceAPI___file_claim",
resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance-gw-a1b2c3d4e5"
)
when temporal {
exists (n: Long).
(count for (t: Timepoint).
where (formerly within 24h (AgentCore::Action::"InsuranceAPI___file_claim"::request{ eventResource: resource } && tp(t)))) == n
&& n <= 3
}
when {
BedrockGuardrails::SensitiveInformation(["US_BANK_ACCOUNT_NUMBER"], [context.input.description]).count() == 0
}
unless {
principal.hasTag("role") &&
principal.getTag("role") == "restricted"
};
```
ガードレールは`description`、フリーテキストパラメータが`file_claim`取る唯一の を画面表示します。機密情報ガードレールは、スクリーニング対象のデータを適切に移動する可能性のあるフィールドに向けます。識別子または数値を指すと、検出するものはなく、 句はサイレントに合格します。 `description`はオプションであるため、ガードレールにテキストを付けず、 句が保持するリクエストを省略します。
## 一時ポリシーを編集するとどうなるか
エンジンで一時ポリシーを追加または更新すると、記録された履歴が適用中のルールと一致しなくなるため、そのエンジンの開いている一時セッションが無効になります。無効なセッションを再利用する次のリクエストは、HTTP 409 で失敗します`ConflictException`。新しいセッションを開始し、再試行します。新しいセッションは空の履歴で始まり、更新されたポリシーに対して評価されます。
**重要**
一時的なポリシー変更をロールアウトするときに、このことを計画します。クライアントは、 を「新しいセッションを開始する`409`」として扱う必要があります。実行中のマルチステップワークフローは、再開するのではなく再起動します。