Tous les produits
Search

Ce produit

    Data Lake Formation:Autorisations

    Centre de documentation

    Data Lake Formation:Autorisations

    Dernière mise à jour :Aug 11, 2026

    Cette rubrique décrit le modèle d'autorisations de Data Lake Formation (DLF) et explique comment accorder les autorisations appropriées à un utilisateur RAM pour utiliser et accéder aux fonctionnalités de DLF.

    Le modèle d'autorisations de Data Lake Formation (DLF) comprend deux couches principales : les autorisations RAM et les autorisations de données DLF. Pour accéder aux pages ou aux données de DLF, un utilisateur doit généralement passer avec succès les vérifications des deux couches d'autorisations afin d'accéder aux ressources de données.

    • Autorisations RAM : elles contrôlent l'accès à toutes les opérations OpenAPI de DLF et déterminent quelles opérations OpenAPI ou pages DLF un utilisateur RAM peut consulter.

    • Autorisations de données DLF : elles contrôlent l'accès et l'utilisation des ressources internes de DLF, notamment les bases de données, les tables, les colonnes, les fonctions et les catalogues de données, ainsi que les autorisations relatives aux opérations d'attribution de droits.

    Couche 1 : Autorisations OpenAPI RAM

    Cette couche contrôle l'accès à toutes les opérations OpenAPI de DLF et détermine si un utilisateur RAM peut accéder à des opérations ou des pages OpenAPI DLF spécifiques. La console RAM propose deux stratégies d'autorisation intégrées :

    • AliyunDLFFullAccess : accorde l'autorisation d'appeler toutes les opérations OpenAPI de DLF.

    • AliyunDLFReadOnlyAccess : accorde l'autorisation d'appeler les opérations OpenAPI de DLF en lecture seule, telles que les opérations API commençant par List ou Get. Cette stratégie n'accorde pas d'autorisation pour les opérations d'écriture telles que Create ou Delete.

      Important

      L'opération SubmitQuery est une opération d'écriture et nécessite l'autorisation AliyunDLFFullAccess.

    Vous pouvez également créer des stratégies d'autorisation RAM personnalisées pour un contrôle plus granulaire au niveau des API.

    Couche 2 : Autorisations de données granulaires DLF

    Cette couche contrôle l'accès et l'utilisation des ressources internes de DLF, notamment les bases de données, les tables, les colonnes, les fonctions et les catalogues de données, ainsi que les autorisations pour des opérations telles que la gestion des rôles, la gestion des utilisateurs et l'attribution de droits.

    Remarque

    • Le contrôle des autorisations de la couche 2 se divise en deux types : les autorisations de données granulaires DLF et les autorisations de données grossières RAM DLF-DSS. Ces types entretiennent une relation OU. Un utilisateur obtient l'accès s'il réussit la vérification des autorisations pour l'un ou l'autre type ; l'accès n'est refusé que si les deux vérifications échouent.

    • Les vérifications d'autorisations pour les ressources de données, telles que les bases de données, les tables, les colonnes, les fonctions et les catalogues de données, prennent effet uniquement après l'activation du paramètre d'autorisation pour le catalogue de données. Toutefois, la vérification des autorisations pour les opérations de gestion, telles que la gestion des rôles, des utilisateurs et des attributions de droits, est toujours appliquée par les autorisations de données granulaires, que le paramètre soit activé ou non.

    Pour simplifier la gestion des autorisations de données, DLF fournit des rôles d'administrateur de données intégrés. Vous trouverez ces rôles sur la page Data Permission > Role et pourrez les attribuer à des utilisateurs spécifiques :

    • admin (administrateur de lac de données) : dispose de toutes les autorisations de données et d'attribution de droits dans Data Lake Formation.

    • super_administrator (super administrateur) : dispose de toutes les autorisations de données et d'attribution de droits dans Data Lake Formation et peut modifier les utilisateurs ayant le rôle admin.

    Pour plus d'informations sur la configuration des autorisations granulaires, consultez la présentation des autorisations de données.

    Couche 2 : Autorisations de données grossières RAM DLF-DSS

    Cette couche contrôle l'accès et l'utilisation des ressources internes de DLF, notamment les bases de données, les tables, les colonnes, les fonctions et les catalogues de données, ainsi que les autorisations pour des opérations telles que la gestion des rôles, la gestion des utilisateurs et l'attribution de droits. La console RAM propose deux stratégies d'autorisation intégrées :

    • AliyunDLFDSSFullAccess : accorde l'accès à toutes les ressources DLF granulaires.

    • AliyunDLFDSSReadOnlyAccess : accorde un accès en lecture seule à toutes les ressources DLF granulaires, y compris pour des opérations telles que List, Get, Select et Execute.

    Remarque

    • Nous vous recommandons d'utiliser les autorisations de données granulaires DLF pour un contrôle précis des autorisations de données.

    • Les vérifications d'autorisations pour les ressources de données, telles que les bases de données, les tables, les colonnes, les fonctions et les catalogues de données, prennent effet uniquement après l'activation du paramètre d'autorisation pour le catalogue de données. Toutefois, la vérification des autorisations pour les opérations de gestion, telles que la gestion des rôles, des utilisateurs et des attributions de droits, est toujours appliquée par les autorisations de données grossières DLF-DSS, que le paramètre soit activé ou non.

    • Un utilisateur RAM disposant de la stratégie RAM AdministratorAccess possède également toutes les autorisations DLF-DSS, ce qui équivaut à disposer de la stratégie AliyunDLFDSSFullAccess.

    Scénarios courants

    • Cas d'utilisation : interrogation des métadonnées DLF sans nécessiter de contrôle des autorisations de données.

      • Accordez les « Autorisations OpenAPI RAM (couche 1) » à l'utilisateur RAM en attachant la stratégie d'autorisation intégrée AliyunDLFFullAccess ou AliyunDLFReadOnlyAccess.

    • Cas d'utilisation : utilisation de DLF pour l'attribution granulaire d'autorisations de données.

      • Étape 1 : accordez les « Autorisations OpenAPI RAM (couche 1) » à l'utilisateur RAM en attachant la stratégie d'autorisation intégrée AliyunDLFFullAccess ou AliyunDLFReadOnlyAccess.

      • Étape 2 : activez le paramètre d'autorisation pour le catalogue de données.

      • Étape 3 (facultative) : si vous utilisez d'autres services tels qu'E-MapReduce (EMR) pour interroger et modifier les données, vous devez également activer le commutateur d'autorisation DLF-Auth dans le cluster EMR.

      • Étape 4 : accordez à l'utilisateur RAM les autorisations de données requises. Utilisez l'une des méthodes suivantes :

        • Attribuez un rôle d'administrateur : utilisez votre compte Alibaba Cloud pour attribuer le rôle admin ou super_administrator à un utilisateur RAM. Cela confère à l'utilisateur RAM des autorisations complètes de gestion des données et des attributions de droits. Pour plus d'informations, consultez la rubrique Gérer les rôles.

        • Attribuez des autorisations d'administrateur de base de données : accordez à un utilisateur toutes les autorisations sur une base de données spécifique. Pour plus d'informations, consultez la rubrique Accorder des autorisations.

        • Attribuez des autorisations d'accès aux tables ou aux colonnes : accordez à un utilisateur des autorisations spécifiques sur une table ou une colonne. Pour plus d'informations, consultez la rubrique Accorder des autorisations.

    FAQ

    • Problème 1 : un message d'erreur indique que l'utilisateur ne dispose pas de l'autorisation RAM requise pour appeler une API DLF.

      Symptôme : la page affiche un message d'erreur indiquant qu'une autorisation RAM est requise pour une autorisation dlf:xxx. Cela signifie que l'utilisateur a besoin des autorisations OpenAPI de la couche 1. Accordez les autorisations requises en attachant la stratégie intégrée AliyunDLFFullAccess ou AliyunDLFReadOnlyAccess dans la console RAM.

    • Problème 2 : un message d'erreur indique que l'utilisateur ne dispose pas de l'autorisation pour une ressource lors d'une tentative d'attribution d'autorisations.

      Symptôme : lorsqu'un utilisateur tente d'accorder une autorisation, un message d'erreur indique qu'il ne dispose pas de l'autorisation dlf permission requise.

      • Accordez à l'utilisateur des autorisations d'attribution de droits pour la ressource spécifique. Vous pouvez également accorder ces autorisations en attribuant un rôle. Pour plus d'informations, consultez la rubrique Accorder des autorisations.

      • Attribuez à l'utilisateur le rôle admin ou super_administrator. Pour plus d'informations, consultez la rubrique Gérer les rôles.

      • Accordez à l'utilisateur des autorisations dlf-dss. Par exemple, l'attribution des autorisations dlf-dss:BatchGrantPermissions et dlf-dss:SelectTable permet à l'utilisateur d'accorder l'autorisation SELECT sur toutes les tables à d'autres utilisateurs.

      Exemple de fenêtre contextuelle d'erreur : le titre est Error Occurred et le message d'erreur est Authorization Failed [4019]. Le message indique que l'utilisateur ne dispose pas de l'autorisation All sur la ressource acs:dlf:cn-hangzhou:{accountId}:metastore/catalogs/{catalogName},databases/default. Le code d'erreur est NoPermission et un message indique que le principal a échoué à la vérification des autorisations dlf.

    • Problème 3 : un message d'erreur indique que l'utilisateur ne dispose pas de l'autorisation pour appeler une opération API du plan de contrôle, telle que ListPermissions ou ListRoles.

      Symptôme : une erreur avec le code d'erreur NoPermission se produit lorsqu'un utilisateur appelle une opération API du plan de contrôle, telle qu'une opération d'interrogation des autorisations ou de gestion des rôles. Le message d'erreur indique que l'utilisateur ne dispose pas de l'autorisation pour l'opération. Pour résoudre ce problème, utilisez l'une des méthodes suivantes :

      Exemple de fenêtre contextuelle d'erreur : le titre est Error Occurred. Le message d'erreur indique que l'utilisateur ne dispose pas de l'autorisation pour effectuer une opération lors de l'appel d'une API du plan de contrôle telle que ListPermissions ou ListRoles. Le code d'erreur est NoPermission et un message indique que le principal a échoué à la vérification des autorisations dlf.

      • Attribuez à l'utilisateur le rôle admin ou super_administrator. Pour plus d'informations, consultez la rubrique Gérer les rôles.

      • Accordez à l'utilisateur des autorisations dlf-dss. DLF fournit les stratégies intégrées AliyunDLFDSSFullAccess et AliyunDLFDSSReadOnlyAccess dans la console RAM. Par exemple :

        • dlf-dss:ListRoles : permet à l'utilisateur de consulter tous les rôles dans DLF.

        • dlf-dss:ListPermissions : permet à l'utilisateur de consulter toutes les autorisations accordées dans DLF.