Salesforce 登录时间（Login Hours）详解：配置、Apex 与最佳实践

背景与应用场景

在企业级应用中，安全性是永远无法绕开的核心话题。Salesforce 作为一个承载着企业核心客户数据和业务流程的平台，提供了多层次的安全模型来保护数据和访问。其中，Login Hours（登录时间）是一个强大而直观的访问控制工具，它允许系统管理员限制用户在特定时间段内登录系统。这个功能虽然基础，但在特定的业务场景下却至关重要。

作为一名 Salesforce 技术架构师，在设计安全和访问策略时，我们必须充分理解 Login Hours 的工作原理和适用范围。其主要应用场景包括：

合规性要求： 很多行业（如金融、医疗）都有严格的合规性规定，要求对系统访问进行严格的时间控制，防止在非工作时间进行未授权的数据访问或操作。例如，欧盟的 GDPR（通用数据保护条例）或美国的 SOX（萨班斯-奥克斯利法案）都强调了数据访问的最小化和可追溯性原则。
呼叫中心或轮班制工作： 对于按班次工作的员工，如客户服务代表或电话销售人员，企业通常希望他们只在自己的工作时间内访问 Salesforce。这不仅有助于规范管理，也能有效防止数据在非工作时间被泄露或滥用。
降低安全风险： 限制登录时间可以显著缩小攻击窗口。如果一个用户凭证意外泄露，攻击者也只能在允许的登录时间内尝试使用它，从而为安全团队发现和响应威胁争取了宝贵的时间。
防止非工作时间操作： 在某些业务中，不希望用户在深夜或周末执行关键操作（如批量数据更新、执行敏感报表），以避免因无人监督而可能引发的错误。通过限制登录时间，可以从源头上杜绝这类风险。

理解并正确运用 Login Hours，是构建一个健壮、合规的 Salesforce 安全架构的基础。它与 IP Ranges（IP 地址限制）、MFA（多因素认证）等共同构成了 Salesforce 的第一道防线。

原理说明

Salesforce 的 Login Hours 机制在概念上非常简单，但其背后的实现原理和细节值得深入探讨。

核心原理是：Login Hours 是直接在用户的 Profile（简档）级别进行配置的。 它不能在 Permission Set（权限集）中设置。这意味着，所有分配了同一个 Profile 的用户，都将遵循相同的登录时间限制。管理员可以为每个 Profile 设置一周七天中每天允许登录的开始和结束时间。

登录验证流程

当一个用户尝试登录 Salesforce 时（无论是通过 UI 还是 API），平台会执行一系列的验证检查。Login Hours 的检查是其中的一个关键步骤：

用户提交用户名和密码。
Salesforce 验证凭证的正确性。
平台检查与该用户 Profile 关联的 Login Hours 设置。
平台获取当前的系统时间（基于 Salesforce 组织设置的默认时区）。
比较当前时间是否在 Profile 定义的允许登录时间段内。
如果时间在允许范围内，则继续后续的验证（如 IP 地址限制、MFA 等）。如果不在允许范围内，则登录请求被拒绝，并向用户显示一条错误消息。

关键机制与行为

时区（Time Zone）： 这是一个非常关键且容易被误解的点。Login Hours 的计算完全基于在公司信息（Company Information）中设置的组织默认时区（Organization's Default Time Zone），而不是用户个人设置中的时区。例如，如果组织时区是“GMT-08:00 太平洋标准时间”，那么所有基于 Login Hours 的限制都会以这个时区的时间为准，无论用户实际身处何地。
活动会话（Active Sessions）： Login Hours 不会中断已经处于活动状态的用户会话。如果一个用户在允许的时间段内登录，并且在时间段结束后仍然在系统中操作，他/她可以继续工作，直到会话超时或主动登出。但是，一旦会话结束（例如，关闭浏览器、会话超时后刷新页面），该用户将无法在该时间点创建新的会G话，也就是无法再次登录。
API 访问： Login Hours 的限制同样适用于 API 调用。如果一个集成程序或外部应用使用某个用户的凭证在受限时间段内尝试调用 Salesforce API，该登录请求（Login aPI call）将会失败，并返回 `LOGIN_DURING_RESTRICTED_HOURS` 错误。因此，在为集成用户设计 Profile 时，必须仔细考虑其 Login Hours，通常会设置为 24/7 可用。

