Integration Security
Securing your integrations on Frends Platform.
It is important to consider security when designing integrations. Frends can transfer confidential data between systems, and all the necessary efforts should be taken to prevent the data from being accidentally deleted or modified, or deliberately misused or stolen. The following sections describe the best practices to use when designing and developing secure integrations.
Access to Frends Tenant
Due to the nature of the integration platform, Frends users may be able to gain access to external systems and sensitive data regarding integration processes. This is why the user list and the users' roles must be kept up to date and no user should have a role they do not need. For auditing purposes, it is important to have an up-to-date list of authorized users.
It is best to attach the authentication for Frends Control Panel to the customer's own Azure AD in order to have full control of who can log in to Frends Control Panel. Also this way it is possible to enable multifactor authentication.
Credentials and secret values
Usernames and passwords are recommended to be stored in Environment Variables. Passwords should always use the type secret in the variables. Every secret and password value should consist of at least twelve characters with at least one upper case letter, one lower case letter, one number, and one special character. There should be a different password for every Environment and every external system.
When creating a new Process, the developer creates the Environment Variables for the credentials, and Company’s integration owner or another person that has access to the credentials fills them in in Frends. Passwords or any other secret values should never be distributed with the related username or ID. Any secret value is not allowed to be sent in clear text or an unencrypted email.
Security considerations within Processes
If production data is to be used for testing it should be masked to protect personal identifiable information (PII) and commercially sensitive data.
Only encrypted transfer protocols such as HTTPS and SFTP should be used.
API Development
In API development it is recommended to use OAuth for authentication and API key for authorization. Other security considerations for APIs are:
IP address filtering
Rules for allowing and denying CRUD operations
Limiting transaction amounts
Blocking faulty headers
Input parameter validation
Using SQL
When using SQL in Processes, it is recommended to use parametrization and other SQL-related security practices to avoid SQL injections. SQL Tasks in Frends include built-in fields for entering parameter values to help with this.
Logging and Archiving
Frends enables easy and comprehensive logging features for the Processes for easy development and debugging of Processes, but for production use logging and archiving the handled data is recommended to be disabled.
The log level for the Production Environment should be set to "Only errors". APIs that handle sensitive data should be designed and implemented so that it is possible to log only the error and no other content of the message when an error occurs. Logging other data than errors should be carefully considered.
GDPR
General Data Protection Regulation (GDPR) requires companies to protect the personally identifiable information (PII) of their employees, customers, and third-party vendors. For example, the following can be considered as PII:
Full name
Home address/mailing address
Email address
Credit card numbers
Date of birth
Phone numbers
Login details
Precise locations
Account numbers
Security codes
IP addresses
User IDs
E-commerce order IDs
When logging or archiving PII, the following should be considered and documented:
What data is collected and why
Where the data is stored
Who has access to the data
What does the legislation say about storing the data
How long it is meaningful to store the data
When deleting the data, possible error situations should be taken into account
Is it possible to delete data according to certain criteria, e.g. name or email address?
The integration owner should maintain a list of users that have access to the integration logs and archives.
High Availability
Having two or more Agents allows them to share the load, and ensures that services are available even if some event, like operating system updates or a huge peak in load, renders one Frends Agent unavailable for a moment.
Usually, if Frends Agents are used to delivering integrations to some critical or "real-time", e.g. mobile, application it is advisable to use multiple Agents in production.
Last updated
Was this helpful?