> ## Documentation Index
> Fetch the complete documentation index at: https://private-7c7dfe99-parallel-read-in-order-multi-part.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# ClickHouse data access (BYOC)

> Accès des employés de ClickHouse aux données client dans les déploiements BYOC

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.

<h2 id="routine-operations">
  Opérations courantes
</h2>

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 :

| Composant | Ce qui parvient à l'infrastructure détenue par ClickHouse |
| - | - |
| State exporter | State du service et de la Backup (health, status — événements opérationnels, et non le contenu des Backup) vers une queue détenue par ClickHouse Cloud : `SQS` sur AWS, Pub/Sub sur GCP, Service Bus sur Azure. |
| Scraper de billing | Métriques de CPU et de mémoire vers un bucket d'object storage détenu par ClickHouse Cloud. |
| AlertManager | Alertes de health du cluster vers ClickHouse Cloud. |

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](#troubleshooting-access). Consultez les [frontières réseau](/fr/products/bring-your-own-cloud/reference/network-security#network-boundaries) pour la référence complète des flux Inbound et Outbound.

<h2 id="troubleshooting-access">
  Accès de dépannage
</h2>

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](/fr/products/bring-your-own-cloud/reference/network-security#tailscale-private-network), jamais via l’internet public.

<h3 id="what-engineers-can-see">
  Ce que les ingénieurs peuvent voir
</h3>

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)

<h3 id="what-engineers-cant-see">
  Ce que les ingénieurs ne peuvent pas voir
</h3>

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.

<h3 id="infrastructure-diagnostics">
  Diagnostics d'infrastructure
</h3>

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.

<h3 id="how-access-is-enforced">
  Comment l’accès est contrôlé
</h3>

* **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.

<h2 id="auditing">
  Audit
</h2>

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](/fr/products/bring-your-own-cloud/reference/network-security#auditing-the-boundary) 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.

<h2 id="future-controls">
  Contrôles futurs
</h2>

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.

<h2 id="related">
  Voir aussi
</h2>

* [Sécurité réseau BYOC](/fr/products/bring-your-own-cloud/reference/network-security) — comment fonctionnent Tailscale et les frontières réseau
* [Privilège BYOC](/fr/products/bring-your-own-cloud/reference/privilege) — IAM roles créés lors de la mise en place de BYOC