Tines security best practices

This document provides a list of features and best practices to consider for securing your Tines tenant.

Best Practices 

Accessing your Tines tenant 

  • Enable Single Sign-on (SSO)

    • Reminder: SSO only enables users to sign in, not sign up. Users must be invited to the tenant to gain access or just-in-time provisioning must be enabled.

    • Consider utilizing just-in-time (JIT) user provisioning* or our API to manage users

  • Enforce multi-factor authentication (MFA) at your identity provider (IdP)

  • Configure session timeouts

    • Users are automatically logged out of their Tines user interface (UI) session after a period of inactivity. By default, this is set to 1 day.

User access control 

Tines offers certain options to keep story building collaborative, while minimizing risk.

  • Limit the number of Tenant Owners

    • There are two users types in Tines, Tenant Owner and User. Tenant Owner corresponds to tenant admin, and should be reserved for those individuals responsible for managing the Tines tenant. All other users should be assigned corresponding User roles. Please see team roles for more information on the various permission levels possible within a team.

    • Ensure you follow your company policy to ensure there is a process if the Tenant Owner departs your organization. Please work with our support team if you have any questions or need assistance with Tenant Owner role assignment.

  • Use teams and roles to restrict access to credentials, stories, & resources

    • Note: Any credential, story, or resource shared with all teams will be available for all users, regardless of role

  • Use custom roles*/role-based access to enforce least privilege.

Credentials and secret management 

  • Enable credential domain restrictions

    • Enforcing domain restrictions for credentials is an important step to maintaining the security of your API keys and data. This helps ensure the credential is only used for the domains you specify or within a function that does not expose the credential value.

    • If you’re already using a vault service, consider integrating it with Tines, e.g.: HashiCorp.

Story building hygiene and functionality 

  • Limit data retention

    • Consider setting a lower event and action log retention period for sensitive stories, if not overall. The default event retention is 7 days on Tines paid plans, with options to go down as low as 1 hour.

    • Within Tines, you can utilize records* to access specific parts of event data longer term if desired. Note: These are stored for 2 years, so you may wish to consider incorporating a regular process to delete these depending upon your company’s data management policy.

  • Review your audit logs regularly and create detections based on your tenant log activity

  • Enforce use of Tines credentials for any password / key / sensitive information. This prevents access in clear text.

  • Utilize action monitoring for sensitive stories/actions

  • Utilize change control* when working with sensitive production stories. This provides greater visibility into story changes.

  • Allowlist Tines egress IPs where necessary

  • Consider adding authentication to Tines webhooks via HTTP header or signature

Tines API keys 

  • Use the appropriate API key when possible.

    • Tenant API keys give API access to the entire tenant and are linked to a separate service account user.

    • Team API keys give API access to one specific team and are linked to a separate service account user. They can be created for team-specific-role-based access, where role-based access control* is enabled.

    • Personal API keys inherit the permissions of their corresponding user.

  • Rotate your Tines API keys according to your company policy

Pages 

  • Review all public pages to ensure they should be public

  • Review access control for sensitive pages

  • Provision access to the Tines app in your IdP

    • This will allow members of your company/organization to access Tines pages which are behind SSO. Remember, they will not have access to your Tines tenant unless they are invited as users.

Self Hosted / Tunnel / Command Over HTTP Considerations 

Patch Management 

  • Ensure you’re not only pulling in Tines updates for the latest product features, but for security patches as well. Subscribe to the RSS Feed for notifications on Tines updates.

  • Ensure the internal systems used to host Tines are patched.

    • For managed container services, such as AWS Fargate, Azure Container Instance, or Google Cloud Run, this is typically covered by the provider. Please refer to your managed service providers guidelines for handling system patches.

Web application firewall (WAF) 

  • WAF is deployed for our Cloud customers and recommended for any non-air gapped self hosted deployments.

Logging 

  • This applies to customers who are self hosting or using features including Tunnel or Command Over HTTP. Ensure you’re collecting logs long term for security detections, incident response, and for diagnosing any issues.

Firewall Rules 

  • Configure rules to permit only the services required.

  • Specific to customers running Tines Tunnel:

    • By default, the container does not impose restrictions on the resources that can be accessed on the private network. Allowlist the internal resources to be made available through the Tines tunnel.

    • Configure an allowlist for the egress traffic.

Custom Certificate Authority 

Secrets Vaults 

  • Leverage vaults for managing infrastructure secrets where possible

    • ECS

    • EKS

    • EC2: Leverage user-script on startup or Systems Manager to set this

 

ℹ️Info