View a markdown version of this page

Document-level Zugriffskontrollen - Amazon Bedrock
FunktionsweiseACL-Erkennung aktivierenGlobale ACL-DateistrukturPer-document Metadaten-DateienÜberprüfen Ihrer KonfigurationFehlerbehebung

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Document-level Zugriffskontrollen

ACL-Erkennung ist keine Autorisierung

Die Bedrock Managed Knowledge Base bietet ACL-aware Filterung, keine Sicherheitsgrenze. Bedrock Managed Knowledge Base authentifiziert keine Endbenutzer — Ihre Anwendung ist dafür verantwortlich, Benutzer zu authentifizieren und den verifizierten Identitätskontext weiterzugeben. Da Bedrock Managed Knowledge Base die Authentizität des von Ihnen angegebenen Benutzerkontextes nicht überprüfen kann, filtert diese Funktion die Ergebnisse auf der Grundlage der von Ihnen angegebenen Identität, stellt jedoch keine echte Autorisierung dar. Sie dürfen sich nicht auf diese Funktion als alleinigen Zugriffskontrollmechanismus ohne vorgeschaltete Authentifizierung verlassen.

Amazon S3-Datenquellen unterstützen optional die Zugriffskontrolle auf Dokumentebene. Im Gegensatz zu anderen Konnektoren verfügt Amazon S3 über kein systemeigenes Berechtigungssystem zum Crawlen. Sie definieren ACLs also anhand von Konfigurationsdateien, die Sie verwalten. Eine Übersicht über die ACL-Erkennung aller Connectors finden Sie unter. Aktivierung der Sensibilisierung für Zugriffskontrolllisten

Funktionsweise

Bei einer ACL-enabled Amazon S3-Datenquelle wendet Bedrock Managed Knowledge Base bei der Filterung vor dem Abruf die vom Kunden bereitgestellten Zugriffskontrolllisten an und gibt nur Dokumente zurück, auf die der abfragende Benutzer zugreifen darf. Real-time Die ACL-Überprüfung wird für Amazon S3 nicht unterstützt, da die vom Kunden bereitgestellten ACL-Metadaten die Quelle der Wahrheit sind.

ACL-Erkennung aktivieren

Um die ACL-Erkennung für eine Amazon S3-Datenquelle aclEnabled zu aktivieren, setzen Sie auf true in connectorParameters und definieren Sie die Zugriffsberechtigungen mit einer von zwei Methoden:

  • Globale ACL-Konfigurationsdatei — Eine einzige zentralisierte JSON-Datei, die Zugriffsberechtigungen auf Ordnerebene (Präfix) definiert. Ideal für Organisationen mit stabilen Berechtigungsstrukturen. Änderungen an der Globaldatei erfordern eine Neuindizierung des betroffenen Präfixes.

  • Document-level Metadatendateien — Jedes Dokument hat seine eigene Metadatendatei, die Informationen zur Zugriffskontrolle enthält. Dies ermöglicht schnellere Indexaktualisierungen, wenn sich Berechtigungen ändern, da nur die betroffenen Dokumente neu indexiert werden müssen.

Wichtig

Bei ACL-enabled Amazon S3-Datenquellen werden Dokumente ohne zugehörigen ACL-Eintrag nicht aufgenommen. Stellen Sie sicher, dass für jedes Dokument eine ACL entweder in der globalen ACL-Datei oder in der zugehörigen Metadatendatei definiert ist.

"connectorParameters": {
    "type": "S3",
    "version": "1",
    "aclEnabled": true,
    "connectionConfiguration": {
        "bucketName": "your-bucket-name",
        "bucketOwnerAccountId": "123456789012"
    },
    "aclConfiguration": {
        "globalAccessControlListS3Uri": "s3://your-bucket-name/acl/global-acl.json"
    }
}

Globale ACL-Dateistruktur

Die globale ACL-Datei ist ein JSON-Array, in dem jeder Eintrag einer Reihe von Zugriffskontrolleinträgen ein Schlüsselpräfix zuordnet. Jeder keyPrefix ist die absolute Amazon S3-URI eines Ordners (gilt für alle Dokumente darunter) oder eines einzelnen Dokuments.

