Ngân hàng đề — AWS Certified Security Specialty

Đáp án

D — Cấu hình resource policy trên API Gateway với điều kiện aws:SourceIp để cho phép các dải IP cụ thể.

Vì sao đúng

Đề yêu cầu: chỉ cho phép truy cập từ một số dải IP nhất định, và resource policy của API Gateway là nơi làm việc đó:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": "*",
    "Action": "execute-api:Invoke",
    "Resource": "arn:aws:execute-api:ap-northeast-1:123456789012:abc123/*",
    "Condition": {
      "IpAddress": {
        "aws:SourceIp": ["203.0.113.0/24", "198.51.100.0/24"]
      }
    }
  }]
}

Vì sao resource policy là nơi đúng: | Đặc điểm | Chi tiết | |---|---| | Áp cho MỌI request tới API | không phụ thuộc vào từng người gọi | | Đánh giá TRƯỚC khi request tới backend | request bị chặn không tốn tài nguyên xử lý | | Không cần sửa mã ứng dụng | cấu hình thuần | | Kết hợp được với xác thực | resource policy + IAM/Cognito authorizer |

Và aws:SourceIp là condition key đúng cho việc lọc theo IP.

Một chi tiết quan trọng cần biết: với private API (truy cập qua VPC endpoint), aws:SourceIp không hoạt động — vì lưu lượng đi qua endpoint và IP nguồn không được giữ nguyên theo cách policy đọc được. Với private API phải dùng aws:SourceVpc hoặc aws:SourceVpce. Đề nói đây là API công khai nên aws:SourceIp là đúng.

Cũng lưu ý mẫu Deny thường dùng hơn trong thực tế:

{"Effect": "Deny", "Principal": "*", "Action": "execute-api:Invoke",
 "Resource": "...",
 "Condition": {"NotIpAddress": {"aws:SourceIp": ["203.0.113.0/24"]}}}

Dạng này chặt hơn: nó từ chối tất cả trừ danh sách trắng, thay vì chỉ cho phép danh sách trắng (vốn có thể bị statement Allow khác ở nơi khác bù vào).

Vì sao các phương án khác sai

• A. Cấu hình resource policy trên API Gateway với điều kiện aws:PrincipalArn để cho phép các dải IP cụ thể — đây là phương án gần nhất và sai condition key: aws:PrincipalArn là ARN của người gọi, không phải địa chỉ IP. Không thể đặt dải IP vào đó.
• B. Cấu hình security group trên API Gateway chỉ cho phép các dải IP cụ thể — API Gateway KHÔNG có security group: nó là dịch vụ được quản lý hoàn toàn, không nằm trong VPC của bạn (trừ trường hợp private API dùng VPC endpoint, và khi đó security group nằm trên endpoint chứ không trên API).
• C. Cấu hình network ACL trên subnet của API Gateway chỉ cho phép các dải IP cụ thể — cùng lỗi khái niệm: API Gateway không nằm trong subnet nào của bạn.

Ghi nhớ

Bốn cơ chế kiểm soát truy cập của API Gateway — hiểu rõ vai trò từng cái: | Cơ chế | Kiểm soát | Đánh giá khi | |---|---|---| | Resource policy | ai/từ đâu gọi được API | trước authorizer | | IAM authorization | request phải ký SigV4 | với từng request | | Cognito / Lambda authorizer | token hợp lệ không | với từng request | | Usage plan + API key | đo lường và giới hạn tần suất — KHÔNG phải bảo mật | sau xác thực | | WAF | lọc mẫu request độc hại | trước tất cả |

Ba condition key lọc theo nguồn — chọn đúng theo loại endpoint: | Condition key | Dùng cho | |---|---| | aws:SourceIp | API CÔNG KHAI (edge/regional) ← câu này | | aws:SourceVpc | private API — theo VPC | | aws:SourceVpce | private API — theo endpoint cụ thể (chặt nhất) |

Đây là bảng cần thuộc: dùng aws:SourceIp cho private API là lỗi phổ biến và policy sẽ chặn hết mọi request vì điều kiện không bao giờ khớp.

Ba lưu ý khi dùng resource policy: | Lưu ý | Chi tiết | |---|---| | Phải DEPLOY API sau khi sửa policy | thay đổi không có tác dụng cho tới khi deploy stage | | Kết hợp với IAM thì cả hai phải cho phép | policy này là lớp bổ sung, không thay thế | | Principal: "*" không có nghĩa là không xác thực | nó chỉ nói policy áp cho mọi người gọi |

Dòng đầu là bẫy vận hành hay gặp nhất: sửa resource policy trong Console, thấy đã lưu, nhưng API vẫn hành xử như cũ — vì chưa deploy.

Và một lựa chọn thay thế đáng cân nhắc cho lọc IP quy mô lớn: AWS WAF với IP set. Nó phù hợp hơn khi: | Tình huống | Vì sao WAF tốt hơn | |---|---| | Danh sách IP dài hoặc thay đổi thường xuyên | IP set quản lý riêng, không phải sửa policy | | Cần cả lọc IP lẫn quy tắc khác | SQL injection, rate limiting, geo blocking | | Cần dùng chung cho nhiều API | một Web ACL gắn cho nhiều tài nguyên |

Với vài dải IP cố định như đề mô tả, resource policy là đủ và không tốn thêm chi phí.

Đáp án

B và E.

• B — Khi private DNS được bật trên interface endpoint của API Gateway, VPC đó KHÔNG truy cập được API Gateway CÔNG KHAI nữa
• E — Security group của VPC endpoint phải cho phép lưu lượng vào trên cổng 443 từ CIDR của VPC

Vì sao đúng

Đề hỏi hai điều cần biết khi dựng private API qua interface endpoint, và B+E là hai điểm quan trọng nhất.

B — đánh đổi của private DNS:

Private DNS TẮT:
  execute-api.ap-northeast-1.amazonaws.com
      → phân giải ra IP CÔNG KHAI → gọi được API công khai
  Gọi private API thì phải dùng tên DNS riêng của endpoint

Private DNS BẬT:
  execute-api.ap-northeast-1.amazonaws.com
      → phân giải ra IP RIÊNG của endpoint (trong VPC)
  → tiện: mã không cần sửa
  → NHƯNG: mọi API Gateway CÔNG KHAI đều không gọi được từ VPC này

Đây là hệ quả thực tế đáng cân nhắc: nếu ứng dụng trong VPC cần gọi cả private API của mình lẫn một API Gateway công khai (của đối tác chẳng hạn), bật private DNS sẽ làm hỏng vế thứ hai.

Cách khắc phục nếu cần cả hai: | Cách | Chi tiết | |---|---| | Tắt private DNS | dùng tên DNS riêng của endpoint cho private API | | Dùng VPC riêng | tách hai nhu cầu | | Route 53 private hosted zone | định tuyến chọn lọc theo tên miền |

E — security group là điều kiện bắt buộc:

Security group của VPC ENDPOINT:
  Type: HTTPS   Protocol: TCP   Port: 443
  Source: 10.0.0.0/16   ← CIDR của VPC (hoặc SG của ứng dụng)

