GĐ29 — AWS SAA: Security, IAM, VPC và Networking

Đọc sau GĐ28. Mục tiêu: mỗi mũi tên trong sơ đồ đều có đường mạng, danh tính và quyền; truy cập được qua mạng chưa đồng nghĩa được phép đọc dữ liệu.

Kiểm chứng ngày 2026-10-05 (đọc tài liệu AWS; lệnh CLI chỉ kiểm cờ bằng aws ... help và --generate-cli-skeleton, chưa chạy trên AWS): Cognito user pool và identity pool, trust policy của role identity pool, role SAML, role OIDC, permission set, ACM gia hạn DNS, KMS rotation, thông báo AccessDenied, policy evaluation, S3 gateway endpoint, Client VPN, mã hóa Direct Connect, Route 53 alias, edge functions. Các mục viết từ trước giữ nguồn riêng ở cuối mỗi mục.

1. IAM: principal, action, resource, condition#

Principal là danh tính thực hiện request. Policy mô tả action trên resource, có thể kèm condition. Role được assume để nhận temporary credentials qua STS; ứng dụng AWS nên dùng role thay access key nằm trong code.

Nguồn: IAM roles, Identity Center, SCP, Cognito.

Ví dụ policy tự xây, chỉ cho worker đọc object trong prefix. Đây là identity policy minh họa, chưa gồm quyền KMS nếu object dùng SSE-KMS:

{  "Version": "2012-10-17",  "Statement": [{    "Effect": "Allow",    "Action": "s3:GetObject",    "Resource": "arn:aws:s3:::YOUR-LAB-BUCKET/raw/*"  }]}

ListBucket dùng ARN bucket; GetObject dùng ARN object. Cấp một action không tự cấp action khác. Trust policy cho assume role cũng không tự cấp quyền đọc S3.

Cognito: user pool và identity pool#

Hai thành phần trả lời hai câu hỏi khác nhau và độc lập với nhau:

Dùng cùng nhau khi app vừa đăng nhập vừa gọi thẳng S3/DynamoDB: user đăng nhập ở user pool, app đổi token lấy credentials tạm ở identity pool. Nếu chỉ có backend của bạn kiểm tra JWT thì không cần identity pool. Cặp nhầm hay gặp: identity pool không lưu hồ sơ user; user pool không cấp credentials AWS. Nguồn: What is Amazon Cognito.

Role mà identity pool cho user đã đăng nhập assume phải có trust policy khóa theo pool ID (aud); IAM không cho lưu trust policy trỏ tới cognito-identity.amazonaws.com mà thiếu điều kiện này. Mẫu theo tài liệu Cognito (ID pool là giá trị minh họa):

{  "Version": "2012-10-17",  "Statement": [{    "Effect": "Allow",    "Principal": {"Federated": "cognito-identity.amazonaws.com"},    "Action": "sts:AssumeRoleWithWebIdentity",    "Condition": {      "StringEquals": {        "cognito-identity.amazonaws.com:aud":          "us-west-2:abcdefg-1234-5678-910a-0e8443553f95"      },      "ForAnyValue:StringLike": {        "cognito-identity.amazonaws.com:amr": "authenticated"      }    }  }]}

Tạo identity pool chỉ cho user đã đăng nhập từ một user pool có sẵn (đã kiểm cờ bằng CLI help; chưa chạy trên AWS):

aws cognito-identity create-identity-pool \  --identity-pool-name lab-pool \  --no-allow-unauthenticated-identities \  --cognito-identity-providers \    ProviderName=cognito-idp.us-east-1.amazonaws.com/us-east-1_EXAMPLE,ClientId=EXAMPLECLIENTID

Nguồn: Cognito IAM roles và trust policy.

Federation SAML, OIDC và IAM Identity Center#

Federation là tin một IdP bên ngoài rồi đổi bằng chứng đăng nhập lấy credentials tạm: SAML dùng sts:AssumeRoleWithSAML, OIDC/web identity dùng sts:AssumeRoleWithWebIdentity. Trust policy phải giới hạn đúng ứng dụng hoặc đúng repo, nếu không bên thứ ba cũng assume được. Trust policy cho SAML (mẫu theo tài liệu IAM; us-east-1 và tên provider là giá trị minh họa):

