Amazon SAA-C03: Bezpieczeństwo, IAM, KMS i nadzór — Przewodnik do nauki

By Laurynas Brazys · 18 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

Część AWS SAA-C03 — Kompletny przewodnik do nauki. Ćwicz ze zweryfikowanymi odpowiedziami w centrum egzaminów Amazon, albo rozwiąż testy na czas na ExamRoll.io.

Podstawy tożsamości: użytkownicy, root, grupy i role

Zarządzanie tożsamością i dostępem (Identity and Access Management) to płaszczyzna kontroli, przez którą przechodzi każdy workload, a jego nadrzędną zasadą jest zasada najmniejszych uprawnień (least privilege): przyznawaj tylko to, co jest niezbędne, tylko na tak długo, jak jest to potrzebne, i preferuj tożsamości, które generują poświadczenia o krótkim czasie życia, zamiast tych przechowujących statyczne sekrety.

Użytkownik root jest właścicielem konta, posiada nieograniczone uprawnienia i nie może być ograniczony przez polityki IAM ani SCP. To czyni go pojedynczym najbardziej wrażliwym poświadczeniem w środowisku i powinien być traktowany jako dostęp awaryjny (break-glass). Na nowym koncie: włącz sprzętowe lub wirtualne urządzenie MFA dla roota, ustaw długie, unikalne hasło, usuń wszelkie historyczne klucze dostępu roota i zarejestruj alternatywne kontakty do spraw rozliczeń, operacji i bezpieczeństwa, aby umożliwić odzyskiwanie konta. Po początkowej konfiguracji — utworzeniu tożsamości administratora IAM, skonfigurowaniu rozliczeń i ustawieniu aliasu konta — użytkownik root nie jest ponownie używany, z wyjątkiem wąskiego zestawu zadań, do których AWS jawnie go wymaga (zamykanie konta, zmiana nazwy konta, przywracanie usuniętych uprawnień IAM, włączanie MFA Delete i kilka operacji w S3/CloudFront wymagających podpisu roota). Używanie roota do codziennej pracy jest błędem, ponieważ nie może być on ograniczony przez polityki, jego działania są trudne do przypisania w CloudTrail, gdy jest współdzielony, a pojedyncze naruszenie bezpieczeństwa daje nieodwracalną kontrolę.

Codzienny dostęp dla ludzi odbywa się poprzez tożsamości IAM ograniczone politykami najmniejszych uprawnień. Dołączaj zarządzane polityki do grup, a nie do poszczególnych użytkowników: grupa Administrators z dołączoną polityką AdministratorAccess i umieszczeni w niej imienni użytkownicy zapewniają jeden punkt do wprowadzania zmian i pozwalają uniknąć antywzorca polegającego na przypinaniu identycznych polityk do każdego użytkownika. Ograniczaj zasoby za pomocą jawnych numerów ARN, a nie *.

Role służą zupełnie innemu celowi. Są one przyjmowane (ang. assumed) przez podmioty (principals) — usługi, instancje EC2, funkcje Lambda, sfederowanych użytkowników, podmioty wywołujące z innych kont — i generują tymczasowe poświadczenia STS, które rotują się automatycznie. Ponieważ te poświadczenia nie mogą wyciec w commicie Git i wygasają w ciągu minut lub godzin, zamiast istnieć do czasu ręcznej rotacji, role są domyślną tożsamością dla wszystkiego, co nie jest człowiekiem.

Dwie polityki dla każdej roli: uprawnień i zaufania

Każda rola jest zarządzana przez dwa niezależne dokumenty, a zapomnienie o którymkolwiek z nich jest klasycznym błędem.

Polityka uprawnień (oparta na tożsamości) deklaruje, co rola może zrobić po jej przyjęciu. Polityka zaufania (oparta na zasobie, dołączona do samej roli) deklaruje, kto może ją przyjąć. Dołączenie AmazonS3ReadOnlyAccess do roli nic nie da, jeśli żaden podmiot nie ma pozwolenia na wywołanie na niej sts:AssumeRole, i odwrotnie, liberalna polityka zaufania bez polityki uprawnień tworzy rolę, którą można przyjąć, ale która nie robi nic użytecznego.

Rola wykonawcza Lambda (execution role) pokazuje wzorzec service-principal — to sama usługa, a nie właściciel konta, jest podmiotem wywołującym:

AssumeRolePolicyDocument:              # trust policy
  Version: "2012-10-17"
  Statement:
    - Effect: Allow
      Principal: { Service: lambda.amazonaws.com }
      Action: sts:AssumeRole
Policies:                              # permissions
  - PolicyName: ReadOrders
    PolicyDocument:
      Statement:
        - Effect: Allow
          Action: dynamodb:GetItem
          Resource: arn:aws:dynamodb:*:*:table/Orders

