Amazon SCS-C02: Ochrona danych i S3 — 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.

Polityki bucketów S3, numery ARN zasobów i jawne odmowy (Explicit Deny)

Polityka bucketu S3 to oparty na zasobach dokument JSON, który jest ewaluowany razem z politykami opartymi na tożsamości. Jej działaniem rządzą dwie zasady. Po pierwsze, jawna reguła Deny zawsze ma pierwszeństwo: bez względu na liczbę istniejących instrukcji Allow, pasująca reguła Deny blokuje żądanie. Po drugie, element Resource musi dokładnie odpowiadać wzorcowi ARN dla danej akcji. Akcje na poziomie bucketu, takie jak s3:ListBucket, działają na zasobie arn:aws:s3:::my-bucket, podczas gdy akcje na poziomie obiektu, takie jak s3:GetObject i s3:PutObject, działają na arn:aws:s3:::my-bucket/*. Częstym błędem w konfiguracji jest przyznanie uprawnienia s3:GetObject do zasobu arn:aws:s3:::my-bucket bez sufiksu /* — wywołanie API jest skierowane do ARN obiektu, żadna instrukcja nie pasuje, a żądanie jest domyślnie odrzucane.

Poniższa polityka odmawia dostępu bez użycia TLS i przyznaje uprawnienia do odczytu określonej roli, poprawnie wykorzystując obie formy ARN.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyInsecureTransport",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::reports",
        "arn:aws:s3:::reports/*"
      ],
      "Condition": { "Bool": { "aws:SecureTransport": "false" } }
    },
    {
      "Sid": "AllowAnalyticsRead",
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::111122223333:role/Analytics" },
      "Action": ["s3:GetObject"],
      "Resource": "arn:aws:s3:::reports/*"
    }
  ]
}

Częstą pułapką jest próba „wycięcia” wyjątku poprzez dodanie instrukcji Allow po szerokiej regule Deny. Instrukcje w polityce nie są wrażliwe na kolejność, a logika ewaluacji IAM zwraca Deny w momencie znalezienia jakiejkolwiek pasującej reguły odmawiającej. Prawidłowym rozwiązaniem jest zawężenie działania reguły Deny — na przykład za pomocą NotPrincipal lub Condition — zamiast dołączania pod nią permisywnej instrukcji.

Reguły cyklu życia (Lifecycle Rules), wygasanie obiektów i Vault Lock

Reguły cyklu życia S3 (Lifecycle rules) automatyzują przenoszenie obiektów między klasami pamięci masowej oraz ich wygasanie. Aby spełnić wymagania dotyczące retencji — na przykład usuwanie danych PII 30 dni po ich załadowaniu — należy dołączyć regułę, która wygasza bieżące wersje obiektów po 30 dniach i krótko potem trwale usuwa wersje niebieżące. Dla powiązanych metadanych zapisanych w DynamoDB, należy włączyć atrybut TTL DynamoDB, aby elementy usuwały się samoczynnie według tego samego harmonogramu; połączenie tych dwóch mechanizmów jest wydajne operacyjnie, ponieważ nie wymaga funkcji Lambda, harmonogramu ani dedykowanego kodu czyszczącego.

LifecycleConfiguration:
  Rules:
    - Id: ExpirePIIAfter30Days
      Status: Enabled
      Filter: { Prefix: "ingest/" }
      Expiration: { Days: 30 }
      NoncurrentVersionExpiration: { NoncurrentDays: 1 }

Dla zarchiwizowanych danych z wymogami retencji regulacyjnej, usługa S3 Glacier Vault Lock zapewnia oddzielny mechanizm kontroli WORM na poziomie skarbca (vault). Gdy polityka Vault Lock zostanie zatwierdzona (dwuetapowy proces inicjacji i ukończenia w ciągu 24 godzin), nie może być zmieniona, nawet przez użytkownika root konta. Jest to mechanizm odrębny od Object Lock, który działa na poziomie obiektu S3.

Block Public Access i CloudFront OAC

S3 Block Public Access (BPA) to zestaw czterech przełączników na poziomie konta i bucketu, które nadpisują każdą listę ACL lub politykę, która w innym przypadku przyznałaby dostęp publiczny. Należy włączyć wszystkie cztery na poziomie konta i wymusić to za pomocą SCP, na przykład odmawiając akcji s3:PutBucketPublicAccessBlock, gdyby miała ona na celu złagodzenie ustawień. Taka obrona w głąb (defense-in-depth) zapobiega przypadkowemu ponownemu udostępnieniu bucketu przez inżyniera za pomocą permisywnej listy ACL.

Dla treści publicznych serwowanych przez CloudFront, prawidłowym wzorcem jest Origin Access Control (OAC). OAC podpisuje żądania z CloudFront do S3 przy użyciu SigV4; polityka bucketu zezwala wtedy na dostęp wyłącznie jednostce usługi (service principal) dystrybucji CloudFront. Poleganie wyłącznie na CloudFront bez OAC (lub starszego OAI) pozostawia adres URL S3 bezpośrednio dostępnym, omijając mechanizmy kontroli dostępu i WAF sieci CDN. Bucket musi pozostać prywatny, z włączonym BPA, a polityka ograniczona do ARN dystrybucji:

{
  "Effect": "Allow",
  "Principal": { "Service": "cloudfront.amazonaws.com" },
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::site-assets/*",
  "Condition": {
    "StringEquals": {
      "AWS:SourceArn": "arn:aws:cloudfront::111122223333:distribution/E1ABCXYZ"
    }
  }
}

S3 Object Lock i replikacja międzyregionalna (Cross-Region Replication)

Object Lock wymusza semantykę WORM na pojedynczych obiektach i wymaga, aby wersjonowanie było włączone, a Object Lock aktywowany podczas tworzenia bucketu (nie można go dodać później do istniejącego bucketu bez kontaktu z AWS). Istnieją dwa tryby retencji:

Tryb Governance: uprzywilejowani użytkownicy (principals) z uprawnieniem s3:BypassGovernanceRetention mogą skrócić lub usunąć okres retencji.
Tryb Compliance: żaden użytkownik — włącznie z użytkownikiem root konta AWS — nie może usunąć ani nadpisać obiektu, ani skrócić jego okresu retencji aż do jego wygaśnięcia. Dodatkowo, blokada prawna (legal hold) może być niezależnie nakładana i zdejmowana przez użytkowników z uprawnieniem s3:PutObjectLegalHold.

Tryb Compliance jest właściwym wyborem, gdy wymagana jest absolutna niezmienność wobec wszystkich tożsamości. Aby rozszerzyć tę gwarancję na inne regiony, należy połączyć Object Lock z S3 Replication. Replikowane obiekty zachowują swoją konfigurację blokady w buckecie docelowym (który również musi mieć włączony Object Lock), dzięki czemu awaria w całym regionie lub złośliwa próba usunięcia nie naruszy chronionej kopii.

Macie i Athena do wykrywania i analizy

Amazon Macie używa zarządzanych i niestandardowych identyfikatorów danych do skanowania obiektów S3 w poszukiwaniu danych PII, PHI, poświadczeń i innych wrażliwych wzorców. Zgłasza wyniki do Security Hub i EventBridge, umożliwiając zautomatyzowane działania naprawcze, takie jak poddawanie obiektów kwarantannie za pomocą restrykcyjnej polityki bucketu opartej na tagach. Należy włączyć Macie w każdym regionie, w którym przechowywane są dane klientów, i delegować administrację poprzez AWS Organizations w celu centralizacji wyników.

Amazon Athena umożliwia bezserwerowe wykonywanie zapytań SQL na danych w S3 i jest standardowym narzędziem do odpytywania zdarzeń danych na poziomie obiektów CloudTrail. Aby zbadać, kto uzyskał dostęp do określonego obiektu S3, należy włączyć zdarzenia danych CloudTrail dla danego bucketu, dostarczać logi do centralnego bucketu S3 i odpytywać je za pomocą Atheny:

SELECT eventTime, userIdentity.arn, sourceIPAddress, requestParameters
FROM cloudtrail_logs
WHERE eventName IN ('GetObject','DeleteObject')
  AND requestParameters LIKE '%reports/q3-financials.pdf%'
  AND eventTime > '2024-01-01T00:00:00Z';

Skonsolidowane pułapki i ich podstawowe przyczyny

Brak /* w ARN-ach obiektów: Wywołania API na poziomie obiektu są oceniane względem bucket/key, a nie ARN zasobnika. Bez /* żadna instrukcja nie pasuje, a IAM zwraca niejawne odrzucenie (implicit deny) — co objawia się jako nieoczekiwane błędy 403 przy GetObject, nawet gdy zasobnik wydaje się dozwolony.
Dodanie reguły Allow po jawnym Deny: Ewaluacja polityk IAM nie zależy od kolejności; każda pasująca reguła Deny natychmiast skutkuje odmową. Rozwiązaniem jest zawężenie zakresu reguły Deny (za pomocą Condition, NotPrincipal lub NotResource), a nie dołączanie kolejnych zezwoleń.
CloudFront bez OAC lub restrykcyjnej polityki zasobnika: Adres URL źródła S3 pozostaje bezpośrednio osiągalny, omijając podpisane adresy URL, reguły WAF i geo-restrykcje. Zawsze włączaj BPA na zasobniku źródłowym i ogranicz s3:GetObject do jednostki głównej usługi (service principal) CloudFront za pomocą AWS:SourceArn.
Zakładanie, że Object Lock można włączyć na istniejącym zasobniku: Object Lock musi być skonfigurowany podczas tworzenia zasobnika. Dostosowanie istniejącego zasobnika wymaga utworzenia nowego z włączonym Object Lock i migracji danych.
Mylenie trybu governance z trybem compliance: Tryb governance nie powstrzyma uprzywilejowanego użytkownika przed usunięciem retencji; tylko tryb compliance blokuje nawet konto root.

Praktyczny problem: Scenariusz użycia

Scenariusz: Meridian Financial przechowuje wyciągi klientów, logi transakcji i długoterminowe archiwa zgodności w wielu zasobnikach S3 w dwóch regionach AWS. Ich środowisko wykorzystuje CloudFront do portali klienckich, logowanie międzykontowe oraz zautomatyzowane przejścia cyklu życia do archiwalnych klas pamięci masowej w celu retencji regulacyjnej.

Wyzwanie: Niedawny audyt wewnętrzny wykazał, że kilka zasobników ma niespójne polityki ujawniające dane PII, brak niezmiennej retencji dla zarchiwizowanych rekordów oraz brak scentralizowanego sposobu na odkrywanie, gdzie znajdują się wrażliwe obiekty na różnych kontach i w różnych regionach.

Zalecane podejście:

Włącz S3 Block Public Access na poziomie konta i zasobnika oraz wdróż CloudFront Origin Access Control (OAC); zaostrz politykę zasobnika, aby zezwalała na GetObject tylko z jednostki głównej OAC CloudFront, używając precyzyjnych ARN-ów zasobów, i dodaj jawne reguły Deny dla każdego żądania, które nie pochodzi przez OAC.
Wymuś szyfrowanie po stronie serwera za pomocą AWS KMS, wymagając kms:Encrypt/kms:GenerateDataKey w polityce zasobnika i dodaj jawne reguły Deny dla żądań PutObject, które nie zawierają nagłówka x-amz-server-side-encryption i wymaganego kms:context, aby zapobiec niezaszyfrowanemu przesyłaniu danych.
Skonfiguruj S3 Object Lock w trybie compliance dla zasobników, które muszą być niezmienne, i włącz Cross-Region Replication (CRR) z regułami replikacji, które zachowują metadane blokady obiektu, aby zreplikowane obiekty pozostały niezmienne w regionie DR.
Utwórz reguły cyklu życia S3 (Lifecycle Rules), aby przenosić starsze obiekty do klas pamięci masowej S3 Glacier i ustawić wygasanie obiektów dla dozwolonych okien retencji; dla archiwów, które muszą być prawnie niezmienne, umieść je w skarbcach Amazon S3 Glacier i zastosuj polityki Glacier Vault Lock, aby wymusić retencję typu WORM (write-once).
Wdróż Amazon Macie na wszystkich kontach, aby odkrywać i klasyfikować dane PII, włącz S3 Inventory i przeszukuj wyniki za pomocą Amazon Athena w celu prowadzenia zapytań śledczych, a także uruchamiaj zautomatyzowane działania naprawcze (Lambda/Step Functions) w celu tagowania, poddawania kwarantannie lub przenoszenia wrażliwych obiektów do zablokowanych, zaszyfrowanych zasobników.

Uzasadnienie: To warstwowe podejście wymusza zasadę najmniejszych uprawnień i szyfrowanie, zapewnia niezmienną retencję i trwałość międzyregionalną w celu zapewnienia zgodności oraz wykorzystuje Macie/Athena do scentralizowanego odkrywania i zautomatyzowanych działań naprawczych — co jest zgodne z najlepszymi praktykami AWS w zakresie ochrony danych i zarządzania ich cyklem życia.

Amazon Macie: Automatyczne odkrywanie, zadania klasyfikacji i listy dozwolonych

Amazon Macie to zarządzana usługa bezpieczeństwa danych, która wykorzystuje uczenie maszynowe i dopasowywanie wzorców do odkrywania danych wrażliwych — danych osobowych (PII), numerów kart płatniczych (PAN), poświadczeń i niestandardowych typów danych zdefiniowanych za pomocą wyrażeń regularnych (regex) — przechowywanych w Amazon S3. Macie działa w dwóch uzupełniających się trybach, które są często mylone.

Automatyczne odkrywanie danych wrażliwych to niskokosztowy, stale działający proces, który próbkuje obiekty we wszystkich zasobnikach na koncie (lub w całej organizacji, gdy Macie jest delegowany na konto bezpieczeństwa). Buduje on ocenę wrażliwości i inwentarz dla każdego zasobnika. Jest to właściwy punkt wyjścia, gdy masz tysiące zasobników i jeszcze nie wiesz, gdzie znajdują się dane wrażliwe, ponieważ minimalizuje koszty i narzut administracyjny poprzez próbkowanie, a nie skanowanie każdego obiektu.

Zadania klasyfikacji (zadania odkrywania danych wrażliwych) to jednorazowe lub zaplanowane głębokie skanowania ukierunkowane na określone zasobniki. Gdy automatyczne odkrywanie oznaczy zasobnik jako zawierający dane wrażliwe, tworzysz zadanie klasyfikacji ograniczone do tego zasobnika w celu przeprowadzenia wyczerpującej analizy. Kanoniczny wzorzec jest zatem następujący: włącz automatyczne odkrywanie w całej organizacji, a następnie uruchamiaj zadania klasyfikacji tylko dla oznaczonych zasobników.

Listy dozwolonych (Allow lists) to mechanizm pomijania znanych, nieszkodliwych dopasowań. Jeśli data lake zawiera syntetyczne, testowe numery PAN (na przykład dobrze znany zakres kart testowych 4111 1111 1111 1111), Macie oznaczy każde ich wystąpienie. Przepisywanie lub przenoszenie danych jest kosztowne i zakłócające pracę; właściwym podejściem jest zdefiniowanie listy dozwolonych w Macie — jako listy dokładnych wartości w postaci zwykłego tekstu lub wyrażenia regularnego (regex) — i powiązanie jej z zadaniami klasyfikacji oraz konfiguracją automatycznego odkrywania. Dopasowania z listy dozwolonych są wykluczane z wyników, podczas gdy prawdziwe numery PAN nadal wywołują alerty.

Problem praktyczny: Scenariusz użycia

Scenariusz: Firma Meridian Financial zarządza środowiskiem AWS z wieloma kontami, w którym setki bucketów S3 przechowują logi transakcji, dokumenty klientów i długoterminowe archiwa przeniesione do S3 Glacier. Ich zespół ds. bezpieczeństwa wdrożył podstawowe szyfrowanie i logowanie, ale brakuje mu scentralizowanego mechanizmu wykrywania danych wrażliwych oraz spójnych kontroli retencji między kontami.

Wyzwanie: Niedawno odkryto publicznie dostępny bucket, który zawierał zarchiwizowane dane klientów z PII (dane osobowe) w wyniku błędnej polityki bucketa i przejścia cyklu życia do S3 Glacier. Meridian musi teraz znaleźć wszystkie dane wrażliwe, usunąć zagrożenia i wdrożyć zgodne z przepisami zasady retencji dla archiwów.

Zalecane podejście:

Włącz Amazon Macie w całej organizacji AWS i uruchom automatyczne wykrywanie w S3, aby Macie stale oceniało buckety i obiekty pod kątem danych wrażliwych i ryzykownych konfiguracji.
Utwórz zadania klasyfikacji Macie (classification jobs) skierowane na wszystkie buckety S3; skonfiguruj niestandardowe identyfikatory danych wrażliwych (custom sensitive data identifiers) dla numerów SSN i numerów kont oraz ustaw listy dozwolonych (allow lists), aby wykluczyć znane dane testowe, pliki dostawców i konta usług.
Użyj S3 Inventory do wyliczenia obiektów w S3 Glacier, a następnie uruchom S3 Batch Operations, aby tymczasowo przywrócić tylko te obiekty, które zostały oznaczone przez inventory do skanowania przez Macie, tak aby zadania klasyfikacji mogły zbadać zawartość zarchiwizowaną w Glacier.
Zautomatyzuj naprawę (remediation), wysyłając wyniki (findings) z Macie do Amazon EventBridge i Security Hub; uruchamiaj funkcje Lambda, aby stosować bezpieczne polityki bucketów S3, włączać S3 Block Public Access, usuwać publiczne listy ACL i oznaczać buckety do przeglądu.
Wdróż trwałą retencję i prewencję: włącz S3 Versioning i S3 Object Lock (w trybach governance/compliance) na krytycznych bucketach, wymuś SSE-KMS z kluczami CMK za pomocą polityki bucketa i wdróż SCP w AWS Organizations, aby blokować publiczne listy ACL i wymagać szyfrowania oraz Object Lock tam, gdzie to konieczne.
Włącz zdarzenia danych (data events) CloudTrail dla S3 i przesyłaj wyniki do systemu SIEM w celu alertowania oraz okresowego planowania zadań klasyfikacji Macie, aby zapewnić ciągłość monitorowania.

Uzasadnienie: To podejście wykorzystuje Macie do automatycznego wykrywania i ukierunkowanej klasyfikacji (z listami dozwolonych), przywraca obiekty z Glacier tylko wtedy, gdy jest to konieczne do inspekcji, automatyzuje naprawę za pomocą EventBridge/Lambda oraz wymusza niezmienną retencję i szyfrowanie za pomocą Object Lock i KMS — co jest zgodne z najlepszymi praktykami AWS w zakresie wykrywania, naprawy i kontroli prewencyjnych.

# Example allow list (regex form) matching common test PANs
Type: Regex
Regex: '^4111[- ]?1111[- ]?1111[- ]?1111$|^5555[- ]?5555[- ]?5555[- ]?4444$'
Name: synthetic-test-pans

Traktowanie surowych wyników z Macie jako ostatecznej prawdy, bez konfigurowania list dozwolonych (allow lists) lub list pomijania (suppression lists), prowadzi do zmęczenia alertami (alert fatigue) i może ukryć prawdziwe incydenty w szumie generowanym przez dane syntetyczne — dlatego proste „ufanie wynikom” jest niewłaściwą odpowiedzią w środowiskach z dużą liczbą fałszywych alarmów (false-positives).

Integracja wyników Macie z EventBridge

Macie publikuje każdy wynik (finding) w Amazon EventBridge w źródle (source) aws.macie. Pozwala to na przekierowywanie wyników bez odpytywania API Macie. Typowa reguła przekazuje wyniki typu Policy do SNS w celu powiadamiania dyżurnego zespołu (on-call paging) i wysyła wyniki typu SensitiveData do AWS Security Hub w celu agregacji.

{
  "source": ["aws.macie"],
  "detail-type": ["Macie Finding"],
  "detail": { "severity": { "description": ["High"] } }
}

Celami (targets) reguły mogą być tematy SNS, Security Hub lub funkcja Lambda do niestandardowej naprawy (np. automatycznego zastosowania restrykcyjnej polityki na problematycznym buckecie).

Warunki w polityce bucketa dla granic organizacji

S3 Block Public Access (BPA) blokuje jedynie dostęp pochodzący z publicznego internetu lub od anonimowych podmiotów (principals). Nie zapobiega to dostępowi do bucketa przez uwierzytelniony podmiot z innego konta AWS lub innej organizacji AWS, jeśli polityka bucketa lub ACL na to zezwala. Dlatego poleganie wyłącznie na BPA jest nieprawidłowe, gdy wymaganiem jest zapobieganie dostępowi między organizacjami — należy połączyć polityki bucketów z Service Control Policies (SCPs) na poziomie AWS Organizations.

Dwa klucze warunkowe IAM (condition keys) umożliwiają precyzyjne egzekwowanie granic organizacji:

aws:ResourceOrgID: ID organizacji, która jest właścicielem zasobu, do którego uzyskiwany jest dostęp. Używany w politykach tożsamości/SCP, aby zabronić podmiotom dostępu do zasobów spoza Twojej organizacji.
aws:PrincipalOrgID: ID organizacji wywołującego podmiotu. Używany w politykach bucketów, aby zabronić dostępu podmiotom spoza Twojej organizacji.
aws:SourceOrgPaths: Ścieżka OU podmiotu źródłowego, pozwalająca na zawężenie zakresu do konkretnej jednostki organizacyjnej (OU) (np. tylko OU „Production” może zapisywać do bucketa zgodności).

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "DenyOutsideOrg",
    "Effect": "Deny",
    "Principal": "*",
    "Action": ["s3:GetObject", "s3:DeleteObject"],
    "Resource": "arn:aws:s3:::acme-compliance/*",
    "Condition": {
      "StringNotEqualsIfExists": {
        "aws:PrincipalOrgID": "o-abcd1234",
        "aws:SourceOrgPaths": "o-abcd1234/r-root/ou-prod-xyz/"
      }
    }
  }]
}

Połącz to z polityką SCP, która odmawia akcji s3:DeleteObject* na zasobach, gdzie aws:ResourceOrgID nie pasuje do ID Twojej organizacji, a eksfiltracja lub usuwanie danych między organizacjami stanie się niemożliwe, nawet jeśli polityka bucketa zostanie przypadkowo złagodzona.

S3 Object Lock: Tryb Compliance i wersjonowanie

Object Lock wymusza semantykę WORM (write-once-read-many) na poszczególnych wersjach obiektów. Wymaga, aby na buckecie włączone było wersjonowanie S3 (S3 Versioning) (Object Lock bez wersjonowania nie jest możliwy — blokada chroni konkretny identyfikator wersji, a nie klucz obiektu).

Tryb Governance (Governance mode): użytkownicy z uprawnieniem s3:BypassGovernanceRetention mogą skracać lub usuwać retencję. Odpowiedni do egzekwowania wewnętrznych polityk.
Tryb Compliance (Compliance mode): żaden podmiot, włączając w to użytkownika root konta AWS, nie może skrócić, usunąć ani wykasować wersji obiektu, dopóki nie upłynie okres retencji. Jest to właściwy wybór dla wymogów regulacyjnych dotyczących niezmienności (np. SEC 17a-4, FINRA, archiwizacja HIPAA).

Retencję można ustawić dla pojedynczego obiektu (data Retain-Until) lub poprzez domyślną konfigurację retencji na poziomie bucketa. Blokady prawne (Legal Holds) to oddzielne, bezterminowe blokady, które obowiązują do momentu ich jawnego usunięcia przez podmiot posiadający uprawnienie s3:PutObjectLegalHold.

aws s3api put-object-retention \
  --bucket acme-audit-logs \
  --key 2024/transactions.parquet \
  --retention '{"Mode":"COMPLIANCE","RetainUntilDate":"2031-01-01T00:00:00Z"}'

S3 Glacier Vault Lock: Poprawianie błędów w polityce przed finalizacją blokady

Vault Lock w S3 Glacier wymusza niezmienne polityki dostępu do sejfu. Proces składa się z dwóch wywołań: initiate-vault-lock wprowadza politykę w stan w toku (in-progress) na 24-godzinne okno, a complete-vault-lock czyni ją trwałą. Jeśli w ciągu 24-godzinnego okna zostanie odkryta literówka — na przykład zbyt liberalny Principal — prawidłowym i najtańszym sposobem naprawy jest:

aws glacier abort-vault-lock --account-id - --vault-name compliance-archive
aws glacier initiate-vault-lock --account-id - --vault-name compliance-archive \
  --policy file://corrected-policy.json

abort-vault-lock anuluje blokadę w stanie „in-progress” bez żadnych kosztów, pozwalając na ponowne zainicjowanie procesu z poprawioną polityką. Alternatywne „naprawy” — takie jak usunięcie i ponowne utworzenie sejfu (co wymagałoby usunięcia wszystkich 10 TB archiwów i ponownego ich przesłania, generując opłaty za odzyskiwanie i transfer) lub oczekiwanie na finalizację blokady i próba jej obejścia — są nieefektywne lub niemożliwe. Po uruchomieniu complete-vault-lock polityka staje się trwale niezmienna; anulowanie jest możliwe tylko w trakcie okna „in-progress”.

Podobna pułapka: Łańcuch zaufania DNSSEC

Częstą pułapką dotyczącą wielu domen jest DNSSEC w usłudze Route 53. Włączenie podpisywania DNSSEC dla strefy hostowanej (hosted zone) dla subdomeny generuje klucz do podpisywania kluczy (Key Signing Key, KSK) oraz odpowiadający mu rekord DS. Ten rekord DS musi zostać opublikowany w strefie nadrzędnej (parent zone); bez niego resolwery nie mogą zweryfikować łańcucha zaufania i albo traktują odpowiedzi jako fałszywe, albo wracają do niezabezpieczonego rozwiązywania nazw, co psuje działanie DNS dla klientów weryfikujących. Włączenie podpisywania bez wyeksportowania rekordu DS i wstawienia go u rejestratora lub w strefie nadrzędnej jest stanem niekompletnej konfiguracji, a nie działającym wdrożeniem DNSSEC.

← Szyfrowanie · Wszystkie domeny · Bezpieczeństwo sieci i VPC →

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

Pass the whole exam — not just this question

You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.

Zdaj egzamin →

Przeglądaj Amazon →