Skip to content



Security is one of the five pillars of CloudAEye design. This topic describes security for CloudAEye SaaS.

Well-Architected Framework

CloudAEye SaaS follows AWS Well-Architected Framework. Our design principles include important topics such as "principle of least privilege and enforce separation of duties with appropriate authorization for each interaction", "apply security at all layers", "protect data in transit and at rest", "automate security best practices", etc.

Identity and Access Management

Priviledge management is done using centralized identity and access management. All human identities and access are managed using role based access control (RBAC) policies. All machine identities are controled using AWS access key concept.

Role-based Access Control (RBAC)

In order to control access, you may use the groups. Add users to a particular group to provide them necessary access.

Groups in CloudAEye are used to group privileges into three broad categories for convenience:

  • Root administrator for the account (Tenant Administrator),
  • Administrators of the services (Service Administrator), and
  • Users of the services (Service User).

The Tenant Administrator group has the highest level of access and is responsible for managing the entire account. The Service Administrator group is responsible for managing specific services within the account. The Service User group has the lowest level of access and is responsible for using the services provided by CloudAEye. By adding a user to a specific group, the user is assigned privileges from that group. For example, all users in the Logs Service Admin group are assigned administrative privileges for that logs service.

Unauthorized Access

For any unprivileged access, user will see an error page similar to the above picture. User will need to request the Tenant Administrator of the account to grant him/her necessary access.


Security During Agent to SaaS Communication

To secure the communiction while logs and metrics services agents send data from client side to CloudAEye SaaS (server side), AWS Signature Version 4 signing process is used. All communication uses HTTPS and TLS (Transport Layer Security). Each SaaS account is provided an access key consists of one access key ID and secret access key. This access key must be kept confidential. CloudAEye adopts shared responsibility model for security. Please contact CloudAEye immidiately if your access key is compromised. CloudAEye will work with you to turn off that access key.

Encryption at REST

You may enable Encryption at REST while creating the logs service.


We use the AWS Key Management Service (AWS KMS) to store and manage the encryption keys. We use the Advanced Encryption Standard algorithm with 256-bit keys (AES-256) to perform the encryption at REST.