Bezpieczeństwo RDS: szyfrowanie i grupy parametrów

RDS obsługuje szyfrowanie danych w spoczynku za pomocą AWS Key Management Service (KMS). Po włączeniu szyfrowania podczas tworzenia instancji DB wszystkie dane na bazowych woluminach EBS, automatyczne kopie zapasowe, migawki i repliki odczytu są szyfrowane przy użyciu określonego klucza KMS.

Szyfrowanie musi zostać włączone podczas tworzenia — istniejącej nieszyfrowanej instancji nie można zaszyfrować w miejscu. Obejściem jest wykonanie nieszyfrowanej migawki, skopiowanie jej z włączonym szyfrowaniem i przywrócenie danych z zaszyfrowanej migawki. Klucz KMS może być kluczem zarządzanym przez AWS lub kluczem zarządzanym przez klienta (CMK), zapewniającym dodatkową kontrolę i możliwość audytu.

Ponieważ nie można włączyć szyfrowania dla istniejącej instancji, należy wykonać następującą migrację:

1. Utworzyć ręczny snapshot nieszyfrowanej instancji
2. Skopiować snapshot i włączyć szyfrowanie podczas kopiowania, określając klucz KMS
3. Odtworzyć nową instancję DB z zaszyfrowanego snapshotu
4. Zaktualizować punkt końcowy aplikacji, aby wskazywał nową instancję
5. Usunąć starą, nieszyfrowaną instancję

Takie podejście wiąże się z pewnym przestojem, chyba że użyją Państwo DMS do utrzymywania synchronizacji nowej zaszyfrowanej instancji przed przełączeniem.

RDS szyfruje dane przesyłane za pomocą SSL/TLS. Każdy silnik udostępnia certyfikat CA do pobrania, którego sterownik klienta używa do weryfikowania tożsamości serwera. Aby wymusić połączenia SSL, należy skonfigurować silnik bazy danych tak, aby odrzucał nieszyfrowane połączenia.

W przypadku MySQL należy ustawić parametr require_secure_transport = ON w grupie parametrów. W przypadku PostgreSQL należy ustawić ssl = 1 oraz opcjonalnie rds.force_ssl = 1, aby całkowicie odrzucać połączenia inne niż SSL. Wiele sterowników baz danych dla języków Java i Python obsługuje również parametr ciągu połączenia sslmode=require.

Grupy parametrów to nazwane zbiory ustawień konfiguracyjnych silnika, które dołącza się do instancji RDS. Są odpowiednikiem edytowania pliku my.cnf w MySQL lub postgresql.conf w PostgreSQL, ale są zarządzane przez AWS i mają wersje odpowiadające rodzinom silników.

AWS udostępnia domyślną grupę parametrów dla każdej wersji silnika, ale jej ustawień nie można edytować. Aby dostosować parametry, należy utworzyć niestandardową grupę parametrów, zmodyfikować wybrane parametry i powiązać ją z instancją DB. Zmiany parametrów statycznych wymagają ponownego uruchomienia, natomiast parametry dynamiczne zaczynają obowiązywać natychmiast.

Po utworzeniu niestandardowej grupy parametrów można modyfikować poszczególne parametry za pomocą polecenia CLI modify-db-parameter-group lub konsoli. Parametry mają metodę zastosowania: immediate (zaczyna obowiązywać bez ponownego uruchomienia) albo pending-reboot (zaczyna obowiązywać dopiero po następnym ponownym uruchomieniu instancji).

Ważne parametry, które należy znać na egzamin: max_connections (limit jednoczesnych połączeń), innodb_buffer_pool_size (rozmiar pamięci podręcznej MySQL), log_bin_trust_function_creators (zezwala na funkcje składowane zapisujące do dziennika binarnego) oraz rds.force_ssl (wymusza SSL dla PostgreSQL).

Grupy opcji są podobne do grup parametrów, ale służą do kontrolowania dodatkowych funkcji silnika bazy danych, a nie do dostrajania konfiguracji. Są używane przede wszystkim z Oracle i SQL Server do włączania funkcji takich jak Oracle Application Express (APEX), Transparent Data Encryption (TDE) w SQL Server lub uwierzytelnianie SQL Server za pomocą Active Directory.

Każda opcja w grupie opcji może mieć własne ustawienia. Grupy opcji mają wersje odpowiadające rodzinom silników i muszą być powiązane z instancją DB. Większość silników open source (MySQL, PostgreSQL, MariaDB) rzadko wymaga niestandardowych grup opcji.

