内部威胁防御 - 防止员工信息泄露和离职人员风险
本文约需 13 分钟阅读
发布日期: 最后更新:
内部威胁是当今组织面临的成本最高、最难检测的安全风险之一。与需要突破边界防御的外部攻击不同，内部人员已经拥有合法的访问控制凭据和组织内部知识，因此其操作与日常业务难以区分，往往在很长时间内不被发现。而且内部威胁大多并非有意窃取机密，而是源于邮件误发、配置错误等日常工作中的过失。本文探讨缓解内部威胁的实用策略，从实施最小权限原则到部署行为分析和构建安全意识文化。
内部威胁的统计与实态
恶意内部人员 vs 过失泄露
提到内部威胁，人们往往想象窃取商业机密的间谍，但实际情况大不相同。内部威胁大致分为三类 - 员工过失（邮件误发、共享设置错误、被钓鱼欺骗）、恶意内部人员的有意窃取，以及外部攻击者盗用合法凭据后冒充内部人员。占件数大多数的是过失，虽然单起损失通常低于其他两类，但发生频率高，累计影响很大。若把对策优先级只放在"揪出恶意内部人员"上，件数最多的部分就会被放任不管。
恶意内部人员事件单起损失较大，而且往往要经过数月才被发现。典型案例是即将离职的员工在跳槽到竞争对手之前带走客户名单或技术文档 - 由于本人拥有正当访问权限，仅看带走数据的那一刻，日志上与日常业务毫无区别。而凭据窃取则是外部攻击者通过钓鱼或社会工程获取员工凭据，冒充合法用户入侵系统。这种情况下认证同样是成功的，因此只看认证是否通过的机制无法发现它。
实施最小权限原则
RBAC 与 ABAC 的选择
内部威胁防御的基础是彻底实施最小权限原则。员工仅获得执行职责所需的最低访问权限，不必要的权限立即撤销。实现这一目标的两种主要方法是 RBAC（基于角色的访问控制）和 ABAC（基于属性的访问控制）。
RBAC 将权限集分配给"销售经理""开发人员""会计"等角色。管理简单、易于部署，但当同一角色的员工因项目不同需要不同权限时难以应对。ABAC 通过组合用户属性（部门、角色、位置）、资源属性（机密级别、项目）和环境属性（时间段、来源 IP、设备类型）动态控制访问。例如，可以定义"会计人员仅在工作时间内从公司网络访问本部门财务数据"等精细策略。组织规模越大，外包、兼任、远程办公混杂的程度越高，仅凭职位就越难表达一个人实际需要的权限，因此组合属性的方式变得更有必要。
实际操作中，结合 RBAC 和 ABAC 的混合方法最为有效。用 RBAC 管理基本访问权限，对敏感资源添加 ABAC 动态控制。这些访问控制设计应与整体的企业密码策略保持一致。每 90 天进行一次访问审查，定期清理未使用的权限至关重要。
离职人员访问权限撤销清单
到离职日的时间线
离职人员的访问管理是内部威胁防御中最容易被忽视的领域之一。人事的离职手续与信息系统部门的账号停用往往是两条独立流程，因此即使过了最后工作日，访问权限仍可能通过外部 SaaS 工具、云存储、共享账号或个人设备上缓存的凭据而存活。尤其是各部门自行签约的服务，很容易不在信息系统部门的台账上，最终没有人负责关停。从收到辞职通知的那一刻起，就应开始逐步缩减访问权限。
离职前两周，撤销对机密项目的访问权限，将权限限制在交接所需的范围内。离职前一周，将共享驱动器的写入权限改为只读，并将大量文件下载添加到监控对象。离职当天，立即禁用所有账户。除了 Active Directory、Google Workspace 和 Microsoft 365 外，不要忘记容易被忽视的 SaaS 账户（Slack、GitHub、Notion、Figma、Jira、Salesforce 等）。
在现代工作环境中，一名员工在工作中接触的 SaaS 往往多达数十种，加上 IT 部门不知道的影子 IT，实际数量更多。在这种规模下，靠人工清单逐项停用离职者的账号并做到毫无遗漏并不现实。要确保可靠地撤销离职人员的访问权限，理想的做法是引入支持 SCIM（跨域身份管理系统）协议的身份管理平台，自动化批量账户配置和取消配置。
通过 UEBA 进行异常检测
行为基线与告警
UEBA（用户和实体行为分析）将用户和设备的正常行为模式作为基线进行学习，实时检测偏离行为。与传统的基于规则的检测（"凌晨 2 点登录就告警"）不同，UEBA 使用机器学习分析每个用户的行为模式。只有当通常 9 点到 18 点工作的员工在深夜访问时才发出告警，而夜班员工的深夜访问则被判断为正常。
UEBA 检测的典型异常模式包括：访问通常不访问的数据库或文件服务器、短时间内大量下载文件、向 USB 设备大量复制数据、从异常时间或地点访问、权限提升尝试等。将这些异常与SIEM（安全信息和事件管理）集成，可以进行日志关联分析，检测单独可能被忽略的复合威胁。UEBA 也是从技术上实现零信任安全"始终验证"原则的核心组件。
部署 UEBA 时需要注意的关键问题是误报（false positive）管理。部署初期由于基线学习不充分，会产生大量误报。要建立可用的基线，需要观测覆盖业务完整周期的时间段 - 月初与月末、旺季与淡季 - 因此刚上线时给出的判定不能全盘照信。如果不适当设计告警优先级（风险评分），安全团队可能陷入告警疲劳，错过真正重要的告警。
组织文化与内部举报制度
仅靠技术措施无法完全防止内部威胁。即使部署了监控工具，如果员工感到"被监视"，信任关系就会受损，反而导致不满和离职，增加内部威胁风险。卡内基梅隆大学 CERT 内部威胁中心的研究发现，许多内部威胁源于工作场所不满、对评价的不公平感和人际关系恶化。
在心理安全感高的组织中，员工更愿意报告安全问题。能够不惧报复地报告"同事有可疑行为"或"我不小心将数据发送到外部"的环境至关重要。设计内部举报制度时，应允许匿名举报、明确保护举报人、使调查流程透明化。参考欧盟举报人保护指令（2019/1937）和日本的公益举报人保护法，建立法律保护框架。
零信任架构与内部威胁防御非常契合。它不无条件信任来自内网的通信，而是对每一次资源访问逐次验证其正当性，因此持有合法凭据的内部人员的异常行为也会纳入检查范围。零信任的"永不信任，始终验证"原则应无例外地适用于内部人员。但由于零信任的实施可能影响员工工作效率，需要谨慎设计安全性与便利性的平衡。
现在就能做的事
- 盘点所有员工的访问权限，立即删除业务不需要的权限（优先审查 90 天以上未使用的权限）
- 创建离职人员访问权限撤销清单，盘点包括 SaaS 账户在内的所有服务
- 建立内部举报制度，引入可匿名报告的机制
- 使用 Passtsuku.com 为每个系统生成唯一的强密码，消除凭据共享和重复使用
常见问题
- 内部威胁最常见的原因是什么？
- 按件数来看，一般认为员工过失占了大多数 - 邮件误发、云存储配置错误、被钓鱼欺骗等无恶意行为占了较大比例。有意窃取和盗用凭据的情况较少，但单起造成的损害往往更大。
- 部署 UEBA 需要多长时间？
- UEBA 工具的技术部署可在数周内完成，但构建有效基线需要观测覆盖月初、月末、旺季等业务周期的时间段。由于初期误报频繁，通常需要 3-6 个月的调优来提高告警准确性。
- 离职人员账户停用中最容易被忽视的是什么？
- SaaS 账户是最容易被忽视的领域之一。虽然 Active Directory 和 Google Workspace 由 IT 部门管理，但部门级别订阅的 Slack、Notion、Figma、GitHub 等账户通常不在 IT 管理范围内，离职后访问权限容易残留。应使用支持 SCIM 的身份管理平台集中管理，或确保离职清单涵盖所有 SaaS 服务。
这篇文章对您有帮助吗？