Security Hub controls for Amazon Redshift - AWS Security Hub
[Redshift.1] Amazon Redshift clusters should prohibit public access[Redshift.2] Connections to Amazon Redshift clusters should be encrypted in transit[Redshift.3] Amazon Redshift clusters should have automatic snapshots enabled[Redshift.4] Amazon Redshift clusters should have audit logging enabled[Redshift.6] Amazon Redshift should have automatic upgrades to major versions enabled[Redshift.7] Redshift clusters should use enhanced VPC routing[Redshift.8] Amazon Redshift clusters should not use the default Admin username[Redshift.9] Redshift clusters should not use the default database name[Redshift.10] Redshift clusters should be encrypted at rest[Redshift.11] Redshift clusters should be tagged[Redshift.12] Redshift event notification subscriptions should be tagged[Redshift.13] Redshift cluster snapshots should be tagged[Redshift.14] Redshift cluster subnet groups should be tagged[Redshift.15] Redshift security groups should allow ingress on the cluster port only from restricted origins[Redshift.16] Redshift cluster subnet groups should have subnets from multiple Availability Zones

Security Hub controls for Amazon Redshift

These AWS Security Hub controls evaluate the Amazon Redshift service and resources.

These controls may not be available in all AWS Regions. For more information, see Availability of controls by Region.

[Redshift.1] Amazon Redshift clusters should prohibit public access

Related requirements: NIST.800-53.r5 AC-21, NIST.800-53.r5 AC-3, NIST.800-53.r5 AC-3(7), NIST.800-53.r5 AC-4, NIST.800-53.r5 AC-4(21), NIST.800-53.r5 AC-6, NIST.800-53.r5 SC-7, NIST.800-53.r5 SC-7(11), NIST.800-53.r5 SC-7(16), NIST.800-53.r5 SC-7(20), NIST.800-53.r5 SC-7(21), NIST.800-53.r5 SC-7(3), NIST.800-53.r5 SC-7(4), NIST.800-53.r5 SC-7(9), PCI DSS v3.2.1/1.2.1, PCI DSS v3.2.1/1.3.1, PCI DSS v3.2.1/1.3.2, PCI DSS v3.2.1/1.3.4, PCI DSS v3.2.1/1.3.6, PCI DSS v4.0.1/1.4.4

Category: Protect > Secure network configuration > Resources not publicly accessible

Severity: Critical

Resource type: AWS::Redshift::Cluster

AWS Config rule: redshift-cluster-public-access-check

Schedule type: Change triggered

Parameters: None

This control checks whether Amazon Redshift clusters are publicly accessible. It evaluates the PubliclyAccessible field in the cluster configuration item.

The PubliclyAccessible attribute of the Amazon Redshift cluster configuration indicates whether the cluster is publicly accessible. When the cluster is configured with PubliclyAccessible set to true, it is an Internet-facing instance that has a publicly resolvable DNS name, which resolves to a public IP address.

When the cluster is not publicly accessible, it is an internal instance with a DNS name that resolves to a private IP address. Unless you intend for your cluster to be publicly accessible, the cluster should not be configured with PubliclyAccessible set to true.

Remediation

To update an Amazon Redshift cluster to disable public access, see Modifying a cluster in the Amazon Redshift Management Guide. Set Publicly accessible to No.

[Redshift.2] Connections to Amazon Redshift clusters should be encrypted in transit

Related requirements: NIST.800-53.r5 AC-4, NIST.800-53.r5 SC-13, NIST.800-53.r5 SC-23, NIST.800-53.r5 SC-23(3), NIST.800-53.r5 SC-7(4), NIST.800-53.r5 SC-8, NIST.800-53.r5 SC-8(1), NIST.800-53.r5 SC-8(2), PCI DSS v4.0.1/4.2.1

Category: Protect > Data Protection > Encryption of data-in-transit

Severity: Medium

Resource type: AWS::Redshift::Cluster AWS::Redshift::ClusterParameterGroup

AWS Config rule: redshift-require-tls-ssl

Schedule type: Change triggered

Parameters: None