{  "Version": "2012-10-17",  "Statement": {    "Effect": "Allow",    "Action": "sts:AssumeRoleWithSAML",    "Principal": {      "Federated": "arn:aws:iam::111122223333:saml-provider/EXAMPLE-IDP"    },    "Condition": {      "StringEquals": {        "SAML:aud": "https://us-east-1.signin.aws.amazon.com/saml"      }    }  }}

Trust policy OIDC cho workflow CI của một repo và một nhánh (GitHub Actions; org/repo là giá trị minh họa). Tài liệu IAM yêu cầu điều kiện sub có mặt và không chỉ là wildcard; thiếu giới hạn này thì repo ngoài tổ chức của bạn cũng assume được role:

{  "Version": "2012-10-17",  "Statement": [{    "Effect": "Allow",    "Principal": {"Federated": "arn:aws:iam::111122223333:oidc-provider/token.actions.githubusercontent.com"},    "Action": "sts:AssumeRoleWithWebIdentity",    "Condition": {      "StringEquals": {        "token.actions.githubusercontent.com:aud": "sts.amazonaws.com",        "token.actions.githubusercontent.com:sub": "repo:my-org/my-repo:ref:refs/heads/main"      }    }  }]}

Nguồn: Role cho SAML, Role cho OIDC, OIDC federation.

IAM Identity Center dành cho nhân viên đăng nhập nhiều account. Permission set là mẫu gồm các IAM policy; khi gán cho user/group ở một account, Identity Center tạo role do nó quản lý trong account đó. Session mặc định của permission set là 1 giờ, tối đa 12 giờ; phiên cổng truy cập (access portal) mặc định 8 giờ, tối đa 90 ngày. Quy tắc chọn: nhân viên vào AWS qua IdP công ty thì Identity Center; người dùng cuối của ứng dụng bạn bán thì Cognito. Chuỗi lệnh tối thiểu (đã kiểm cờ bằng CLI help; chưa chạy trên AWS):

aws sso-admin list-instancesaws sso-admin create-permission-set \  --instance-arn arn:aws:sso:::instance/ssoins-EXAMPLE \  --name ReadOnlyLab --session-duration PT4Haws sso-admin attach-managed-policy-to-permission-set \  --instance-arn arn:aws:sso:::instance/ssoins-EXAMPLE \  --permission-set-arn arn:aws:sso:::permissionSet/ssoins-EXAMPLE/ps-EXAMPLE \  --managed-policy-arn arn:aws:iam::aws:policy/ReadOnlyAccessaws sso-admin create-account-assignment \  --instance-arn arn:aws:sso:::instance/ssoins-EXAMPLE \  --target-id 111122223333 --target-type AWS_ACCOUNT \  --permission-set-arn arn:aws:sso:::permissionSet/ssoins-EXAMPLE/ps-EXAMPLE \  --principal-type GROUP --principal-id EXAMPLE-GROUP-ID

Nguồn: Permission sets.

Root user, Access Analyzer và Control Tower#

• Root user: chỉ dùng cho việc bắt buộc phải là root (ví dụ đóng account standalone, khôi phục quyền khi IAM admin tự thu quyền, gỡ bucket policy chặn mọi principal). Bật MFA cho root; việc hằng ngày làm bằng Identity Center hoặc role. Nguồn: AWS account root user.
• IAM Access Analyzer: tìm tài nguyên chia sẻ ra ngoài vùng tin cậy (S3 bucket, role, KMS key, ...), quyền không dùng, kiểm tra cú pháp policy và sinh policy từ hoạt động trong CloudTrail. Phân tích external access theo từng Region. Nguồn: Access Analyzer.
• Control Tower: dựng landing zone nhiều account trên Organizations, Service Catalog và Identity Center; áp controls (preventive, detective, proactive) và cấp account bằng Account Factory. Nguồn: Control Tower.

