Skip to main content

Building securely

Log retention​

info

By package:

  • Pro: 7 days
  • Team: 7 days (30 as optional add-on)
  • Enterprise: 30 days

The retention of your workflow execution data, viewable in the Debug Log, can be reduced from 30 days down to 24hrs or be disabled entirely. We call the latter ghost processing.

With ghost processing, no log data is generated for viewing within the workflow. The workflow data is however stored in our internal systems for 24hrs. This is for availability reasons in the event that an aspect of the platform has a problem, it can be automatically retried.

It's important to note that changing the log retention will apply to all workflows in the Organization.

Reducing the retention of workflow logs or disabling it entirely can make troubleshooting workflows difficult. You can still take advantage of:

  • Error reporting: By forwarding error reports to a separate workflow so they can be surfaced elsewhere (eg: slack/internal support ticket).
  • Log streaming: Available regardless of your log retention period. This allows you to stream your workflow execution data to your own systems or SIEM so you can set your own retention period.

Available Tray regions​

  • US (AWS-West) - Default

  • EU (AWS-Ireland)

  • APAC (AWS-Sydney)

Data encryption​

Encrypting data​

Tray's Crypto Helpers can be used to encrypt/decrypt data within your workflows using the available algorithms (CIV, Hmac, Hash etc.)

Encrypting files​

Tray's Encryption Helpers uses PGP encryption to both:

  • Encrypt files to be sent to a particular destination
  • Receive and decrypt files

A typical setup would be to import an encrypted file with our FTP Client and then decrypt it with the Encryption Helpers 'PGP Decrypt file' operation.

Verifying data​

Tray's JWT Helper can be used to sign / verify data with JSON Web Tokens.

Securing webhook urls​

Each webhook generated by Tray has a public url in a format which includes a UUID:

https://c5272511-xxxx-xxxx-xxxx-90ff4062627b.trayapp.io

Whilst these are almost impossible to guess or brute force, we strongly recommend further securing your webhooks.

As detailed in our Webhook Trigger documentation Tray allows for CSRF tokens to be used with webhook triggers to ensure only certain requests are allowed.

Calls to the webhook without an x-csrf-token header and correct value are rejected.

As an additional security measure for Embedded customers, you can generate a different CSRF token per End User / Solution Instance. This can be achieved by using env variables / config variables

Authentications​

As per Tray's security policies we implement data encryption at rest and additional encryption for extra sensitive data like workflow authentications (API keys, access tokens etc).

We also redact workflow authentications from workflow input logs.

You must never hardcode any auth information in the Tray builder - the $.auth environment path can be used if e.g. an API token is needed to be passed as a header in an HTTP Client step.

Tray API tokens​

It is important not to expose your Tray API tokens anywhere in your app.

Shared responsibilities​

Please take particular note of the Shared Responsiblities detailed in our Security Statement