Amazon SCS-C02: Szyfrowanie, KMS i sekrety — Przewodnik do nauki

By Laurynas Brazys · 25 July 2026 · #amazon #scs-c02 #certification #exam-prep #study-guide

Część AWS Security Specialty SCS-C02 — Przewodnik do nauki. Ćwicz ze zweryfikowanymi odpowiedziami w centrum egzaminów Amazon, albo rozwiąż testy na czas na ExamRoll.io.

Typy kluczy AWS KMS, polityki i kontrola dostępu

AWS KMS obsługuje trzy szerokie kategorie kluczy, a wybór właściwej z nich decyduje o tym, kto kontroluje materiał klucza, gdzie on się znajduje i jak może być rotowany. Klucze należące do AWS są dla Ciebie niewidoczne, nic nie kosztują i są używane przez usługi takie jak S3 po włączeniu SSE-S3. Klucze zarządzane przez AWS (z aliasem aws/<service>) pozwalają usłudze szyfrować w Twoim imieniu, ale nie możesz modyfikować ich polityki klucza, dlatego nie nadają się do dostępu międzykontowego ani szczegółowego zarządzania. Klucze zarządzane przez klienta (CMK) to podstawowe narzędzie pracy: kontrolujesz politykę klucza, rotację (roczną automatyczną lub na żądanie), granty, aliasy i okno usuwania.

Ważne są dwa wyspecjalizowane warianty. Importowany materiał klucza jest używany, gdy wymogi regulacyjne lub BYOK zmuszają do generowania materiału klucza poza AWS i importowania go do klucza KMS. Importowany materiał to jedyny sposób na skonfigurowanie jawnego wygaśnięcia materiału klucza — klucze CMK generowane przez AWS nigdy nie wygasają. Nie można włączyć automatycznej rocznej rotacji AWS dla kluczy importowanych; materiał trzeba reimportować samodzielnie. Klucze wieloregionowe współdzielą ten sam identyfikator klucza i materiał w różnych regionach za pomocą kluczy-replik, dzięki czemu szyfrogram utworzony w us-east-1 może być odszyfrowany w us-west-1 bez ponownego szyfrowania. Każda replika ma własną, niezależną politykę klucza i aliasy, ale materiał kryptograficzny jest synchronizowany.

Najczęściej źle rozumianym mechanizmem kontroli jest polityka klucza KMS. W przeciwieństwie do większości zasobów AWS, gdzie polityki IAM same w sobie nadają dostęp, klucze KMS używają swojej polityki klucza jako głównego źródła autoryzacji. Polityka IAM nadająca uprawnienie kms:Decrypt do klucza jest bezskuteczna, chyba że polityka klucza również deleguje dostęp do IAM (poprzez Principal wskazujący na roota konta wraz z odpowiednią instrukcją lub przez bezpośrednie nazwanie podmiotu). Dlatego inżynier z uprawnieniami AdministratorAccess może nadal otrzymywać błąd AccessDenied podczas wywoływania Decrypt na kluczu CMK, którego polityka nie ufa danemu kontu. Kanononiczna instrukcja delegacji wygląda następująco:

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

Granty i warunki ViaService dodają warstwowe ograniczenia — na przykład wymuszając, aby klucz był używany tylko za pośrednictwem S3 w określonym regionie za pomocą kms:ViaService: s3.us-east-1.amazonaws.com.

Szyfrowanie po stronie serwera i klienta

Dla S3 dwie popularne opcje po stronie serwera różnią się głównie kontrolą i audytowalnością:

• SSE-S3 (AES-256): S3 w pełni zarządza kluczami; nie ma widocznej dla klienta polityki klucza, brak zdarzeń odszyfrowania per klucz w CloudTrail i brak możliwości zarządzania międzykontowego. Wystarczające do podstawowego szyfrowania danych w spoczynku, ale niewystarczające, gdy zgodność z przepisami wymaga udowodnienia, kto odszyfrował dane.
• SSE-KMS: Używa klucza CMK, który kontrolujesz; każde wywołanie odszyfrowania jest logowane, polityka klucza wymusza dostęp i można ograniczyć go za pomocą kontekstu szyfrowania. Kosztuje więcej za żądanie i zużywa limity TPS dla KMS, dlatego należy włączyć klucze bucketu (BucketKeyEnabled: true), aby radykalnie zmniejszyć liczbę wywołań KMS.

