AWS Security Hub · EMR
EMR.4: EMR security configs should encrypt in transit
Written and reviewed by Emnode · Last reviewed
What does AWS Security Hub EMR.4 check?
EMR.4 checks whether an EMR security configuration (`AWS::EMR::SecurityConfiguration`) enables encryption in transit. It's change-triggered and reports FAILED when a security configuration exists with in-transit encryption disabled, even if no cluster is currently using that configuration.
Why does EMR.4 matter?
EMR frameworks constantly shuffle data between cluster nodes and between the cluster and the applications talking to it, and by default that traffic moves in clear text across your VPC. In-transit encryption (node-to-node and application TLS) is separate from at-rest, so a cluster can have fully encrypted disks and still expose its shuffle traffic on the wire. It maps to NIST SC-8 (transmission confidentiality) and SC-13.
How do I fix EMR.4?
- Confirm which security configuration is failing and what it's missing.
- Prepare TLS certificates and create a new compliant security configuration (configurations are immutable).
- Cut new clusters over to the compliant configuration and retire the old ones.
- Add a guardrail so non-compliant configurations can't return.
Remediation script · bash
# Find the highest-impact plaintext-permitting stores across engines.
aws rds describe-db-instances \
--query 'DBInstances[].DBInstanceIdentifier' --output text
aws elasticache describe-replication-groups \
--query 'ReplicationGroups[?TransitEncryptionEnabled==`false`].ReplicationGroupId' \
--output text
# RDS for PostgreSQL: require TLS via rds.force_ssl (static -> needs a reboot).
PG=$(aws rds describe-db-instances --db-instance-identifier prod-orders-pg \
--query 'DBInstances[].DBParameterGroups[].DBParameterGroupName' --output text)
aws rds modify-db-parameter-group --db-parameter-group-name "$PG" \
--parameters 'ParameterName=rds.force_ssl,ParameterValue=1,ApplyMethod=pending-reboot'
aws rds reboot-db-instance --db-instance-identifier prod-orders-pg
# Redshift: require_ssl on a custom cluster parameter group, then reboot.
aws redshift modify-cluster-parameter-group --parameter-group-name analytics-tls \
--parameters ParameterName=require_ssl,ParameterValue=true
aws redshift reboot-cluster --cluster-identifier analytics-prodFull walkthrough (console steps, edge cases and verification) in the lesson Enforce TLS on database and cache connections.
Is EMR.4 a false positive?
Because EMR.4 is change-triggered on AWS::EMR::SecurityConfiguration and not on the clusters, it fails any security configuration with in-transit encryption off even when no cluster currently uses it: an orphaned or superseded configuration left behind after a migration will keep the finding open on its own. There are also legitimately unencrypted-in-transit configurations: a single-node or sandbox cluster where there's no node-to-node shuffle to protect and the application traffic never leaves a trusted private subnet, kept that way to avoid the certificate management and performance overhead TLS adds. Since configurations are immutable, treat these as documented exceptions (set the finding to SUPPRESSED with the configuration name and rationale, or delete the stale configuration) rather than forcing TLS onto a workload that was intentionally scoped without it.