Product security and architecture
- is always encrypted at rest and in transit over public networks, and customer credentials are additionally encrypted at the application level and can only be decrypted by the application components that require them.
- User authentication through your organization’s identity provider like Google, Okta, or any SAML-compatible identity provider, allows you to control security requirements like MFA.
- Users can be assigned attributes that can checked in authorization logic to, for example, limit the user’s access to data sets or apply filters.
- Authentication and authorization checks are applied immediately upon the receipt of every request to Omni, and, if passed, set an authorization context on subsequent code execution that ensures the request is sandboxed to the appropriate user and organization.
- Access to a customer’s Omni instance by Omni personnel for support is visible to and controllable by the customer.
Customer data
Omni processes the following data:- Information about Omni users, for example name and email. This does not include user passwords since this is delegated to a third party identity provider
- Omni configuration data, for example connection parameters, the Omni data model, and chart and dashboard configuration, excluding credentials to customer systems
- Data contained in the data sources connected to Omni, referred to as “Customer Data”
- Credentials to access customer data, referred to as “Customer Credentials”
Data segregation and encryption
and are:- Logically segregated on Omni’s systems by customer tenant ID and unique dataset identifiers
- Always encrypted at rest and in transit over public networks
Subprocessors
Omni uses the following third parties to assist in providing the Omni services, and those that have access to customer data are considered subprocessors.| Name | Nature of Processing | Territories |
|---|---|---|
| Amazon Web Services | Cloud infrastructure | US, EU, Australia |