7.2 安全性与权限管理

7.2 安全性与权限管理

多人共用一套工具，边界怎么划

本篇是第 7 章第 2 节，承接集群，讲当工具从个人走向团队时的安全与权限，是合规的底座。

Kettle 自身权限较弱，企业版资源库有账号体系，可做连接到转换的访问控制。我们团队用文件+Git 的方案，权限交给 Git 仓库的分支保护与评审，反而更清晰：谁改了哪一步，merge 记录一目了然。

凭据安全是第一要务。连接里的密码必须走变量，真值存配置中心或密文，绝不能进仓库。我们曾因明文密码泄露全网改密，从此所有凭据走变量+定期轮转，Kettle 文件里只见 ${DB_PASS}。

最小权限原则：ETL 账号只给目标库必要的读写，不给 DROP、不给跨库。我们让 DBA 按转换逐库授权，出了问题影响面可控。很多事故是被过大的账号权限放大的。

审计方面，Kettle 的执行日志本身可落库，我们把它接进集中日志，谁在何时跑了什么、改了什么参数都可追溯。对金融类管道，审计轨迹是合规硬要求，不能省。

网络安全上，Carte 的 8080 端口不该对公网开放。我们用内网隔离+访问白名单，必要时走 SSH 隧道。集群节点间通信也限制在同一安全组，避免被横向移动。

关键代码与配置

下面这段 text 给出了可直接落地的配置，输入来自上一步、输出写入目标端：

# 7.2 安全性与权限管理
DB_HOST=${DB_HOST}
DB_PASS=${DB_PASS}   # 由 Vault 注入，文件本身不落密
# Git 仓库忽略此文件，避免误提交
​

凭据与文件分离是我们的铁律。变量名进 Git，真值由配置中心注入，泄露面缩到最小。

# 启动时不绑定公网
Carte.sh 8080 --control-socket=127.0.0.1
# 外部访问走跳板机 SSH 隧道，不直接暴露
​

Carte 端口不对外是安全基线。我们所有执行节点都收在内网，运维走隧道，攻击面极小。

背景

ETL 账号被图省事给了 DBA 全权限，某转换因错误 SQL 误 truncate 了不该动的表。

操作

按转换所需最小权限重建账号，只保留目标库读写，严禁 DDL。

-- 收回危险权限，仅留必要
REVOKE DROP,ALTER ON *.* FROM 'etl_rw'@'%';
GRANT SELECT,INSERT,UPDATE,DELETE ON dwd_* TO 'etl_rw'@'%';
​

结果

误 SQL 失去破坏力，同类事故被根除，影响面受限在 ETL 库内。

解读

根因是权限过度。工具再稳也挡不住过大的账号，最小权限是最后一道围栏。

变式

更优是把 DDL 与 DML 账号分开，结构变更走评审流程用 DDL 账号，日常跑数只用 DML 账号，职责彻底分离。

常见误区与工程取舍

误区：ETL 账号给全权限。必须最小权限，禁 DDL。

误区：密码进仓库。变量名进 Git，真值走配置中心。

取舍：权限交给 Git 评审或资源库账号；Carte 收内网，审计日志落库。

深入：多团队怎么隔离权限

当多个团队共用一套 Kettle 与资源库，权限隔离就必不可少了。连接应按环境（dev/test/prod）与团队分配，避免 A 团队误连 B 团队的生产库。作业与转换在资源库里按角色授权，敏感作业（如清数、发对外文件）限定少数人。凭据统一由秘钥管理注入，个人不持有生产密码。审计上，资源库的变更历史能追溯「谁在何时改了哪个转换」，这是合规与排错的基础。

# 凭据与权限的落地（输入：秘钥管理系统；输出：Kettle 运行上下文变量）
p_db_pwd=${vault:dw_prod:password}   # 从秘钥库动态取，个人不接触明文
# 越权操作在资源库层被拒，并留下审计日志
​

⚠️ 常见坑（安全权限）

• 全员共用一个超级账号：一人误操作拖垮所有人，且无法追责。
• 个人持有生产密码：人员流动后密码难回收，应走秘钥管理。
• 不做审计：出事查不出谁改的，合规过不去。

💡 关键直觉

• 权限是「最小够用」：每人/每组只拿干活必需的连接与作业权限。
• 秘钥管理 + 资源库审计，是多人共用 Kettle 时不可省略的两道闸。

工程实录：多团队权限隔离

全员共用超级账号，一人误操作拖垮所有人。

连接按团队/环境隔离，作业按角色授权，凭据走秘钥库。

p_db_pwd=${vault:dw_prod:password}   # 临时密钥，个人不接触明文
# 数据组可读写 dw、改作业；分析组仅读 dw、不可改
​

越权在资源库层被拒，操作可审计追溯。

权限最小够用，秘钥库+审计是不可省的两道闸。

敏感作业限定少数人，并留审批记录。

参数与阈值速查

现场口诀

权限管理遵循「最小够用」：每人每组的连接与作业权限只给干活必需的，敏感作业限定少数人并留审计。个人不持有生产密码，统一由秘钥库注入。越权操作在资源库层就被拒，并留下谁在何时改了什么的痕迹，这是合规与排错的共同基础。

# 凭据由秘钥库动态注入，个人终端不落地明文
p_db_pwd=${vault:dw_prod:password}
# 审计：资源库记录每次 .ktr/.kjb 变更的操作者与时间戳
​

现场口诀（续）

权限体系要配套密钥轮换与离职回收：人员变动时，秘钥库吊销其临时令牌即可，不必逐库改密码。审计日志让每一次元数据变更都可追溯到人，既满足合规，也让「谁改坏了转换」不再靠猜测。最小够用加可追溯，是多人共用 Kettle 时不可省的两道闸。

权限不是一次性配置，而是持续运维：定期审视谁还拥有什么权限，项目结束即回收，避免权限随人员流动悄悄膨胀成隐患。最小够用加可追溯加定期回收，三者闭环，多人环境才真正安全。