This control checks whether connections to Amazon Redshift clusters are required to use encryption in transit. The check fails if the Amazon Redshift cluster parameter require_SSL isn't set to True.

TLS can be used to help prevent potential attackers from using person-in-the-middle or similar attacks to eavesdrop on or manipulate network traffic. Only encrypted connections over TLS should be allowed. Encrypting data in transit can affect performance. You should test your application with this feature to understand the performance profile and the impact of TLS.

Remediation

To update an Amazon Redshift parameter group to require encryption, see Modifying a parameter group in the Amazon Redshift Management Guide. Set require_ssl to True.

[Redshift.3] Amazon Redshift clusters should have automatic snapshots enabled

Related requirements: NIST.800-53.r5 CP-10, NIST.800-53.r5 CP-6, NIST.800-53.r5 CP-6(1), NIST.800-53.r5 CP-6(2), NIST.800-53.r5 CP-9, NIST.800-53.r5 SC-5(2), NIST.800-53.r5 SC-7(10), NIST.800-53.r5 SI-13(5)

Category: Recover > Resilience > Backups enabled

Severity: Medium

Resource type: AWS::Redshift::Cluster

AWS Config rule: redshift-backup-enabled

Schedule type: Change triggered

Parameters:

Parameter Description Type Allowed custom values Security Hub default value

​MinRetentionPeriod

Minimum snapshot retention period in days

Integer

7 to 35

7

This control checks whether an Amazon Redshift cluster has automated snapshots enabled, and a retention period greater than or equal to the specified time frame. The control fails if automated snapshots aren't enabled for the cluster, or if the retention period is less than the specified time frame. Unless you provide a custom parameter value for the snapshot retention period, Security Hub uses a default value of 7 days.

Backups help you to recover more quickly from a security incident. They strengthen the resilience of your systems. Amazon Redshift takes periodic snapshots by default. This control checks whether automatic snapshots are enabled and retained for at least seven days. For more details on Amazon Redshift automated snapshots, see Automated snapshots in the Amazon Redshift Management Guide.

Remediation

To update the snapshot retention period for an Amazon Redshift cluster, see Modifying a cluster in the Amazon Redshift Management Guide. For Backup, set Snapshot retention to a value of 7 or greater.

[Redshift.4] Amazon Redshift clusters should have audit logging enabled

Related requirements: NIST.800-53.r5 AC-2(4), NIST.800-53.r5 AC-4(26), NIST.800-53.r5 AC-6(9), NIST.800-53.r5 AU-10, NIST.800-53.r5 AU-12, NIST.800-53.r5 AU-2, NIST.800-53.r5 AU-3, NIST.800-53.r5 AU-6(3), NIST.800-53.r5 AU-6(4), NIST.800-53.r5 CA-7, NIST.800-53.r5 SC-7(9), NIST.800-53.r5 SI-3(8), NIST.800-53.r5 SI-4(20), NIST.800-53.r5 SI-7(8), PCI DSS v4.0.1/10.2.1

Category: Identify > Logging

Severity: Medium

Resource type: AWS::Redshift::Cluster

AWS Config rule: redshift-cluster-audit-logging-enabled (custom Security Hub rule)

Schedule type: Change triggered

Parameters:

  • loggingEnabled = true (not customizable)

This control checks whether an Amazon Redshift cluster has audit logging enabled.

Amazon Redshift audit logging provides additional information about connections and user activities in your cluster. This data can be stored and secured in Amazon S3 and can be helpful in security audits and investigations. For more information, see Database audit logging in the Amazon Redshift Management Guide.

Remediation

To configure audit logging for an Amazon Redshift cluster, see Configuring auditing using the console in the Amazon Redshift Management Guide.

[Redshift.6] Amazon Redshift should have automatic upgrades to major versions enabled

Related requirements: NIST.800-53.r5 CA-9(1), NIST.800-53.r5 CM-2, NIST.800-53.r5 CP-9, NIST.800-53.r5 SC-5(2), NIST.800-53.r5 SI-2, NIST.800-53.r5 SI-2(2), NIST.800-53.r5 SI-2(4), NIST.800-53.r5 SI-2(5)

