KingbaseES 账号安全与日常加固检查实践：从可用到可控- 惊觉

KingbaseES 账号安全与日常加固检查实践：从可用到可控

这篇文章是咱们这个系列的第 16 篇了。上一篇的话咱们聊了用户、角色还有最小权限控制的东西，那么这篇咱们接着聊安全这个话题，也就是说围绕账号治理、弱权限检查还有敏感操作习惯这些来做个加固。

引言

上一篇咱们其实已经把角色化授权给弄好了。也就是说，报表用户只能读，应用用户去负责业务的写入。但是呢，数据库安全这个东西，它往往仅仅不是你创建几个角色就完事了的。账号是不是长期没人用啊？权限是不是给得太大啦？密码是不是太弱啦？还有是不是存在大家都在用的共享账号啊？这些情况的话，其实都会影响到数据库的安全。

那么这篇文章的话，我也没想着去一次把所有的安全特性都给覆盖了，这不太现实。其实咱们就是从日常能去执行的角度出发，来整理一套适合咱们这个 kb_shop 学习环境的安全检查方法罢了。

这篇文章的重点有这么几个：

看看用户和角色。
检查一下对象的权限。
改一改用户的密码。
限制一下普通用户能访问的范围。
弄一个日常安全检查的 SQL 出来。

文章目录

KingbaseES 账号安全与日常加固检查实践：从可用到可控

安全加固的基本思路

数据库安全的话，通常来说可以拆成三层来看：

层次	关注点
身份认证	谁可以登录
权限控制	登录后能做什么
审查治理	权限是否合理，是否需要回收

咱们这个系列前一篇重点讲的是权限控制，那么这篇的话，其实更多是关注日常的检查还有治理习惯这些。对于写征文和教程来说的话，安全章节它到底有啥价值呢？其实就是让看文章的人能有个意识：数据库这东西，往往仅仅不只是建个表查个数据那么简单，你还必须得考虑谁能来访问、能访问多少东西、还有权限怎么收回来。

电科金仓 KingbaseES 这个数据库，通常来说是用在企业层级里的业务系统当中的。那么账号安全这块，你就不能光指着“知道密码的人少”这一点了。更稳妥一点的搞法是什么呢？其实也就是把账号分层来管。比如说，管理员账号拿来搞对象和权限的维护；应用账号给程序去连着用；报表账号就只读分析；临时账号也就是为了短期排查用的。这样的话，就算某个账号不小心漏了或者被用错了，那它的影响范围往往也会被死死限制在它该干的活里面。

咱们这篇文章截图里面的 \du、\dp 还有那个安全检查脚本输出的东西，其实分别就管了这三类信息：也就是“到底有哪些账号啊”、“对象权限到底给了谁啊”、“当前的会话正不正常啊”。这些东西的话，拿来做日常巡检的基础材料是非常合适的。而且你拿去放在投稿文章里面当实操证据也很好，这说明啥？说明安全加固它绝不是一句空话，而是可以通过命令反复去检查的实在工作。

一、查看用户和角色

咱们先来连上 kb_shop：

cd /d D:\Tools\Kingbase\ES\Server\bin
ksql -U system -d kb_shop -h localhost -p 54321

接着去看看用户和角色：

\du

敲这个命令的话，其实你就能看到当前已经有的角色，还有用户属性和角色成员关系这些了。通常来说，咱们做日常安全检查的时候，这第一步往往仅仅只是得先搞清楚系统里面到底存在哪些账号。

二、检查表权限

接着咱们来查查表的权限：

\dp sales.*
\dp inventory.*
\dp report.*

如果你发现某个普通用户，他居然有了不该有的 UPDATE 或者是 DELETE 权限，这是一个问题。那咋办呢？就需要去评估一下是不是得把这个权限给收回来。

这里的话，你要重点去盯 grantee 还有 privilege_type 这两列。grantee 这个东西，它表示的是权限到底给谁了，可能是某个用户，也有可能是某个角色；那么 privilege_type 呢，它代表的就是具体的权限类型了。对于做报表的用户来说的话，通常仅仅只应该出现查询类的权限；要是你发现报表角色居然有写入或者删除的权限，那就有问题了，你需要回到第十五篇的那个授权模型，重新去把权限收拢一下。

