Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Policy di esempio

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

Strumenti disponibili

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

Policy di autorizzazione

Le seguenti politiche illustrano varie funzionalità e modelli di autorizzazione del linguaggio Cedar. Ogni policy include una descrizione in linguaggio naturale, 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 committenti di ottenere una 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 dimostra i permessi di più azioni utilizzando l'operatore. in Invece di scrivere politiche separate per ogni operazione di lettura, una singola politica consente 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 committenti con ambito contenente «insurance:claim» di presentare reclami.

Polizza 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 tramite tag. Il hasTag metodo verifica se il tag esiste e getTag ne recupera il valore. L'likeoperatore con caratteri jolly (*) esegue la corrispondenza dei modelli, consentendo formati di ambito flessibili come «insurance:claim», «insurance:claim:write» o «admin insurance:claim».

Role-based Politica 3: autorizzazione con no

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

Linguaggio naturale: impedisce ai presidi di aggiornare la copertura a meno che non ricoprano il ruolo di «senior adjuster» 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 delle condizioni. Il divieto si applica a meno che l'utente non abbia uno dei ruoli specificati. Ciò è utile per creare eccezioni alle restrizioni. La policy 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 è salute, proprietà 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 tramite context.input i controlli di uguaglianza delle stringhe con logica OR. L'hasoperatore verifica innanzitutto l'esistenza del campo prima di accedervi, prevenendo errori in caso di mancanza di campi opzionali.

Politica 5: controllo dell'esistenza del campo

Questa politica dimostra come applicare le regole aziendali richiedendo campi opzionali.

Linguaggio naturale: impedisce ai committenti 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 di descrizione è facoltativo nello schema dello strumento, ma questa politica lo rende obbligatorio vietando le richieste che non lo includono. Questo dimostra come le policy 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 presidi 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, questa crea un'autorizzazione in due parti: gli utenti devono avere il nome utente «agente assicurativo» E avere il ruolo di «perito senior» o «manager» per aggiornare la copertura.

Politica 7: corrispondenza del modello con like

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

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

Polizza 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 una corrispondenza flessibile dei modelli con l'likeoperatore. La jolly * corrisponde a qualsiasi carattere, quindi «auto», «auto-liability», «comprehensive auto» o «auto-collision» corrisponderebbero tutti. Ciò è utile quando si desidera far corrispondere 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.

Polizza 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ò effettuare l'aggiornamento (Policy 6) e cosa può aggiornare (Policy 8).

Comprendere la semantica delle autorizzazioni

Queste politiche dimostrano la semantica chiave dell'autorizzazione di Cedar:

Rifiuto per default

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

Vieta le vittorie

Se una delle politiche di divieto corrisponde, la richiesta viene respinta anche se anche le politiche di autorizzazione corrispondono. La politica 5 (divieto senza descrizione) sostituisce la politica 2 (permesso con ambito) quando manca la 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 senior o manager (Polizza 3) e aggiornare la responsabilità o collisione (Polizza 8).

Scenario di test

I seguenti scenari dimostrano 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, consentendo una corrispondenza stabile e una corrispondenza dei modelli. arn:aws:sts::<account>:assumed-role/<role-name> principal == principal.id

Permesso di base per l'entità IAM

Questa policy 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 non abbiano restrizioni aggiuntive. IAM-authenticated

Role-based restrizione con esatta corrispondenza principale

Limita l'accesso allo strumento ai chiamanti utilizzando 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 assunti è. 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 corrispondenza dei modelli

Puoi anche usare principal.id like per modelli di abbinamento 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: si ottiene lo stesso risultato principal == ma si 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 provenienti 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 modello *: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 ogni 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 multiagente in cui agenti diversi hanno ruoli IAM diversi e dovrebbero avere diversi livelli di accesso agli strumenti. Ogni policy viene utilizzata principal == con l'ID dell'entità del ruolo specifico. La tools/list risposta per ciascun agente include solo gli strumenti che è autorizzato a utilizzare.

IAM con convalida degli input

Combina la corrispondenza principale IAM con la convalida degli 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 policy combina l'esatta corrispondenza delle principali con la convalida degli input. Solo i chiamanti che utilizzano l'RefundProcessorRoleaccount specificato possono elaborare i rimborsi e solo quando l'importo del rimborso è inferiore a 1000$.

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 vieta a tutti i chiamanti provenienti da un account di un fornitore terzo (444455556666) di effettuare cancellazioni amministrative. A causa della semantica del divieto di vittoria, questa ha la precedenza su qualsiasi politica di autorizzazione.

Proibisci a ruoli specifici di svolgere 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 lo utilizzano di eseguire operazioni di scrittura, indipendentemente ReadOnlyAgentRole da eventuali politiche di autorizzazione che potrebbero altrimenti consentirle.