🔓Security
Measures Orchestra undertakes to keep your operations secure
Orchestra has access to underlying data applications but no underlying data. Orchestra will only collect and store metadata from data tools / integrations and will never directly interact with underlying data that exists in a data lake or data warehouse.
We take security extremely seriously and to that effect have the following measures in place to ensure the service is not compromised:
All connections use TLS1.3 with HTTPS
Infrastructure runs in a private subnet with a reverse proxy
SSO sign-in via Google supported (more can be added if required just let us know)
All common web security practices (CORS, CSP, HSTS, etc.) are implemented
Orchestra validates all user input to protect against common attacks like SQL injection, Cross-Site Scripting (XSS), and Cross-Site Request Forgery (CSRF)
All logs are stored for 90 days, and actively monitored for suspicious activity
Data Processing
Orchestra is a platform for Orchestration and Observability, and therefore does not process any customer data. Generally, tools that process customer data are those that store it (e.g. data warehouses like bigquery or snowflake), tools that move data (e.g. Fivetran, Airbyte, Stitch, Hightouch, Census) and so-on.
For example, Orchestra requires integration credentials to platforms that do process customer data, but not the data itself. For example, we may ask you for a Fivetran Credential so Orchestra can interact with Fivetran; this does not mean Orchestra has access to the same set of privileges Fivetran does.
This does not preclude the possibility of Customer Data appearing in the Orchestra platform, which is possible where the platform is used improperly. Orchestra is not a solution for storing Customer Data so customers should comply with the Section 7 of the Terms of Service to ensure underlying customer data does not appear in the Orchestra platform (see Terms of Service at bottom)
Integration Credentials
Storing integration credentials in a secure and controlled way is an important aspect of the app. We store credentials encrypted at rest. When the secret is needed we only decrypt it just before the secret is used. The decryption key is only accessible to the resources that require it.
Whitelist IPs
Sometimes it is necessary to orchestrate tasks for integrations behind a firewall. For Orchestra to communicate with those resources it is necessary to add the Orchestra platform IP addresses to your whitelist of allowed IPs. The IPs Orchestra currently uses are:
Failover protocol and redundancy
Orchestra backs up all critical metadata needed to deliver the service
Orchestra uses relevant subnets in multi availability zones
Orchestra takes advantage of relevant SLAs from cloud providers (AWS, Azure, GCP)
Servers, Databases, serverless infrastructure and other compute resources are all monitored by alerts as governed by the Internal Alerting Protocol
These are regularly reviewed and updated
Services send alerts to multiple destinations, which have multiple owners, which ensures errors and high priority logs are captured in real-time
Core Orchestration is run in an entirely serverless fashion, which means:
All core processes are independent
Orchestra automatically handles re-runs and failures due to idiosyncratic errors
Business Continuity and Incident Response Plans can be found under the 'resources' section of https://getorchestra.io
Last updated