salesforce零基礎學習（一百二十三）Transaction Security 淺入淺出

我們先想一個客戶是否提過以下類似的場景：

當前的公司對數據的隱私管理的相對嚴格，針對報表，儘管允許數據導出，但是當指定的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;

    }

}