ポリシーの例

このセクションでは、保険管理システムの Cedar 認可ポリシーの包括的な例を示します。これらの例は、独自のアプリケーションに適応できるさまざまな Cedar 言語機能と認可パターンを示しています。

使用可能なツール

Insurance API には、保険ポリシーと請求を管理するための 5 つのツールが用意されています。

承認ポリシー

以下のポリシーは、Cedar 言語のさまざまな機能と認可パターンを示しています。各ポリシーには、自然言語の説明、Cedar コード、詳細な説明が含まれています。

ポリシー 1: マルチアクション許可

このポリシーは、1 つのポリシーステートメントを使用して、複数の関連アクションへのアクセスを許可する方法を示しています。

自然言語: すべてのプリンシパルにポリシーの取得とクレームステータスの取得を許可します。

Cedar ポリシー:

permit(
  principal is AgentCore::OAuthUser,
  action in [
    AgentCore::Action::"InsuranceAPI___get_policy",
    AgentCore::Action::"InsuranceAPI___get_claim_status"
  ],
  resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance"
);

説明: このポリシーは、 in演算子を使用したマルチアクション許可を示しています。読み取りオペレーションごとに個別のポリシーを記述する代わりに、1 つのポリシーで複数の関連アクションへのアクセスが許可されます。これは、同じ認可要件を共有する同様のオペレーションをグループ化する場合に便利です。

ポリシー 2: スコープベースの認可

このポリシーは、OAuth スコープを使用して特定のオペレーションへのアクセスを制御する方法を示しています。

自然言語: 「insurance:claim」を含むスコープを持つプリンシパルにファイルクレームを許可します。

Cedar ポリシー:

permit(
  principal is AgentCore::OAuthUser,
  action == AgentCore::Action::"InsuranceAPI___file_claim",
  resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance"
)
when {
  principal.hasTag("scope") &&
  principal.getTag("scope") like "*insurance:claim*"
};

説明: このポリシーは、タグを使用した OAuth スコープの検証を示しています。hasTag メソッドは、タグが存在するかどうかをチェックし、その値getTagを取得します。ワイルドカード (*) を持つlike演算子はパターンマッチングを実行し、「insurance:claim」、「insurance:claim:write」、「admin insurance:claim」などの柔軟なスコープ形式を可能にします。

ポリシー 3: 以下の場合を除き、 を使用したロールベースの認可

このポリシーでは、 unless句を使用して制限の例外を作成する方法を示します。

自然言語: プリンシパルにロール「シニアアジャスタ」または「マネージャー」がない限り、プリンシパルがカバレッジを更新できないようにします。

Cedar ポリシー:

forbid(
  principal is AgentCore::OAuthUser,
  action == AgentCore::Action::"InsuranceAPI___update_coverage",
  resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance"
)
unless {
  principal.hasTag("role") &&
  (principal.getTag("role") == "senior-adjuster" || principal.getTag("role") == "manager")
};

説明: このポリシーは、条件ロジックを反転させる unless句を示しています。禁止は、ユーザーが指定されたロールのいずれかを持っていない限り適用されます。これは、制限の例外を作成するのに役立ちます。このポリシーには、複数の許容値をチェックするための OR ロジックも表示されます。

ポリシー 4: OR ロジックとの文字列の等価性

このポリシーは、入力パラメータを検証し、複数の許容値に OR ロジックを使用する方法を示しています。

自然言語: クレームタイプがヘルス、プロパティ、または自動の場合、プリンシパルにクレームの申請を許可します。

Cedar ポリシー:

permit(
  principal is AgentCore::OAuthUser,
  action == AgentCore::Action::"InsuranceAPI___file_claim",
  resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance"
)
when {
  context.input has claimType &&
  (context.input.claimType == "health" ||
   context.input.claimType == "property" ||
   context.input.claimType == "auto")
};

説明: このポリシーは、 を介してツール入力パラメータにアクセスしcontext.input、OR ロジックを使用して文字列の等価チェックを行う方法を示しています。has オペレータは、アクセスする前にフィールドが存在することを最初に検証し、オプションフィールドが欠落している場合のエラーを防止します。

ポリシー 5: フィールド存在チェック

このポリシーは、オプションフィールドを要求してビジネスルールを適用する方法を示しています。

自然言語: 説明が指定されていない限り、プリンシパルによるクレームの申請をブロックします。

Cedar ポリシー:

forbid(
  principal is AgentCore::OAuthUser,
  action == AgentCore::Action::"InsuranceAPI___file_claim",
  resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance"
)
unless {
  context.input has description
};

説明: このポリシーは、オプションのパラメータに必須フィールドを適用する方法を示しています。ツールスキーマでは説明フィールドはオプションですが、このポリシーでは、含まれていないリクエストを禁止することで必須になります。これは、ポリシーがスキーマ検証以外にビジネスルールを追加する方法を示しています。

