Security¶

Overview¶

Security is one of the five pillars of CloudAEye design. CloudAEye supports both SaaS and self-hosted deployments. This topic describes the security principles, identity and access controls, data protection, and deployment architecture used by these deployment models.

AWS Well-Architected Framework¶

CloudAEye SaaS follows the AWS Well-Architected Framework. Our design principles include applying the principle of least privilege, separating duties with appropriate authorization for each interaction, applying security at every layer, protecting data in transit and at rest, and automating security best practices.

Self-hosted deployments use AWS services and architecture components within the customer's AWS environment. The deployment is designed to support the customer's security policies and infrastructure controls.

Identity and Access Management¶

CloudAEye uses centralized identity and access management. Human-user access is governed by role-based access control (RBAC) policies. Machine identities and service-to-service access are controlled through AWS identity and access mechanisms and appropriately scoped credentials.

Role-based Access Control (RBAC)¶

Access can be managed through groups. Add users to a particular group to provide them with the required access.

Groups in CloudAEye organize privileges into three broad categories:

Tenant Administrator — the account-level administrator with the highest level of access, responsible for managing the entire account.
Service Administrator — an administrator responsible for managing specific services within the account.
Service User — a user with permission to use the services provided by CloudAEye.

A user's privileges are determined by their group membership. For example, users in the Logs Service Admin group receive administrative privileges for that service.

Unauthorized Access¶

When a user attempts to access a resource without the required privileges, CloudAEye displays an unauthorized-access error. The user should contact the Tenant Administrator to request the necessary access.

RBACError

SAML 2.0 Single Sign-On (SSO)¶

CloudAEye supports SAML 2.0-based single sign-on (SSO), allowing organizations to authenticate users through their existing identity provider (IdP).

With SAML SSO:

Users sign in to CloudAEye through the organization's configured identity provider.
The organization can apply its identity-provider authentication policies, such as its existing sign-in and multi-factor authentication requirements.
CloudAEye continues to enforce application-level authorization through its RBAC groups and permissions. Authentication through an IdP does not, by itself, grant administrative or service-level privileges.

The SAML integration must be configured with the organization's identity provider. Access to CloudAEye should be limited to authorized users, and their CloudAEye roles should be assigned according to the organization's access-control policies.

Security During Agent-to-SaaS Communication¶

When logs and metrics agents send data from a customer's environment to CloudAEye SaaS, communication is protected using HTTPS and TLS (Transport Layer Security). AWS Signature Version 4 signing is used to authenticate supported agent requests.

Each SaaS account is provided with an access key consisting of an access key ID and a secret access key. These credentials must be kept confidential and appropriately protected. CloudAEye follows a shared-responsibility model for security. If an access key is compromised, contact CloudAEye immediately so that the affected key can be disabled.

Self-Hosted Deployment Security¶

CloudAEye supports deployment within a customer's AWS account and customer-managed Virtual Private Cloud (VPC). In this model, the customer retains ownership and control of the AWS environment in which the CloudAEye application and its supporting data services run.

Deployment Architecture¶

The self-hosted deployment uses AWS infrastructure components including:

Amazon ECS to run CloudAEye application workloads.
Application Load Balancer (ALB) to route application traffic.
Private subnets to keep application and supporting services within the customer's VPC network boundary.
Terraform to provision and manage the deployment infrastructure as code.
Customer-managed VPC to provide control over network topology, routing, and network access policies.

The deployment is provisioned in the customer's AWS account. The customer controls the underlying AWS account, VPC, and associated infrastructure configuration.

Data Flows and Supporting Services¶

In a self-hosted deployment, the supporting data services operate within the customer's AWS environment:

MongoDB stores application data.
ChromaDB provides vector storage.
Amazon SQS supports message queuing and asynchronous processing.
Amazon CloudWatch supports operational logging and monitoring.

Application data and service communications remain within the customer's AWS environment, subject to the customer's network configuration and any explicitly configured external integrations.

Data Sovereignty and Customer Control¶

The self-hosted model is designed to give customers control over their infrastructure and data environment:

The customer owns and manages the AWS account and deployment environment.
Application storage and supporting data services are deployed within the customer's AWS account.
The customer controls VPC configuration, network access, and applicable security policies.
The customer can apply its own AWS governance, monitoring, retention, and access-management requirements to the environment.

The customer is responsible for managing access to its AWS account and for the security configuration of the infrastructure it controls. CloudAEye application-level controls, including RBAC, complement these customer-managed infrastructure controls.

Encryption at Rest¶

For SaaS deployments, CloudAEye uses AWS Key Management Service (AWS KMS) to store and manage encryption keys. Advanced Encryption Standard with 256-bit keys (AES-256) is used for encryption at rest.

For self-hosted deployments, data storage and encryption controls are managed within the customer's AWS environment. Customers can apply their AWS key-management and data-protection policies to the deployed services.

Shared Responsibility¶

CloudAEye security responsibilities depend on the deployment model:

SaaS: CloudAEye manages the service infrastructure and its security controls. Customers are responsible for managing their users, credentials, access permissions, and the data they submit to the service.
Self-hosted: The customer controls the AWS account, VPC, infrastructure, storage, and network access. CloudAEye application-level security controls, such as RBAC, operate alongside the customer's infrastructure and identity-management policies.

Customers should follow least-privilege practices, protect credentials, regularly review user access, and configure monitoring and retention in accordance with their security requirements.