KMS, ACM i wzorce szyfrowania
Zarządzać kluczami szyfrowania za pomocą AWS KMS, aprowizować i rotować certyfikaty TLS za pomocą ACM oraz wybierać między szyfrowaniem po stronie klienta, serwera i podczas przesyłania.
KMS, ACM i wzorce szyfrowania 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.
Szyfrowanie w AWS: przegląd
Szyfrowanie jest podstawowym mechanizmem bezpieczeństwa, który chroni poufność danych nawet w przypadku naruszenia zabezpieczeń nośnika pamięci lub uzyskania dostępu inną drogą. AWS zapewnia szyfrowanie danych w spoczynku (przechowywanych w bazach danych, S3 i EBS) oraz podczas przesyłania (przemieszczających się przez sieci). Najważniejsze usługi to: AWS Key Management Service (KMS), który zarządza kluczami szyfrowania danych w spoczynku, oraz AWS Certificate Manager (ACM), który udostępnia i zarządza certyfikatami TLS na potrzeby szyfrowania danych podczas przesyłania. Zrozumienie, kiedy i jak stosować każdą z tych usług, jest niezbędne w obszarze Security Architecture egzaminu SAA-C03.
# Encryption coverage on AWS:
# At rest (KMS):
# S3, EBS, RDS, DynamoDB, EFS, SQS,
# Lambda env vars, Secrets Manager, SSM Parameter Store
# In transit (ACM/TLS):
# ALB listeners (HTTPS), API Gateway, CloudFront,
# Direct Connect, VPN, inter-service communication
# Both:
# S3 Server-Side Encryption + HTTPS only policyAWS KMS: Key Management Service
AWS KMS to w pełni zarządzana usługa służąca do tworzenia kluczy szyfrowania i zarządzania nimi. KMS korzysta z Hardware Security Modules (HSMs) do ochrony kluczy — materiał klucza nigdy nie opuszcza HSM w postaci niezaszyfrowanej. KMS integruje się z większością usług AWS na potrzeby szyfrowania po stronie serwera. Typy kluczy: AWS Managed Keys (bezpłatne, automatycznie rotowane co roku, bez możliwości bezpośredniego sterowania nimi), Customer Managed Keys (CMK) (1 USD miesięcznie za każdy klucz; użytkownik kontroluje rotację, politykę klucza i usuwanie). Custom Key Store korzysta z własnego klastra CloudHSM w przypadku wymagań zgodności nakazujących używanie dedykowanych HSM.
# Create a Customer Managed Key (CMK)
aws kms create-key \
--description 'Production database encryption key' \
--key-usage ENCRYPT_DECRYPT \
--origin AWS_KMS \
--tags TagKey=Purpose,TagValue=RDS-Encryption
# Create an alias for the key
aws kms create-alias \
--alias-name alias/prod-db-key \
--target-key-id arn:aws:kms:us-east-1:123:key/abc-def
# CMK costs: $1/month + $0.03 per 10,000 API callsPolityki kluczy i granty KMS
Każdy klucz KMS ma politykę klucza — politykę opartą na zasobie, która określa, kto może używać klucza i zarządzać nim. W przeciwieństwie do polityk IAM, które są oparte na tożsamości, polityki kluczy są wymagane: polityka klucza musi jawnie przyznawać dostęp, aby polityki IAM zaczęły obowiązywać. Dobrą praktyką jest oddzielenie administracji kluczem (kto może nim zarządzać) od używania klucza (które usługi i role mogą szyfrować i odszyfrowywać). Do tymczasowego delegowania dostępu należy używać grantów klucza — na przykład przyznać klastrowi EMR tymczasowe prawo użycia klucza KMS na potrzeby zadania bez modyfikowania polityki klucza.
# KMS key policy: grant RDS and admin access
{
'Statement': [
{
'Sid': 'Enable root account full access',
'Principal': {'AWS': 'arn:aws:iam::123:root'},
'Action': 'kms:*',
'Effect': 'Allow'
},
{
'Sid': 'Allow RDS to use this key',
'Principal': {'Service': 'rds.amazonaws.com'},
'Action': ['kms:Encrypt','kms:Decrypt','kms:GenerateDataKey'],
'Effect': 'Allow'
}
]
}Szyfrowanie kopertowe KMS
KMS używa szyfrowania kopertowego do wydajnej ochrony dużych ilości danych. Za pomocą klucza KMS nie można bezpośrednio zaszyfrować więcej niż 4 KB danych. Zamiast tego: KMS generuje Data Encryption Key (DEK) — losowy klucz używany lokalnie do szyfrowania właściwych danych. Następnie DEK jest szyfrowany za pomocą klucza KMS (Key Encryption Key). Zaszyfrowany DEK jest przechowywany razem z zaszyfrowanymi danymi. Aby odszyfrować dane, najpierw wywołuje się KMS w celu odszyfrowania DEK, a następnie lokalnie używa się jawnego DEK do odszyfrowania danych. Tak właśnie działają szyfrowanie S3, EBS i RDS.
# Generate a Data Key (for envelope encryption)
aws kms generate-data-key \
--key-id alias/my-key \
--key-spec AES_256
# Response contains:
# Plaintext: base64-encoded DEK (use to encrypt data locally)
# CiphertextBlob: KMS-encrypted DEK (store alongside data)
# To decrypt:
# 1. Call kms:Decrypt(CiphertextBlob) -> plaintext DEK
# 2. Use plaintext DEK to decrypt data locally
# 3. Zeroize plaintext DEK from memory
aws kms decrypt --ciphertext-blob fileb://encrypted-dek.binRotacja kluczy KMS
Rotacja kluczy jest dobrą praktyką bezpieczeństwa polegającą na okresowej wymianie materiału kryptograficznego klucza, co ogranicza czas narażenia w przypadku jego przejęcia. W przypadku Customer Managed Keys można włączyć automatyczną coroczną rotację — KMS generuje nowy materiał klucza i używa go do nowych operacji szyfrowania, zachowując stary materiał klucza do odszyfrowywania istniejących danych. AWS Managed Keys są automatycznie rotowane co roku. Imported key material NIE obsługuje automatycznej rotacji (rotację trzeba przeprowadzać ręcznie). Po rotacji nowe operacje KMS automatycznie korzystają z nowego materiału klucza, bez konieczności wprowadzania zmian w aplikacji.
# Enable automatic annual key rotation
aws kms enable-key-rotation \
--key-id alias/prod-db-key
# Verify rotation is enabled
aws kms get-key-rotation-status \
--key-id alias/prod-db-key
# Manual rotation (for imported key material):
# 1. Create a new CMK
# 2. Update all services to use new key
# 3. Re-encrypt existing data with new key
# 4. Schedule old key for deletion (minimum 7-day waiting period)Opcje szyfrowania po stronie serwera S3
S3 obsługuje trzy opcje szyfrowania po stronie serwera: SSE-S3 — S3 zarządza kluczami przy użyciu AES-256; opcja bezpłatna, zapewniająca najmniejszą kontrolę. SSE-KMS — korzysta z klucza KMS (zarządzanego przez AWS lub CMK), zapewnia ścieżkę audytową użycia klucza w CloudTrail, obsługuje polityki kluczy i wiąże się z opłatą za wywołania API KMS. SSE-C — użytkownik dostarcza materiał klucza i zarządza nim przy każdym żądaniu; S3 nigdy nie przechowuje klucza. Z SSE-KMS należy korzystać, gdy potrzebna jest kontrola audytowa nad tym, kto i kiedy używał klucza. SSE-S3 należy stosować w przypadku danych o niskiej wrażliwości, gdy ważne są prostota i koszt. Szyfrowanie należy wymuszać za pomocą polityki bucketa, która odrzuca PutObject bez szyfrowania.
# Enforce SSE-KMS on all new S3 objects
aws s3api put-bucket-policy \
--bucket my-secure-bucket \
--policy '{
"Statement": [{
"Effect": "Deny",
"Principal": "*",
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::my-secure-bucket/*",
"Condition": {
"StringNotEquals": {
"s3:x-amz-server-side-encryption": "aws:kms"
}
}
}]
}'
# Set default encryption for bucket
aws s3api put-bucket-encryption \
--bucket my-secure-bucket \
--server-side-encryption-configuration '{"Rules":[{"ApplyServerSideEncryptionByDefault":{"SSEAlgorithm":"aws:kms","KMSMasterKeyID":"alias/my-key"}}]}'AWS Certificate Manager (ACM)
AWS Certificate Manager (ACM) udostępnia, zarządza i automatycznie odnawia certyfikaty SSL/TLS dla usług AWS bez dodatkowych opłat. Certyfikatów ACM można używać z ALB, NLB, CloudFront, API Gateway i AppSync. ACM automatycznie obsługuje cykl życia certyfikatu — odnawia certyfikaty 60 dni przed wygaśnięciem i przejrzyście wdraża odnowienie. Można żądać certyfikatów dla posiadanych domen (weryfikowanych za pomocą DNS lub poczty e-mail) albo importować certyfikaty innych podmiotów. Certyfikatów ACM NIE można pobierać — są powiązane z usługą AWS, z którą zostały skojarzone.
# Request a public ACM certificate
aws acm request-certificate \
--domain-name app.example.com \
--subject-alternative-names '*.example.com' \
--validation-method DNS
# ACM returns a CNAME record to add to Route 53
# Add the CNAME -> ACM validates domain ownership
# Certificate is issued and auto-renews annually
# Attach to ALB listener (HTTPS:443)
aws elbv2 create-listener \
--load-balancer-arn <ALB-ARN> \
--protocol HTTPS --port 443 \
--certificates CertificateArn=arn:aws:acm:us-east-1:123:certificate/abc \
--default-actions Type=forward,TargetGroupArn=<TG-ARN>Prywatny urząd certyfikacji ACM
ACM Private CA (urząd certyfikacji) umożliwia utworzenie w pełni zarządzanej, prywatnej hierarchii urzędów certyfikacji do wystawiania certyfikatów dla zasobów wewnętrznych — instancji EC2, kontenerów, wewnętrznych interfejsów API i urządzeń IoT. W przeciwieństwie do publicznych certyfikatów ACM (używanych z usługami dostępnymi z Internetu) certyfikaty prywatnego urzędu certyfikacji można wystawiać dla dowolnej wewnętrznej nazwy hosta lub adresu IP. Private CA należy używać do: wzajemnego TLS (mTLS) między mikrousługami, uwierzytelniania opartego na certyfikatach dla sieci VPN oraz spełniania wymagań zgodności dotyczących wewnętrznej infrastruktury PKI. Private CA kosztuje 400 USD miesięcznie za urząd certyfikacji oraz 0,75 USD za każdy wystawiony certyfikat.
# Create ACM Private Certificate Authority
aws acm-pca create-certificate-authority \
--certificate-authority-type ROOT \
--certificate-authority-configuration '{
"KeyAlgorithm": "RSA_2048",
"SigningAlgorithm": "SHA256WITHRSA",
"Subject": {
"Country": "US",
"Organization": "Example Corp",
"CommonName": "Example Corp Internal CA"
}
}'
# Issue certificate from private CA
aws acm request-certificate \
--domain-name internal-service.example.internal \
--certificate-authority-arn arn:aws:acm-pca:us-east-1:123:certificate-authority/xxxSzyfrowanie EBS i RDS
W przypadku szyfrowania woluminu EBS należy włączyć je podczas tworzenia woluminu (lub skopiować istniejący wolumin z włączonym szyfrowaniem). Wszystkie dane na woluminie, w tym migawki, są szyfrowane przy użyciu wskazanego klucza KMS. Szyfrowanie EBS jest przezroczyste dla systemu operacyjnego — nie wymaga zmian w aplikacji. W przypadku szyfrowania RDS należy włączyć je podczas tworzenia instancji DB; istniejącej, nieszyfrowanej instancji RDS nie można bezpośrednio zaszyfrować. Obejście tego ograniczenia polega na utworzeniu zaszyfrowanej migawki z nieszyfrowanej instancji, a następnie odtworzeniu jej jako nowej zaszyfrowanej instancji. Zaszyfrowane migawki EBS i RDS pozostają zaszyfrowane podczas kopiowania.
# Enable account-level EBS default encryption
aws ec2 enable-ebs-encryption-by-default
aws ec2 modify-ebs-default-kms-key-id \
--kms-key-id alias/prod-ebs-key
# Encrypt an existing unencrypted RDS instance:
# 1. Create unencrypted snapshot
aws rds create-db-snapshot \
--db-instance-identifier mydb \
--db-snapshot-identifier mydb-plain-snapshot
# 2. Copy snapshot with encryption
aws rds copy-db-snapshot \
--source-db-snapshot-identifier mydb-plain-snapshot \
--target-db-snapshot-identifier mydb-encrypted-snapshot \
--kms-key-id alias/prod-db-keySzyfrowanie po stronie klienta a szyfrowanie po stronie serwera
Zrozumienie różnicy między szyfrowaniem po stronie serwera a szyfrowaniem po stronie klienta jest ważne na egzaminie SAA-C03. Szyfrowanie po stronie serwera: AWS szyfruje dane po ich odebraniu i odszyfrowuje je przed dostarczeniem — między aplikacją a AWS dane są przesyłane w postaci jawnej. Szyfrowanie po stronie klienta: szyfrują Państwo dane przed wysłaniem ich do AWS — AWS przechowuje wyłącznie szyfrogram i nigdy nie widzi danych w postaci jawnej. Szyfrowania po stronie klienta należy używać w przypadku danych o najwyższym poziomie wrażliwości, gdy nie można zaufać dostawcy chmury w zakresie obsługi danych jawnych, na przykład dokumentacji medycznej lub danych finansowych objętych rygorystycznymi regulacjami.
# Client-side encryption with AWS Encryption SDK
# (conceptual Python example)
# 1. Application encrypts data locally using KMS DEK
# from aws_encryption_sdk import KmsKeyProvider, encrypt
# key_provider = KmsKeyProvider(key_ids=['alias/my-key'])
# ciphertext, _ = encrypt(
# source=b'Sensitive patient data',
# key_provider=key_provider
# )
# 2. Send ciphertext to S3
# s3.put_object(Bucket='hipaa-data', Key='record.enc', Body=ciphertext)
# AWS only stores ciphertext - cannot decrypt without your key policyDostęp między kontami do KMS
Klucze KMS można udostępniać między kontami AWS na potrzeby szyfrowania między kontami. Jeśli na przykład aplikacja na koncie A zapisuje zaszyfrowane dane w zasobniku S3 należącym do konta B, klucz KMS konta A musi zezwalać podmiotowi z konta B na jego używanie. Należy skonfigurować zasady klucza KMS na koncie A, aby przyznać dostęp między kontami, a następnie utworzyć zasady IAM na koncie B, które umożliwią roli korzystanie z klucza konta A. Ten wzorzec jest często stosowany w architekturach udostępniania danych i architekturach wielokontowych, w których centralne konto zarządza kluczami szyfrowania.
# KMS key policy: allow cross-account access
# (in Account A's key policy)
{
'Sid': 'Allow Account B to use this key',
'Effect': 'Allow',
'Principal': {
'AWS': 'arn:aws:iam::999999999999:root'
},
'Action': [
'kms:Encrypt',
'kms:Decrypt',
'kms:ReEncrypt*',
'kms:GenerateDataKey*',
'kms:DescribeKey'
],
'Resource': '*'
}
# Account B IAM policy also needed to allow the role to use itSzybki sprawdzian
Sprawdź swoją wiedzę na temat zagadnień AWS Solutions Architect (SAA-C03) z tej lekcji.
Podsumowanie lekcji
W tej lekcji poznali Państwo następujące zagadnienia: KMS zarządza kluczami szyfrowania, zapewniając ochronę HSM, oraz obsługuje CMK umożliwiające szczegółową kontrolę dostępu i ślady audytowe, ACM udostępnia i automatycznie odnawia certyfikaty TLS dla usług AWS bez dodatkowych opłat, a także szyfrowanie można stosować po stronie serwera (KMS) lub po stronie klienta, przy czym szyfrowanie po stronie serwera jest najczęściej stosowanym wzorcem w obciążeniach natywnych dla AWS. Należy wymuszać szyfrowanie za pomocą zasad zasobników, które odrzucają operacje bez szyfrowania. W następnej części omówimy GuardDuty, Inspector i Macie.
Często zadawane pytania
Czy lekcja „KMS, ACM i wzorce szyfrowania” jest bezpłatna?
Tak — pełny tekst „KMS, ACM i wzorce szyfrowania” 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 „KMS, ACM i wzorce szyfrowania”?
Zarządzać kluczami szyfrowania za pomocą AWS KMS, aprowizować i rotować certyfikaty TLS za pomocą ACM oraz wybierać między szyfrowaniem po stronie klienta, serwera i podczas przesyłania. Ć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 „KMS, ACM i wzorce szyfrowania”?
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
- KMS, ACM i wzorce szyfrowania
- GuardDuty, Inspector i Macie
- Secrets Manager i Parameter Store
- WAF, Shield i Network Firewall