Gérer le contrôle des accès

Cette page explique comment gérer le contrôle des accès pour les projets et les documents.

Présentation du contrôle des accès aux données

Le contrôle des accès aux données est une fonctionnalité clé de Document AI Warehouse. Il contrôle qui a accès à quelle ressource dans Document AI Warehouse, et le niveau d'accès dont disposent ces utilisateurs.

Les API Document AI Warehouse sont basées sur Google Cloud. HTTPS est utilisé pour assurer la transmission sécurisée des données sur Internet. L'authentification et l'autorisation sont appliquées aux API Document AI Warehouse pour protéger le service et les données utilisateur en fonction des identités Google.

Les API Document AI Warehouse utilisent OAuth2 pour l'authentification avec un compte utilisateur. Toutes les méthodes d'API nécessitent le champ d'application OAuth https://www.googleapis.com/auth/cloud-platform.

Document AI Warehouse applique le contrôle des accès aux données client en fonction de Cloud IAM. Document AI Warehouse définit un ensemble de rôles et d'autorisations associées pour vous permettre de limiter l'accès de différents utilisateurs aux données stockées dans notre service. Pour en savoir plus, consultez la section Rôles et autorisations IAM.

Utiliser un compte de service pour appliquer un contrôle d'accès de base

Vous avez besoin d'un compte de service disposant des autorisations requises pour accéder à l'API Document AI Warehouse. Si vous suivez l'étape "Provisionner via la console Google Cloud " du guide de démarrage rapide, un compte de service est automatiquement provisionné avec le rôle "Administrateur Document AI Warehouse".

Mode de contrôle des accès

Document AI Warehouse propose trois modes de contrôle des accès :

  • Accès universel : aucun contrôle des accès au niveau des documents
  • Contrôle des accès au niveau des documents avec votre propre service d'identité
  • Contrôle des accès au niveau des documents avec Cloud Identity

Les utilisateurs doivent choisir l'un des modes d'accès lors du processus de provisionnement. Les sections suivantes décrivent la différence entre les trois modes de contrôle des accès et expliquent comment activer chacun d'eux.

Accès universel

Le contrôle des accès universel vous permet d'utiliser exclusivement Identity and Access Management (IAM) pour gérer les autorisations. IAM applique les mêmes autorisations à tous les documents du projet avec l'identité authentifiée.

Dans ce mode, une fois la procédure de provisionnement terminée dans le guide de démarrage rapide, vous et tous vos utilisateurs pouvez accéder à tous les documents du projet Google Cloudsélectionné dans le service Document AI Warehouse à l'aide du compte de service, avec les autorisations associées à ce compte.

La suite de ce document traite du contrôle des accès au niveau des documents. Si vous utilisez l'accès universel, vous pouvez ignorer le reste du document.

Contrôle des accès au niveau des documents

Si vous utilisez Document AI Warehouse, vous pouvez :

  • Utiliser votre propre service d'identité
    • L'utilisateur final et les groupes de membres de l'utilisateur final sont tous deux requis dans les métadonnées de la demande. Utilisez cette option si votre entreprise dispose de sa propre méthode pour authentifier l'utilisateur et identifier les groupes auxquels il appartient.
  • Utiliser Cloud Identity
    • Seul l'utilisateur final est requis dans les métadonnées de la requête, car Document AI Warehouse collecte les groupes de membres de Cloud Identity pour les clients. La différence entre cette méthode et l'utilisation d'un service d'identité personnalisé est que vous gérez les appartenances aux groupes des utilisateurs à l'aide de Cloud Identity plutôt que d'un système interne.

