Contrôle précis des accès pour les flux de modifications

Cette page explique le fonctionnement du contrôle des accès précis avec les flux de modifications Spanner.

Pour les utilisateurs du contrôle des accès précis, vous autorisez l'accès en lecture aux données des flux de modifications à l'aide des autorisations suivantes. Les deux autorisations sont obligatoires.

  • Accordez SELECT au flux de modifications.

    GoogleSQL 

    GRANT SELECT ON CHANGE STREAM CHANGE_STREAM_NAME TO ROLE ROLE_NAME;

    PostgreSQL 

    GRANT SELECT ON CHANGE STREAM CHANGE_STREAM_NAME TO ROLE_NAME;

  • Accordez EXECUTE à la fonction de lecture créée automatiquement pour le flux de modifications. Vous utilisez la fonction de lecture pour lire les enregistrements du flux de modifications.

    GoogleSQL 

    GRANT EXECUTE ON TABLE FUNCTION READ_FUNCTION_NAME TO ROLE ROLE_NAME;

    PostgreSQL 

    GRANT EXECUTE ON FUNCTION READ_FUNCTION_NAME TO ROLE_NAME;

    Pour en savoir plus sur les conventions d'attribution de noms aux fonctions de lecture de flux de modifications et sur le formatage des informations qu'elles renvoient, consultez les articles suivants:

Vues INFORMATION_SCHEMA pour les flux de modifications

Les vues suivantes affichent des informations sur les rôles et les droits de base de données pour les flux de modifications:

Les lignes de ces vues sont filtrées en fonction des droits du rôle de base de données actuel sur les flux de modifications. Cela garantit que les entités principales ne peuvent voir que les rôles, les droits et les flux de modifications auxquels elles ont accès.

Le filtrage des lignes s'applique également aux vues suivantes liées aux flux de modifications:

GoogleSQL

Le rôle système spanner_info_reader et ses membres voient toujours un INFORMATION_SCHEMA non filtré.

PostgreSQL

Le rôle système spanner_info_reader et ses membres voient une information_schema non filtrée.

Le filtrage des lignes s'applique également aux vues de métadonnées suivantes pour les fonctions de lecture du flux de modifications:

GoogleSQL

PostgreSQL

Mises en garde

  • Les flux de modifications utilisent une base de données de métadonnées pour gérer l'état interne. La base de données de métadonnées peut être identique ou différente de la base de données de l'application. Nous vous recommandons d'utiliser une autre base de données. Toutefois, pour les utilisateurs du contrôle des accès précis, la base de données de métadonnées ne peut pas être la même que la base de données de l'application. En effet, le principal IAM qui exécute le job Dataflow a besoin d'un accès en lecture/écriture au niveau de la base de données pour la base de données de métadonnées. Cela remplacerait les droits de contrôle des accès précis qui ont été configurés pour la base de données de l'application.

    Pour en savoir plus, consultez Envisager une base de données de métadonnées distincte.

  • Étant donné qu'un flux de modifications contient une copie distincte des données des tables et des colonnes suivies, soyez prudent lorsque vous accordez aux utilisateurs l'accès au flux de modifications. Les lecteurs du flux de modifications peuvent afficher les modifications de données des tables et colonnes suivies, même s'ils ne disposent pas des droits SELECT sur les tables et les colonnes. Bien qu'il soit plus flexible de configurer des commandes distinctes pour les flux de modifications et leurs tables et colonnes suivies, il existe un risque potentiel. Veillez donc à structurer les rôles et les droits d'accès de la base de données en conséquence. Par exemple, lorsque vous révoquez le privilège SELECT sur une table d'un rôle, envisagez de révoquer également SELECT sur le flux de modifications et de révoquer EXECUTE sur la fonction de lecture associée.

  • Si vous accordez SELECT sur un flux de modifications qui suit toutes les tables, le bénéficiaire peut voir les modifications de données pour toutes les tables ajoutées ultérieurement.

En savoir plus