2. Cách suy luận allow/deny và cross-account#

Bắt đầu từ implicit deny. Kiểm tra policy cấp quyền, rồi các giới hạn áp dụng; explicit deny thắng allow. Trong cùng account, identity/resource policies có thể phối hợp; boundary/session policy/SCP có quy tắc tương tác tùy principal. Không rút gọn mọi trường hợp thành “cộng tất cả Allow”.

Cross-account qua assume-role: caller cần quyền sts:AssumeRole, role đích cần trust phù hợp; sau đó session dùng permissions của role đích và các giới hạn áp dụng. Với truy cập resource trực tiếp xuyên account, kiểm tra cả phía identity và resource. External ID giúp chống confused deputy trong tình huống bên thứ ba assume role; nó không phải password.

Ví dụ debug AccessDenied:

1. Xác định principal thực bằng aws sts get-caller-identity trong môi trường của app.
2. Đọc action/resource/condition của request bị chặn.
3. Kiểm tra policy role, resource policy, boundary và SCP áp dụng.
4. Nếu có KMS, kiểm tra key policy và quyền dùng key.
5. Đối chiếu CloudTrail; không chữa bằng cách cấp AdministratorAccess.

Nguồn: Policy evaluation, cross-account role.

Ví dụ vì sao AccessDenied#

Tình huống tự dựng: role app-worker (account 111122223333) đọc s3://lab-data/raw/a.csv từ laptop bằng credentials của role. Các lớp áp dụng:

Explicit deny thắng mọi allow, nên request bị từ chối dù identity policy đúng. Bucket policy trong ví dụ (mẫu theo tài liệu gateway endpoint, giá trị là minh họa):

{  "Version": "2012-10-17",  "Statement": [{    "Sid": "OnlyViaEndpoint",    "Effect": "Deny",    "Principal": "*",    "Action": "s3:GetObject",    "Resource": "arn:aws:s3:::lab-data/*",    "Condition": {      "StringNotEquals": {"aws:sourceVpce": "vpce-0abc1234def567890"}    }  }]}

Cách sửa đúng là cho request đi qua endpoint (chạy từ trong VPC) hoặc đổi điều kiện của Deny. Thêm Allow vào identity policy không có tác dụng. Policy dạng này cũng chặn truy cập từ AWS Management Console, theo tài liệu.

Thông báo lỗi chỉ ra lớp nào chặn, nếu dịch vụ hỗ trợ định dạng này (tùy dịch vụ, theo tài liệu IAM):

Nếu nhiều loại policy cùng chặn, thông báo chỉ nêu một loại. Công cụ giả lập chỉ đánh giá identity policy và permissions boundary của principal; với principal là role, nó không mô phỏng được resource policy (theo aws iam simulate-principal-policy help), nên với ví dụ bucket policy ở trên hãy đọc thông báo lỗi hoặc CloudTrail thay vì tin kết quả allowed của simulator. Lệnh dưới (đã kiểm cờ bằng CLI help; chưa chạy trên AWS; --context-entries cho phép giả lập khóa như aws:SourceVpce) hợp để kiểm phần identity policy:

aws iam simulate-principal-policy \  --policy-source-arn arn:aws:iam::111122223333:role/app-worker \  --action-names s3:GetObject \  --resource-arns arn:aws:s3:::lab-data/raw/a.csv

Nguồn: Troubleshoot access denied, Gateway endpoints cho S3.

3. Mã hóa, TLS và secret#

Envelope encryption: dữ liệu được mã hóa bằng data key; data key được bảo vệ bằng KMS key. Quyền đọc S3 chưa chắc đủ quyền giải mã SSE-KMS. Rotation key không đồng nghĩa ứng dụng tự mã hóa lại toàn bộ dữ liệu cũ.

TLS bảo vệ đường truyền; encryption at rest bảo vệ dữ liệu lưu; authorization quyết định ai đọc được. Cần cả ba lớp. Khi ALB terminate TLS, xem xét riêng kết nối ALB → target theo yêu cầu bảo mật.

