Ref: https://learn.cantrill.io/courses/1820301/lectures/41301427

• Summary:
• Contents:

RDS Encryption

RDS Encryption in Transit

• 💡 In other words: RDS data encrypted/protected while transferred between RDS & clients
• SSL/TLS available
  • Can be set to mandatory on a per user basis

RDS Encryption at Rest

• 💡 In other words: RDS data encrypted/protected when written to disk
• Two options:
  1. EBS volume encryption with KMS
     • Default
     • Handled by Host & underlying EBS-based storage
       • KMS generates DEKs from AWS-managed or customer-managed KEK/CMK
       • DEKs loaded on hosts as required, used for encryption/decryption operations
     • ‼️ This encryption can not be removed once it's added!
     • Opaque to DB engine (DB engine has no encryption awareness)
       • As far as DB engine is aware, it's storing unencrypted data
       • 👍 Advantage: no need for DB engine to natively support encryption/decryption
  2. Transparent Data Encryption (TDE)
     • Native DB engine encryption, available for some DB engines
       • Supported by RDS MSSQL & RDS Oracle
     • Handled within the DB engine
       • Data encrypted by DB engine before being written to disk
       • 👍 Advantage: Opaque to RDS instance host → less trust
     • RDS Oracle supports AWS CloudHSM integration
       • Even more secure, with much stronger key controls
       • CloudHSM secured by customer
         • AWS has no key exposure → Data secure even from AWS
       • 👍 Meets very demanding regulatory situations (AWS is not in the trust chain)

• ‼️ If an RDS instance is encrypted, its equivalent data in replicas and snapshots is encrypted with the exact same configuration as the RDS instance
  • If KMS encryption → replicas, logs and snapshots use the same DEKs and KEKs/CMKs

RDS Authentication and Authorization

• 💡 Reminder: authentication refers to how users can log in to RDS; authorization refers to how access is controlled inside RDS

• Normally, logins to RDS done via local DB users
  • A local DB user has credentials (username & password)
  • Upon provisioning of an RDS instance, at least one local DB user created (e.g. admin)
  • ‼️ Local DB users ≠ IAM users!
    • Local DB users are controlled by the DB engine, NOT by AWS!
• Alternative: configure IAM user authentication against a DB (DB login via IAM)
  1. RDS local DB user is configured to use AWS authentication tokens
  2. IAM policy attached to an IAM identity (user or role) maps the identity to a local DB user
  3. IAM identity can run the generate-db-auth-token operation
     • Token valid for 15 mins
     • Token allows access to RDS for IAM identity without needing a password
  • ‼️ IAM can only be used for RDS authentication, NOT for RDS authorization!!
    • Authorization is controlled internally by the DB engine!
    • DB engine assigns permissions to each local DB user