MaxCompute:Contrôle d'accès au niveau des lignes

CREATE/REPLACE

• Syntaxe

  CREATE [OR REPLACE] ROW ACCESS POLICY [IF NOT EXISTS] <policy_name> 
  ON <table_name> 
  TO <authorized_objects> 
  FILTER USING <filter_expr>
  [AS <clause>];

• Description

  Crée ou modifie une politique d'accès aux lignes afin d'accorder des autorisations à un utilisateur ou à un rôle spécifié.

• Paramètres

  Paramètre	Description
  policy_name	Nom de la politique d'accès aux lignes. Vous pouvez personnaliser ce nom.
  table_name	Nom de la table à laquelle accéder.
  authorized_objects	Objet à autoriser. Valeurs possibles : USER <user_list> : liste des noms d'utilisateur à autoriser, séparés par des virgules. ROLE <role_list> : liste des noms de rôle à autoriser. Plusieurs noms de rôle sont séparés par des virgules. DEFAULT : règle par défaut appliquée lorsqu'aucune règle utilisateur ni aucune règle de rôle ne correspond.
  filter_expr	Expression de filtre. Pour plus d'informations, consultez la section description de filter_expr.
  clause	Attribut de la politique d'accès aux lignes. La valeur peut être PERMISSIVE ou RESTRICTIVE. Pour plus d'informations, consultez la section Spécification de l'attribut PERMISSIVE ou RESTRICTIVE.

  • Description de filter_expr

    La version actuelle impose des contraintes strictes sur filter_expr :

    • filter_expr doit être une expression scalaire qui renvoie une valeur de type BOOLEAN.

    • L'expression ne peut pas contenir de sous-requêtes ni d'instructions telles que SELECT, CREATE ou UPDATE.

    • filter_expr ne peut faire référence qu'à des constantes ou à des colonnes de la table autorisée. Elle ne peut pas référencer de colonnes provenant d'autres tables.

    • Vous pouvez utiliser les opérateurs intégrés de MaxCompute, notamment les opérateurs relationnels, arithmétiques, binaires et logiques. Pour plus d'informations, consultez la rubrique Opérateurs.

    • Seul un sous-ensemble de fonctions scalaires intégrées est autorisé. Les fonctions définies par l'utilisateur (UDF), les fonctions d'agrégation et les fonctions de fenêtrage ne sont pas prises en charge. Les fonctions prises en charge sont les suivantes :

      • Fonctions de chaîne : CONCAT, CONCAT_WS, GET_JSON_OBJECT, INSTR, LENGTH, LENGTHB, REGEXP_EXTRACT, REGEXP_REPLACE, REVERSE, SUBSTR, TOLOWER, TOUPPER, TRIM, LTRIM, RTRIM, REPLACE.

      • Fonctions mathématiques : ABS, ROUND.

      • Fonctions de date et d'heure : DATEADD, TO_DATE, TO_CHAR.

      • Autres fonctions : SIZE, FIELD, COALESCE, IF, SPLIT.

  • Spécification de l'attribut PERMISSIVE ou RESTRICTIVE

    Plusieurs politiques peuvent s'appliquer à un utilisateur donné. Ces politiques sont alors combinées pour déterminer si l'utilisateur peut finalement accéder à une ligne de données spécifique. Lors de la création d'une politique d'accès aux lignes, vous pouvez utiliser AS {PERMISSIVE | RESTRICTIVE} pour spécifier l'attribut de la politique comme étant PERMISSIVE ou RESTRICTIVE. Si vous ne spécifiez aucun attribut, la politique est définie sur PERMISSIVE par défaut. Voici un exemple :

    Si plusieurs politiques s'appliquent à un utilisateur :

    • Si toutes les politiques sont PERMISSIVE, elles se combinent selon une relation OU. Un utilisateur peut accéder à une ligne si l'expression filter_expr d'au moins une politique est évaluée à vrai.

    • Si toutes les politiques sont RESTRICTIVE, elles se combinent selon une relation ET. Un utilisateur ne peut accéder à une ligne que si toutes les politiques sont satisfaites.

    • Si certaines politiques sont PERMISSIVE et d'autres RESTRICTIVE, un utilisateur ne peut accéder à une ligne que si les deux conditions suivantes sont remplies pour cette ligne :

      • Au moins une des politiques PERMISSIVE est satisfaite.

      • Toutes les politiques RESTRICTIVE sont satisfaites.

    Remarque

    Chaque fois que vous ajoutez une nouvelle politique d'accès aux lignes à une table, vous devez évaluer l'effet combiné de toutes les politiques appliquées à cette table. Par exemple, si un utilisateur est soumis à des politiques RESTRICTIVE et PERMISSIVE, il doit satisfaire aux conditions de toutes les politiques RESTRICTIVE et d'au moins une politique PERMISSIVE.

