Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
# Document-level controles de acceso
**El conocimiento de la ACL no es una autorización**
La base de conocimientos gestionada de Bedrock proporciona ACL-aware filtros, no un límite de seguridad. La base de conocimientos gestionada por Bedrock no autentica a los usuarios finales; su aplicación es responsable de autenticar a los usuarios y de transmitir el contexto de identidad verificado. Dado que Bedrock Managed Knowledge Base no puede verificar la autenticidad del contexto de usuario que usted proporciona, esta función filtra los resultados en función de la identidad que proporciona, pero no constituye una autorización verdadera. No debe confiar en esta función como único mecanismo de control de acceso sin una autenticación previa.
Las fuentes de datos personalizadas admiten opcionalmente el control de acceso a nivel de documento. A diferencia de los conectores rastreados, una fuente de datos personalizada no tiene un sistema de permisos nativo, por lo que debe proporcionar la lista de control de acceso (ACL) de cada documento cuando lo ingiere junto con la operación. `IngestKnowledgeBaseDocuments` Para obtener información general sobre el reconocimiento de las ACL en todos los conectores, consulte. [Habilitación del conocimiento de las listas de control de acceso](kb-managed-acl.md)
## Funcionamiento
Para obtener una fuente de datos ACL-enabled personalizada, la base de conocimiento gestionada de Bedrock aplica las listas de control de acceso proporcionadas por el cliente durante el filtrado previo a la recuperación y devuelve solo los documentos a los que el usuario que realiza la consulta puede acceder. Real-time La verificación de la ACL no es compatible con las fuentes de datos personalizadas porque los metadatos de la ACL proporcionados por el cliente son la fuente de la verdad.
## Habilite el reconocimiento de ACL
Para habilitar el reconocimiento de la ACL en una fuente de datos personalizada, `aclEnabled` `true` configúrelo en `connectorParameters` cuando cree o actualice la fuente de datos. Para ver la estructura de configuración de la fuente de datos, consulte[Personalizada](kb-managed-ds-custom.md).
```
"connectorParameters": {
"type": "CUSTOM",
"version": "1",
"aclEnabled": true
}
```
## Proporcione controles de acceso al ingerir documentos
La ACL de un documento se proporciona a través del `accessControlList` campo del documento de `metadata` la `IngestKnowledgeBaseDocuments` solicitud. La fuente de la ACL viene determinada por `metadata.type` el mismo campo que controla la procedencia de los atributos de los metadatos:
+ **`IN_LINE_ATTRIBUTE`**— La ACL se lee de la `accessControlList` matriz del cuerpo de la solicitud.
+ **`S3_LOCATION`**— La ACL se lee de la `accessControlList` matriz del `.metadata.json` archivo del documento en Amazon S3.
Como se `accessControlList` encuentra debajo de un campo de nivel superior y `metadata` no como un campo de nivel superior`KnowledgeBaseDocument`, un documento tiene una única fuente de ACL, controlada por`metadata.type`. Esto evita que se proporcionen ACL contradictorias para el mismo documento (por ejemplo, una ACL en línea en la solicitud y una ACL en el archivo S3). La desventaja es que no se puede combinar una ACL en línea con atributos de S3-based metadatos, o S3-based una ACL con atributos de metadatos en línea, para el mismo documento.
Cada entrada contiene`accessControlList`:
+ `name`— La dirección de correo electrónico de un usuario.
+ `type`— Debe serlo`USER`.
+ `access`— O lo uno `ALLOW` o lo otro`DENY`. Denegar el permiso de anulación.
### ACL en línea (metadata.type = IN\_LINE\_ATTRIBUTE)
Introdúzcalos `accessControlList` directamente en el cuerpo de la solicitud junto con los atributos de metadatos en línea.
```
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)
Dirija los metadatos del documento a un `.metadata.json` archivo de Amazon S3. Tanto los atributos de los metadatos como los que `accessControlList` se leen de ese archivo.
```
"metadata": {
"type": "S3_LOCATION",
"s3Location": {
"uri": "s3://{{amzn-s3-demo-bucket}}/{{hr-policy-2026}}.metadata.json"
}
}
```
El `.metadata.json` archivo usa el mismo formato que los [archivos de metadatos por documento](kb-managed-ds-s3-acl.md#kb-managed-ds-s3-acl-perdoc) para las fuentes de datos de Amazon S3. Este archivo utiliza nombres de campo de ACL en mayúsculas (`Name`,`Type`,`Access`), que difieren de los nombres de campo en minúsculas (`name`,`type`,`access`) que se utilizan en la solicitud en línea.
```
{
"metadataAttributes": {},
"accessControlList": [
{
"Name": "{{alice@example.com}}",
"Type": "USER",
"Access": "ALLOW"
},
{
"Name": "{{bob@example.com}}",
"Type": "USER",
"Access": "DENY"
}
]
}
```
## Verificación de la configuración
Como las ACL personalizadas las proporciona el cliente, valídalas antes de realizar la consulta`IngestKnowledgeBaseDocuments`:
1. Confirme `aclEnabled` que está `true` en la fuente de datos (). `connectorParameters` `type` `CUSTOM`
1. Confirme que cada documento ingerido incluya una referencia `accessControlList` inferior `metadata` y que `metadata.type` coincida con la fuente de ACL (`IN_LINE_ATTRIBUTE`en el caso de un archivo en línea, en el caso `S3_LOCATION` de un archivo S3).
1. Confirme que las mayúsculas del campo de entrada de la ACL coincidan con la fuente:`name`//en minúsculas `access` para las ACL en línea y`type`//en mayúscula `Name` para el archivo S3. `Type` `Access` `.metadata.json`
1. Confirma que el correo electrónico de un usuario de prueba coincide exactamente con el `name` de una `ALLOW` entrada de un documento que esperas que recupere.
## Resolución de problemas
**nota**
Las configuraciones incorrectas de las ACL no producen errores explícitos durante la recuperación. Se produce un error al cerrar la recuperación: los documentos afectados se omiten de forma silenciosa, por lo que la consulta arroja menos resultados o no arroja ningún resultado en lugar de un error. Utilice las comprobaciones de verificación anteriores para diagnosticar estos problemas.
**ACL-enabled Síntomas, causas y soluciones personalizados**
| Síntoma | Causa probable | Fix |
| --- | --- | --- |
| Retrieve devuelve 0 resultados para un usuario que debería tener acceso. | El userId correo electrónico no coincide con ninguna accessControlList entrada. | Alinee el correo electrónico del usuario con name el de una ALLOW entrada. |
| Se rechaza o ignora una ACL en línea. | La carcasa del campo es incorrecta o no metadata.type IN\_LINE\_ATTRIBUTE lo es. | Utilicename/type/en minúscula access y configúrelo enmetadata.type. IN\_LINE\_ATTRIBUTE |
| No se S3-based aplica una ACL. | metadata.typeno S3\_LOCATION lo está o falta el .metadata.json archivoaccessControlList. | metadata.typeConfigúrelo S3\_LOCATION e accessControlList inclúyalo en el archivo. |
| Un documento nunca se devuelve a nadie. | El documento se ingirió sin unaccessControlList. | Re-ingest el documento con unaccessControlList. |