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 propre compte cloud. 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 courantes

Le control plane de ClickHouse Cloud pilote votre BYOC deployment sans lire les données client. Les composants qui envoient des données vers l’infrastructure détenue par ClickHouse ne transmettent que des metadata opérationnelles : Le trafic de query, le contenu des tables et les schemas ne transitent jamais par ces canaux. L’intégralité de votre dataset de monitoring — la stack Prometheus et Thanos, ainsi que vos logs — reste dans votre propre account ; la telemetry limitée décrite dans le tableau ci-dessus constitue les seules données d’observability exportées en continu vers les systèmes détenus par ClickHouse. Les tableaux de bord Monitoring de ClickHouse et, après escalation approuvée, ses ingénieurs peuvent en outre interroger cette stack et vos logs sur place via Tailscale, sans qu’aucune donnée ne soit persistée du côté de ClickHouse — voir accès de dépannage. Consultez les frontières réseau pour la référence complète des flux Inbound et Outbound.

​
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

Au sein de ClickHouse, l’accès de dépannage approuvé est limité aux tables système. 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. Au sein de ClickHouse, l’accès est limité aux seules tables système.

​
Diagnostics d’infrastructure

Cette même procédure d’escalation soumise à approbation peut également accorder, de façon distincte, un accès limité dans le temps aux surfaces d’infrastructure via Tailscale : le Kubernetes API server, ainsi que le monitoring stack et les logs internes au cluster. Il s’agit d’une surface distincte de l’accès à ClickHouse décrit ci-dessus : elle ne contient aucune donnée de table client, et rien de ce qui y est consulté n’est persisté du côté de ClickHouse.

​
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 persistance côté ClickHouse : les résultats consultés lors d’une session de dépannage — qu’ils proviennent des tables système, de la stack de monitoring ou de vos logs — parviennent à l’outillage de l’ingénieur pour y être affichés, mais ne sont ni stockés dans l’infrastructure ClickHouse ni renvoyés vers celle-ci.

​
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 (ClickHouse) : 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.
  • Visible côté client (infrastructure) : system.query_log ne peut pas rendre compte des surfaces d’infrastructure ci-dessus. Les appels à l’API Kubernetes apparaissent dans les audit logs Kubernetes de votre cluster, les appels à l’API cloud dans votre piste d’audit cloud, et les connexions Tailscale elles-mêmes dans vos journaux de flux, là où vous les avez activés. Consultez Auditer la frontière pour savoir où se trouve chacun de ces éléments selon le cloud, et lesquels sont activés par défaut.
  • 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 26 septembre 2026