ポリシー 6: ユーザー名ベースの認可

このポリシーは、特定のユーザー ID に基づいてアクセスを許可する方法を示しています。

自然言語: ユーザー名「Clare」のプリンシパルにカバレッジの更新を許可します。

Cedar ポリシー:

permit(
  principal is AgentCore::OAuthUser,
  action == AgentCore::Action::"InsuranceAPI___update_coverage",
  resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance"
)
when {
  principal.hasTag("username") &&
  principal.getTag("username") == "Clare"
};

説明: このポリシーは、正確な文字列マッチングを使用したユーザー名ベースの認可を示しています。ポリシー 3 と組み合わせると、2 つの部分からなる認可が作成されます。カバレッジを更新するには、ユーザーはユーザー名「保険エージェント」を持ち、ロール「シニアアジャスタ」または「マネージャー」を持っている必要があります。

ポリシー 7: like とのパターンマッチング

このポリシーは、カテゴリベースのアクセスコントロールにワイルドカードを使用した柔軟なパターンマッチングを示しています。

自然言語: カバレッジタイプに「auto」が含まれている場合、プリンシパルにプレミアムの計算を許可します。

Cedar ポリシー:

permit(
  principal is AgentCore::OAuthUser,
  action == AgentCore::Action::"InsuranceAPI___calculate_premium",
  resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance"
)
when {
  context.input has coverageType &&
  context.input.coverageType like "*auto*"
};

説明: このポリシーは、 like演算子との柔軟なパターンマッチングを示しています。ワイルドカード * は任意の文字と一致するため、「auto」、「auto-liability」、「comprehensive-auto」、または「auto-collision」はすべて一致します。これは、正確な文字列ではなく値のカテゴリを一致させる場合に便利です。

ポリシー 8: AND との条件の組み合わせ

このポリシーは、複数の条件を組み合わせて複雑な認可ルールを作成する方法を示しています。

自然言語: カバレッジタイプが責任または衝突であり、新しい制限が指定されている場合、プリンシパルがカバレッジを更新できるようにします。

Cedar ポリシー:

permit(
  principal is AgentCore::OAuthUser,
  action == AgentCore::Action::"InsuranceAPI___update_coverage",
  resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance"
)
when {
  context.input has coverageType &&
  context.input has newLimit &&
  (context.input.coverageType == "liability" || context.input.coverageType == "collision")
};

説明: このポリシーは、複数の条件を AND ロジックと組み合わせる方法を示しています。coverageType が存在し、newLimit が存在し、 coverageType が「liability」または「collision」のいずれかである必要があります。これはポリシー 6 と連携してレイヤー認可を作成します。誰が更新できるか (ポリシー 6)、何が更新できるか (ポリシー 8)。

認可セマンティクスについて

これらのポリシーは、主要な Cedar 認可セマンティクスを示しています。

デフォルトで拒否

アクションを明示的に許可するポリシーがない場合は、拒否されます。たとえば、「insurance:claim」スコープを持たないユーザーは、ポリシーで明示的に禁止されていなくても、クレームを提出できません。

落札の禁止

禁止ポリシーが一致した場合、許可ポリシーも一致してもリクエストは拒否されます。ポリシー 5 (説明なしの禁止) は、説明がない場合にポリシー 2 (スコープで許可) を上書きします。

ポリシーのレイヤー化

複数のポリシーを同じリクエストに適用できます。

リクエストを成功させるには、保険エージェント (ポリシー 6)、シニアアジャスタロールまたはマネージャーロール (ポリシー 3)、責任または衝突の更新 (ポリシー 8) の 3 つをすべて満たす必要があります。

テストシナリオ

以下のシナリオは、ポリシーが実際にどのように連携するかを示しています。

IAM ベースの認可の例

AgentCore Gateway が OAuth の代わりに AWS_IAM 認証を使用する場合、Cedar ポリシーのプリンシパルは として表されますAgentCore::IamEntity。引き受けたロールを介して認証する発信者の場合、Cedar エンティティ ID は形式 を使用してarn:aws:sts::<account>:assumed-role/<role-name>、安定したprincipal ==マッチングとprincipal.idパターンマッチングを可能にします。

基本的な IAM エンティティ許可

このポリシーは、IAM 認証呼び出し元が特定のツールを使用することを許可します。

permit(
  principal is AgentCore::IamEntity,
  action == AgentCore::Action::"OrderAPI___get_order",
  resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/order-gateway"
);

説明: これは IAM ポリシーの最も簡単な形式です。これにより、AWS_IAM を介して認証されたすべての発信者が get_order ツールを呼び出すことができます。これは、発信者が追加の制限なしで IAM 認証されていることを確認する必要がある場合にのみ使用します。

