Hardening SalesForce Integration in Azure Logic Apps + Azure Secure Devops Kit Alignment of Logic Apps

What are logic apps? Azure Logic Apps could be described as a convenient way to “commoditize” input and output operations between multiple resources and API’s within Azure’s 1st party and third party ecosystem.

Where are Logic Apps used? As far as I’ve seen Logic apps are quite popular with architecture modernization projects where the architecture is leaning towards “pluggable/decoupled” microservice architecture. Logic Apps can consume and push data to 1st and 3rd party services, which sometimes completely obsoletes previous built in API consumer client from a monolithic app – Salesforce integration is good example of this.

But Isn’t app managed by Microsoft?

The fact that Logic App abstracts lot of the plumbing doesn’t mean it doesn’t have rich set of optional security features. We are exploring common ones for these.

But why harden Salesforce side, isn’t this Azure related security configuration

When you have integrations going across environments and clouds, you have to look at the big picture. Especially when the master data that you process is sometimes the data in SalesForce you need to ensure, that source of the data is also protected… Not just where the data is going to

There are similar recommendations on the AZSK kit, but this combines the IP restrictions + and reduces the amount of accounts that have access to the integration in SF side.

Logic App connectors must have minimum required permissions on data source This ensures that connectors can be used only towards intended actions in the Logic App

Medium

Checklist

Before proceeding

Expected result

Once you’ve configured the setup (setup guide below), and tested failure and success behavior the end result you should show failed and success events.

After adding the Logic App IP’s the result should be success.

---

Azure Side Configuration

• Enable Azure Monitoring of the API connection for Azure Control Plane Actions

• If you want to reduce the output for reader level roles of possibly confidential inputs/outputs in the Logic Apps, then enable Secure Inputs/Outputs setting for the Logic App
  • Read more here considerations and secure parameters

• If your using storage account as part of your logic app flow , ensure storage account logging is enabled

1.0;2020-02-20T07:33:25.0496414Z;PutBlob;Success;201;13;13;authenticated;logicapp;logicapp;blob;"https://logicapp.blob.core.windows.net:443/accounts/Apparel";"/logicapp/accounts/Apparel";

SalesForce Side

• Profiles in Users
  • Clone, or create new profile for Logic Apps integration.
    • I cloned the System administrator profile, but more granular setup is possibly available by configuring the least privilege permissions for the application
  • Under ‘Login IP ranges’ add the Azure Logic App IP ranges that can be found from properties (Include the user IP also which you will use for registering the API in the Logic App)

---

• The SF integration connection ‘API connection’ in Azure runs in the context of the user registering the API first time in logic apps
  • There is no point to allow non related users of creating OAuth2 tokens bearing the apps context

• Oauth Policies in App Manager
  • For ‘Permitted users’, change setting to ‘Admin approved users are pre-authorized’
  • For ‘IP Relaxation’ change setting to ‘Enforce IP restrictions’

• Profiles in App Manager
  • Add the profile created in previous step to profiles
    • This step restricts the users that can use the integration to a custom profile, or system administrators profile

• In Security ‘Session Management’ Ensure IP restrictions aren’t just enforced on login by selecting this setting
  • This setting applies based on the profile IP restriction settings, not globally unless all your profiles have IP login restrictions in place

• After this revoke all existing user tokens for the app under user settings and Oauth connected Apps

• Reauthorize the connection

• Now test the integration to work

Further AZSK recommendations

• This blog adds the non-Azure side recommendation to hardening guidelines.
• The following guidelines are where you should start, if you start hardening your Logic Apps
• if your logging data in Logic Apps (which is recommended to detect misuse and doing debugging: Understand which and what kind of data (PII) etc will be stored/persisted in the logs outside possibly standard access and retention policies.
  • If you want to separate part of the data create separate logic app with secure inputs/outputs, or implement secure inputs/outputs for the current application

Source https://github.com/azsk/DevOpsKit-docs/blob/master/02-Secure-Development/ControlCoverage/Feature/LogicApps.md

LogicApps

Description & Rationale	ControlSeverity	Automated	Fix Script
Multiple Logic Apps should not be deployed in the same resource group unless they trust each other API Connections contain critical information like credentials/secrets, etc., provided as part of configuration. Logic App can use all API Connections present in the same Resource Group. Thus, Resource Group should be considered as security boundary when threat modeling.	High	Yes	No
Logic App connectors must have minimum required permissions on data source This ensures that connectors can be used only towards intended actions in the Logic App	Medium	No	No
All users/identities must be granted minimum required permissions using Role Based Access Control (RBAC) Granting minimum access by leveraging RBAC feature ensures that users are granted just enough permissions to perform their tasks. This minimizes exposure of the resources in case of user/service account compromise.	Medium	Yes	No
If Logic App fires on an HTTP Request (e.g. Request or Webhook) then provide IP ranges for triggers to prevent unauthorized access Specifying the IP range ensures that the triggers can be invoked only from a restricted set of endpoints.	High	Yes	No
Must provide IP ranges for contents to prevent unauthorized access to inputs/outputs data of Logic App run history Using the firewall feature ensures that access to the data or the service is restricted to a specific set/group of clients. While this may not be feasible in all scenarios, when it can be used, it provides an extra layer of access control protection for critical assets.	High	Yes	No
Application secrets and credentials must not be in plain text in source code (code view) of a Logic App Keeping secrets such as DB connection strings, passwords, keys, etc. in clear text can lead to easy compromise at various avenues during an application’s lifecycle. Storing them in a key vault ensures that they are protected at rest.	High	Yes	No
Logic App access keys must be rotated periodically Periodic key/password rotation is a good security hygiene practice as, over time, it minimizes the likelihood of data loss/compromise which can arise from key theft/brute forcing/recovery attacks.	Medium	No	No
Diagnostics logs must be enabled with a retention period of at least 365 days. Logs should be retained for a long enough period so that activity trail can be recreated when investigations are required in the event of an incident or a compromise. A period of 1 year is typical for several compliance requirements as well.	Medium	Yes	No
Logic App Code View code should be backed up periodically Logic App code view contains application’s workflow logic and API connections detail which could be lost if there is no backup. No backup/disaster recovery feature is available out of the box in Logic Apps.	Medium	No	No

Source https://github.com/azsk/DevOpsKit-docs/blob/master/02-Secure-Development/ControlCoverage/Feature/APIConnection.md

APIConnection

Description & Rationale	ControlSeverity	Automated	Fix Script
Logic App connectors must use AAD-based authentication wherever possible Using the native enterprise directory for authentication ensures that there is a built-in high level of assurance in the user identity established for subsequent access control. All Enterprise subscriptions are automatically associated with their enterprise directory (xxx.onmicrosoft.com) and users in the native directory are trusted for authentication to enterprise subscriptions.	High	Yes	No
Data transit across connectors must use encrypted channel Use of HTTPS ensures server/service authentication and protects data in transit from network layer man-in-the-middle, eavesdropping, session-hijacking attacks.	High	Yes	No

Br Joosua!