View a markdown version of this page

Document-level contrôles d'accès - Amazon Bedrock
Comment ça marcheActiver la sensibilisation à l'ACLStructure globale des fichiers ACLPer-document fichiers de métadonnéesVérification de votre configurationRésolution des problèmes

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 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.

Les sources de données Amazon S3 prennent éventuellement en charge le contrôle d'accès au niveau du document. Contrairement à d'autres connecteurs, Amazon S3 ne dispose pas de système d'autorisation d'exploration natif. Vous définissez donc des ACL via des fichiers de configuration que vous gérez. Pour une vue d'ensemble de la prise en compte des ACL sur tous les connecteurs, consultezActivation de la sensibilisation aux listes de contrôle d'accès.

Comment ça marche

Pour une source de données ACL-enabled Amazon S3, 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, en renvoyant uniquement les documents auxquels l'utilisateur effectuant la requête est autorisé à accéder. Real-time La vérification des ACL n'est pas prise en charge pour Amazon S3 car les métadonnées ACL fournies par le client constituent la source de vérité.

Activer la sensibilisation à l'ACL

Pour activer la prise en compte des ACL pour une source de données Amazon S3, configurez aclEnabled connectorParameters et définissez les autorisations d'accès à l'aide de l'une des deux méthodes suivantes : true

  • Fichier de configuration ACL global  : fichier JSON centralisé unique qui définit les autorisations d'accès au niveau du dossier (préfixe). Idéal pour les organisations dotées de structures d'autorisation stables. Les modifications apportées au fichier global nécessitent la réindexation du préfixe concerné.

  • Document-level fichiers de métadonnées  : chaque document possède son propre fichier de métadonnées contenant des informations de contrôle d'accès. Cela permet des mises à jour plus rapides de l'index lorsque les autorisations changent, car seuls les documents concernés doivent être réindexés.

Important

Pour les sources de données ACL-enabled Amazon S3, les documents sans entrée ACL associée ne sont pas ingérés. Assurez-vous que chaque document possède une ACL définie soit via le fichier ACL global, soit dans son fichier de métadonnées.

"connectorParameters": {
    "type": "S3",
    "version": "1",
    "aclEnabled": true,
    "connectionConfiguration": {
        "bucketName": "your-bucket-name",
        "bucketOwnerAccountId": "123456789012"
    },
    "aclConfiguration": {
        "globalAccessControlListS3Uri": "s3://your-bucket-name/acl/global-acl.json"
    }
}

Structure globale des fichiers ACL

Le fichier ACL global est un tableau JSON dans lequel chaque entrée associe un préfixe clé à un ensemble d'entrées de contrôle d'accès. Chacun keyPrefix est l'URI Amazon S3 absolu d'un dossier (s'appliquant à tous les documents qu'il contient) ou d'un document individuel.

[
    {
        "keyPrefix": "s3://your-bucket-name/finance/",
        "aclEntries": [
            {
                "Name": "user1@example.com",
                "Type": "USER",
                "Access": "ALLOW"
            }
        ]
    }
]

Chaque aclEntries élément contient :

  • Name— L'adresse e-mail d'un utilisateur.

  • Type— Ça doit être le casUSER.

  • Access— L'un ALLOW ou l'autreDENY. Refuser les dérogations autoriser.

Per-document fichiers de métadonnées

Comme alternative au fichier ACL global, vous pouvez définir des ACL par document à l'aide de fichiers de métadonnées. Pour chaque document, créez un fichier nommé filename.metadata.json dans le même chemin Amazon S3. Incluez un accessControlList tableau avec le même format d'entrée que le fichier global.

{
    "metadataAttributes": {},
    "accessControlList": [
        {
            "Name": "user1@example.com",
            "Type": "USER",
            "Access": "ALLOW"
        },
        {
            "Name": "user2@example.com",
            "Type": "USER",
            "Access": "DENY"
        }
    ]
}

Per-document les métadonnées ont priorité sur le fichier ACL global. Si un document possède à la fois une entrée de préfixe global correspondante et un fichier de métadonnées par document, les métadonnées par document sont utilisées.

Note

Le fichier de configuration ACL doit être stocké dans le même compartiment Amazon S3 que le contenu de votre source de données.

Vérification de votre configuration

Les ACL Amazon S3 étant fournies par le client, validez-les avant de lancer une requête :

  1. Confirmez aclEnabled qu'il se trouve true dans la source de donnéesconnectorParameters.

  2. Vérifiez que chaque document possède une ACL, qu'il s'agisse d'une entrée dans le fichier ACL global ou d'un .metadata.json fichier par document. Les documents sans ACL ne sont pas ingérés.

  3. Validez le JSON de l'ACL : chaque entrée contient Name Type (e-mail de l'utilisateurUSER), Access () et (ALLOWouDENY), et les fichiers ACL se trouvent dans le même compartiment que votre contenu.

  4. Vérifiez que l'adresse e-mail d'un utilisateur test correspond exactement à celle figurant Name dans l'ALLOWentrée d'un document que vous souhaitez qu'il récupère.

Résolution des problèmes

Note

Les erreurs de configuration des ACL ne produisent pas d'erreurs explicites lors de la récupération. La récupération échoue : les documents concernés sont omis en silence, de sorte qu'une requête renvoie moins de résultats, voire aucun résultat, au lieu d'une erreur. Utilisez les contrôles de vérification ci-dessus pour diagnostiquer ces problèmes.

ACL-enabled Symptômes, causes et solutions d'Amazon S3
Symptôme Cause probable Corriger
Retrieve renvoie 0 résultat pour un utilisateur qui devrait y avoir accès. L'adresse e-mail de l'utilisateur ne correspond à aucune entrée ACL (incompatibilité des e-mails). Assurez-vous que l'ACL Name correspond exactement à l'adresse e-mail de l'utilisateur.
Un document n'est jamais retourné à personne. Le document ne possède aucune entrée ACL, il n'a donc pas été ingéré. Ajoutez une ACL pour le document via le fichier ACL global ou un fichier par document.metadata.json, puis resynchronisez.
Une ACL par document ne prend pas effet. Le nom .metadata.json du fichier est incorrect ou son chemin n'est pas le bon. Nommez-le filename.metadata.json dans le même chemin S3 ; les métadonnées par document remplacent le fichier global.
Les modifications de l'ACL ne sont pas reflétées. Les modifications globales des fichiers ACL nécessitent la réindexation du préfixe concerné. Resynchronisez le préfixe concerné.