Szyfrowanie po stronie klienta za pomocą AWS Encryption SDK jest odpowiednie, gdy dane muszą być zaszyfrowane przed opuszczeniem aplikacji lub gdy usługa przechowywania nigdy nie może zobaczyć tekstu jawnego. W przypadku obciążeń o dużej przepustowości należy opakować SDK w menedżer materiałów kryptograficznych z buforowaniem (CachingCryptoMaterialsManager), który ponownie wykorzystuje klucze danych dla wielu wiadomości w ramach konfigurowalnych limitów bajtów, wiadomości i TTL. Bez buforowania każde wywołanie encrypt uruchamia żądanie GenerateDataKey, co szybko wyczerpuje limity zapytań KMS i zwiększa koszty.

from aws_encryption_sdk import CachingCryptoMaterialsManager, LocalCryptoMaterialsCache
cache = LocalCryptoMaterialsCache(capacity=100)
ccmm = CachingCryptoMaterialsManager(
    master_key_provider=mkp, cache=cache,
    max_age=600.0, max_messages_encrypted=10000)

Secrets Manager i Parameter Store

Secrets Manager przechowuje poświadczenia zaszyfrowane kluczem KMS CMK i obsługuje automatyczną rotację za pomocą funkcji Lambda — AWS dostarcza szablony dla RDS, Redshift i DocumentDB, a niestandardowe funkcje Lambda obsługują wszystko inne. Rotacja uruchamia czterostopniową maszynę stanów (createSecret, setSecret, testSecret, finishSecret), która przygotowuje nowe poświadczenia pod etykietą AWSPENDING, zanim awansuje je do AWSCURRENT. Aplikacje powinny przechwytywać błędy uwierzytelniania, odświeżać sekret i ponawiać próbę — ten wzorzec eliminuje przestoje w działaniu, ponieważ poprzednie poświadczenie pozostaje przez krótki czas ważne dzięki etykiecie AWSPREVIOUS.

Gdy funkcja Lambda odpowiedzialna za rotację działa wewnątrz VPC (co jest typowe dla dostępu do prywatnej instancji RDS), potrzebuje ona wychodzącego dostępu sieciowego do punktu końcowego usługi Secrets Manager. W prywatnym VPC bez NAT należy wdrożyć interfejsowy punkt końcowy VPC (com.amazonaws.<region>.secretsmanager) i zezwolić grupie bezpieczeństwa funkcji Lambda na dostęp do tego punktu końcowego na porcie 443. Zapomnienie o tym to klasyczny błąd: rotacja wydaje się skonfigurowana, ale każde jej wywołanie kończy się timeoutem.

Aby uzyskać odporność międzyregionalną, użyj wieloregionowego klucza KMS i funkcji replikacji sekretów w Secrets Manager. Główny sekret w us-east-1 jest zaszyfrowany głównym kluczem CMK; replika w us-west-1 odszyfrowuje go za pomocą klucza-repliki CMK. Aliasy takie jak alias/prod-db można na żądanie przekierować na nowy identyfikator klucza, co pozwala na szybką rotację kluczy bez zmiany kodu aplikacji.

Typ SecureString w Parameter Store to lżejsza alternatywa, gdy nie potrzebujesz rotacji. Obie usługi udostępniają dynamiczne referencje w CloudFormation ({{resolve:secretsmanager:MySecret:SecretString:password}}), dzięki czemu szablony stosów nigdy nie zawierają tekstu jawnego.

Szyfrowanie EBS, RDS, Aurora i migawek

Szyfrowanie w spoczynku jest włączane na poziomie woluminu lub instancji w momencie tworzenia i nie można go przełączyć w miejscu. Wzorzec naprawczy dla niezgodnego z wymogami, niezaszyfrowanego zasobu to kopia migawki z włączonym szyfrowaniem:

aws ec2 copy-snapshot --source-snapshot-id snap-abc \
  --source-region us-east-1 --encrypted \
  --kms-key-id alias/prod-ebs
aws ec2 create-volume --snapshot-id snap-newEncrypted ...

W przypadku RDS i Aurora należy przywrócić zaszyfrowaną migawkę do nowej instancji i dokonać przełączenia. Odzyskiwanie międzykontowe wymaga udostępnienia migawki oraz nadania kontu docelowemu uprawnień kms:CreateGrant i kms:Decrypt do klucza CMK za pośrednictwem polityki klucza — samo udostępnienie migawki zakończy się niepowodzeniem, ponieważ konto docelowe nie będzie mogło odszyfrować klucza danych. Należy włączyć domyślne szyfrowanie EBS na poziomie konta, aby nowo tworzone woluminy były zawsze szyfrowane, niezależnie od zachowania wywołującego.

TLS: Certyfikaty ACM i polityki ALB

ACM wydaje i automatycznie odnawia publiczne certyfikaty bezpłatnie, gdy są one powiązane ze zintegrowanymi usługami (ALB, CloudFront, API Gateway). Certyfikatów nie można eksportować, więc TLS zakończony na EC2 wymaga albo ACM Private CA (dla prywatnych certyfikatów, które można eksportować), albo zaimportowanego certyfikatu. Praktycznym wzorcem jest zakończenie publicznego TLS na ALB za pomocą certyfikatu ACM i użycie certyfikatu self-signed lub z prywatnego CA dla połączenia z ALB do EC2, jeśli wymagane jest szyfrowanie end-to-end. Wymuś na klientach korzystanie z nowoczesnych szyfrów za pomocą polityki bezpieczeństwa, takiej jak ELBSecurityPolicy-TLS13-1-2-2021-06, która wyłącza TLS 1.0/1.1 i słabe zestawy szyfrów.

Częste pułapki

IAM bez polityki klucza. Nadanie uprawnienia kms:Decrypt w polityce IAM, podczas gdy polityka klucza CMK pomija głównego podmiotu konta (account principal), skutkuje błędem AccessDenied. KMS traktuje politykę klucza jako nadrzędną; uprawnienia IAM mogą jedynie dodatkowo ograniczać to, na co pozwala polityka klucza.

Lambda do rotacji bez punktu końcowego VPC. Jeśli funkcja Lambda działa w prywatnych podsieciach, a VPC nie ma bramy NAT ani interfejsowego punktu końcowego secretsmanager, wywołanie rotacji do secretsmanager.<region>.amazonaws.com nie może zostać rozwiązane ani nawiązane. Grupa bezpieczeństwa punktu końcowego musi również zezwalać na ruch na porcie 443 z grupy bezpieczeństwa funkcji Lambda.

Utożsamianie SSE-S3 z SSE-KMS. SSE-S3 używa klucza należącego do AWS, bez polityki edytowalnej przez klienta, bez logowania deszyfrowania per obiekt w CloudTrail i bez możliwości udostępniania klucza między kontami. Spełnia wymóg „szyfrowania w spoczynku” (encrypt at rest), ale nie może wymusić, które podmioty (principals) mogą deszyfrować określone obiekty — tylko SSE-KMS z kluczem CMK zapewnia taki poziom zarządzania.

Problem praktyczny: Scenariusz użycia

Scenariusz: Firma Meridian Financial prowadzi wielokontową organizację AWS Organization z kontem Security, oddzielnymi kontami Prod/NonProd, mikrousługami w ECS/EKS za ALB, klastrami RDS/Aurora, instancjami EC2 z wolumenami EBS oraz jeziorami danych w S3. Deweloperzy i automatyzacja obecnie używają mieszanki kluczy zarządzanych przez AWS, parametrów SSM w postaci zwykłego tekstu oraz sporadycznego ręcznego udostępniania snapshotów między kontami.

Wyzwanie: Inżynier przypadkowo udostępnił niezaszyfrowany snapshot RDS na konto strony trzeciej, a kilka poświadczeń API zostało odkrytych jako przechowywane w postaci zwykłego tekstu w parametrach SecureString, co stworzyło ryzyko eksfiltracji danych i nieautoryzowanego dostępu do odtworzenia zasobów.

