Amazon Redshift Security Guide: Access, Encryption and Data Sharing Controls

An Amazon Redshift warehouse usually holds the most valuable data an organisation has in one place, and it is reached by more identities than almost any other system: analysts, BI tools, ETL jobs, data sharing consumers and administrators. Redshift ships with strong controls, but several of them are off or permissive by default, and the ones that matter most sit in three different layers: AWS IAM, the database's own users and roles, and the network. This guide covers how to authenticate people and workloads, how to apply least privilege inside the database with roles, row-level security and masking, how encryption and keys really work, how to share data with other clusters and accounts safely, and what to log and measure. It is written for cloud security engineers, data platform owners and auditors who run provisioned clusters or Redshift Serverless.

Key takeaways

• Kill static database passwords first. Use temporary IAM credentials (GetClusterCredentials lasts 15 to 60 minutes) or identity provider federation for people and workloads, and keep the admin user for break glass only.
• Two permission systems must agree. IAM decides who may obtain credentials and call the Redshift API; database GRANTs, roles, row-level security and masking decide what a session can read. Review both.
• Encryption at rest is on by default, transport encryption is not. Set require_SSL to true in the parameter group and have clients use sslmode verify-full.
• Data sharing is a trust boundary. Cross-account datashares need explicit producer authorisation and consumer association; keep them narrow and review authorisations as you would a partner contract.
• The user activity log is off until you turn it on. Audit logging alone does not record queries: enable_user_activity_logging must also be true.

The Redshift security model in three layers

Most Redshift weaknesses come from treating it as either a pure AWS resource or a pure database. It is both, and each layer has its own controls and its own owners.

An attacker with the IAM permission to call GetClusterCredentials for an existing privileged database user inherits that user's database rights, and an attacker with a stolen database password needs no IAM at all if the endpoint is reachable. That is why both layers need reviews, and why the network layer still matters even with strong identity controls. See the AWS Security Guide for the account-level baseline this guide assumes.

Authentication: people, applications and the admin user

Options compared

Hardening GetClusterCredentials

• Scope the resource: IAM policies can restrict GetClusterCredentials to specific clusters, databases, database user names and group names. Never grant it on *; name the dbuser and dbgroup ARNs.
• Control AutoCreate: AutoCreate=true creates a missing user with PUBLIC permissions and needs redshift:CreateClusterUser. Users created this way carry the IAMA: prefix, existing users the IAM: prefix, which makes them easy to find in STL_CONNECTION_LOG and SYS_CONNECTION_LOG.
• Control group joins: DbGroups adds the session to existing database groups and requires redshift:JoinGroup on those groups. An unscoped JoinGroup permission is a privilege escalation path into whatever your most privileged group is.
• Keep sessions short: leave DurationSeconds at the default 900 for batch jobs; 3,600 is the maximum.

The admin user

Every provisioned cluster has an admin superuser created at launch. Security Hub CSPM control Redshift.8 flags clusters that keep the default admin user name. Use a non-default name, store the password in AWS Secrets Manager (Redshift can manage the admin password there), do not use the admin user for routine work, and alert on every connection by it. Superusers bypass most in-database controls, so the number of superusers is a metric in its own right. For the general practice see the Service Account Security Guide.

Least privilege inside the database

Inside Redshift, grant access to roles, not to individual users, and build from three mechanisms that stack.

• Role-based access control: create roles per data domain and function (for example finance_read, etl_writer) with CREATE ROLE, GRANT the object privileges to the role, then GRANT ROLE to users. Revoke default privileges on the PUBLIC group for sensitive schemas, because every user, including auto-created IAM users, is a member of PUBLIC.
• Column-level grants: GRANT SELECT (col1, col2) ON table TO ROLE ... hides whole columns from a role.
• Row-level security: an RLS policy (CREATE RLS POLICY with a USING predicate) is attached to a table for a user or role, and the table is switched on with ALTER TABLE ... ROW LEVEL SECURITY ON. Queries are filtered automatically without changes to SQL. AWS advises keeping policies simple: if a policy predicate uses a lookup table, Redshift scans that table too, so heavy joins slow every query by an affected role. Treat the IGNORE RLS permission as a privileged entitlement.
• Dynamic data masking: masking policies change what a role sees at query time without changing stored data. Several policies can be attached to the same column for different roles with a priority to resolve conflicts, conditional masking works at cell level, and masking can redact fully or partially or hash values through SQL, Python or Lambda user-defined functions. Hashing keeps join keys usable for analysts who must never see the raw value.

The general principles of database privilege design are in the Database Security Guide; this section covers only what differs in Redshift.

Encryption and key management

At rest

Redshift databases and their snapshots are encrypted at rest by default with an AWS-owned key. Switching to a customer managed AWS KMS key gives you control over key policy, rotation, disabling and CloudTrail visibility of key use. Redshift uses a four-tier hierarchy: the KMS root key, a cluster encryption key (CEK), a database encryption key (DEK) and per-block data encryption keys.

