Amazon Redshift controls
These controls are related to Amazon Redshift resources.
These controls may not be available in all Amazon Web Services Regions. For more information, see Availability of controls by Region.
[Redshift.1] Amazon Redshift clusters should prohibit public access
Related requirements: 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, 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)
Category: Protect > Secure network configuration > Resources not publicly accessible
Severity: Critical
Resource type:
AWS::Redshift::Cluster
Amazon 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)
Category: Protect > Data Protection > Encryption of data-in-transit
Severity: Medium
Resource type:
AWS::Redshift::Cluster AWS::Redshift::ClusterParameterGroup
Amazon 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
Amazon Config rule:
redshift-backup-enabled
Schedule type: Change triggered
Parameters:
| Parameter | Description | Type | Allowed custom values | Security Hub default value |
|---|---|---|---|---|
|
|
Minimum snapshot retention period in days |
Integer |
|
|
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)
Category: Identify > Logging
Severity: Medium
Resource type:
AWS::Redshift::Cluster
Amazon 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
Amazon 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 Amazon CLI, use the Amazon Redshift modify-cluster command
to set the --allow-version-upgrade attribute.
aws redshift modify-cluster --cluster-identifierclustername--allow-version-upgrade
Where clustername
[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
Amazon 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
Amazon 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 it is created. To create a new cluster, follow the instructions here.
[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
Amazon 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
Amazon 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
Amazon 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 Amazon 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 Amazon 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 Amazon 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 Amazon? 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 Amazon Web Services, including Amazon Billing. For more tagging best practices, see Tagging your Amazon resources in the Amazon Web Services 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
Amazon 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 Amazon 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 Amazon 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 Amazon 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 Amazon? 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 Amazon Web Services, including Amazon Billing. For more tagging best practices, see Tagging your Amazon resources in the Amazon Web Services 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
Amazon 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 Amazon 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 Amazon 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 Amazon 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 Amazon? 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 Amazon Web Services, including Amazon Billing. For more tagging best practices, see Tagging your Amazon resources in the Amazon Web Services 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
Amazon 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 Amazon 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 Amazon 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 Amazon 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 Amazon? 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 Amazon Web Services, including Amazon Billing. For more tagging best practices, see Tagging your Amazon resources in the Amazon Web Services 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
Category: Protect > Secure network configuration > Security group configuration
Severity: High
Resource type:
AWS::Redshift::Cluster
Amazon 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.