

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
<a name="kb-managed-ds-googledrive-acl"></a>

**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 Google Drive prennent en charge le contrôle d'accès au niveau du document en option. Lorsque cette option est activée, Bedrock Managed Knowledge Base synchronise les listes de contrôle d'accès (ACL) de Google Drive lors de chaque exploration et vérifie les autorisations de chaque utilisateur au moment de la requête, afin que les utilisateurs ne voient que les résultats des documents auxquels ils sont autorisés à accéder dans Google Drive. 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
<a name="kb-managed-ds-googledrive-acl-how"></a>

Lorsqu'un utilisateur interroge une base de connaissances qui utilise une source de données ACL-enabled Google Drive, Bedrock Managed Knowledge Base applique les contrôles d'accès en deux étapes :
+ **Pre-retrieval filtrage** — Bedrock Managed Knowledge Base applique les listes de contrôle d'accès synchronisées depuis Google Drive lors du dernier crawl, renvoyant uniquement les documents candidats auxquels l'utilisateur (ou ses groupes) est autorisé à accéder.
+ **Real-time vérification** — Bedrock Managed Knowledge Base vérifie les documents des candidats en temps réel en vérifiant l'accès actuel de l'utilisateur demandeur à Google Drive. Seuls les documents auxquels l'utilisateur est actuellement autorisé à accéder sont inclus dans la réponse.

Cette approche en deux étapes fournit un contrôle d'accès au niveau du document qui reste à jour même lorsque les autorisations Google Drive changent entre les synchronisations.

## Qu'est-ce qui est crawlé
<a name="kb-managed-ds-googledrive-acl-crawl"></a>

Lorsque les ACL sont activées, la base de connaissances gérée de Bedrock explore les autorisations de partage au niveau des fichiers depuis Google Drive, notamment :
+ Partage direct par utilisateur (autorisations de fichiers individuelles)
+ Abonnements à Google Groups
+ Abonnements à un lecteur partagé

## Activer la sensibilisation à l'ACL
<a name="kb-managed-ds-googledrive-acl-enable"></a>

Pour activer la prise en compte des ACL pour une source de données Google Drive, définissez le type `aclEnabled` d'authentification sur `true` in `connectorParameters` et utilisez le type d'`SERVICE_ACCOUNT`authentification. La délégation à l'échelle du domaine doit être activée sur le compte de service dans votre console d'administration Google Workspace.

**Important**  
La configuration de l'ACL est permanente. Vous ne pouvez pas activer les ACL sur une source de données créée sans support ACL, et vous ne pouvez pas désactiver les ACL une fois activées.

Le AWS Secrets Manager secret doit inclure `adminAccountEmail``clientEmail`, et`privateKey`. Pour obtenir des instructions détaillées sur la création du compte de service, la configuration de la délégation à l'échelle du domaine et l'obtention de ces valeurs, consultez. [Configurer l'authentification du compte de service pour Google Drive](kb-managed-googledrive-service-account-setup.md)

```
"connectorParameters": {
    "type": "GOOGLEDRIVE",
    "version": "1",
    "aclEnabled": true,
    "connectionConfiguration": {
        "authType": "SERVICE_ACCOUNT",
        "secretArn": "{{arn:aws:secretsmanager:region:account-id:secret:secret-name}}"
    },
    "dataEntityConfiguration": {
        "crawlMyDrive": true,
        "crawlSharedWithMe": false,
        "crawlSharedDrives": false
    }
}
```

**Note**  
Le type d'`OAUTH2`authentification n'est pas pris en charge pour les sources de données ACL-enabled Google Drive. Vous devez utiliser `SERVICE_ACCOUNT` avec une délégation à l'échelle du domaine.

## Real-time vérification d'accès
<a name="kb-managed-ds-googledrive-acl-realtime"></a>

Bedrock Managed Knowledge Base utilise la délégation à l'échelle du domaine du compte de service pour vérifier l'accès aux documents en temps réel par rapport à l'API Google Drive, confirmant ainsi que l'utilisateur demandeur a toujours accès à chaque document candidat.

## Vérification de votre configuration
<a name="kb-managed-ds-googledrive-acl-verify"></a>

Vous pouvez valider la configuration de votre compte de service indépendamment d'une demande de récupération. Effectuez chacune des vérifications suivantes :

1. **Domain-wide délégation** :
   + Dans la console d'administration de Google Workspace, vérifiez que l'identifiant client du compte de service est autorisé pour les étendues requises (étendue de lecture de Google Drive et étendue de lecture du SDK directory/group d'administration).

1. **Accès au lecteur (exploration et vérification)** :
   + À l'aide du compte de service (`clientEmail`et`privateKey`) en usurpant l'identité`adminAccountEmail`, appelez l'API Google Drive pour répertorier les fichiers d'un utilisateur et confirmer la réussite.

1. **Résolution de groupe** :
   + Appelez l'API Admin SDK Directory pour répertorier les adhésions aux groupes d'un utilisateur et confirmer qu'elle renvoie les groupes attendus.

## Résolution des problèmes
<a name="kb-managed-ds-googledrive-acl-troubleshooting"></a>

**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 solutions de Google Drive**  

| Symptôme | Cause probable | Corriger | 
| --- | --- | --- | 
| Retrieve ne renvoie aucun résultat, mais l'utilisateur a accès à Google Drive. | Domain-wide la délégation n'est pas configurée ou le compte de service n'a pas les étendues requises, de sorte que l'accès ne peut pas être vérifié. | Autorisez l'ID client du compte de service pour les étendues Drive et Admin SDK requises dans la console d'administration Google Workspace. | 
| Group-based l'accès n'est pas respecté. | La portée de directory/group lecture du SDK d'administration est absente de la délégation. | Ajoutez l'étendue de lecture du groupe Admin SDK à la délégation du compte de service à l'échelle du domaine. | 
| L'exploration ou la synchronisation échouent. | LeclientEmail/n'privateKeyest pas valide ou n'adminAccountEmailest pas un administrateur de Workspace. | Vérifiez les informations d'identification du compte de service et vérifiez qu'il adminAccountEmail s'agit d'un administrateur de Workspace. | 
| Tous les utilisateurs sont refusés après avoir travaillé auparavant. | La clé du compte de service a été modifiée ou révoquée. | Mettez à jour le privateKey in the secret. | 