总而言之，Login Hours 是一个在用户尝试建立新会话时生效的“准入”控制机制，而不是一个“驱逐”机制。它通过 Profile 与用户绑定，并以组织时区为基准进行判断。

示例代码

Login Hours 的配置本身是声明式的（Declarative），通过点击界面完成，不涉及代码。然而，作为技术架构师或开发者，我们经常需要通过代码来审计和监控与登录行为相关的数据。虽然我们无法通过 Apex 直接查询一个 Profile 的具体 Login Hours 设置（这些元数据未直接暴露给 SOQL），但我们可以查询用户的登录历史，并与已知的策略进行比对分析。

以下是一些有用的 SOQL 查询示例，这些代码严格来源于 Salesforce 官方文档。

查询特定用户的登录历史

我们可以通过查询 LoginHistory 对象来获取用户的登录记录。这个对象记录了过去六个月的所有登录尝试，包括成功和失败的记录。这对于审计用户是否在非工作时间尝试登录非常有用。

// 查询特定用户最近 20 次的登录记录
// 可以通过 Status 字段判断登录是否成功，通过 LoginTime 判断登录时间
// 结合用户的 Profile，可以分析是否存在违反 Login Hours 策略的尝试

String userId = '005xxxxxxxxxxxxxxx';
List<LoginHistory> loginHistories = [
    SELECT Id, UserId, LoginTime, LoginType, Status, SourceIp, TlsProtocol, TlsCipherSuite, Browser, Platform
    FROM LoginHistory
    WHERE UserId = :userId
    ORDER BY LoginTime DESC
    LIMIT 20
];

for (LoginHistory lh : loginHistories) {
    System.debug('User ' + lh.UserId + ' tried to log in at ' + lh.LoginTime + ' with status: ' + lh.Status);
}

注释：

LoginHistory: 这是一个标准的 Salesforce 对象，存储登录尝试的详细信息。
UserId: 尝试登录的用户的 ID。
LoginTime: 登录尝试发生的时间戳（UTC 时间）。
Status: 登录结果，例如 'Success'（成功）、'Invalid Password'（密码无效）、'Failed: Computer activation required'（需要设备激活）或 'Login-hours'（因登录时间限制而失败）。通过筛选 `Status = 'Login-hours'` 可以直接找到因 Login Hours 策略而被阻止的尝试。
LoginType: 登录方式，例如 'Application'（通过网页浏览器）、'API'（通过 API）等。

查询组织中所有因登录时间限制而失败的尝试

为了进行全局的安全审计，我们可以查询整个组织内所有因为 Login Hours 限制而登录失败的记录。

// 查询过去 30 天内所有因 Login Hours 限制而登录失败的记录
// 这有助于识别哪些用户或 Profile 的 Login Hours 设置可能过于严格，或者是否存在持续的违规尝试

List<LoginHistory> failedLogins = [
    SELECT UserId, LoginTime, SourceIp, Status
    FROM LoginHistory
    WHERE Status = 'Login-hours' AND LoginTime = LAST_N_DAYS:30
    ORDER BY LoginTime DESC
];

if (failedLogins.isEmpty()) {
    System.debug('No login failures due to login hours in the last 30 days.');
} else {
    for (LoginHistory fl : failedLogins) {
        System.debug('User Id: ' + fl.UserId + ' failed to log in from IP: ' + fl.SourceIp + ' at: ' + fl.LoginTime);
    }
}

注释：

Status = 'Login-hours': 这是筛选此特定失败原因的关键条件。请注意，这个 `Status` 字段的实际值可能因 Salesforce 版本和语言设置略有不同，但其含义是明确的。在API中，这个状态通常代表因登录时间限制而失败。
LAST_N_DAYS:30: 这是一个 SOQL 日期字面量，用于方便地查询特定时间范围内的数据，避免了手动计算日期的麻烦。