Nguồn: KMS keys, ACM, Secrets Manager, Parameter Store.

S3 + KMS trong identity policy#

Worker đọc và ghi object mã hóa SSE-KMS cần quyền S3 và quyền key, trong cùng policy (ARN là minh họa). Key policy của key cũng phải cho phép, như đã nói ở phần tự kiểm tra:

{  "Version": "2012-10-17",  "Statement": [    {      "Effect": "Allow",      "Action": ["s3:GetObject", "s3:PutObject"],      "Resource": "arn:aws:s3:::YOUR-LAB-BUCKET/raw/*"    },    {      "Effect": "Allow",      "Action": ["kms:Decrypt", "kms:GenerateDataKey"],      "Resource": "arn:aws:kms:us-east-1:111122223333:key/EXAMPLE-KEY-ID"    }  ]}

Nguồn: S3 SSE-KMS permissions, KMS key policies.

Xoay vòng KMS key#

• Customer managed key đối xứng (AWS_KMS origin): rotation tự động là tùy chọn; bật mà không đặt chu kỳ thì mặc định 365 ngày. AWS managed key luôn xoay mỗi năm và bạn không bật/tắt được.
• Asymmetric key, HMAC key và key trong custom key store không hỗ trợ rotation tự động hay theo yêu cầu; muốn xoay thì tạo key mới và đổi alias/ứng dụng.
• Rotation chỉ đổi key material hiện tại; ciphertext cũ vẫn giải mã được và dữ liệu không bị mã hóa lại. Key ID không đổi.

aws kms enable-key-rotation --key-id EXAMPLE-KEY-IDaws kms get-key-rotation-status --key-id EXAMPLE-KEY-ID

Đã kiểm cờ bằng CLI help; chưa chạy trên AWS. Nguồn: Rotate KMS keys.

ACM: chứng chỉ gia hạn thế nào#

• DNS validation: ACM tự gia hạn khi cert đang được một dịch vụ AWS dùng và các CNAME do ACM cấp vẫn còn, tra được qua DNS công khai. ACM kiểm tra điều kiện này ở 45 ngày trước khi hết hạn (chứng chỉ cấp trước đây với hiệu lực 395 ngày gia hạn ở 60 ngày trước, và sau gia hạn có hiệu lực 198 ngày). Thiếu CNAME thì ACM không xác thực được tên miền và gia hạn không diễn ra.
• Email validation: ACM gửi email nhắc khi gần hết hạn; không tự gia hạn như DNS.
• Chứng chỉ import không được ACM gia hạn tự động; ACM cũng không gia hạn chứng chỉ đã hết hạn.
• Gia hạn giữ nguyên ARN. Chứng chỉ ACM là tài nguyên theo Region; cert cho CloudFront phải nằm ở us-east-1.
• Khi không xác thực được, ACM gửi sự kiện AWS Health và EventBridge ở 30, 15, 7, 3 và 1 ngày trước khi hết hạn.

aws acm describe-certificate --certificate-arn CERT_ARN \  --query 'Certificate.[Status,RenewalEligibility,RenewalSummary.RenewalStatus]'

Đã kiểm tên trường bằng CLI help; chưa chạy trên AWS. Nguồn: Managed renewal, Renewal cho DNS validation, ACM Regions.

4. VPC: đọc route table bằng một request thật#

Sơ đồ ví dụ tự xây cho API container:

Internet → Route 53 → ALB (public subnets ở AZ-A, AZ-B)                         ↓ chỉ port ứng dụng từ ALB SG                 app (private subnets ở AZ-A, AZ-B)                         ↓ chỉ 5432 từ app SG                 RDS (private DB subnets)app → S3 gateway endpoint → S3app → public NAT gateway → IGW → API bên ngoài (IPv4)

VPC ví dụ 10.20.0.0/16; subnet /24 được chia theo AZ/tầng. Giữ CIDR không trùng với mạng cần kết nối sau này. Route table chọn route có prefix cụ thể nhất phù hợp đích.