• Rotation: rotating keys on a cluster rotates the CEK for the cluster and its snapshots and the DEK for the cluster; the cluster enters the ROTATING_KEYS state and is briefly unavailable. Snapshot DEKs are not rotated, so old snapshots remain under their original DEK.
• Disabling a key is destructive: if a customer managed key is disabled, Redshift can place the warehouse in the inaccessible-kms-key state for 14 days; if the key is not re-enabled in time the warehouse is deleted. Protect the key policy and alert on DisableKey and ScheduleKeyDeletion for Redshift keys. The Codefinger S3 ransomware campaign showed attackers using a victim's own AWS encryption features against them; key administration rights deserve the same protection as data rights.
• Cross-Region snapshot copies: KMS keys are Regional, so copying snapshots of a cluster encrypted with a customer managed key needs a snapshot copy grant in the destination Region.
• Migrating older clusters: an unencrypted cluster can be modified to use KMS encryption; Redshift migrates the data, the first completed snapshot confirms the change, and tables created with BACKUP NO are not retained. On DC2 nodes only reads run during encryption.
• HSM: HSM-based encryption supports only AWS CloudHSM Classic, which is closed to new customers, and is not supported for DC2, RG or RA3 node types. For new designs use KMS.

In transit

By default a cluster accepts connections with or without SSL. Set require_SSL to true in the cluster parameter group (and in the Serverless workgroup configuration); set use_fips_ssl as well where FIPS 140-2 is required. On the client side, sslmode=verify-full verifies the certificate and the host name even if the server does not require SSL; use the current Amazon Trust CA bundle, not the older Redshift CA bundle. Security Hub CSPM control Redshift.2 checks transport encryption and Redshift.10 checks encryption at rest. See the Cryptographic Key Management Guide.

Network exposure and data movement

• Do not make clusters publicly accessible: Security Hub CSPM control Redshift.1 flags public access, and Redshift.15 flags security groups that allow the cluster port from unrestricted origins. Analysts reach the warehouse through private connectivity, a Redshift-managed VPC endpoint or a bastion pattern, not the internet.
• Enable enhanced VPC routing: without it, COPY and UNLOAD traffic to S3 and other services goes over the internet path; with it, traffic follows your VPC routes, so S3 gateway endpoints, endpoint policies, security groups and VPC flow logs apply (control Redshift.7). It does not cover Redshift Spectrum.
• Restrict UNLOAD destinations: UNLOAD writes query results to S3 using an IAM role attached to the cluster. An S3 endpoint policy that allows only your organisation's buckets (for example with the aws:ResourceOrgID condition key) prevents UNLOAD to an attacker-owned bucket, a direct defence against ATT&CK T1537 Transfer Data to Cloud Account.
• Scope the cluster's IAM roles: roles attached for COPY, UNLOAD, Spectrum and federated queries are machine identities with data access of their own. Give each a narrow S3 prefix and avoid sharing one role across clusters. See the AWS IAM Policies and Roles Guide.

Data sharing safely

Redshift data sharing gives consumers live, read-consistent access to producer data across clusters, workgroups, accounts and Regions without copying it. Access is read-only by default, but writes can be enabled, and the grantable permissions include SELECT, INSERT and UPDATE on tables and USAGE and CREATE on schemas.

1. Design the share: add only the objects the consumer needs. Prefer a view or a purpose-built table over a whole schema, and avoid ALTER DATASHARE ... SET INCLUDENEW = TRUE on sensitive schemas, because new tables would flow out automatically.
2. Grant inside the producer: GRANT USAGE ON DATASHARE to a namespace (same account) or to an AWS account (cross-account).
3. Authorise explicitly: for cross-account sharing, a producer administrator must run authorize-data-share for the consumer account ID; both producer and consumer clusters must be encrypted.
4. Associate narrowly on the consumer side: associate-data-share-consumer can target the entire account or a specific namespace; choose the namespace unless every warehouse in the account should see the data, and decline shares nobody expected.
5. Review and revoke: list authorisations quarterly and use deauthorize-data-share when a relationship ends. Datashares listed through AWS Data Exchange are a commercial channel and need the same object review.

Restrict the IAM actions AuthorizeDataShare, AssociateDataShareConsumer and the datashare SQL to a small group; in AWS Organizations an SCP can deny AuthorizeDataShare outside approved accounts. See the AWS Organizations and SCPs Guide and the Third-Party Access Guide.

Logging, detection and metrics

Audit logs can go to S3 (only SSE-S3 encryption, and S3 Object Lock must be off on the bucket) or to CloudWatch Logs under /aws/redshift/cluster/<cluster_name>/<log_type>; Redshift Serverless sends audit logs to CloudWatch only. Logging to system tables is automatic but retention there is short, so export. Security Hub CSPM control Redshift.4 checks that audit logging is enabled. Send everything to the central store described in the Cloud Logging and Audit Trail Guide.

Detections worth building: UNLOAD to a bucket outside the organisation; a large SELECT * against a sensitive table by a principal that never queried it before; GetClusterCredentials with AutoCreate from an unusual role; new datashare authorisations; snapshot restore or snapshot sharing with another account (ATT&CK T1537); disabling audit logging or KMS keys.

