Scenariusze bezpiecznych architektur
Rozwiązywać pytania scenariuszowe dotyczące najmniejszych uprawnień IAM, szyfrowania, izolacji VPC oraz WAF/Shield, aby utrwalić wiedzę z domeny bezpieczeństwa.
Scenariusze bezpiecznych architektur to bezpłatna lekcja Cloud & IT Cert Prep na CoddyKit. To lekcja 1 z 4. Możesz przeczytać całą lekcję poniżej za darmo — a potem ćwiczyć ją interaktywnie w przeglądarce z wbudowanym edytorem kodu i tutorem AI dostępnym 24/7. To część ścieżki edukacyjnej Cloud & IT Cert Prep, a Twój postęp synchronizuje się między webem a aplikacją CoddyKit. Kurs Cloud & IT Cert Prep zawiera 4 lekcji w sumie.
Scenariusz 1: dostęp EC2 do S3 zgodny z zasadą najmniejszych uprawnień
Scenariusz: Instancja EC2 uruchamia aplikację internetową, która musi odczytywać obiekty z określonego bucketu S3. Zespół ds. bezpieczeństwa wymaga, aby na instancji nie były przechowywane dane uwierzytelniające długoterminowe oraz aby dostęp był zgodny z zasadą najmniejszych uprawnień. Rozwiązanie: Utwórz rolę IAM z zasadą zezwalającą wyłącznie na s3:GetObject w odniesieniu do ARN określonego bucketu. Dołącz rolę do instancji EC2 jako profil instancji. Aplikacja korzysta z usługi metadanych instancji (IMDS), aby automatycznie pobierać tymczasowe dane uwierzytelniające — nie są potrzebne żadne zapisane klucze.
# IAM policy for least-privilege EC2 -> S3 read
{
'Version': '2012-10-17',
'Statement': [{
'Effect': 'Allow',
'Action': ['s3:GetObject'],
'Resource': 'arn:aws:s3:::my-app-bucket/*'
}]
}
# Attach role to EC2 instance
aws ec2 associate-iam-instance-profile \
--instance-id i-1234567890abcdef0 \
--iam-instance-profile Name=EC2S3ReadRoleScenariusz 2: szyfrowanie danych w bazie RDS
Scenariusz: Firma przechowuje dane osobowe klientów w bazie danych RDS PostgreSQL. Zespół ds. zgodności wymaga szyfrowania danych w spoczynku oraz możliwości audytowania użycia klucza. Rozwiązanie: Włącz szyfrowanie RDS za pomocą AWS KMS z użyciem klucza zarządzanego przez klienta (CMK). CMK pozwala zespołowi ds. bezpieczeństwa kontrolować rotację klucza, wyświetlać informacje o jego użyciu w CloudTrail oraz w razie potrzeby odwołać dostęp. Uwaga: szyfrowanie musi być włączone podczas tworzenia instancji RDS — istniejącej, nieszyfrowanej instancji RDS nie można zaszyfrować w miejscu. Aby zaszyfrować istniejącą bazę danych, utwórz snapshot, skopiuj go z włączonym szyfrowaniem, a następnie odtwórz bazę z zaszyfrowanego snapshotu.
# Create an encrypted RDS instance
aws rds create-db-instance \
--db-instance-identifier prod-postgres \
--db-instance-class db.t3.medium \
--engine postgres \
--master-username admin \
--master-user-password SecurePass123! \
--storage-encrypted \
--kms-key-id arn:aws:kms:us-east-1:123456789012:key/mrk-abc123 \
--allocated-storage 100Scenariusz 3: bucket S3 — blokowanie dostępu publicznego
Scenariusz: Deweloper przypadkowo udostępnił publicznie bucket S3, ujawniając dane klientów. Zespół ds. bezpieczeństwa chce mieć pewność, że żaden bucket S3 na koncie nigdy nie zostanie udostępniony publicznie, nawet jeśli deweloper podejmie taką próbę. Rozwiązanie: Włącz S3 Block Public Access na poziomie konta. Ustawienie to nadpisuje każdą zasadę bucketu lub ACL przyznające dostęp publiczny, niezależnie od konfiguracji poszczególnych zespołów. Połącz je z regułą AWS Config (s3-bucket-public-read-prohibited), aby stale wykrywać niezgodne buckety i generować alerty.
# Block all public access at account level
aws s3control put-public-access-block \
--account-id 123456789012 \
--public-access-block-configuration \
'BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true'
# Deploy Config rule to detect violations
aws configservice put-config-rule \
--config-rule '{"ConfigRuleName": "s3-bucket-public-read-prohibited", "Source": {"Owner": "AWS", "SourceIdentifier": "S3_BUCKET_PUBLIC_READ_PROHIBITED"}}'Scenariusz 4: izolacja warstwy bazy danych w VPC
Scenariusz: Firma chce mieć pewność, że jej baza danych RDS będzie dostępna wyłącznie z serwerów aplikacji, a nie z internetu. Rozwiązanie: Umieść RDS w prywatnej podsieci bez trasy do bramy internetowej. Utwórz grupę zabezpieczeń dla RDS, która zezwala na ruch przychodzący wyłącznie na porcie 5432 (PostgreSQL) z grupy zabezpieczeń serwerów aplikacji — a nie z dowolnego zakresu adresów IP. Dzięki temu nawet w przypadku przejęcia serwera aplikacji atakujący nie będzie mógł uzyskać dostępu do bazy danych z zewnątrz VPC, a możliwość poruszania się w jej obrębie zostanie ograniczona przez reguły grup zabezpieczeń.
# Create RDS security group allowing only the app tier SG as source
aws ec2 create-security-group \
--group-name rds-sg \
--description 'RDS security group' \
--vpc-id vpc-abc123
aws ec2 authorize-security-group-ingress \
--group-id sg-rds \
--protocol tcp \
--port 5432 \
--source-group sg-app # app tier security group ID onlyScenariusz 5: rotacja danych uwierzytelniających do bazy danych
Scenariusz: Kod aplikacji zawiera obecnie dane uwierzytelniające do bazy danych zapisane na stałe w plikach konfiguracyjnych. Audyt bezpieczeństwa wskazuje to jako krytyczne zagrożenie. Rozwiązanie: Przechowuj dane uwierzytelniające w AWS Secrets Manager i skonfiguruj automatyczną rotację (Secrets Manager ma wbudowane funkcje rotacji Lambda dla RDS). Zaktualizuj aplikację tak, aby w czasie działania pobierała dane uwierzytelniające z Secrets Manager za pomocą SDK. Aplikacja automatycznie otrzyma nowe dane uwierzytelniające po każdej rotacji, bez konieczności wdrażania zmian. Włącz szablon rotacji sekretu RDS, aby w pełni zarządzać rotacją danych uwierzytelniających bez przestojów.
# Store RDS credentials in Secrets Manager
aws secretsmanager create-secret \
--name prod/myapp/rds \
--secret-string '{"username":"admin","password":"OldPass123!","host":"rds-endpoint.amazonaws.com","port":5432}'
# Enable automatic rotation every 30 days
aws secretsmanager rotate-secret \
--secret-id prod/myapp/rds \
--rotation-lambda-arn arn:aws:lambda:us-east-1:123:function:SecretsManagerRDSPostgreSQLRotationSingleUser \
--rotation-rules AutomaticallyAfterDays=30Scenariusz 6: wykrywanie nietypowej aktywności API
Scenariusz: Firma chce wykrywać przypadki przejęcia danych uwierzytelniających konta AWS i użycia ich z nieoczekiwanych lokalizacji. Rozwiązanie: Włącz Amazon GuardDuty we wszystkich regionach. GuardDuty analizuje zdarzenia CloudTrail, dzienniki VPC Flow Logs i dzienniki DNS, wykorzystując uczenie maszynowe do wykrywania anomalii: wywołań API z nietypowych lokalizacji geograficznych, wzorców kopania Bitcoinów na EC2, komunikacji z węzłami wyjściowymi Tor lub wzorców eksfiltracji danych uwierzytelniających. GuardDuty generuje ustalenia, które mogą uruchamiać reguły EventBridge automatycznie powiadamiające zespół ds. bezpieczeństwa za pośrednictwem SNS lub tworzące zgłoszenie do pomocy technicznej.
# Enable GuardDuty in a Region
aws guardduty create-detector \
--enable \
--finding-publishing-frequency FIFTEEN_MINUTES
# EventBridge rule to react to GuardDuty HIGH severity findings
aws events put-rule \
--name guardduty-high-severity \
--event-pattern '{
"source": ["aws.guardduty"],
"detail-type": ["GuardDuty Finding"],
"detail": {"severity": [{"numeric": [">=", 7]}]}
}'Scenariusz 7: WAF do blokowania złośliwych żądań
Scenariusz: Aplikacja internetowa działająca za modułem ALB otrzymuje ataki typu SQL injection. Aplikacji nie można od razu zmodyfikować. Rozwiązanie: Powiąż AWS WAF z modułem ALB. Wdróż grupę reguł AWS Managed Rules for Common Threats (Core Rule Set oraz grupę reguł SQL Database), która obejmuje wbudowane wykrywanie SQL injection. WAF sprawdza żądania HTTP, zanim dotrą one do ALB, i blokuje żądania pasujące do wzorców ataków — bez konieczności zmiany kodu aplikacji. Włącz również rejestrowanie WAF do Kinesis Firehose na potrzeby analizy bezpieczeństwa.
# Create WAF Web ACL with SQL injection protection
aws wafv2 create-web-acl \
--name AppProtection \
--scope REGIONAL \
--default-action Allow={} \
--rules '[{
"Name": "AWSManagedRulesSQLiRuleSet",
"Priority": 1,
"Statement": {
"ManagedRuleGroupStatement": {
"VendorName": "AWS",
"Name": "AWSManagedRulesSQLiRuleSet"
}
},
"OverrideAction": {"None": {}},
"VisibilityConfig": {"SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "SQLi"}
}]' \
--region us-east-1Scenariusz 8: przyjmowanie roli między kontami
Scenariusz: Centralne konto bezpieczeństwa potrzebuje dostępu tylko do odczytu do wszystkich kont obciążeń w AWS Organisation, aby przeprowadzać audyty bezpieczeństwa. Rozwiązanie: Na każdym koncie obciążenia utwórz rolę IAM z zasadą zaufania zezwalającą kontu bezpieczeństwa (wskazanemu identyfikatorem konta) na jej przyjęcie. Dołącz zasadę tylko do odczytu (np. zarządzaną przez AWS zasadę SecurityAudit). Zespół ds. bezpieczeństwa na koncie centralnym korzysta z STS AssumeRole, aby tymczasowo przyjmować rolę na każdym koncie obciążenia. Jest to zgodne z zasadą najmniejszych uprawnień — na kontach obciążeń nie są tworzeni stali użytkownicy IAM.
# Trust policy in workload account (allows security account to assume role)
{
'Version': '2012-10-17',
'Statement': [{
'Effect': 'Allow',
'Principal': {
'AWS': 'arn:aws:iam::SECURITY_ACCOUNT_ID:root'
},
'Action': 'sts:AssumeRole'
}]
}
# From security account: assume role in workload account
aws sts assume-role \
--role-arn arn:aws:iam::WORKLOAD_ACCOUNT_ID:role/SecurityAuditRole \
--role-session-name audit-2024-01Scenariusz 9: ograniczanie działań za pomocą SCP
Scenariusz: Firma korzysta z AWS Organizations i chce uniemożliwić każdemu kontu w jednostce organizacyjnej niezwiązanej z produkcją uruchamianie drogich instancji GPU. Rozwiązanie: Utwórz Service Control Policy (SCP), która odmawia wykonania operacji ec2:RunInstances dla rodzin instancji GPU (p3, p4, g4, g5), a następnie dołącz ją do jednostki organizacyjnej niezwiązanej z produkcją. SCP mają zastosowanie nawet do użytkowników root i użytkowników IAM z uprawnieniami na poziomie administratora na kontach członkowskich — działają jak zabezpieczenia, których żadna tożsamość na koncie nie może obejść. Zapobiega to przypadkowym lub złośliwym dużym wydatkom na kontach deweloperskich i testowych.
# SCP to deny GPU instance types in non-prod OU
{
'Version': '2012-10-17',
'Statement': [{
'Sid': 'DenyGPUInstances',
'Effect': 'Deny',
'Action': 'ec2:RunInstances',
'Resource': 'arn:aws:ec2:*:*:instance/*',
'Condition': {
'StringLike': {
'ec2:InstanceType': ['p3.*', 'p4d.*', 'g4.*', 'g5.*']
}
}
}]
}Scenariusz 10: ścieżka audytowa na potrzeby zgodności
Scenariusz: Firma z sektora usług finansowych musi wykazać audytorom, że wszystkie wywołania API AWS są rejestrowane, zabezpieczone przed manipulacją i przechowywane przez 7 lat. Rozwiązanie: Utwórz wieloregionowy szlak AWS CloudTrail, który dostarcza dzienniki do dedykowanego bucketu S3 na koncie przeznaczonym do rejestrowania. Włącz Log File Integrity Validation (kryptograficzne pliki skrótów wykrywające manipulowanie dziennikami). Ustaw zasadę Object Lock S3 w trybie Compliance z okresem przechowywania wynoszącym 7 lat dla bucketu z dziennikami. Dzięki temu dzienników nie będzie można usunąć ani zmodyfikować — nawet przez użytkownika root — przez wymagany okres przechowywania.
# Create multi-region trail with integrity validation
aws cloudtrail create-trail \
--name compliance-trail \
--s3-bucket-name central-audit-logs-123 \
--is-multi-region-trail \
--enable-log-file-validation \
--include-global-service-events
aws cloudtrail start-logging --name compliance-trailScenariusz 11: punkt końcowy VPC do prywatnego dostępu do S3
Scenariusz: Instancje EC2 w prywatnej VPC muszą uzyskiwać dostęp do S3 bez przesyłania ruchu przez publiczny internet. Obecnie używana jest brama NAT, a koszty są wysokie z powodu opłat za przetwarzanie danych przez bramę NAT. Rozwiązanie: Utwórz bramę S3 Gateway VPC Endpoint. Dodaj wpis trasy do tabeli tras prywatnej podsieci, kierując listę prefiksów S3 do punktu końcowego. Ruch do S3 pozostaje teraz w całości w szkielecie sieci AWS — nie jest potrzebna ani brama NAT, ani brama internetowa. Punkty końcowe S3 Gateway są bezpłatne (w przeciwieństwie do punktów końcowych typu Interface, które wiążą się z opłatą godzinową za każdą strefę dostępności). Zwiększa to również bezpieczeństwo, ponieważ usuwa dostęp do S3 ze ścieżki prowadzącej przez publiczny internet.
# Create S3 Gateway VPC Endpoint
aws ec2 create-vpc-endpoint \
--vpc-id vpc-abc123 \
--service-name com.amazonaws.us-east-1.s3 \
--route-table-ids rtb-private-1a rtb-private-1b
# Result: route table automatically gets a route:
# Destination: pl-63a5400a (S3 prefix list)
# Target: vpce-xyz456 (the Gateway Endpoint)
# EC2 instances now reach S3 privately at no endpoint costSzybki test
Sprawdź swoją wiedzę na temat zagadnień AWS Solutions Architect (SAA-C03) omówionych w tej lekcji.
Podsumowanie lekcji
W tej lekcji przeanalizowano scenariusze obejmujące: role IAM i profile instancji umożliwiające dostęp do EC2 bez poświadczeń, Secrets Manager do automatycznej rotacji poświadczeń bazy danych, AWS WAF do blokowania ataków typu injection bez zmian w kodzie oraz CloudTrail z S3 Object Lock do tworzenia odpornych na manipulacje logów zgodności. W następnej części omówimy scenariusze dotyczące odpornej i wysoce dostępnej architektury.
Często zadawane pytania
Czy lekcja „Scenariusze bezpiecznych architektur” jest bezpłatna?
Tak — pełny tekst „Scenariusze bezpiecznych architektur” jest dostępny za darmo tutaj w sieci. Aby ćwiczyć ją interaktywnie (wbudowany edytor kodu i tutor AI dostępny 24/7) i odblokować resztę kursu Cloud & IT Cert Prep, przejdź na CoddyKit PRO. Kurs Cloud & IT Cert Prep zawiera 4 lekcji w sumie.
Co nauczysz się w „Scenariusze bezpiecznych architektur”?
Rozwiązywać pytania scenariuszowe dotyczące najmniejszych uprawnień IAM, szyfrowania, izolacji VPC oraz WAF/Shield, aby utrwalić wiedzę z domeny bezpieczeństwa. Ćwiczysz Cloud & IT Cert Prep z praktycznym kodem, który uruchamiasz bezpośrednio w przeglądarce, a tutor AI dostępny 24/7 odpowiada na Twoje pytania podczas pracy nad lekcją.
Czy potrzebuję doświadczenia, aby zacząć Cloud & IT Cert Prep?
Nie wymagamy żadnego doświadczenia. Cloud & IT Cert Prep w CoddyKit jest strukturyzowany dla początkujących i zaawansowanych użytkowników, więc możesz zacząć tutaj lub od początku i uczyć się w swoim tempie. To lekcja 1 z 4.
Ile czasu zajmuje lekcja „Scenariusze bezpiecznych architektur”?
Większość lekcji CoddyKit trwa około 5–10 minut. Każda lekcja to mały, interaktywny krok, dzięki czemu robisz systematyczne postępy i zawsze wracasz dokładnie do tego samego miejsca — na webie i w aplikacji.
Czy mogę pisać i uruchamiać kod w tej lekcji Cloud & IT Cert Prep?
Tak. Każda lekcja Cloud & IT Cert Prep zawiera wbudowany edytor kodu, więc piszesz i uruchamiasz prawdziwy kod bezpośrednio w przeglądarce i od razu otrzymujesz sprzężenie zwrotne od AI — bez konfiguracji na komputerze.
Wszystkie lekcje w tym kursie
- Scenariusze bezpiecznych architektur
- Scenariusze odpornych i wysoce dostępnych architektur
- Scenariusze wysokiej wydajności i optymalizacji kosztów
- Pełny mini-egzamin z mieszanych domen