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.
Activation de la sensibilisation aux listes de contrôle d'accès
La base de connaissances gérée de Bedrock prend en charge la ACL-aware récupération, c'est-à-dire la possibilité de filtrer les résultats des requêtes en fonction des listes de contrôle d'accès (ACL) au niveau du document explorées à partir de vos sources de données connectées. Lorsque la reconnaissance des ACL est activée sur une source de données, Bedrock Managed Knowledge Base ingère les autorisations (utilisateurs autorisés, utilisateurs refusés, groupes autorisés, groupes refusés) parallèlement au contenu du document. Au moment de la requête, vous fournissez un contexte utilisateur et Bedrock Managed Knowledge Base renvoie uniquement les documents auxquels l'utilisateur est autorisé à accéder. Pour la syntaxe de requête utilisée pour transmettre le contexte utilisateur au moment de la récupération, consultezACL-aware extraction sur des bases de connaissances gérées.
La sensibilisation à l'ACL n'est pas une autorisation
La base de connaissances gérée de Bedrock fournit un ACL-aware filtrage, et non une limite de sécurité. La base de connaissances gérée de 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 la base de connaissances gérée de Bedrock 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 ACL-aware fonctionne la récupération
ACL-aware la récupération s'effectue en deux étapes :
-
Pre-retrieval filtrage : lors de l'ingestion, Bedrock Managed Knowledge Base analyse les autorisations relatives aux documents depuis la source de données. Au moment de la requête, Bedrock Managed Knowledge Base utilise le contexte utilisateur que vous fournissez pour filtrer les résultats de recherche, en renvoyant uniquement les documents pour lesquels l'utilisateur (ou ses groupes) apparaît dans la liste d'autorisation et n'apparaît pas dans la liste de refus.
-
Real-time Vérification des ACL : pour les connecteurs qui la prennent en charge (SharePoint OneDrive, Google Drive, Confluence), Bedrock Managed Knowledge Base appelle en temps réel la source de données pour vérifier que l'utilisateur a toujours accès à chaque document renvoyé. Cela permet de détecter les modifications d'autorisation survenues entre les synchronisations. Les connecteurs S3 et Custom ne prennent pas en charge la vérification en temps réel car leurs métadonnées ACL sont fournies par le client via des fichiers de configuration au lieu d'être explorées à partir d'un système d'autorisation en direct.
Les deux étapes utilisent la même logique d'évaluation : si un utilisateur apparaît à la fois dans une liste d'autorisation et dans une liste de refus pour un document, l'accès est refusé. Refuser l'emporte toujours sur Autoriser.
Modèle d'identité
La base de connaissances gérée de Bedrock utilise le courrier électronique comme identifiant utilisateur universel pour la mise en correspondance des ACL. L'utilisateur est toujours identifié par son adresse e-mail universelle : l'e-mail que vous transmettez dans le contexte utilisateur doit correspondre exactement à l'e-mail associé à l'utilisateur dans chaque source de données connectée. Il n'y a pas de résolution d'alias ni de mappage entre les fournisseurs d'identité et les fournisseurs. Les groupes, en revanche, sont identifiés par la manière dont le connecteur source les représente (un nom de groupe, un identifiant de groupe ou un autre identifiant) et sont comparés aux appartenances aux groupes explorées à partir de cette source de données.
Les appartenances aux groupes sont résolues à partir de la source de données. Lors de l'ingestion, Bedrock Managed Knowledge Base analyse les adhésions aux groupes de chaque source de données et les stocke en interne. Au moment de la requête, la base de connaissances gérée de Bedrock détermine automatiquement à quels groupes appartient un utilisateur en fonction de ces données explorées.
Note
Les adhésions aux groupes sont aussi récentes que lors de la dernière synchronisation. Les modifications d'autorisation entre les synchronisations ne sont répercutées qu'à la fin de la prochaine tâche d'ingestion. Pour les connecteurs qui prennent en charge la vérification des ACL en temps réel, cette vérification permet de détecter les modifications d'autorisation survenues depuis la dernière synchronisation.
Matrice de support des connecteurs
Tous les connecteurs ne prennent pas en charge la reconnaissance des ACL. Le tableau suivant indique quels connecteurs prennent en charge le filtrage préalable à la récupération et la vérification des ACL en temps réel.
| Connecteur | Pre-retrieval filtre | Real-time ACL | Remarques |
|---|---|---|---|
| SharePoint | Pris en charge | Pris en charge | Utilise les autorisations au niveau de l'application (2LO). Nécessite un type ENTRA_ID_APP_ONLY d'authentification. |
| OneDrive | Pris en charge | Pris en charge | Utilise les autorisations au niveau de l'application (2LO). Nécessite un type ENTRA_APP_ID d'authentification. |
| Google Drive | Pris en charge | Pris en charge | Utilise la délégation à l'échelle du domaine (2LO). Nécessite un type SERVICE_ACCOUNT d'authentification. |
| Confluence | Pris en charge | Pris en charge | Utilise un jeton d'API d'administration pour les contrôles en temps réel. Nécessite un type BASIC d'authentification. |
| Amazon S3 | Pris en charge | Non pris en charge | ACL définies via un fichier de configuration ACL fourni par le client dans Amazon S3. Aucune vérification en temps réel car le fichier de métadonnées fourni par le client est la source de vérité. |
| Personnalisé | Pris en charge | Non pris en charge | ACL définies par le biais de métadonnées fournies par le client. Aucune vérification en temps réel, car les métadonnées fournies par le client constituent la source de vérité. |
| Robot Web | Non pris en charge | N/A | Le contenu Web n'est soumis à aucun modèle d'autorisation. La reconnaissance des ACL ne peut pas être activée pour ce connecteur. |
Pour plus de détails sur la configuration des ACL spécifiques au connecteur, consultez :
Comportement de défaillance
ACL-aware échec de la récupération fermé. Si une partie du pipeline d'évaluation des ACL rencontre une erreur (échec de résolution de groupe, délai de vérification en temps réel ou erreur de service interne), Bedrock Managed Knowledge Base ne renvoie pas les documents concernés. Une défaillance passagère n'entraîne jamais le renvoi de documents à des utilisateurs non autorisés.
En cas de défaillance de l'ACL, la réponse peut contenir zéro résultat ou moins de résultats que prévu. Les réponses d'erreur indiquent un échec de résolution de l'ACL. Vous pouvez donc le distinguer d'une requête qui ne correspond réellement à aucun document.
Vos responsabilités
Étant donné que la base de connaissances gérée de Bedrock fournit un ACL-aware filtrage et non une solution d'autorisation complète, vous êtes responsable des éléments suivants :
-
Authentification des utilisateurs finaux : vous devez authentifier les utilisateurs dans votre application avant de transmettre leur identité à Bedrock Managed Knowledge Base. La base de connaissances gérée de Bedrock ne vérifie pas l'authenticité du contexte utilisateur que vous fournissez.
-
Identité de messagerie cohérente : l'adresse e-mail que vous transmettez doit correspondre à celle utilisée dans chaque source de données connectée. Si les e-mails diffèrent d'un système à l'autre, la correspondance ACL échoue silencieusement et l'utilisateur ne reçoit aucun résultat de cette source de données.
-
Gestion du cycle de vie des e-mails — Si une adresse e-mail est réattribuée à une autre personne (par exemple, après le départ d'un employé), vous devez la détecter avant de transmettre l'identité à Bedrock Managed Knowledge Base. Real-time La vérification des ACL agit comme un filet de sécurité pour les connecteurs qui la prennent en charge, mais ne remplace pas une gestion appropriée du cycle de vie des identités.
