RDS-säkerhet: Kryptering och parametergrupper

RDS krypterar data under överföring med SSL/TLS. Varje engine tillhandahåller ett CA-certifikat som kan laddas ned och som klientens drivrutin använder för att verifiera serverns identitet. Om du vill tvinga fram SSL-anslutningar konfigurerar du databasmotorn så att den avvisar okrypterade anslutningar.

För MySQL anger du parametern require_secure_transport = ON i parametergruppen. För PostgreSQL anger du ssl = 1 och eventuellt rds.force_ssl = 1 för att helt avvisa anslutningar utan SSL. Många databasdrivrutiner för Java och Python stöder också anslutningssträngsparametern sslmode=require.

Parametergrupper är namngivna samlingar med konfigurationsinställningar för en engine som du kopplar till en RDS-instans. De motsvarar att redigera my.cnf i MySQL eller postgresql.conf i PostgreSQL, men hanteras av AWS och versionshanteras per engine-familj.

AWS tillhandahåller en standardparametergrupp för varje engine-version, men inställningarna i den kan inte redigeras. Om du vill anpassa parametrar skapar du en anpassad parametergrupp, ändrar de önskade parametrarna och kopplar den till din DB-instans. Ändringar av statiska parametrar kräver en omstart, medan dynamiska parametrar börjar gälla omedelbart.

När du har skapat en anpassad parametergrupp ändrar du enskilda parametrar med CLI-kommandot modify-db-parameter-group eller i konsolen. Parametrar har en tillämpningsmetod: immediate (börjar gälla utan omstart) eller pending-reboot (börjar endast gälla efter nästa omstart av instansen).

Viktiga parametrar att känna till inför provet: max_connections (begränsar samtidiga anslutningar), innodb_buffer_pool_size (storleken på MySQL:s cache i minnet), log_bin_trust_function_creators (tillåter lagrade funktioner som skriver till binärloggen) och rds.force_ssl (tvingar fram SSL för PostgreSQL).

Option-grupper liknar parametergrupper, men styr tilläggsfunktioner för databasmotorn i stället för konfigurationsoptimering. De används främst med Oracle och SQL Server för att aktivera funktioner som Oracle Application Express (APEX), SQL Server Transparent Data Encryption (TDE) eller SQL Server Active Directory-autentisering.

Varje option i en option-grupp kan ha egna inställningar. Option-grupper versionshanteras per engine-familj och måste kopplas till DB-instansen. De flesta motorer med öppen källkod (MySQL, PostgreSQL, MariaDB) behöver sällan anpassade option-grupper.

RDS stöder IAM-databasutentisering för MySQL- och PostgreSQL-motorer. I stället för ett statiskt användarnamn och lösenord antar applikationen en IAM-roll och genererar en tillfällig autentiseringstoken (giltig i 15 minuter) med AWS CLI-kommandot eller SDK-anropet generate-db-auth-token.

Fördelarna omfattar att inga långlivade databaslösenord behövs, automatisk rotation av autentiseringsuppgifter via IAM-principer och centraliserad åtkomstkontroll. Funktionen kräver att du aktiverar --enable-iam-database-authentication på instansen och skapar en databasanvändare som är kopplad till en IAM-roll.

AWS Secrets Manager kan lagra och automatiskt rotera RDS-huvudlösenordet och applikationens autentiseringsuppgifter. När rotation är aktiverad anropar Secrets Manager en Lambda-funktion som uppdaterar databaslösenordet och lagrar det nya värdet i hemligheten – applikationen hämtar det senaste hemlighetsvärdet via Secrets Manager API, så att den alltid har giltiga autentiseringsuppgifter.

När du skapar en RDS-instans i konsolen kan du välja att låta Secrets Manager hantera huvudautentiseringsuppgifterna. Detta eliminerar hårdkodade lösenord i kod eller miljövariabler.

RDS-instanser körs i en VPC och använder DB-subnätsgrupper för att ange vilka subnät (över flera AZ:er) som instansen kan placeras i. Bästa praxis är att placera RDS i privata subnät utan direktåtkomst till internet.

Säkerhetsgrupper styr vilka IP-adresser och andra säkerhetsgrupper som får nå DB-porten (t.ex. TCP 3306 för MySQL). Applikationslagrets säkerhetsgrupp bör vara den enda tillåtna källan i RDS-säkerhetsgruppen, vilket upprätthåller minsta möjliga behörighet på nätverksnivå. Konfigurera aldrig 0.0.0.0/0 (all trafik) som en inkommande regel i en RDS-säkerhetsgrupp.

Enhanced Monitoring publicerar mätvärden på operativsystemnivå (CPU, minne, filsystem och disk-I/O) till CloudWatch Logs var 1–60:e sekund, vilket ger högre upplösning än standardmätvärdena i CloudWatch, som samlas in var 60:e sekund. Funktionen använder en agent som körs på DB-värden och är tillgänglig för alla motorer utom SQL Server i speglingsläge.

Databasens granskningsloggar (allmän frågelogg och logg över långsamma frågor för MySQL; pgaudit för PostgreSQL) kan publiceras till CloudWatch Logs för efterlevnadsanalys. Aktivera dessa via parametergrupper och konfigurera sedan loggexporterna i RDS-konsolen under Log exports.

Viktiga säkerhetsåtgärder för RDS inför SAA-C03-provet:

• Aktivera kryptering i vila med en KMS CMK när du skapar instansen
• Tvinga fram SSL/TLS under överföring via inställningar i parametergruppen
• Placera instanser i privata subnät med restriktiva säkerhetsgrupper
• Använd IAM-databasutentisering eller Secrets Manager för att undvika statiska lösenord
• Aktivera CloudTrail för att logga RDS API-anrop och CloudWatch Logs för databasens granskningsloggar
• Använd AWS Config-regler (t.ex. rds-instance-public-access-check) för att upptäcka felkonfigurationer

I den här lektionen har du lärt dig att RDS-kryptering i vila använder KMS och måste aktiveras när instansen skapas, att parametergrupper styr motorkonfigurationen, inklusive tillämpning av SSL/TLS under överföring, och att IAM-databasutentisering och Secrets Manager eliminerar statiska databaslösenord. Nästa avsnitt handlar om DynamoDB-tabeller, objekt och utformning av primärnycklar.