# Richtlinien in natürlicher Sprache verfassen
Policy in wählt AgentCore automatisch die optimale Region innerhalb Ihrer Region aus, um Ihre über den Policy-Authoring-Service gestellten Inferenzanfragen zu verarbeiten. Dadurch werden die verfügbaren Rechenressourcen und die Modellverfügbarkeit maximiert und das beste Kundenerlebnis gewährleistet. Ihre Daten werden nur in der Region gespeichert, aus der die Anfrage stammt. Eingabeaufforderungen und Ausgabeergebnisse können jedoch außerhalb dieser Region verarbeitet werden. Alle Daten werden bei der Übertragung über das sichere Netzwerk von Amazon verschlüsselt.
Policy in AgentCore leitet Ihre Inferenzanfragen wie folgt sicher an verfügbare Rechenressourcen in dem geografischen Gebiet weiter, aus dem die Anfrage stammt:
+ Inferenzanfragen mit Ursprung in der Europäischen Union werden innerhalb der Europäischen Union bearbeitet.
+ Inferenzanfragen mit Ursprung in den Vereinigte Staaten werden in den Vereinigte Staaten bearbeitet.
+ Inferenzanfragen mit Ursprung in APAC werden innerhalb APAC bearbeitet.
**Topics**
+ [-Übersicht](#nl2cedar-overview)
+ [Beispiel](#nl2cedar-example)
+ [Politische Auswirkungen](#nl2cedar-policy-effects)
+ [Semantik der Autorisierung](#nl2cedar-authorization-semantics)
+ [Richtlinienelemente](#nl2cedar-policy-elements)
+ [Beispiele für Richtlinien](#nl2cedar-policy-examples)
+ [Syntax der Bedingung](#nl2cedar-condition-syntax)
+ [Bedingungen kombinieren](#nl2cedar-combining-conditions)
+ [Häufige Fallstricke](#nl2cedar-common-pitfalls)
## -Übersicht
Cedar bietet eine präzise Zugriffskontrolle, erfordert jedoch das Erlernen der formalen Syntax. NL2Cedar ermöglicht Ihnen:
1. Schreiben Sie die Autorisierungsanforderungen in natürlicher Sprache
1. Automatisch in die Cedar-Syntax konvertieren
1. Stellen Sie sicher, dass die generierten Richtlinien Ihren Anforderungen entsprechen
**Anmerkung**
Für die Generierung von Richtlinien in natürlicher Sprache sind ein AgentCore Gateway und eine Policy-Engine erforderlich. Der Dienst verwendet das AgentCore Gateway-Schema, um gültige Cedar-Richtlinien zu generieren. Anweisungen zur Einrichtung finden Sie unter [Erste Schritte mit Policy](policy-getting-started.md). AgentCore
**Anmerkung**
Natürliche Sprache ist flexibel, aber Präzision ist aus Sicherheitsgründen unerlässlich. Die Richtlinien müssen klar und unmissverständlich sein.
## Beispiel
Die Rückerstattungspolitik aus dem vorherigen Abschnitt kann in natürlicher Sprache ausgedrückt werden:
**Natürliche Sprache:**
Erlauben Sie dem Auftraggeber mit dem Benutzernamen „refund-agent“, Rückerstattungen zu bearbeiten, wenn der Rückerstattungsbetrag weniger als 500$ beträgt.
**Konvertiert zu Zedernholz:**
```
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
};
```
## Politische Auswirkungen
Autorisierungsrichtlinien haben zwei mögliche Auswirkungen: Zulassen und Verbieten.
**Topics**
+ [Richtlinien für Genehmigungen](#nl2cedar-permit-policies)
+ [Verbieten Sie Richtlinien](#nl2cedar-forbid-policies)
### Richtlinien für Genehmigungen
Genehmigungsrichtlinien geben an, was Benutzer tun können:
+ „Erlaube dem Benutzer, Rückerstattungen zu bearbeiten“
+ „Erlauben Sie Benutzern mit der Rolle Director, Entscheidungen zu genehmigen“
+ „Autorisieren Sie Benutzer mit dem Geltungsbereich admin:write, um die Abdeckung zu aktualisieren“
### Verbieten Sie Richtlinien
In den Richtlinien zum Verbot wird festgelegt, was Benutzer nicht tun können:
+ „Sperren Sie Benutzern den Zugriff auf Modelle mit hoher Sensibilität“
+ „Untersagen Sie jüngeren Versicherern die Genehmigung von Entscheidungen“
+ „Benutzern verbieten, Rückerstattungen zu bearbeiten, wenn die Risikovalidierung noch aussteht“
## Semantik der Autorisierung
Für die Erstellung effektiver Autorisierungsregeln ist es entscheidend zu verstehen, wie Cedar Richtlinien bewertet. Cedar folgt drei Grundprinzipien:
+ **Standardmäßig wird alles verweigert** — Wenn keine Richtlinie eine Aktion ausdrücklich zulässt, wird sie automatisch blockiert
+ **Verbieten gewinnt immer** — Wenn eine Verbotsrichtlinie zutrifft, wird der Zugriff verweigert, auch wenn die Genehmigungsrichtlinien ebenfalls übereinstimmen
+ **Mindestens eine Genehmigung erforderlich — Damit** Zugriff gewährt werden kann, muss mindestens eine Genehmigungsrichtlinie übereinstimmen UND es dürfen keine Verbotsrichtlinien übereinstimmen
**Warum sollten Verbotsrichtlinien verwendet werden, wenn standardmäßig alles verweigert wird?**
Richtlinien zum Verbot stellen sicher, dass bestimmte Aktionen nicht fälschlicherweise zugelassen werden können. Selbst wenn jemand eine umfassendere Genehmigungsrichtlinie verfasst, hat die Verbotsrichtlinie Vorrang und blockiert den Zugriff.
**Beispielszenario:**
```
// 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"
};
```
**Ergebnis:** Benutzer können Ergebnisse mit niedriger und mittlerer Sensitivität einsehen (nur mit Genehmigung), aber Ergebnisse mit hoher Sensitivität werden immer blockiert (Gewinne verbieten).
Verwenden Sie Verbotsrichtlinien für:
+ Explizite Sicherheitseinschränkungen, die niemals außer Kraft gesetzt werden dürfen
+ Compliance-Anforderungen
+ Notabschaltungen
+ Schaffung von Ausnahmen zu umfassenderen Genehmigungsrichtlinien
## Richtlinienelemente
Autorisierungsrichtlinien erfordern drei Schlüsselelemente:
1. **Wer** — Welche Benutzer oder Rollen können die Aktion ausführen
1. **Was** — Welche Operationen oder Tools können sie verwenden
1. **Wann** — Unter welchen Bedingungen oder Einschränkungen
**Topics**
+ [Hauptspezifikation](#nl2cedar-principal-specification)
+ [Spezifikation der Aktion](#nl2cedar-action-specification)
+ [Spezifikation des Zustands](#nl2cedar-condition-specification)
### Hauptspezifikation
Der Prinzipal identifiziert, für welche Benutzer, Rollen oder Gruppen die Richtlinie gilt.
Flexible Ausdrücke:
+ „Erlaube dem Benutzer Refund-Agent,...“
+ „Erlaube Benutzern mit dem Benutzernamen refund-agent,...“
+ „Benutzer mit der Rolle Versicherungsagent können...“
+ „Jeder mit dem Gültigkeitsbereich refund:write ist berechtigt,...“
+ „Alle Benutzer können...“
Seien Sie genau in Bezug auf Identität:
Unvollständig: ❌ „Erlaube die Bearbeitung von Rückerstattungen unter 500$“
Vollständig: ✓ „Erlaube dem Rückerstattungsbeauftragten, Rückerstattungen unter 500$ zu bearbeiten“
### Spezifikation der Aktion
Das „Was“ gibt an, welche Operationen, Tools oder Aktionen die Richtlinie kontrolliert.
Flexible Aktionsverben:
+ „Erlauben Sie Benutzern, Rückerstattungen zu bearbeiten“
+ „Bearbeitung von Rückerstattungen zulassen“
+ „Benutzer können Anwendungen erstellen“
+ „Autorisieren Sie das Anzeigen von Audit-Logs“
Machen Sie genaue Angaben zum Tool:
Vage: ❌ „Benutzern den Zugriff auf Modelle ermöglichen“
Klar: ✓ „Erlaube dem Data-Science-Team den Zugriff auf das Analysemodell“
### Spezifikation des Zustands
Das „Wann“ gibt an, unter welchen Umständen die Richtlinie gilt.
Flexible bedingte Ausdrücke:
+ „... wenn der Betrag weniger als 500$ beträgt“
+ „... wenn es sich bei der Region um die USA, Kalifornien oder Großbritannien handelt“
+ „... nur wenn der Genehmigungsstatus „Vom Manager genehmigt“ lautet
+ „... sofern die Risikobewertung eingereicht wurde“
Seien Sie genau bei den Bedingungen:
Vage: ❌ „Erlaube Überweisungen, wenn der Betrag angemessen ist“
Präzise: ✓ „Erlaube Überweisungen, wenn der Betrag weniger als 10.000$ beträgt“
## Beispiele für Richtlinien
Die folgenden Beispiele zeigen, wie Richtlinien für natürliche Sprache mit klaren Prinzipien, Aktionen und Bedingungen strukturiert werden können.
**Topics**
+ [Beispiel 1: Einfache Richtlinie User-Based](#nl2cedar-example-1)
+ [Beispiel 2: Role-Based mit mehreren Bedingungen](#nl2cedar-example-2)
+ [Beispiel 3: Scope-Based Zugriff](#nl2cedar-example-3)
+ [Beispiel 4: Jeder mit Einschränkungen](#nl2cedar-example-4)
### Beispiel 1: Einfache Richtlinie User-Based
Erlauben Sie dem Benutzer, Rückerstattungen zu bearbeiten, wenn der Betrag weniger als 500$ beträgt.
Elemente:
+ **Wer:** User Refund-Agent
+ **Was**: Rückerstattungen bearbeiten
+ **Wann:** Der Betrag beträgt weniger als 500 USD
### Beispiel 2: Role-Based mit mehreren Bedingungen
Erlauben Sie Benutzern mit der Rolle Versicherungsagent, den Versicherungsschutz zu aktualisieren, wenn die Versicherungsart „Haftung“ oder „Kollision“ lautet und die Police aktiv ist.
Elemente:
+ **Wer:** Benutzer mit der Rolle Versicherungsagent
+ **Was: Versicherungsschutz aktualisieren**
+ **Wann:** Die Versicherungsart ist Haftung oder Kollision UND die Police ist aktiv
### Beispiel 3: Scope-Based Zugriff
Erlauben Sie Benutzern mit dem Geltungsbereich travel:book, Flugbuchungen zu erstellen, wenn die Region nicht in der EU liegt und das Produkt dafür in Frage kommt.
Elemente:
+ **Wer:** Benutzer mit Scope travel:book
+ **Was: Flugbuchungen** erstellen
+ **Wann:** Die Region gehört nicht zur EU UND das Produkt ist teilnahmeberechtigt
### Beispiel 4: Jeder mit Einschränkungen
Erlauben Sie allen Benutzern, Modellergebnisse anzuzeigen, wenn die Datensensitivität gering oder mittel ist und der Ergebnistyp Risikobewertung ist.
Elemente:
+ **Wer:** alle Benutzer
+ **Was:** Modellergebnisse anzeigen
+ **Wann:** Die Datensensitivität ist niedrig oder mittel UND der Ergebnistyp ist Risiko-Score
## Syntax der Bedingung
Unter bestimmten Bedingungen werden Richtlinien oft mehrdeutig. So schreiben Sie klare, überprüfbare Bedingungen.
**Topics**
+ [Numerische Vergleiche](#nl2cedar-numeric-comparisons)
+ [Übereinstimmende Zeichenketten](#nl2cedar-string-matching)
+ [Boolesche Bedingungen](#nl2cedar-boolean-conditions)
+ [Existenz des Feldes](#nl2cedar-field-existence)
### Numerische Vergleiche
Gute Beispiele:
+ „wenn der Betrag weniger als 500$ beträgt“
+ „wenn der Deckungsbetrag unter 5 Millionen liegt“
+ „wenn der Anspruch 10.000.000 USD übersteigt“
+ „wenn die Anzahl der Passagiere genau 2 beträgt
Vermeiden Sie vage Begriffe:
+ ❌ „wenn der Betrag gering ist“
+ ❌ „wenn die Deckung hoch ist“
### Übereinstimmende Zeichenketten
Genaue Übereinstimmung:
+ „wenn die Region in den USA liegt“
+ „wenn die Zahlungsmethode Kreditkarte ist“
+ „wenn der Status genehmigt ist“
Mehrere Optionen:
+ „wenn es sich bei der Region um die USA, Kalifornien oder Großbritannien handelt“
+ „wenn der Entscheidungstyp „Genehmigen“ oder „Weiterempfehlen“ lautet
Musterabgleich:
+ „wenn die E-Mail @example .com enthält“
+ „wenn der Bereich admin:write enthält“
Negation:
+ „wenn die Region nicht EU ist“
+ „wenn die Einstufung nicht eingeschränkt ist“
### Boolesche Bedingungen
Direkte Kontrollen:
+ „wenn das Produkt in Frage kommt“
+ „wenn die Risikobewertung eingereicht wird“
+ „wenn Expressversand angefordert wird“
Negation:
+ „wenn das Produkt nicht in Frage kommt“
+ „wenn die Risikobewertung nicht eingereicht wird“
### Existenz des Feldes
Felder erforderlich:
+ „wenn ein Grund angegeben wird“
+ „wenn eine Anwendungs-ID existiert“
+ „wenn das Rückgabedatum angegeben ist“
## Bedingungen kombinieren
Echte Richtlinien erfordern oft mehrere Bedingungen. Verwenden Sie klare logische Konnektoren.
**Topics**
+ [UND Logik (alles muss wahr sein)](#nl2cedar-and-logic)
+ [ODER-Logik (Mindestens eine muss wahr sein)](#nl2cedar-or-logic)
+ [Komplexe Logik](#nl2cedar-complex-logic)
### UND Logik (alles muss wahr sein)
Verwende Wörter wie: „und“, „auch“, „zusätzlich“, „während“, „mit“
Beispiel:
Erlauben Sie Bewerbungen, wenn die Region USA ist und das Produkt berechtigt ist und das Gebiet aktiv ist.
### ODER-Logik (Mindestens eine muss wahr sein)
Verwenden Sie Wörter wie: „oder“, „alternativ“, „entweder“
Beispiel:
Erlauben Sie die Genehmigung, wenn der Antrag 10.000.000$ übersteigt oder das Risikoniveau hoch oder kritisch ist.
### Komplexe Logik
Verwenden Sie für komplexe Bedingungen eine klare Struktur:
Beispiel:
Erlauben Sie den Abschluss, wenn die Workflow-Phase abgeschlossen oder genehmigt ist und der Compliance-Status bestanden ist und die Autorität Manager oder Direktor lautet.
## Häufige Fallstricke
Vermeiden Sie diese häufigen Fehler beim Schreiben von Richtlinien für natürliche Sprache, um sicherzustellen, dass sie korrekt in die Cedar-Syntax konvertiert werden.
**Topics**
+ [Fehler 1: Vage Prinzipien](#nl2cedar-mistake-1)
+ [Fehler 2: Mehrdeutige Aktionen](#nl2cedar-mistake-2)
+ [Fehler 3: Subjektive Bedingungen](#nl2cedar-mistake-3)
+ [Fehler 4: Fehlende Bedingungen](#nl2cedar-mistake-4)
+ [Fehler 5: Unklare Logik](#nl2cedar-mistake-5)
### Fehler 1: Vage Prinzipien
Schlecht: „Erlaube den Zugriff auf das Rückerstattungstool“
Gut: „Erlaube dem Benutzer, auf das Rückerstattungstool zuzugreifen“
### Fehler 2: Mehrdeutige Aktionen
Schlecht: „Benutzern den Zugriff auf Daten erlauben“
Gut: „Benutzern das Einsehen von Patientenakten ermöglichen“
### Fehler 3: Subjektive Bedingungen
Schlecht: „Erlaube Überweisungen, wenn der Betrag angemessen ist“
Gut: „Erlaube Überweisungen, wenn der Betrag weniger als 10.000$ beträgt“
### Fehler 4: Fehlende Bedingungen
Schlecht: „Erlaube Benutzern mit dem Geltungsbereich admin:write, die Abdeckung zu aktualisieren“
Gut: „Erlaubt Benutzern mit dem Geltungsbereich admin:write, den Versicherungsschutz zu aktualisieren, wenn die Police aktiv ist und die Versicherungsart Haftung oder Kollision ist“
### Fehler 5: Unklare Logik
Schlecht: „Zulassen, wenn A oder B und C“
Gut: „Zulassen, wenn (A oder B) und C“ oder „Zulassen, wenn A oder (B und C)“