我们先想一个客户是否提过以下类似的场景：
- 当前的公司对数据的隐私管理的相对严格，针对报表，尽管允许数据导出，但是当指定的profile进行导出的功能，不希望这个profile的user导出过多的数量，比如 sales rep在使用report的时候允许查看数据，但是使用导出功能时，导出account的数据禁止超过10条。
- 当前公司对浏览器要求很严格，必须要求指定浏览器指定版本才可以登录。
- 客户对于用户权限管理特别严格，使用permission set进行管理并且不允许任意的分配到指定的 permission set，需要基于指定的规则来弄，不满足规则的不允许放在这个permission set中。
这种需求是可能出现的，如果客户提出了这种要求，那么 salesforce是否能实现呢？ 答案是可以的，接下来就引出我们今天的内容， transaction security.
注意：如果想使用Transaction Security, 首先需要去购买 Salesforce Shield 或者 Salesforce Shield Event Monitoring 附加的license/subscription.
Transaction Security是一个拦截实时事件并应用适当操作来监视和控制用户活动的框架。每个Transaction Security Policy都有评估事件和满足这些条件后触发的实时操作的条件。这些操作包括block当前行为、MFA和通知。Transaction Security可以基于Condition Builder或者 Apex方式来配置。其中
- Condition Builder用于基于 no code点击配置的方式来实现基于条件的监控操作。
- Apex用于基于code方式来实现复杂场景的监控操作。
接下来基于三方面来讲 Transaction Security Policy: Type / Action & Notification / Content Builder & Apex方式配置。
一. Transaction Security Policy Type
我们可以在这些实时事件监视事件上创建我们的 Transaction Security Policy.
|
Event Type |
Type Short Description |
Conditions Available in Condition Builder |
Actions |
Considerations |
|
ApiEvent |
API events monitor API transactions, such as SOQL queries and data exports. |
API Type, API Version, Application, Client, Elapsed Time, Operation, Platform, Queried Entities, Query, Rows Processed, Session Level, Source IP, User Agent, User ID, Username |
Block, Notifications |
Multi-factor authentication isn’t supported. |
|
ApiAnomalyEventStore |
API anomaly event policies monitor anomalies in how users make API calls. |
User, Username, SourceIp, Score, QueriedEntities, Operation, RowsProcessed, UserAgent |
Notifications |
|
|
BulkApiResultEventStore |
Bulk API Result Event policies detect when a user downloads the results of a Bulk API request. |
Query, SessionLevel, SourceIp, UserId, Username |
Block, Notifications |
|
|
CredentialStuffingEventStore |
Credential stuffing event policies monitor when a user successfully logs into Salesforce during an identified credential stuffing attack. Credential stuffing refers to large-scale automated login requests using stolen user credentials. |
AcceptLanguage, LoginUrl, Score, SourceIp, UserAgent, UserId, Username |
Notifications |
|
|
ListViewEvent |
List View event policies monitor when data is viewed or downloaded from your list views using Salesforce Classic, Lightning Experience, or the API. |
Application Name, Developer Name, Event Source, List View ID, Name, Name of Columns, Number of Columns, Order By, Owner ID, Queried Entities, Rows Processed, Scope, Session Level, Source IP, User ID, Username |
Block, Notifications, Multi-Factor Authentication (for UI logins)
Multi-factor authentication is not supported for list views in Lightning pages, so the action is upgraded to Block. |
|
|
LoginEvent |
Login event policies track login activity and enforce your org’s login requirements. |
API Type, API Version, Application, Browser, Country, Login URL, Platform, Session Level, Source IP, TLS Protocol, User ID, User Type, Username |
Block, Notifications, Multi-Factor Authentication (for UI logins) |
|
|
PermissionSetEventStore |
Permission set event policies monitor when users are assigned critical permissions in a permission set. |
Event Source, Operation, Permission Type, User Count, User ID, Username |
Block, Notifications |
|
|
ReportAnomalyEventStore |
Report anomaly event policies monitor anomalies in how users run or export reports. |
Report, Score, SourceIp, UserId, Username |
Notifications |
|
|
ReportEvent |
Report event policies monitor when data is viewed or downloaded from your reports. |
Dashboard ID, Dashboard Name, Description, Event Source, Format, Is Scheduled, Name, Name of Columns, Number of Columns, Operation, Owner ID, Queried Entities, Report ID, Rows Processed, Scope, Session Level, Source IP, User ID, Username |
Block, Notifications, Multi-Factor Authentication (for UI logins) |
|
|
SessionHijackingEventStore |
Session hijacking event policies monitor when unauthorized users gain ownership of a Salesforce user’s session with a stolen session identifier. |
CurrentUserAgent, CurrentIp, CurrentPlatform, CurrentScreen, CurrentWindow, PreviousUserAgent, PreviousIp, PreviousPlatform, PreviousScreen, PreviousWindow, Score, SourceIp, UserId, Username |
Notifications |
|
我们项目中常用的可能会用到LoginEvent / ListViewEvent / ReportEvent。其他的使用到再自行查阅。
二. Action & Notification
当一个实时的事件触发了我们配置的 policy，我们可以进行什么样的行为呢？目前可以实现阻止当前用户的行为或者强制让用户MFA去授权继续操作。除此以外，可选项还包括 接收事件的应用内通知或电子邮件通知。
三. Content Builder & Apex方式配置
上述讲了 Transaction Security Type以及 Action，本块内容讲一下具体的实操方式。首先我们需要先启用这个功能
1. Content Builder: 基于可视化无代码点击配置方式来搞定。
2. Apex方式配置：当我们需要一些复杂逻辑时，Content Builder便无法实现，这个时候我们就需要使用 Apex方式来配置。
第三步和上面的Content Builder操作相同，区别是暂时先别启用。
系统会自动生成这个Condition类
针对这个类实现了 TxnSecurity.EventCondition这个接口，好处是 salesforce已经给了很多的 example，所以不需要从0开始造车，复制粘贴修改很快便可以实现。核心的方法就是 evaluate，当为true，则代表着满足了当前的 transaction policy，系统便会执行我们配置的action。下方的demo为，除管理员外，不允许用户导出超过10条的数据
global class BlockLargeDataExportEventCondition implements TxnSecurity.EventCondition { public boolean evaluate(SObject event) { switch on event{ when ReportEvent reportEvent { return evaluate(reportEvent); } when null { // Don't take policy action when event is null return false; } when else{ // Don't take policy action when event is not handled return false; } } } /** * Handle evaluating ReportEvent */ private boolean evaluate(ReportEvent reportEvent){ Profile profile = [SELECT Name FROM Profile WHERE Id IN (SELECT profileId FROM User WHERE Id = :reportEvent.UserId)]; // Take policy action only if the user profile is not 'System Administrator' and // RowsProcessed greater than 10. if (!profile.Name.equals('System Administrator') && reportEvent.RowsProcessed >= 10 && reportEvent.Operation== 'ReportExported') { return true; } return false; } }
执行效果： 管理员导出数据
使用非admin账号登录操作。
总结：Transaction Security虽然是付费的功能，但是好多涉及到用户隐私/权限进行一定的监控和增强。篇中有错误地方欢迎指出，有不懂欢迎留言。