Salesforce 安全配置审计四大盲区与红队检查清单

导语：Harsh Bothra 在 Learn365 第 25 天抛出一份 Salesforce 部署的安全审计清单——密码策略、实时事件监控、登录 IP 范围、点击劫持防护四大块。这四件事在不少企业的 Salesforce 后台都被默认略过，结果就是攻击者只要拿到一个能登录的账号就能横着走。这篇文章把这四块拆成原理 + 绕法 + 修复,顺便给一份红队审计的 checklist。

一、背景:为什么 Salesforce 配置总被忽视

Salesforce（赛富时）的控制台功能太多,管理员平时能点开的就有上千项,真正落地安全策略时往往只关心”能不能用”,不太关心”配置安不安全”。再加上很多企业把 Salesforce 接 SSO（单点登录）后,本地密码策略就形同虚设,谁也不会再回看 Profile 里的密码配置。

但接 SSO 不等于账号本身安全。攻击者拿到 Service Account（服务账号）凭据、Salesforce 原生账号、Connected App 客户端密钥之后,直接走 OAuth Token 也能登进来。配置审计的目标,就是把这些旁路堵死。

二、四大检查项

2.1 密码策略

密码策略这一块,核心是四件事:复杂度、密保答案模糊化、锁定时长、最大尝试次数。

复杂度不用多讲,强密码是基本盘。容易被忽视的是密保答案——很多企业直接把”你最喜欢的颜色”这种开放问题当密保,攻击者做一轮 OSINT（公开信息搜集）就能把答案猜出来。Salesforce 提供了「Obscure Secret Answer」开关,开启之后答案在数据库里以哈希形式存,前台也只能看到密文,等于把社会工程学攻击面砍掉一截。

锁定时长和最大尝试次数要配对看:次数设得低(比如 3 次)但锁定时长太长(比如 60 分钟),正常用户会被误伤;反过来次数高、时长短,等于给攻击者爆破留窗口。一般经验值是 5-10 次失败后锁定 15-30 分钟,具体看业务场景。

2.2 实时事件监控

Salesforce 的 Real-Time Event Monitoring(实时事件监控,缩写 RTEM)是企业侧能拿到的最细颗粒度的行为日志。常见事件类型包括:API 调用异常、Report/ListView 访问、登录登出、批量数据导出、权限变更等等。

RTEM 默认只保留 24 小时,要从 Salesforce Event Monitoring 单独购买。预算不充裕的企业,这一块基本是关的——但攻击者最喜欢的也是这种”日志没开”的环境,横向移动几天都没人察觉。

Harsh 在原文里点了一句”确保所有必要事件都开了”,实际落地时要按业务勾选:LoginEvent、ApiEvent、ReportEvent、ListViewEvent 这四类几乎是必开,缺一个都会被攻击者用上。

2.3 登录 IP 范围

给 Profile(角色)或 Organization(组织)配置 Login IP Ranges(登录 IP 段),等于给 Salesforce 后台再加一道网络层白名单。原理很简单:不在白名单段的源 IP 登录请求一律拒。

这一招对付账号被盗特别有效——攻击者在境外 VPN(虚拟专用网络)拿到凭据,即使密码正确,也会被 IP 段直接拒。配置上要注意两点:一是不能只配 IPv4,IPv6 段也要覆盖,不然只开 v4 的用户用 v6 出口会被误锁;二是不要在 IP 段里放”0.0.0.0-255.255.255.255″这种全开,等于没配。

2.4 点击劫持防护

Clickjacking(点击劫持)原理不复杂:攻击者把 Salesforce 的敏感页(比如审批页、配置页)iframe(内嵌)进自己的恶意页面,透明叠一层诱导按钮,用户看到的是”领取奖品”,实际点的是”批准权限变更”。

防护手段是给响应头加上 X-Frame-Options: SAMEORIGIN 或 Content-Security-Policy: frame-ancestors 'self'。Salesforce 在 Setup 里有个 Clickjacking Protection 开关,默认开启,但很多企业为了嵌入自家门户(比如把 Dashboard 嵌到内部 BI 平台)手动关掉,关掉之后就忘了开回来。

判断方式很简单:浏览器开发者工具看响应头有没有这两个字段之一。没有的话,这个环境就有被劫持的风险。

Salesforce 四大安全配置检查项：密码策略/实时事件监控/登录 IP 范围/点击劫持防护

三、红队审计清单

按攻击者视角,把上述四块串成一次审计流程:

拿一个低权限测试账号,从外部 IP 登录,看是否被 IP 段拦下——如果能登,直接记一个高危。
在控制台故意输错密码 10 次,看锁定时长是否符合预期——如果没锁定,密码策略失效。
用 Burp Suite(抓包工具)拦截一次登录请求,看响应头有没有 X-Frame-Options 或 CSP(内容安全策略)——没有的话记一个中危。
让甲方导出最近 30 天的 LoginEvent 日志,看是否覆盖了所有用户——如果只有管理员有日志,普通用户的事件没开,记一个高危。
找一个有密保问题的账号,看密保答案前台是否以明文显示——如果明文,Obscure Secret Answer 没开,记一个中危。

跑完五步基本能覆盖 80% 的 Salesforce 配置风险点。剩下的 20% 涉及 Connected App、OAuth Scope、Profile 权限继承,留到 Part-2 讲。

四、防御建议

密码策略 + 密保模糊化 + IP 白名单三件套永远要开,不要为了”用户体验”关掉
实时事件监控即使预算紧,也要把 LoginEvent 和 ApiEvent 单独开通,这是溯源的唯一抓手
Clickjacking 防护默认开启,任何”为了集成”关闭的操作要走变更审批
定期(每季度)跑一次配置审计,自动化工具可以选 Salesforce 的 Security Center 或者 Health Check

五、思考题

如果组织开了 SSO,本地密码策略是不是就完全没用了?
RTEM 默认只保留 24 小时,如果不购买,有没有开源方案能补上这块?
Clickjacking 防护被业务部门要求关掉,作为安全工程师你该怎么拒?

下一讲(Part-2)会展开 Connected App、OAuth Scope、Profile 权限继承这三块的审计点,继续填 Salesforce 安全配置的剩余 20% 盲区。

素材出处:Harsh Bothra,Learn365 Day 25 – Salesforce Security Misconfiguration (Part-1),https://github.com/harsh-bothra/learn365/blob/main/days/day25.md

文章版权归作者所有，未经允许请勿转载。

THE END