Apex Transaction Security Implementation Examples

This example implements a policy that is triggered when someone logs in from different IP addresses in the past 24 hours.

This example implements a policy that is triggered when a session is created from a specific IP address.

This example implements a policy that triggers when more than 1,000 leads are exported, for example, by the Data Loader. EntityName is a field in the event e that contains the name of the entity, such as Account or Contact.

This policy is triggered when someone accesses a report.

This example uses the IP address in a login policy. The policy is triggered when there’s a login from localhost.

From the Transaction Security Policies page, create a policy to block localhost logins. Here is the generated Apex policy:

This policy triggers when 2,000 records or more are downloaded via the API.

An admin or other customer with API privileges can download all customer data in bulk using SOAP API, REST API, or Bulk API. This security policy restricts API-based data downloads to 2,000 records and alerts the admin with a real-time notification if the policy is triggered.

This policy requires everyone to use two-factor authentication before accessing a specific report.

You can have sensitive, confidential data in your quarterly Salesforce reports. You also want to ensure that teams accessing those reports use two-factor authentication (2FA) for high assurance before viewing this data. The policy makes 2FA a requirement, but you can’t provide high-assurance sessions until your teams have a way to meet the 2FA requirements. As a prerequisite, first set up 2FA in your Salesforce environment.

This example highlights the capability of a policy to enforce 2FA for a specific report. The report defined here is any report with “Quarterly Report” in its name. Anyone accessing the report is required to have a high-assurance session using 2FA.

This policy triggers when a user with a known operating system and browser combination tries to log in with another browser on a different operating system.

Many organizations have standard hardware and support specific versions of different browsers. You can use this standard to reduce the security risk for high impact individuals by acting when logins take place from unusual devices. For example, your CEO typically logs in from San Francisco using a MacBook or Salesforce mobile application on an iPhone to Salesforce. When a login occurs from elsewhere using a Chromebook, it’s highly suspicious. Because hackers do not necessarily know which platforms corporate executives use, this policy makes a security breach less likely.

In this example, the customer organization knows that their CEO is using a MacBook running OS X with the Safari browser. Any attempt to log in using the CEO’s credentials with anything else is automatically blocked.

This policy blocks access by country.

Your organization could have remote offices and a global presence but, due to international law, wants to restrict access to its Salesforce org.

This example builds a policy that blocks users logging in from North Korea. If users are in North Korea but using a corporate VPN, their VPN gateway would be in Singapore or the United States. The VPN gateway would make their login successful because Salesforce would see the internal U.S.-based company IP address.

You can also restrict access to other values, like postal code or city.

This policy blocks access for anyone using an older version of the Android OS.

You’re concerned with a specific mobile platform’s vulnerabilities and its ability to capture screen shots and read data while accessing Salesforce. If the device is not running a security client, you could restrict access from device platforms using operating systems with known and well-identified vulnerabilities. This policy blocks devices using Android 5.0 or earlier.

This policy blocks a specified word by searching posted Chatter text.

You can scan or filter for specific words in posts. This example looks for a post containing the word “Salesforce” and blocks those posts. You can also write conditions that loop through a list of words or keep a running total of the occurrence of the words.

This policy blocks a connected app with API access from accessing large amounts data.

Sometimes connected apps have API privileges to access data org-wide due to sharing or account access settings definitions. However, the end user of the connected app is restricted to only a specific dataset. This conflict can result in an increased security risk by identifying the API key and performing command-line searches directly in the database to look for leads. The following policy avoids this situation and data loss around your company’s lead information.