Zalecane podejście:

1. Utwórz w koncie Security symetryczny klucz CMK zarządzany przez klienta (customer-managed) w AWS KMS o zasięgu całej organizacji, z polityką klucza przyznającą uprawnienia do użycia kontom członkowskim za pomocą aws:PrincipalOrgID i włącz automatyczną rotację; używaj grantów do krótkotrwałych operacji między kontami.
2. Napraw istniejące artefakty, kopiując niezaszyfrowany snapshot RDS i wszelkie snapshoty EBS, wybierając przy tym nowy klucz CMK w celu utworzenia zaszyfrowanych kopii, a następnie usuń oryginalne, niezaszyfrowane snapshoty; ustaw domyślne ustawienia konta tak, aby nowe zasoby RDS i EBS były domyślnie szyfrowane.
3. Zmigruj sekrety do AWS Secrets Manager (lub SSM Parameter Store SecureString) zaszyfrowane kluczem CMK, włącz automatyczną rotację poświadczeń bazodanowych w Secrets Manager za pomocą funkcji Lambda i ogranicz dostęp za pomocą polityk opartych na zasobach oraz ról IAM z minimalnymi uprawnieniami.
4. Wymuś szyfrowanie w tranzycie (encryption in transit), provisionując zarządzane przez ACM certyfikaty TLS i dołączając je do ALB z nowoczesną polityką TLS (TLS 1.2/1.3), a także skonfiguruj bazy danych i klientów, aby wymagały połączeń TLS.
5. Zapobiegaj powtórzeniu problemu za pomocą barier ochronnych (guardrails): zastosuj Service Control Policies, aby blokować tworzenie/udostępnianie niezaszyfrowanych snapshotów i niezaszyfrowanych operacji put do S3, włącz reguły AWS Config dla zaszyfrowanych zasobów oraz monitoruj użycie KMS i Secrets Manager za pomocą CloudTrail i alarmów CloudWatch.

Uzasadnienie: Centralne klucze CMK z politykami na poziomie organizacji, zautomatyzowane ponowne szyfrowanie, Secrets Manager do zarządzania cyklem życia sekretów, wymuszanie TLS oraz prewencyjne bariery ochronne są zgodne z najlepszymi praktykami AWS dotyczącymi minimalnych uprawnień (least-privilege) i obrony w głąb (defense-in-depth), aby wyeliminować sekrety w postaci zwykłego tekstu i nieautoryzowany dostęp do snapshotów.

Klucze CMK zarządzane przez klienta: wieloregionowość, importowany materiał i polityki kluczy

Zarządzany przez klienta klucz CMK to płaszczyzna sterowania dla każdej operacji kryptograficznej na danych, które posiadasz w AWS. Trzy właściwości, które najczęściej decydują o tym, czy projekt zakończy się sukcesem, czy spowoduje awarię, to topologia regionowa klucza, pochodzenie jego materiału klucza oraz dołączona do niego polityka.

Klucze wieloregionowe to zestaw kluczy KMS w różnych regionach, które współdzielą ten sam identyfikator klucza i, co kluczowe, ten sam materiał klucza. Nie są one replikowane automatycznie w taki sposób, jak globalne tabele DynamoDB — repliki tworzy się jawnie z klucza podstawowego za pomocą ReplicateKey. Ponieważ materiał klucza jest identyczny we wszystkich replikach, szyfrogram utworzony w us-east-1 może zostać odszyfrowany w us-west-1 bez wywołań KMS między regionami. Jest to dokładnie ta właściwość, która jest wymagana podczas replikacji sekretu Secrets Manager między regionami: zreplikowany sekret w regionie zapasowym (failover) musi być możliwy do odszyfrowania lokalnie, zarówno w celu wyeliminowania opóźnień międzyregionalnych przy każdym wywołaniu GetSecretValue, jak i w celu przetrwania regionalnej awarii regionu podstawowego. Jednoregionowy klucz CMK nie może obsługiwać repliki Secrets Manager w innym regionie, więc prawidłowym wzorcem jest zaszyfrowanie sekretu podstawowego za pomocą wieloregionowego klucza CMK, zreplikowanie klucza do regionu docelowego, a następnie zreplikowanie sekretu, wskazując na zreplikowany klucz CMK.