Subnet “public” không làm mọi tài nguyên trong đó public. Route, địa chỉ, SG và NACL cùng quyết định kết nối. IPv6 có mô hình riêng: egress-only IGW cho outbound IPv6; không áp nguyên xi public NAT IPv4 cho mọi đích IPv6.

Nguồn: Route tables, Internet gateway, egress-only IGW.

5. Security group, NACL và Flow Logs#

Port trả lời thường là ephemeral port; NACL chỉ mở port 443 một chiều có thể làm HTTPS timeout. SG reference nhận diện nguồn theo SG trong điều kiện hỗ trợ, không sao chép rules của SG nguồn.

Flow Logs hỗ trợ phân tích metadata kết nối bị accept/reject. Nó không phải bản ghi payload HTTP; lỗi IAM vẫn có thể xảy ra dù network flow được accept.

Nguồn: VPC security, SG rules, NACL.

Cho SG của DB nhận từ SG của app bằng CLI#

Rule dưới đây mở 5432 chỉ cho tài nguyên gắn sg-app, không dùng CIDR. Thêm hay bớt instance trong sg-app không cần sửa rule của DB (ID là minh họa; đã kiểm cờ bằng CLI help; chưa chạy trên AWS):

aws ec2 authorize-security-group-ingress \  --group-id sg-0db0000000000000 \  --protocol tcp --port 5432 \  --source-group sg-0app000000000000

6. NAT, VPC endpoints và private access#

Public NAT gateway giúp tài nguyên private khởi tạo traffic tới Internet. Nó không phải inbound load balancer và không thay quyền IAM. Với thiết kế NAT zonal, cân nhắc NAT theo AZ và route cùng AZ để tránh phụ thuộc một AZ và transfer xuyên AZ. Kiểm tra các kiểu NAT/topology hiện có trong Region trước khi triển khai.

AWS hiện có Regional NAT gateway hỗ trợ mở rộng multi-AZ theo mô hình regional. Phân biệt kiểu này với sơ đồ zonal ở trên; kiểm tra availability, cấu hình routing và giá trước khi chọn. Không coi “mỗi AZ phải tạo một NAT riêng” là quy tắc cho mọi kiểu NAT.

Gateway endpoint cho S3/DynamoDB dùng route table; không dùng PrivateLink. Interface endpoint dùng ENI/private IP và PrivateLink cho dịch vụ hỗ trợ; xét SG, DNS, endpoint policy và chi phí. Endpoint policy là lớp kiểm soát bổ sung, không tự cấp quyền dịch vụ.

Ví dụ app private chỉ đọc S3: cân nhắc S3 gateway endpoint để bỏ đường NAT cho traffic đó. App còn gọi LLM API bên ngoài vẫn cần egress khác. Nếu tải nhỏ, nhiều interface endpoints có fixed cost lớn hơn dự đoán; cần so tổng chi phí.

Nguồn: NAT gateways, PrivateLink concepts, gateway endpoints.

Endpoint policy cho S3 gateway endpoint#

Endpoint policy mặc định cho toàn quyền. Policy dưới giới hạn endpoint chỉ truy cập một bucket (mẫu theo tài liệu, tên bucket là minh họa), rồi gắn khi tạo endpoint (đã kiểm cờ bằng CLI help; chưa chạy trên AWS):

{  "Version": "2012-10-17",  "Statement": [{    "Sid": "AllowOneBucket",    "Effect": "Allow",    "Principal": "*",    "Action": ["s3:ListBucket", "s3:GetObject", "s3:PutObject"],    "Resource": [      "arn:aws:s3:::lab-data",      "arn:aws:s3:::lab-data/*"    ]  }]}

aws ec2 create-vpc-endpoint \  --vpc-id vpc-0example00000000 \  --vpc-endpoint-type Gateway \  --service-name com.amazonaws.us-east-1.s3 \  --route-table-ids rtb-0example00000000 \  --policy-document file://endpoint-policy.json