Category: Identify > Vulnerability, patch, and version management

Severity: Medium

Resource type: AWS::Redshift::Cluster

AWS Config rule: redshift-cluster-maintenancesettings-check

Schedule type: Change triggered

Parameters:

  • allowVersionUpgrade = true (not customizable)

This control checks whether automatic major version upgrades are enabled for the Amazon Redshift cluster.

Enabling automatic major version upgrades ensures that the latest major version updates to Amazon Redshift clusters are installed during the maintenance window. These updates might include security patches and bug fixes. Keeping up to date with patch installation is an important step in securing systems.

Remediation

To remediate this issue from the AWS CLI, use the Amazon Redshift modify-cluster command, and set the --allow-version-upgrade attribute. clustername is the name of your Amazon Redshift cluster.

aws redshift modify-cluster --cluster-identifier clustername --allow-version-upgrade

[Redshift.7] Redshift clusters should use enhanced VPC routing

Related requirements: NIST.800-53.r5 AC-4, NIST.800-53.r5 AC-4(21), NIST.800-53.r5 SC-7, NIST.800-53.r5 SC-7(11), NIST.800-53.r5 SC-7(20), NIST.800-53.r5 SC-7(21), NIST.800-53.r5 SC-7(4), NIST.800-53.r5 SC-7(9)

Category: Protect > Secure network configuration > API private access

Severity: Medium

Resource type: AWS::Redshift::Cluster

AWS Config rule: redshift-enhanced-vpc-routing-enabled

Schedule type: Change triggered

Parameters: None

This control checks whether an Amazon Redshift cluster has EnhancedVpcRouting enabled.

Enhanced VPC routing forces all COPY and UNLOAD traffic between the cluster and data repositories to go through your VPC. You can then use VPC features such as security groups and network access control lists to secure network traffic. You can also use VPC Flow Logs to monitor network traffic.

Remediation

For detailed remediation instructions, see Enabling enhanced VPC routing in the Amazon Redshift Management Guide.

[Redshift.8] Amazon Redshift clusters should not use the default Admin username

Related requirements: NIST.800-53.r5 CA-9(1), NIST.800-53.r5 CM-2

Category: Identify > Resource Configuration

Severity: Medium

Resource type: AWS::Redshift::Cluster

AWS Config rule: redshift-default-admin-check

Schedule type: Change triggered

Parameters: None

This control checks whether an Amazon Redshift cluster has changed the admin username from its default value. This control will fail if the admin username for a Redshift cluster is set to awsuser.

When creating a Redshift cluster, you should change the default admin username to a unique value. Default usernames are public knowledge and should be changed upon configuration. Changing the default usernames reduces the risk of unintended access.

Remediation

You can't change the admin username for your Amazon Redshift cluster after creating it. To create a new cluster with a non-default username, see Step 1: Create a sample Amazon Redshift cluster in the Amazon Redshift Getting Started Guide.

[Redshift.9] Redshift clusters should not use the default database name

Related requirements: NIST.800-53.r5 CA-9(1), NIST.800-53.r5 CM-2

Category: Identify > Resource Configuration

Severity: Medium

Resource type: AWS::Redshift::Cluster

AWS Config rule: redshift-default-db-name-check

Schedule type: Change triggered

Parameters: None

This control checks whether an Amazon Redshift cluster has changed the database name from its default value. The control will fail if the database name for a Redshift cluster is set to dev.

When creating a Redshift cluster, you should change the default database name to a unique value. Default names are public knowledge and should be changed upon configuration. As an example, a well-known name could lead to inadvertent access if it was used in IAM policy conditions.

Remediation

You can't change the database name for your Amazon Redshift cluster after it is created. For instructions on creating a new cluster, see Getting started with Amazon Redshift in the Amazon Redshift Getting Started Guide.

[Redshift.10] Redshift clusters should be encrypted at rest