[
    {
        "keyPrefix": "s3://your-bucket-name/finance/",
        "aclEntries": [
            {
                "Name": "user1@example.com",
                "Type": "USER",
                "Access": "ALLOW"
            }
        ]
    }
]

Jedes aclEntries Element enthält:

  • Name— Die E-Mail-Adresse eines Benutzers.

  • Type— Muss seinUSER.

  • Access— Entweder ALLOW oderDENY. Überschreibungen verweigern, zulassen.

Per-document Metadaten-Dateien

Als Alternative zur globalen ACL-Datei können Sie ACLs pro Dokument mithilfe von Metadatendateien definieren. Erstellen Sie für jedes Dokument eine Datei, die filename.metadata.json im gleichen Amazon S3-Pfad benannt ist. Schließen Sie ein accessControlList Array mit demselben Eingabeformat wie die globale Datei ein.

{
    "metadataAttributes": {},
    "accessControlList": [
        {
            "Name": "user1@example.com",
            "Type": "USER",
            "Access": "ALLOW"
        },
        {
            "Name": "user2@example.com",
            "Type": "USER",
            "Access": "DENY"
        }
    ]
}

Per-document Metadaten haben Vorrang vor der globalen ACL-Datei. Wenn ein Dokument sowohl einen passenden globalen Präfixeintrag als auch eine Metadatendatei pro Dokument hat, werden die Metadaten pro Dokument verwendet.

Anmerkung

Die ACL-Konfigurationsdatei muss im selben Amazon S3-Bucket wie Ihr Datenquelleninhalt gespeichert werden.

Überprüfen Ihrer Konfiguration

Da Amazon S3-ACLs vom Kunden bereitgestellt werden, überprüfen Sie sie, bevor Sie eine Anfrage stellen:

  1. Confirm aclEnabled steht true in der Datenquelle. connectorParameters

  2. Vergewissern Sie sich, dass jedes Dokument eine ACL hat — entweder einen Eintrag in der globalen ACL-Datei oder eine .metadata.json Datei pro Dokument. Dokumente ohne ACL werden nicht aufgenommen.

  3. Validieren Sie das ACL-JSON: Jeder Eintrag hat Name (Benutzer-E-Mail), Type (USER) und Access (ALLOWoderDENY), und die ACL-Dateien befinden sich im selben Bucket wie Ihr Inhalt.

  4. Bestätigen Sie, dass die E-Mail-Adresse eines Testbenutzers genau mit der E-Mail-Adresse Name in einem ALLOW Eintrag für ein Dokument übereinstimmt, das er voraussichtlich abrufen wird.

Fehlerbehebung

Anmerkung

Fehlkonfigurationen der ACL führen beim Abrufen nicht zu expliziten Fehlern. Beim Abrufen schlägt das Schließen fehl: Die betroffenen Dokumente werden stillschweigend weggelassen, sodass eine Abfrage weniger oder gar keine Ergebnisse als einen Fehler zurückgibt. Verwenden Sie die oben genannten Verifizierungsprüfungen, um diese Probleme zu diagnostizieren.

ACL-enabled Amazon S3-Symptome, Ursachen und Problembehebungen
Symptom Wahrscheinliche Ursache Reparieren
Retrieve gibt 0 Ergebnisse für einen Benutzer zurück, der Zugriff haben sollte. Die E-Mail-Adresse des Benutzers stimmt mit keinem ACL-Eintrag überein (E-Mail-Konflikt). Stellen Sie sicher, dass die ACL genau Name mit der E-Mail-Adresse des Benutzers übereinstimmt.
Ein Dokument wird niemals an jemanden zurückgegeben. Das Dokument hat keinen ACL-Eintrag und wurde daher nicht aufgenommen. Fügen Sie über die globale ACL-Datei oder eine Datei pro Dokument eine ACL für das Dokument .metadata.json hinzu und synchronisieren Sie dann erneut.
Eine ACL pro Dokument wird nicht wirksam. Die .metadata.json Datei hat einen falschen Namen oder befindet sich im falschen Pfad. Benennen Sie sie filename.metadata.json im gleichen S3-Pfad. Metadaten pro Dokument überschreiben die globale Datei.
ACL-Änderungen werden nicht berücksichtigt. Globale ACL-Dateiänderungen erfordern eine Neuindizierung des betroffenen Präfixes. Synchronisieren Sie das betroffene Präfix erneut.