Điểm dễ nhầm theo tài liệu: gateway endpoint chỉ có ở Region đã tạo; không dùng được từ on-premises, từ VPC peering khác Region hay qua Transit Gateway (các trường hợp đó cần interface endpoint); request đi qua endpoint không dùng được aws:SourceIp trong identity/bucket policy mà dùng aws:VpcSourceIp; mặc định có quota 20 gateway endpoint mỗi Region. Nguồn: Gateway endpoints cho S3.

7. Kết nối nhiều VPC và on-premises#

Ví dụ A peer B và B peer C: A không tự đi qua B tới C. Với yêu cầu mạng hub cho nhiều account, xem Transit Gateway thay xây mesh peering bằng tay.

Nguồn: Peering, Transit Gateway, VPN, Direct Connect.

Client VPN và mã hóa trên Direct Connect#

• AWS Client VPN là VPN dựa trên client OpenVPN do AWS quản lý, cho người dùng ở bất cứ đâu vào VPC hoặc mạng on-premises; khác Site-to-Site VPN nối mạng với mạng. Mặc định chưa có authorization rule nào, nên user kết nối được vẫn chưa vào được mạng đích cho tới khi bạn thêm rule theo nhóm AD/IdP. Xác thực bằng Active Directory, federated (SAML) hoặc certificate; cổng 443 hoặc 1194, mặc định 443; tính phí theo giờ cho mỗi endpoint association và mỗi kết nối. Nguồn: What is Client VPN.
• Direct Connect không mã hóa traffic theo mặc định. Hai cách mã hóa theo tài liệu: chạy Site-to-Site VPN (IPsec) trên Direct Connect, hoặc dùng MACsec trên kết nối hỗ trợ (mã hóa từ data center của bạn tới điểm Direct Connect). Nguồn: Encryption in Direct Connect.
• Ba loại virtual interface: private (vào VPC bằng IP riêng), public (tới dịch vụ AWS công khai bằng IP công khai), transit (tới Transit Gateway qua Direct Connect gateway). Nguồn: Virtual interfaces.

8. Route 53, CloudFront và Global Accelerator#

Route 53 là DNS, không proxy HTTP. Weighted routing dùng chia traffic, latency routing chọn theo độ trễ, failover routing dùng primary/secondary với health evaluation, geolocation/geoproximity phục vụ yêu cầu vị trí. TTL/cache DNS khiến chuyển traffic không tức thì cho mọi client.

CloudFront cache nội dung ở edge. Thiết kế cache key theo dữ liệu thật: query/header/cookie đưa vào cache key quá nhiều sẽ giảm cache hit; đưa quá ít có thể trả nhầm dữ liệu. Với nội dung private, cần viewer authorization và cấu hình cache phù hợp.

S3 origin nên private, dùng Origin Access Control (OAC) và bucket policy cho distribution. S3 website endpoint là custom origin, không dùng OAC như S3 REST origin. Signed URL/cookie kiểm soát viewer; OAC kiểm soát CloudFront → S3: hai đoạn khác nhau.

Global Accelerator hướng traffic TCP/UDP qua mạng AWS tới endpoint, có static anycast IP; không phải CDN cache object. Chọn CloudFront khi cần cache HTTP content; đánh giá Accelerator khi cần static IP/global routing cho ứng dụng phù hợp.

Nguồn: Route 53 policies, CloudFront cache key, OAC, Global Accelerator.

Alias hay CNAME trong Route 53#

Alias record là phần mở rộng riêng của Route 53, trỏ tới một số tài nguyên AWS (CloudFront, ELB, API Gateway, S3 website, Global Accelerator, record khác cùng zone, ...). So với CNAME theo tài liệu:

Quy tắc luyện thi: domain gốc trỏ vào ALB hoặc CloudFront thì dùng alias. Nguồn: Alias và non-alias.

CloudFront Functions và Lambda@Edge#

Cả hai chạy code theo sự kiện CloudFront. Số liệu theo trang so sánh của AWS (hạn mức có thể thay đổi, đọc ngày 2026-10-05):

