Kontrola branż wysoce regulowanych przy użyciu Amazon Aurora PostgreSQL

Klienci z branży usług finansowych (FSI) i inne silnie regulowane branże często muszą kontrolować każde działanie wykonane przez każdego użytkownika i administratora bazy danych, a także identyfikować każdą osobę zalogowaną do ich baz danych, zwykle przy użyciu dostawcy tożsamości (IdP). W takich przypadkach IdP jest uważany za źródło prawdy do mapowania użytkowników.

Bezpieczeństwo jest najwyższym priorytetem. Dlatego twórcy uważnie słuchają swoich klientów, aby oferować zarówno bezpieczne środowisko przetwarzania w chmurze, jak i innowacyjne usługi bezpieczeństwa, które zostały zaprojektowane w celu zaspokojenia potrzeb najbardziej wrażliwych na ryzyko organizacji.

W tym artykule autorzy przedstawią proaktywne rozwiązanie powszechnego wyzwania związanego z bezpieczeństwem w wysoce regulowanych branżach i opiszą, jak zastosować najlepsze praktyki bezpieczeństwa w zakresie audytu i monitorowania działań użytkowników na danych przechowywanych w Amazon Aurora PostgreSQL-Compatible Edition.

Zarys rozwiązania

Rozwiązanie wykorzystuje następujące usługi i funkcje AWS:

• Amazon Aurora Database Activity Streams – używane do monitorowania i audytu działań użytkowników;
• AWS Identity and Access Management (IAM) – zintegrowane z IdP klienta w celu uwierzytelniania użytkowników przed Aurora;
• AWS Security Token Service – AWS STS umożliwia żądanie tymczasowych poświadczeń o ograniczonych uprawnieniach dla użytkowników AWS Identity and Access Management (IAM) lub dla użytkowników, których uwierzytelniasz (użytkownicy federacyjni);
• Security Assertion Markup Language – wykorzystanie tagów asercji SAML do łączenia każdego uwierzytelnionego użytkownika bazy danych z powiązanym użytkownikiem IdP;
• AWS Single Sign-On – dzięki AWS SSO możesz tworzyć tożsamości użytkowników i zarządzać nimi w magazynie tożsamości AWS SSO;
• AWS Key Management Service (AWS KMS) – AWS KMS ułatwia tworzenie kluczy kryptograficznych i zarządzanie nimi oraz kontrolowanie ich użycia w szerokim zakresie usług AWS i w aplikacjach.

Aurora zapewnia trzy metodologie uwierzytelniania:

• Uwierzytelnianie hasłem;
• Uwierzytelnianie Kerberos;
• Uwierzytelnianie bazy danych IAM.

Rozwiązanie przedstawione w tym artykule wykorzystuje uwierzytelnianie IAM. Dzięki tej metodzie nie musisz przechowywać poświadczeń użytkownika w bazie danych i możesz połączyć się z bazą danych przy użyciu tymczasowego tokena uwierzytelniania. Token uwierzytelniający to unikalny ciąg znaków generowany na żądanie z wywołania API Amazon Relational Database Service (Amazon RDS).

Tokeny uwierzytelniania są generowane przy użyciu AWS Signature w wersji 4. Każdy token ma 15-minutowy czas życia.

Rozwiązanie oferuje następujące korzyści:

• Ruch sieciowy do oraz z bazy danych jest szyfrowany przy użyciu protokołu Secure Socket Layer (SSL) lub Transport Layer Security (TLS). Aby uzyskać więcej informacji na temat używania SSL i TLS z Aurora, zobacz Używanie SSL/TLS do szyfrowania połączenia z klastrem DB;
• Za pomocą IAM można centralnie zarządzać dostępem do zasobów bazy danych, zamiast zarządzać dostępem indywidualnie w każdym klastrze baz danych;
• W przypadku aplikacji działających w chmurze Amazon Elastic Compute Cloud (Amazon EC2) można użyć poświadczeń profilu specyficznych dla instancji EC2, aby uzyskać dostęp do bazy danych zamiast hasła, aby zapewnić większe bezpieczeństwo;
• Uwierzytelnianie bazy danych IAM jest dostępne zarówno dla baz danych Amazon Aurora MySQL-Compatible Edition, jak i Aurora PostgreSQL.