aws kms create-key --multi-region --region us-east-1
aws kms replicate-key --key-id mrk-abc123 \
  --replica-region us-west-1
aws secretsmanager replicate-secret-to-regions \
  --secret-id prod/db \
  --add-replica-regions Region=us-west-1,KmsKeyId=mrk-abc123

Importowany materiał klucza (pochodzenie zewnętrzne, Origin=EXTERNAL) występuje, gdy generujesz surowy materiał AES-256 poza AWS i importujesz go do „powłoki” klucza KMS. AWS nigdy nie posiada kopii tego materiału poza chronioną pamięcią HSM i nie ma żadnej kopii zapasowej. Jeśli usuniesz zaimportowany materiał — czy to za pomocą DeleteImportedKeyMaterial, czy z powodu upływu daty jego wygaśnięcia — klucz przechodzi w stan PendingImport, a wszystkie szyfrogramy utworzone przy jego użyciu stają się niemożliwe do odzyskania, chyba że ponownie zaimportujesz dokładnie te same bajty. Jest to ścieżka odzyskiwania, gdy na przykład wolumin EBS nie może zostać podłączony, ponieważ jego zaszyfrowany klucz danych nie może zostać odszyfrowany: ponowne zaimportowanie identycznego materiału klucza z Twojego depozytu offline (escrow) sprawia, że wolumin znów staje się użyteczny. Nie ma żadnej opcji przywracania po stronie AWS, żadnej sztuczki z rotacją ani żadnego zgłoszenia do wsparcia technicznego, które pozwoliłoby odzyskać usunięty importowany materiał. Traktuj kopię offline jako infrastrukturę warstwy zero (tier-zero).

Polityki kluczy są źródłem zaufania (root of trust) dla każdego klucza KMS. W przeciwieństwie do samego IAM, KMS wymaga jawnego zezwolenia w samej polityce klucza; polityka IAM przyznająca kms:Decrypt jest nieskuteczna, chyba że polityka klucza deleguje uprawnienia do IAM (poprzez "Principal": {"AWS": "arn:aws:iam::111122223333:root"} w połączeniu z instrukcją warunkową). W przypadku użycia między kontami, polityka klucza musi jawnie wskazywać zewnętrzne konto lub podmiot (principal), a zewnętrzne konto musi następnie przyznać uprawnienia swoim własnym użytkownikom za pośrednictwem IAM. Zapomnienie o konfiguracji po stronie polityki klucza jest najczęstszą przyczyną niepowodzeń w dostępie do Secrets Manager między kontami — polityka zasobu Secrets Manager pozwala zewnętrznemu podmiotowi wywołać GetSecretValue, ale bazowa operacja Decrypt kończy się niepowodzeniem, ponieważ klucz CMK wciąż odmawia dostępu wywołującemu.

Wzorce użycia Secrets Manager i Parameter Store SecureString

Zarówno Secrets Manager, jak i SecureStrings w SSM Parameter Store delegują szyfrowanie do KMS, ale różnią się kosztem, semantyką rotacji i zachowaniem między regionami. Secrets Manager obsługuje natywną replikację wieloregionową, wersjonowanie z etykietami tymczasowymi (staging labels) (AWSCURRENT, AWSPENDING) oraz rotację opartą na funkcjach Lambda. Parameter Store SecureString jest tańszy, integruje się ze ścieżkami hierarchicznymi i dobrze sprawdza się w przypadku sekretów konfiguracyjnych, które są rzadko rotowane.

Aby umożliwić dostęp między kontami, musisz zaktualizować zarówno politykę zasobu dla sekretu (lub politykę IAM na koncie konsumenta w przypadku Parameter Store), jak i politykę klucza KMS dla szyfrującego klucza CMK. Założenie, że same uprawnienia Secrets Manager wystarczą, jest błędne, ponieważ proces pobierania sekretu zawsze wykonuje niejawną operację kms:Decrypt na kluczu CMK; bez zezwolenia w polityce klucza dla konta zewnętrznego, wywołujący otrzyma wyjątek AccessDeniedException na etapie Decrypt, nawet jeśli polityka samego sekretu jest spełniona.

