Marico's space

最近折腾 ClickHouse® 部署，在安全这块踩了几个坑。默认安装跑起来是快，但说实话，生产环境直接用就跟裸奔差不多。查了一圈资料，把安全加固的路子摸清楚了，这篇把核心要点说清楚。

为什么数据库安全不能忽视

ClickHouse® 跑着 BI 看板、监控系统、财务报表、IoT 数据分析这些业务，里头全是敏感信息——客户数据、财务记录、运营指标、商业机密。安全没做好，数据泄露、恶意访问、服务瘫掉这些问题分分钟找上门。

默认安装的 ClickHouse® 在性能上下了功夫，但安全方面基本是"你爱咋配咋配"的状态。所以上线前得自己把该补的短板补上。

1. 关掉默认账户

新装的 ClickHouse® 会生成一个 default 用户，生产环境千万别拿它直接跑应用。

正确姿势：

• 设一个强密码
• 给每个应用单独建用户
• 清理掉不用的账户
• 别共用凭证

创建一个专用用户：

CREATE USER analytics
IDENTIFIED BY 'StrongPassword123!';

或者直接在 users.xml 里配置密码：

<users> <default> <password>your_strong_password</password> </default>
</users>

血泪教训：哪怕是开发环境，也别让 default 用户空着密码裸奔。

2. 权限要按需分配，RBAC 用起来

应用连数据库绝对不要用管理员账号。给每个应用、每个角色单独建用户，只给它干活需要的权限。

例子：

CREATE USER analytics_user
IDENTIFIED BY 'strong_password'; GRANT SELECT ON default.* TO analytics_user;

权限别给太大：

✅ 推荐：

GRANT SELECT ON sales.orders TO analyst;

❌ 踩坑：

GRANT ALL ON *.* TO analyst;

最小权限原则（Principle of Least Privilege）记牢了，能省掉后面很多麻烦。

3. 网络访问要收紧

ClickHouse® 默认监听所有网卡，生产环境必须改。

该做的：

• 限制监听网卡
• 只允许授信 IP 访问
• 不要把 ClickHouse® 直接暴露到公网
• 能用内网就用内网

只监听本机：

<listen_host>127.0.0.1</listen_host>

按 IP 限制用户访问：

CREATE USER analytics_user
IDENTIFIED BY 'strong_password'
HOST IP '10.0.0.0/24';

配合 VPN、阿里云 VPC、私有网络、IP 白名单效果更好。

4. 防火墙规则配起来

防火墙是多一层保护，万一 ClickHouse® 配置有漏还能兜底。

示例（ufw）：

sudo ufw allow from 10.0.0.5 to any port 8123 sudo ufw allow from 10.0.0.5 to any port 9000 sudo ufw deny 8123 sudo ufw deny 9000

ClickHouse® 常用端口：

端口	用途
8123	HTTP API
9000	原生 TCP 协议
8443	HTTPS（加密）
9440	加密原生 TCP
9009	副本同步

只开你实际用到的端口，不用的全部关掉。

5. 通信链路要加密

没开 TLS 的话，客户端和 ClickHouse® 之间的所有流量都是明文的，抓包直接看。

生成证书：

openssl req -newkey rsa:2048 -nodes \
-keyout /etc/clickhouse-server/server.key \
-x509 -days 365 \
-out /etc/clickhouse-server/server.crt

启用加密端口：

<https_port>8443</https_port> <tcp_port_secure>9440</tcp_port_secure> <openSSL> <server> <certificateFile>/etc/clickhouse-server/server.crt</certificateFile> <privateKeyFile>/etc/clickhouse-server/server.key</privateKeyFile> <verificationMode>none</verificationMode> <cacheSessions>true</cacheSessions> </server>
</openSSL>

加密连接：

curl https://localhost:8443/?query=SELECT+1 \
-u default:password \
--cacert /etc/clickhouse-server/server.crt

生产环境建议用受信任 CA（证书颁发机构）签发的证书，别用自签名。

