Skip to main content
Par défaut, les employés de ClickHouse n’ont pas accès à vos données. Vos données ClickHouse, y compris toutes les tables utilisateur et les résultats de requête, restent dans votre VPC. Les seuls moyens par lesquels ClickHouse interagit avec votre déploiement sont décrits ci-dessous — aucun ne donne accès aux données des tables client.

Opérations de routine

Le plan de contrôle de ClickHouse Cloud exécute votre déploiement BYOC sans lire les données client. Les composants qui envoient des données hors de votre VPC ne transportent que des métadonnées opérationnelles : Le trafic des requêtes, le contenu des tables et les schémas ne transitent jamais par ces canaux. Les log et les métriques restent à l’intérieur de votre VPC BYOC.

Accès de dépannage

Lorsque les ingénieurs ClickHouse doivent diagnostiquer un problème dans votre déploiement, ils demandent un accès juste à temps via un processus interne d’escalade et d’approbation. Une fois approuvé, cet accès est accordé au moyen d’un certificat à durée limitée et acheminé via Tailscale, jamais via l’internet public.

Ce que les ingénieurs peuvent voir

Avec un accès de dépannage approuvé, les ingénieurs peuvent uniquement consulter les tables système de ClickHouse. Cela inclut :
  • system.query_log — le texte de la requête et les métadonnées d’exécution des requêtes exécutées sur votre service
  • system.tables, system.columns et des tables système similaires — le schéma et les métadonnées
  • D’autres tables system.* utilisées pour le diagnostic (par ex. : parts, mutations, réplicas)

Ce que les ingénieurs ne peuvent pas voir

Les ingénieurs ne peuvent pas consulter les tables utilisateur des clients. L’accès est limité aux seules tables système.

Comment l’accès est contrôlé

  • Approbation requise : chaque demande d’accès passe par un système d’approbation interne avec des approbateurs désignés. Les ingénieurs ne peuvent pas s’octroyer eux-mêmes un accès.
  • Certificats à durée limitée : un certificat temporaire, à durée limitée, est généré pour chaque session approuvée. L’accès expire automatiquement.
  • Authentification par certificat : les certificats remplacent l’authentification par mot de passe pour tout accès humain aux instances BYOC.
  • Lecture seule sur les tables système : l’identité du certificat est limitée à la lecture des tables système.
  • Aucune donnée exportée : les logs et les résultats de requête des sessions de dépannage ne sont jamais renvoyés vers l’infrastructure ClickHouse.

Audit

L’activité des ingénieurs est visible de votre côté et fait l’objet d’un audit par ClickHouse :
  • Visible côté client : chaque requête qu’un ingénieur ClickHouse exécute sur votre instance apparaît dans votre propre system.query_log, y compris le texte de la requête et l’identité du certificat. Vous pouvez en faire l’audit directement depuis votre service ClickHouse.
  • Côté ClickHouse : l’équipe sécurité de ClickHouse journalise et audite en interne toutes les demandes d’accès, les approbations et les connexions Tailscale.

Contrôles futurs

L’approbation contrôlée par le client — où vous approuvez chaque demande d’accès d’un ingénieur avant sa prise d’effet — figure sur la feuille de route. Aujourd’hui, l’approbation est gérée via le processus d’escalade interne de ClickHouse.
Dernière modification le 29 juin 2026