• Secrets Manager: zarządzana rotacja, struktura JSON, ~$0.40/sekret/miesiąc, wbudowana replikacja wieloregionowa
• Parameter Store SecureString (Advanced): tańszy przy dużej liczbie wartości, 8 KB na parametr, brak wbudowanej replikacji między regionami
• Parameter Store SecureString (Standard): darmowy poziom dla parametrów szyfrowanych przez KMS do 4 KB, brak mechanizmu rotacji

Szyfrowanie kopertowe, klucze zasobnika i tokeny nadań

Szyfrowanie kopertowe oznacza, że KMS nigdy nie ma bezpośredniego kontaktu z Twoimi danymi masowymi. Wywołujesz GenerateDataKey, które zwraca zarówno klucz danych w postaci jawnej (używany lokalnie do szyfrowania danych za pomocą AES-GCM), jak i zaszyfrowaną kopię tego klucza danych (przechowywaną obok zaszyfrowanego tekstu). Aby odszyfrować dane, wywołujesz Decrypt na opakowanym kluczu danych i ponownie odtwarzasz klucz w postaci jawnej lokalnie. Ten wzorzec jest kluczowy, ponieważ KMS ma limity zapytań (na region, na klucz) i ceny za każde wywołanie API. Jeśli będziesz szyfrować każdy 4 KB rekord za pomocą bezpośredniego wywołania Encrypt, napotkasz na problemy z dławieniem (throttling) i gwałtownym wzrostem kosztów; jeśli wygenerujesz jeden klucz danych na partię lub na plik, przepustowość będzie skalować się liniowo wraz z wydajnością Twojej lokalnej biblioteki kryptograficznej.

Klucze zasobnika S3 (S3 Bucket Keys) stosują tę samą zasadę wewnątrz S3 dla SSE-KMS. Bez klucza zasobnika, każde żądanie PUT i GET obiektu SSE-KMS generuje wywołanie GenerateDataKey lub Decrypt. W zasobniku, który odbiera tysiące obiektów na sekundę, powoduje to zarówno dławienie zapytań do KMS, jak i zaskakująco wysoki rachunek za usługę KMS. Włączenie klucza zasobnika sprawia, że S3 generuje jeden krótkotrwały klucz na poziomie zasobnika i używa go ponownie dla wielu obiektów, co zmniejsza liczbę żądań do KMS o rzędy wielkości:

aws s3api put-bucket-encryption --bucket app-data \
  --server-side-encryption-configuration '{
    "Rules":[{
      "ApplyServerSideEncryptionByDefault":{
        "SSEAlgorithm":"aws:kms","KMSMasterKeyID":"alias/app"},
      "BucketKeyEnabled":true}]}'

Nadania (Grants) są alternatywą dla polityk kluczy w celu tymczasowego, szczegółowego delegowania uprawnień. Mają one znaczenie operacyjne ze względu na spójność ostateczną (eventual consistency): po zwróceniu odpowiedzi przez CreateGrant, nadanie nie jest natychmiast widoczne dla każdego punktu końcowego KMS w regionie. Jeśli klient spróbuje wykonać Encrypt kilka milisekund później, może otrzymać wyjątek AccessDeniedException. Ciało odpowiedzi CreateGrant zawiera ciąg znaków GrantToken, który, przekazany w kolejnych wywołaniach KMS za pomocą parametru --grant-tokens, zmusza KMS do natychmiastowego uwzględnienia nadania, niezależnie od stanu jego propagacji.

TOKEN=$(aws kms create-grant --key-id $KEY \
  --grantee-principal arn:aws:iam::111122223333:role/worker \
  --operations Encrypt Decrypt --query GrantToken --output text)
aws kms encrypt --key-id $KEY --plaintext fileb://payload \
  --grant-tokens "$TOKEN"

