问各位大神一个关于 springboot 项目数据安全的问题

[iColdCat]

背景：

最近在学 springboot 正好公司有个需求 简单点说就是业务系统依赖这个 jar 包之后 就会多出来一个接口 这个接口的返回值是所在的业务系统的所有 api 接口 然后就开发了一个 jar 包（类似于自定义 starter 的那种） 之后各业务系统都引入了这个依赖

具体的实现：

我这边是写了一个 controller 然后通过 spring.factories 的方式把这个 controller 注入到引用的业务系统的容器中实现的 写好之后 deploy 到了私服 之后大家谁需要都可以引用

发现的问题：

如果在 jar 包中能通过这种方式向引用 jar 包的系统中注入一个接口，那么就可以通过 @value 的方式获取配置文件中的所有数据 包括数据库链接、用户名、密码等通用的配置 获取配置之后就可以通过 jdbc 连接数据库然后进行数据的导出 这就会引发一个数据泄露的问题

我们来设想一下：

这是一个 jar 包 这个包的 groupId 和 artifactId 是公开的 比如 我说的是比如哈 某个业务系统的开发人员想要导出数据进行售卖 但是他没法直接查数据库 然后他自己本地写了一个项目 把 groupId 和 artifactId 写成和我这个 jar 包一样 然后在项目中通过 @value 的方式获取了配置之后查数据 那这样就完全可以神不知鬼不觉的把数据盗走对不对

最最最最重要的是 如果任何公司内部的人发现了这个思路 他都可以这么做 而且这么做基本没有被查到的概率 即使是被查到了 也会因为私服密码是通用的而无法定位到具体是哪个人上传过有问题的 jar 包 因为这个操作并不需要把代码推到 git 不需要在生产环境的 Jenkins 进行部署 他需要做的就是用同样的 groupId 和 artifactId 再上传一遍 jar 包然后等待业务系统重启就 ok 了

今早在跟领导商量过之后已经把 jar 包从私服上紧急删除了 并且把 jar 包里的功能代码贴了出来 也通知了各业务系统 让他们把这个依赖移除 如果需要这块功能的话可以直接把代码贴在项目里

但是我个人还是有点疑惑：

这种问题到底有没有可能发生 如果发生了 在大家上传私服用的是同一个账号密码的情况下 能不能查出来具体是谁上传的这个 jar 包

望大佬解惑 本人技术菜鸡 评论区勿喷 和平讨论哈

ok了 感谢各位的回复哈 总结了一下大概有以下几个方式可以避免我所说的问题 1.私服禁止版本覆盖 2.私服分账号 不要多人共用一个账号 3.设置上传权限

[iColdCat]

哦对了 从 jar 包中确实是可以通过 @value 的方式获取业务系统容器中的值的 我已经试验过了

[buliugu]

供应链攻击了解一下

[aofall]

Nexus 私服支持多账户，为什么要所有人共用一个账号呢

数据库账号密码可以试试使用 jasypt 加密，不过这只是保证不以明文来存储密码，并非绝对安全的

有这种担心的应该还是公司人员流动性太大了。。好好想办法怎么留下员工才是最关键的

[clf]

emmmm ，所以你们数据库是端口对外开放的么。服务器安全应该要做到即便所有人都知道你的数据库密码，但就是连不了数据库的程度。比如所有的数据库端口不对外开放，只通过 k8s 网络访问，基本无法直接操作生产数据库。密码知道了也连不了。

对 jar 包版本进行严格管理，禁止版本覆盖，jar 包更新后，用到它的服务手动更新依赖的 jar 包版本，而不是 jar 包更新了就全部重启自动更新。另外就是限制 jar 包源代码的项目权限，不要谁都能访问，私服可以弄成只通过 CI 才能更新，git 上增加代码审计。

[iColdCat]

@buliugu 嗯嗯 好像就是这么一回事
@aofall 目前我公司是只有一个账号的 不过如果分账号之后确实可以解决这个问题 关于人员流动的问题这个就不是我管的了哈哈哈 我只是一个普通的开发人员 刚好遇到了这个场景 想到了这个问题而已

[iColdCat]

@clf 数据库肯定是不会对外开放的 只不过我想的是如果是内部人员操作的话要怎么预防呢 内部人员通过内网是可以访问数据库的 但是直接查的话需要个人的账号密码登陆 所以我在文中说不能直接查数据导出（因为会在个人账号下留有记录）而通过项目查的话就不会存在这个问题

[iColdCat]

@clf 不过禁止版本覆盖也确实是个解决办法哈~ 我公司这边还是可以版本覆盖的 回来我去跟运维他们提个建议

[wangyu17455]

不安全的地方在于引入了来历不明的 jar 包，解决这点就好了，不论是在 jar 包里塞一个 ssh server 还是通过 @value 注解获取配置都只是手段上的区别

[clf]

@iColdCat #6
我司生产环境内网也无法直接访问。需要通过工具+token 代理数据库端口到本地才可以。

通过项目查的意思没大致明白，一种是项目代码直接把数据库数据返回给前端？一种是读服务器账号密码登录到数据库？@value 的风险应该是后者吧。

[iColdCat]

@clf 就是在一些 TO C 的项目里 是没有 ip 白名单的 也就是在公网是可以访问接口的
通过 @value 获取到数据库信息并且连接之后 在封装到一个接口里 然后操作人就可以直接调这个接口就可以获取数据库中的数据

[iColdCat]

@wangyu17455 嗯嗯对 重点是 jar 包的来源 我所说的那个 @value 只是众多干坏事的手段中的一个而已

[notwaste]

好奇为什么不把 “所在的业务系统的所有 api 接口” 放配置中心呢

[iColdCat]

@notwaste 其实也未尝不可 但是对接的三方是比较多的 难免有人会忘记添加

[wolfie]

import bug gets bug 。
谁没事瞎依赖。

[clf]

@iColdCat #10 api 采用白名单机制？除了白名单上的接口（如登录），其它所有接口都是强制身份验证的。引入依赖管理的话，我们是在 gitlab mr 到主分支的时候会触发检查脚本，黑名单上的不允许引入（比如 fastjson 禁止引入，特定模块下禁止引入数据库相关依赖），部分项目采用白名单。

[cheng6563]

我司 Nexus 的 Release 版本上传权限只给了 master 的 CI

[Kyle18Tang]

如果要求不高，没必要写个 Starter ，直接使用 Spring Boot Actuator 的 mappings 这个 Endpoint.

[iColdCat]

@Kyle18Tang 嗯嗯 其实从功能性来讲的话确实是没有必要弄个 starter 但是最开始想的是 开发一个这样的 jar 包 之后其他系统引用一下就 ok 了 就不用所有业务系统再去加接口了