Preferred Alternatives to IP Allowlisting on Hyperforce

These best practices are the supported means of securing connectivity for Hyperforce.

Bi-Directional connection protection

• Implement Mutual TLS (mTLS)
• Use Salesforce Private Connect

For connections from the customer network to Salesforce

• Allowlist Domains
• Use Service Name Indicators (SNI)
• Use an Authentication Provider (Optional)
• Use Connected Apps

Read further for detailed explanations of the benefits of each of these practices.

Bi-Directional Connection Protection

Implement Mutual TLS (mTLS)

Transport Layer Security (TLS) is an encryption-based connection protocol that establishes secure links from a client to a server. Mutual TLS (mTLS) goes a step further, and also establishes secure links from the server to the client. By validating the certificates of both entities before establishing a connection, mTLS provides enhanced security. Customers who implement mTLS can be absolutely sure that they are connecting to Salesforce, and vice versa.  mTLS can be used as an alternative to, or in combination with domain- and IP-based allowlisting. 

Resources

• Authentication Settings for External Systems
• Two-way SSL Authentication with Certificates
• Using Salesforce Client Certificate for Outbound Messages

Use Salesforce Private Connect

Customers who want to avoid using the public internet for communication between Salesforce and their Amazon Web Services (AWS) instance have the option to purchase Salesforce Private Connect. Salesforce Private Connect is a networking service that provides customers with a fully-managed, bi-directional, private connection between their Salesforce org and their AWS account. Customers can easily connect their Salesforce org to resources in their Virtual Private Clouds (VPCs) running on AWS by using Amazon’s PrivateLink, for more secure API integrations. All traffic is routed over a dedicated connection without any traffic or customer VPCs ever being exposed to the public internet.

Private Connect is more secure than IP allowlisting because it guarantees that only Salesforce is calling into the customer’s endpoint. A common analogy for understanding Private Connect is to consider a telephone vs. a walkie-talkie. Anyone can call a telephone, so preventing spam calls requires constant attention and adjustment to allowed and blocked callers. This strategy is similar to maintaining an IP allowlist. With a walkie-talkie, the 2 handsets have a dedicated connection, so there are no lists to manage. Private Connect is similar to using a walkie-talkie, where only a specific caller, identified by an unchanging AWS ID called an Amazon Resource Name (ARN), is allowed to connect.

Private Connect is available for Sales Cloud, Service Cloud, CRM Analytics, and Data Cloud.

Resources

• Sales and Service Clouds (Core) and CRM Analytics: Secure Cross-Cloud Integrations with Private Connect
• Data Cloud: Private Connect for Data Cloud

Connecting From the Customer Network to Salesforce

Allowlist Domains

Domain allowlisting isn’t supported for connections originating from Salesforce and going into the customer’s network. 

For connections from the customer's network into Salesforce, instead of allowlisting IPs, customers can allowlist Salesforce domain names such as *.force.com. Domain name allowlisting is generally easy to implement, and domain names rarely change.

Resources

• Allow the Required Domains
• Domain Name System Security

Use Service Name Indication (SNI)

Service Name Indication extends the Transport Layer Security (TLS) protocol by allowing a client or browser to specify the hostname to which it wants to connect. This is important because a server might present multiple certificates on the same IP address. A common analogy for understanding SNI is sending a package to someone who lives in an apartment building. TLS guarantees that the package is sent to the right address, and SNI guarantees that the package is sent to the right apartment at that address.

In Hyperforce, each Salesforce domain has a separate HTTPS certificate. In the absences of SNI, Hyperforce returns a default certificate that supports all *.my.salesforce.com and *.sandbox.my.salesforce.com domains, but to address any other domains, web browsers and API callers must specify the desired domain by including SNI in their ClientHello message. Even when addressing default domains, sending SNI is recommended. (Read more in Resolve HTTPS/SSL connection errors in Hyperforce with SNI.)

To establish secure connections from the customer’s network into Hyperforce, we recommend that customers investigate whether their network infrastructure supports SNI header inspection. By inspecting the SNI header, the customer can ensure that they direct traffic into their own Salesforce environment.

SNI provides the following benefits

• Accuracy: Guarantees that all traffic is routed to the correct destination
• Simplicity: Customers add an extension to a common protocol
• Scalability: Expands the number of connections a customer can make, especially if they use IPv4
• Security: Connections are based on TLS, which is more secure than IP allowlists.

Resources

• TLS 1.2 and SNI Enablement Overview
• Include the Server Name Indicator (SNI) Extension for Custom Domain Request
• Resolve HTTPS/SSL Connection Errors in Hyperforce with SNI
• Include SNI Extension for Custom Domains using Salesforce Cloud option with Salesforce Edge Network

Use an Authentication Provider (Optional)

For customers who want to use an authentication provider such as Github or Okta to access their Salesforce environment, Salesforce will manage the authentication app for them.

This option provides customers with choice and control over their authentication process, but is not a Salesforce requirement.

Resources

• Authentication Providers
• Use Salesforce-Managed Authentication Providers
• Configure a Salesforce Authentication Provider
• Set up SSO for your Internal Users

 Use Connected Apps

If you need to access Salesforce from external Applications, use Connected Apps. The connected app framework enables external applications to integrate with Salesforce using APIs and standard protocols, such as Security Assertion Markup Language (SAML), OAuth, and OpenID Connect. Connected apps use these protocols to authorize, authenticate, and provides single sign-on (SSO) for external apps. Connected apps can securely access data with API integration, integrate service providers with Salesforce, provide authorization for external API gateways, and manage access to 3rd party apps.
 

Resources

• Connected App Use Cases
• How to Create a Connected App
• OpenID Connect -- Dynamic Client Registration for External API Gateways

See Also

• Introducing Hyperforce -- General Information and FAQ
• Retain Uninterrupted Access to Salesforce on Hyperforce
• Salesforce IP Addresses and Domains to Allow