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
SharePoint les sources de données prennent éventuellement en charge le contrôle d'accès au niveau du document. Lorsque cette option est activée, Bedrock Managed Knowledge Base synchronise les listes de contrôle d'accès (ACL) à SharePoint chaque exploration et vérifie les autorisations de chaque utilisateur au moment de la requête, de sorte que les utilisateurs ne voient que les résultats des documents auxquels ils sont autorisés à accéder. SharePoint 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).
**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.
## Comment ça marche
Lorsqu'un utilisateur interroge une base de connaissances qui utilise une source de ACL-enabled SharePoint données, Bedrock Managed Knowledge Base applique les contrôles d'accès en deux étapes :
+ **Pre-retrieval filtrage** — La base de connaissances gérée par Bedrock applique les listes de contrôle d'accès synchronisées SharePoint lors du dernier crawl, renvoyant uniquement les documents candidats auxquels l'utilisateur (ou ses groupes) est autorisé à accéder.
+ **Real-time vérification** — La base de connaissances gérée par Bedrock vérifie les documents candidats en temps réel en vérifiant l'accès actuel de l'utilisateur demandeur. SharePoint 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 actuel même lorsque les SharePoint autorisations changent entre les synchronisations.
## Qu'est-ce qui est crawlé
Lorsque les ACL sont activées, la base de connaissances gérée de Bedrock explore les structures d'autorisation suivantes à partir de : SharePoint
+ Site-level adhésions et attributions de rôles
+ Autorisations au niveau de la bibliothèque de documents
+ Item-level autorisations (fichier et page), y compris les autorisations uniques qui interrompent l'héritage
+ Appartenances à des groupes de sécurité, y compris les groupes de sécurité Microsoft Entra ID (Azure AD), les groupes de sécurité à extension messagerie et les groupes de distribution. Les appartenances à des groupes imbriqués (transitifs) sont également résolues.
Au moment de la requête, vous transmettez l'adresse e-mail de l'utilisateur (et non celle d'un groupe). La base de connaissances gérée Bedrock résout les appartenances aux groupes de cet utilisateur à partir des données qu'il a analysées et les applique lors du filtrage des résultats. Pour plus d'informations sur le modèle d'identité, consultez[Sensibilisation aux listes de contrôle d'accès](kb-managed-acl.md).
## Activer la sensibilisation à l'ACL
Pour activer la prise en compte des ACL pour une source de SharePoint données, définissez `aclEnabled` la `true` valeur sur in the `connectorParameters` et utilisez le type d'`ENTRA_ID_APP_ONLY`authentification. Ce type d'authentification utilise des autorisations d'application basées sur des certificats qui permettent à Bedrock Managed Knowledge Base d'explorer les informations d'identité et de vérifier l'accès aux documents au moment de la requête.
**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.
L'enregistrement de votre application Entra ID doit disposer des autorisations d'application suivantes :
+ `User.Read.All`et `GroupMember.Read.All` sur Microsoft Graph (pour l'exploration des identités)
+ `Sites.FullControl.All`sur SharePoint ou `Sites.Selected` avec des autorisations par site accordées (pour la vérification de l'accès aux documents)
Ils `connectionConfiguration` doivent inclure un `certificateS3Path` pointage vers un fichier de certificat PKCS \#12 (.p12) dans Amazon S3.
**Note**
Le `certificatePassword` champ du secret est facultatif. Si vous l'omettez, Bedrock Managed Knowledge Base ouvre le fichier PKCS \#12 (.p12) en utilisant l'ID client de votre application comme mot de passe. Le certificat doit donc avoir été créé avec ce mot de passe. Nous vous recommandons de toujours définir une valeur explicite à entropie élevée `certificatePassword` pour protéger la clé privée du certificat au repos.
```
"connectorParameters": {
"type": "SHAREPOINT",
"version": "1",
"aclEnabled": true,
"connectionConfiguration": {
"tenantId": "{{your-tenant-id}}",
"authType": "ENTRA_ID_APP_ONLY",
"secretArn": "{{arn:aws:secretsmanager:region:account-id:secret:secret-name}}",
"certificateS3Path": {
"s3BucketName": "{{your-certificate-bucket}}",
"s3KeyName": "{{certs/certificate.p12}}"
}
},
"dataEntityConfiguration": {
"siteUrls": [
"{{https://contoso.sharepoint.com/sites/engineering}}"
],
"crawlFiles": true,
"crawlPages": true
}
}
```
**Note**
Le type d'`OAUTH2_APP`authentification n'est pas pris en charge pour les sources ACL-enabled SharePoint de données. Vous devez utiliser `ENTRA_ID_APP_ONLY`.
## Real-time vérification d'accès
Bedrock Managed Knowledge Base vérifie par rapport SharePoint à chaque document candidat au moment de la requête en utilisant les autorisations basées sur les certificats de l'application (l'enregistrement de l'`ENTRA_ID_APP_ONLY`application est configuré pour l'exploration). Contrairement à un flux de connexion utilisateur délégué, aucune connexion ou consentement interactif par utilisateur n'est requis. La vérification utilise le même enregistrement et le même certificat d'application, via l'`Sites.Selected`autorisation `Sites.FullControl.All` or, pour confirmer que l'utilisateur demandeur a toujours accès à chaque document.
## Vérification de votre configuration
Vous pouvez valider les autorisations de votre application Entra indépendamment d'une demande de récupération. Effectuez chacune des vérifications suivantes :
1. **Microsoft Graph (crawl)** :
+ Procurez-vous un jeton d'application avec portée `https://graph.microsoft.com/.default` et confirmez que la `roles` réclamation inclut `User.Read.All` et`GroupMember.Read.All`.
+ Appelez un point de terminaison de site Microsoft Graph (par exemple,`GET https://graph.microsoft.com/v1.0/sites/{site}`) et confirmez qu'il renvoie le site.
1. **SharePoint REST (vérification en temps réel)** :
+ Acquérez un jeton à l'aide de l'assertion du client de certificat avec portée`https://{tenant}.sharepoint.com/.default`.
+ Vérifiez que la `roles` réclamation du jeton inclut l'autorisation SharePoint `Sites.FullControl.All` (ou`Sites.Selected`). Une `roles: null` valeur signifie que l'autorisation ou le consentement de l'administrateur est absent.
+ Appelez `GET https://{tenant}.sharepoint.com/_api/web` et confirmez le succès (HTTP 200). Une réponse échouée ou non autorisée signifie que l' SharePoint autorisation ou le consentement de l'administrateur est absent, ce qui entraîne le refus de tous les documents.
## 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 précédents pour diagnostiquer ces problèmes.
**ACL-enabled SharePoint symptômes, causes et solutions**
| Symptôme | Cause probable | Corriger |
| --- | --- | --- |
| Retrieve ne renvoie aucun résultat, mais l'utilisateur y a accès SharePoint. | L'autorisation SharePoint Sites.FullControl.All (ouSites.Selected) ou le consentement de l'administrateur étant absents, l'appel SharePoint REST est rejeté et tous les documents sont refusés. | Accordez l' SharePoint Sites.FullControl.Allautorisation (ou Sites.Selected des autorisations par site) avec le consentement de l'administrateur. Comme ces informations d'identification de l'application sont mises en cache, attendez jusqu'à une heure pour que la modification prenne effet, ou testez avec un utilisateur qui n'a pas encore été interrogé pour confirmer plus tôt. |
| L'accès d'un utilisateur a été modifié SharePoint, mais le nouveau résultat n'est pas reflété immédiatement. | Per-user les résultats d'accès sont finalement cohérents entre la source de données et la base de connaissances gérée par Bedrock (généralement en deux minutes environ), de sorte qu'un changement d'accès récent peut ne pas être reflété immédiatement. | Une fois que la source de données a reflété la modification, attendez environ deux minutes et réessayez. |
| Tous les utilisateurs sont refusés après avoir travaillé auparavant. | Le certificat a expiré ou le consentement de l'administrateur a été révoqué. | Renouvelez le certificat lors de l'enregistrement de l'application Entra et dans Amazon S3, et accordez à nouveau le consentement de l'administrateur. |
| L'exploration ou la synchronisation échouent bien que la configuration semble correcte. | Une autorisation d'application Microsoft Graph requise est manquante. | Grant User.Read.All etGroupMember.Read.All. |
| Erreurs liées au mot de passe du certificat ou à la création de jetons. | Le .p12 mot de passe ne correspond pascertificatePassword. | certificatePasswordDéfini sur le mot de passe utilisé pour créer le .p12 fichier. |