先看一段真实的操作记录。达梦安全版本， SYSDBA建用户：

SQL> CREATE USER CJC IDENTIFIED BY "******" DEFAULT TABLESPACE CJC;
第1 行附近出现错误[-2007]:语法分析出错.

建不了。密码和默认表空间都不让设。只能先建个光秃秃的用户：

SQL> CREATE USER CJC;
操作已执行

然后退出，换 SYSSSO账号登录，再补一刀：

SQL> ALTER USER CJC IDENTIFIED BY "******" DEFAULT TABLESPACE CJC;
操作已执行

两行SQL，两个账号，中间夹一次登录切换。这就是三权分立落到日常运维里的样子。

设计上没毛病，问题出在落地

三权分立的逻辑本身是对的。SYSDBA管运行，SYSSSO管安全策略，SYSAUDITOR管审计。谁也不能既改数据又删痕迹。四权分立再把对象操作拿出去给SYSDBO，拆得更细。

这套东西的驱动力来自等保。等保2.0三级以上明确要求数据库得支持系统管理员、安全管理员、审计员三种权限独立分配。厂商做这个功能，没毛病。

问题是，设计的时候假设了一个前提： 有三个独立的人，分别干这三件事。

现实里这个前提基本不成立。

建个用户切两次账号，这还只是开始

刚才那个例子，还只是“创建用户”一个动作。日常运维里被拆散的操作远不止这一处。

备份恢复，三权下SYSDBA能自己搞定，但严格按职责分离走，备份、审批、验证理论上得不同角色经手。审计日志，SYSDBA看不了，得切SYSAUDITOR，故障排查的时候你想确认某个时间点谁动了什么，得先找审计员。权限调整更微妙，给业务用户加一张表的查询权限，算安全管理员的事还是DBA的事？实际操作里往往还是SYSDBA在做，但这就在职责分离的边界上踩线了。

行业里有句话：“三权分立成了运维的噩梦。”原话可能有点夸张，但意思传达到了。原本一条语句干完的事，现在要两个人、两次登录、两条语句。流程的膨胀速度，比实际安全风险的降低幅度快得多。

说难听点，很多时候就是一个人演三个角色

三权分立有个隐含假设： 至少三个人，各管一摊，互相不汇报、不串通。 这在大型金融机构、运营商、政务云里或许能实现。但在大量中小企业，一个DBA同时管着MySQL、PostgreSQL、Oracle和达梦，可能还兼着系统运维和开发DBA的活。公司不会因为达梦有个三权分立，就多招两个人专门管SYSSSO和SYSAUDITOR。

那怎么办？常见的做法是： 一个人手里攥着三个账号的密码。 建用户切SYSDBA，设密码切SYSSSO，查审计切SYSAUDITOR。数据库层面看，三个角色各司其职，等保测评账号隔离那项能过。组织层面看，还是同一个人。

这就引出一个挺尴尬的问题： 当一套安全机制的组织前提不存在时，它到底在防谁？

数据库能强制账号隔离，但它验证不了“SYSDBA的密码和SYSSSO的密码是不是同一个人在保管”。这是技术手段解决不了的组织问题。数据库也没法强制要求两个账号不能由同一人持有——真那么干了，大部分部署场景直接没法用。

于是形成了一种默契：数据库提供三权分立的“形式”，运维人员提供“一个人分饰三角”的“实质”。合规材料上的账号分离是真的，日常操作里的权力集中也是真的。

好处和代价，都摆桌面上说

先说好处，不吹不黑。

防内部人作恶是真有用。 尤其是外包人员流动性大的环境，一个能改数据又能删审计日志的账号，永远是个风险敞口。多一道锁，就多一道保险。

等保能过。 这是硬指标，没得商量。很多项目上不上三权分立，不取决于技术判断，取决于测评机构那一关。

出事儿的时候能追溯。 谁在什么时间干了什么，审计日志里有记录。真出了数据问题，至少能查到人。

再说代价，也不藏着。

日常运维效率往下掉。 变更频繁的时候，切账号切到怀疑人生。凌晨做割接，本来脑子就不清醒，还要记住现在该用哪个账号。

密码管理反而更乱。 三个账号密码，如果为了省事写成一样，三权分立直接失效，而且比不分立更危险——因为所有人都以为它是安全的。如果写成不一样，运维人员就得维护三套密码，交接的时候新人第一句就问：“这三个账号密码一样吗？”

审计日志的存储和性能开销。 全量审计会挤占业务负载，系统本来就跑得紧的时候，额外开销可能直接影响稳定性。一个不可用的数据库，再安全也没意义。

小团队落不了地。 人不够，强行上三权，最后就是一个人管三个号。合规表格好看，实际权力集中程度和不启用没本质区别。

交接麻烦。 人一走，三个账号的密码如果没交接清楚，系统可能直接卡住。

我的看法：看菜下饭，别为了合规硬上

我不觉得三权分立和四权分立是噱头。在正确的场景里，它们有真实价值。但“正确的场景”比厂商宣传的窄得多。

真正需要三权分立的，是数据敏感度高、操作审计要求严格、 且有足够人力预算配独立角色的环境。政务核心系统、金融交易系统、涉及个人敏感信息的平台，这些场景里，三权分立的成本值得付，因为数据泄露或内部篡改的后果远大于运维效率的损失。

不需要三权分立的，是中小企业的业务库、内部管理系统、数据敏感度不高的应用。这些场景里，强行上三权，结果大概率是“一个人管三个号”，合规材料好看，实际权力集中程度没变。与其在数据库层面做形式化分离，不如把精力放在更实际的地方：最小权限原则严格执行、账号密码妥善管理、关键操作日志留痕、定期权限审计。

四权分立更极端。SYSDBO进来之后，SYSDBA连业务表都碰不了，所有数据操作走SYSDBO。在一个开发、测试、运维本来就不分的团队里，这只会制造更多账号切换。四权真正的适用场景，是开发人员和安全运维人员本身就是两拨人、有明确组织边界的大型系统。不具备这个条件时，强行上四权，就是在三权的形式主义上再加一层。

你贴的那个案例之所以值得琢磨，是因为它暴露了一个错位： 数据库安全功能的设计者，假设了一个“组织健全、人力充足”的使用环境；一线运维面对的，是一个“人手不够、一人多岗”的现实世界。 这两者之间的差距，不是运维人员“不规范操作”能解释的，是系统性的。

安全的目标不是让合规表格好看，是让真实风险可控。当一套机制把大量精力消耗在流程切换和账号管理上，却没实质增加攻击者攻破系统的难度时，该问的不是“运维为什么不用”，而是“它在为谁而设”。

欢迎关注我的公众号《IT小Chen》