Polish - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

AWS - KMS Enum

Wspieraj HackTricks

KMS - Key Management Service

AWS Key Management Service (AWS KMS) jest przedstawiany jako zarządzana usługa, upraszczająca proces tworzenia i zarządzania kluczami głównymi klientów (CMKs). Te CMKs są integralne w szyfrowaniu danych użytkowników. Zauważalną cechą AWS KMS jest to, że CMKs są głównie zabezpieczane przez moduły bezpieczeństwa sprzętowego (HSMs), co zwiększa ochronę kluczy szyfrujących.

KMS używa kryptografii symetrycznej. Jest ona używana do szyfrowania informacji w spoczynku (na przykład, wewnątrz S3). Jeśli potrzebujesz szyfrować informacje w tranzycie, musisz użyć czegoś takiego jak TLS.

KMS jest usługą specyficzną dla regionu.

Administratorzy w Amazon nie mają dostępu do twoich kluczy. Nie mogą odzyskać twoich kluczy i nie pomagają w ich szyfrowaniu. AWS po prostu zarządza systemem operacyjnym i podstawową aplikacją, a my musimy zarządzać naszymi kluczami szyfrującymi i tym, jak są one używane.

Customer Master Keys (CMK): Mogą szyfrować dane do 4KB. Są zazwyczaj używane do tworzenia, szyfrowania i deszyfrowania DEKs (Data Encryption Keys). Następnie DEKs są używane do szyfrowania danych.

Klucz główny klienta (CMK) jest logiczną reprezentacją klucza głównego w AWS KMS. Oprócz identyfikatorów klucza głównego i innych metadanych, w tym daty utworzenia, opisu i stanu klucza, CMK zawiera materiał klucza używany do szyfrowania i deszyfrowania danych. Kiedy tworzysz CMK, domyślnie AWS KMS generuje materiał klucza dla tego CMK. Możesz jednak wybrać utworzenie CMK bez materiału klucza, a następnie zaimportować własny materiał klucza do tego CMK.

Istnieją 2 typy kluczy głównych:

  • AWS managed CMKs: Używane przez inne usługi do szyfrowania danych. Jest używany przez usługę, która go utworzyła w danym regionie. Są tworzone po raz pierwszy, gdy implementujesz szyfrowanie w tej usłudze. Rotuje co 3 lata i nie można tego zmienić.

  • Customer manager CMKs: Elastyczność, rotacja, konfigurowalny dostęp i polityka klucza. Włączanie i wyłączanie kluczy.

Envelope Encryption w kontekście Key Management Service (KMS): Dwupoziomowy system hierarchii do szyfrowania danych za pomocą klucza danych, a następnie szyfrowania klucza danych za pomocą klucza głównego.

Key Policies

Te definiują kto może używać i uzyskiwać dostęp do klucza w KMS.

Domyślnie:

  • Daje konto AWS, które posiada klucz KMS pełny dostęp do klucza KMS.

W przeciwieństwie do innych polityk zasobów AWS, polityka klucza KMS AWS nie daje automatycznie uprawnień do konta ani żadnego z jego użytkowników. Aby dać uprawnienia administratorom konta, polityka klucza musi zawierać wyraźne oświadczenie przyznające to uprawnienie, jak to.

  • Bez zezwolenia na konto ("AWS": "arn:aws:iam::111122223333:root") uprawnienia IAM nie będą działać.

  • Pozwala konto na używanie polityk IAM do zezwalania na dostęp do klucza KMS, oprócz polityki klucza.

Bez tego uprawnienia, polityki IAM, które zezwalają na dostęp do klucza, są nieskuteczne, chociaż polityki IAM, które odmawiają dostępu do klucza, są nadal skuteczne.

  • Zmniejsza ryzyko, że klucz stanie się niezarządzalny poprzez przyznanie uprawnień do kontroli dostępu administratorom konta, w tym użytkownikowi root konta, którego nie można usunąć.

Przykład domyślnej polityki:

{
"Sid": "Enable IAM policies",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
},
"Action": "kms:*",
"Resource": "*"
}

Jeśli konto jest dozwolone ("arn:aws:iam::111122223333:root"), podmiot z konta nadal będzie potrzebował uprawnień IAM do użycia klucza KMS. Jednakże, jeśli ARN roli na przykład jest specjalnie dozwolony w Polityce Klucza, ta rola nie potrzebuje uprawnień IAM.

Szczegóły Polityki

