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-Awareness ist keine Autorisierung**
Die Bedrock Managed Knowledge Base bietet ACL-aware Filterung, keine Sicherheitsgrenze. Bedrock Managed Knowledge Base authentifiziert keine Endbenutzer — Ihre Anwendung ist für die Authentifizierung von Benutzern und die Weitergabe des verifizierten Identitätskontextes verantwortlich. 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 vorherige Authentifizierung verlassen.
Benutzerdefinierte Datenquellen unterstützen optional die Zugriffskontrolle auf Dokumentebene. Im Gegensatz zu gecrawlten Konnektoren verfügt eine benutzerdefinierte Datenquelle über kein systemeigenes Berechtigungssystem. Sie geben daher die Zugriffskontrollliste (ACL) für jedes Dokument an, wenn Sie es im Rahmen des Vorgangs aufnehmen. `IngestKnowledgeBaseDocuments` Eine Übersicht über die ACL-Awareness für alle Konnektoren finden Sie unter. [Aktivierung des Bewusstseins für Zugriffskontrolllisten](kb-managed-acl.md)
## Funktionsweise
Bei einer ACL-enabled benutzerdefinierten Datenquelle wendet Bedrock Managed Knowledge Base beim Filtern 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-Prüfung wird für benutzerdefinierte Datenquellen nicht unterstützt, da die vom Kunden bereitgestellten ACL-Metadaten die Quelle der Wahrheit sind.
## Aktivieren Sie ACL Awareness
Um ACL Awareness für eine benutzerdefinierte Datenquelle `aclEnabled` zu aktivieren, legen Sie `true` `connectorParameters` bei der Erstellung oder Aktualisierung der Datenquelle die Einstellung auf fest. Informationen zur Konfigurationsstruktur der Datenquelle finden Sie unter[Benutzerdefiniert](kb-managed-ds-custom.md).
```
"connectorParameters": {
"type": "CUSTOM",
"version": "1",
"aclEnabled": true
}
```
## Sorgen Sie für Zugriffskontrollen, wenn Sie Dokumente aufnehmen
Sie geben die ACL eines Dokuments über das `accessControlList` Feld auf dem Dokument `metadata` in der `IngestKnowledgeBaseDocuments` Anfrage an. Die ACL-Quelle wird durch dasselbe Feld bestimmt`metadata.type`, das steuert, woher die Metadatenattribute stammen:
+ **`IN_LINE_ATTRIBUTE`**— Die ACL wird aus dem `accessControlList` Array im Hauptteil der Anfrage gelesen.
+ **`S3_LOCATION`**— Die ACL wird aus dem `accessControlList` Array in der `.metadata.json` Datei des Dokuments in Amazon S3 gelesen.
Da `accessControlList` sich ein Dokument `metadata` unter und nicht als Feld der obersten Ebene befindet`KnowledgeBaseDocument`, hat es eine einzige ACL-Quelle, die von `metadata.type` gesteuert wird. Dadurch wird verhindert, dass widersprüchliche ACLs für dasselbe Dokument bereitgestellt werden (z. B. eine Inline-ACL für die Anfrage und eine ACL in der S3-Datei). Der Kompromiss besteht darin, dass Sie eine Inline-ACL nicht mit S3-based Metadatenattributen oder eine S3-based ACL mit Inline-Metadatenattributen für dasselbe Dokument kombinieren können.
Jeder `accessControlList` Eintrag enthält:
+ `name`— Die E-Mail-Adresse eines Benutzers.
+ `type`— Muss sein`USER`.
+ `access`— Entweder `ALLOW` oder`DENY`. Verweigern, Überschreibungen zulassen.
### Inline-ACL (metadata.type = IN\_LINE\_ATTRIBUTE)
Geben Sie die `accessControlList` direkt im Anfragetext zusammen mit den Inline-Metadatenattributen an.
```
PUT /knowledgebases/{{KB12345678}}/datasources/{{DS12345678}}/documents HTTP/1.1
Content-type: application/json
{
"documents": [
{
"content": {
"dataSourceType": "CUSTOM",
"custom": {
"customDocumentIdentifier": {
"id": "hr-policy-2026"
},
"inlineContent": {
"textContent": {
"data": "Annual leave policy: All full-time employees are entitled to..."
},
"type": "TEXT"
},
"sourceType": "IN_LINE"
}
},
"metadata": {
"type": "IN_LINE_ATTRIBUTE",
"inlineAttributes": [
{
"key": "department",
"value": { "stringValue": "HR", "type": "STRING" }
}
],
"accessControlList": [
{
"name": "{{alice@example.com}}",
"type": "USER",
"access": "ALLOW"
},
{
"name": "{{bob@example.com}}",
"type": "USER",
"access": "DENY"
}
]
}
}
]
}
```
### S3-based ACL (metadata.type = S3\_LOCATION)
Zeigen Sie mit den Metadaten des Dokuments auf eine `.metadata.json` Datei in Amazon S3. Sowohl die Metadatenattribute als auch die `accessControlList` werden aus dieser Datei gelesen.
```
"metadata": {
"type": "S3_LOCATION",
"s3Location": {
"uri": "s3://{{amzn-s3-demo-bucket}}/{{hr-policy-2026}}.metadata.json"
}
}
```
Die `.metadata.json` Datei verwendet dasselbe Format wie die [Metadatendateien pro Dokument](kb-managed-ds-s3-acl.md#kb-managed-ds-s3-acl-perdoc) für Amazon S3 S3-Datenquellen. Diese Datei verwendet großgeschriebene ACL-Feldnamen (`Name`,`Type`,`Access`), die sich von den in der Inline-Anfrage verwendeten kleingeschriebenen Feldnamen (`name``type`,,`access`) unterscheiden.
```
{
"metadataAttributes": {},
"accessControlList": [
{
"Name": "{{alice@example.com}}",
"Type": "USER",
"Access": "ALLOW"
},
{
"Name": "{{bob@example.com}}",
"Type": "USER",
"Access": "DENY"
}
]
}
```
## Überprüfen Ihrer Konfiguration
Da benutzerdefinierte ACLs vom Kunden bereitgestellt werden`IngestKnowledgeBaseDocuments`, überprüfen Sie sie, bevor Sie eine Abfrage durchführen:
1. Bestätigen Sie, dass `aclEnabled` es sich `true` in der Datenquelle befindet `connectorParameters` () `type``CUSTOM`.
1. Vergewissern Sie sich, dass jedes aufgenommene Dokument ein `accessControlList` Under-`metadata`, und das der ACL-Quelle `metadata.type` entspricht (`IN_LINE_ATTRIBUTE`für Inline-Dateien, `S3_LOCATION` für eine S3-Datei).
1. Vergewissern Sie sich, dass die Groß- und Kleinschreibung im ACL-Eingabefeld mit der Quelle übereinstimmt: Kleinbuchstaben `name``type`//`access`für Inline-ACLs, Großbuchstaben`Name`/`Type`/`Access`für die S3-Datei. `.metadata.json`
1. Vergewissern Sie sich, dass die E-Mail-Adresse eines Testbenutzers genau mit der `name` in einem `ALLOW` Eintrag für ein Dokument übereinstimmt, das der Benutzer voraussichtlich abrufen wird.
## Fehlerbehebung
**Anmerkung**
ACL-Fehlkonfigurationen führen nicht zu expliziten Fehlern beim Abrufen. Der Abruf schlägt fehl: Die betroffenen Dokumente werden stillschweigend ausgelassen, sodass eine Abfrage weniger oder gar keine Ergebnisse als einen Fehler zurückgibt. Verwenden Sie die oben genannten Überprüfungsprüfungen, um diese Probleme zu diagnostizieren.
**ACL-enabled Benutzerdefinierte Symptome, Ursachen und Lösungen**
| Symptom | Wahrscheinliche Ursache | Reparieren |
| --- | --- | --- |
| Retrieve gibt 0 Ergebnisse für einen Benutzer zurück, der Zugriff haben sollte. | Die userId E-Mail stimmt mit keinem accessControlList Eintrag überein. | Ordnen Sie die E-Mail-Adresse des Benutzers der name in einem ALLOW Eintrag zu. |
| Eine Inline-ACL wird abgelehnt oder ignoriert. | Falsche Groß- und Kleinschreibung im Feld oder metadata.type nichtIN\_LINE\_ATTRIBUTE. | Verwenden Siename/type/in Kleinbuchstaben access und setzen Sie metadata.type den Wert aufIN\_LINE\_ATTRIBUTE. |
| Eine S3-based ACL wird nicht angewendet. | metadata.typeist nichtS3\_LOCATION, oder die .metadata.json Datei fehltaccessControlList. | Auf metadata.type einstellen S3\_LOCATION und accessControlList in die Datei aufnehmen. |
| Ein Dokument wird niemals an Dritte zurückgegeben. | Das Dokument wurde ohne eine accessControlList aufgenommen. | Re-ingest das Dokument mit einemaccessControlList. |