Policy di esempio

Questa sezione fornisce esempi completi di politiche di autorizzazione Cedar per un sistema di gestione assicurativa. Questi esempi illustrano varie funzionalità del linguaggio Cedar e modelli di autorizzazione che è possibile adattare alle proprie applicazioni.

Strumenti disponibili

L'API Insurance fornisce cinque strumenti per la gestione delle polizze assicurative e dei reclami:

Policy di autorizzazione

Le seguenti politiche illustrano varie funzionalità e modelli di autorizzazione del linguaggio Cedar. Ogni politica include la descrizione del linguaggio naturale, il codice Cedar e una spiegazione dettagliata.

Politica 1: permesso Multi-action

Questa politica dimostra come concedere l'accesso a più azioni correlate utilizzando un'unica dichiarazione politica.

Linguaggio naturale: consenti a tutti i responsabili di ottenere la polizza e ottenere lo stato del reclamo.

Politica 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"
);

Spiegazione: questa politica illustra i permessi multiazione che utilizzano l'operatore. in Invece di scrivere policy separate per ogni operazione di lettura, una singola policy garantisce l'accesso a più azioni correlate. Ciò è utile per raggruppare operazioni simili che condividono gli stessi requisiti di autorizzazione.

Politica 2: autorizzazione Scope-based

Questa politica mostra come utilizzare gli ambiti OAuth per controllare l'accesso a operazioni specifiche.

Linguaggio naturale: consenti ai mandanti con ambito contenente «insurance:claim» di presentare reclami.

Politica 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*"
};

Spiegazione: questa politica dimostra la convalida dell'ambito OAuth utilizzando i tag. Il hasTag metodo verifica se il tag esiste e getTag ne recupera il valore. L'likeoperatore con wildcards (*) esegue il pattern matching, consentendo formati di ambito flessibili come «insurance:claim», «insurance:claim:write» o «admin insurance:claim».

Role-based Politica 3: autorizzazione con a meno che

Questa politica dimostra l'utilizzo della unless clausola per creare eccezioni alle restrizioni.

Linguaggio naturale: impedisce ai responsabili di aggiornare la copertura a meno che il preside non ricopra il ruolo di «aggiustatore senior» o «manager».

Politica 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")
};

Spiegazione: questa politica illustra la unless clausola, che inverte la logica della condizione. Il divieto si applica a meno che l'utente non abbia uno dei ruoli specificati. Questo è utile per creare eccezioni alle restrizioni. La politica mostra anche la logica OR per il controllo di più valori accettabili.

Politica 4: uguaglianza delle stringhe con logica OR

Questa politica mostra come convalidare i parametri di input e utilizzare la logica OR per più valori accettabili.

Linguaggio naturale: consenti ai mandanti di presentare reclami quando il tipo di reclamo è sanitario, immobiliare o auto.

Politica 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")
};

Spiegazione: questa politica dimostra l'accesso ai parametri di input dello strumento context.input e i controlli di uguaglianza delle stringhe con la logica OR. L'hasoperatore verifica innanzitutto l'esistenza del campo prima di accedervi, evitando errori quando mancano campi opzionali.

Politica 5: controllo dell'esistenza del campo

Questa politica dimostra come far rispettare le regole aziendali richiedendo campi opzionali.

Linguaggio naturale: impedisce ai mandanti di presentare reclami a meno che non venga fornita una descrizione.

Politica 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
};

Spiegazione: questa politica dimostra l'applicazione dei campi obbligatori per i parametri opzionali. Il campo della descrizione è facoltativo nello schema dello strumento, ma questa politica lo rende obbligatorio vietando le richieste che non lo includono. Questo mostra come le politiche possono aggiungere regole aziendali oltre alla convalida dello schema.

Politica 6: autorizzazione Username-based

Questa politica mostra come concedere l'accesso in base a identità utente specifiche.

Linguaggio naturale: consenti ai mandanti con nome utente «Clare» di aggiornare la copertura.

Politica 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"
};

Spiegazione: questa politica dimostra l'autorizzazione basata sul nome utente utilizzando la corrispondenza esatta delle stringhe. In combinazione con la Policy 3, ciò crea un'autorizzazione in due parti: gli utenti devono avere il nome utente «insurance-agent» E avere il ruolo di «senior-adjuster» o «manager» per aggiornare la copertura.

Politica 7: Pattern matching con like

Questa politica dimostra una corrispondenza flessibile dei modelli utilizzando caratteri jolly per il controllo degli accessi basato sulle categorie.

Linguaggio naturale: consenti ai committenti di calcolare il premio quando il tipo di copertura contiene «auto».

Politica 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*"
};

Spiegazione: questa politica dimostra un adattamento flessibile dei modelli all'likeoperatore. Il carattere jolly * corrisponde a qualsiasi carattere, quindi «auto», «auto-liability», «comprehensive-auto» o «auto-collision» corrisponderebbero tutti. Ciò è utile quando si desidera abbinare una categoria di valori anziché stringhe esatte.

Politica 8: condizioni combinate con AND

Questa politica mostra come combinare più condizioni per creare regole di autorizzazione complesse.

Linguaggio naturale: consenti ai committenti di aggiornare la copertura quando il tipo di copertura è responsabilità o collisione e viene fornito un nuovo limite.

Politica 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")
};

