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?