Đây là lỗi cấu hình phổ biến nhất với interface endpoint: endpoint được tạo thành công, hiện trạng thái available, nhưng mọi lời gọi đều timeout — vì security group mặc định không cho phép gì cả.

Vì sao các phương án khác sai

• A. Khi private DNS được bật, VPC đó VẪN truy cập được API Gateway công khai — đây là phương án gần nhất và mâu thuẫn trực tiếp với B: đó chính là điều không còn làm được.
• C. Security group của VPC endpoint phải cho phép lưu lượng vào trên cổng 80 — sai cổng: API Gateway dùng HTTPS (443), không phải HTTP (80).
• D. Network ACL của subnet chứa endpoint phải cho phép lưu lượng vào trên cổng 443 — gần đúng nhưng không chính xác: NACL mặc định cho phép mọi lưu lượng, nên đây không phải điều bắt buộc phải cấu hình. Và quan trọng hơn: NACL không có trạng thái, nên nếu bạn siết NACL thì phải mở cả cổng 443 vào lẫn dải cổng tạm (1024–65535) ra — phát biểu chỉ nói cổng 443 vào là thiếu.

Ghi nhớ

Ba yêu cầu để private API hoạt động:

① Interface VPC endpoint cho execute-api
② Security group của endpoint cho phép 443 từ nguồn cần thiết
③ API Gateway resource policy cho phép aws:SourceVpce hoặc aws:SourceVpc

Thiếu ② thì timeout; thiếu ③ thì 403 — hai triệu chứng khác nhau, hữu ích khi gỡ lỗi.

Hai cách gọi private API: | Cách | URL | |---|---| | Private DNS bật | https://<api-id>.execute-api.<region>.amazonaws.com/<stage> | | Private DNS tắt | https://<vpce-id>-<random>.execute-api.<region>.vpce.amazonaws.com/<stage> kèm header Host: <api-id>.execute-api... |

Cách thứ hai phức tạp hơn nhưng giữ được khả năng gọi API công khai — đó là đánh đổi mà phương án B nói tới.

Điều kiện để private DNS hoạt động: | Điều kiện | Chi tiết | |---|---| | enableDnsSupport = true trên VPC | bắt buộc | | enableDnsHostnames = true trên VPC | bắt buộc | | Bật PrivateDnsEnabled trên endpoint | |

Hai dòng đầu hay bị bỏ sót: nếu VPC được tạo bằng CloudFormation hoặc Terraform với cấu hình tối thiểu, hai cờ này có thể đang tắt — và private DNS âm thầm không hoạt động.

Ba loại resource policy cho private API:

// Theo VPC endpoint cụ thể — CHẶT NHẤT
{"Condition": {"StringEquals": {"aws:SourceVpce": "vpce-0abc123"}}}

// Theo VPC
{"Condition": {"StringEquals": {"aws:SourceVpc": "vpc-0abc123"}}}

// Theo tổ chức
{"Condition": {"StringEquals": {"aws:PrincipalOrgID": "o-abc123"}}}

Security group và NACL cho endpoint — phân biệt: | | Security group | NACL | |---|---|---| | Mặc định | chặn hết inbound | cho phép hết | | Trạng thái | có — phản hồi tự động qua | không — phải mở cả hai chiều | | Phải cấu hình? | ✅ bắt buộc | thường không cần |

Bảng này giải thích vì sao E đúng còn D không: security group là thứ bắt buộc phải mở, NACL thì mặc định đã thông.

Đáp án

A — Cấu hình IAM policy cho các phòng ban khác nhau, cấp quyền dựa trên thẻ (tag) của tài nguyên và thẻ của principal.

Vì sao đúng

Đề nêu tình huống: nhiều phòng ban, mỗi phòng chỉ được truy cập tài nguyên của mình, cần giải pháp mở rộng được và ít công quản lý.

Đây là ABAC — Attribute-Based Access Control, và nó giải quyết đúng vấn đề mở rộng:

{
  "Effect": "Allow",
  "Action": ["ec2:StartInstances", "ec2:StopInstances"],
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "ec2:ResourceTag/PhongBan": "${aws:PrincipalTag/PhongBan}"
    }
  }
}

Sức mạnh của ${aws:PrincipalTag/...}: một policy duy nhất phục vụ mọi phòng ban. Người dùng có tag PhongBan=KeToan chỉ chạm được tài nguyên có tag PhongBan=KeToan.

So sánh công sức khi mở rộng: | | ABAC (đáp án A) | RBAC truyền thống | |---|---|---| | Thêm một phòng ban | gắn tag cho người và tài nguyên — KHÔNG sửa policy | viết policy mới + tạo role mới | | Thêm tài nguyên | gắn tag | sửa policy để thêm ARN | | Số policy phải bảo trì | MỘT | một cho mỗi phòng ban |

Và đề nhấn mạnh "scalable" cùng "minimizing administrative overhead" — đó chính xác là điểm mạnh của ABAC.

Cách thực hiện đầy đủ:

① Gắn tag cho người dùng/role:      PhongBan=KeToan
② Gắn tag cho tài nguyên:            PhongBan=KeToan
③ Một IAM policy so khớp hai tag
④ Bắt buộc gắn tag khi TẠO tài nguyên (aws:RequestTag)

Bước ④ là điều kiện để hệ thống không có lỗ hổng:

{"Effect": "Deny", "Action": "ec2:RunInstances", "Resource": "arn:aws:ec2:*:*:instance/*",
 "Condition": {"StringNotEquals": {
   "aws:RequestTag/PhongBan": "${aws:PrincipalTag/PhongBan}"}}}

Vì sao các phương án khác sai

• D. Dùng IAM role có permissions boundary để hạn chế truy cập cho các phòng ban khác nhau — đây là phương án gần nhất và là công cụ hữu ích, nhưng permissions boundary là TRẦN quyền cho một entity, không phải cơ chế phân tách theo phòng ban. Nó vẫn cần một boundary riêng cho mỗi phòng — không mở rộng tốt hơn RBAC. (Boundary bổ sung tốt cho ABAC: dùng nó để đảm bảo không ai tự sửa tag của mình.)
• B. Dùng IAM group để nhóm người dùng và gán quyền theo group — RBAC truyền thống: hoạt động được nhưng cần một group + một policy cho mỗi phòng ban, và mỗi tài nguyên mới phải thêm vào policy. Đúng là điều mà yêu cầu "scalable" muốn tránh.
• C. Dùng AWS Organizations SCP hạn chế truy cập cho các phòng ban khác nhau — sai mức phân tách: SCP áp cho tài khoản hoặc OU, nên nó chỉ hoạt động nếu mỗi phòng ban có tài khoản riêng. Đề không nói vậy, và SCP không cấp quyền — nó chỉ đặt trần.

Ghi nhớ

ABAC và RBAC — bảng so sánh cốt lõi: | | ABAC | RBAC | |---|---|---| | Quyết định dựa trên | thuộc tính (tag) | vai trò được gán | | Số policy | ít — thường một | tăng theo số vai trò | | Thêm tài nguyên mới | tự động áp dụng nếu có tag | phải sửa policy | | Kiểm toán | khó hơn — phải xem tag | dễ hơn — đọc policy là biết | | Phù hợp | tổ chức lớn, tài nguyên thay đổi nhiều | tổ chức nhỏ, quyền ổn định |

