Si vous disposez d'un dashboard multi-tenant sur une plateforme BI compatible OAuth et souhaitez restreindre l'accès aux lignes d'une table en fonction d'un utilisateur ou d'un groupe précis, la sécurité au niveau des lignes de BigQuery est faite pour vous.
Historiquement, restreindre l'accès à certaines lignes consistait à ajouter des colonnes supplémentaires dans la table pour identifier les ayants droit, puis à effectuer un JOIN avec une table auxiliaire listant ces utilisateurs ou groupes. Par exemple :
SELECT
t.*
FROM `project.dataset.table` AS t
JOIN `project.dataset.users` AS u ON t.access=u.name;
Plutôt simple, n'est-ce pas ? Sauf que maintenir cette table d'utilisateurs demande un effort supplémentaire à chaque ajout ou suppression. Pour éviter cela, utilisez la fonctionnalité de sécurité au niveau des lignes disponible dans BigQuery. Vous pouvez désormais accorder l'accès directement via les groupes Google et unifier la gestion. Par exemple :
CREATE OR REPLACE ROW ACCESS POLICY policy_<customer_id>
ON `project.dataset.table`
GRANT TO ('group:<customer_id>@<domain>')
FILTER USING (customer_id = '<customer_id>');
Par ailleurs, plutôt que de recourir à des identifiants communs reposant sur un Single-Service Account, vous pouvez vous appuyer sur l'autorisation de l'utilisateur via OAuth. Vous obtenez ainsi un accès plus fin (sécurité et audit), un contrôle des quotas et des données d'utilisation pour piloter le produit à partir de ces informations.
J'espère que vous êtes rigoureux et que vos décisions s'appuient sur des faits concrets.
Le défi
Si vous comptez plus de 100 clients en phase de montée en charge, cette solution n'est pas viable : BigQuery impose une limite stricte (croyez-moi sur parole et ne perdez pas de temps à demander à Google de la relever). Et puis, créer plus de 100 règles pour une seule table, ça paraît un peu excessif, non ?
Autre question : que faire si vous voulez disposer d'un groupe d'administrateurs ayant réellement besoin d'accéder à l'ensemble des données ? Ce cas d'usage peut lui aussi se révéler épineux.
Comment relever ce défi ?
L'approche suivante filtre l'accès à partir du nom de domaine de l'utilisateur. Avantage : vous évitez la création de nouveaux groupes et la gestion de leurs membres. Elle garantit également un accès illimité aux données pour votre groupe interne — le tout avec seulement deux politiques au niveau des lignes.
L'inconvénient évident : vos clients doivent disposer d'un nom de domaine d'entreprise pour que la méthode soit réellement efficace. Cette solution n'est pas adaptée aux domaines génériques type gmail.com, yahoo.com ou hotmail.com, sous peine d'accorder l'accès à des millions d'utilisateurs.
-- Create a table
CREATE TABLE test.my_table (
id INT,
name STRING,
domain STRING);
-- Insert some values
INSERT INTO test.my_table (id, name, domain) VALUES
(1, 'test1', 'example.com'),
(2, 'test2', 'domain.com');
-- Restrict access to the users based on their domain name
CREATE OR REPLACE ROW ACCESS POLICY restrict_per_domain
ON `test.my_table`
GRANT TO ('allAuthenticatedUsers')
FILTER USING (domain = SUBSTR(SESSION_USER(),STRPOS(SESSION_USER(),'@')+1));
-- Grant access to an internal DoiT group
CREATE OR REPLACE ROW ACCESS POLICY grant_internal_group
ON `test.my_table`
GRANT TO ('group:<internal_group>@<domain>')
FILTER USING (1=1);
Résultat :
1. [email protected], qui appartient au groupe allAuthenticatedUsers, ne voit qu'une seule ligne, tandis que
2. [email protected], qui appartient au groupe [email protected], voit toutes les lignes.
En résumé : les politiques permissives au niveau des lignes l'emportent sur les plus restrictives (comme pour l'héritage des permissions IAM) et, bien que Google ne le documente pas explicitement, il est possible d'utiliser des groupes tels que allAuthenticatedUsers.
Pour conclure, nous avons vu comment exploiter pleinement la sécurité au niveau des lignes avec un outil BI compatible OAuth. Vous gardez ainsi la maîtrise du quoi, du quand et du qui — tout en réduisant la maintenance. À vous de jouer !
Pour rester en contact, suivez-nous sur le DoiT Engineering Blog , sur LinkedIn DoiT et sur Twitter DoiT . Pour découvrir nos opportunités de carrière, rendez-vous sur https://careers.doit-intl.com .