BYOC 安全手册

ClickHouse 在自备 Cloud (BYOC) 模式下采用安全共享责任模型，该模型可从我们的 Trust Center 下载，地址为 https://trust.clickhouse.com。以下信息为 BYOC 客户提供了一些示例，说明如何识别潜在的安全事件。客户应结合自身的安全计划评估这些信息，以确定是否需要额外的检测和告警。

可能已泄露的 ClickHouse 凭据

请参阅数据库审计日志文档，查看用于检测基于凭据的攻击以及调查恶意活动的查询。

应用层拒绝服务攻击

实施拒绝服务 (DoS) 攻击的方法多种多样。如果攻击是通过特定载荷使 ClickHouse 实例崩溃，应先将系统恢复到运行状态，或重启系统并限制访问以重新取得控制权。使用以下查询查看 system.crash_log，以获取有关此次攻击的更多信息。

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

已泄露的由 ClickHouse 创建的 AWS 角色

ClickHouse 使用预先创建的角色来启用系统功能。本节假定客户使用 AWS 并启用了 CloudTrail，且可以访问 CloudTrail 日志。如果某起事件可能是由某个已泄露的角色导致的，请检查 CloudTrail 和 CloudWatch 中与 ClickHouse IAM 角色及相关操作有关的活动。有关 IAM 角色列表，请参阅设置过程中提供的 CloudFormation 堆栈或 Terraform 模块。

未经授权访问 EKS 集群

ClickHouse BYOC 在 EKS 中运行。本节假设客户在 AWS 中使用 CloudTrail 和 CloudWatch，并且可以访问相关日志。如果某起事件可能是由已被入侵的 EKS 集群导致的，请在 EKS CloudWatch 日志中使用以下查询来识别具体威胁。按用户名列出 Kubernetes API 调用次数

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

判断用户是否为 ClickHouse 工程师

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

审查访问 Kubernetes Secret 的用户，排除服务角色

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/

ClickHouse Cloud

Bring Your Own Cloud

可能已泄露的 ClickHouse 凭据

应用层拒绝服务攻击

已泄露的由 ClickHouse 创建的 AWS 角色

未经授权访问 EKS 集群

​可能已泄露的 ClickHouse 凭据

​应用层拒绝服务攻击

​已泄露的由 ClickHouse 创建的 AWS 角色

​未经授权访问 EKS 集群

可能已泄露的 ClickHouse 凭据

应用层拒绝服务攻击

已泄露的由 ClickHouse 创建的 AWS 角色

未经授权访问 EKS 集群