View a markdown version of this page

Document-level contrôles d'accès - Amazon Bedrock
Comment ça marcheActiver la sensibilisation à l'ACLStructure de fichier ACL globalePer-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 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 Amazon S3 prennent en charge le contrôle d'accès au niveau du document en option. Contrairement aux autres connecteurs, Amazon S3 ne dispose d'aucun système d'autorisation natif à explorer. Vous définissez donc les 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, voirSensibilisation 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, renvoyant uniquement les documents auxquels l'utilisateur demandeur 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 sont 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, définissez les autorisations aclEnabled d'accès true dans le connectorParameters et définissez les autorisations d'accès à l'aide de l'une des deux méthodes suivantes :

  • 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 de réindexer le 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 d'accélérer les mises à jour 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 dans 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 de fichier ACL globale

Le fichier ACL global est un tableau JSON dans lequel chaque entrée associe un préfixe de clé à un ensemble d'entrées de contrôle d'accès. Chacune keyPrefix est l'URI Amazon S3 absolue d'un dossier (applicable à 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 et 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 globale 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 demander :

  1. Confirmez aclEnabled que cela true figure dans celui de 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 code JSON de l'ACL : chaque entrée contient Name Type (e-mail 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 Name à celle d'une ALLOW entrée pour un document que vous souhaitez qu'il récupère.

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 ci-dessus pour diagnostiquer ces problèmes.

ACL-enabled Symptômes, causes et correctifs 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 (adresse e-mail non concordante). Assurez-vous que l'ACL Name correspond exactement à l'adresse e-mail de l'utilisateur.
Un document n'est jamais retourné à qui que ce soit. Le document ne comporte 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 est incorrect. 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 prises en compte. Les modifications du fichier ACL global nécessitent la réindexation du préfixe concerné. Resynchronisez le préfixe concerné.