L'utilisation du mode d'accès au niveau du document présente quelques limites :

  • Seuls les membres et les rôles de la ACL sont acceptés. Les conditions IAM sont ignorées.
  • Les rôles personnalisés ne sont pas acceptés dans la LCA.
  • Document AI Warehouse ne valide pas les identifiants des utilisateurs finaux. Document AI Warehouse ne vérifie les identifiants du compte de service que pour s'assurer que les appels proviennent des clients. Les identifiants de l'utilisateur final doivent être validés côté client.
  • Les clients doivent fournir l'utilisateur final (et tous les groupes dont il est membre s'ils n'utilisent pas l'option Cloud Identity) dans les métadonnées de la requête pour appliquer le contrôle des accès.
  • Le nombre de groupes de membres pour l'utilisateur final doit être inférieur à 100.

Contrôle des accès au niveau des documents avec le propre service d'identité du client

Vous pouvez choisir ce mode si vous souhaitez effectuer les opérations suivantes :

  • Accorder aux utilisateurs finaux (ou groupes) différentes autorisations d'accès à chacun des documents.
  • Utilisez votre propre service d'identité.

Ce mode vous permet d'utiliser conjointement IAM et les listes de contrôle d'accès (LCA) pour gérer les autorisations. Chaque document de Document AI Warehouse peut être configuré avec une CACL au niveau du document spécifique. L'authentification et l'autorisation se déroulent comme suit :

  • Les identifiants du compte de service sont authentifiés et autorisés à accéder au service.
  • Dans les métadonnées de la requête, incluez l'utilisateur final et les groupes auxquels il appartient. L'utilisateur final ou au moins l'un des groupes auxquels il appartient doit être autorisé à accéder au document.

Document AI Warehouse n'accorde l'accès au document demandé que si les deux conditions de la liste précédente sont remplies.

Le UserInfo (y compris l'ID de l'utilisateur final et les ID des groupes auxquels il appartient) du RequestMetadata fourni dans l'appel d'API est utilisé pour vérifier si l'utilisateur final est autorisé à effectuer l'action correspondante sur la ressource de document demandée. Par exemple, le UserInfo fourni dans l'API GetDocument est utilisé pour valider si l'utilisateur final est autorisé à afficher le document. Si l'utilisateur final ou l'un des groupes de membres sont autorisés à afficher le document, l'utilisateur final est autorisé à l'afficher.

Exemple de RequestMetadata au format JSON :

request_metadata: {
    user_info: {
        id: user:fake_user_id
        group_ids: [
            group:fake_group_id_1,
            group:fake_group_id_2,
            group:fake_group_id_3,
        ]
    }
}

En plus de suivre le guide de démarrage rapide, ce mode de contrôle des accès nécessite quelques étapes supplémentaires avant de commencer à envoyer des API à Document AI Warehouse :

  1. Récupérez les appartenances aux groupes d'un utilisateur final donné à partir de votre service d'annuaire (par exemple, Azure Active Directory ou Okta).
  2. Suivez les instructions de la section Configurer le contrôle d'accès pour définir une règle de projet par défaut. Vous pouvez également définir une LCA au niveau du document pour des documents spécifiques après leur création.

Après avoir suivi les étapes précédentes, vous êtes prêt à utiliser le compte de service pour effectuer des appels d'API à Document AI Warehouse avec les informations sur les utilisateurs finaux et les appartenances aux groupes dans la section RequestMetadata du corps de la requête.

Dans ce mode, vous devez déployer un proxy pour authentifier et autoriser les utilisateurs finaux. Le proxy utilise le compte de service auquel le rôle d'administrateur a été attribué pour accéder au service. La clé du compte de service doit être protégée afin qu'elle ne soit utilisée que par le proxy.

En tant que solution clé en main, la console Document AI Warehouse est un proxy qui peut stocker la clé du compte de service, authentifier les utilisateurs finaux à l'aide des identités Google et transférer les requêtes à Document AI Warehouse.

Contrôle des accès au niveau des documents avec Cloud Identity

Si vous ne souhaitez pas utiliser votre propre service d'identité, vous pouvez également choisir d'utiliser Cloud Identity pour simplifier le processus.

