Security overview

This document is for security reviewers. It covers what Cloud Certainty SQLark protects against, how users are identified, how access is limited, where data goes and how it is encrypted. Everything described here runs in your own AWS account.

#Threat model

SQLark runs Amazon Athena queries over your data for many people. What it must prevent:

Out of scope: a malicious administrator of the AWS account (they can change any IAM policy), and the security of the identity provider and of users' devices.

#Controls

#Identity and authorization

The API trusts the Cognito ID token's signature, issuer and audience (checked by API Gateway), and then decides who the caller is from its claims. Roles, grants, history and the bootstrap admin are keyed on the email claim, so a user who could pick their own email could take over someone else's access. The API therefore accepts the email only when it is one the user can't choose; otherwise it refuses the caller with 403 forbidden on every route.

The provider is read from the signed token, never from anything the client sends.

Bootstrap admin. BootstrapAdminEmail is always an admin, so it is bound to an immutable identity: the first trusted sign-in with that email records the caller's Cognito user ID, and from then on only that user is the bootstrap admin. Sign in as the bootstrap admin straight after deployment. Resetting the binding is described in the admin guide.

#Permissions, grants and session policies

What a user can do is the intersection of two independent layers.

1. The connection's IAM role sets the ceiling for everyone: the local role is limited by the stack parameters LocalAccessLevel (Query or Full), DataBucketNames, ResultBucketNames and DataKmsKeyArns; a spoke role by the same parameters of its own stack. SQLark can never do more in an account than its role allows, and the account owner controls that role.
2. SQLark grants decide what each user may do within that ceiling: a subject (user or group), a connection, Regions, workgroup patterns, database patterns and permissions (browse, query, download, ddl). See the admin guide.

Grants are not only checked in code. For every request, the API calls sts:AssumeRole on the connection's role with:

• SourceIdentity = the user's email. It can't be changed for the rest of the session, also in role chains, and it appears in CloudTrail for every Athena, Glue and S3 call in the target account;
• a role session name sq-<email>, also visible in CloudTrail;
• a session policy (for non-admins) that allows only the Athena actions on the one workgroup the request needs, AWS Glue reads only on the databases (and their tables) granted in that workgroup, Glue writes only where the user holds ddl, and S3 writes only to the workgroup's result location (plus the data locations with ddl). Athena uses these same credentials to read the catalogue, the table data and KMS keys, so the policy bounds the query itself. If a user's grants are too many to fit the session policy size limit, the request is refused rather than widened.

Grants on workgroup A with database X and on workgroup B with database Y never combine into "B with X": each execution's policy holds only the databases granted in its own workgroup.

Your Lake Formation permissions, bucket policies and SCPs still apply on top: SQLark adds restrictions and never removes yours. Use Lake Formation for row and column security inside a table.

#IAM summary

* resources appear only where AWS has no resource-level permissions (athena:ListWorkGroups, ListDataCatalogs, ListEngineVersions, License Manager, lakeformation:GetDataAccess) and for DataBucketNames when you keep its default *. For the listings, SQLark filters results by the caller's grants: a user never sees a workgroup or database they have no grant on.

#Data flows

#What stays in your account

Everything: identities, connections and external IDs, grants, the query history with SQL text, saved queries, dashboards, snapshots (which contain result rows), usage figures and the audit log, as well as your data and the query results. Cloud Certainty operates no service in the data path, and the stack never contacts the vendor at runtime. The AWS Marketplace container registry and the vendor's public bucket in us-east-1 (templates and the release manifest) are read-only distribution points used at install and upgrade, and, with UpdateChecks = Enabled, for a daily read of the public release manifest that sends nothing about you. Links to cloudcertainty.com in the portal are plain links, followed only when someone clicks them.

#Encryption

• In transit. TLS for every AWS API and the portal (HTTPS only, with HSTS). The artifacts and results buckets deny non-TLS requests.
• At rest. With KmsKeyArn (hub) or ResultsKmsKeyArn (spoke), your customer managed key encrypts the DynamoDB tables, CloudWatch Logs, the update topic, the artifacts bucket and the SQLark results buckets, and the SQLark workgroup enforces SSE-KMS for its results. Without it, AWS owned keys and SSE-S3 are used. Your own buckets, tables and catalogue keep their own encryption.
• Query results. SQLark results buckets block public access, enforce bucket ownership, are reachable only over TLS and delete results after ResultsRetentionDays (30 by default).

#Portal hardening

Amplify Hosting serves the portal with these headers:

• A strict Content-Security-Policy: no inline or third-party script, frame-ancestors 'none', and AWS endpoints allowed only for sign-in and the API. Downloads open the presigned S3 link as a normal navigation.
• Strict-Transport-Security, X-Content-Type-Options: nosniff, Referrer-Policy: no-referrer, X-Frame-Options: DENY, and a Permissions-Policy that turns off camera, microphone, geolocation, payment and USB.

Charts are drawn in the browser; nothing is loaded from third parties. Tokens are kept in session storage, never in cookies; refresh tokens last 8 hours and can be revoked.

#Audit

Every administrative change (roles, connections, grants, settings), every write statement, every result download, every snapshot created or deleted, and every saved query and dashboard change is written to the audit log with the actor, source IP and target. Admins read it in Administration › Audit. Events are kept for the plan's audit days: 30 on Starter, 90 on Team, 365 on Business and 3,650 on Enterprise. The query history keeps who ran every query for 30 to 730 days by plan. For each AWS call, CloudTrail in the account that runs the query shows the assumed-role session with sourceIdentity set to the user's email. Forward CloudTrail and the log groups to your SIEM.

#Licensing

SQLark reads its AWS Marketplace licence from AWS License Manager in your account: at install and in the API. Nothing about your usage or data is sent anywhere. Without a valid licence the installer stops and the API answers 402 licence_required. If License Manager is unreachable, or a licence that was active disappears (which bridges a move between plans), SQLark keeps working for up to 72 hours from the last successful check. Your data stays in place either way.

#Shared responsibility

• Keep BootstrapAdminEmail on a protected identity and enforce MFA at your IdP. Grant Admin to a second person or group.
• Keep connection roles at Query unless a team needs write statements there, and narrow DataBucketNames to your data lake buckets.
• Grant groups rather than single users, with database prefixes per team (sales_*) in team workgroups.
• Keep the per-query scan limit on SQLark workgroups, set scan budgets on Business, and review Administration › Usage.
• Treat snapshots like exports: share only data everyone signed in may see, with short expiries.
• On Business and above, set the IP allowlist to your corporate egress ranges if users should only connect from managed networks.
• Forward CloudTrail and SQLark's log groups to your SIEM.