Einführung
Der Assistent ist bereits auf documents.read begrenzt, doch ein erlaubtes Werkzeug kann weiterhin ein verbotenes Dokument anfordern. Du wartest eine frische Schulungsinstanz, deren Objektrichtlinie noch alle Abrufe erlaubt.
Ergänze eine kleine Python-Regel in zwei Stufen: zuerst Eigentum schützen, danach ausdrückliche Freigaben erhalten. Der Server bezieht Identität aus authentifizierten Sitzungen, nicht aus Vorschlagsargumenten. Alle Dokumente sind synthetisch, alle Vorschläge offen wiedergegeben; Lesen und Autorisierung sind echt. Die Terminalkenntnisse des vorherigen Labs reichen; Python-Syntax wird hier erklärt.
Lesen an den authentifizierten Eigentümer binden
In diesem Schritt verhinderst du, dass ein erlaubtes Werkzeug das private Dokument eines anderen Nutzers erreicht.
Wähle zu Beginn dieses Schritts den Tab Test Client in der Lab-Oberfläche aus.
Nutze diese Zugriffstabelle. owner und shared_with sind gespeicherte Dokumentfelder, keine vorgeschlagenen Werte.
| Dokument | Eigentümer | Freigegeben für | Alice darf lesen | Bob darf lesen |
|---|---|---|---|---|
alice-notes |
alice |
niemanden | ja | nein |
bob-notes |
bob |
niemanden | nein | ja |
team-plan |
bob |
alice |
ja | ja |
In Test Client wählt --as bob Bobs vorbereiteten authentifizierten Zugang. Ohne Option wird Alice gewählt. Bestätige zuerst normales Eigentümerlesen:
Wechsle zum Tab Test Client, bevor du den folgenden Befehl ausführst.
assistant call documents.read alice-notes
Erwartet werden HTTP 200 und Alices Inhalt. Reproduziere nun die fehlende Objektprüfung:
assistant call documents.read bob-notes
Fälschlich kommen HTTP 200 und Synthetic Bob private budget zurück. Es werden keine echten privaten Informationen verwendet. Die Werkzeugliste allein schützte das Objekt nicht.
Wechsle zum Tab Policy Editor. Sieh die kleine Richtlinie an:
Wechsle zum Tab Policy Editor, bevor du den folgenden Befehl ausführst.
cat /home/labex/project/policy.py
def can_read(principal, doc): definiert eine Funktion mit zwei Eingaben. Das eingerückte return True erlaubt derzeit jedem den Zugriff. Ein Python-Dictionary speichert benannte Felder: principal["id"] liest die authentifizierte Identität und doc["owner"] das gespeicherte Eigentum. == vergleicht Werte und liefert einen booleschen Wert, wahr oder falsch. Vier führende Leerzeichen halten return innerhalb der Funktion.
Ersetze die Funktion durch einen Eigentümervergleich. Dieselbe wörtliche Here-Dokument-Methode aus dem vorigen Lab schreibt die gesamte Datei:
cat > /home/labex/project/policy.py <<'EOF'
def can_read(principal, doc):
return doc["owner"] == principal["id"]
EOF
Wechsle zum Tab Test Client. Wiederhole die Anfrage nach dem privaten Dokument eines anderen Benutzers:
Wechsle zum Tab Test Client, bevor du den folgenden Befehl ausführst.
assistant call documents.read bob-notes
Erwartet werden HTTP 403 und document_denied. Anders als bei tool_denied ist Lesen als Operation erlaubt, doch dieses Objekt ist für Alice verboten. Teste die Gegenrichtung:
assistant --as bob call documents.read alice-notes
Auch sie muss abgelehnt werden. Bobs eigenes Dokument muss lesbar bleiben:
assistant --as bob call documents.read bob-notes
Erwarte HTTP 200. Scheitern alle Abrufe mit policy_error, wechsle zum Tab Policy Editor und wiederhole die Änderung mit korrekter Einrückung und Anführungszeichen. Wechsle zurück zu Test Client, bevor du Abrufe wiederholst. Der Server lädt die Funktion je Anfrage neu. Diese Zwischenregel stellt Freigaben absichtlich noch nicht wieder her; das folgt im nächsten Schritt.
Freigaben erhalten, ohne behaupteten Nutzern zu vertrauen
In diesem Schritt erlaubst du gespeicherte Freigaben und verweigerst eine gefälschte Identität im Vorschlag.
Wähle zu Beginn dieses Schritts den Tab Policy Editor in der Lab-Oberfläche aus.
Die Eigentümerregel blockiert Alice bei team-plan, obwohl Bob Zugriff ausdrücklich freigegeben hat. In Python prüft in die Zugehörigkeit zu einer Liste, und or akzeptiert eine der Bedingungen. Verbinde Eigentum mit Mitgliedschaft in der gespeicherten Freigabeliste. In Policy Editor:
Wechsle zum Tab Policy Editor, bevor du den folgenden Befehl ausführst.
cat > /home/labex/project/policy.py <<'EOF'
def can_read(principal, doc):
return doc["owner"] == principal["id"] or principal["id"] in doc["shared_with"]
EOF
Wechsle zum Tab Test Client. Prüfe die legitime Freigabe:
Wechsle zum Tab Test Client, bevor du den folgenden Befehl ausführst.
assistant call documents.read team-plan
Erwartet werden HTTP 200 und Synthetic shared project plan. Sende nun eine gefälschte Identität. --claim bob fügt user_id: bob zu unvertrauenswürdigen Argumenten hinzu. Es wählt nicht Bobs authentifizierten Zugang:
assistant replay documents.read bob-notes --claim bob
Erwartet werden HTTP 403, Principal alice und document_denied. Der Server ordnet vor dem Richtlinienaufruf den echten Zugang Alice zu und ignoriert die behauptete Identität. Probiere auch den direkten Handler:
assistant call documents.read bob-notes --claim bob
Er muss ebenso ablehnen. --as bob und --claim bob haben bewusst verschiedene Bedeutungen: Ersteres nutzt einen vorbereiteten Zugang Bobs, Letzteres ist nur Text im Vorschlag.
Wechsle zum Tab Assistant Tool Lab, melde dich als alice mit training-alice an, wähle documents.read, gib bob-notes ein, setze bob in Untrusted user_id (optional) und klicke auf Replay proposal. Das Serverergebnis muss weiterhin alice identifizieren und das private Dokument ablehnen. Ändere das Dokument zu team-plan, lösche die Behauptung und wiederhole: Nützliches freigegebenes Lesen muss gelingen.
Behalte die Leserichtlinie in tools.json. Der Prüfpunkt testet beide Konten, beide Routen, Eigentum/Freigabe/Privatheit und unbekannte entbehrliche Dokumente. Feste Dokument-IDs, alles erlauben, einem vorgeschlagenen Nutzer vertrauen oder alles verweigern erfüllen diese Matrix nicht. Tippfehler behebst du durch vollständiges Neuschreiben der kleinen Funktion und erneutes Lesen.
Zusammenfassung
Du hast Dokumentzugriff anhand authentifizierter Identität und gespeicherten Eigentums oder Freigaben durchgesetzt. Ein gefälschtes Vorschlagsfeld wird nicht zur Autorität. Der Server liefert weiter nützliche eigene und freigegebene Dokumente und verweigert fremde private Objekte sowie unnötige Operationen. Dies demonstriert deterministische Werkzeugautorisierung, keine Zuverlässigkeit eines laufenden Modells.