当然了你也可以去查权限信息，像这样写：

SELECT table_schema,
       table_name,
       privilege_type,
       grantee
FROM information_schema.role_table_grants
WHERE table_schema IN ('sales', 'inventory', 'report')
ORDER BY table_schema, table_name, grantee, privilege_type;

这条 SQL 的话，其实挺适合你把它存下来当安全检查脚本用的。

三、修改用户密码

如果说你需要去改一下报表用户的密码的话，像这样搞就行：

ALTER USER report_user WITH PASSWORD 'NewReport@123456';

不过这个密码示例啊，往往仅仅只是用在咱们这个学习环境里面的。到了正式环境里面的话，那你就得老老实实按照你们组织的密码复杂度要求、轮换周期还有凭据管理规范来弄了。千万要避免把真实的密码直接写进文章、脚本或者是代码仓库里面去。

截图里面你能看到密码修改的语句执行成功了，但是文章里面咱们不去展示真实的生产密码，这一点其实也是非常重要的。在教程里面的话，咱们可以用演示的密码来帮大家把流程跑通，但是正式环境里面，那必须得由凭据管理系统、运维平台或者安全规范来统一管理才行。写数据库文章的话，千万别把真实的 IP、真实的账号密码还有生产环境的库名给直接暴露出来。

四、锁定或回收不用的账号

如果说某个用户不用了的情况，咱们可以先去把他的角色给收回来。不过这里我得说一下，咱们这里的回收和删除语句，往往仅仅只是拿来当个治理示例看看的，不太建议你在咱们这个连续学习的环境里面直接去执行。那为什么呢？原因在于如果你执行了，后面你再想复查第十五篇那个报表只读权限的时候，你就得重新去建用户或者重新授权了，这就挺麻烦的。

REVOKE kb_shop_readonly FROM report_user;

这里的话，我之所以先演示去回收角色，而不是上来就直接把用户给删了，其实是有原因的。那为什么呢？因为权限治理这个东西，它得是可逆的，还得是能审查的。很多账号它往往仅仅只是临时停用一下罢了，你直接删了的话，可能就会影响后面去排查问题。你先去回收角色，就能让这个账号失去干活的权限，同时账号的记录还留着，这样也方便确认是不是误删了。等确定真不需要了，再走删除流程，那样的话就更稳妥一点。

如果确定真不需要了的情况，那就可以去删用户了：

DROP USER report_user;

不过在删用户之前的话，你得先确认一下它是不是还拥有什么对象。要是这个用户下面还有表、视图或者别的什么对象，你就得先去把对象的归属给处理了，或者把依赖的东西给删掉才行。

那如果说你已经手快把上面的回收或者删除操作给执行了，后面还想接着用 report_user 的话，那也没事。你可以回到第十五篇，重新把用户建出来，然后再把 kb_shop_readonly 这个角色授给它就行了。

五、避免共享管理员账号

在咱们这个学习环境里面的话，一直都在用 system，这其实是为了让演示简单点。但是在真实环境里面的话，通常来说是不建议好几个人凑在一起共享一个管理员账号的。更合理一点的搞法其实是这样的：

管理员账号：少数人使用，负责管理操作
应用账号：应用程序连接使用，权限受控
报表账号：只读访问报表视图
临时账号：设置用途和回收时间

共享管理员账号这个事儿，它最大的问题就在于，出了事责任很难追查到底是谁干的，而且误操作的风险那也是高得很。

对于搞数据库运维的人来说的话，账号设计还得考虑审计还有交接的问题。一个弄得清清楚楚的账号体系，往往应该能回答这么三个问题：这个账号到底是谁的？为啥它需要这些权限？啥时候得去复查一下或者把权限收回来？即使咱们这个学习环境里面没有什么完整的审计平台，你也可以先通过命名规范、角色说明还有弄个人工的台账，来建立一些基本的治理习惯。

六、建立安全检查脚本

咱们来建个脚本：

D:\Tools\Kingbase\sql\check_security.sql

里面写点啥呢，像这样：

\echo 'Role list'
\du