Ponadto w ramach proponowanego rozwiązania IAM jest zintegrowany z IdP klienta. Dzięki temu użytkownicy klienta, uwierzytelnieni już przed IdP, mogą pomyślnie zalogować się do bazy danych. Jest to kluczowy punkt rozwiązania, ponieważ pozwala na łączenie działań jednoznacznie rejestrowanych przez strumienie aktywności bazy danych Aurora z użytkownikami IdP, które są ostatecznie jednoznacznie powiązane z osobami.

Następujące podmioty powiązane z użytkownikami są domyślnie niepowiązane ze sobą z technicznego punktu widzenia:

• Użytkownicy IdP – IdP jest zwykle przyjmowany przez firmy jako źródło prawdy dla użytkowników IT i ich relacji z osobami fizycznymi;
• Role uprawnień (IAM) – są to role uprawnień przyjmowane przez użytkowników po przejściu do AWS. Powiązane z nimi uprawnienia pozwalają im uzyskać tymczasowy token do logowania do bazy danych Aurora;
• Użytkownicy bazy danych – są to użytkownicy bazy danych zdefiniowani w bazie danych Aurora.

Ta logiczna separacja między tymi użytkownikami, zdefiniowana na różnych poziomach architektury (IdP, IAM, baza danych), reprezentuje punkty przerwane w łańcuchu działań, które należy skorelować, aby określić, zaczynając od dziennika audytu, kto wykonał działania w bazie danych.

Kluczowym punktem rozwiązania jest połączenie trzech podmiotów poprzez wykorzystanie natywnej integracji zaangażowanych usług, aby upewnić się, że użytkownik IdP rozpoczynający łańcuch jest jednoznacznie połączony z użytkownikiem bazy danych.

Dzięki temu akcje wykonywane wbrew bazie danych i logowane do dzienników kontroli strumieni aktywności bazy danych są jednoznacznie powiązane z użytkownikiem zidentyfikowanym przez dostawcę tożsamości.

Zarys przepływu pracy

Poniższy diagram przedstawia przepływ pracy na wysokim poziomie rozwiązania. Przepływ pracy składa się z dwóch głównych kroków: uwierzytelnienia i audytu.

Przepływ pracy składa się z dwóch głównych etapów: uwierzytelnienia (kroki 1–7) i audytu (kroki 8–9). Każdy użytkownik, który musi uwierzytelnić się w Aurora, wykonuje następujące kroki:

1. Użytkownik loguje się za pomocą korporacyjnego IdP (w tym poście używa się AWS SSO). Ponieważ IdP jest źródłem prawdy, pozwala powiązać użytkownika z osobą.
2. Dostawca tożsamości uwierzytelnia użytkownika i przekierowuje go do usługi AWS Security Token Service (AWS STS).
3. Użytkownik zostaje przekierowany do punktu końcowego AWS STS, przekazując swoje informacje uwierzytelniające w ramach asercji SAML.
4. SAML zapewnia użytkownikowi tymczasowe (ograniczone, zgodnie z jego wymaganiami) poświadczenia uprawnień dla uwierzytelnionych użytkowników IdP do logowania się w usługach AWS.
5. Użytkownik może używać tokena zabezpieczającego do wykonywania wywołań AWS API. W tym przypadku używają one API generate-db-auth-token Amazon RDS, aby uzyskać tymczasowy token do logowania w bazie danych Aurora. Po wygenerowaniu tokena uwierzytelniającego jest on ważny przez 15 minut przed wygaśnięciem. Jeśli spróbujesz nawiązać połączenie przy użyciu wygasłego tokenu, żądanie połączenia zostanie odrzucone (zobacz Łączenie z wystąpieniem bazy danych przy użyciu uwierzytelniania uprawnień, aby uzyskać więcej informacji). Dzięki tokenowi możesz uniknąć zarządzania hasłami użytkowników bazy danych.
6. Amazon RDS API zapewnia tymczasowy token.
7. Użytkownik loguje się do bazy danych Aurora za pomocą tokena tymczasowego.
8. Gdy użytkownik loguje się do bazy danych, jego działania są rejestrowane przez Aurorę w strumieniu w Amazon Kinesis Data Streams. Zobacz Monitorowanie strumieni aktywności bazy danych, aby uzyskać szczegółowe informacje na temat typów działań rejestrowanych przez strumienie aktywności bazy danych Aurora.
9. Możesz monitorować strumień danych. Możesz użyć wielu rozwiązań do tego celu, ten post wykorzystuje niestandardowy skrypt, który używa AWS SDK dla Pythona (Boto3) do pobierania komunikatów ze strumienia lub przekazywania komunikatów strumienia do innych AWS lub usług stron trzecich (takich jak AWS Lambda lub IBM Guardium).

Skonfiguruj integrację dostawcy tożsamości z uprawnieniami

Aby zasymulować rzeczywisty scenariusz, twórcy używają AWS SSO jako dostawcy tożsamości. Proces integracji składa się z następujących etapów wysokiego poziomu:

1. Utwórz zestaw uprawnień.
2. Utwórz użytkownika AWS SSO.
3. Ustaw atrybuty kontroli dostępu.
4. Powiąż użytkownika z polisami uprawnień.
5. Połącz się za pomocą AWS SSO.

Pora przyjrzeć się poszczególnym krokom w bardziej szczegółowy sposób.

Utwórz zestaw uprawnień

Zestaw uprawnień to zbiór zasad zdefiniowanych przez administratora, których AWS SSO używa do określenia uprawnień użytkownika do dostępu do danego konta AWS. Zestawy uprawnień mogą zawierać zasady zarządzane przez AWS lub zasady niestandardowe, które są przechowywane w AWS SSO. Zasady to dokumenty, które działają jako kontenery dla co najmniej jednego oświadczenia o uprawnieniach. Oświadczenia te reprezentują indywidualne kontrole dostępu (zezwalaj lub odmawiaj) dla różnych zadań, które określają, jakie zadania użytkownicy mogą lub nie mogą wykonywać na koncie AWS.

Zestawy uprawnień są przechowywane w AWS SSO i są używane tylko dla kont AWS. Zestawy uprawnień są ostatecznie tworzone jako role uprawnień na danym koncie AWS, z zasadami zaufania, które pozwalają użytkownikom przejąć rolę za pośrednictwem logowania jednokrotnego AWS.

Aby stworzyć zestaw uprawnień, wykonaj następujące kroki:

1. W konsoli AWS SSO wybierz Konta AWS w panelu nawigacyjnym.

2. Wybierz Utwórz polisę uprawnień.

3. Wybierz Utwórz niestandardową polisę uprawnień.

4. W polu Nazwa wpisz dba.

5. Wprowadź następujące niestandardowe zasady:

Polityka określa, że powiązani użytkownicy mogą logować się do bazy danych <DATABASECLUSTER> przy użyciu użytkownika bazy danych, którego nazwa odpowiada polu AWS SSO userName.

6. Wybierz Dalej: Tagi i wykonaj kroki, aby utworzyć polisę uprawnień.

Poniższy zrzut ekranu przedstawia nowy zestaw uprawnień w konsoli AWS SSO.

Tworzenie użytkownika logowania jednokrotnego AWS

Aby utworzyć użytkownika AWS SSO, wykonaj następujące kroki:

1. W konsoli AWS SSO wybierz Użytkownicy w panelu nawigacyjnym.