Dòng "kiểm toán" là nhược điểm thật của ABAC và đáng nói thẳng: với RBAC, đọc policy là biết ai truy cập được gì. Với ABAC, phải kiểm tra tag của cả người dùng lẫn tài nguyên — nên cần công cụ hỗ trợ (IAM Access Analyzer, AWS Config).

Ba condition key của ABAC: | Key | Nghĩa | |---|---| | aws:PrincipalTag/<key> | tag trên NGƯỜI GỌI | | aws:ResourceTag/<key> hoặc <service>:ResourceTag/<key> | tag trên TÀI NGUYÊN | | aws:RequestTag/<key> | tag được gửi TRONG REQUEST (lúc tạo) | | aws:TagKeys | danh sách khoá tag trong request |

Ba biện pháp bắt buộc để ABAC an toàn: | Biện pháp | Chống lại | |---|---| | Bắt buộc gắn tag khi tạo tài nguyên | tài nguyên không tag = không ai quản được | | CẤM sửa tag đã có | người dùng đổi tag để tự cấp quyền | | Cấm sửa tag của chính principal | tự nâng quyền |

Dòng giữa là lỗ hổng nghiêm trọng nhất của ABAC nếu quên:

{"Effect": "Deny",
 "Action": ["ec2:CreateTags", "ec2:DeleteTags"],
 "Resource": "*",
 "Condition": {"ForAnyValue:StringEquals": {"aws:TagKeys": ["PhongBan"]}}}

Không có statement này, bất kỳ ai cũng đổi tag PhongBan của một tài nguyên thành phòng của mình và chiếm quyền.

Ba nguồn tag cho principal: | Nguồn | Cách gắn | |---|---| | IAM user/role tag | gắn trực tiếp | | Session tag khi assume role | sts:AssumeRole với Tags | | SAML attribute | IdP gửi thuộc tính → thành session tag ← mẫu chuẩn cho tổ chức dùng AD |

Dòng cuối là cách ABAC được dùng thật ở quy mô doanh nghiệp: phòng ban của nhân viên đã có sẵn trong Active Directory, và nó tự động thành session tag khi đăng nhập — không phải quản lý tag ở hai nơi.

Đáp án

B, D và E:

• B — Cho phép kms:Decrypt trong IAM policy của Lambda execution role
• D — Cho phép kms:GenerateDataKey trong IAM policy của Lambda execution role
• E — Thêm Lambda execution role vào KEY POLICY của KMS key

Vì sao đúng

Đề mô tả: Lambda đọc và ghi object trên bucket S3 mã hoá bằng SSE-KMS, và cần quyền gì cho việc đó.

Hai quyền KMS cho hai thao tác — đây là điểm cốt lõi: | Thao tác S3 | Quyền KMS cần | |---|---| | Đọc object (GetObject) | kms:Decrypt | | Ghi object (PutObject) | kms:GenerateDataKey (và thường cả Decrypt cho multipart) |

Vì sao ghi cần GenerateDataKey chứ không phải Encrypt:

S3 ghi object với SSE-KMS:
  ① S3 gọi kms:GenerateDataKey → nhận data key dạng RÕ + dạng MÃ HOÁ
  ② Mã hoá object bằng data key dạng rõ
  ③ Vứt bỏ bản rõ, lưu bản mã hoá cùng object

S3 không bao giờ gọi kms:Encrypt cho SSE-KMS — nó dùng mã hoá phong bì. Đây là chi tiết bị nhầm rất thường xuyên.

Triệu chứng kinh điển khi thiếu GenerateDataKey:

GetObject  → thành công (có kms:Decrypt)
PutObject  → AccessDenied

Đọc được nhưng ghi thất bại — và thông báo lỗi không nói rõ thiếu quyền KMS nào.

E — key policy là vế thứ hai bắt buộc:

Quyền KMS cần CẢ HAI:
  ① IAM policy của principal  (B và D)
  ② KEY POLICY của KMS key    (E)

Đây là đặc điểm riêng của KMS, khác với hầu hết dịch vụ AWS: key policy là nguồn quyền chính, và IAM policy chỉ có tác dụng nếu key policy uỷ quyền cho tài khoản.

{
  "Sid": "Cho phep Lambda su dung khoa",
  "Effect": "Allow",
  "Principal": {"AWS": "arn:aws:iam::123456789012:role/lambda-xu-ly-anh"},
  "Action": ["kms:Decrypt", "kms:GenerateDataKey"],
  "Resource": "*"
}

Vì sao các phương án khác sai

• A. Cho phép kms:Encrypt trong IAM policy của Lambda execution role — đây là phương án gần nhất và là hiểu lầm phổ biến nhất về SSE-KMS: S3 dùng mã hoá phong bì, nên nó gọi GenerateDataKey chứ không phải Encrypt. Cấp kms:Encrypt không giúp gì cho việc ghi object.
• C. Cho phép kms:ReEncrypt trong IAM policy — không cần cho luồng thông thường: ReEncrypt dùng khi đổi khoá mã hoá của dữ liệu đã mã hoá (ví dụ chuyển sang CMK khác) mà không cần giải mã ra bản rõ. Không phải thao tác đọc/ghi bình thường.
• F. Thêm Lambda execution role vào BUCKET POLICY của S3 bucket — không cần thiết: trong cùng một tài khoản, IAM policy là đủ cho quyền S3. Bucket policy chỉ cần khi truy cập chéo tài khoản hoặc khi cần Deny bao quát. (Và đề hỏi về quyền KMS, không phải quyền S3.)

Ghi nhớ

Quyền KMS cho từng thao tác S3 với SSE-KMS — bảng cần thuộc: | Thao tác | Quyền KMS | |---|---| | GetObject | kms:Decrypt | | PutObject | kms:GenerateDataKey | | Multipart upload | kms:GenerateDataKey + kms:Decrypt | | CopyObject | cả hai (giải mã nguồn, mã hoá đích) | | Đổi khoá | kms:ReEncrypt |

Quy tắc thực dụng: cấp cả Decrypt và GenerateDataKey cho principal cần đọc-ghi — thiếu một trong hai gây lỗi khó chẩn đoán.

Hai lớp quyền của KMS — điểm khác biệt lớn nhất so với dịch vụ khác:

① KEY POLICY (bắt buộc)
   → nguồn quyền CHÍNH của KMS key
   → không có statement cho principal hoặc cho tài khoản = KHÔNG AI dùng được

② IAM POLICY
   → chỉ có tác dụng nếu key policy uỷ quyền cho tài khoản

Statement uỷ quyền cho tài khoản — có nó thì IAM policy mới hoạt động:

{"Sid": "Uy quyen cho IAM cua tai khoan",
 "Effect": "Allow",
 "Principal": {"AWS": "arn:aws:iam::123456789012:root"},
 "Action": "kms:*", "Resource": "*"}

