一、一个“不得不共享”的现实：财务软件只允许一个登录账号

我们公司使用一套外包的 财务报税软件（Delphi 开发），供应商明确告知：

“系统仅支持单用户模式，不允许多账号，也不开放 API。”

但现实中：

• 财务部有 3 人需要操作；
• 每月报税季，大家轮流使用同一套账号密码；
• 登录记录只有“admin 登录成功”，无法区分是谁操作的。

更糟的是：

• 密码写在团队群公告里；
• 曾有实习生误删数据，却无法追责；
• 等保测评直接指出：“共享账号未实现操作可追溯，违反最小权限原则”。

问题本质：
不是我们想共享，而是系统限制我们只能共享。
但安全不能因此妥协——我们需要 “物理共享，逻辑隔离”。

---

二、合规要求 vs 现实约束

要求	现实
等保2.0 二级 8.1.4.1：应唯一标识用户	软件只认一个用户名
《网络安全法》第21条：采取监测、记录网络运行状态的技术措施	软件无审计日志功能
内部风控：操作需可追溯到人	所有操作显示为“admin”

传统方案为何失效？

• 创建多个账号？ → 软件不支持；
• 每人记不同密码？ → 共享场景下不可行；
• 录屏监控？ → 成本高、隐私风险大、难检索。

我们需要一种 “在不改造应用的前提下，实现身份绑定 + 操作审计” 的方案。

---

三、破局思路：通过密码代填 + 会话标记实现“逻辑身份”

核心思想：

让同一个账号密码由系统托管，但每次使用时自动关联真实操作人，并记录上下文。

架构设计

[员工A] → 访问统一门户 → 身份认证（如手机号+验证码）
    ↓
[ASP 凭据中心] → 验证权限后，下发“财务软件”凭据
    ↓
[SYP 本地代理] → 启动财务软件，并自动填入账号密码
    ↓
[同时记录]：操作人=张三，时间=2025-12-10 14:30，IP=192.168.1.105

关键创新：

• 密码永不暴露给用户；
• 每次登录都绑定真实身份；
• 支持 Web（BS）和桌面（CS） 应用。

---

四、技术实现：三步完成安全共享

步骤1：在 ASP身份认证系统中注册“共享应用”

以财务软件为例，在凭据管理系统中创建条目：

{
  "app_name": "tax-finance-system",
  "type": "desktop",
  "executable": "C:\\Finance\\tax.exe",
  "credentials": {
    "username": "admin",
    "password": "EncryptedVaultRef:tax_pwd_2025"
  },
  "allowed_users": ["zhangsan", "lisi", "wangwu"],
  "audit_enabled": true
}

密码由 ASP 动态生成并加密存储，用户无法查看或复制。

步骤2：部署 SYP 本地代理（支持 Windows）

员工电脑安装轻量级代理程序（ 示例：当李四点击“启动财务软件”，SYP 会：

1. 启动 tax.exe；
2. 等待登录窗口出现；
3. 自动输入 admin 和托管密码；
4. 同时上报审计事件。

步骤3：审计日志集中管理

所有操作记录到 ASP 审计中心，字段包括：

字段	示例
操作人	lisi@company.com
应用名称	tax-finance-system
启动时间	2025-12-10 14:32:05
客户端 IP	192.168.1.108
会话 ID	sess-8f3a9c
是否成功	是

支持按人、按应用、按时间段检索，满足等保“6个月日志留存”要求。

---

五、效果对比：从“黑盒操作”到“透明可溯”

场景	传统共享	新方案
密码管理	群公告/Excel	系统托管，用户不可见
登录方式	手动输入	自动代填，防键盘记录
操作归属	全是“admin”	精确到真实员工
离职回收	易遗漏	权限立即撤销
等保合规	不达标	提供完整审计证据链

在最近一次内部审计中，我们成功定位到一笔异常凭证录入，精确到操作人和时间点，避免了更大损失。

---

六、扩展场景：不止财务软件

该模式适用于多种“强制单账号”系统：

类型	示例	解决方案
政府申报系统	电子税务局、社保平台	BS 代填 + 截图存证（可选）
行业专用软件	医疗 HIS、工程 CAD 插件	CS 代填 + 进程监控
SaaS 共享账号	某些按账号收费的 BI 工具	浏览器插件自动登录

 共同特征：

• 无法多账号；
• 无审计能力；
• 需多人使用。

---

七、安全边界与最佳实践

1. 最小权限原则：仅授权必要人员；
2. 会话水印（可选）：在 CS 应用窗口叠加半透明操作人信息；
3. 操作录像（高敏场景）：对特定应用启用屏幕录制（需员工知情）；
4. 应急熔断：发现异常操作，可远程终止会话。

注意：
本方案 不鼓励账号共享，而是在 系统限制无法避免共享时，提供安全兜底。

---

八、写在最后

安全不是理想主义的口号，
而是面对现实约束时的最优解。

当技术限制让我们“不得不共享”，
我们至少可以做到：
密码不泄露、操作可追溯、责任能到人。

这，就是中小企业也能落地的“务实安全”。

互动话题：
你们公司有没有“只能共用一个账号”的系统？
是如何管理权限和审计的？
欢迎评论区分享你的经验！

参考资料：

• GB/T 22239-2019《信息安全技术 网络安全等级保护基本要求》
• NIST SP 800-53 Rev.5：AC-6 Least Privilege
• 《中小企业数据安全管理指南》（中国信通院）

文章作者：五台