Pour gérer de manière centralisée les utilisateurs et les groupes,les clients Google Cloud peuvent configurer Cloud Identity à partir de zéro ou fédérer les identités entre Google et d'autres fournisseurs d'identité, tels qu'Active Directory et Azure Active Directory.

La section UserInfo de RequestMetadata fournie dans l'appel d'API permet de valider si l'utilisateur final est autorisé à effectuer l'action correspondante sur la ressource de document demandée. Avec Cloud Identity, seul l'ID de l'utilisateur final est requis dans RequestMetadata. Document AI Warehouse collecte les informations sur le groupe d'appartenance auprès du service Cloud Identity. Si l'utilisateur final ou l'un des groupes de membres sont autorisés à accéder au document, l'utilisateur final peut y accéder.

Exemple de RequestMetadata au format JSON :

request_metadata: {
    user_info: {
        id: user:fake_user_id
    }
}

En plus de suivre le guide de démarrage rapide, ce mode de contrôle des accès nécessite quelques étapes supplémentaires avant de commencer à envoyer des requêtes à Document AI Warehouse :

  1. Intégrez Cloud Identity pour les utilisateurs finaux et les groupes.
  2. Suivez les instructions de la section Configurer le contrôle d'accès pour définir une règle de projet par défaut. Vous pouvez également définir une LCA au niveau du document pour des documents spécifiques après leur création.

Après avoir suivi les étapes précédentes, vous êtes prêt à utiliser le compte de service pour effectuer des appels d'API à Document AI Warehouse avec les informations de l'utilisateur final dans la section RequestMetadata du corps de la requête.

Configurer le contrôle des accès

Avant de commencer

Avant de commencer, assurez-vous d'avoir consulté la page Démarrage rapide.

SetAcl et FetchAcl

Lorsqu'un projet est créé, aucune LCA n'est définie. Le propriétaire du projet peut appeler l'API Document AI Warehouse SetAcl pour définir une stratégie de projet par défaut à l'aide de rôles prédéfinis pour le projet en définissant le champ projectOwner sur "true" à l'aide du compte de service. Les membres de la règle du projet ont accès à tous les documents du projet en fonction des rôles accordés. Vous pouvez accorder l'accès aux utilisateurs ou groupes administrateurs dans la règle par défaut du projet.

Le tableau suivant récapitule le rôle requis pour chaque action sur les documents. Pour en savoir plus sur les autorisations accordées à chaque rôle, consultez Rôles et autorisations IAM.

Pour effectuer des appels à l'API Document Schema à l'aide du compte de service, consultez projects.locations.documentSchemas.

Méthode de l'API Document Rôles requis
CreateDocument roles/contentwarehouse.documentCreator
UpdateDocument roles/contentwarehouse.documentEditor
DeleteDocument
SetACL		 roles/contentwarehouse.documentAdmin
GetDocument
FetchACL
SearchDocuments		 roles/contentwarehouse.documentViewer

CreateDocument

Accordez l'accès "Créateur" à l'utilisateur final ou au groupe, si ce n'est pas déjà fait :

  • [Facultatif] Récupérez les groupes de membres pour l'administrateur de l'utilisateur final à partir du service d'identité du client. Cette étape peut être ignorée par les clients qui utilisent Cloud Identity.
  • Attribuez à l'utilisateur final A (ou au groupe auquel il appartient) le rôle roles/contentwarehouse.documentCreator au niveau du projet en appelant SetAcl à l'aide du compte de service avec l'administrateur de l'utilisateur final [et les groupes de membres] dans les métadonnées de la requête. L'administrateur de l'utilisateur final dispose d'un accès documentAdmin au niveau du projet.