6. 资源配额要设

一条烂查询能把你集群资源吃干抹净。用配额给每个用户的使用量设上限。

CREATE QUOTA analytics_quota
FOR INTERVAL 1 HOUR
MAX queries = 1000,
MAX read_rows = 1000000000,
MAX result_rows = 10000000
TO analytics_user;

配额保住了集群稳定性，也防止有人恶意刷资源。

7. 资源使用要监控

监控不只是看性能，发现异常访问也得靠它。

有用的系统表：

SELECT *
FROM system.metrics;

看当前在跑啥：

SELECT *
FROM system.processes;

重点盯这些：

• CPU 占用飙升
• 内存突然变大
• 磁盘空间飞快消耗
• 流量异常增长
• 查询跑很久不停
• 负载突然变高

平时多看看，出问题能第一时间发现。

8. 查询日志和审计要开

生产数据库必须留审计日志，谁干了啥要能查出来。

开启查询日志：

<query_log> <database>system</database> <table>query_log</table> <flush_interval_milliseconds>7500</flush_interval_milliseconds>
</query_log>

查最近的操作记录：

SELECT *
FROM system.query_log
WHERE type='QueryFinish'
AND event_time >= now() - INTERVAL 1 DAY
ORDER BY event_time DESC
LIMIT 20;

日志能帮你查这些：

• 谁登录过
• 哪些查询失败了
• 哪些查询特别重
• 有没有异常访问
• 用户行为分析
• 合规审计

9. 不用的接口关掉

多一个服务就多一个被攻击的面。不需要的功能模块直接禁掉。

<!-- 禁用 MySQL 兼容接口 -->
<!-- <mysql_port>9004</mysql_port> --> <!-- 禁用 PostgreSQL 兼容接口 -->
<!-- <postgresql_port>9005</postgresql_port> --> <!-- 禁用服务器间 HTTP 通信 -->
<!-- <interserver_http_port>9009</interserver_http_port> -->

只保留核心功能，受攻击面小了心里也踏实。

10. 配置文件要保护好

配置文件里往往存着密码、连接信息这些敏感内容，权限要设对。

sudo chmod 640 /etc/clickhouse-server/users.xml sudo chmod 640 /etc/clickhouse-server/config.xml sudo chown clickhouse:clickhouse /etc/clickhouse-server/users.xml sudo chown clickhouse:clickhouse /etc/clickhouse-server/config.xml

只有管理员才应该有权访问这些文件。

11. 版本要及时更新

每个新版本通常都会修安全漏洞、修 bug、优化性能和稳定性。

更新前先在测试环境跑一遍，确认没问题再上生产。

关注官方 Release Notes（新版本包含啥、修了啥问题），别让集群跑在有已知漏洞的旧版本上。

12. 行级安全策略用起来

ClickHouse® 支持行级策略（Row Policies），可以限制不同用户只能看到特定数据。

CREATE ROW POLICY china_policy
ON default.orders
FOR SELECT
USING region='CN'
TO analytics_user;

然后：

SELECT *
FROM default.orders;

用户查出来的数据永远只有：

region = 'CN'

多租户系统或者 SaaS 应用特别适合用这个，不同客户的数据隔离就靠它了。

生产安全检查清单

安全措施	优先级
给 default 用户设密码	紧急
创建专用用户	紧急
限制网络访问	紧急
配置防火墙规则	紧急
开启 SSL/TLS 加密	高
收紧用户权限	高
配置资源配额	高
开启查询日志	高
关闭不用的接口	中
保护配置文件	中
保持版本更新	中
实现行级安全策略	中

最后说几句

安全不是某一个功能，是一整套配合着用的实践。

扎实的身份验证、最小权限访问、网络暴露收紧、通信加密，这是基础。在此之上加上审计日志、监控告警、资源配额、行级策略，才算构建起多层防御体系。

从一开始就按这套来，上生产心里有底，数据安全也有保障。