Metrics:

• Share of connections using IAM or federated credentials rather than static passwords (target over 95 per cent).
• Number of superusers and users with IGNORE RLS, per cluster, trended monthly.
• Percentage of clusters and workgroups passing Redshift.1, .2, .4, .7, .8 and .10.
• Active cross-account datashare authorisations with a named owner and review date (target 100 per cent).
• Median time to revoke access after a leaver or partner offboarding.

Implementation roadmap

1. Baseline (week 1 to 2): enable Security Hub CSPM Redshift controls across accounts, inventory clusters, workgroups, superusers, datashares, attached IAM roles and parameter groups. Turn on audit logging with enable_user_activity_logging.
2. Close exposure (week 2 to 4): remove public accessibility and open security group rules, set require_SSL, enable enhanced VPC routing with S3 endpoint policies. Test in a non-production cluster first: parameter group changes may need a reboot, and COPY or UNLOAD jobs fail if no VPC path exists. Roll back by reverting the parameter group or route change.
3. Move identities (month 2): migrate applications to GetClusterCredentials with scoped policies and people to IdP federation with MFA; set short password expiry on remaining static users, then lock them. Keep a break-glass admin in Secrets Manager.
4. Least privilege in the database (month 2 to 3): build RBAC roles per domain, revoke PUBLIC grants on sensitive schemas, apply column grants, then RLS and masking on the highest-risk tables. Pilot with one team, compare query results and performance, and keep detach statements ready to roll back.
5. Keys and sharing (month 3): move sensitive clusters to customer managed KMS keys, protect key policies, review every datashare and authorisation, add SCP guardrails.
6. Operate: quarterly access and datashare reviews, monthly metric reporting, detection tuning.

Small versus large estates: a single team with one Serverless workgroup can rely on IAM Identity Center or IdP federation, a handful of RBAC roles and CloudWatch audit logs. A large estate with many producer and consumer clusters needs a data owner per datashare, SCP guardrails on sharing APIs, centralised log analytics and a formal entitlement review, ideally fed from the same tooling described in the Access Reviews Guide.

Framework mapping

In CIS Controls v8.1 the same work falls mainly under Control 3 (Data Protection), Control 6 (Access Control Management) and Control 8 (Audit Log Management).

Common failure patterns

• Long-lived database passwords with no MFA: a service account password in a BI tool or notebook is reusable from anywhere the endpoint is reachable. The Snowflake breach showed how infostealer credentials without MFA or network restrictions opened 165 customer data warehouses; the same pattern applies to any cloud warehouse.
• Unscoped GetClusterCredentials: a policy allowing any DbUser and any DbGroups lets any holder log in as the most privileged database user.
• Audit logging "on" but no query log: enable_user_activity_logging left at false means investigators can see who connected but not what they ran.
• Broad datashares: whole schemas shared with INCLUDENEW, associated with an entire consumer account, never reviewed after the project ends.
• Overpowered cluster roles: one IAM role with s3:* attached to every cluster turns any SQL injection or compromised analyst account into an UNLOAD exfiltration path. Cloud role credentials abused through another service were at the centre of the Capital One breach.
• Snapshots forgotten: manual snapshots shared with other accounts or kept after a cluster is deleted carry the full data set outside current access controls.

Practitioner checklist

• Enable Security Hub CSPM Redshift controls in every account and fix Redshift.1, .2, .4, .7, .8 and .10 findings.
• Set require_SSL to true and move clients to sslmode verify-full with the Amazon Trust CA bundle.
• Turn on audit logging and enable_user_activity_logging; export logs to a central, access-controlled store.
• Replace static passwords with GetClusterCredentials or IdP federation with MFA; scope dbuser and dbgroup ARNs in IAM.
• Rename the default admin, store its password in Secrets Manager, alert on every admin and superuser session.
• Build RBAC roles, revoke sensitive grants from PUBLIC, apply column grants, RLS and masking to regulated tables.
• Use customer managed KMS keys for sensitive warehouses and alert on DisableKey and ScheduleKeyDeletion.
• Remove public accessibility, enable enhanced VPC routing and restrict UNLOAD destinations with S3 endpoint policies.
• Inventory datashares and cross-account authorisations, assign an owner to each and review quarterly.
• Review manual snapshots and snapshot sharing monthly.

Standards and references

• AWS: Amazon Redshift database encryption
• AWS: Database audit logging in Amazon Redshift
• AWS: GetClusterCredentials API reference
• AWS: Row-level security in Amazon Redshift
• AWS: Sharing data across AWS accounts in Amazon Redshift
• AWS: Enhanced VPC routing in Amazon Redshift
• AWS: Configuring security options for connections
• AWS: Security Hub CSPM controls for Amazon Redshift

Related NHI Mgmt Group resources: Data Security Guide · Database Security Guide · BigQuery Security Guide · Snowflake Security Guide · Data Exfiltration Guide