优化 Salesforce 安全性：深入解析登录时间设置

十月 02, 2025

背景与应用场景

大家好，我是一名 Salesforce 管理员。在我的日常工作中，确保我们 Salesforce 组织 (Org) 的安全性和合规性是首要任务之一。用户访问控制是安全策略的基石，而其中一个经常被忽视但却极其强大的工具就是 Login Hours (登录时间)。这个功能允许我们精确控制用户可以在什么时间段内访问 Salesforce，从而为我们的数据增加了一道重要的时间维度上的安全屏障。

那么，在哪些实际场景中，Login Hours 会发挥巨大作用呢？

场景一：标准化工作时间的呼叫中心

想象一个呼叫中心，其座席人员的工作时间是周一到周五，上午 9 点到下午 6 点。公司不希望座席在非工作时间访问客户的敏感数据，这既是为了数据安全，也是为了遵守劳动法规，防止员工在规定时间外工作。通过为座席人员的 Profile (简档) 设置 Login Hours，我们可以确保他们只能在排定的工作时间内登录系统。任何在晚上或周末的登录尝试都将被拒绝。

场景二：强化高风险岗位的访问控制

对于财务、法务或人力资源等部门的员工，他们接触的数据通常是公司最核心的机密。为了最大限度地降低数据泄露的风险，特别是来自内部的恶意或意外操作，我们可以限制这些用户只能在标准的办公时间内访问系统。这可以有效防止有人在深夜或假期等监控较弱的时段登录系统，进行未授权的数据导出或修改。

场景三：系统维护与数据迁移窗口

作为管理员，我们经常需要在深夜或周末进行系统维护、版本发布或大规模数据迁移。在这些操作期间，我们不希望有业务用户登录系统，因为他们的操作可能会与我们的维护任务产生冲突，甚至导致数据不一致。通过临时为所有非管理员用户设置严格的 Login Hours，我们可以有效地“冻结”用户访问，为维护工作创造一个安全、无干扰的环境。

场景四：满足行业合规性要求

在金融（如 SOX）或医疗（如 HIPAA）等受到严格监管的行业中，合规性审计要求对数据访问有严格的记录和控制。Login Hours 作为一种可审计的访问控制措施，可以向审计员证明公司已经采取了技术手段，将对敏感数据的访问限制在受监控的业务时间内，从而满足特定的合规性条款。

通过这些场景，我们可以看到 Login Hours 不仅仅是一个简单的“开关”，而是一个灵活且强大的安全治理工具，能够帮助我们管理员根据业务需求和安全策略，精细化地管理用户访问权限。

原理说明

要理解 Login Hours 的工作原理，我们必须抓住其核心——它是在 Profile (简档) 级别进行配置的。在 Salesforce 的安全模型中，Profile 定义了一组用户的基本权限和设置，包括他们可以访问的对象、字段、应用程序，以及我们今天讨论的登录时间。

配置 Login Hours 的过程非常直观：

进入 Setup (设置)。
在“快速查找”框中，输入“Profiles”并选择 Profiles (简档)。
选择你想要限制登录时间的特定简档，例如“客户服务代表”。
在简档的详细信息页面，向下滚动找到 Login Hours (登录时间) 这个设置项，点击旁边的 Edit (编辑)。
你会看到一个以星期日到星期六为行，以小时为列的网格视图。在这里，你可以为每一天指定一个允许登录的开始时间和结束时间。例如，你可以设置周一到周五为“上午 9:00”到“下午 6:00”。对于不想允许登录的日期（如周六、周日），只需将开始和结束时间设置为相同即可，系统会自动将其识别为“不允许登录”。
设置完成后，点击 Save (保存)。

一旦设置完成，该简档下的所有用户都会受到此规则的约束。当用户尝试在允许的时间范围之外登录时，他们会看到一条错误消息，提示他们的登录尝试被拒绝。

关键机制：活跃会话的处理

一个非常关键且容易混淆的知识点是：当用户的 Login Hours 结束时，对于已经登录在系统中的用户会发生什么？

Salesforce 的默认行为是：用户的当前会话 (Session) 不会被强制终止。这意味着，一个在下午 5:59 登录的用户，即使他的登录时间在下午 6:00 结束，他仍然可以继续使用系统，完成他正在进行的操作。但是，一旦他登出或会话超时，他就无法在允许的时间段之外重新发起一个新的会话了。

然而，Salesforce 提供了一个更严格的选项来改变这个默认行为。在 Setup (设置) -> Session Settings (会话设置) 中，有一个名为 "Enforce login hours on every request" (在每次请求时强制执行登录时间) 的复选框。如果勾选了这个选项，那么当用户的登录时间结束后，系统会在用户的下一次操作（例如点击一个链接、保存一条记录）时检查登录时间，并立即终止其会话，将其强制登出。这是一个非常严格的控制，在启用前需要仔细评估对用户体验的影响。

示例代码

作为管理员，虽然 Login Hours 的配置是纯声明式的（point-and-click），但我们经常需要通过数据查询来进行审计和监控。例如，我们可能想知道最近一个月内，有多少次登录失败是由于 Login Hours 限制导致的。这时，我们就需要用到 SOQL (Salesforce Object Query Language, Salesforce 对象查询语言) 来查询 LoginHistory (登录历史) 对象。

