我們先想一個客戶是否提過以下類似的場景：
- 當前的公司對資料的隱私管理的相對嚴格，針對報表，儘管允許資料匯出，但是當指定的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雖然是付費的功能，但是好多涉及到使用者隱私/許可權進行一定的監控和增強。篇中有錯誤地方歡迎指出，有不懂歡迎留言。