Właściwości polityki:

  • Dokument oparty na JSON

  • Resource --> Dotknięte zasoby (może być "*")

  • Action --> kms:Encrypt, kms:Decrypt, kms:CreateGrant ... (uprawnienia)

  • Effect --> Allow/Deny

  • Principal --> dotknięty arn

  • Warunki (opcjonalne) --> Warunek nadania uprawnień

Grants:

  • Pozwalają delegować swoje uprawnienia innemu podmiotowi AWS w ramach swojego konta AWS. Musisz je utworzyć za pomocą API AWS KMS. Można wskazać identyfikator CMK, podmiot grantu i wymagany poziom operacji (Decrypt, Encrypt, GenerateDataKey...)

  • Po utworzeniu grantu wydawane są GrantToken i GrantID

Dostęp:

  • Poprzez politykę klucza -- Jeśli istnieje, ma pierwszeństwo przed polityką IAM

  • Poprzez politykę IAM

  • Poprzez grants

Administratorzy Kluczy

Administrator kluczy domyślnie:

  • Ma dostęp do zarządzania KMS, ale nie do szyfrowania ani deszyfrowania danych

  • Tylko użytkownicy IAM i role mogą być dodawani do listy Administratorów Kluczy (nie grupy)

  • Jeśli używany jest zewnętrzny CMK, Administratorzy Kluczy mają uprawnienia do importowania materiału klucza

Rotacja CMK

  • Im dłużej ten sam klucz jest używany, tym więcej danych jest szyfrowanych tym kluczem, a jeśli ten klucz zostanie naruszony, tym większy obszar danych jest zagrożony. Dodatkowo, im dłużej klucz jest aktywny, tym większe prawdopodobieństwo jego naruszenia.

  • KMS rotuje klucze klientów co 365 dni (lub możesz przeprowadzić ten proces ręcznie, kiedy chcesz) i klucze zarządzane przez AWS co 3 lata i tego czasu nie można zmienić.

  • Starsze klucze są zachowywane do deszyfrowania danych zaszyfrowanych przed rotacją

  • W przypadku naruszenia, rotacja klucza nie usunie zagrożenia, ponieważ będzie możliwe deszyfrowanie wszystkich danych zaszyfrowanych naruszonym kluczem. Jednakże, nowe dane będą szyfrowane nowym kluczem.

  • Jeśli CMK jest w stanie wyłączony lub oczekujący na usunięcie, KMS nie przeprowadzi rotacji klucza dopóki CMK nie zostanie ponownie włączony lub usunięcie nie zostanie anulowane.

Ręczna rotacja

  • Należy utworzyć nowy CMK, wtedy zostanie utworzony nowy CMK-ID, więc będziesz musiał zaktualizować każdą aplikację, aby odnosiła się do nowego CMK-ID.

  • Aby ułatwić ten proces, możesz używać aliasów do odniesienia się do key-id i następnie po prostu zaktualizować klucz, do którego odnosi się alias.

  • Musisz zachować stare klucze do deszyfrowania starych plików zaszyfrowanych nimi.

Możesz importować klucze z infrastruktury kluczy on-premises.

Inne istotne informacje o KMS

KMS jest wyceniany na podstawie liczby żądań szyfrowania/deszyfrowania otrzymanych od wszystkich usług miesięcznie.

KMS ma pełną integrację audytu i zgodności z CloudTrail; tutaj możesz audytować wszystkie zmiany wykonane na KMS.

Za pomocą polityki KMS możesz zrobić następujące:

  • Ograniczyć, kto może tworzyć klucze danych i które usługi mają dostęp do używania tych kluczy

  • Ograniczyć dostęp systemów do tylko szyfrowania, tylko deszyfrowania lub obu

  • Zdefiniować, aby umożliwić systemom dostęp do kluczy w różnych regionach (chociaż nie jest to zalecane, ponieważ awaria w regionie hostującym KMS wpłynie na dostępność systemów w innych regionach).

Nie możesz synchronizować ani przenosić/kopiować kluczy między regionami; możesz tylko zdefiniować zasady umożliwiające dostęp między regionami.

Enumeration

aws kms list-keys
aws kms list-key-policies --key-id <id>
aws kms list-grants --key-id <id>
aws kms describe-key --key-id <id>
aws kms get-key-policy --key-id <id> --policy-name <name> # Default policy name is "default"
aws kms describe-custom-key-stores

Privesc

AWS - KMS Privesc

Post Exploitation

AWS - KMS Post Exploitation

Persistence

AWS - KMS Persistence

Referencje

Wspieraj HackTricks
PreviousAWS - IAM, Identity Center & SSO EnumNextAWS - Lambda Enum

Last updated