Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Document-level contrôles d'accès
**La connaissance de l'ACL n'est pas une autorisation**
La base de connaissances gérée Bedrock fournit un ACL-aware filtrage et non une limite de sécurité. La base de connaissances gérée Bedrock n'authentifie pas les utilisateurs finaux. Votre application est chargée d'authentifier les utilisateurs et de transmettre le contexte d'identité vérifié. Étant donné que Bedrock Managed Knowledge Base ne peut pas vérifier l'authenticité du contexte utilisateur que vous fournissez, cette fonctionnalité filtre les résultats en fonction de l'identité que vous fournissez mais ne constitue pas une véritable autorisation. Vous ne devez pas vous fier à cette fonctionnalité comme seul mécanisme de contrôle d'accès sans authentification en amont.
Les sources de données personnalisées prennent en charge le contrôle d'accès au niveau du document en option. Contrairement aux connecteurs analysés, une source de données personnalisée ne possède aucun système d'autorisation natif. Vous devez donc fournir la liste de contrôle d'accès (ACL) pour chaque document lorsque vous l'ingérez avec l'`IngestKnowledgeBaseDocuments`opération. Pour une vue d'ensemble de la prise en compte des ACL sur tous les connecteurs, voir[Sensibilisation aux listes de contrôle d'accès](kb-managed-acl.md).
## Comment ça marche
Pour une source de données ACL-enabled personnalisée, Bedrock Managed Knowledge Base applique les listes de contrôle d'accès fournies par le client lors du filtrage préalable à la récupération, renvoyant uniquement les documents auxquels l'utilisateur demandeur est autorisé à accéder. Real-time La vérification ACL n'est pas prise en charge pour les sources de données personnalisées car les métadonnées ACL fournies par le client sont la source de vérité.
## Activer la sensibilisation à l'ACL
Pour activer la prise en compte des ACL pour une source de données personnalisée, définissez `aclEnabled` cette option sur `true` in `connectorParameters` lorsque vous créez ou mettez à jour la source de données. Pour la structure de configuration de la source de données, consultez[Personnalisé](kb-managed-ds-custom.md).
```
"connectorParameters": {
"type": "CUSTOM",
"version": "1",
"aclEnabled": true
}
```
## Fournissez des contrôles d'accès lorsque vous ingérez des documents
Vous fournissez l'ACL d'un document par le biais du `accessControlList` champ du document `metadata` dans la `IngestKnowledgeBaseDocuments` demande. La source de l'ACL est déterminée par `metadata.type` le même champ qui contrôle l'origine des attributs de métadonnées :
+ **`IN_LINE_ATTRIBUTE`**— L'ACL est lue à partir du `accessControlList` tableau dans le corps de la requête.
+ **`S3_LOCATION`**— L'ACL est lue à partir du `accessControlList` tableau contenu dans le `.metadata.json` fichier du document dans Amazon S3.
Parce qu'`accessControlList`il se `metadata` trouve en dessous plutôt qu'en tant que champ de premier niveau`KnowledgeBaseDocument`, un document possède une source ACL unique, contrôlée par`metadata.type`. Cela évite que des ACL conflictuelles ne soient fournies pour le même document (par exemple, une ACL en ligne sur la demande et une ACL dans le fichier S3). L'inconvénient est qu'il est impossible de combiner une ACL en ligne avec des attributs de S3-based métadonnées, ou une S3-based ACL avec des attributs de métadonnées en ligne, pour le même document.
Chaque `accessControlList` entrée contient :
+ `name`— L'adresse e-mail d'un utilisateur.
+ `type`— Ça doit être le cas`USER`.
+ `access`— L'un `ALLOW` ou l'autre`DENY`. Refuser les dérogations et autoriser.
### ACL en ligne (metadata.type = IN\_LINE\_ATTRIBUTE)
Fournissez-les `accessControlList` directement dans le corps de la demande, à côté des attributs de métadonnées intégrés.
```
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 (métadata.type = S3\_LOCATION)
Pointez les métadonnées du document vers un `.metadata.json` fichier dans Amazon S3. Les attributs de métadonnées et les `accessControlList` sont lus à partir de ce fichier.
```
"metadata": {
"type": "S3_LOCATION",
"s3Location": {
"uri": "s3://{{amzn-s3-demo-bucket}}/{{hr-policy-2026}}.metadata.json"
}
}
```
Le `.metadata.json` fichier utilise le même format que les [fichiers de métadonnées par document pour les](kb-managed-ds-s3-acl.md#kb-managed-ds-s3-acl-perdoc) sources de données Amazon S3. Ce fichier utilise des noms de champs ACL en majuscules (`Name``Type`,,`Access`), qui diffèrent des noms de champs en minuscules (`name`,`type`,`access`) utilisés dans la demande en ligne.
```
{
"metadataAttributes": {},
"accessControlList": [
{
"Name": "{{alice@example.com}}",
"Type": "USER",
"Access": "ALLOW"
},
{
"Name": "{{bob@example.com}}",
"Type": "USER",
"Access": "DENY"
}
]
}
```
## Vérification de votre configuration
Dans la mesure où les ACL personnalisées sont fournies par le client`IngestKnowledgeBaseDocuments`, validez-les avant de demander :
1. Confirmez que `true` cela `aclEnabled` se trouve dans la source de données `connectorParameters` (`type``CUSTOM`).
1. Vérifiez que chaque document ingéré inclut un `accessControlList` sous-titre `metadata` et qu'il `metadata.type` correspond à la source de l'ACL (`IN_LINE_ATTRIBUTE`pour un fichier en ligne, `S3_LOCATION` pour un fichier S3).
1. Vérifiez que le cadre du champ de saisie ACL correspond à la source : minuscule`name`/`type`/`access`pour les ACL en ligne, majuscule`Name`/`Type`/`Access`pour le fichier S3. `.metadata.json`
1. Vérifiez que l'adresse e-mail d'un utilisateur test correspond exactement `name` à celle d'une `ALLOW` entrée pour un document que vous souhaitez qu'il récupère.
## Résolution des problèmes
**Note**
Les erreurs de configuration de l'ACL ne produisent pas d'erreurs explicites lors de la récupération. La récupération échoue à la fermeture : les documents concernés sont omis en silence, de sorte qu'une requête renvoie moins de résultats, voire aucun, plutôt qu'une erreur. Utilisez les contrôles de vérification ci-dessus pour diagnostiquer ces problèmes.
**ACL-enabled Symptômes, causes et correctifs personnalisés**
| Symptôme | Cause probable | Corriger |
| --- | --- | --- |
| Retrieve renvoie 0 résultat pour un utilisateur qui devrait y avoir accès. | L'userIde-mail ne correspond à aucune accessControlList entrée. | Alignez l'e-mail de l'utilisateur avec name celui d'une ALLOW entrée. |
| Une ACL intégrée est rejetée ou ignorée. | Le boîtier de terrain est incorrect ou ne metadata.type l'est pasIN\_LINE\_ATTRIBUTE. | Utilisezname/type/en minuscules access et réglez surmetadata.type. IN\_LINE\_ATTRIBUTE |
| Aucune S3-based ACL n'est appliquée. | metadata.typece n'est pas S3\_LOCATION le cas ou le .metadata.json fichier est manquantaccessControlList. | Définissez metadata.type S3\_LOCATION et incluez accessControlList dans le fichier. |
| Un document n'est jamais retourné à qui que ce soit. | Le document a été ingéré sans. accessControlList | Re-ingest le document avec unaccessControlList. |