VMware Aria Operations for Applications (formerly known as Tanzu Observability by Wavefront) protects your data and includes facilities for you to customize authentication and authorization.
This page gives a summary.
- Download this white paper for a detailed discussion.
- Download and review the Cloud Security Alliance Consensus Assessments Initiative Questionnaire for VMware Aria Operations for Applications for our consensus assessment questionnaire.
Operations for Applications has successfully completed all requirements for the following certifications and reports:
- ISO 27001/27017/27018
- SOC 2 Type 1
- CSA STAR Level 1
Operations for Applications is used for monitoring applications. Operations for Applications securely stores user name and password information, but does not collect information about individual users. We do not install agents that collect user information.
None of the built-in integrations collect user information. However, our customers can set up their service instances to collect any type of information they want.
Currently, Operations for Applications uses AWS to run the service and to store customer application data.
- The service is served from a single AWS region spread across multiple availability zones for failover.
- All incoming and outgoing traffic is encrypted.
- We take advantage of other AWS security features such as encryption at rest and system backups that use asymmetric encryption.
- The customer environments are isolated from each other. Data is stored on encrypted data volumes.
The AWS data centers incorporate physical protection against environmental risks. To access the AWS ISO27001 report, see https://aws.amazon.com/compliance.
For more information on AWS controls, visit: https://cloudsecurityalliance.org/star/registry/amazon/services/amazon-web-services/.
Our development, QA, and production use separate equipment and environments, and are managed by separate teams. Customers retain control and ownership of their content. We do not replicate customer content unless the customer asks for it explicitly.
Operations for Applications is architected to be highly available. In the event of a hardware failure, we automatically migrate to or restart workloads, on another host machine in the cluster and automatically restart the failed host. If the host machine fails to restart, or the performance of the restarted host is degraded, the service is capable of replacing the failed host in a cluster with an entirely new host within minutes.
Operations for Applications supports the option of Disaster Recovery (DR) across regions for customers. Contact your Operations for Applications representative for details.
Applications send data to Operations for Applications using either the Wavefront proxy or direct ingestion. We protect all data traffic with TLS (Transport Layer Security) and HTTPS. If you send data directly to Operations for Applications, we require TLS 1.2 connections.
The Wavefront proxy uses HTTPS, and we offer options to secure it further:
Perform a manual install and place the Wavefront proxy behind an HTTP proxy.
Use proxy configuration properties to set ports, connect times, and more.
Use an allow list regex or block list regex to control traffic to the Wavefront proxy.
Operations for Applications supports three methods of authentication.
- By using a user name and password.
Operations for Applications supports user accounts and service accounts. User accounts must authenticate with a user name and password, service accounts authenticate with a token.
You can use the authentication provided by Operations for Applications or use one of the supported authentication integrations. We support several authentication solutions including Azure AD, Google ID, and Okta.
We also support self-service SAML SSO setup.
If your chosen authentication solution supports two-factor authentication, Operations for Applications requires two-factor authentication for login.
Large customers can request multi-tenant SSO. Users in different teams inside the company can authenticate to different tenants and cannot access the other tenant’s data.
Operations for Applications supports multi-level authorization:
- Roles and permissions determine which groups or users can manage which objects or perform certain tasks. For example, you could create a read-only role with no permissions and assign it to a Novice group, or create a Developers role, assign Dashboards, Alerts, Proxy, Metrics, and Chart Embedding permissions, and assign it to a developer group.
- Access control applies to individual objects (dashboards or alerts). Privileged groups or users can revoke grant access to individual groups or users. Operations for Applications supports a high security mode where only the object creator and the Super Admin user can view and modify new dashboards.
- Metrics security policy rules allow fine-grained control over metrics visibility in dashboards, charts, alerts, etc.
If you use the REST API, you must pass in an API token and have the necessary permissions to perform the task, for example, Dashboards permission to modify dashboards.
If you use direct ingestion, you are required to pass in an API token and must also have the Direct Data Ingestion permission.
You can view changes that were made to dashboards, alerts, etc., by using versions of charts and dashboards.
Our cloud integrations support monitoring data from different cloud providers. The process is like this:
- You open the integration.
- You give Operations for Applications global read-only access or limited access.
For details, see the individual integration.
VMware Security Development Lifecycle
VMware has an industry-leading Security Development Lifecycle process and a VMware Cloud Services Security organization that focuses on ensuring that VMware cloud services implement industry standard operational and security controls.