\echo 'Table privileges'
SELECT table_schema,
       table_name,
       privilege_type,
       grantee
FROM information_schema.role_table_grants
WHERE table_schema IN ('sales', 'inventory', 'report')
ORDER BY table_schema, table_name, grantee, privilege_type;

\echo 'Current sessions'
SELECT pid,
       datname,
       usename,
       client_addr,
       state
FROM pg_stat_activity
WHERE datname = 'kb_shop'
ORDER BY pid;

接着去执行它：

ksql -U system -d kb_shop -h localhost -p 54321 -f D:\Tools\Kingbase\sql\check_security.sql

安全检查脚本这东西，其实你不需要搞得多复杂，关键在于你能定期去跑它，跑出来的结果你能看懂，而且还能从中发现不正常的地方。

把检查的 SQL 存成脚本，这到底有啥好处呢？其实也就是把那种一次性的人工去查，变成了可以重复去干的巡检动作了。后面不管你是要交接给同事，还是要写进运维文档里面，或者说接入定时任务，都可以直接复用这一套检查逻辑。对初学者来说的话，走这一步其实也能帮你养成一个挺重要的习惯：数据库安全这东西，它往往不是等出了问题你再去查，而是要在日常跑着的时候就得持续去盯着观察的。

七、账号安全的日常检查清单

安全加固这活儿，它往往不是你搞一次就完事的，它得是周期性去治理的。通常来说建议你至少定期去查查下面这些内容：

是否存在长期不用账号
是否存在共享管理员账号
普通账号是否拥有过高权限
应用账号是否直接使用管理员角色
临时账号是否按期回收
密码是否长期未更换
是否能追踪账号用途

你也可以给每个账号再去补一张人工台账出来，像这样：

账号	用途	权限角色	负责人	是否长期使用
`report_user`	报表查询	`kb_shop_readonly`	报表负责人	是
`app_user`	应用写入	`kb_shop_writer`	应用负责人	是
临时账号	临时排查	按需授权	DBA	否

只有把数据库内部的权限，还有外部的管理台账给结合起来，安全治理这东西才能搞得更完整一点。

截图里面的那个安全检查脚本，其实是可以和这张台账互相去校验一下的。脚本它负责啥呢？负责把数据库里真实的权限给输出来。台账它负责啥呢？负责说明权限背后的业务用途到底是啥。那如果脚本查出来有个账号在，但是台账里面却没记录，这就说明这个账号得去复核一下了；如果台账里面标的是临时账号，但是在数据库里面却一直没收回来的情况，那这也得弄到整改里面去解决掉。

八、常见问题排查

问题 1：删除用户失败

这个的话，往往可能是因为这个用户下面还挂着对象，或者是有依赖的权限没清理。你得先去查查对象归属到底是谁的，接着再去决定是转移它还是删掉它。

问题 2：应用账号权限不足

这个得按顺序去查了：

是否能连接数据库
是否有 schema USAGE
是否有表权限
是否有序列权限

问题 3：权限越改越乱

出现这个情况的话，我建议你还是通过角色去授权，千万别直接给每个用户一个个去授权。也就是说，用户仅仅只需要加到角色里面去就行，权限这东西集中放在角色上去维护就好了。

九、本文小结

这篇文章接着第十五篇的最小权限控制，咱们进一步扩展到了账号安全还有日常加固检查这些方面。咱们去看了角色、权限还有会话，也演示了怎么改密码、怎么收权限还有怎么弄安全检查脚本。

这篇文章咱们掌握了：

\du
\dp
information_schema.role_table_grants
ALTER USER PASSWORD
REVOKE
DROP USER
安全检查脚本
共享管理员账号风险

到了下一篇的话，咱们就会回到连接场景里面去了，到时候去讲讲怎么在 Windows 客户端上面去远程连 CentOS 服务器上的 KingbaseES。而且还会去排查一下防火墙、监听地址、访问控制规则还有端口连通性这些让人头疼的问题。

转载自 CSDN-专业IT技术社区

原文链接：https://blog.csdn.net/COLLINSXU/article/details/167169507

KingbaseES 账号安全与日常加固检查实践：从可用到可控