Journal d’audit ClickHouse

ClickHouse déplace des quantités énormes de données à une vitesse fulgurante — idéal pour l’analytique, problématique pour quiconque doit prouver précisément qui a touché quoi et quand. L’exécution en colonnes, le traitement distribué et l’ingestion en temps réel créent des environnements où les journaux se dispersent à travers les nœuds comme des plombs de fusil. Pourtant, des régulations telles que SOX, HIPAA, PCI DSS et GDPR exigent des preuves d’audit complètes, immuables et centralisées.

ClickHouse fournit une télémétrie native, mais il n’a jamais été conçu pour fonctionner comme un journal d’audit complet et conforme. Au lieu de cela, il émet des fragments : tables système, journaux texte, flux diagnostiques et métadonnées opérationnelles. Comprendre ces capacités — et leurs limites — est la première étape. La seconde est de voir comment DataSunrise transforme la télémétrie de ClickHouse en un système unifié, enrichi et auditable.

Qu’est-ce qu’un journal d’audit ?

Un journal d’audit est un enregistrement chronologique et résistant à la falsification qui capture chaque action effectuée sur un système de données. Il décrit qui a accédé au système, quelle opération a eu lieu, quels objets ont été impliqués, quand l’action s’est déroulée, d’où la requête est originaire et comment le système a répondu. Pour remplir sa fonction, un journal d’audit doit rester immuable, garantissant qu’aucune modification rétroactive ne peut survenir. Il doit également être complet, capturant toute activité pertinente sans lacunes ; corrélé, de sorte que tous les événements à travers sessions, utilisateurs et nœuds forment un récit cohérent ; enrichi, signifiant que chaque entrée contient des détails contextuels comme les informations d’identité, la sensibilité des données et le risque ; et exportable, permettant aux organisations de produire des preuves réglementaires sur demande.

Les journaux de débogage, journaux de requêtes et journaux de cluster ne sont pas des journaux d’audit. Ce sont des sorties diagnostiques sans garanties, structure ni responsabilité exigées pour la conformité ou la reconstitution judiciaire. Un véritable journal d’audit satisfait aux exigences réglementaires, médico-légales et opérationnelles — pas simplement à l’introspection système. La journalisation native de ClickHouse produit un signal brut, mais pas un enregistrement auditable. DataSunrise fournit la structure, l’enrichissement, la consolidation et l’alignement conformité nécessaires pour transformer ces signaux bruts en une piste d’audit vérifiable.

Présentation de la journalisation d’audit native de ClickHouse

ClickHouse expose la télémétrie opérationnelle et au niveau des requêtes via des tables systèmes et des fichiers journaux à rotation. Ceux-ci constituent la base d’un journal d’audit basique.

1. Tables de journal des requêtes

ClickHouse enregistre de nombreux détails sur le cycle de vie des requêtes dans plusieurs tables système. La table system.query_log capture des informations telles que le texte des requêtes, la durée d’exécution, la consommation mémoire et l’utilisateur authentifié. Une profondeur supplémentaire est stockée dans system.query_thread_log, qui suit les métadonnées d’exécution par thread, et system.part_log, qui documente les opérations d’insertion, de fusion et de réplication liées aux parties de données. Des messages de diagnostic de plus bas niveau sont écrits dans system.text_log, qui sert de flux pour les événements internes du serveur. Les administrateurs interrogent fréquemment system.query_log pour extraire l’activité récente, par exemple :

SELECT
    event_time,
    query_kind,
    query,
    user,
    client_hostname,
    client_name
FROM system.query_log
WHERE event_time > now() - INTERVAL 1 HOUR
ORDER BY event_time DESC;

Ces tables offrent une visibilité brute mais ne constituent pas automatiquement une piste d’audit cohésive.

Journal d'audit ClickHouse - Capture d'écran affichant l’ID de requête et des horodatages répétés. — Cette image montre une section du journal d’audit ClickHouse.

2. Journalisation d’accès et d’autorisation

ClickHouse émet des informations liées à l’accès via diverses méthodes d’autorisation et de contrôle d’accès basé sur les rôles (RBAC). Cela comprend des signaux tels que les contrôles d’accès basés sur les rôles, les tentatives d’authentification échouées, les modifications d’utilisateurs et de rôles, ainsi que les résultats de l’application des privilèges. Ces événements apparaissent dans les journaux système et les tables système, mais ne sont pas unifiés dans une structure d’audit orientée conformité.

Une inspection typique des échecs d’autorisation pourrait ressembler à ceci :

SELECT event_time, type, user, client_address, error_message
FROM system.text_log
WHERE type = 'Information'
  AND error_message ILIKE '%Authentication failed%'
ORDER BY event_time DESC;

Extraire les modifications liées au RBAC peut nécessiter de requêter les métadonnées RBAC de ClickHouse :

SHOW GRANTS;

Parce que ces signaux restent dispersés, corréler le comportement d’authentification avec l’exécution réelle des requêtes nécessite une consolidation externe.

3. Flux de journaux serveur

Au-delà de la journalisation des requêtes et des autorisations, ClickHouse produit des journaux opérationnels qui contiennent souvent des détails pertinents pour l’audit. Cela inclut des entrées dans clickhouse-server.log, des traces du sous-système de réplication, des événements de rechargement de configuration et des messages d’opérations DDL. Par exemple, enquêter sur les événements au niveau serveur nécessite généralement de consulter le fichier journal brut :

sudo tail -n 200 /var/log/clickhouse-server/clickhouse-server.log

Les opérateurs peuvent également analyser l’activité DDL en interrogeant les tables système de ClickHouse :

SELECT event_time, query
FROM system.query_log
WHERE query_kind = 'DDL'
ORDER BY event_time DESC;

Bien que ces sorties fournissent une télémétrie utile, elles existent dans des flux et formats séparés. ClickHouse ne les fusionne pas en un enregistrement d’audit structuré, laissant les organisations corréler manuellement les événements opérationnels lors de la construction d’une piste d’audit conforme.

Journal d’audit DataSunrise pour ClickHouse

DataSunrise transforme la télémétrie fragmentée de ClickHouse en une couche d’audit pleinement normalisée avec corrélation, enrichissement, application de politiques et automatisation de la conformité.

1. Journal d’audit unifié à l’échelle du cluster

DataSunrise crée une vue d’audit unifiée sur l’ensemble du déploiement ClickHouse en consolidant les journaux de requêtes, les événements d’authentification, l’activité RBAC, les opérations au niveau serveur, les contextes de session et les mappages d’objets sensibles. Plutôt que de laisser cette télémétrie dispersée entre plusieurs tables et fichiers journaux, DataSunrise la corrèle en une seule piste d’audit chronologique qui améliore considérablement la visibilité et garantit que toutes les actions analytiques, administratives ou opérationnelles peuvent être tracées avec un contexte complet.