需要强调的是，我们无法通过 SOQL 直接查询 `Profile` 对象来获取类似 `MondayStartHour` 这样的字段。这些配置属于元数据范畴，需要通过 Metadata API 来读取或修改。对于日常的监控和审计，查询 `LoginHistory` 是最直接和有效的方法。

注意事项

在实施 Login Hours 策略时，必须考虑以下几点，以避免对业务造成意外影响。

权限要求： 配置 Login Hours 需要 "Manage Users" 和 "Customize Application" 的权限。通常只有系统管理员才拥有这些权限。
API 与集成： 如前所述，API 登录同样受 Login Hours 限制。为集成用户（Integration User）分配一个具有受限 Login Hours 的 Profile 是一种常见的错误，这可能导致数据同步在夜间或周末中断。最佳实践是为集成用户创建一个专用的 Profile，并确保其 Login Hours 设置为 24/7，同时通过 IP Ranges 来限制其访问源，实现安全双保险。
时区问题： 再次强调，Login Hours 基于组织默认时区。对于一个拥有全球分布用户的跨国公司，这一点尤其重要。你可能需要创建多个 Profile，每个 Profile 对应不同时区的工作时间（例如 "Support Profile - EMEA", "Support Profile - APAC"），尽管这会增加管理的复杂性。在设计时必须与业务部门充分沟通，明确时间基准。
不中断活动会话： 要向用户和业务部门明确，Login Hours 不会强制踢出已登录的用户。如果业务要求在特定时间点必须终止所有会话，那么需要寻求其他解决方案，例如开发一个定时执行的 Apex 任务来查询并终止活动会话（这是一种高级且有风险的操作，需要谨慎实施）。
管理员访问： 避免为系统管理员 Profile 设置过于严格的 Login Hours。在系统出现紧急故障时（例如在午夜），如果管理员因为 Login Hours 限制而无法登录，后果将是灾难性的。通常，系统管理员的 Profile 应该拥有 24/7 的访问权限。
错误消息： 当用户因 Login Hours 限制无法登录时，他们会看到一个标准的错误消息。建议在公司的 IT 支持文档中对这个错误消息进行说明，以便用户能够理解原因并知道在紧急情况下该联系谁。

总结与最佳实践

作为技术架构师，我们在设计和实施 Login Hours 策略时，应遵循以下最佳实践：

分层安全策略（Defense in Depth）： 不要孤立地使用 Login Hours。应将其与 IP Ranges、多因素认证（MFA）、更精细的对象和字段级安全（Object and Field-Level Security）以及事务安全策略（Transaction Security Policies）结合使用，构建一个纵深防御体系。
明确角色职责： Login Hours 的应用应该基于清晰定义的业务角色和其工作模式。最适合的场景是那些工作时间固定的岗位，如呼叫中心坐席。对于角色职责模糊或工作时间灵活的用户，强制的 Login Hours 可能会影响效率。
专用集成 Profile： 始终为 API 集成创建专用的用户和 Profile。这个 Profile 应该拥有最小权限原则（Principle of Least Privilege），并且 Login Hours 设置为 24/7 可用，但必须通过 IP Ranges 严格限制其来源 IP 地址。
定期审计： 利用 `LoginHistory` 对象定期生成报告，审计登录成功和失败的记录。这不仅可以验证 Login Hours 策略的有效性，还能帮助发现异常的登录模式，例如在非工作时间出现大量失败的登录尝试，这可能是凭证攻击的信号。
清晰的沟通： 在实施或更改 Login Hours 策略之前，务必与所有受影响的用户和业务部门进行清晰的沟通。解释策略的原因、具体的时间限制以及在紧急情况下如何获得临时访问权限的流程。

总而言之，Login Hours 是 Salesforce 平台提供的一个基础安全特性。虽然它不能解决所有的访问控制问题，但在正确的场景下，它是一个实现合规性和降低安全风险的低成本、高效率的工具。一个优秀的 Salesforce 架构师应当熟练掌握其原理、限制和最佳实践，并将其融入到整体的安全设计蓝图中。

Salesforce中文网