2. Wybierz Dodaj użytkownika.

3. W sekcji Szczegóły użytkownika wprowadź swoje informacje o użytkowniku.

4. W obszarze Dodaj użytkownika do grup możesz opcjonalnie dodać użytkownika do grupy AWS SSO. W tym poście ten krok został pominięty.

Poniższy zrzut ekranu przedstawia nowego użytkownika wymienionego w konsoli AWS SSO.

Ustaw atrybuty kontroli dostępu

Musisz skonfigurować mapowanie tagów użytkownika logowania jednokrotnego AWS, aby przeszły przez asercję SAML. W tym przypadku należy skonfigurować atrybut userName użytkownika AWS SSO, ponieważ musi zostać porównany z użytkownikiem bazy danych.

1. W konsoli AWS SSO wybierz Ustawienia w panelu nawigacyjnym.

2. Wybierz Włącz obok Atrybuty kontroli dostępu.

3. Wybierz Pokaż szczegóły

4. Dodaj atrybut z kluczem userName i wartością ${path:userName}.

5. Wybierz Zapisz zmiany.

Na stronie Ustawienia pojawi się komunikat, że atrybuty są teraz włączone.

Taka konfiguracja zapewnia, że atrybut „userName” jest mapowany na atrybut asercji SAML „userName”.

Powiąż użytkownika z polisami uprawnień

Musisz powiązać użytkownika lub grupę użytkowników z polisą uprawnień.

1. W konsoli AWS SSO wybierz Konta AWS w panelu nawigacyjnym.

2. Na zakładce Organizacja AWS wybierz Przypisz użytkowników.

3. Na zakładce Użytkownicy wybierz użytkowników do powiązania z określoną polisą uprawnień.

4. Wybierz polisę uprawnień do użycia.

5. Wybierz Zakończ.

Możesz teraz łączyć się za pomocą logowania jednokrotnego AWS.

Połącz się za pomocą AWS SSO

Możesz teraz przejść do strony Dashboard w konsoli AWS SSO i uzyskać dostęp do portalu użytkownika. Użytkownicy mogą również uzyskać dostęp do strony logowania AWS SSO bez konieczności logowania się do konsoli. Aby połączyć się za pomocą AWS SSO, wykonaj następujące kroki:

1. Zaloguj się przy użyciu poświadczeń utworzonego użytkownika.

Do pierwszego logowania użyj linku wysłanego na Twój adres e-mail.

Po zalogowaniu zostaniesz poproszony o podanie listy kont AWS i powiązanych zestawów uprawnień, które są powiązane z Twoim użytkownikiem AWS SSO.

2. Wybierz właściwe konto.

3. Wybierz znacznik, aby rozwinąć szczegóły konta

4. Wybierz Wiersz poleceń lub dostęp programowy, aby uzyskać tymczasowe poświadczenia o ograniczonych uprawnieniach dla usług AWS.

Możesz skopiować poświadczenia i wykonywać wywołania API usług AWS, zgodnie z uprawnieniami skonfigurowanymi w powiązanym zestawie uprawnień.

Czas zalogować się do bazy danych Aurora. Gdy masz dostępny klaster Aurora, kliknij na czarne pole, aby uzyskać tymczasowe poświadczenia, które pozwolą Ci uzyskać token Aurora w celu zalogowania się do bazy danych.

Skonfiguruj integrację Aurora z IAM

Dla każdego użytkownika, który musi zalogować się do bazy danych Aurora przez IAM, musisz wcześniej utworzyć użytkownika w bazie danych bez zapisywania hasła.

Aby użyć uwierzytelniania IAM z Aurora PostgreSQL, wykonaj następujące kroki:

1. Włącz uwierzytelnianie bazy danych IAM w klastrze DB za pomocą interfejsu wiersza poleceń AWS (AWS CLI) w następujący sposób:

aws rds modify-db-cluster --db-cluster-identifier <cluster-identifier> --enable-iam-database-authentication --apply-immediately