Nguồn: CloudFront Functions và Lambda@Edge.

9. Chọn đúng dịch vụ bảo vệ và phát hiện#

Ví dụ cần “ai xóa security group?” → CloudTrail. Cần “bucket có cấu hình đúng policy nội bộ không?” → Config. Cần “API bị SQL injection request” → WAF kết hợp xử lý input đúng trong ứng dụng.

Nguồn: AWS security services, CloudTrail, Config.

10. Tự kiểm tra#

• Vẽ request Internet → ALB → app → DB, có subnet/route/SG.

  Đáp án

  Đáp án mẫu:

  textReady

  Client --HTTPS 443--> Route 53 (alias) --> ALB (SG-alb: 443 từ Internet)                                  ALB có node ở subnet public của cả hai AZAZ-A                                   AZ-Bpublic 10.20.0.0/24                    public 10.20.1.0/24  rt: 0.0.0.0/0 -> IGW                   rt: 0.0.0.0/0 -> IGWapp 10.20.10.0/24                      app 10.20.11.0/24  SG-app: 8080 từ SG-alb                 SG-app: 8080 từ SG-alb  rt: 0.0.0.0/0 -> NAT                   rt: 0.0.0.0/0 -> NATdb 10.20.20.0/24                       db 10.20.21.0/24  SG-db: 5432 từ SG-app                  SG-db: 5432 từ SG-app  rt: chỉ route local                    rt: chỉ route local

  Phải thấy: ALB cần subnet ở ít nhất hai AZ khác nhau; DB subnet group cũng nên có subnet ở ít nhất hai AZ; DB không có route Internet; SG-db tham chiếu SG-app thay vì CIDR. Sai thường gặp: đặt app ở public subnet "cho dễ" hoặc mở 5432 cho 0.0.0.0/0. Xem GĐ29 mục 4.

• Giải thích vì sao NAT không cho user truy cập app private.

  Đáp án

  Public NAT gateway chỉ dịch địa chỉ cho kết nối do phía trong khởi tạo (outbound). App private không có public IPv4 và subnet private không có route tới IGW cho chiều vào. Đường vào hợp lệ là ALB ở public subnet rồi tới app qua SG. NAT không phải load balancer và không cấp quyền IAM. Sai thường gặp: tưởng đặt NAT là mở app ra Internet. Xem mục 6.

• Phân biệt role trust và permission; tìm explicit deny.

  Đáp án

  Trust policy trả lời "ai được assume role"; permission policy trả lời "role làm được gì". Có trust mà thiếu permission thì assume được nhưng bị AccessDenied khi gọi API. Explicit deny có thể nằm ở identity policy, resource policy, permissions boundary, SCP; nó thắng mọi allow. Cùng account: identity policy và resource policy được cộng (union); boundary và SCP là giới hạn trần (intersection), không tự cấp quyền. Cách tìm deny: đọc từng lớp theo thứ tự, dùng CloudTrail để biết principal và action thật, và IAM policy simulator (chưa chạy ở đây). Xem mục 2.

• Phân biệt S3 gateway endpoint với interface endpoint.

  Đáp án

  Gateway: chỉ S3 và DynamoDB, hoạt động bằng route trong route table, không tính phí thêm, nhưng không dùng được từ on-premises, từ VPC peering khác Region hay qua Transit Gateway. Interface: ENI với private IP (PrivateLink), nhiều dịch vụ, có chi phí, dùng được từ on-premises. Với app private chỉ đọc S3 trong cùng Region, gateway endpoint thường là phương án "most cost-effective". Xem mục 6.

• Giải thích S3 access và KMS decrypt là hai quyền khác nhau.

  Đáp án

  Đọc object SSE-KMS cần s3:GetObject và kms:Decrypt trên key; ghi cần kms:GenerateDataKey. Với KMS, IAM policy chỉ có tác dụng cấp quyền khi key policy cho phép (key policy mặc định bật IAM policies; nếu key policy không bật, allow trong IAM vô hiệu). Sai thường gặp: chỉ sửa IAM role rồi vẫn AccessDenied. Từ 05/01/2023 object mới được mã hóa SSE-S3 mặc định; đó là mặc định khác với SSE-KMS. Xem mục 3.

