Linux Cassandra安全加固：认证、授权、加密与审计

一、Cassandra 安全模型概述

1.1 安全威胁与防护层级

常见威胁：

• 未授权访问：默认无认证，任何人可CQL操作
• 数据窃听：明文传输，网络嗅探
• 权限滥用：超级用户全权，无细粒度控制
• 审计缺失：操作无踪迹，合规审计难

防护四层：

1. 认证（Authentication）：谁能登录
2. 授权（Authorization）：登录后能做什么
3. 加密（Encryption）：传输/存储加密
4. 审计（Auditing）：记录所有操作

5.0增强：更细粒度权限（函数/角色级）、审计插件化。

1.2 启用顺序建议

1. 先认证+授权（内部测试）
2. 再节点间加密（滚动重启）
3. 最后客户端加密+审计（最小影响）

二、认证（Authentication）配置与管理

2.1 启用PasswordAuthenticator

cassandra.yaml：

authenticator:PasswordAuthenticator# 默认AllowAllAuthenticator
authorizer:CassandraAuthorizer
role_manager:CassandraRoleManager

• 重启生效（滚动）
• 默认超级用户：cassandra/cassandra

2.2 角色管理（CQL）

连接cqlsh（旧默认用户）：

-- 创建运营超级用户
CREATEROLE ops_admin WITHPASSWORD = 'strong_password'AND SUPERUSER = trueAND LOGIN = true;

-- 禁用默认用户（生产必做）
ALTERROLE cassandra WITH SUPERUSER = falseAND LOGIN = false;

-- 创建业务角色
CREATEROLE app_user WITHPASSWORD = 'app_pass'AND LOGIN = true;

-- 授予权限（下节详述）
GRANTSELECTON KEYSPACE prod TO app_user;

• 角色（Role）取代User（5.0统一）
• 密码策略：复杂、定期轮换

2.3 JMX认证

cassandra-env.sh：

JVM_OPTS="$JVM_OPTS -Dcassandra.jmx.auth=true"
# 或更细 -Dcom.sun.management.jmxremote.authenticate=true

nodetool加-u/-pw

生产：JMX仅内网。

三、授权（Authorization）深度实践

3.1 CassandraAuthorizer 原理

• 基于角色（Role）的RBAC
• 权限粒度：Keyspace、Table、Function、Role、JMX

权限类型：

• CREATE/ALTER/DROP/MODIFY/SELECT/AUTHORIZE/DESCRIBE 等

3.2 权限授予与管理

示例：

-- 应用角色：只读核心表
GRANTSELECTON KEYSPACE prod.users TO readonly_app;

-- 运维角色：表级管理
GRANTALTERONTABLE prod.logs TO ops_mid;

-- 函数权限（5.0+）
GRANTEXECUTEONFUNCTION prod.hash_func TO app_user;

-- 权限继承
CREATEROLE dev_team;
GRANT readonly_app TO dev_team;  # 继承权限

列出权限：

LIST ALL PERMISSIONS OF ops_admin;
LIST ROLES OF app_user;  # 查看子角色

3.3 最佳实践

• 最小权限原则：应用专用角色，只授必要表
• 角色分层：超级 > 运维 > 应用 > 只读
• 定期审查：脚本导出LIST ALL PERMISSIONS
• 生产禁用超级用户登录

常见坑：忘记GRANT AUTHORIZE，导致无法委托权限。

四、加密（Encryption）配置

4.1 节点间加密（Internode Encryption）

保护Gossip、Streaming、Repair流量。

cassandra.yaml：

server_encryption_options:
internode_encryption:all# none/dc/all（生产all）
keystore:/etc/cassandra/conf/.keystore
keystore_password:keystore_pass
truststore:/etc/cassandra/conf/.truststore
truststore_password:trust_pass
require_client_auth:true# 双向认证
require_endpoint_verification:true

4.2 客户端到节点加密（Client Encryption）

CQL客户端流量。

client_encryption_options:
enabled:true
optional:false# 强制加密
keystore:/etc/cassandra/conf/.keystore
keystore_password:keystore_pass
require_client_auth:true# 客户端证书

4.3 证书生成（OpenSSL脚本）

# 自签CA
openssl req -new -x509 -days 3650 -keyout ca.key -out ca.crt -subj "/CN=MyCA"

# Keystore/Truststore
keytool -genkeypair -alias node -keyalg RSA -keystore .keystore -storepass keystore_pass -keypass key_pass -dname "CN=node1.example.com"

# 导入CA到truststore
keytool -importcert -alias ca -file ca.crt -keystore .truststore -storepass trust_pass -noprompt

生产推荐：Let's Encrypt或企业PKI。

滚动启用：先optional:true测试，再强制。

性能影响：5.0优化后<5%开销。

4.4 存储加密（Transparent Data Encryption，TDE）

5.0+支持SSTable加密（kmip_key_provider）。

生产：敏感数据表启用。

五、审计（Auditing）配置与集成

5.1 启用审计日志

cassandra.yaml：

audit_logging_options:
enabled:true
logger:BinAuditLogger# 或FullQueryLogger（完整CQL）
included_keyspaces:prod,logs
excluded_keyspaces:system
included_categories:QUERY,AUTH,DML
excluded_categories:
included_users:
excluded_users:cassandra

• BinAuditLogger：二进制高效（cassanda-audit工具查看）
• FullQueryLogger：明文CQL（易读，但敏感数据需脱敏）

5.2 查看审计日志

工具：audit工具或ELK集成。

5.0支持JSON格式，便于Filebeat → Elasticsearch。

5.3 最佳实践

• 分类过滤：只审计敏感操作
• 存储分离：审计日志独立盘
• 合规：GDPR/PCI需完整FQL

六、生产安全加固完整模板

cassandra.yaml安全段：

authenticator:PasswordAuthenticator
authorizer:CassandraAuthorizer
role_manager:CassandraRoleManager

server_encryption_options:
internode_encryption:all
...

client_encryption_options:
enabled:true
...

audit_logging_options:
enabled:true
logger:FullQueryLogger
...

防火墙：仅9042（客户端）、7000/7001（节点间）内网开放。

七、常见问题与案例

1. 认证后连接拒 → 默认用户禁用前未创超级 → 用system用户恢复
2. 加密后启动失败 → 证书CN/IP不匹配 → require_endpoint_verification=false临时
3. 权限不足 → GRANT遗漏 → LIST PERMISSIONS检查
4. 审计日志爆炸 → 未过滤 → excluded system
5. 性能下降 → 加密开销 → 硬件加速（AES-NI）