プリンシパルが完全に一致するロールベースの制限

を使用して、特定の IAM ロールを使用して発信者へのツールアクセスを制限しますprincipal ==。

permit(
  principal == AgentCore::IamEntity::"arn:aws:sts::111122223333:assumed-role/MyServiceRole",
  action == AgentCore::Action::"OrderAPI___process_order",
  resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/order-gateway"
);

説明: 引き受けたロールの Cedar エンティティ ID は ですarn:aws:sts::<account>:assumed-role/<role-name>。これにより、認証中に使用されるセッション名に関係なく、安定したprincipal ==マッチングが可能になります。

パターンマッチングによるロールベースの制限

は、より広範なマッチングパターンprincipal.id likeにも使用できます。

permit(
  principal is AgentCore::IamEntity,
  action == AgentCore::Action::"OrderAPI___process_order",
  resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/order-gateway"
)
when {
  principal.id like "arn:aws:sts::111122223333:assumed-role/MyServiceRole"
};

説明: これにより、 と同じ結果が得られますprincipal ==が、 when句を使用します。パターンマッチングは、アカウント () 内の任意のロールのマッチングなど、より広範なマッチングが必要な場合に便利ですprincipal.id like "arn:aws:sts::111122223333:assumed-role/*"。

アカウントベースの制限

特定の AWS アカウントからの発信者へのツールアクセスを制限します。

permit(
  principal is AgentCore::IamEntity,
  action == AgentCore::Action::"OrderAPI___process_order",
  resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/order-gateway"
)
when {
  principal.id like "*:111122223333:*"
};

説明: パターン *:111122223333:* は、そのアカウント ID を含むすべての ARN と一致します。これにより、指定された AWS アカウントからの発信者のみにアクセスが制限されます。

マルチエージェントフェデレーション

異なる IAM ロールを持つ複数のエージェントが同じゲートウェイにアクセスする場合は、個別のポリシーを作成して、各エージェントが使用できるツールを制御します。

// Agent A can only read orders
permit(
  principal == AgentCore::IamEntity::"arn:aws:sts::111122223333:assumed-role/AgentA-Role",
  action == AgentCore::Action::"OrderAPI___get_order",
  resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/order-gateway"
);

// Agent B can read and process orders
permit(
  principal == AgentCore::IamEntity::"arn:aws:sts::111122223333:assumed-role/AgentB-Role",
  action in [
    AgentCore::Action::"OrderAPI___get_order",
    AgentCore::Action::"OrderAPI___process_order"
  ],
  resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/order-gateway"
);

説明: このパターンは、異なるエージェントが異なる IAM ロールを持ち、異なるレベルのツールアクセスを持つ必要があるマルチエージェントアーキテクチャに役立ちます。各ポリシーは、特定のロールのエンティティ ID principal ==で を使用します。各エージェントのtools/listレスポンスには、使用が許可されているツールのみが含まれます。

入力検証を含む IAM

IAM プリンシパルマッチングをツール入力検証と組み合わせます。

permit(
  principal == AgentCore::IamEntity::"arn:aws:sts::111122223333:assumed-role/RefundProcessorRole",
  action == AgentCore::Action::"RefundAPI___process_refund",
  resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/refund-gateway"
)
when {
  context.input has amount &&
  context.input.amount < 1000
};

説明: このポリシーは、正確なプリンシパルマッチングと入力検証を組み合わせます。返金金額が 1,000 USD 未満の場合にのみ、指定されたアカウントRefundProcessorRoleから を引き受ける発信者のみが返金を処理できます。

特定のアカウントを禁止する

特定の AWS アカウントの発信者が機密ツールにアクセスできないようにします。

forbid(
  principal is AgentCore::IamEntity,
  action == AgentCore::Action::"AdminAPI___delete_resource",
  resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/admin-gateway"
)
when {
  principal.id like "*:444455556666:*"
};

説明: この禁止ポリシーは、サードパーティーベンダーアカウント (444455556666) からのすべての発信者が管理上の削除を実行できないようにします。forbid-wins セマンティクスにより、これは許可ポリシーよりも優先されます。

機密性の高いオペレーションから特定のロールを禁止する

読み取り専用ロールを使用して発信者が書き込みオペレーションを実行できないようにします。

forbid(
  principal == AgentCore::IamEntity::"arn:aws:sts::111122223333:assumed-role/ReadOnlyAgentRole",
  action in [
    AgentCore::Action::"OrderAPI___process_order",
    AgentCore::Action::"OrderAPI___cancel_order"
  ],
  resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/order-gateway"
);

説明: この禁止ポリシーにより、 を使用する発信者ReadOnlyAgentRoleは、許可ポリシーにかかわらず、書き込みオペレーションを実行できなくなります。