• Chọn đúng DNS/CDN/global routing cho một yêu cầu.

  Đáp án

  Route 53 chỉ là DNS (weighted, latency, failover, geolocation); CloudFront cache nội dung HTTP ở edge, S3 origin private dùng OAC; Global Accelerator đưa TCP/UDP qua mạng AWS, cấp hai địa chỉ IPv4 anycast tĩnh theo mặc định, không cache. Cách chọn: cần cache file tĩnh toàn cầu thì CloudFront; cần IP tĩnh/failover nhanh cho ứng dụng không phải HTTP cache thì Global Accelerator; chuyển vùng theo chính sách DNS thì Route 53. Sai thường gặp: dùng Route 53 failover rồi cho rằng dữ liệu cũng đã failover (chỉ DNS đổi). Xem mục 8.

• Debug timeout và AccessDenied theo hai đường kiểm tra khác nhau.

  Đáp án

  Hai triệu chứng, hai tầng:

  textReady

  Timeout (không có phản hồi)          AccessDenied / 403 (có phản hồi)-> tầng mạng                         -> tầng danh tính và quyền1. route table đúng đích chưa?       1. aws sts get-caller-identity2. SG đích mở port từ nguồn chưa?       (principal thật của app là ai)3. NACL hai chiều (ephemeral port)?  2. policy của role, resource policy4. đích có lắng nghe không, health?  3. boundary, SCP, explicit deny5. VPC Flow Logs: ACCEPT hay REJECT  4. KMS key policy nếu dữ liệu mã hóa6. Reachability Analyzer             5. CloudTrail: event bị từ chối

  Có phản hồi AccessDenied nghĩa là gói tin đã đi và về được, nên đừng sửa SG. Timeout thường là route/SG/NACL, đừng sửa IAM. NACL không có trạng thái: mở 443 chiều vào mà thiếu chiều ra cho cổng ephemeral (tài liệu AWS khuyên mở 1024-65535 để phủ nhiều loại client; yêu cầu từ ELB và NAT gateway dùng 1024-65535) thì HTTPS timeout. NACL mặc định của VPC cho phép mọi traffic; NACL tạo mới chặn mọi traffic tới khi thêm rule. Xem mục 5 và mục 2.

• Một role có identity policy cho s3:GetObject, boundary cho s3:*, nhưng bucket policy có Deny khi request không đi qua endpoint. Vì sao request từ laptop vẫn bị từ chối, và sửa ở đâu?

  Đáp án

  Explicit deny trong resource policy thắng mọi allow, nên identity policy đúng vẫn không cứu được. Thông báo lỗi dạng with an explicit deny in a resource-based policy (nếu dịch vụ dùng định dạng này) chỉ đúng lớp cần sửa. Sửa bằng cách cho request đi qua endpoint hoặc đổi điều kiện của Deny; thêm Allow vào identity policy không giúp được gì. Sai thường gặp: cấp thêm quyền cho role. Xem mục 2 (ví dụ vì sao AccessDenied).

• Chọn Cognito user pool, identity pool hay IAM Identity Center cho ba nhu cầu: (a) khách hàng đăng nhập vào SPA của bạn, backend kiểm JWT; (b) app di động tải ảnh thẳng lên S3 bằng credentials tạm; (c) kỹ sư công ty dùng IdP công ty vào năm account AWS.

  Đáp án

  (a) User pool: phát JWT, backend tự kiểm, không cần identity pool. (b) User pool để đăng nhập cộng identity pool để đổi token lấy credentials STS, role có trust policy khóa theo pool ID. (c) IAM Identity Center với permission set gán cho group ở từng account. Sai thường gặp: dùng identity pool để lưu hồ sơ user, hoặc dùng Cognito cho nhân viên vào console AWS. Xem mục 1.

Tiếp: GĐ30 — Compute & Resilience.