Spiegazione: questa politica dimostra la combinazione di più condizioni con la logica AND. Tutte e tre le condizioni devono essere vere: CoverageType deve esistere, newLimit deve esistere e coverageType deve essere «responsabilità» o «collisione». Funziona con la Policy 6 per creare un'autorizzazione a più livelli: chi può aggiornare (Policy 6) e cosa può aggiornare (Policy 8).

Comprensione della semantica delle autorizzazioni

Queste politiche dimostrano la semantica chiave dell'autorizzazione Cedar:

Rifiuto per default

Se nessuna politica consente esplicitamente un'azione, questa viene negata. Ad esempio, un utente senza l'ambito «insurance:claim» non può presentare reclami anche se nessuna politica lo vieta esplicitamente.

Forbid vince

Se una delle politiche di divieto corrisponde, la richiesta viene rifiutata anche se anche le politiche di autorizzazione corrispondono. La Policy 5 (divieto senza descrizione) ha la precedenza sulla Policy 2 (autorizzazione con ambito) quando manca una descrizione.

Stratificazione delle politiche

È possibile applicare più politiche alla stessa richiesta:

Affinché una richiesta abbia successo, deve soddisfare tutti e tre i requisiti: essere agente assicurativo (Polizza 6), ricoprire il ruolo di perito o dirigente (Policy 3) e aggiornare la responsabilità in caso di collisione (Policy 8).

Scenario di test

Gli scenari seguenti mostrano come le politiche interagiscono nella pratica:

IAM-based esempi di autorizzazione

Quando il AgentCore gateway utilizza l'autenticazione AWS_IAM anziché OAuth, il principale nelle politiche Cedar è rappresentato come. AgentCore::IamEntity Per i chiamanti che si autenticano tramite ruoli presunti, l'ID dell'entità Cedar utilizza il formato, che consente la corrispondenza stabile e la corrispondenza dei modelli. arn:aws:sts::<account>:assumed-role/<role-name> principal == principal.id

Permesso di entità IAM di base

Questa politica consente a qualsiasi IAM-authenticated chiamante di utilizzare uno strumento specifico:

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"
);

Spiegazione: questa è la forma più semplice di policy IAM. Consente a qualsiasi chiamante autenticato tramite AWS_IAM di chiamare lo strumento get_order. Usalo quando devi solo verificare che i chiamanti siano privi di restrizioni aggiuntive. IAM-authenticated

Role-based restrizione con corrispondenza esatta dei principali

Limita l'accesso allo strumento ai chiamanti che utilizzano un ruolo IAM specifico utilizzando: 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"
);

Spiegazione: l'ID dell'entità Cedar per i ruoli presunti è. arn:aws:sts::<account>:assumed-role/<role-name> Ciò consente una principal == corrispondenza stabile indipendentemente dal nome della sessione utilizzato durante l'autenticazione.

Role-based restrizione con pattern matching

Puoi anche usare principal.id like per modelli di corrispondenza più ampi:

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"
};

Spiegazione: Ciò ottiene lo stesso risultato principal == ma utilizza una when clausola. Il pattern matching è utile quando è necessaria una corrispondenza più ampia, ad esempio la corrispondenza di qualsiasi ruolo in un account (). principal.id like "arn:aws:sts::111122223333:assumed-role/*"

Account-based restrizione

Limita l'accesso allo strumento ai chiamanti da account specifici 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:*"
};

Spiegazione: Il pattern *:111122223333: * corrisponde a qualsiasi ARN contenente l'ID dell'account. Ciò limita l'accesso ai chiamanti solo dall'account specificato. AWS

Multi-agent federazione

Quando più agenti con ruoli IAM diversi accedono allo stesso gateway, crea policy separate per controllare quali strumenti può utilizzare ciascun agente:

// 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"
);

Spiegazione: questo modello è utile per le architetture multi-agente in cui agenti diversi hanno ruoli IAM diversi e dovrebbero avere diversi livelli di accesso agli strumenti. Ogni policy utilizza l'principal ==ID di entità del ruolo specifico. La tools/list risposta per ogni agente include solo gli strumenti che è autorizzato a utilizzare.

IAM con convalida dell'input

Combina la corrispondenza dei principali IAM con la convalida dell'input dello strumento:

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
};

Spiegazione: questa politica combina l'esatta corrispondenza dei principali con la convalida degli input. I rimborsi possono elaborare i rimborsi solo se il chiamante RefundProcessorRole proviene dall'account specificato e solo quando l'importo del rimborso è inferiore a 1000 USD.

Proibisci account specifici

Impedisci ai chiamanti di AWS account specifici di accedere a strumenti sensibili:

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:*"
};

Spiegazione: questa politica di divieto impedisce a tutti i chiamanti provenienti da un account di fornitore terzo (444455556666) di eseguire eliminazioni amministrative. A causa della semantica Forbid-Wins, ciò ha la precedenza su qualsiasi politica di autorizzazione.

Proibisci l'accesso a ruoli specifici alle operazioni sensibili

Impedisci ai chiamanti che utilizzano ruoli di sola lettura di eseguire operazioni di scrittura:

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"
);

Spiegazione: questa politica di divieto impedisce ai chiamanti che utilizzano il ReadOnlyAgentRole di eseguire operazioni di scrittura, indipendentemente dalle politiche di autorizzazione che potrebbero altrimenti consentirle.