Đây là statement mặc định khi tạo CMK qua Console — nếu bạn xoá nó và không thêm principal cụ thể nào, khoá trở nên không dùng được và không sửa được (xem thêm câu #7696).

Ba cơ chế cấp quyền KMS: | Cơ chế | Đặc điểm | |---|---| | Key policy | bắt buộc, là gốc | | IAM policy | cần key policy uỷ quyền cho tài khoản | | Grant | cấp quyền tạm thời, chi tiết — dùng cho dịch vụ AWS |

Grant đáng biết: nhiều dịch vụ AWS (EBS, RDS, DynamoDB) tự tạo grant khi bạn bật mã hoá — đó là cách chúng lấy quyền dùng khoá mà không cần bạn sửa key policy.

Ba điều kiện hữu ích trong key policy:

// Chỉ cho phép qua dịch vụ S3
{"Condition": {"StringEquals": {"kms:ViaService": "s3.ap-northeast-1.amazonaws.com"}}}

// Ràng buộc theo encryption context
{"Condition": {"StringEquals": {"kms:EncryptionContext:phong-ban": "ke-toan"}}}

// Chỉ trong tổ chức
{"Condition": {"StringEquals": {"aws:PrincipalOrgID": "o-abc123"}}}

kms:ViaService đặc biệt hữu ích: nó đảm bảo khoá chỉ dùng được thông qua S3, không dùng trực tiếp qua API KMS — thu hẹp đáng kể phạm vi nếu role bị lạm dụng.

Đáp án

B — Dùng AWS Systems Manager Session Manager để truy cập instance mà không cần mở cổng SSH.

Vì sao đúng

Đề yêu cầu: truy cập instance trong private subnet để bảo trì, an toàn nhất và không mở cổng vào Internet.

Session Manager loại bỏ hoàn toàn nhu cầu mở cổng:

Cách truyền thống (bastion host):
  Internet → bastion (cổng 22 MỞ ra Internet) → instance private
  ✗ một máy phơi ra Internet
  ✗ SSH key phải quản lý và xoay vòng
  ✗ bastion là mục tiêu tấn công

Session Manager:
  Người dùng → AWS API (HTTPS, xác thực bằng IAM)
                    ↓
  SSM Agent trên instance KHỞI TẠO kết nối RA (outbound 443)
  ✓ KHÔNG có cổng inbound nào mở
  ✓ KHÔNG có SSH key
  ✓ KHÔNG cần bastion

Điểm mấu chốt: chiều kết nối là RA, không phải VÀO. SSM Agent trên instance chủ động kết nối tới dịch vụ Systems Manager, và phiên làm việc đi qua kênh đó. Nên security group của instance không cần rule inbound nào cả.

Bốn lợi ích bảo mật: | Lợi ích | Chi tiết | |---|---| | Không có cổng inbound | giảm diện tích tấn công về gần bằng không | | Không có SSH key | không có bí mật để mất hay xoay vòng | | Kiểm soát bằng IAM | phân quyền theo tag của instance, theo người dùng | | Kiểm toán đầy đủ | CloudTrail ghi ai mở phiên; session log ghi CẢ NỘI DUNG PHIÊN |

Dòng cuối là giá trị lớn nhất về tuân thủ: bật session logging ghi lại toàn bộ lệnh gõ vào S3 hoặc CloudWatch Logs — điều rất khó làm với SSH truyền thống.

Vì sao các phương án khác sai

• A. Dùng bastion host trong public subnet để truy cập instance private — đây là phương án gần nhất và là cách làm truyền thống hợp lệ, nhưng nó thua Session Manager ở mọi mặt: phải mở cổng 22 ra Internet, phải quản lý SSH key, phải vá và giám sát thêm một máy, và bastion trở thành mục tiêu tấn công.
• C. Dùng VPN kết nối tới VPC và truy cập instance qua IP riêng — hoạt động và an toàn, nhưng nhiều công hơn hẳn: phải dựng và vận hành VPN, quản lý chứng chỉ hoặc pre-shared key, và vẫn cần quản lý SSH key cho chặng cuối. Là giải pháp đúng cho nhu cầu truy cập mạng rộng, quá nặng cho việc bảo trì instance.
• D. Dùng Direct Connect kết nối tới VPC và truy cập instance qua IP riêng — hoàn toàn không tương xứng: Direct Connect là kết nối vật lý chuyên dụng, mất hàng tuần tới hàng tháng để thiết lập và tốn kém. Dùng nó để bảo trì vài instance là không hợp lý.

Ghi nhớ

Bốn cách truy cập instance trong private subnet — theo mức khuyến nghị: | Cách | Cổng inbound | Quản lý key | Công sức | |---|---|---|---| | Session Manager | KHÔNG | KHÔNG | thấp nhất | | EC2 Instance Connect Endpoint | KHÔNG | tạm thời, tự động | thấp | | Bastion host | CÓ (22) | CÓ | trung bình | | VPN / Direct Connect | không (qua mạng riêng) | CÓ | cao |

Dòng thứ hai đáng biết: EC2 Instance Connect Endpoint là lựa chọn tương tự Session Manager nhưng dùng giao thức SSH thật — hữu ích khi công cụ của bạn cần SSH (scp, rsync, port forwarding kiểu SSH).

Ba yêu cầu để dùng Session Manager (xem thêm câu #7693):

① SSM Agent cài và đang chạy
② IAM instance profile có AmazonSSMManagedInstanceCore
③ Đường mạng tới endpoint SSM (VPC endpoint hoặc NAT)

Ba tính năng nâng cao của Session Manager: | Tính năng | Việc | |---|---| | Session logging | ghi toàn bộ nội dung phiên vào S3 hoặc CloudWatch Logs | | Port forwarding | chuyển tiếp cổng — truy cập CSDL private từ máy cá nhân | | Run As | chạy phiên dưới danh nghĩa một user hệ điều hành cụ thể | | KMS encryption | mã hoá dữ liệu phiên |

Port forwarding đáng biết: nó cho phép kết nối tới RDS trong private subnet từ máy tính của bạn mà không cần bastion và không mở gì:

aws ssm start-session --target i-0abc123   --document-name AWS-StartPortForwardingSessionToRemoteHost   --parameters '{"host":["db.abc.rds.amazonaws.com"],
                 "portNumber":["3306"],"localPortNumber":["3306"]}'

Ba cách siết chặt quyền mở phiên bằng IAM:

// Chỉ mở được phiên tới instance có tag Moi-Truong=dev
{"Effect": "Allow", "Action": "ssm:StartSession",
 "Resource": "arn:aws:ec2:*:*:instance/*",
 "Condition": {"StringEquals": {"ssm:resourceTag/Moi-Truong": "dev"}}}

Và một điểm đáng nói về việc dừng dùng bastion: chuyển sang Session Manager cho phép bạn xoá hẳn public subnet cho tầng ứng dụng và đóng cổng 22 trên mọi security group — hai thay đổi làm giảm đáng kể bề mặt tấn công của toàn bộ hệ thống.

Đáp án

B — Tạo metric filter trên CloudWatch Logs khớp với BẤT KỲ thay đổi nào của security group, và tạo CloudWatch alarm kích hoạt SNS.

Vì sao đúng

Đề yêu cầu: cảnh báo khi security group thay đổi, và mấu chốt nằm ở chữ "bất kỳ".

Các sự kiện liên quan tới thay đổi security group: | Sự kiện | Việc | |---|---| | AuthorizeSecurityGroupIngress | thêm rule vào | | AuthorizeSecurityGroupEgress | thêm rule ra | | RevokeSecurityGroupIngress | xoá rule vào | | RevokeSecurityGroupEgress | xoá rule ra | | CreateSecurityGroup | tạo mới | | DeleteSecurityGroup | xoá | | ModifySecurityGroupRules | sửa rule |

Metric filter phải bắt hết:

{ ($.eventName = "AuthorizeSecurityGroupIngress") ||
  ($.eventName = "AuthorizeSecurityGroupEgress")  ||
  ($.eventName = "RevokeSecurityGroupIngress")    ||
  ($.eventName = "RevokeSecurityGroupEgress")     ||
  ($.eventName = "CreateSecurityGroup")           ||
  ($.eventName = "DeleteSecurityGroup") }

Vì sao "bất kỳ thay đổi nào" là yêu cầu đúng về mặt bảo mật: | Thay đổi | Rủi ro | |---|---| | Thêm rule inbound | mở cổng ra ngoài — rủi ro rõ ràng | | XOÁ rule | có thể phá vỡ kiểm soát an ninh hiện có | | Tạo security group mới | có thể được gắn vào tài nguyên với rule lỏng lẻo | | Xoá security group | tài nguyên có thể rơi về SG mặc định |

Cả bốn đều đáng cảnh báo — chỉ theo dõi việc thêm rule là bỏ sót nửa vấn đề.

Và đây là một trong các kiểm soát của CIS AWS Foundations Benchmark — kiểm soát 4.10: "Ensure a log metric filter and alarm exist for security group changes".

Vì sao các phương án khác sai

• A. Tạo metric filter khớp với thay đổi thêm rule INBOUND cho phép truy cập từ mọi nơi (0.0.0.0/0), và alarm kích hoạt SNS — đây là phương án gần nhất và là cảnh báo có giá trị cao, nhưng nó quá hẹp so với yêu cầu: đề nói "when there are changes to the security groups", không giới hạn ở rule mở toàn bộ. Nó bỏ sót việc mở một cổng cho một IP cụ thể trái phép, và bỏ sót việc xoá rule.
• C. Tạo VPC Flow Log giám sát lưu lượng vào và ra khỏi security group, và alarm kích hoạt SNS — sai loại dữ liệu: Flow Logs ghi lưu lượng mạng thực tế, không ghi thay đổi cấu hình. Nó cho biết ai kết nối tới đâu, không cho biết ai sửa rule.
• D. Tạo VPC Flow Log giám sát lưu lượng vào và ra khỏi VPC, và alarm kích hoạt SNS — cùng lỗi như C, phạm vi rộng hơn nhưng vẫn sai loại dữ liệu.

Ghi nhớ

Ba cách phát hiện thay đổi security group — nên dùng nhiều lớp: | Cách | Đặc điểm | |---|---| | CloudTrail + metric filter + alarm | cảnh báo theo ngưỡng ← câu này | | EventBridge rule | phản ứng NGAY từng sự kiện, độ trễ thấp hơn | | AWS Config rule | đánh giá tuân thủ liên tục + tự khắc phục |

Config đáng nói thêm cho trường hợp này: managed rule vpc-sg-open-only-to-authorized-ports và restricted-ssh đánh giá liên tục, và có thể gắn remediation action tự động gỡ rule vi phạm — mạnh hơn chỉ cảnh báo.

Chín kiểm soát giám sát của CIS AWS Foundations Benchmark — đáng thuộc: | Kiểm soát | Sự kiện | |---|---| | Đăng nhập Console không có MFA | ConsoleLogin + MFAUsed = No | | Sử dụng root user | userIdentity.type = Root | | Thay đổi IAM policy | Put*Policy, Delete*Policy, Attach*, Detach* | | Thay đổi cấu hình CloudTrail | StopLogging, DeleteTrail, UpdateTrail | | Đăng nhập Console thất bại | errorMessage = Failed authentication | | Thay đổi/xoá CMK | DisableKey, ScheduleKeyDeletion | | Thay đổi S3 bucket policy | PutBucketPolicy, DeleteBucketPolicy | | Thay đổi SECURITY GROUP | ← câu này | | Thay đổi NACL, gateway, route table, VPC | các sự kiện tương ứng |

Danh sách này là bộ cảnh báo nền tảng mà mọi tài khoản AWS production nên có — và Security Hub với chuẩn CIS tự đánh giá xem chúng đã được cấu hình chưa.

Ba mức phản ứng khi security group thay đổi: | Mức | Cơ chế | |---|---| | Cảnh báo | SNS tới đội bảo mật ← câu này | | Ghi nhận và đánh giá | Config rule + Security Hub finding | | Tự động khắc phục | Lambda hoặc SSM Automation gỡ rule vi phạm ngay |

Mức thứ ba đáng cân nhắc cho rule nguy hiểm rõ ràng (ví dụ mở cổng 22 hoặc 3389 cho 0.0.0.0/0): tự động gỡ trong vài giây rồi mới thông báo, thay vì chờ người đọc email.

Và một biện pháp phòng ngừa mạnh hơn giám sát: SCP chặn hẳn việc mở cổng nhạy cảm ra Internet, hoặc yêu cầu mọi thay đổi security group phải qua CI/CD với review. Phát hiện sau khi rule đã mở vẫn để lại một khoảng thời gian bị phơi.

Đáp án

C — Tạo rate-based rule trong AWS WAF giới hạn số request tới URI cụ thể đó từ mỗi IP.

Vì sao đúng

Đề mô tả tình huống rất cụ thể: một URI nhất định đang bị gọi quá nhiều từ một số địa chỉ IP, và cần giới hạn tần suất cho riêng URI đó.

Rate-based rule với scope-down statement là công cụ chính xác:

{
  "Name": "GioiHanUriDangNhap",
  "Priority": 1,
  "Statement": {
    "RateBasedStatement": {
      "Limit": 100,
      "AggregateKeyType": "IP",
      "ScopeDownStatement": {
        "ByteMatchStatement": {
          "SearchString": "/api/dang-nhap",
          "FieldToMatch": {"UriPath": {}},
          "PositionalConstraint": "STARTS_WITH",
          "TextTransformations": [{"Priority": 0, "Type": "LOWERCASE"}]
        }
      }
    }
  },
  "Action": {"Block": {}}
}

ScopeDownStatement là phần làm nên đáp án: nó khiến rate limit chỉ đếm request tới URI đó, không ảnh hưởng tới phần còn lại của ứng dụng.

Cơ chế đếm của rate-based rule: | Đặc điểm | Chi tiết | |---|---| | Cửa sổ đánh giá | 5 phút trượt (cấu hình được: 1, 2, 5, 10 phút) | | Khoá gộp | IP, hoặc header, hoặc cookie, hoặc kết hợp | | Hành động khi vượt | Block, Count, CAPTCHA, Challenge | | Tự động gỡ chặn | khi tần suất giảm xuống dưới ngưỡng |

Và "tự động gỡ chặn" là ưu điểm quan trọng so với việc chặn cứng theo IP: người dùng hợp lệ đứng sau NAT chung với kẻ lạm dụng sẽ được phục vụ lại khi tình hình bình thường.

Vì sao các phương án khác sai

• A. Tạo rate-based rule trong AWS WAF giới hạn số request tới ứng dụng web từ mỗi IP — đây là phương án gần nhất và quá rộng: nó áp cho toàn bộ ứng dụng, nên người dùng hợp lệ duyệt nhiều trang cũng bị chặn, trong khi vấn đề chỉ nằm ở một URI. Đề nói rõ "requests to a specific URI".
• B. Tạo AWS WAF rule chặn request từ các IP cụ thể — giải pháp cứng và thiếu bền: IP thay đổi liên tục, nên bạn phải cập nhật danh sách mãi. Và chặn cứng theo IP nuốt luôn người dùng hợp lệ chia sẻ IP đó (văn phòng, trường học, mạng di động). Rate-based rule tự điều chỉnh theo hành vi thay vì theo danh tính.
• D. Tạo AWS Shield Advanced rule chặn request từ các IP cụ thể — Shield Advanced không có "rule" kiểu đó: nó chống DDoS ở tầng mạng và tầng ứng dụng, cung cấp đội ứng phó (SRT) và bảo vệ chi phí. Việc lọc theo quy tắc là của WAF, và Shield Advanced hoạt động cùng với WAF chứ không thay thế.

Ghi nhớ

Bốn loại statement trong AWS WAF rule: | Loại | Việc | |---|---| | Rate-based | đếm request theo khoá, chặn khi vượt ngưỡng | | Match statement | khớp IP set, chuỗi, regex, kích thước, geo | | Managed rule group | bộ quy tắc sẵn của AWS hoặc bên thứ ba | | Logical | AND, OR, NOT để kết hợp |

Bốn hành động của WAF rule: | Hành động | Kết quả | |---|---| | Allow | cho qua | | Block | chặn, trả 403 (tuỳ chỉnh được phản hồi) | | Count | chỉ đếm — dùng để THỬ rule trước khi bật chặn | | CAPTCHA / Challenge | phân biệt người và bot |

Count là chế độ nên dùng đầu tiên khi triển khai rule mới: nó cho biết rule sẽ chặn bao nhiêu request thật mà chưa gây ảnh hưởng — tránh việc chặn nhầm người dùng hợp lệ.

Challenge đáng biết cho trường hợp này: thay vì chặn hẳn, nó gửi một thử thách JavaScript im lặng — bot không vượt qua được, còn trình duyệt thật thì qua mà người dùng không nhận ra.

Bốn loại AggregateKeyType của rate-based rule: | Khoá | Đếm theo | |---|---| | IP | địa chỉ IP nguồn ← câu này | | FORWARDED_IP | IP trong header X-Forwarded-For — cần khi có CDN/proxy phía trước | | CUSTOM_KEYS | header, cookie, query string, label — kết hợp tối đa 5 khoá | | CONSTANT | toàn bộ request khớp scope-down |

CUSTOM_KEYS mạnh cho trường hợp thực tế: giới hạn theo session ID trong cookie hoặc user ID trong header thay vì IP — chính xác hơn nhiều khi người dùng chia sẻ IP.

Bốn tài nguyên gắn được Web ACL: | Tài nguyên | Ghi chú | |---|---| | CloudFront | Web ACL phải ở us-east-1 | | Application Load Balancer | cùng Region | | API Gateway | REST API | | AppSync, Cognito User Pool, App Runner | |

Và ba lớp bảo vệ nên có cùng nhau:

Shield Standard   → chống DDoS tầng 3/4, MIỄN PHÍ, tự động
WAF               → lọc tầng 7 theo quy tắc  ← câu này
Shield Advanced   → chống DDoS nâng cao, đội SRT, bảo vệ chi phí

Shield Standard đã bật sẵn cho mọi khách hàng — nên câu hỏi thực tế chỉ là có cần WAF và Shield Advanced hay không.

Đáp án

B — Dùng AWS CloudFormation Guard để định nghĩa và kiểm tra các quy tắc tuân thủ đối với template CloudFormation.

Vì sao đúng

Đề yêu cầu: đảm bảo template CloudFormation tuân thủ chính sách bảo mật của công ty TRƯỚC KHI triển khai.

CloudFormation Guard (cfn-guard) được thiết kế đúng cho việc này:

Lập trình viên viết template
    ↓ commit vào Git
CI/CD pipeline chạy cfn-guard
    ├─ VI PHẠM → build THẤT BẠI, không triển khai
    └─ ĐẠT     → tiếp tục triển khai

Guard dùng một ngôn ngữ khai báo riêng, đọc được như tiếng Anh:

# Mọi S3 bucket phải bật mã hoá
let s3_buckets = Resources.*[ Type == 'AWS::S3::Bucket' ]
rule s3_phai_ma_hoa when %s3_buckets !empty {
  %s3_buckets.Properties.BucketEncryption exists
  << Vi phạm: S3 bucket phải bật mã hoá phía máy chủ >>
}

# Security group không được mở SSH ra Internet
let sgs = Resources.*[ Type == 'AWS::EC2::SecurityGroup' ]
rule khong_mo_ssh when %sgs !empty {
  %sgs.Properties.SecurityGroupIngress[*] {
    when FromPort == 22 { CidrIp != "0.0.0.0/0" }
  }
}

cfn-guard validate --data template.yaml --rules quy-tac-bao-mat.guard

Vì sao "trước khi triển khai" là điểm mấu chốt — đây là shift-left security: | Thời điểm phát hiện | Chi phí sửa | Rủi ro | |---|---|---| | Lúc viết mã / CI | thấp nhất | không có | | Lúc triển khai | trung bình | có thể đã tạo tài nguyên | | Sau khi chạy production | cao | tài nguyên không tuân thủ đã tồn tại và bị phơi |

Vì sao các phương án khác sai

• A. Dùng AWS Config đánh giá và kiểm toán cấu hình tài nguyên AWS — đây là phương án gần nhất và là công cụ tuân thủ đúng, nhưng nó hoạt động SAU KHI tài nguyên đã được tạo. Đề yêu cầu kiểm tra template trước khi triển khai. (Hai công cụ bổ sung nhau: Guard chặn ở cổng vào, Config canh chừng những gì đã chạy.)
• C. Dùng AWS Trusted Advisor kiểm tra template CloudFormation — Trusted Advisor không đọc template: nó phân tích tài nguyên đang chạy và đưa ra khuyến nghị về chi phí, hiệu năng, bảo mật, giới hạn dịch vụ.
• D. Dùng AWS Systems Manager quản lý và tuân thủ cho tài nguyên AWS — sai phạm vi: Systems Manager quản lý instance đang chạy (vá lỗi, kiểm kê, cấu hình). Nó không kiểm tra template hạ tầng.

Ghi nhớ

Ba tầng kiểm soát tuân thủ cho hạ tầng dạng mã — nên có cả ba: | Tầng | Công cụ | Thời điểm | |---|---|---| | Trước khi triển khai | cfn-guard, cfn_nag, Checkov, tfsec | CI/CD | | Lúc triển khai | CloudFormation Hooks, Service Control Policy | runtime của deployment | | Sau khi triển khai | AWS Config, Security Hub | liên tục |

Tầng giữa đáng biết: CloudFormation Hooks chạy cfn-guard rule ngay trong quá trình tạo stack — nên nó chặn cả việc triển khai thủ công qua Console, thứ mà kiểm tra ở CI/CD không bắt được.

Ba đặc điểm của CloudFormation Guard: | Đặc điểm | Chi tiết | |---|---| | Ngôn ngữ khai báo riêng | dễ đọc, không cần viết mã | | Áp dụng cho nhiều loại tệp JSON/YAML | không chỉ CloudFormation — cả Kubernetes manifest, Terraform plan | | Chạy được ở nhiều nơi | CLI, Docker, GitHub Action, Lambda, CloudFormation Hooks | | Mã nguồn mở | miễn phí |

Dòng thứ hai là điều bất ngờ với nhiều người: Guard là bộ đánh giá quy tắc trên cấu trúc dữ liệu JSON/YAML bất kỳ, nên nó dùng được cho cả Terraform (qua terraform show -json) và Kubernetes.

Ba loại quy tắc thường viết: | Loại | Ví dụ | |---|---| | Bắt buộc mã hoá | S3, EBS, RDS phải bật mã hoá | | Cấm cấu hình mạng nguy hiểm | không mở 22/3389 cho 0.0.0.0/0 | | Bắt buộc gắn tag | mọi tài nguyên phải có tag PhongBan, MoiTruong | | Giới hạn loại tài nguyên | chỉ dùng instance type được duyệt |

Dòng cuối liên quan tới ABAC (câu #7706): nếu quyền dựa trên tag, thì bắt buộc gắn tag ngay từ template là điều kiện để hệ thống phân quyền hoạt động.

Ba công cụ tương đương đáng biết: | Công cụ | Phạm vi | |---|---| | cfn-guard | AWS, ngôn ngữ khai báo riêng | | cfn_nag | CloudFormation, quy tắc dựng sẵn | | Checkov | đa nền tảng: CloudFormation, Terraform, Kubernetes, Helm | | tfsec, Terrascan | Terraform |

Và một lưu ý về cách triển khai hiệu quả: bắt đầu ở chế độ cảnh báo, không chặn. Áp bộ quy tắc lên toàn bộ template hiện có trước, xem có bao nhiêu vi phạm, sửa dần, rồi mới bật chế độ chặn build — bật chặn ngay từ đầu trên codebase có sẵn thường làm cả đội dừng việc.

Đáp án

A, D và E:

• A — Security group của EC2 instance không cho phép lưu lượng từ dải IP của subnet chứa NLB
• D — Network ACL của subnet chứa instance không cho phép lưu lượng từ dải IP của subnet chứa NLB
• E — Ứng dụng trên instance không lắng nghe trên cổng health check

Vì sao đúng

Đề mô tả: NLB báo instance không lành mạnh (unhealthy) dù ứng dụng chạy bình thường — và ba nguyên nhân này là ba chỗ hay hỏng nhất.

Điểm kỹ thuật mấu chốt: NLB gửi health check từ IP RIÊNG của subnet nó nằm trong.

NLB health check:
  Nguồn = địa chỉ IP riêng của node NLB trong subnet của nó
  → security group của instance phải cho phép CIDR đó
  → NACL của subnet instance phải cho phép CIDR đó

Và đây là khác biệt quan trọng so với ALB: | | ALB | NLB | |---|---|---| | Có security group riêng? | ✅ có từ đầu | thêm sau (2023), nhiều NLB cũ KHÔNG có | | Cách cho phép health check | tham chiếu SG của ALB | cho phép CIDR SUBNET của NLB |

Ba nguyên nhân theo thứ tự nên kiểm tra:

E → Ứng dụng có lắng nghe trên cổng health check không?
     (đơn giản nhất — kiểm bằng curl localhost trên chính instance)
A → Security group của instance cho phép CIDR subnet NLB chưa?
     (nguyên nhân phổ biến NHẤT)
D → NACL của subnet instance cho phép chưa?
     (ít gặp hơn vì NACL mặc định thông, nhưng nếu đã siết thì đây là chỗ hỏng)

Về E — chi tiết dễ bỏ sót: health check port có thể khác cổng ứng dụng. Cấu hình HealthCheckPort mặc định là traffic-port, nhưng nếu đặt riêng (ví dụ 8080 cho endpoint /health) thì ứng dụng phải thực sự lắng nghe ở đó.

Về D — NACL không có trạng thái, nên phải mở cả hai chiều:

Inbound:  cho phép CIDR subnet NLB → cổng health check
Outbound: cho phép ra dải cổng tạm (1024–65535) về phía NLB

Quên chiều outbound là lỗi rất hay gặp khi siết NACL.

Vì sao các phương án khác sai

• B. Security group của NLB không cho phép lưu lượng ra tới instance — đây là phương án gần nhất và sai với đa số NLB: NLB theo truyền thống KHÔNG có security group. AWS bổ sung tính năng này năm 2023 nhưng chỉ gán được lúc TẠO — NLB đã tồn tại thì không thêm được. Với NLB không có SG, phát biểu này vô nghĩa.
• C. Network ACL của subnet chứa NLB không cho phép lưu lượng ra tới instance — về lý thuyết NACL của subnet NLB có ảnh hưởng, nhưng đây không phải nguyên nhân điển hình và không nằm trong ba chỗ hỏng thường gặp. Phương án D (NACL phía instance) mới là chỗ thực sự hay gây vấn đề.
• F. Tên DNS của NLB không phân giải đúng địa chỉ IP — không liên quan tới health check: DNS ảnh hưởng tới việc client tìm thấy NLB, không ảnh hưởng tới việc NLB kiểm tra target. Nếu DNS hỏng thì triệu chứng là client không kết nối được, không phải target unhealthy.

Ghi nhớ

Danh sách kiểm tra khi target unhealthy — theo thứ tự:

① Ứng dụng có chạy và lắng nghe đúng cổng không?  → curl localhost trên instance
② Endpoint health check trả về mã gì?              → phải khớp Matcher (mặc định 200)
③ Security group của instance cho phép nguồn chưa?
④ NACL của subnet instance thông cả hai chiều chưa?
⑤ Timeout và ngưỡng có quá chặt không?             → ứng dụng khởi động chậm
⑥ Route table có đường về không?

Nguồn health check — bảng phân biệt cần thuộc: | Load balancer | Nguồn health check | Cách cho phép | |---|---|---| | ALB | ENI của ALB | tham chiếu security group của ALB | | NLB | IP riêng của node NLB | cho phép CIDR SUBNET của NLB |

Đây là lỗi cấu hình phổ biến nhất khi chuyển từ ALB sang NLB: quy tắc "tham chiếu SG của load balancer" không áp dụng được.

Bốn tham số health check ảnh hưởng tới kết quả: | Tham số | Mặc định (NLB) | |---|---| | HealthCheckIntervalSeconds | 30 giây | | HealthCheckTimeoutSeconds | 10 giây (HTTP) / 6 (TCP) | | HealthyThresholdCount | 5 lần liên tiếp | | UnhealthyThresholdCount | 2 lần liên tiếp | | Matcher | 200–399 (HTTP) |

Với ứng dụng khởi động chậm, tăng HealthCheckIntervalSeconds hoặc dùng deregistration delay và Auto Scaling health check grace period — nếu không, instance bị đánh dấu unhealthy và thay thế trước khi kịp khởi động xong, tạo vòng lặp thay thế liên tục.

Đặc điểm riêng của NLB cần nhớ: | Đặc điểm | Chi tiết | |---|---| | Tầng 4 (TCP/UDP/TLS) | không hiểu HTTP header | | Giữ IP nguồn của client | target thấy IP thật của client, không phải IP của NLB | | Địa chỉ IP tĩnh cho mỗi AZ | có thể gán Elastic IP | | Độ trễ cực thấp | phù hợp workload hiệu năng cao |

Dòng thứ hai có hệ quả về security group: với lưu lượng thật (khác health check), security group của instance thấy IP của client, nên rule phải cho phép nguồn đó — không phải CIDR của NLB. Health check và lưu lượng thật đến từ nguồn khác nhau — một chi tiết thường gây bối rối khi gỡ lỗi.

(Với NLB có bật PreserveClientIP=false hoặc target type là alb/ip ở chế độ nhất định, hành vi này khác đi — nên kiểm tra cấu hình cụ thể khi chẩn đoán.)

Đáp án

C — Dùng điều kiện aws:CurrentTime trong IAM policy để hạn chế truy cập theo khoảng ngày.

Vì sao đúng

Đề yêu cầu: cấp quyền truy cập tạm thời chỉ trong một khoảng ngày nhất định, và aws:CurrentTime là condition key đúng:

{
  "Effect": "Allow",
  "Action": ["s3:GetObject", "s3:ListBucket"],
  "Resource": ["arn:aws:s3:::du-lieu-du-an",
               "arn:aws:s3:::du-lieu-du-an/*"],
  "Condition": {
    "DateGreaterThan": {"aws:CurrentTime": "2026-09-01T00:00:00Z"},
    "DateLessThan":    {"aws:CurrentTime": "2026-12-31T23:59:59Z"}
  }
}

Cách hoạt động: | Đặc điểm | Chi tiết | |---|---| | aws:CurrentTime | thời điểm AWS đánh giá request | | Định dạng | ISO 8601 (YYYY-MM-DDThh:mm:ssZ) | | Toán tử | DateGreaterThan, DateLessThan, và biến thể Equals | | Hết hạn | quyền TỰ động ngừng — không cần ai nhớ gỡ |

Vế "tự động hết hạn" là giá trị lớn nhất: đây là cách chống lại vấn đề quyền tích tụ — quyền tạm thời được cấp rồi không ai nhớ thu hồi, và sau vài năm tài khoản đầy những quyền không còn cần thiết.

Áp dụng thực tế: | Tình huống | Cách dùng | |---|---| | Nhà thầu làm việc theo hợp đồng có thời hạn | ← đúng câu này | | Quyền nâng cao cho một đợt bảo trì | giới hạn đúng cửa sổ bảo trì | | Truy cập dữ liệu cho một dự án kiểm toán | hết dự án là hết quyền |

Vì sao các phương án khác sai

• B. Dùng điều kiện aws:RequestedRegion trong IAM policy để hạn chế truy cập theo khoảng ngày — đây là phương án gần nhất và sai condition key: aws:RequestedRegion là Region mà request nhắm tới, không liên quan gì tới thời gian.
• A. Dùng điều kiện aws:SourceIp để hạn chế truy cập theo khoảng ngày — cùng lỗi: aws:SourceIp là địa chỉ IP nguồn.
• D. Dùng điều kiện aws:PrincipalArn để hạn chế truy cập theo khoảng ngày — cùng lỗi: aws:PrincipalArn là ARN của người gọi.

Ghi nhớ

Condition key toàn cục hay dùng — bảng cần thuộc: | Key | Chứa gì | |---|---| | aws:CurrentTime | thời điểm đánh giá request ← câu này | | aws:SourceIp | IP nguồn | | aws:RequestedRegion | Region đích của request | | aws:PrincipalArn | ARN của principal | | aws:MultiFactorAuthPresent | có dùng MFA không | | aws:MultiFactorAuthAge | MFA được xác thực cách đây bao lâu (giây) | | aws:SecureTransport | có dùng HTTPS không | | aws:PrincipalOrgID | ID tổ chức | | aws:TokenIssueTime | thời điểm token STS được cấp | | aws:userid, aws:username | định danh người gọi |

Bốn toán tử ngày tháng: | Toán tử | Nghĩa | |---|---| | DateGreaterThan | sau thời điểm này | | DateLessThan | trước thời điểm này | | DateGreaterThanEquals, DateLessThanEquals | bao gồm mốc | | DateEquals, DateNotEquals | bằng / khác |

Kết hợp hai toán tử đầu tạo thành một khoảng — đúng như đáp án làm.

Ba cách cấp quyền tạm thời trên AWS — chọn theo tình huống: | Cách | Thời hạn | Phù hợp | |---|---|---| | aws:CurrentTime trong policy | khoảng ngày cố định | hợp đồng, dự án có ngày kết thúc ← câu này | | STS AssumeRole với DurationSeconds | 15 phút – 12 giờ | phiên làm việc | | IAM Identity Center + permission set | quản lý tập trung | tổ chức lớn | | aws:TokenIssueTime | thu hồi phiên cũ | ứng phó sự cố |

Dòng thứ hai đáng nói: với nhu cầu ngắn hạn (một phiên làm việc), assume role với thời hạn ngắn là cơ chế đúng — nó tự hết hạn mà không cần policy nào. aws:CurrentTime phù hợp cho khoảng dài hơn và cố định theo lịch.

Hai điều kiện MFA đáng biết — chúng hay đi cùng quyền nhạy cảm:

// Bắt buộc có MFA
{"Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}}}

// MFA phải được xác thực trong vòng 1 giờ
{"Condition": {"NumericLessThan": {"aws:MultiFactorAuthAge": "3600"}}}

Dòng thứ hai chặt hơn dòng đầu: nó ngăn việc dùng một phiên đã xác thực MFA từ nhiều giờ trước cho một thao tác nhạy cảm.

Và một lưu ý về múi giờ: aws:CurrentTime luôn theo UTC. Đặt 2026-12-31T23:59:59Z cho một hợp đồng kết thúc cuối ngày ở Việt Nam (UTC+7) sẽ cắt quyền sớm 7 giờ — với hợp đồng thì thường không sao, nhưng với cửa sổ bảo trì hẹp thì đó là sai lệch đủ để gây sự cố. Luôn tính đổi sang UTC khi đặt mốc.