Symbol zastępczy <identyfikator-klastra> to nazwa klastra bazy danych. Na przykład używamy następującego kodu:

aws rds modify-db-cluster --db-cluster-identifier aupg-labs-cluster
  --enable-iam-database-authentication --apply-immediately

Możesz także użyć Konsoli Zarządzania AWS (AWS Management Console) lub Amazon RDS API. Aby uzyskać więcej informacji, zobacz Włączanie i wyłączanie uwierzytelniania bazy danych uprawnień.

2. Połącz się z klastrem bazy danych (za pomocą nazwy użytkownika i hasła), utwórz użytkownika z uprawnieniami logowania i przyznaj użytkownikowi dostęp do roli IAM:

CREATE USER <db_user_name> WITH LOGIN; 
GRANT rds_iam TO <db_user_name>;

Jako przykład, użyj poniższego kodu:

CREATE USER arianna WITH LOGIN; 
GRANT rds_iam TO arianna;

Następnie możesz użyć zasady IAM utworzonej w poprzednim kroku, aby uzyskać dostęp do bazy danych przy użyciu uwierzytelniania bazy danych IAM. Aby uzyskać więcej informacji, zobacz Tworzenie i używanie zasad uprawnień dostępu do bazy danych uprawnień.

Uniemożliwiaj użytkownikom bazy danych ustawienie lub zmianę hasła

Rozwiązanie przedstawione w tym artykule zakłada, że wszyscy użytkownicy bazy danych uzyskują dostęp do bazy danych przechodząc przez swojego korporacyjnego IdP i IAM. W tej sekcji pokazano, jak uniemożliwić użytkownikom modyfikowanie haseł w bazie danych i uzyskiwanie bezpośredniego dostępu do bazy danych za pomocą uwierzytelniania SQL.

Możesz ograniczyć uprawnienia do zarządzania hasłami użytkowników bazy danych do specjalnej roli. Zapewnia to większą kontrolę nad zarządzaniem hasłami po stronie klienta.

Włączasz ograniczone zarządzanie hasłami za pomocą statycznego parametru rds.restrict_password_commands i używasz roli o nazwie rds_password. Gdy parametr rds.restrict_password_commands jest ustawiony na 1, tylko użytkownicy należący do roli rds_password mogą uruchamiać określone polecenia SQL. Ograniczone polecenia SQL to polecenia modyfikujące hasła użytkowników bazy danych i czas wygaśnięcia hasła. Uwierzytelnianie IAM jest jedyną realną opcją dostępu do bazy danych, z wyjątkiem głównego użytkownika, który zawsze może uzyskać dostęp do bazy danych przez uwierzytelnianie SQL.

Aby korzystać z ograniczonego zarządzania hasłami, w klastrze bazy danych musi być uruchomiony program Aurora PostgreSQL 10.6 lub nowszy. Ponieważ parametr rds.restrict_password_commands jest statyczny, zmiana tego parametru wymaga ponownego uruchomienia bazy danych.

Gdy baza danych ma włączone ograniczone zarządzanie hasłami, przy próbie uruchomienia ograniczonych poleceń SQL pojawia się następujący błąd: BŁĄD: musi być członkiem s, aby modyfikować hasła.

Poniższe polecenia demonstrują logowanie użytkownika „arianna” do bazy danych i próbę zmiany hasła.

Uwaga: Poniższy kod wymaga uwierzytelnienia w AWS zgodnie z opisem w sekcji „Przetestuj rozwiązanie”.

$ export RDSHOST="XXXYYYZZZ-cluster.cluster-csiunruwl2ci.eu-west-1.rds.amazonaws.com"
$ export PGPASSWORD="$(aws rds generate-db-auth-token --hostname $RDSHOST --port 5432 --region eu-west-1 --username arianna )"