Poleganie na ponawianiu prób z wykładniczym czasem oczekiwania (retry-with-backoff) zamiast na tokenie nadania jest poprawnym, ale gorszym rozwiązaniem — marnuje czas (zwiększa opóźnienia) i nadal może zawieść pod dużym obciążeniem. Kanoniczna odpowiedź jest zawsze taka sama: zwróć token nadania z usługi, która tworzy nadanie, i wymagaj od klientów przedstawienia go podczas pierwszej operacji.

Problem praktyczny: Scenariusz użycia

Scenariusz: Meridian Financial prowadzi wielokontowe środowisko AWS, w którym przechowuje dane osobowe klientów (PII) w S3, transakcyjne bazy danych w RDS oraz bezserwerowe przetwarzanie za pomocą Lambda. Firma używa kluczy CMK zarządzanych przez klienta (Customer Managed CMKs) z zaimportowanym materiałem klucza, aby spełnić regionalne przepisy dotyczące powiernictwa kluczy, i replikuje klucze do drugiego regionu w celu odzyskiwania po awarii (disaster recovery).

Wyzwanie: Niedawny audyt wykrył błędnie skonfigurowaną politykę klucza KMS, która pozwalała na deszyfrowanie między kontami, a zewnętrzny audytor potrzebuje tymczasowego dostępu do deszyfrowania podzbioru obiektów S3. Meridian potrzebuje również bezpiecznej rotacji sekretów i wydajnego szyfrowania dużych obiektów, aby kontrolować koszty zapytań do KMS.

Zalecane podejście:

1. Dokonaj rotacji błędnie skonfigurowanej polityki klucza CMK w AWS KMS na politykę najmniejszych uprawnień, która jawnie przyznaje dostęp tylko wymaganym podmiotom (principals) i rolom IAM, oraz utwórz wieloregionalną replikę CMK na potrzeby DR, używając wieloregionalnych kluczy KMS.
2. Ponownie zaimportuj lub zaplanuj zarządzanie cyklem życia dla zaimportowanego materiału klucza zgodnie z oknami zgodności i włącz automatyczne powiadomienia o wygaśnięciu/rotacji materiału klucza za pomocą AWS Config i EventBridge.
3. Dla audytora utwórz nadanie KMS (grant) z krótkim czasem życia (TTL) i natychmiast użyj tokena nadania w sesji assume-role audytora, aby zezwolić na tymczasowe operacje deszyfrowania bez zmiany polityki klucza.
4. Przenieś długoterminowe poświadczenia do AWS Secrets Manager z rotacją opartą na Lambda, powiązaną z docelową usługą (RDS lub klucze API), a parametry infrastruktury przechowuj jako SecureString w Systems Manager Parameter Store dla elementów nierotowanych, wymuszając szyfrowanie za pomocą CMK i stosując restrykcyjne polityki zasobowe.
5. Zaimplementuj szyfrowanie kopertowe dla dużych obiektów S3, wywołując GenerateDataKey (Encrypt/Decrypt) z KMS w kodzie aplikacji lub za pośrednictwem AWS SDK, oraz włącz klucze zasobnika S3 (S3 Bucket Keys), aby zmniejszyć liczbę żądań do KMS i koszty szyfrowania dużych obiektów po stronie serwera.
6. Włącz logowanie CloudTrail i logowanie użycia kluczy KMS, a także utwórz alarmy CloudWatch/reguły GuardDuty, aby ostrzegać o nieoczekiwanych operacjach deszyfrowania lub tworzeniu nadań.

Uzasadnienie: Takie podejście wymusza dostęp do kluczy na zasadzie najmniejszych uprawnień, zapewnia zgodność z przepisami dla importowanego materiału i ciągłość działania w wielu regionach, wykorzystuje tymczasowe nadania do bezpiecznego dostępu dla stron trzecich, centralizuje sekrety z mechanizmem rotacji oraz optymalizuje wykorzystanie i koszty KMS zgodnie z najlepszymi praktykami AWS.

← Logowanie · Wszystkie domeny · Ochrona danych i S3 →

Przećwicz te pytania → · Testy na czas na ExamRoll.io →

Przeglądaj Amazon →