LoginHistory 对象记录了组织内所有的用户登录尝试，包括成功和失败的记录。其中，`Status` 字段会明确标识出失败的原因。

以下是一个查询过去 30 天内所有因“登录时间限制”而失败的登录尝试的 SOQL 示例，我们可以在 Developer Console 的 Query Editor 中运行它。

-- This SOQL query retrieves records from the LoginHistory object.
-- LoginHistory stores information about all user login attempts into the organization.
SELECT
    LoginTime,  -- The date and time of the login attempt.
    UserId,     -- The ID of the user who attempted to log in.
    SourceIp,   -- The source IP address from which the login attempt was made.
    Status,     -- The status of the login attempt. We are filtering on this field.
    LoginType   -- The type of login, e.g., 'Application', 'API', 'Remote'.
FROM
    LoginHistory
WHERE
    -- We filter for records where the 'Status' field is 'Login-hours'.
    -- This specific value indicates that the login failed because it was outside
    -- the user's configured profile login hours.
    Status = 'Login-hours'
    AND
    -- We use a date literal to filter for login attempts that occurred
    -- within the last 30 days, making the query relevant for recent activity analysis.
    LoginTime = LAST_N_DAYS:30
ORDER BY
    -- Sorting the results by LoginTime in descending order to see the most recent attempts first.
    LoginTime DESC

通过运行这个查询，我们可以清晰地看到哪些用户在什么时间、从哪个 IP 地址尝试在非规定时间内登录。这些信息对于安全审计、识别潜在的违规行为或仅仅是了解员工的工作习惯都非常有价值。

注意事项

在实施 Login Hours 策略时，作为管理员，我们需要特别注意以下几点，以避免意外情况的发生。

1. 时区（Time Zone）

这是一个最常见的陷阱。Login Hours 的设置是基于组织的默认时区，而不是用户的个人时区。组织的默认时区在 Company Information (公司信息) 页面设置。如果你的公司是一个跨国企业，有分布在不同时区的员工，这一点尤为重要。例如，你将组织时区设为“太平洋标准时间 (PST)”，并为某个简档设置了 9am-5pm 的登录时间。那么，对于一个在纽约（东部标准时间，EST）的员工来说，他的实际登录时间将是 12pm-8pm EST。在为全球团队设置 Login Hours 时，必须进行时区换算，或者为不同时区的团队创建不同的简档。

2. 简档与权限集（Profile vs. Permission Set）

Login Hours 是一个严格绑定在 Profile (简档) 上的功能，它不能通过 Permission Set (权限集) 来进行扩展或覆盖。这意味着，如果一组用户需要不同的登录时间，他们就必须被分配到不同的简档。这在设计用户权限模型时需要提前规划好。

3. API 与集成用户（API and Integration Users）

Login Hours 的限制同样适用于通过 API 进行的登录。如果你的外部系统（如 ERP、营销自动化平台）或数据加载工具（如 Data Loader）使用的集成用户所属的简档设置了 Login Hours，那么这些系统在允许时间之外将无法连接到 Salesforce，导致集成任务失败。因此，最佳实践是为所有集成创建一个专用的简档，并确保其 Login Hours 为 24/7 全天候可用。

4. 系统管理员简档（System Administrator Profile）

强烈建议不要为主要的系统管理员简档设置任何 Login Hours 限制。想象一下，如果在周末系统发生紧急故障，而你因为登录时间限制而被锁在系统之外，那将是灾难性的。为了安全起见，至少要保留一个不受限制的管理员账户，以备不时之需。

5. 会话终止选项的影响

再次强调，在启用“Enforce login hours on every request”选项前请三思。虽然它提供了更强的安全性，但也可能极大地影响用户体验。一个正在填写复杂表单或处理紧急案例的用户被突然强制登出，可能会导致数据丢失和极大的挫败感。在启用此功能前，务必与业务部门充分沟通，并确保用户了解这一行为。

总结与最佳实践

总而言之，Login Hours 是 Salesforce 管理员工具箱中一个不可或缺的安全控制工具。它通过在时间维度上限制访问，为“最小权限原则” (Principle of Least Privilege) 的实施提供了有力支持，有效降低了数据在非工作时间面临的风险。

作为管理员，以下是一些实施 Login Hours 的最佳实践：

主动规划，而非被动响应：在创建新用户或新简档时，就应该主动考虑是否需要设置 Login Hours，而不是等到出现安全事件后才来补救。
清晰沟通：在为用户应用 Login Hours 限制之前，务必通过邮件、内部通知等方式告知他们具体的登录时间范围，避免造成不必要的困惑和支持请求。
专人专用，专档专用：为集成和自动化流程创建专用的用户和简档，并确保它们拥有 24/7 的访问权限，以保障业务流程的连续性。
定期审计与审查：定期（例如每季度）审查所有简档的 Login Hours 设置，确保它们仍然符合当前业务需求和安全策略。同时，结合 LoginHistory 报告，监控异常登录行为。
考虑全局业务：在为跨时区的团队设置 Login Hours 时，务必进行精确的规划和时区计算，可能需要创建多个“角色相同，时区不同”的简档来满足需求。

通过深思熟虑地规划和实施 Login Hours 策略，我们可以显著提升 Salesforce 组织的安全态势，保护公司最宝贵的数据资产，同时确保业务流程的平稳运行。

Salesforce中文网