$ psql "host=$RDSHOST port=5432 sslmode=verify-ca sslrootcert=/home/ec2-user/rds-ca-2019-root.pem dbname=mylab user=arianna password=$PGPASSWORD"

mylab=> alter user arianna password 'weakpwd';
ERROR:  must be a member of rds_password to alter passwords

Teraz, gdy utworzyłeś użytkownika bazy danych i skonfigurowałeś go do logowania tylko za pomocą tymczasowego tokena IAM, możesz przypisać użytkownikowi niezbędne uprawnienia i umożliwić audytowi przechwytywanie działań wykonywanych w bazie danych w czasie zbliżonym do rzeczywistego. Pamiętaj, aby przypisać jak najmniej uprawnień, które są faktycznie niezbędne.

Autorzy zalecają również przejrzenie wpisu Working with RDS i Aurora PostgreSQL (część 1 i część 2), aby uzyskać więcej informacji na temat pracy z dziennikami PostgreSQL i „dostroić” różne parametry, aby zdobyć więcej szczegółów aktywności

Kontroluj aktywność bazy danych w bazie danych

Strumienie aktywności bazy danych to technologia bezpieczeństwa bazy danych służąca do monitorowania i analizowania aktywności bazy danych. Strumienie aktywności bazy danych mogą pomóc firmom spełnić wymagania prawne i branżowe.

Strumienie aktywności bazy danych zapewniają strumień aktywności w klastrze bazy danych w czasie zbliżonym do rzeczywistego. Aurora przekazuje działania do strumienia danych Kinesis. Strumień jest tworzony automatycznie. Możesz także skonfigurować usługi AWS, takie jak Amazon Kinesis Data Firehose i AWS Lambda, aby zużywały strumień i przechowywały dane (zobacz How database activity streams work, aby uzyskać więcej informacji).

Po przechwyceniu tych informacji w czasie zbliżonym do rzeczywistego możesz monitorować i blokować te działania za pomocą reguł i alarmów.

Rozwiązanie w tym poście pokazuje, jak przechwytywane są dane dotyczące aktywności bazy danych. Następnie można skorzystać z integracji tej funkcji Aurora z aplikacjami IBM Security Guardium, McAfee Data Center Security Suite oraz Imperva SecureSphere Database Audit and Protection.

Możesz również rozszerzyć to rozwiązanie, wdrażając własne aplikacje konsumenckie w celu integracji przepływów pracy przetwarzania i zdefiniowania niestandardowego kompleksowego rozwiązania.bazy danych.

Skonfiguruj strumień aktywności bazy danych

Strumień aktywności uruchamia się na poziomie klastra bazy danych, aby monitorować aktywność bazy danych dla wszystkich instancji bazy danych klastra. Wszelkie instancje bazy danych dodane do klastra są automatycznie monitorowane. Przed rozpoczęciem upewnij się, że spełniasz wszelkie wymagania wstępne.

Przesyłanie strumieniowe aktywności bazy danych wymaga klucza zarządzanego przez klienta (CMK) przy użyciu AWS KMS. Ten klucz szyfruje klucz, który z kolei szyfruje zarejestrowaną aktywność bazy danych. Aby uzyskać więcej informacji, zobacz Konfigurowanie usługi KMS dla przesyłania strumieniowego aktywności bazy danych.

Uruchom strumień aktywności bazy danych

Możesz wybrać, aby sesja bazy danych obsługiwała zdarzenia dotyczące aktywności bazy danych synchronicznie lub asynchronicznie.

Wybierz CMK inny niż klucz domyślny.

Gdy jest włączony, możesz zobaczyć pod stroną konfiguracji szczegóły strumienia aktywności bazy danych, wraz ze statusem Rozpoczęto.

Przetestuj rozwiązanie

Możesz przetestować mechanizm uwierzytelniania za pomocą rozwiązania opisanego w tym poście i sprawdzić, czy jesteś w stanie połączyć się z bazą danych tylko z nazwą użytkownika powiązaną z Twoim użytkownikiem IdP. W tym przypadku skorzystano ze środowiska AWS Cloud9, w którym ustawiono główne zmienne dla tymczasowego połączenia:

1. Przeprowadź uwierzytelnianie za pośrednictwem logowania jednokrotnego AWS zgodnie z wcześniejszym opisem podczas konfigurowania integracji dostawcy tożsamości z uprawnieniami.

2. Skopiuj tymczasowe poświadczenia do wiersza poleceń AWS Cloud9.

3. Wykonaj połączenie z bazą danych.

$export RDSHOST="XXXYYYZZZ-cluster.cluster-ro-csiunruwl2ci.eu-west-1.rds.amazonaws.com"

$ export PGPASSWORD="$(aws rds generate-db-auth-token --hostname $RDSHOST --port 5432 --region eu-west-1 --username arianna)"

4. Uruchom program terminala interaktywnego PostgreSQL o nazwie psql, który umożliwia interaktywne wprowadzanie, edycję i uruchamianie poleceń SQL, takich jak tworzenie tabeli z dummy:

psql "host=$RDSHOST port=5432 dbname=postgres user=arianna password=$PGPASSWORD"

$ psql "host=$RDSHOST port=5432 sslmode=verify-ca sslrootcert=/ /Downloads/rds-ca-2019-root.pem dbname=postgres user=arianna password=$PGPASSWORD"
psql (13.3, server 11.9)
SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off)
Type "help" for help.


mylab=> CREATE TABLE phonebook(phone VARCHAR(32), firstname VARCHAR(32), lastname VARCHAR(32), address VARCHAR(64));
CREATE TABLE
mylab=> 
mylab=> INSERT INTO phonebook(phone, firstname, lastname, address) VALUES('+1 123 456 7890', 'Paola', 'LoR', 'UK address 12'); 
INSERT 0 1
mylab=> SELECT * FROM phonebook ORDER BY lastname; 
      phone      | firstname | lastname |    address    
-----------------+-----------+----------+---------------
 +1 123 456 7890 | Paola     | LoR      | UK address 12
(1 row)

mylab=> UPDATE phonebook SET address = 'North America', phone = '+1 123 456 7890' WHERE firstname = 'Paola' AND lastname = 'LoR'; 
UPDATE 1
mylab=> DROP TABLE phonebook;
DROP TABLE

Następnie możesz odczytać aktywność ze strumienia aktywności bazy danych.

5. Przejdź do zakładki Konfiguracja klastra Aurora i wybierz łącze do strumienia.

6. Aby pobrać dane ze strumienia danych Kinesis, możesz użyć skryptu takiego jak https://awsauroralabsmy.com/scripts/das_reader.py.

Poniższy zrzut ekranu przedstawia dane wyjściowe skryptu wraz z audytem operacji, które przeprowadziliśmy na klastrze Aurora.

Aby sformatować dane wyjściowe przesyłania strumieniowego aktywności bazy danych i zinterpretować wyniki, możesz użyć edytora z wtyczką JSON lub narzędzia wiersza poleceń, takiego jak jq.

Podsumowanie

W tym artykule pokazano, jak skonfigurować rozwiązanie do spełnienia wymagań audytu baz danych w Aurorze. Zaproponowane rozwiązanie umożliwia wysoce regulowanym klientom konfigurowanie audytu Aurora przy jednoczesnym łączeniu zgłoszonych użytkowników bazy danych z ich zaufanymi użytkownikami IdP. Rozwiązanie wykorzystuje strumienie aktywności bazy danych Aurora do audytu działań użytkowników bazy danych. Łączy ona funkcję uwierzytelniania Aurora IAM z metodologiami federacji tożsamości AWS w celu łączenia zaufanych jednostek użytkownika dostawcy tożsamości z użytkownikami bazy danych Aurora, którzy są zgłaszani do strumieni aktywności bazy danych.

źródło: AWS