• Cas d'utilisation

  • Accorder des autorisations à un utilisateur spécifique

    Supposons qu'une table soit nommée table01 et contienne une colonne STRING nommée region. Une politique d'accès aux lignes est configurée pour certains utilisateurs afin de restreindre leur accès aux seuls enregistrements dont la valeur de la colonne region est china. Voici un exemple de commande :

    CREATE ROW ACCESS POLICY policy01
    ON table01
    TO USER (aliyun$odps_test01**@aliyun.com,aliyun$odps_test02**@aliyun.com)
    FILTER USING (region = "china");

  • Accorder des autorisations à un rôle spécifique

    Supposons que le système comporte deux rôles, role1 et role2. Vous pouvez autoriser ces deux rôles à accéder uniquement aux enregistrements dont le champ region a la valeur china. La commande est la suivante :

    CREATE ROW ACCESS POLICY policy02
    ON table01
    TO ROLE (role1, role2)
    FILTER USING (region = "china");

  • Accorder des autorisations à l'utilisateur par défaut

    Lorsque vous ajoutez la première politique d'accès aux lignes à une table, l'accès devient restreint. Les utilisateurs qui ne correspondent à aucune politique perdent l'accès aux données, car ils ne figurent pas sur une liste d'autorisation. Pour contrôler l'accès des autres utilisateurs, vous pouvez configurer une politique par défaut. À ce stade, l'administrateur peut utiliser les commandes suivantes pour modifier les autorisations d'accès de l'utilisateur par défaut.

    Refuser l'accès à tous les autres utilisateurs par défaut revient à spécifier que l'utilisateur par défaut ne dispose d'aucune autorisation d'accès.

    CREATE ROW ACCESS POLICY policy03 
    ON table01
    TO DEFAULT 
    FILTER USING (false);

    Si vous souhaitez limiter l'utilisateur par défaut à l'accès aux seuls enregistrements dont le champ region a la valeur other, la commande est la suivante :

    CREATE ROW ACCESS POLICY policy04 
    ON table01
    TO default 
    FILTER USING (region = "other");

    Important

    Lors de l'ajout d'une politique d'accès aux lignes à une table, tenez compte du comportement d'accès des utilisateurs autres que ceux ciblés par le contrôle. Si d'autres utilisateurs ont précédemment accédé à la table, vous devez définir des règles explicites pour eux afin d'éviter des erreurs de refus d'accès inattendues.

• Logique d'autorisation

  Le diagramme de flux suivant illustre le processus d'autorisation lorsqu'un utilisateur accède à une table dotée d'une politique d'accès aux lignes.

  

DROP

• Supprime une politique spécifique d'une table.

  DROP ROW ACCESS POLICY <policy_name> ON <table_name>;

• Supprime toutes les politiques d'une table.

  DROP ALL ROW ACCESS POLICY ON <table_name>;

DESC

Consulte les détails d'une politique spécifique sur une table.

DESC ROW ACCESS POLICY <policy_name> ON <table_name>;

LIST

• Répertorie toutes les politiques appliquées à une table.

  LIST ROW ACCESS POLICY ON <table_name>;

• Consulte les politiques configurées pour un utilisateur spécifique sur une table.

  LIST ROW ACCESS POLICY ON <table_name> TO USER <user_name>;

• Consulte les politiques configurées pour un rôle spécifique sur une table.

  LIST ROW ACCESS POLICY ON <table_name> TO ROLE <role_name>;

-- Create a table.
CREATE TABLE policy_test(a bigint, b string);

-- Insert data into the table.
INSERT overwrite TABLE policy_test VALUES(1L, "1"), (2L, "2"), (3L, "3"), (4L, "4");

-- Check the inserted data.
SELECT * FROM policy_test;
-- The following result is returned:
+------------+---+
| a          | b |
+------------+---+
| 1          | 1 |
| 2          | 2 |
| 3          | 3 |
| 4          | 4 |
+------------+---+

Vérification du comportement de compatibilité

Lorsque MaxCompute évalue une expression de filtre, son comportement peut être influencé par des paramètres de type flag. Si un utilisateur définit une politique d'accès aux lignes selon un comportement de compatibilité donné, puis définit d'autres politiques selon un comportement différent, des fuites de données peuvent survenir en raison de résultats inattendus. Par conséquent, lorsque le contrôle d'accès au niveau des lignes est appliqué, le système vérifie le comportement de compatibilité au moment de la définition. En cas d'incohérence des paramètres, une erreur est signalée et l'accès est refusé.