Related requirements: NIST.800-53.r5 CA-9(1), NIST.800-53.r5 CM-3(6), NIST.800-53.r5 SC-13, NIST.800-53.r5 SC-28, NIST.800-53.r5 SC-28(1), NIST.800-53.r5 SI-7(6)

Category: Protect > Data Protection > Encryption of data-at-rest

Severity: Medium

Resource type: AWS::Redshift::Cluster

AWS Config rule: redshift-cluster-kms-enabled

Schedule type: Change triggered

Parameters: None

This control checks if Amazon Redshift clusters are encrypted at rest. The control fails if a Redshift cluster isn't encrypted at rest or if the encryption key is different from the provided key in the rule parameter.

In Amazon Redshift, you can turn on database encryption for your clusters to help protect data at rest. When you turn on encryption for a cluster, the data blocks and system metadata are encrypted for the cluster and its snapshots. Encryption of data at rest is a recommended best practice because it adds a layer of access management to your data. Encrypting Redshift clusters at rest reduces the risk that an unauthorized user can access the data stored on disk.

Remediation

To modify a Redshift cluster to use KMS encryption, see Changing cluster encryption in the Amazon Redshift Management Guide.

[Redshift.11] Redshift clusters should be tagged

Category: Identify > Inventory > Tagging

Severity: Low

Resource type: AWS::Redshift::Cluster

AWS Config rule: tagged-redshift-cluster (custom Security Hub rule)

Schedule type: Change triggered

Parameters:

Parameter Description Type Allowed custom values Security Hub default value
requiredTagKeys List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive. StringList List of tags that meet AWS requirements No default value

This control checks whether an Amazon Redshift cluster has tags with the specific keys defined in the parameter requiredTagKeys. The control fails if the cluster doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter requiredTagKeys. If the parameter requiredTagKeys isn't provided, the control only checks for the existence of a tag key and fails if the cluster isn't tagged with any key. System tags, which are automatically applied and begin with aws:, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see What is ABAC for AWS? in the IAM User Guide.

Note

Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see Tagging your AWS resources in the AWS General Reference.

Remediation

To add tags to a Redshift cluster, see Tagging resources in Amazon Redshift in the Amazon Redshift Management Guide.

[Redshift.12] Redshift event notification subscriptions should be tagged

Category: Identify > Inventory > Tagging

Severity: Low

Resource type: AWS::Redshift::EventSubscription

AWS Config rule: tagged-redshift-eventsubscription (custom Security Hub rule)

Schedule type: Change triggered

Parameters:

Parameter Description Type Allowed custom values Security Hub default value
requiredTagKeys List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive. StringList List of tags that meet AWS requirements No default value

This control checks whether an Amazon Redshift cluster snapshot has tags with the specific keys defined in the parameter requiredTagKeys. The control fails if the cluster snapshot doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter requiredTagKeys. If the parameter requiredTagKeys isn't provided, the control only checks for the existence of a tag key and fails if the cluster snapshot isn't tagged with any key. System tags, which are automatically applied and begin with aws:, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see What is ABAC for AWS? in the IAM User Guide.

Note

Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see Tagging your AWS resources in the AWS General Reference.

Remediation

To add tags to a Redshift event notification subscription, see Tagging resources in Amazon Redshift in the Amazon Redshift Management Guide.

[Redshift.13] Redshift cluster snapshots should be tagged

Category: Identify > Inventory > Tagging

Severity: Low

Resource type: AWS::Redshift::ClusterSnapshot

AWS Config rule: tagged-redshift-clustersnapshot (custom Security Hub rule)

Schedule type: Change triggered

Parameters:

Parameter Description Type Allowed custom values Security Hub default value
requiredTagKeys List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive. StringList List of tags that meet AWS requirements No default value

This control checks whether an Amazon Redshift cluster snapshot has tags with the specific keys defined in the parameter requiredTagKeys. The control fails if the cluster snapshot doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter requiredTagKeys. If the parameter requiredTagKeys isn't provided, the control only checks for the existence of a tag key and fails if the cluster snapshot isn't tagged with any key. System tags, which are automatically applied and begin with aws:, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see What is ABAC for AWS? in the IAM User Guide.

