Salesforce 安全配置审计 Part-2：六道防线从 HTTPOnly 到 MFA

导语：Part-1 聊了密码策略、实时事件监控、登录 IP 范围、点击劫持防护四块。Part-2 把剩下六道防线收口——HTTPOnly Cookie、Release Updates、字段历史跟踪、角色层级、Transaction Security、MFA。这六件事在不少 Salesforce 后台都被默认忽略，加起来刚好填上 Part-1 留的 20% 盲区。

一、Part-1 回顾

Part-1 收尾时说过，剩下的 20% 涉及 Connected App、OAuth Scope、Profile 权限继承——这一类今天接着补。但 Part-2 的重心不在 OAuth 那条线上，Harsh 把话题切到了”配置层”的六道防线：偏底层、强相关、容易被忘。

这六条不是按优先级排，是按「打开 Setup 时第一眼能看到」顺序列。理解这个排序能省不少审计时间——拿到一个 Org，先按这六条顺序过一遍，再去碰 OAuth 那些细节。

二、六大检查项

2.1 HTTPOnly Cookie 属性

HTTPOnly 是给 Session Cookie 加的一道 XSS 防线：浏览器 JavaScript 读不到这个 Cookie，等于把会话 token 锁在浏览器的同源策略里。

攻击者最常见的绕法是把 XSS 落点放在同源页面——比如 Salesforce 自家的 Visualforce 页面。一旦 XSS 拿到 HTTPOnly 的 Cookie 都读不出来，session 不会被直接盗，但 token 仍可能从 Referer/抓包日志里漏出去，所以 HTTPOnly 不是万能的，必须配合 Content-Security-Policy 一起开。

判断方法：浏览器开发者工具看 Set-Cookie 响应头有没有 HttpOnly。没有的话，记一个中危，建议在 Setup → Session Settings 里勾上。

2.2 Release Updates

Salesforce 每季（约 3 月、6 月、9 月、12 月）发一批 Release Updates——这一批更新里有相当一部分是安全补丁。比如关闭老 API 版本、强制新密码规则、移除 deprecated 的端点。

默认行为是「自动激活」，但企业可以选「先测试后启用」。问题在于「测试」本身需要时间，不少企业一拖再拖，最终变成「永远测试中」——结果就是有安全补丁挂在那里没装。

审计这一项要看两件事：一是当前 Org 是不是所有 Critical / High 级别的 Release Updates 都已激活；二是测试中的那些有没有书面记录（Bug、变更单、负责人）。两个都没，那这条算高危。

2.3 Field History Tracking

Field History Tracking（字段历史跟踪）记录的是某条记录里关键字段的修改历史——谁改的、什么时候改的、改前值、改后值。这条线比 LoginEvent 更细：登录日志只告诉你「谁进来了」，字段历史告诉你「进来后动了什么」。

关键 Object（账户、联系人、商机、合同）和关键字段（金额、状态、所有者、密码字段）必须开跟踪。开之后至少保留 18-24 个月，攻击者改字段再擦记录也能在历史里查到。

审计时常用一个判断：进入任意一个 Object 的 Setup → Field History Tracking，看「Track field history changes」是不是勾上。如果根本没勾，那审计、合规、事后溯源三条线全断。

2.4 Role Hierarchy

Role Hierarchy（角色层级）决定的是数据访问的「纵向」——高层 Role 看见下属所有记录，低层 Role 看不见。设计原则很简单：层级越深越宽，能访问的记录越多。

攻击者的利用思路也很直接：拿到一个 Role 较高的账号（销售总监、区域经理）就能横向看整个下属组织的数据，包括销售记录、客户合同、联系方式。换句话说，账号本身价值由 Role 决定。

审计这一条要看的两个点：层级深度是否合理（业务上真需要 6 层以上吗？）、高 Role 账号数量是否过多。一家 200 人的销售团队有 10 个「VP 级别」账号基本可以判定 Role 滥用。

