RDS-sikkerhed: Kryptering og parametergrupper

RDS krypterer data under overførsel ved hjælp af SSL/TLS. Hver motor leverer et CA-certifikat, der kan downloades, og som din klientdriver bruger til at bekræfte serverens identitet. Hvis du vil gennemtvinge SSL-forbindelser, skal du konfigurere databasemotoren til at afvise ukrypterede forbindelser.

I MySQL skal du angive parameteren require_secure_transport = ON i parametergruppen. I PostgreSQL skal du angive ssl = 1 og eventuelt rds.force_ssl = 1 for helt at afvise forbindelser uden SSL. Mange Java- og Python-databasedrivere accepterer også forbindelsesstrengparameteren sslmode=require.

Parametergrupper er navngivne samlinger af konfigurationsindstillinger for en motor, som du knytter til en RDS-instans. De svarer i RDS til at redigere my.cnf i MySQL eller postgresql.conf i PostgreSQL, men administreres af AWS og versionsstyres pr. motorfamilie.

AWS leverer en standardparametergruppe til hver motorversion, men indstillingerne i den kan ikke redigeres. Hvis du vil tilpasse parametre, skal du oprette en brugerdefineret parametergruppe, ændre de ønskede parametre og knytte den til din DB-instans. Ændringer af statiske parametre kræver en genstart, mens dynamiske parametre træder i kraft med det samme.

Når du har oprettet en brugerdefineret parametergruppe, kan du ændre individuelle parametre ved hjælp af CLI-kommandoen modify-db-parameter-group eller konsollen. Parametre har en anvendelsesmetode: immediate (træder i kraft uden genstart) eller pending-reboot (træder først i kraft efter næste genstart af instansen).

Vigtige parametre, du bør kende til eksamen: max_connections (begrænser samtidige forbindelser), innodb_buffer_pool_size (størrelsen på MySQLs cache i hukommelsen), log_bin_trust_function_creators (tillader lagrede funktioner, der skriver til den binære log), og rds.force_ssl (tvinger SSL for PostgreSQL).

Optiongrupper minder om parametergrupper, men styrer tilføjelsesfunktioner til databasemotoren i stedet for at finjustere konfigurationen. De bruges primært sammen med Oracle og SQL Server til at aktivere funktioner som Oracle Application Express (APEX), SQL Server Transparent Data Encryption (TDE) eller SQL Server-godkendelse med Active Directory.

Hver option i en optiongruppe kan have sine egne indstillinger. Optiongrupper versionsstyres pr. motorfamilie og skal knyttes til DB-instansen. De fleste open source-motorer (MySQL, PostgreSQL, MariaDB) har sjældent brug for brugerdefinerede optiongrupper.

RDS understøtter IAM-databasegodkendelse for MySQL- og PostgreSQL-motorer. I stedet for et statisk brugernavn og en statisk adgangskode antager din applikation en IAM-rolle og genererer et midlertidigt godkendelsestoken (gyldigt i 15 minutter) ved hjælp af AWS CLI-kommandoen generate-db-auth-token eller et SDK-kald.

Fordelene omfatter ingen langtidsgyldige databaseadgangskoder, automatisk rotation af legitimationsoplysninger via IAM-politikker og centraliseret adgangskontrol. Funktionen kræver, at du aktiverer --enable-iam-database-authentication på instansen og opretter en databasebruger, der er knyttet til en IAM-rolle.

AWS Secrets Manager kan gemme og automatisk rotere din RDS-masteradgangskode og applikationens legitimationsoplysninger. Når rotation er aktiveret, kalder Secrets Manager en Lambda-funktion, som opdaterer databaseadgangskoden og gemmer den nye værdi i hemmeligheden—din applikation henter den seneste hemmelighedsværdi via Secrets Manager API'et, så den altid har gyldige legitimationsoplysninger.

Når du opretter en RDS-instans i konsollen, kan du tilvælge, at Secrets Manager administrerer masterlegitimationsoplysningerne. Det fjerner hardcodede adgangskoder fra kode og miljøvariabler.

RDS-instanser kører i en VPC og bruger DB-undernetgrupper til at angive, hvilke undernet (på tværs af flere AZ'er) instansen kan placeres i. Det er best practice at placere RDS i private undernet uden direkte internetadgang.

Sikkerhedsgrupper styrer, hvilke IP-adresser og andre sikkerhedsgrupper der kan nå DB-porten (f.eks. TCP 3306 for MySQL). Applikationslagets sikkerhedsgruppe bør være den eneste tilladte kilde i RDS-sikkerhedsgruppen, så netværksbaserede mindste privilegier håndhæves. Konfigurér aldrig 0.0.0.0/0 (al trafik) som en indgående regel i en RDS-sikkerhedsgruppe.

Enhanced Monitoring publicerer målinger på operativsystemniveau (CPU, hukommelse, filsystem, disk-I/O) til CloudWatch Logs hvert 1.–60. sekund, hvilket giver en finere granularitet end standardmålingerne i CloudWatch, der foretages hvert 60. sekund. Funktionen bruger en agent, der kører på DB-værten, og er tilgængelig for alle motorer undtagen SQL Server i spejlingstilstand.

Revisionslogge for databasen (generel forespørgselslog og log over langsomme forespørgsler for MySQL; pgaudit for PostgreSQL) kan publiceres til CloudWatch Logs til analyse af overholdelse af krav. Aktivér disse via parametergrupper, og konfigurér derefter logeksporten i RDS-konsollen under Logeksport.

Vigtige bedste sikkerhedspraksisser for RDS til SAA-C03-eksamen:

• Aktivér kryptering i hvile med en KMS CMK, når du opretter instansen
• Gennemtving SSL/TLS under overførsel via indstillinger i parametergruppen
• Placér instanser i private undernet med begrænsende sikkerhedsgrupper
• Brug IAM-databasegodkendelse eller Secrets Manager for at undgå statiske adgangskoder
• Aktivér CloudTrail for at logge RDS API-kald og CloudWatch Logs til revisionslogge for databasen
• Brug AWS Config-regler (f.eks. rds-instance-public-access-check) til at opdage fejlkonfigurationer

I denne lektion har du lært, at RDS-kryptering i hvile bruger KMS og skal aktiveres ved oprettelsen, at parametergrupper styrer motorkonfigurationen, herunder håndhævelse af SSL/TLS under overførsel, og at IAM-databasegodkendelse og Secrets Manager eliminerer statiske databaseadgangskoder. Næste gang ser vi på DynamoDB-tabeller, elementer og design af primærnøgler.