Skip to main content
emnode
Compliance Medium severity

AWS Security Hub · DMS

DMS.10: DMS Neptune endpoints should have IAM auth

Written and reviewed by Emnode · Last reviewed

What does AWS Security Hub DMS.10 check?

DMS.10 checks whether a DMS endpoint whose target is an Amazon Neptune database has IAM authorization enabled. The backing AWS Config rule, DMS_NEPTUNE_IAM_AUTHORIZATION_ENABLED, reads the endpoint's IamAuthEnabled flag and marks the endpoint NON_COMPLIANT when IamAuthEnabled is false. Turning IAM auth on is what makes the endpoint authenticate to Neptune through a scoped service role (the role you supply in the ServiceAccessRoleArn parameter) rather than a weaker alternative.

Why does DMS.10 matter?

IAM authorization via a service role gives the endpoint short-lived, auditable, least-privilege access to the Neptune cluster instead of static or broad credentials. Without it, the endpoint's access is harder to scope and rotate. The risk lingers because DMS endpoints are sticky: they cost nothing and often outlive the migration that created them, quietly failing the control long after the replication instance is gone.

How do I fix DMS.10?

  1. Inspect each Neptune target endpoint to confirm whether IamAuthEnabled is set to true.
  2. Create or correct a scoped IAM role that grants the endpoint only the Neptune access it needs.
  3. Enable IAM auth on the endpoint and reference the role through the ServiceAccessRoleArn parameter, then verify the connection with the AWS CLI.
  4. Delete orphaned endpoints left over from completed migrations to clear stale findings.

Remediation script · bash

# Move the highest-impact databases onto IAM authentication first (free, no reboot).
for db in $(aws rds describe-db-instances \
    --query 'DBInstances[?IAMDatabaseAuthenticationEnabled==`false`].DBInstanceIdentifier' \
    --output text); do
  aws rds modify-db-instance --db-instance-identifier "$db" \
    --enable-iam-database-authentication --apply-immediately
  echo "$db: IAM database authentication enabled"
done

# Find every instance still using a default admin username (immutable; needs migration).
aws rds describe-db-instances \
  --query "DBInstances[?contains(['admin','postgres','root','sa','master','mysql','dbadmin'], MasterUsername)].[DBInstanceIdentifier,MasterUsername]" \
  --output table

# Recreate one of those with a non-default master username set explicitly at creation.
aws rds restore-db-cluster-from-snapshot \
  --db-cluster-identifier prod-orders-db-v2 \
  --snapshot-identifier prod-orders-db-pre-rename \
  --engine aurora-postgresql

Full walkthrough (console steps, edge cases and verification) in the lesson Harden database auth, ports and access.

Is DMS.10 a false positive?

The control only evaluates endpoints whose target is Amazon Neptune, so it won't flag your other endpoint types. The catch is the default: IamAuthEnabled is false on a new endpoint, so every Neptune target endpoint fails this control until IAM auth is explicitly turned on; a fresh endpoint failing isn't a misfire, it's the expected starting state. The other common case is a Neptune endpoint left over from a finished migration: it costs nothing, so it lingers and keeps failing even though the work is done. Confirm the endpoint is no longer part of any active migration, then delete it to clear the finding, or if it must be retained for a documented reason, suppress the finding rather than enabling IAM auth on a dormant endpoint.

Part of the learning path Tighten your databases
  • DMS.1 A DMS replication instance is publicly accessible
  • DMS.6 DMS instances auto minor version upgrade
  • DMS.7 DMS target DB tasks should have logging
  • DMS.8 DMS source DB tasks should have logging
  • DMS.9 DMS endpoints should use SSL
  • DMS.11 DMS MongoDB endpoints should have auth
  • DMS.12 DMS Redis endpoints should have TLS
  • DMS.13 DMS replication instances should be Multi-AZ