AWS - Redshift Enum

Support HackTricks

Amazon Redshift

Redshift to w pełni zarządzana usługa, która może skalować się do ponad petabajta, używana jako hurtownia danych dla rozwiązań big data. Korzystając z klastrów Redshift, możesz przeprowadzać analizy na swoich zbiorach danych za pomocą szybkich narzędzi zapytań opartych na SQL i aplikacji business intelligence, aby uzyskać lepsze zrozumienie wizji dla swojego biznesu.

Redshift oferuje szyfrowanie danych w spoczynku za pomocą czteropoziomowej hierarchii kluczy szyfrowania, używając KMS lub CloudHSM do zarządzania najwyższym poziomem kluczy. Gdy szyfrowanie jest włączone dla twojego klastra, nie można go wyłączyć i odwrotnie. Gdy masz nieszyfrowany klaster, nie można go zaszyfrować.

Szyfrowanie dla twojego klastra może nastąpić tylko podczas jego tworzenia, a po zaszyfrowaniu dane, metadane i wszelkie migawki są również szyfrowane. Poziomy hierarchii kluczy szyfrowania są następujące: poziom pierwszy to klucz główny, poziom drugi to klucz szyfrowania klastra, CEK, poziom trzeci to klucz szyfrowania bazy danych, DEK, a wreszcie poziom czwarty to same klucze szyfrowania danych.

KMS

Podczas tworzenia klastra możesz wybrać domyślny klucz KMS dla Redshift lub wybrać własny CMK, co daje większą elastyczność w kontroli nad kluczem, zwłaszcza z perspektywy audytowalnej.

Domyślny klucz KMS dla Redshift jest automatycznie tworzony przez Redshift przy pierwszym wyborze i użyciu opcji klucza i jest w pełni zarządzany przez AWS.

Ten klucz KMS jest następnie szyfrowany za pomocą klucza głównego CMK, poziom pierwszy. Ten zaszyfrowany klucz danych KMS jest następnie używany jako klucz szyfrowania klastra, CEK, poziom drugi. Ten CEK jest następnie wysyłany przez KMS do Redshift, gdzie jest przechowywany oddzielnie od klastra. Redshift następnie wysyła ten zaszyfrowany CEK do klastra przez bezpieczny kanał, gdzie jest przechowywany w pamięci.

Redshift następnie prosi KMS o odszyfrowanie CEK, poziom drugi. Ten odszyfrowany CEK jest następnie również przechowywany w pamięci. Redshift następnie tworzy losowy klucz szyfrowania bazy danych, DEK, poziom trzeci, i ładuje go do pamięci klastra. Odszyfrowany CEK w pamięci następnie szyfruje DEK, który jest również przechowywany w pamięci.

Ten zaszyfrowany DEK jest następnie wysyłany przez bezpieczny kanał i przechowywany w Redshift oddzielnie od klastra. Zarówno CEK, jak i DEK są teraz przechowywane w pamięci klastra zarówno w formie zaszyfrowanej, jak i odszyfrowanej. Odszyfrowany DEK jest następnie używany do szyfrowania kluczy danych, poziom czwarty, które są losowo generowane przez Redshift dla każdego bloku danych w bazie danych.

Możesz użyć AWS Trusted Advisor do monitorowania konfiguracji swoich wiader Amazon S3 i upewnienia się, że logowanie wiader jest włączone, co może być przydatne do przeprowadzania audytów bezpieczeństwa i śledzenia wzorców użytkowania w S3.

CloudHSM

Using Redshift with CloudHSM

Podczas pracy z CloudHSM w celu przeprowadzenia szyfrowania, najpierw musisz ustanowić zaufane połączenie między klientem HSM a Redshift, używając certyfikatów klienta i serwera.

To połączenie jest wymagane do zapewnienia bezpiecznej komunikacji, umożliwiając przesyłanie kluczy szyfrowania między klientem HSM a klastrami Redshift. Używając losowo wygenerowanej pary kluczy prywatnych i publicznych, Redshift tworzy publiczny certyfikat klienta, który jest szyfrowany i przechowywany przez Redshift. Musi on zostać pobrany i zarejestrowany w kliencie HSM oraz przypisany do odpowiedniej partycji HSM.

Następnie musisz skonfigurować Redshift z następującymi danymi swojego klienta HSM: adres IP HSM, nazwa partycji HSM, hasło partycji HSM oraz publiczny certyfikat serwera HSM, który jest szyfrowany przez CloudHSM za pomocą wewnętrznego klucza głównego. Po dostarczeniu tych informacji, Redshift potwierdzi i zweryfikuje, że może połączyć się i uzyskać dostęp do partycji rozwojowej.

Jeśli twoje wewnętrzne polityki bezpieczeństwa lub kontrole zarządzania wymagają zastosowania rotacji kluczy, jest to możliwe z Redshift, umożliwiając rotację kluczy szyfrowania dla zaszyfrowanych klastrów, jednak musisz być świadomy, że podczas procesu rotacji kluczy klaster będzie niedostępny przez bardzo krótki czas, więc najlepiej jest rotować klucze tylko wtedy, gdy jest to konieczne lub jeśli uważasz, że mogły zostać skompromitowane.

Podczas rotacji, Redshift będzie rotować CEK dla twojego klastra i dla wszelkich kopii zapasowych tego klastra. Będzie rotować DEK dla klastra, ale nie jest możliwe rotowanie DEK dla migawek przechowywanych w S3, które zostały zaszyfrowane za pomocą DEK. Klaster zostanie w stanie 'rotating keys' do momentu zakończenia procesu, po czym status powróci do 'available'.

Enumeration

# Get clusters
aws redshift describe-clusters
## Get if publicly accessible
aws redshift describe-clusters | jq -r ".Clusters[].PubliclyAccessible"
## Get DB username to login
aws redshift describe-clusters | jq -r ".Clusters[].MasterUsername"
## Get endpoint
aws redshift describe-clusters | jq -r ".Clusters[].Endpoint"
## Public addresses of the nodes
aws redshift describe-clusters | jq -r ".Clusters[].ClusterNodes[].PublicIPAddress"
## Get IAM roles of the clusters
aws redshift describe-clusters | jq -r ".Clusters[].IamRoles"

# Endpoint access & authorization
aws redshift describe-endpoint-access
aws redshift describe-endpoint-authorization

# Get credentials
aws redshift get-cluster-credentials --db-user <username> --cluster-identifier <cluster-id>
## By default, the temporary credentials expire in 900 seconds. You can optionally specify a duration between 900 seconds (15 minutes) and 3600 seconds (60 minutes).
aws redshift get-cluster-credentials-with-iam --cluster-identifier <cluster-id>
## Gives creds to access redshift with the IAM redshift permissions given to the current AWS account
## More in https://docs.aws.amazon.com/redshift/latest/mgmt/redshift-iam-access-control-identity-based.html

# Authentication profiles
aws redshift describe-authentication-profiles

# Snapshots
aws redshift describe-cluster-snapshots

# Scheduled actions
aws redshift describe-scheduled-actions

# Connect
# The redshift instance must be publicly available (not by default), the sg need to allow inbounds connections to the port and you need creds
psql -h redshift-cluster-1.sdflju3jdfkfg.us-east-1.redshift.amazonaws.com -U admin -d dev -p 5439

Privesc

AWS - Redshift Privesc

Persistence

Następujące akcje pozwalają na przyznanie dostępu do innych kont AWS do klastra:

Wspieraj HackTricks

Last updated