Data Privacy and Protection Policy¶
Overview¶
CloudAEye provides multi-tenant SaaS services. Each customer’s data is kept separate from each other. We rely on data classification to categorize data based on levels of sensitivity. We use encryption to protect data by way of rendering it unintelligible to unauthorized access.
Concepts¶
Tenant Isolation¶
The idea behind tenant isolation is that our multi-tenant architecture introduces constructs that tightly control access to resources and block any attempt to access resources of another tenant. Tenant isolation focuses exclusively on using tenant context to limit access to resources. This way, we can ensure that customer data is always secure and protected.
Tokenization¶
Tokenization is a process that allows us to define a token to represent an otherwise sensitive piece of information. For example, we can use a token to represent a customer’s credit card number. This way, we can ensure that customer data is always secure and protected.
Encryption¶
Encryption is a way of transforming content in a manner that makes it unreadable without a secret key necessary to decrypt the content back into plaintext.
Data at REST¶
Data at rest represents any data that is persisted in non-volatile storage for any duration in the workload. Protecting data at rest reduces the risk of unauthorized access. This way, we can ensure that customer data is always secure and protected.
Data in Transit¶
Data in transit is any data that is sent from one system to another. By providing the appropriate level of protection for data in transit, we can protect the confidentiality and integrity of the workload’s data. This way, we can ensure that customer data is always secure and protected.
Data Privacy and Protection¶
Tenant Isolation¶
Our multi-tenant SaaS architecture is designed with tenant isolation in mind. We store each tenant’s data in a completely separate piece of infrastructure to ensure that customer data is always secure and protected. We use ‘resource-based policies’ in IAM (AWS Identity and Access Management) to ensure tenant isolation. These policies guard against unauthorized access and make the backing store service only accessible for one and intended tenant.
Identity and Access Management¶
We manage privilege using centralized identity and access management. All human identities and access are managed using role-based access control (RBAC) policies. Our overall architecture enables access control at multiple levels. For machine identities, we control access using AWS access keys. This way, we can ensure that customer data is always secure and protected.
Tokenization¶
We use the AWS Secrets Manager service to manage, retrieve and rotate credentials. This helps us improve our security posture by eliminating the need for hard-coded credentials in application source code. Instead, we replaced hard-coded credentials with a runtime call to the Secrets Manager service to retrieve credentials dynamically when we need them. This way, we can ensure that our credentials are always up-to-date and secure.
Encryption at REST and in Transit¶
We ensure that customer data is secure by encrypting it both in transit and at rest. For data in transit, we use HTTPS and TLS (Transport Layer Security), as well as the AWS Signature Version 4 signing process.
For encryption at REST, we use the AWS Key Management Service (AWS KMS) to store and manage the encryption keys. We also use the Advanced Encryption Standard algorithm with 256-bit keys (AES-256) to perform the encryption at REST. This way, you can be sure that customer data is always protected.
Frequently Asked Questions (FAQ)¶
Purpose¶
What is the purpose and use of collected customer data?¶
CloudAEye provides multi-tenant SaaS services. Our code review service analyzes pull requests (PRs). Our automated test failure analysis pinpoints the root-cause of test failures in CI and suggests solutions.
Isolation¶
How does CloudAEye store customer data?¶
Our multi-tenant SaaS architecture is designed with tenant isolation in mind. We store each tenant’s data in a completely separate piece of infrastructure to ensure that customer data is always secure and protected. For code review, we do not store any customer code in CloudAEye. We only store meta-data such as name of repositories that are being monitored for code review. We analyze the pull request when a request for review is made. No information is stored in CloudAEye. We use ‘resource-based policies’ in IAM (AWS Identity and Access Management) to ensure tenant isolation. These policies guard against unauthorized access and make the backing store service only accessible for one and intended tenant.
Data Storage and Retention¶
Where is the customer data stored specifically?¶
CloudAEye is hosted on us-east region of AWS.
How long is customer data retained by CloudAEye? Will customer data be deleted or returned at the end of the engagement?¶
Customer choose the retention policy. We offer customers to define and set policy-based data aging and removal. For code review, customer may set a retention period for removing the old code reviews. After the retention period, the data will be deleted.
Can CloudAEye provide customer data in a readable and easily transferable format when required by the customer?¶
Yes.
What specific data is sent to CloudAEye?¶
- Code Review: The customer grants read access to the repository and its pull requests to enable automatic code reviews.
- Jira: (Optional) The customer can connect their Atlassian Jira Cloud instance for read/write access to enable AI-assisted productivity features. For example, the system can generate step-by-step implementation guidance for a Jira issue or create a tracking issue directly from a code review comment.
- Test Failure Analysis: Customers may connect their GitHub Actions, Jenkins, or AWS CodeBuild environments to support automated root-cause analysis and resolution of test failures.
Does CloudAEye need access to customer's source code?¶
Yes. For code review, CloudAEye needs a read only access. No code is stored in CloudAEye. When the code review request is made by customer, CloudAEye accesses the specific code snippets.
Personal Information¶
Does CloudAEye use personal information for any purpose outside of providing the services?¶
No.
Does CloudAEye handle or otherwise process any type of personal data (e.g. Personally Identifiable Information (PII), employee, customer, partner, etc.) for purposes other than account management or billing?¶
No.
Does CloudaEye use any anonymized or aggregate data for any independent purpose outside of providing the services?¶
No.
Does CloudAEye delete personal information such as email address?¶
Yes, when customer unsubscribes from our service, all account information is removed.
Can CloudAEye stop processing personal information when requested?¶
CloudAEye offers role-based access control (RBAC) policies. A tenant administrator (root user) can add or remove users. We use AWS Cognito for authentication, authorization and manage access to different services. When someone leaves customer's organization, the tenant administrator may remove that individual.
To remove the last user (Tenant Administrator), we require customer to unsubscribe from the service to delete this data.
Encryption¶
Is customer data encrypted in transit?¶
Yes.
Is customer data encrypted at rest?¶
Yes.
What encryption algorithms (at rest and in transit) do you use to encrypt and decrypt data?¶
We use AWS Key Management Service (AWS KMS) to store and manage the encryption keys and the Advanced Encryption Standard algorithm with 256-bit keys (AES-256) to perform the encryption.