5.5 Transaction Security

Transaction Security 是 Salesforce 的实时策略引擎——你可以写规则，对登录、API 调用、数据导出等事件触发动作：阻断、加二次验证、发送告警。

类似传统 DLP（数据防泄漏），但触发点是 Salesforce 自家事件，不是文件操作。比如一条规则可以这样写：「同一账号在 5 分钟内导出超过 1000 条 Account 记录时阻断并通知 SOC」。

不少企业没开这条线，等于把 Logout 之前的所有异常行为都「先放行后审计」。开起来成本不高，但写规则需要业务方介入，所以常见结果是「配置了但没人维护」。

审计时点开 Setup → Transaction Security Policies，看是不是有 enabled 状态的政策。一个都没启用的话，记一个中危。

2.6 Multi-Factor Authentication

MFA（Multi-Factor Authentication，多因素认证）放在最后不是不重要，是因为这是六条里唯一一条没有 SaaS 默认值的——必须企业主动配置才能生效。

Salesforce 支持几种 MFA 实现：自带 Salesforce Authenticator（基于 TOTP，即基于时间的一次性密码）、第三方 IdP（Identity Provider，身份提供商，如 Okta、Azure AD）、硬件密钥（WebAuthn）。

攻击者绕 MFA 的常见思路是 Session Hijacking（会话劫持）——账号 MFA 过了之后劫持 Cookie。所以 MFA + Session IP 绑定 + 短 Session 超时必须组合，单开 MFA 不够。

审计这一条直接看 Profile 或 Permission Set 里的「Two-Factor Authentication for API Logins」和「Two-Factor Authentication for User Interface Logins」是不是都勾了。任何一项没勾，对应入口就可以用单因素登录，记一个高危。

三、红队审计清单（合并 Part-1 + Part-2）

Part-1 给了五步流程，Part-2 再补五步，覆盖全部十项检查：

1. 浏览器抓 Salesforce 登录请求，看 Set-Cookie 有没有 HttpOnly、Secure、SameSite 三个标志——缺一记中危
2. Setup → Release Updates 页面，统计未激活的 Critical 项数量——大于 5 记高危
3. 任意一个核心 Object 的 Field History Tracking 状态——未开记中危
4. Role Hierarchy 层级深度截图 + 高 Role 账号数量——超过业务合理范围记高危
5. Transaction Security Policies 启用数量——0 条记中危
6. 找一个 Service Account（服务账号），看 Profile 里 MFA 配置——未开记高危
7. Part-1 五步再跑一遍（IP 段、密码锁定、Clickjacking、RTEM、密保答案）

十步跑完，Salesforce 配置层的常见风险点 95% 都能覆盖。剩下 5% 涉及 Connected App、OAuth Scope、API 限流、Profile 共享规则，留到 Part-3 讲。

四、防御建议

• HTTPOnly + Secure + SameSite 三件套同时开，不要只开其中一个
• Release Updates 不要永远停在「测试」状态，每季度评审一次是否能升级
• 字段历史跟踪覆盖至少账户、联系人、商机、合同四个 Object，保留 24 个月
• Role Hierarchy 按业务最小化设计，不要为「方便管理」加宽层级
• Transaction Security 至少配 3 条规则：批量导出、异常登录、API 高频调用
• MFA 一定要覆盖「API Logins」和「User Interface Logins」两个入口，缺一不可

五、思考题

• 启用了 Release Updates 但内部测试环境跟不上，企业应该怎么处理？
• Role Hierarchy 设计的「最小够用」原则具体怎么落地？有没有可量化的指标？
• Transaction Security 规则和 SIEM（安全信息与事件管理）告警是重复的吗？怎么避免双轨维护？

下一讲（Part-3）会展开 Connected App、OAuth Scope、API 限流这三块的审计点，把 Salesforce 配置审计最后一个 5% 收口。

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