Note

Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see Tagging your AWS resources in the AWS General Reference.

Remediation

To add tags to a Redshift cluster snapshot, see Tagging resources in Amazon Redshift in the Amazon Redshift Management Guide.

[Redshift.14] Redshift cluster subnet groups should be tagged

Category: Identify > Inventory > Tagging

Severity: Low

Resource type: AWS::Redshift::ClusterSubnetGroup

AWS Config rule: tagged-redshift-clustersubnetgroup (custom Security Hub rule)

Schedule type: Change triggered

Parameters:

Parameter Description Type Allowed custom values Security Hub default value
requiredTagKeys List of non-system tag keys that the evaluated resource must contain. Tag keys are case sensitive. StringList List of tags that meet AWS requirements No default value

This control checks whether an Amazon Redshift cluster subnet group has tags with the specific keys defined in the parameter requiredTagKeys. The control fails if the cluster subnet group doesn’t have any tag keys or if it doesn’t have all the keys specified in the parameter requiredTagKeys. If the parameter requiredTagKeys isn't provided, the control only checks for the existence of a tag key and fails if the cluster subnet group isn't tagged with any key. System tags, which are automatically applied and begin with aws:, are ignored.

A tag is a label that you assign to an AWS resource, and it consists of a key and an optional value. You can create tags to categorize resources by purpose, owner, environment, or other criteria. Tags can help you identify, organize, search for, and filter resources. Tagging also helps you track accountable resource owners for actions and notifications. When you use tagging, you can implement attribute-based access control (ABAC) as an authorization strategy, which defines permissions based on tags. You can attach tags to IAM entities (users or roles) and to AWS resources. You can create a single ABAC policy or a separate set of policies for your IAM principals. You can design these ABAC policies to allow operations when the principal's tag matches the resource tag. For more information, see What is ABAC for AWS? in the IAM User Guide.

Note

Don’t add personally identifiable information (PII) or other confidential or sensitive information in tags. Tags are accessible to many AWS services, including AWS Billing. For more tagging best practices, see Tagging your AWS resources in the AWS General Reference.

Remediation

To add tags to a Redshift cluster subnet group, see Tagging resources in Amazon Redshift in the Amazon Redshift Management Guide.

[Redshift.15] Redshift security groups should allow ingress on the cluster port only from restricted origins

Related requirements: PCI DSS v4.0.1/1.3.1

Category: Protect > Secure network configuration > Security group configuration

Severity: High

Resource type: AWS::Redshift::Cluster

AWS Config rule: redshift-unrestricted-port-access

Schedule type: Periodic

Parameters: None

This control checks whether a security group associated with an Amazon Redshift cluster has ingress rules that permit access to the cluster port from the internet (0.0.0.0/0 or ::/0). The control fails if the security group ingress rules permit access to the cluster port from the internet.

Permitting unrestricted inbound access to the Redshift cluster port (IP address with a /0 suffix) can result in unauthorized access or security incidents. We recommend applying the principal of least privilege access when creating security groups and configuring inbound rules.

Remediation

To restrict ingress on the Redshift cluster port to restricted origins, see Work with security group rules in the Amazon VPC User Guide. Update rules where the port range matches the Redshift cluster port and the IP port range is 0.0.0.0/0.

[Redshift.16] Redshift cluster subnet groups should have subnets from multiple Availability Zones

Category: Recover > Resilience > High availability

Severity: Medium

Resource type: AWS::Redshift::ClusterSubnetGroup

AWS Config rule: redshift-cluster-subnet-group-multi-az

Schedule type: Change triggered

Parameters: None

The control checks whether an Amazon Redshift cluster subnet group has subnets from more than one Availability Zone (AZ). The control fails if the cluster subnet group doesn't have subnets from at least two different AZs.

Configuring subnets across multiple AZs help ensure that your Redshift data warehouse can continue operating even when failure events occur.

Remediation

To modify a Redshift cluster subnet group to span multiple AZs, see Modifying a cluster subnet group in the Amazon Redshift Management Guide.