Créez un document :

  • Facultatif : Récupérez les groupes de membres pour l'utilisateur final A à partir de votre service d'identité. Vous pouvez ignorer cette étape si vous utilisez Cloud Identity.
  • Appelez CreateDocument avec l'utilisateur final A [et les groupes de membres] dans les métadonnées de la requête pour créer un document à l'aide du compte de service. Une fois le document créé, l'utilisateur final A peut le consulter et le modifier par défaut. Les clients peuvent également spécifier une règle par défaut pour accorder l'accès aux utilisateurs ou aux groupes lors de la création. Par exemple, vous pouvez accorder l'accès documentViewer au groupe X, l'accès documentEditor au groupe Y et l'accès documentAdmin au groupe Z.

GetDocument et FetchAcl

Une fois le document créé, l'utilisateur final A ou les membres des groupes X, Y ou Z peuvent appeler GetDocument pour afficher le document, ou appeler FetchAcl pour afficher la LCA du document. Pour ce faire, procédez comme suit :

  1. Facultatif : Récupérez les groupes de membres pour l'utilisateur final A à partir de votre service d'identité. Vous pouvez ignorer cette étape si vous utilisez Cloud Identity.
  2. Appelez GetDocument ou FetchAcl à l'aide du compte de service avec l'utilisateur final A (et les groupes de membres) dans les métadonnées de la requête.

L'appel de l'utilisateur final B est refusé si B n'est pas membre de groupX, groupY ou groupZ.

UpdateDocument, DeleteDocument et SetAcl

Une fois le document créé, seuls l'utilisateur final A ou les membres du groupe Y ou du groupe Z sont autorisés à appeler UpdateDocument pour mettre à jour le document. Seuls l'utilisateur final A ou les membres du groupe Z sont autorisés à appeler DeleteDocument pour supprimer le document ou SetAcl pour le partager avec d'autres utilisateurs finaux ou groupes. Pour ce faire, procédez comme suit :

  1. Facultatif : Récupérez les groupes de membres pour l'utilisateur final A à partir de votre service d'identité. Vous pouvez ignorer cette étape si vous utilisez Cloud Identity.
  2. Appelez UpdateDocument, DeleteDocument ou SetAcl à l'aide du compte de service avec l'utilisateur final A [et les groupes de membres] dans les métadonnées de la requête.

L'appel des membres du groupe X sera refusé, car ils ne disposent que d'un accès documentViewer au document.

SearchDocuments

Les documents renvoyés dépendent des rôles attribués à l'utilisateur final. Par exemple, pour une requête de recherche vide, tous les documents du projet seront renvoyés si l'utilisateur final dispose d'un accès documentViewer au niveau du projet. Sinon, seuls les documents pour lesquels l'utilisateur final dispose de l'autorisation contentwarehouse.documents.get sont renvoyés.

Pour appeler l'API SearchDocument, les clients doivent procéder comme suit.

  1. Facultatif : Récupérez les groupes de membres pour l'utilisateur final A à partir de votre service d'identité. Vous pouvez ignorer cette étape si vous utilisez Cloud Identity.
  2. Appelez SearchDocument à l'aide du compte de service avec l'utilisateur final A (et les groupes de membres) dans les métadonnées de la requête.
Méthode API Document Link Rôles requis
CreateDocumentLink Source : roles/contentwarehouse.documentEditor
Target : roles/contentwarehouse.documentViewer
ListLinkedTargets
ListLinkedSources		 roles/contentwarehouse.documentViewer
DeleteDocumentLink Source : roles/contentwarehouse.documentEditor

Les utilisateurs finaux peuvent associer les documents doc1 et doc2 s'ils disposent de l'autorisation contentwarehouse.documents.update pour doc1 et de l'autorisation contentwarehouse.documents.get pour doc2.

ListLinkedTargets et ListLinkedSources

Les utilisateurs finaux ne peuvent lister les documents cibles ou sources que s'ils disposent de l'autorisation contentwarehouse.documents.get.

Les utilisateurs finaux peuvent supprimer les liens s'ils disposent de l'autorisation contentwarehouse.documents.update sur les documents sources.