Skip to main content

Best practices on security

How to keep your environment secure and performant

Ossi Galkin avatar
Written by Ossi Galkin
Updated over a year ago

Security

It is important to consider security when designing integrations. Frends transfers 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.

Frends Credentials

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 better to attach Frends Control Panel to the customer's own Azure AD, so the customer has full control of who can log in to Frends Control Panel. Also this way it is possible to enable multifactor authentication.

Secret Values

Usernames and passwords are 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.

Other Considerations

If production data is used for testing it should be masked to protect personal identifiable information (PII) and commercially sensitive data.

Only encrypted transfer protocols (https, sftp, etc.) should be used.

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

SQL

When using SQL Tasks in Processes, values should always be written to the parameter fields of Tasks to avoid the possibility of SQL injections.

Logging and Archiving

In general, logging and archiving the production data should be avoided. 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.

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.

Did this answer your question?