在制造业数字化转型过程中，主机厂对供应商的安全准入要求日益严格。本文从技术角度分析共享账号管理的核心挑战，并介绍一种基于密码代理和身份认证的轻量级解决方案。
背景：为什么"共享账号"成了供应链安全的软肋
在典型的制造业供应链协作场景中，存在大量跨组织的系统访问需求：
- 主机厂派驻工程师到供应商现场进行技术支持
- 供应商将部分开发工作外包给第三方团队
- 多家供应商需要访问同一套协同平台
这些场景下，共享账号几乎成了默认选择——它简单、直接、不需要额外的身份基础设施。
但共享账号带来的问题也很明显：
问题1：不可追溯性
当多人共用同一个系统账号时，日志中只能看到"admin用户在14:30执行了某操作"，而无法确定具体是哪个人。这对于事后审计和安全事件调查来说是致命缺陷。
问题2：密码管理混乱
共享账号的密码通常通过非正式渠道传播：写在白板上、存在共享文档里、口头告知。这导致：
- 密码泄露后无法定位源头
- 离职人员可能仍然知道密码
- 无法强制执行密码定期更换策略
问题3：权限边界模糊
当外包人员使用与正式员工相同的共享账号时，实际上打破了最小权限原则。一旦发生安全事故，影响范围难以控制。
技术方案思路
解决上述问题的核心思路可以概括为：
将"账号"与"人"解耦——让共享账号继续服务于系统访问需求，但确保每次访问都能关联到具体的操作者身份。
实现这一目标需要两个基础组件：
组件1：统一身份层（Identity Layer）
为所有系统访问者建立唯一的数字身份。这个身份需要满足：
- 唯一性（一个人对应一个身份）
- 可验证性（通过多因素认证确认身份真实性）
- 可追溯性（身份与真实人员绑定）
- 生命周期可控（入职开通、离职禁用）
组件2：凭证代理层（Credential Proxy）
在用户与目标系统之间引入一个代理层：
- 用户不再直接接触原始密码
- 代理层根据用户身份动态获取系统凭证
- 所有操作经过代理层时被记录
- 使用完毕后可自动触发密码轮转
架构设计
┌────────────────────────────────────┐
│ 访问请求流程 │
│ │
│ 用户 → [身份认证] → [权限校验] │
│ ↓ ↓ │
│ ASP平台 SYP代理引擎 │
│ (MFA+实名) (动态凭证+审计) │
│ └───────┬───┘ │
│ ▼ │
│ 目标业务系统 │
└────────────────────────────────────┘
关键技术点
1. 密码代管机制
传统模式下，密码存储在用户的大脑或文档中。改进方案将密码集中到一个加密存储库：
# 密码生命周期管理伪代码
class CredentialVault:
def store(self, account_id, password):
# 加密存储（AES-256）
encrypted = self.encrypt(password, self.master_key)
self.db.save(account_id, encrypted)
def retrieve(self, account_id, requester_id):
# 验证请求者权限
if not self.check_acl(requester_id, account_id):
raise AccessDenied()
# 解密返回（明文仅在内存中短暂存在）
return self.decrypt(self.db.get(account_id))
def rotate(self, account_id):
# 自动生成强密码
new_pwd = self.generate_strong_password()
# 更新目标系统
self.update_target_system(account_id, new_pwd)
# 更新密库
self.store(account_id, new_pwd)
2. 会话录制与审计
代理层需要在会话级别记录操作行为。对于不同协议类型，实现方式有所不同：
| 协议 | 审计方式 | 可记录内容 |
|---|---|---|
| RDP/远程桌面 | 屏幕录像 + 键盘输入记录 | 每一步操作可视化回放 |
| SSH/Terminal | 命令行日志 + 输出捕获 | 执行的每条命令及其结果 |
| HTTP/Web | 请求日志 + 响应摘要 | API调用序列 |
| 数据库 | SQL审计 | 执行的SQL语句 |
3. MFA多因素认证集成
身份层需要支持多种第二因子：
# MFA策略配置示例
MFA_POLICY = {
"internal_staff": {
"required": True,
"methods": ["otp_totp", "sms"],
"fallback": ["sms"] # OTP不可用时降级为短信
},
"oem_engineer": {
"required": True,
"methods": ["otp_totp"], # 驻厂工程师仅允许OTP
"fallback": []
},
"contractor": {
"required": True,
"methods": ["sms", "push_notification"],
"max_session_hours": 8, # 外包人员限制单次会话时长
"account_expiry_days": 30 # 账号有效期
}
}
实施踩过的坑
在实际落地过程中，有几个值得注意的点：
坑1：用户抵触情绪
改变习惯总是有阻力的。研发团队习惯了"打开终端就能连服务器"，现在要多做一步身份认证。
缓解措施：选择透明代理模式，让用户的操作体验尽可能接近原有方式。同时做好沟通，说明这是主机厂审核要求而非内部管控。
坑2：老旧系统兼容性
有些遗留系统的认证方式比较特殊（如自研协议、老版本SSH），标准代理方案可能不适用。
应对方式：对于这类系统，可以先采用"半托管"模式——只做密码轮转和基本日志，不做完整代理；或者通过自定义脚本适配特定协议。
坑3：审计日志的数据量
全量录制会产生大量数据，尤其是图形界面的屏幕录像。
建议：
- 设置合理的保留周期（如90天）
- 对敏感命令设置告警规则（如 rm -rf / 、DROP TABLE）
- 定期归档历史日志到低成本存储
合规对标
该方案覆盖的主要合规控制点：
| 标准/框架 | 相关控制项 | 方案覆盖情况 |
|---|---|---|
| 等保2.0 (GB/T 22239) | 身份鉴别(a)、安全审计(g) | ✅ MFA + 全量操作审计 |
| ISO 27001 | A.9 访问控制 | ✅ 最小权限 + 账号生命周期 |
| TISAX | 信息保护 | ✅ 敏感操作可追溯 |
| NIST SP 800-53 | AC-2/AC-6/AU-2 | ✅ 账号管理 + 审计 |
总结
共享账号管理是供应链安全准入中最常见也最棘手的问题之一。通过引入身份认证层和凭证代理层的组合方案，可以在不大幅改变现有工作模式的前提下，实现操作可追溯、密码可管控、权限可回收的目标。这种轻量级的实施路径特别适合中小型供应商在有限资源下快速满足主机厂的审核要求。
参考资料：
- GB/T 22239-2019 信息安全技术 网络安全等级保护基本要求
- ISO/IEC 27001:2022 Information security management systems
- TISAX (Trusted Information Security Assessment Exchange) Assessment Criteria
- NIST Special Publication 800-53 Rev.5 - Security and Privacy Controls
