6.4 安全控制

6.4 安全控制

本节摘要：本节讲 ClickHouse 的安全体系：RBAC 权限、TLS 加密、配额限流、审计日志。给集群加护栏，防止误操作和资源滥用。

阅读收获

阅读完本节，你应当能够：

1. 用 RBAC 配置用户、角色、权限
2. 配置 TLS 加密客户端-服务端通信
3. 用 Quota 限制用户资源，防滥用
4. 开启审计日志追踪操作

一、RBAC 权限模型

ClickHouse 的权限基于 RBAC（基于角色的访问控制）。核心概念：

• 用户（user）：登录账号，有密码、网络限制、默认角色。
• 角色（role）：权限的集合，授予用户后用户获得这些权限。
• 权限（privilege）：能做什么操作，粒度到库/表/列。

-- 建角色并授权
CREATE ROLE analyst_role;
GRANT SELECT ON default.* TO analyst_role;
GRANT INSERT ON default.events TO analyst_role;

-- 建用户并授角色
CREATE USER alice IDENTIFIED WITH sha256_password BY 'xxx';
GRANT analyst_role TO alice;

-- 设置默认角色
ALTER USER alice DEFAULT ROLE analyst_role;
​

权限粒度很细，可以按操作类型（SELECT/INSERT/ALTER/CREATE/DROP）和对象（库/表/列）授权。生产建议按角色分配，用户只授角色，不直接授权限，方便管理。

二、最小权限原则

给权限要克制，遵循最小权限——只给业务必需的，别给 ALL PRIVILEGES：

特别要限制 DROP 和 ALTER——误删误改的根源往往是权限给太宽。生产账号不该有 DDL 权限，DDL 走单独的运维流程。

三、TLS 加密

默认 ClickHouse 客户端到服务端是明文的，生产要开 TLS。配置在 config.xml 里：

• 服务端证书和私钥
• 客户端验证服务端证书（可选双向认证）

开 TLS 后，HTTP 和 TCP 端口都能加密。副本间同步、Distributed 表跨节点通信也建议加密，防内网嗅探。

⚠️ 常见坑：很多人只加密外部访问，内网节点间通信还是明文。内网不是绝对安全——一旦一台被入侵，明文通信可被嗅探。生产建议全链路 TLS。

四、配额限流（Quota）

Quota 限制用户在一段时间内的资源使用，防某个用户把集群资源吃光：

-- 限制用户每小时查询数和扫描行数
CREATE QUOTA analyst_quota
FOR INTERVAL 1 HOUR
MAX QUERIES 1000
MAX ERRORS 100
MAX ROWS 1000000000
MAX QUERY_DURATION_MS 60000;
GRANT analyst_quota TO analyst_role;
​

Quota 维度：查询数、错误数、扫描行数、查询时长、结果行数。可以按用户或按角色限。配合 max_memory_usage 等单查询限制，构成"单查询 + 用户级"两层资源控制。

五、审计日志

审计日志记录谁在什么时候做了什么操作，是合规和追溯的依据。开启 query_log 并配置记录内容：

<query_log>
    <database>system</database>
    <table>query_log</table>
    <log_queries>1</log_queries>
    <log_query_threads>1</log_query_threads>
</query_log>
​

system.query_log 会记录每条查询的用户、来源 IP、SQL、耗时、扫描行数。排查误操作、追溯责任都靠它。生产要长期保留（按合规要求，金融场景常需保留 6 个月以上）。

-- 查谁删了表
SELECT event_time, user, query
FROM system.query_log
WHERE query LIKE '%DROP TABLE events%'
ORDER BY event_time DESC;
​

六、其他安全要点

• 网络隔离：ClickHouse 端口不直接暴露公网，放内网 + 跳板。
• 密码策略：用 sha256 加密存储，别用明文；定期轮换。
• 多租户：不同业务用不同库 + 不同用户 + Quota 隔离，防互相影响。
• 行级安全：ClickHouse 支持行级权限策略，限制用户只看自己部门的数据。

💡 关键直觉：安全的核心是"最小权限 + 全链路加密 + 可追溯"。权限给克制、通信加密、操作有日志，三件事做到位，绝大多数安全风险就堵住了。别等出事才补，部署时就配好。

核心回顾

• RBAC：用户授角色、角色授权限，按角色管理，粒度到库/表/列。
• 最小权限：只给业务必需的，限制 DROP/ALTER，DDL 走运维流程。
• TLS：生产全链路加密，含内网节点间通信，防嗅探。
• Quota：限制用户查询数/扫描行数/时长，配合单查询限制构成两层控制。
• 审计日志：query_log 记录用户/IP/SQL/耗时，长期保留供追溯。
• 安全三件套：最小权限 + 全链路加密 + 可追溯，部署时就配好。

第 6 章结束。你已经能部署升级、监控告警、备份恢复、安全控制，把 ClickHouse 管成生产级。最后一章看生态集成和架构最佳实践。

权限与配额的管理命令

RBAC 的命令不难，难在管理习惯。下面是一套推荐的初始化流程，从建角色到授权一气呵成：

-- 1. 建业务角色
CREATE ROLE analyst_role;
CREATE ROLE etl_role;

-- 2. 按最小权限授权
GRANT SELECT ON default.* TO analyst_role;
GRANT SELECT, INSERT ON default.events TO etl_role;

-- 3. 建用户并绑定角色
CREATE USER alice IDENTIFIED WITH sha256_password BY 'StrongPass1';
CREATE USER etl_bot IDENTIFIED WITH sha256_password BY 'AnotherStrongPass';
GRANT analyst_role TO alice;
GRANT etl_role TO etl_bot;
​

管理习惯上三条建议：角色只做权限的载体，用户只绑角色、不直接授权限；权限变更改角色而不是逐个改用户；定期用 SHOW GRANTS 审计权限清单，清理不需要的授权：

-- 查看某用户的全部权限
SHOW GRANTS FOR alice;
​

配额和权限是两套东西：权限管"能不能做"，配额管"能做多少"。给看板账号设一个宽松但存在上限的配额，给批量任务账号设严格的配额，能防止单点滥用拖垮集群：

-- 看板账号：每小时最多 600 次查询、扫描 1 亿行
CREATE QUOTA dashboard_quota
FOR INTERVAL 1 HOUR
MAX QUERIES 600
MAX ROWS 100000000;
GRANT dashboard_quota TO dashboard_user;
​

审计是最后一道防线。system.query_log 保留所有操作记录，建议在查询日志表上配 TTL 长期保留（比如 6 个月），同时把异常操作（DROP、ALTER）单独做告警。权限、配额、审计三件套配齐，安全框架就立起来了。