Guide de sécurité BYOC - ClickHouse Documentation

ClickHouse exploite Bring Your Own Cloud (BYOC) selon un modèle de responsabilité partagée en matière de sécurité, téléchargeable depuis notre Trust Center à l’adresse https://trust.clickhouse.com. Les informations ci-dessous sont fournies aux clients BYOC comme exemples de méthodes permettant d’identifier de potentiels événements de sécurité. Les clients doivent examiner ces informations dans le contexte de leur programme de sécurité afin de déterminer si des détections et des alertes supplémentaires peuvent s’avérer utiles.

Identifiants ClickHouse potentiellement compromis

Consultez la documentation du journal d’audit de la base de données pour obtenir des requêtes permettant de détecter les attaques visant les identifiants, ainsi que des requêtes pour enquêter sur des activités malveillantes.

Attaque par déni de service au niveau applicatif

Il existe différentes façons de mener une attaque par déni de service (DoS). Si l’attaque vise à faire planter l’instance ClickHouse au moyen d’un payload spécifique, remettez le système en état de marche, ou redémarrez-le et restreignez l’accès pour en reprendre le contrôle. Utilisez la query suivante pour examiner system.crash_log afin d’obtenir plus d’informations sur l’attaque.

SELECT * 
FROM clusterAllReplicas('default',system.crash_log)

Compromission des rôles AWS créés par ClickHouse

ClickHouse utilise des rôles créés à l’avance pour activer des fonctions système. Cette section part du principe que le client utilise AWS avec CloudTrail et a accès aux logs CloudTrail. Si un incident peut résulter de la compromission d’un rôle, examinez les activités dans CloudTrail et CloudWatch liées aux rôles IAM de ClickHouse et aux actions associées. Reportez-vous à la stack CloudFormation ou au module Terraform fourni lors de la configuration pour obtenir la liste des rôles IAM.

Accès non autorisé au cluster EKS

ClickHouse BYOC s’exécute dans EKS. Cette section suppose que le client utilise CloudTrail et CloudWatch sur AWS et qu’il a accès aux logs. Si un incident peut résulter de la compromission d’un cluster EKS, utilisez les requêtes ci-dessous dans les logs CloudWatch d’EKS pour identifier des menaces spécifiques. Répertoriez le nombre d’appels à l’API Kubernetes par username

fields user.username
| stats count(*) as count by user.username

Déterminer si un utilisateur est un ingénieur de ClickHouse

fields @timestamp,user.extra.sessionName.0, requestURI, verb,userAgent, @message, @logStream, @log
| sort @timestamp desc
| filter user.username like /clickhouse.com/
| limit 10000

Vérifier les utilisateurs accédant aux secrets Kubernetes, en excluant les rôles de service

fields @timestamp,user.extra.sessionName.0, requestURI, verb,userAgent, @message, @logStream, @log
| sort @timestamp desc
| filter requestURI like /secret/
| filter verb="get"
| filter ispresent(user.extra.sessionName.0)
| filter user.username not like /ClickHouseManagementRole/
| filter user.username not like /data-plane-mgmt/

​Identifiants ClickHouse potentiellement compromis

​Attaque par déni de service au niveau applicatif

​Compromission des rôles AWS créés par ClickHouse

​Accès non autorisé au cluster EKS

Identifiants ClickHouse potentiellement compromis

Attaque par déni de service au niveau applicatif

Compromission des rôles AWS créés par ClickHouse

Accès non autorisé au cluster EKS