RDS obsługuje uwierzytelnianie baz danych za pomocą IAM dla silników MySQL i PostgreSQL. Zamiast stałej nazwy użytkownika i hasła aplikacja przyjmuje rolę IAM i generuje tymczasowy token uwierzytelniający (ważny przez 15 minut) za pomocą polecenia AWS CLI generate-db-auth-token lub wywołania SDK.

Korzyści obejmują brak długoterminowych haseł do bazy danych, automatyczną rotację poświadczeń za pomocą zasad IAM oraz scentralizowaną kontrolę dostępu. Ta funkcja wymaga włączenia opcji --enable-iam-database-authentication w instancji oraz utworzenia użytkownika bazy danych powiązanego z rolą IAM.

AWS Secrets Manager może przechowywać i automatycznie rotować hasło główne RDS oraz poświadczenia aplikacji. Po włączeniu rotacji Secrets Manager wywołuje funkcję Lambda, która aktualizuje hasło w bazie danych i zapisuje nową wartość w sekrecie — aplikacja pobiera najnowszą wartość sekretu za pośrednictwem interfejsu API Secrets Manager, dzięki czemu zawsze ma prawidłowe poświadczenia.

Podczas tworzenia instancji RDS w konsoli można włączyć zarządzanie poświadczeniami głównymi przez Secrets Manager. Eliminuje to zakodowane na stałe hasła w kodzie lub zmiennych środowiskowych.

Instancje RDS działają wewnątrz VPC i używają grup podsieci DB do określania, w których podsieciach (w wielu strefach AZ) można umieścić instancję. Zgodnie z najlepszymi praktykami RDS należy umieszczać w prywatnych podsieciach bez bezpośredniego dostępu do Internetu.

Grupy zabezpieczeń określają, które adresy IP i inne grupy zabezpieczeń mogą łączyć się z portem DB (np. TCP 3306 dla MySQL). Grupą zabezpieczeń warstwy aplikacji należy ustawić jako jedyne dozwolone źródło w grupie zabezpieczeń RDS, egzekwując zasadę najmniejszych uprawnień na poziomie sieci. Nigdy nie należy konfigurować reguły przychodzącej 0.0.0.0/0 (cały ruch) w grupie zabezpieczeń RDS.

Enhanced Monitoring publikuje metryki na poziomie systemu operacyjnego (CPU, pamięć, system plików, operacje wejścia/wyjścia dysku) w CloudWatch Logs co 1–60 sekund, zapewniając większą szczegółowość niż domyślne 60-sekundowe metryki CloudWatch. Korzysta z agenta działającego na hoście DB i jest dostępne dla wszystkich silników z wyjątkiem trybu dublowania SQL Server.

Dzienniki audytu bazy danych (dziennik zapytań ogólnych i dziennik powolnych zapytań dla MySQL; pgaudit dla PostgreSQL) można publikować w CloudWatch Logs na potrzeby analizy zgodności. Należy włączyć je za pomocą grup parametrów, a następnie skonfigurować eksport dzienników w konsoli RDS w sekcji Eksport dzienników.

Najważniejsze najlepsze praktyki bezpieczeństwa RDS na egzamin SAA-C03:

• Włączyć szyfrowanie danych w spoczynku za pomocą klucza KMS CMK podczas tworzenia instancji
• Wymusić SSL/TLS podczas przesyłania danych za pomocą ustawień grupy parametrów
• Umieszczać instancje w prywatnych podsieciach z restrykcyjnymi grupami zabezpieczeń
• Używać uwierzytelniania baz danych za pomocą IAM lub Secrets Manager, aby unikać stałych haseł
• Włączyć CloudTrail do rejestrowania wywołań API RDS oraz CloudWatch Logs dla dzienników audytu bazy danych
• Używać reguł AWS Config (np. rds-instance-public-access-check) do wykrywania błędnych konfiguracji

W tej lekcji dowiedzieli się Państwo, że: szyfrowanie danych RDS w spoczynku korzysta z KMS i musi zostać włączone podczas tworzenia instancji, grupy parametrów kontrolują konfigurację silnika, w tym wymuszanie SSL/TLS podczas przesyłania danych, a także że uwierzytelnianie baz danych za pomocą IAM i Secrets Manager eliminują stałe hasła do baz danych. Następnie omówimy tabele i elementy DynamoDB oraz projektowanie kluczy głównych.