多客户独立数据库下安全服务账号登录方案咨询

背景 #

• 所有客户拥有独立数据库，前后端系统共用，用户通过client id（db-id）登录
• 各数据库内用户密码采用不同加密算法加密
• 客户数据库的密码算法密钥为随机自动生成

核心需求 #

实现服务账号登录客户数据库，且方案无安全漏洞

现有初步方案的风险分析 #

1. 同步生成同算法服务账号密码：风险极高，密码一旦泄露会直接导致客户数据库被非法访问，完全违背客户数据独立安全的原则
2. 后端预留访问入口：即便限制办公IP，仍存在IP伪造、内部人员泄露等风险，属于不可接受的重大安全隐患
3. 指定加密算法用户+API密钥访问：API密钥若管理不善（如存储未加密、传输过程泄露），会引发不可控的安全风险，且密钥生命周期缺乏管控的话，风险会长期存在
4. 授权非特定加密的邮箱账号：账号本身无漏洞，但依赖SMTP发送验证信息，客户系统不支持的话无法落地
5. 客户生成授权码+后端创建同算法用户：这是目前最合理的方案，核心优势在于将访问权限的主动权完全交给客户，仅在客户主动授权时生成对应账号，避免了长期留存的安全风险

优化后的安全落地建议 #

基于第5种方案，可从以下维度进一步强化安全性：

• 授权码严格管控：客户生成的授权码设置短有效期（如15分钟），且仅支持单次使用，创建账号后立即失效
• 服务账号权限最小化：后端创建的服务账号仅赋予当前需求所需的最小权限（例如仅允许查询特定业务表，禁止修改、删除、DDL操作），杜绝过度授权
• 全链路操作审计：对服务账号的所有数据库操作进行完整日志记录，包括操作时间、具体内容、发起IP、操作人员等，确保可追溯
• 账号自动回收：服务账号完成任务后，或到达预设的最长有效期（如24小时），自动从客户数据库中删除，避免长期存在的闲置账号风险
• 授权双向验证：客户生成授权码时需通过二次身份验证（如密码二次确认、企业内部OA审批）；后端创建账号时，需校验授权码与客户数据库唯一标识的绑定关系，防止授权码被冒用

对谷歌API模式的补充说明 #

谷歌API的服务账号默认访问模式，是基于其统一云环境的身份管控体系，并不适用于你的客户独立数据库场景。因为每个客户数据库是完全独立的，必须确保客户对自身数据的绝对控制权，不能默认赋予服务账号无限制访问权限，否则会违反数据安全合规要求（如GDPR、等保2.0）。

内容的提问来源于stack exchange，提问作者AlperXX