企业采购翻译工具时，功能评估通常一周就能完成，真正拖时间的是安全评审。IT 和法务关心的问题和业务部门完全不同：用户身份怎么管、数据存在哪、离职员工的访问怎么回收、出了事故审计日志能不能查。这篇讲的是这一侧的部署实践。
SAML 2.0：先理清三个角色
单点登录的配置之所以容易出错，是因为很多人没分清三个角色的职责。身份提供方（IdP，比如 Okta、Azure AD、OneLogin）负责验证用户身份；服务提供方（SP，也就是应用本身）负责接受断言并授予访问；用户浏览器只是在两者之间传递断言。
配置时最关键的三个值是实体 ID、断言消费服务地址（ACS URL）和签名证书。实体 ID 两边必须完全一致，包括协议头和结尾斜杠。ACS URL 填错会导致断言发到错误的端点，表现为登录后白屏。证书过期是最常见的故障原因，建议在证书到期前 30 天设置提醒，并提前完成轮换。
SCIM：让账号生命周期自动化
只配 SSO 不配 SCIM 是很多团队的遗留问题。SSO 解决的是怎么登录，SCIM 解决的是谁应该存在。没有 SCIM，员工入职要手工建账号，离职要手工删账号——而后者经常被忘记。
SCIM 打通之后，IdP 里的用户创建、属性更新、停用、删除会自动同步到应用侧。部门字段可以映射成应用里的团队归属，职级字段可以映射成权限组。这里有个实践建议：把停用和删除区分开，停用保留数据便于交接，删除才真正清除——直接删除会导致该用户创建的术语表和翻译记忆一并消失。
会话生命周期要和风险等级匹配
会话超时设置是安全和体验之间的直接权衡。设太短，用户一天登录五次会想办法绕过；设太长，共享设备上的会话会成为风险敞口。
比较合理的做法是分层：普通办公网络下的会话可以设 8 到 12 小时，覆盖一个工作日；从非受信网络访问时缩短到 1 小时并要求二次验证；涉及管理后台的操作单独设置更短的超时。另外要确认 IdP 侧的单点登出确实生效——很多环境里 SSO 配好了，但登出只清了应用侧的会话，IdP 会话还在，换个标签页又能进去。
数据处理边界要写进合同
安全评审里最难通过的往往不是技术项，而是数据流向。需要明确回答的问题包括：提交的文本存在哪个区域、保留多久、是否用于模型训练、子处理方有哪些、发生泄露时的通知时限。
数据安全说明和内容删除策略覆盖了保留期和删除机制的具体条款。对有数据驻留要求的行业——金融、医疗、政府——要在选型阶段就确认可选的部署区域，这个不是上线后能改的配置。
审计日志：出事之后才想起来就晚了
审计日志的价值在于事后可追溯，但前提是事前就开着并且留存足够久。需要覆盖的事件至少包括：登录成功与失败、权限变更、术语表和风格规则的修改、批量导出、管理员操作。
日志本身要能导出到企业的 SIEM 系统做统一分析，光在应用后台能看是不够的——安全团队不会为了一个应用单独去翻一个后台。留存期建议对齐公司的整体合规要求，金融和医疗行业通常要求 6 个月到 7 年不等。
分阶段上线，不要一次性全员开通
建议按四步走：先在 IT 部门内部做 20 人左右的试点，验证 SSO 和 SCIM 的完整链路；再扩到一到两个业务部门，观察真实使用场景下的权限模型是否合理；然后全员开通但保留本地账号作为回退通道；最后关闭本地账号，强制走 SSO。
每一步之间留一到两周观察期。最容易在扩量后暴露的问题是权限组划分——试点阶段人少，谁能访问什么靠人工确认；扩到几百人后，权限组的设计缺陷才会显现。想了解企业部署的整体方案，可以看 企业解决方案或直接联系销售获取安全评审材料。