Exemple : cet exemple utilise les données d'exemple pour montrer comment les politiques sont appliquées selon différents comportements de compatibilité.

1. Le comportement de la fonction SUBSTR lorsque son deuxième paramètre est 0 dépend du mode de compatibilité Hive. Pour plus d'informations, consultez la rubrique SUBSTR.

   • En mode de compatibilité Hive, une position de départ égale à 0 pour la fonction SUBSTR produit le même résultat qu'une position de départ égale à 1.

     SET odps.sql.hive.compatible=true;
     SELECT substr('abc', 0);
     -- In Hive compatibility mode, a start position of 0 is treated the same as a start position of 1.
     +-----+
     | _c0 |
     +-----+
     | abc |
     +-----+

   • Hors du mode de compatibilité Hive, une position de départ égale à 0 renvoie une chaîne vide.

     SET odps.sql.hive.compatible=false;
     SELECT substr('abc', 0);
     -- Outside of Hive compatibility mode, a start position of 0 returns an empty string.
     +-----+
     | _c0 |
     +-----+
     |     |
     +-----+

2. Lors de la création d'une politique d'accès aux lignes, le système vérifie les opérateurs et les fonctions utilisés dans filter_expr. Si leur comportement dépend de certains paramètres Flag, ces paramètres sont enregistrés dans Settings. Vous pouvez utiliser la commande DESC pour consulter les paramètres Flag concernés.

   -- Delete all policies on the table.
   DROP ALL row access policy ON policy_test;
   
   -- Configure a policy in Hive compatibility mode, using the SUBSTR function in filter_expr.
   SET odps.sql.hive.compatible=true;
   CREATE row access policy policy04 ON policy_test TO default filter using(substr(b, 0)='1');
   
   -- View the details of the policy configured on the policy_test table.
   DESC row access policy policy04 on policy_test;

   Le résultat suivant est renvoyé : le champ Settings affiche la valeur du paramètre odps.sql.hive.compatible.

   Authorization Type: Row Access Policy
   Name: policy04
   Objects: acs:odps:*:projects/sql_optimizer/tables/policy_test
   FilterExpr: substr(b, 0) = '1'
   NormalizedFilterExpr: ::substr(policy_test.b, 0) = '1'
   Restrictive: false
   Settings: odps.sql.hive.compatible=true

3. Lors de l'application ultérieure de la politique, le système vérifie si les Settings de l'environnement actuel correspondent aux Settings en vigueur lors de la création de la politique. En cas d'incohérence, une erreur est signalée.

   • Appliquez la politique en mode de compatibilité Hive.

     SET odps.sql.hive.compatible=true;
     SELECT * FROM policy_test;

     Le résultat suivant est renvoyé :

     +------------+---+
     | a          | b |
     +------------+---+
     | 1          | 1 |
     +------------+---+

   • En mode non compatible avec Hive, la requête échoue car la valeur du paramètre odps.sql.hive.compatible est incohérente avec celle spécifiée lors de la création de la politique.

     SET odps.sql.hive.compatible=false;
     SELECT * FROM policy_test;

     Le résultat suivant est renvoyé :

     FAILED: ODPS-0130071:[0,0] Semantic analysis exception - physical plan generation failed: java.lang.IllegalArgumentException: Row access policy flag mismatch for: odps.sql.hive.compatible, flag value when grant this policy is true, while at runtime is false. please set odps.sql.hive.compatible = true or contact your project manager.

Comportement de téléchargement via MaxCompute Tunnel

Lorsque vous téléchargez des données depuis une table dotée d'une politique d'accès aux lignes à l'aide de MaxCompute Tunnel, les règles de contrôle d'accès au niveau des lignes doivent toujours être respectées. Toutefois, Tunnel ne peut pas exécuter lui-même la logique de filtrage. Il lance donc une tâche SQL pour filtrer les données, puis télécharge le résultat.

Par conséquent, lorsque vous utilisez des commandes Tunnel ou le SDK Tunnel pour télécharger des données depuis une table MaxCompute dotée d'une politique d'accès aux lignes, un délai d'attente survient pendant l'exécution de la tâche SQL.

Désactivation de la création de politiques d'accès aux lignes

Pour empêcher la création de nouvelles politiques d'accès aux lignes dans un projet, un administrateur de projet peut exécuter la commande suivante afin de modifier les propriétés du projet :

setproject odps.sql.create.row.policy.disable=true;

Les valeurs possibles sont les suivantes :

• false (par défaut) : autorise la création de nouvelles politiques d'accès aux lignes.

• true : interdit la création de nouvelles politiques d'accès aux lignes, mais permet la modification et la suppression des politiques existantes.