Tożsamość dla workloadów: Instance Profiles, Task Roles, IRSA, Roles Anywhere

Każde poświadczenie, które znajduje się w szablonie, zmiennej środowiskowej lub na laptopie, to przyszłe naruszenie bezpieczeństwa. Kanoniczny wzorzec AWS zastępuje statyczne klucze dostępu poświadczeniami o krótkim czasie życia, automatycznie rotowanymi i dostarczanymi za pośrednictwem ról.

Dla EC2 mechanizmem dostarczania jest instance profile — lekki kontener, który wiąże rolę IAM z instancją, aby usługa metadanych instancji (IMDSv2) mogła udostępniać tymczasowe poświadczenia dla SDK. Domyślny łańcuch dostawców poświadczeń (credential provider chain) odnajduje je bez konfiguracji, więc boto3.client('s3') po prostu działa, a kod aplikacji nigdy nie widzi poświadczeń. Należy wymusić użycie IMDSv2 (HttpTokens: required), aby zapobiec eksfiltracji poświadczeń za pomocą ataków SSRF. Poświadczenia rotują się mniej więcej co sześć godzin, a ich unieważnienie to prosta edycja roli.

AppRole:
  Type: AWS::IAM::Role
  Properties:
    AssumeRolePolicyDocument:
      Statement:
        - Effect: Allow
          Principal: { Service: ec2.amazonaws.com }
          Action: sts:AssumeRole
    Policies:
      - PolicyName: S3DocAccess
        PolicyDocument:
          Statement:
            - Effect: Allow
              Action: [s3:GetObject, s3:PutObject]
              Resource: arn:aws:s3:::docs-bucket/*
AppInstanceProfile:
  Type: AWS::IAM::InstanceProfile
  Properties:
    Roles: [!Ref AppRole]

Dla ECS analogią jest task role; dla Lambda jest to execution role; dla podów EKS jest to IRSA (IAM Roles for Service Accounts) lub EKS Pod Identity. W każdym przypadku to sam AWS pośredniczy w dostarczaniu poświadczeń w oparciu o rolę, a workload nigdy nie widzi długoterminowego sekretu.

Zaszywanie kluczy dostępu w obrazie AMI, skrypcie user-data lub pliku .env jest błędem z trzech konkretnych powodów: klucze nigdy nie rotują się automatycznie, nie można ich ograniczyć do kontekstu sesji, jak np. źródłowy VPC endpoint, a jeśli instancja zostanie skompromitowana lub obraz AMI zostanie przypadkowo udostępniony, poświadczenie wycieka na stałe.

Dla workloadów poza AWS — serwerów on-premise, innych chmur, runnerów CI — które potrzebują tymczasowych poświadczeń AWS bez zaszytych kluczy, IAM Roles Anywhere wykorzystuje certyfikaty X.509 z prywatnego urzędu certyfikacji (AWS Private CA lub własnego) jako kotwicę zaufania (trust anchor). Workload przedstawia swój certyfikat kliencki i otrzymuje poświadczenia STS o krótkim czasie życia:

aws_signing_helper credential-process \
  --certificate /etc/pki/client.pem \
  --private-key /etc/pki/client.key \
  --trust-anchor-arn arn:aws:rolesanywhere:...:trust-anchor/... \
  --profile-arn arn:aws:rolesanywhere:...:profile/... \
  --role-arn arn:aws:iam::111122223333:role/OnPremWorkload

To rozwiązuje ten sam antywzorzec, który wewnątrz AWS rozwiązują role instancji i Secrets Manager.

Dostęp dla ludzi na dużą skalę: Identity Center, SAML, Directory Service

Tworzenie użytkowników IAM na każdym koncie osobno jest niemożliwe do zarządzania w dużej skali. AWS IAM Identity Center (następca AWS SSO) jest zalecanym punktem wejścia dla dostępu pracowników: pojedynczy katalog, który federuje się z każdym kontem w organizacji i wydaje tymczasowe sesje oparte na rolach za pomocą zestawów uprawnień (permission sets) — szablonowych ról IAM mapowanych na grupy z dostawcy tożsamości (IdP). Użytkownicy uwierzytelniają się raz w portalu Identity Center, a następnie przyjmują zestawy uprawnień na dowolnym przypisanym koncie.

Identity Center integruje się z zewnętrznymi dostawcami tożsamości (IdP), takimi jak Okta, Entra ID/Azure AD, Google Workspace, ADFS, za pomocą SAML 2.0 i SCIM w celu automatyzacji procesów dołączania, przenoszenia i usuwania pracowników (joiner/mover/leaver), oraz z lokalnym Active Directory za pośrednictwem AWS Directory Service AD Connector (proxy) lub AWS Managed Microsoft AD (pełna replika w AWS). W przypadku aplikacji mobilnych lub webowych, które muszą wywoływać AWS w imieniu nieuwierzytelnionych użytkowników lub użytkowników uwierzytelnionych przez strony trzecie, Amazon Cognito wymienia tożsamość zewnętrzną na tymczasowe poświadczenia STS, ponownie unikając zaszywania długoterminowych kluczy.

Dostęp Międzykontowy

Dostęp międzykontowy jest realizowany za pomocą ról, a nie współdzielonych użytkowników, i obie strony muszą wyrazić na niego zgodę. Konto docelowe (B) tworzy rolę, której polityka zaufania wskazuje na konto A (lub konkretny podmiot w nim), a wywołujący w koncie A musi również posiadać uprawnienie sts:AssumeRole skierowane na ARN tej roli. Żadna ze stron samodzielnie nie jest wystarczająca. Taki mechanizm generuje krótkotrwałe poświadczenia i pozostawia czytelny ślad audytowy w CloudTrail na obu kontach.

Gdy podmiotem przejmującym rolę jest strona trzecia (np. dostawca SaaS), dodaj warunek ExternalId, aby zapobiec problemowi zdezorientowanego zastępcy (confused deputy problem), i rozważ wymuszenie MFA:

{
  "Effect": "Allow",
  "Principal": { "AWS": "arn:aws:iam::222222222222:root" },
  "Action": "sts:AssumeRole",
  "Condition": {
    "StringEquals": { "sts:ExternalId": "a1b2c3-unique-token" },
    "Bool": { "aws:MultiFactorAuthPresent": "true" }
  }
}

W przypadku wywołań międzykontowych usługa-usługa, zadanie to realizują polityki zasobów. Aby umożliwić tematowi SNS na koncie A wywołanie funkcji Lambda na koncie B:

aws lambda add-permission \
  --function-name ProcessNotification \
  --statement-id AllowSNSInvoke \
  --action lambda:InvokeFunction \
  --principal sns.amazonaws.com \
  --source-arn arn:aws:sns:us-east-1:111111111111:my-topic

--principal sns.amazonaws.com to service principal (sama usługa SNS wywołuje Lambdę), a --source-arn ogranicza zaufanie do konkretnego tematu, aby zapobiec problemowi zdezorientowanego zastępcy.

W przypadku udostępniania S3 w obrębie Organizacji, naiwne podejście — wymienienie ARN każdego konta w polityce bucketa — nie skaluje się i przestaje działać za każdym razem, gdy dodawane jest nowe konto. Prawidłowym wzorcem jest aws:PrincipalOrgID:

{
  "Effect": "Allow",
  "Principal": "*",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::reports-bucket/*",
  "Condition": {
    "StringEquals": { "aws:PrincipalOrgID": "o-abcd1234ef" }
  }
}

Każdy podmiot na dowolnym koncie w tej organizacji jest dozwolony; każdy inny jest odrzucany. Zauważ, że Principal: "*" bez tego warunku oznaczałoby publiczny bucket — to klucz warunku (condition key) ogranicza zakres. Strona tożsamości wciąż ma znaczenie: użytkownicy na kontach członkowskich również potrzebują uprawnienia s3:GetObject nadanego przez ich własną politykę IAM (chyba że są użytkownikiem root konta), ponieważ dostęp międzykontowy wymaga, aby obie strony zezwoliły na wywołanie.

W przypadku S3, od 2023 roku domyślne ustawienie Object Ownership, Bucket owner enforced, całkowicie wyłącza listy ACL, czyniąc polityki bucketa jedynym mechanizmem autoryzacji dla danego bucketa. Jeśli obiekty były wcześniej przesyłane przez inne konta, historyczne listy ACL obiektów lub predefiniowana lista ACL bucket-owner-full-control mogą nadal obowiązywać.

Organizations i Polityki Kontroli Usług (SCP)

AWS Organizations grupuje konta w drzewo jednostek organizacyjnych (OU) z kontem zarządzającym (management account) w korzeniu. Polityki Kontroli Usług (Service Control Policies) to bariery ochronne dołączane do korzenia, jednostki organizacyjnej (OU) lub pojedynczego konta. Obowiązują one każdego użytkownika i rolę IAM na koncie — włączając w to użytkownika root konta — ale nie samo konto zarządzające, dlatego nigdy nie powinno się na nim uruchamiać obciążeń roboczych.

Kluczowy model myślowy: SCP nigdy nie nadają uprawnień. Definiują one maksymalny zbiór dozwolonych działań na koncie. Działanie jest dozwolone tylko wtedy, gdy jest nadane przez politykę tożsamości lub zasobu oraz nie jest blokowane przez żadne SCP na ścieżce danego konta. Jeśli deweloper ma AdministratorAccess, ale SCP zabrania ec2:RunInstances poza regionem ap-southeast-2, próba uruchomienia instancji w us-east-1 zakończy się niepowodzeniem. I odwrotnie, SCP zezwalające na s3:* samo w sobie nic nie robi — użytkownik nadal potrzebuje polityki IAM nadającej s3:*. SCP filtrują to, na co IAM już zezwolił; są to sufity, a nie podłogi.

Typowe zastosowania SCP obejmują blokadę regionów, zakaz wyłączania CloudTrail lub GuardDuty, zakaz usuwania kluczy KMS poza rolą typu ‘break-glass’ oraz wymuszanie szyfrowania. Aby wymusić szyfrowanie EBS podczas uruchamiania, połącz dwa mechanizmy: włącz domyślne szyfrowanie EBS w regionie (jest to ustawienie per-region na koncie, aby użytkownicy nie musieli zmieniać skryptów) oraz dodaj SCP jako audytowalną barierę ochronną:

{
  "Effect": "Deny",
  "Action": "ec2:RunInstances",
  "Resource": "arn:aws:ec2:*:*:volume/*",
  "Condition": { "Bool": { "ec2:Encrypted": "false" } }
}

Ponieważ SCP obowiązują na całym koncie, nie mogą zostać ominięte przez administratora ze złamanymi zabezpieczeniami na koncie członkowskim. Polityki tagów wymuszają standaryzowane klucze tagów i wielkość liter (np. CostCenter, a nie costcenter), dzięki czemu alokacja kosztów i ABAC działają niezawodnie. Organizations wspiera również administrację delegowaną: zamiast uruchamiać usługi bezpieczeństwa z konta zarządzającego, można delegować konto członkowskie (np. konto “security” lub “audit”) jako administratora dla usług GuardDuty, Security Hub, IAM Access Analyzer czy Config — zachowując rozdział obowiązków.

KMS: Klucze, polityki kluczy i modele własności

KMS rozróżnia materiał klucza na podstawie własności i kontroli:

Klucz CMK jest zarządzany przez politykę klucza — politykę opartą na zasobach, dołączoną do klucza. W przeciwieństwie do prawie każdego innego zasobu AWS, same polityki IAM nie mogą przyznać dostępu do klucza KMS, chyba że polityka klucza najpierw deleguje uprawnienia do IAM:

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

Bez tej instrukcji żadna polityka IAM nie umożliwi użycia klucza. Zarówno polityka klucza, jak i polityka IAM wywołującego muszą zezwalać na daną operację — to najczęstszy pojedynczy błąd związany z szyfrowaniem. Nadanie uprawnienia kms:Decrypt w polityce IAM jest konieczne, ale niewystarczające; jeśli polityka klucza nie deleguje uprawnień do IAM lub nie wymienia podmiotu (principal), deszyfrowanie kończy się błędem AccessDenied, nawet dla administratora.

W przypadku usług, które używają KMS w Twoim imieniu (EBS, S3, RDS, Lambda), rola wywołująca zazwyczaj potrzebuje uprawnień kms:GenerateDataKey, kms:Decrypt i często kms:CreateGrant. Dla zarządzanej grupy węzłów EKS szyfrującej woluminy EBS za pomocą klucza CMK, rola powiązana z usługą Auto Scaling (service-linked role) musi być uwzględniona w polityce klucza z uprawnieniem kms:CreateGrant, w przeciwnym razie uruchamianie instancji po cichu zakończy się niepowodzeniem.

Rotacja kluczy CMK zarządzanych przez klienta wymaga jawnego włączenia — wielu praktyków błędnie zakłada, że wszystkie klucze KMS rotują automatycznie:

aws kms enable-key-rotation --key-id alias/my-cmk
aws kms get-key-rotation-status --key-id alias/my-cmk

Rotacja zachowuje ten sam identyfikator (ID) i alias klucza; zmienia się materiał kryptograficzny, ale wcześniejsze szyfrogramy pozostają możliwe do odszyfrowania, ponieważ KMS przechowuje stary materiał do deszyfrowania istniejących szyfrogramów, podczas gdy nowe operacje zapisu używają świeżego materiału. Zaimportowany materiał nigdy nie rotuje automatycznie. KMS wymusza obowiązkowe okno oczekiwania na usunięcie trwające od 7 do 30 dni; połącz to z regułą EventBridge dopasowującą ScheduleKeyDeletion lub DisableKey w CloudTrail i skieruj ją na temat SNS, aby stworzyć bezserwerowy wzorzec alertowania bez odpytywania (poll-free):

{
  "source": ["aws.kms"],
  "detail-type": ["AWS API Call via CloudTrail"],
  "detail": { "eventName": ["ScheduleKeyDeletion", "DisableKey"] }
}

External Key Stores rozszerzają ten model, gdy organy regulacyjne wymagają, aby materiał klucza fizycznie znajdował się w HSM kontrolowanym przez klienta. KMS przekazuje operacje kryptograficzne do proxy XKS, które komunikuje się z HSM on-premise; jeśli HSM jest offline, deszyfrowanie kończy się niepowodzeniem — odpowiedzialność za dostępność spoczywa na kliencie.

Klucze wieloregionowe (MRK) współdzielą ten sam identyfikator (ID) i materiał klucza pomiędzy regionami, dzięki czemu szyfrogram utworzony w us-east-1 może być bezpośrednio odszyfrowany w eu-west-1. Jest to prawidłowy wzorzec dla DynamoDB Global Tables, replikacji międzyregionalnej S3 (Cross-Region Replication) z SSE-KMS oraz scenariuszy DR, w których zapasowy region musi odczytywać zaszyfrowane kopie zapasowe. Standardowe klucze jednoregionowe wymagałyby odszyfrowania i ponownego zaszyfrowania w momencie replikacji.

Międzykontowe udostępnianie zaszyfrowanych zasobów

Udostępnianie zaszyfrowanych obrazów AMI i snapshotów EBS to jeden z najczęstszych powodów niepowodzeń w operacjach międzykontowych, ponieważ wymaga czterech skoordynowanych działań: (1) użycia klucza CMK zarządzanego przez klienta — klucze zarządzane przez AWS nie mogą być udostępniane; (2) dodania konta docelowego jako podmiotu (principal) w polityce klucza z uprawnieniami kms:Decrypt, kms:DescribeKey, kms:CreateGrant i kms:ReEncrypt*; (3) zmodyfikowania uprawnień do uruchamiania/udostępniania obrazu AMI lub snapshotu, aby uwzględnić to konto; oraz (4) upewnienia się, że podmiot IAM na koncie docelowym również posiada te uprawnienia KMS. Operacja udostępniania pozornie kończy się sukcesem, jeśli pominiesz krok 2, ale konto odbierające nie będzie w stanie odszyfrować zasobów. Założenie, że samo udostępnienie AMI wystarczy, to klasyczna pułapka.

Tryby szyfrowania po stronie serwera w S3

Gdy wymaganie określa automatyczną roczną rotację, możliwość audytu w CloudTrail oraz minimalizację kosztów kluczy, odpowiedzią jest SSE-KMS z kluczem aws/s3 zarządzanym przez AWS — rotuje on co rok bez dodatkowych opłat, a każde wywołanie `GenerateData

Wymuszanie szyfrowania i TLS na S3

Uczynienie bucketa „domyślnie szyfrowanym” nie wystarczy — klienci mogą pominąć lub nadpisać nagłówek szyfrowania. Należy zastosować dwie warstwy zabezpieczeń: domyślne szyfrowanie bucketa (które uzupełnia nagłówek, jeśli klient go pominie) oraz politykę bucketa opartą na regule deny, która odrzuca operacje PutObject bez wymaganego nagłówka, a także instrukcję odmawiającą dostępu bez TLS:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyUnEncryptedObjectUploads",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::phi-bucket/*",
      "Condition": {
        "StringNotEquals": { "s3:x-amz-server-side-encryption": "aws:kms" }
      }
    },
    {
      "Sid": "DenyInsecureTransport",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": ["arn:aws:s3:::phi-bucket", "arn:aws:s3:::phi-bucket/*"],
      "Condition": { "Bool": { "aws:SecureTransport": "false" } }
    }
  ]
}

Warunek aws:SecureTransport wymusza użycie HTTPS, spełniając wymóg „szyfrowania w tranzycie”. W połączeniu z SSE-KMS wykorzystującym klucz CMK należący do zespołu ds. zgodności, jest to kanoniczny wzorzec przechowywania danych PHI.

Szyfrowanie w tranzycie a szyfrowanie w spoczynku

Szyfrowanie w spoczynku (szyfrowane przez KMS woluminy EBS, storage RDS, obiekty S3) i szyfrowanie w tranzycie (TLS w sieci) to niezależne mechanizmy kontrolne, które adresują różne zagrożenia — odpowiednio kradzież dysku w porównaniu z przechwyceniem danych w sieci. Włączenie KMS na instancji RDS chroni jej bazowy storage; nie ma to żadnego wpływu na sesję klienta z bazą danych, która domyślnie może być nieszyfrowana. W przypadku RDS MySQL ochrona w tranzycie wymaga pobrania pakietu certyfikatów CA usługi RDS, ustawienia require_secure_transport=ON w grupie parametrów i łączenia się klientów z użyciem opcji --ssl-ca=rds-combined-ca-bundle.pem. Traktowanie włączonego „szyfrowania w spoczynku” jako wystarczającego zabezpieczenia jest częstym błędem wykrywanym podczas audytów.

Secrets Manager i Parameter Store

Statyczne hasła do baz danych w plikach konfiguracyjnych, zmiennych środowiskowych lub parametrach CloudFormation to główny wektor wycieku poświadczeń. AWS Secrets Manager przechowuje sekrety zaszyfrowane za pomocą KMS, udostępnia je poprzez kontrolowaną przez IAM operację GetSecretValue i — co kluczowe — automatycznie je rotuje za pomocą funkcji Lambda do rotacji. Dla usług RDS, Aurora, Redshift i DocumentDB, AWS dostarcza zarządzaną funkcję Lambda do rotacji, która łączy się z bazą danych, generuje nowe hasło, atomowo aktualizuje zarówno sekret, jak i użytkownika bazy danych, oraz wspiera strategie jedno- i wieloużytkownikowe. Dla innych systemów tworzy się własną funkcję Lambda implementującą czteroetapowy cykl życia: createSecret, setSecret, testSecret, finishSecret.

import boto3, json
secret = json.loads(
    boto3.client('secretsmanager')
         .get_secret_value(SecretId='prod/aurora/app')['SecretString'])
conn = pymysql.connect(host=secret['host'],
                       user=secret['username'],
                       password=secret['password'])

Aplikacje przechowują wartość w pamięci podręcznej przez krótki czas (używając biblioteki cache’ującej z AWS SDK) i ponownie nawiązują połączenie w przypadku niepowodzenia uwierzytelnienia. Rotacja jest niewidoczna dla aplikacji i zmiana hasła nie wymaga wdrożenia.

SSM Parameter Store SecureString jest alternatywą, gdy rotacja nie jest wymagana, a głównym czynnikiem jest koszt:

Podmiot pobierający parametr typu SecureString potrzebuje uprawnień zarówno ssm:GetParameter, jak i kms:Decrypt na danym kluczu. Pominięcie uprawnienia KMS to jedna z najczęstszych błędnych konfiguracji — polityka IAM wygląda poprawnie, ale wywołanie API kończy się niepowodzeniem na etapie deszyfrowania.

Na EC2, ECS, EKS i w Lambda kod powinien przyjmować rolę IAM i wywoływać GetSecretValue lub GetParameter; żadnych długoterminowych poświadczeń na dysku. Osadzanie kluczy dostępu użytkownika IAM bezpośrednio w kodzie aplikacji — nawet w formie zaszyfrowanej — narusza zasadę najmniejszych uprawnień i komplikuje rotację.

Narzędzia audytowe i analityki śledczej

CloudTrail rejestruje każde wywołanie API w AWS: kto, co, kiedy i skąd. Organization trail włączony z poziomu konta zarządzającego zbiera zdarzenia ze wszystkich kont do jednego bucketa S3, idealnie na zamkniętym koncie bezpieczeństwa z włączonymi S3 Object Lock i MFA Delete. Zapewnia to niezmienną oś czasu do analizy śledczej — który podmiot usunął wolumin, która rola zmodyfikowała grupę bezpieczeństwa, który klucz dostępu wywołał ec2:RunInstances o 03:17 UTC. Należy to uzupełnić o logi i alarmy CloudWatch (logowanie roota, zmiany w politykach IAM) oraz AWS Config do śledzenia stanu zasobów w danym punkcie czasowym i pakiety zgodności (conformance packs). Aby zapobiec manipulacji, należy użyć polityki SCP odmawiającej uprawnień cloudtrail:StopLogging i cloudtrail:DeleteTrail.

MFA Delete na buckecie S3 wymusza na użytkowniku root przedstawienie tokena MFA w celu trwałego usunięcia wersji obiektu lub wyłączenia wersjonowania. Może być włączone tylko przez roota za pomocą CLI i zapewnia silną ochronę przed ransomware i usunięciem danych przez osoby z wewnątrz.

Amazon Macie wykorzystuje zarządzane uczenie maszynowe do odkrywania danych PII, PHI, poświadczeń i danych finansowych w S3, generując wyniki sklasyfikowane według ważności. Jest to narzędzie do odkrywania danych, a nie do ich szyfrowania.

Wykrywanie zagrożeń: GuardDuty, Security Hub, Detective

Amazon GuardDuty stale analizuje logi VPC Flow Logs, logi DNS oraz zdarzenia zarządcze i zdarzenia danych z CloudTrail, oferując dedykowane plany ochrony dla logów audytowych EKS, zdarzeń danych S3, skanowania EBS pod kątem złośliwego oprogramowania, aktywności sieciowej Lambda oraz zdarzeń logowania do RDS. Funkcja GuardDuty RDS Protection ujawnia anomalie lub próby uwierzytelnienia metodą brute-force w Aurora i RDS — zachowanie, którego grupa bezpieczeństwa nie jest w stanie wychwycić, ponieważ na warstwie L4 połączenie jest prawidłowe. Wyniki (findings) są przekazywane do pulpitów nawigacyjnych EventBridge, Security Hub i Detective.

Grupy bezpieczeństwa działają tylko na warstwach L3–L4. Grupa zezwalająca na ruch z 0.0.0.0/0 na porcie 443 wykonuje swoje zadanie, gdy przekazuje ładunek SQL injection — właśnie po to istnieje WAF, aby to zatrzymać. Obrona w głąb (defense in depth) oznacza stosowanie grup bezpieczeństwa, WAF, Shield i GuardDuty, gdzie każde z tych narzędzi chroni warstwę, której inne nie widzą.

DDoS: Shield Standard i Advanced

AWS Shield Standard jest automatyczny i darmowy, chroniąc każde konto przed powszechnymi atakami na warstwy L3/L4 (SYN floods, reflection). Działa w tle bez widoczności, bez niestandardowych środków zaradczych i bez możliwości interwencji człowieka.

AWS Shield Advanced (3000 USD/miesiąc za organizację plus opłaty za transfer danych) jest wymagany, gdy scenariusz wspomina o proaktywnym zaangażowaniu, dedykowanej reakcji, ochronie kosztów przed skalowaniem wywołanym przez DDoS lub widoczności ataków niemal w czasie rzeczywistym. Obejmuje CloudFront, Global Accelerator, ALB, CLB, Route 53 i elastyczne adresy IP (Elastic IPs) oraz zapewnia całodobowy dostęp do Shield Response Team (SRT) — wstępnie autoryzowanego poprzez rolę IAM — do tworzenia reguł WAF w Twoim imieniu podczas aktywnego ataku. Gdy projekt za ALB i Route 53 wymaga zarządzanego wykrywania oraz reakcji człowieka, sam Shield Standard jest niewystarczający; to jest powtarzająca się pułapka. Wersja Advanced zapewnia również ochronę kosztów skalowania wywołanego przez ataki. Gdy wspomniany jest „NAJMNIEJSZY wysiłek wdrożeniowy”, a architektura już zawiera Global Accelerator lub ALB, odpowiedzią jest zazwyczaj włączenie Shield Advanced i dołączenie zarządzanych przez AWS grup reguł WAF, a nie budowanie niestandardowych Lambda@Edge czy migracja CDN.

Ochrona warstwy aplikacji: AWS WAF

AWS WAF dołącza się do CloudFront, Application Load Balancers, API Gateway, AppSync, App Runner i pul użytkowników Cognito. Nie chroni bezpośrednio Network Load Balancers (należy umieścić CloudFront przed nimi). Inspekcjonuje ruch L7 i stosuje reguły dotyczące SQL injection, XSS, ograniczeń rozmiaru, geo-blockingu, reputacji IP i ograniczania liczby zapytań (rate limiting). AWS Managed Rules dostarczają gotowe grupy reguł, takie jak AWSManagedRulesCommonRuleSet i AWSManagedRulesSQLiRuleSet, bez konieczności pisania wyrażeń regularnych (regex).

Reguły oparte na częstotliwości (rate-based rules) są główną obroną przed atakami typu HTTP flood i credential stuffing — liczą one żądania w pięciominutowym oknie na źródłowy adres IP (lub na przekazany nagłówek) i automatycznie blokują sprawców:

Rules:
  - Name: RateLimitPerIP
    Priority: 1
    Statement:
      RateBasedStatement:
        Limit: 2000        # per 5-min window per IP
        AggregateKeyType: IP
    Action: { Block: {} }
    VisibilityConfig:
      CloudWatchMetricsEnabled: true
      MetricName: RateLimitPerIP
      SampledRequestsEnabled: true

WAF nie jest usługą DDoS — to rola Shield. WAF uzupełnia polityki zasobów (polityki bucketów S3 odmawiające połączeń innych niż TLS, polityki punktów końcowych VPC ograniczające dostępne buckety) oraz kontrole sieciowe (grupy bezpieczeństwa, NACL) — błędna konfiguracja na jednej warstwie nie może prowadzić do ujawnienia danych.

Izolacja sieci: Security Groups, NACL, Network Firewall

Wewnątrz VPC obrona jest warstwowa:

• Security groups są stanowe, stosowane do ENI, działają tylko na zasadzie zezwoleń (allow-only) i oceniają wszystkie reguły jednocześnie. Ruch powrotny jest automatycznie dozwolony, więc nie trzeba jawnie otwierać portów efemerycznych.
• Sieciowe listy ACL (NACL) są bezstanowe, stosowane do podsieci, obsługują zarówno zezwolenia (allow), jak i odmowy (deny), i oceniają reguły w kolejności numerycznej. Ponieważ są bezstanowe, jeśli zezwolisz na ruch przychodzący na porcie 443, musisz również zezwolić na ruch wychodzący na porty efemeryczne 1024–65535 dla odpowiedzi. Zapomnienie o tym powoduje ciche odrzucanie wszystkich odpowiedzi. Grupy bezpieczeństwa nie mają tego problemu.
• AWS Network Firewall zapewnia głęboką inspekcję pakietów (DPI), reguły IPS kompatybilne z Suricata oraz filtrowanie ruchu wychodzącego na podstawie domen, umieszczając się między podsieciami a IGW/TGW w celu scentralizowanej inspekcji.

Zakładanie, że same grupy bezpieczeństwa wystarczą, ignoruje zagrożenia na poziomie podsieci i kontrolę zasięgu rażenia (blast-radius); zakładanie, że same NACL wystarczą, ignoruje ich bezstanowość i ogólność.

Katalog pułapek

Pominięta polityka zaufania (trust policy). Polityka uprawnień roli nadaje zdolności; tylko polityka zaufania nadaje możliwość jej przyjęcia (assumability). Obie muszą być otwarte, aby dostęp między kontami lub między usługami zadziałał — wywołujący otrzyma AccessDenied na sts:AssumeRole niezależnie od tego, jak liberalna jest polityka tożsamości.

Polityka IAM bez pasującej polityki klucza. Uprawnienie kms:Decrypt w IAM jest konieczne, ale niewystarczające. Polityka klucza musi albo wymieniać podmiot (principal), albo delegować uprawnienia do IAM za pomocą Principal: {"AWS": "arn:aws:iam::ACCOUNT:root"}. Udostępnianie zaszyfrowanych AMI/snapshotów kończy się niepowodzeniem, gdy wykonano tylko udostępnienie AMI, a polityka klucza nie została zaktualizowana.

Traktowanie SCP jako nadań uprawnień. SCP ograniczają, nigdy nie nadają uprawnień. SCP z Allow s3:* nie robi nic bez pasującej polityki tożsamości. I odwrotnie, liberalna polityka tożsamości jest ograniczona przez każde Deny w SCP na ścieżce konta.

Zakładanie automatycznej rotacji kluczy KMS. Klucze zarządzane przez klienta (CMK) nie rotują, dopóki nie zostanie to włączone; zaimportowany materiał klucza nigdy nie rotuje automatycznie.

Wybór SSE-S3 dla danych podlegających kontroli zgodności. SSE-S3 nie ma polityki klucza, widoczności w CloudTrail ani ścieżki unieważnienia — nie spełnia żadnego wymagania wspominającego o „administrowaniu”, „kontrolowaniu”, „audytowaniu” lub „unieważnianiu” klucza.

Traktowanie szyfrowania w spoczynku (at rest) jako wystarczającego. Szyfrowanie w spoczynku i w tranzycie są niezależne. RDS z KMS nadal wymaga require_secure_transport=ON i walidacji certyfikatu CA klienta.

Wymienianie kont indywidualnie w polityce bucketu. Nie skaluje się i psuje się przy zmianach w organizacji. Użyj aws:PrincipalOrgID.

Zakodowane na stałe klucze dostępu w dowolnym miejscu. W user data, plikach .env, parametrach CloudFormation, Git — zawsze jest to błąd. Używaj profili instancji, ról zadań, ról wykonawczych, IRSA/Pod Identity lub Roles Anywhere.

Użytkownik root do codziennej pracy lub dołączanie do niego polityk. Root nie może być ograniczony przez IAM ani SCP; dodawanie polityki do roota jest bezsensowne. Każda odpowiedź, która to robi, jest z gruntu błędna.

Użytkownicy IAM do dostępu między kontami. Użytkownicy IAM nie mogą być przyjmowani (assumed) między kontami; utwórz rolę na koncie docelowym i pozwól podmiotowi z konta źródłowego ją przyjąć.

NLB za WAF. WAF nie dołącza się do NLB. Jeśli wymagane jest filtrowanie L7, umieść CloudFront przed NLB.

Brak reguły dla wychodzących portów efemerycznych w NACL. Bezstanowe NACL wymagają jawnych reguł dla ścieżki powrotnej. Brak reguły dla portów 1024–65535 na wyjściu cicho psuje wszystkie odpowiedzi na przychodzące żądania na porcie 443.

Shield Standard dla zarządzanego zaangażowania. Standard jest pasywny i nie daje dostępu do SRT; tylko Advanced spełnia wymóg „proaktywnego zarządzanego zaangażowania” lub „ochrony kosztów”.

← Integracja aplikacji · Wszystkie domeny · Zarządzanie →

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

Przeglądaj Amazon →