Data Security and Privacy
This page details how customer data is protected inside an AlertD deployment: where it is stored, how it is encrypted at rest and in transit, and how access is scoped.
A high-level summary of AlertD’s security model lives in Getting Started → Security Model. This page goes deeper on the encryption configuration, which auditors and security reviewers typically want to see explicitly.
Where Customer Data Is Stored
All customer state lives inside the customer’s own AWS account, in the region where the AlertD CloudFormation stack was deployed. Nothing is sent to or stored by AlertD outside that account.
| Data | Storage Location |
|---|---|
| User queries, session history, query results, execution plans, workspace metadata | Amazon Aurora Serverless v2 cluster created by the AlertD stack |
| Aurora database credentials | AWS Secrets Manager secret created by the AlertD stack |
LLM API key (if openai or anthropic profile is selected) | AWS Secrets Manager secret created by the AlertD stack |
| Application, Pulsar, and database logs | Amazon CloudWatch Logs log groups created by the AlertD stack |
| Container images (read-only) | Amazon ECR (pulled from the AlertD Marketplace ECR registry at deploy time) |
The AlertD application and Pulsar tasks themselves are stateless; their writable filesystem is ephemeral and is discarded when the task is replaced.
Encryption at Rest
Every AWS service that holds AlertD data is encrypted at rest. AlertD does not require customers to create or manage any KMS keys — the AWS-managed default keys are used everywhere.
| Service | What Is Encrypted | Encryption Method | Key |
|---|---|---|---|
| Amazon Aurora Serverless v2 | All cluster storage and automated backups | AES-256 storage encryption, enabled at cluster creation | AWS-managed KMS key for RDS (aws/rds) |
| AWS Secrets Manager | All secret values (DB credentials, LLM API key) | AWS-managed envelope encryption | AWS-managed KMS key for Secrets Manager (aws/secretsmanager) |
| Amazon CloudWatch Logs | All log group data | Server-side encryption | AWS-owned KMS key (or an AWS-managed aws/logs key) |
| Amazon ECS / Fargate ephemeral storage | Task scratch space | Fargate platform-managed encryption | AWS-managed |
| Amazon S3 (CloudFormation template object) | Read-only public template object — contains no customer data | SSE-S3 | AWS-managed |
Because the underlying KMS keys are AWS-managed, key rotation is performed automatically by AWS on a recurring schedule. Customers do not need to schedule or trigger key rotation themselves. See Monitoring and Maintaining AlertD → Cryptographic Keys for the operational view.
If your security policy requires customer-managed KMS keys (CMKs) rather than AWS-managed keys, contact AlertD support. Aurora, Secrets Manager, and CloudWatch Logs all support CMKs and the stack can be configured to use them.
Encryption in Transit
All network paths into, out of, and between AlertD components use modern TLS.
| Path | Protocol | Notes |
|---|---|---|
| End user browser → Application Load Balancer | HTTPS (TLS 1.2+) with the ACM certificate provided at deploy time | The ALB enforces HTTPS on its public listener |
| ALB → AlertD application task | HTTP over the private subnet | Traffic never leaves the customer’s VPC |
| AlertD task → Amazon Aurora | TLS-enabled PostgreSQL connection (sslmode=require) | Aurora certificate is the AWS RDS CA |
| AlertD task → AWS APIs (STS, Secrets Manager, CloudWatch, service APIs in the target account) | HTTPS via the AWS SDK v3 for JavaScript | Default endpoints are TLS-enforced |
AlertD task → api.openai.com / api.anthropic.com (when applicable) | HTTPS | The LLM provider enforces TLS 1.2+ |
AlertD task → Amazon Bedrock (when claude profile selected) | HTTPS via the AWS SDK | Stays within AWS backbone |
Monitoring Role and Least Privilege
AlertD reaches your infrastructure through a single IAM monitoring role — either created automatically by the CloudFormation stack (CreateMonitoringRole = true, see Deployment Step 6) or created by you in the target account during Advanced Setup. This role is the only access AlertD is granted as part of the deployment, and it carries no write permissions of any kind.
By default the role attaches the AWS-managed ReadOnlyAccess policy. To follow the principle of least privilege more strictly, you can instead attach the narrower AWS-managed ViewOnlyAccess policy, which grants only List* and Describe*-style permissions to enumerate resources and their metadata, and withholds the broader Get* permissions in ReadOnlyAccess that can return resource contents and detailed configuration.
| Policy | Scope | Recommended when |
|---|---|---|
ReadOnlyAccess (default) | Read metadata and content-level read APIs across services | You want all AlertD features available |
ViewOnlyAccess (tighter least privilege) | List/Describe resources and metadata only | Your security policy requires the minimum read surface |
Feature trade-off with ViewOnlyAccess. AlertD remains fully functional for inventory and infrastructure questions, but two capabilities depend on the broader ReadOnlyAccess permissions and will not work under ViewOnlyAccess:
- S3 cost optimization — requires the additional S3 read APIs that
ViewOnlyAccesswithholds. - Amazon Bedrock prompt optimization — requires the additional Bedrock read APIs that
ViewOnlyAccesswithholds.
If you rely on either feature, use ReadOnlyAccess. Otherwise, ViewOnlyAccess is the least-privilege choice.
To apply the tighter policy: when creating the role manually (Advanced Setup, or CreateMonitoringRole = false), attach ViewOnlyAccess in place of ReadOnlyAccess at the permissions step. The trust policy and every other step are unchanged.
What AlertD Cannot Access
Regardless of which policy you attach, AlertD’s monitoring role grants read-only access — under the default ReadOnlyAccess policy (and even more so under ViewOnlyAccess), AlertD cannot:
- Create, modify, or delete any AWS resource
- Read data inside resources (S3 object contents, database records, log contents your services emit)
- Create or modify IAM users, roles, or policies
- Generate access keys
For a longer treatment, see the FAQ → Security & Privacy section.
Related References
- Getting Started → Security Model — high-level security overview
- Monitoring and Maintaining AlertD → Secrets Management — how to rotate stored secrets
- FAQ → Security & Privacy — common questions