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

Đáp án

B — Cấu hình S3 VPC endpoint và tạo bucket policy chỉ cho phép truy cập từ VPC endpoint đó.

Vì sao đúng

Đề mô tả một vector tấn công rất cụ thể: thành viên trong đội có quyền trên instance có thể dựng một EC2 khác ở VPC khác rồi dùng cùng thông tin đăng nhập để lấy dữ liệu.

Vì sao ràng buộc theo VPC endpoint chặn được điều đó:

{
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:*",
  "Resource": ["arn:aws:s3:::kho-tai-lieu",
               "arn:aws:s3:::kho-tai-lieu/*"],
  "Condition": {
    "StringNotEquals": {"aws:SourceVpce": "vpce-0abc123"}
  }
}

Điều kiện này gắn quyền truy cập vào một thực thể MẠNG cụ thể, không phải vào danh tính:

Kẻ tấn công có: thông tin đăng nhập (IAM role) ✓
Kẻ tấn công thiếu: đường đi qua VPC endpoint vpce-0abc123 ✗
    → dù có role đúng, request từ VPC khác vẫn bị từ chối

Đây là điểm mấu chốt phân biệt với phương án A: IAM role đi theo được. Ai dựng được EC2 ở VPC khác và gắn cùng instance profile (hoặc assume được role đó) thì có đủ quyền. Ràng buộc mạng thì không đi theo được.

Và VPC endpoint còn có lợi ích phụ: lưu lượng tới S3 không rời khỏi mạng AWS, không cần NAT Gateway, không đi qua Internet.

(S3 dùng Gateway endpoint — miễn phí, hoạt động qua route table. Điều kiện tương đương cho Gateway endpoint là aws:SourceVpce, hoặc aws:SourceVpc nếu muốn ràng buộc theo cả VPC.)

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

• A. Thiết lập IAM role cho phép truy cập, rồi tạo bucket policy chỉ cho phép truy cập từ role gắn vào instance profile — đây là phương án gần nhất và là lớp kiểm soát cần thiết, nhưng nó không chặn được vector tấn công mà đề mô tả: thành viên đội có thể gắn chính role đó vào một EC2 ở VPC khác — bucket policy vẫn thấy đúng principal và cho qua.
• C. Gắn Elastic IP cho instance và tạo bucket policy chỉ cho phép từ Elastic IP đó — sai kiến trúc và sai bảo mật: instance nằm trong private VPC, gắn Elastic IP là phơi nó ra Internet — trái mục đích. Và IP có thể bị gán lại cho tài nguyên khác.
• D. Thiết lập security group hạn chế cho instance và tạo bucket policy chỉ cho phép từ security group đó — bucket policy không nhận security group làm điều kiện: nó chỉ làm việc với IAM principal và các condition key như aws:SourceVpce, aws:SourceIp, aws:SourceVpc. Không có aws:SourceSecurityGroup.

Ghi nhớ

Ba condition key ràng buộc nguồn mạng cho S3 — bảng cần thuộc: | Condition key | Ràng buộc theo | Độ chặt | |---|---|---| | aws:SourceVpce | một VPC endpoint cụ thể | chặt nhất ← câu này | | aws:SourceVpc | một VPC | vừa | | aws:SourceIp | dải IP công khai | KHÔNG dùng được cho lưu lượng qua VPC endpoint |

Dòng cuối là bẫy hay gặp: đặt aws:SourceIp cho lưu lượng đi qua VPC endpoint sẽ chặn hết — vì request không mang IP công khai nào.

Hai loại VPC endpoint: | Loại | Dịch vụ | Chi phí | Cơ chế | |---|---|---|---| | Gateway | CHỈ S3 và DynamoDB | miễn phí | route table entry | | Interface | hầu hết dịch vụ khác | theo giờ + GB | ENI trong subnet (PrivateLink) |

S3 hỗ trợ cả hai — Gateway endpoint là lựa chọn mặc định vì miễn phí; Interface endpoint cần thiết khi truy cập S3 từ tại chỗ qua Direct Connect/VPN, vì Gateway endpoint không dùng được từ ngoài VPC.

Ba lớp kiểm soát nên dùng cùng nhau cho bucket nhạy cảm: | Lớp | Chặn gì | |---|---| | IAM policy / bucket policy theo principal | ai được phép | | aws:SourceVpce | từ đâu được phép ← câu này | | Block Public Access | không bao giờ công khai | | SSE-KMS với key policy chặt | thêm một lớp quyền độc lập |

Mô hình đúng là kết hợp lớp 1 và lớp 2, không phải chọn một: principal đúng và đường đi đúng thì mới cho qua.

Và một cấu hình bổ sung đáng làm cho VPC endpoint: endpoint policy. Nó giới hạn những gì đi qua endpoint đó được:

{"Effect": "Allow", "Principal": "*",
 "Action": ["s3:GetObject"],
 "Resource": "arn:aws:s3:::kho-tai-lieu/*"}

Kết quả là hai chiều khoá vào nhau: bucket chỉ nhận request qua endpoint này, và endpoint này chỉ cho phép đọc đúng bucket đó. Một instance bị xâm nhập trong VPC cũng không dùng endpoint để chạm tới bucket khác được.

Đáp án

D — Đảm bảo security group và network ACL ở CẢ HAI VPC đều cho phép lưu lượng.

Vì sao đúng

Đề mô tả triệu chứng rất đặc trưng:

NLB ở Account 1: kết nối đã được CHẤP NHẬN ✓
                 dữ liệu ĐANG RỜI KHỎI NLB   ✓
Phía client ở Account 2: KHÔNG nhận được dữ liệu ✗

Dữ liệu đi ra được nhưng không tới nơi — đó là dấu hiệu kinh điển của lưu lượng bị chặn ở tầng mạng, không phải lỗi cấu hình PrivateLink.

Vì sao phải kiểm cả HAI phía:

Account 2 (consumer)                    Account 1 (provider)
  Client
    ↓ ① SG của client cho phép ra 443?
  VPC endpoint (ENI)
    ↓ ② SG CỦA ENDPOINT cho phép vào từ client?
    ↓ ③ NACL của subnet chứa endpoint thông cả hai chiều?
  ─────── PrivateLink ───────
  NLB
    ↓ ④ SG của target cho phép vào từ NLB?
    ↓ ⑤ NACL của subnet chứa target?
  Target (EC2/service)

Hai chỗ hay hỏng nhất: | Chỗ | Triệu chứng | |---|---| | Security group của VPC endpoint chặn 443 | kết nối timeout — đây là lỗi phổ biến nhất | | NACL không cho phép dải cổng tạm ở chiều về | request đi được, phản hồi bị chặn |

Dòng thứ hai giải thích chính xác triệu chứng trong đề: NACL không có trạng thái, nên phải mở tường minh cả chiều đi lẫn chiều về:

Inbound:  cho phép 443 từ nguồn
Outbound: cho phép 1024–65535 về phía nguồn   ← hay bị quên

Quên chiều outbound thì dữ liệu rời NLB được nhưng phản hồi bị NACL của phía kia chặn — đúng như mô tả.

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

• C. Bật VPC Flow Logs để thu thập thông tin chi tiết về lưu lượng đi và đến ENI của NLB — đây là phương án gần nhất và là công cụ chẩn đoán tốt (nó cho thấy gói bị REJECT ở đâu), nhưng nó chỉ chẩn đoán, không sửa gì. Đề hỏi "steps should be undertaken to troubleshoot", và bước cần làm là kiểm tra và sửa cấu hình mạng — Flow Logs giúp xác nhận chứ không phải là giải pháp.
• A. Dùng CloudTrail để ghi lại thông tin chi tiết về các lời gọi tới Amazon VPC API và xác định IP nguồn — sai loại dữ liệu: CloudTrail ghi lời gọi API quản lý (tạo endpoint, sửa NLB), không ghi lưu lượng dữ liệu. Nó không cho biết vì sao gói tin không tới nơi.
• B. Cấu hình Gateway VPC Endpoint thay vì PrivateLink để truy cập dịch vụ giữa các tài khoản — không thực hiện được: Gateway endpoint chỉ hỗ trợ S3 và DynamoDB. Nó không dùng cho dịch vụ tự vận hành sau NLB.

Ghi nhớ

Kiến trúc PrivateLink — ba thành phần:

Provider (Account 1)          Consumer (Account 2)
  Network Load Balancer
      ↓
  VPC Endpoint Service   ←──  Interface VPC Endpoint
  (com.amazonaws.vpce...)      (ENI trong subnet của consumer)

Danh sách kiểm tra khi PrivateLink không thông:

① Endpoint service đã CHẤP NHẬN kết nối chưa?      (đề nói rồi: có)
② SG của VPC endpoint cho phép inbound 443?         ← hay hỏng nhất
③ SG của client cho phép outbound tới endpoint?
④ NACL hai đầu thông CẢ HAI CHIỀU?                  ← hay hỏng nhì
⑤ SG của target cho phép inbound TỪ DẢI SUBNET NLB?
⑥ Health check của NLB có PASS không?
⑦ Endpoint service có bật đúng AZ mà consumer dùng?

Bước ⑦ là chi tiết ít người biết: endpoint service chỉ khả dụng ở các AZ mà NLB có subnet. Consumer tạo endpoint ở AZ không được hỗ trợ sẽ không kết nối được — và AWS ánh xạ AZ theo AZ ID chứ không theo tên, nên ap-northeast-1a của hai tài khoản có thể là hai AZ vật lý khác nhau.

Security group và NACL — bảng phân biệt luôn cần khi gỡ lỗi mạng: | | Security group | Network ACL | |---|---|---| | Mức | ENI | subnet | | Trạng thái | stateful — phản hồi tự động qua | stateless — phải mở CẢ HAI chiều | | Rule | chỉ Allow | Allow và Deny | | Mặc định (VPC mặc định) | chặn inbound | cho phép hết | | Mặc định (NACL tuỳ chỉnh) | — | CHẶN hết |

Dòng cuối là bẫy hay gặp: NACL do bạn tạo mới mặc định chặn mọi thứ, khác hẳn NACL mặc định của VPC.

Ba đặc điểm của NLB liên quan tới chẩn đoán: | Đặc điểm | Hệ quả | |---|---| | Health check đến từ IP RIÊNG của subnet NLB | SG của target phải cho phép CIDR đó | | Giữ IP nguồn của client | lưu lượng thật đến từ IP client, không phải IP NLB | | NLB truyền thống không có security group | không kiểm soát được ở tầng NLB |

Hai dòng đầu nghĩa là target cần cho phép HAI nguồn khác nhau: CIDR subnet NLB (cho health check) và IP client (cho lưu lượng thật) — một chỗ gây bối rối thường xuyên.

Và với PrivateLink cụ thể, có một ngoại lệ đáng nhớ: khi lưu lượng đi qua VPC endpoint tới NLB, NLB nhìn thấy IP của endpoint ENI, không phải IP của client gốc — nên security group của target chỉ cần cho phép dải subnet của NLB.

Đáp án

C — Thiết lập một Lambda execution role cấp quyền dùng KMS key cho từng Lambda function.

Vì sao đúng

Đề nêu yêu cầu cụ thể: mỗi Lambda function phải có quyền truy cập lập trình RIÊNG để dùng KMS key.

Execution role là cơ chế duy nhất đúng để cấp quyền cho Lambda:

Lambda function chạy
    ↓ tự động assume EXECUTION ROLE của nó
    ↓ mọi lời gọi AWS API dùng quyền của role đó
KMS, S3, và các dịch vụ khác

Và vì mỗi function có execution role riêng, mỗi function có quyền riêng — đúng yêu cầu "each Lambda function has its own programmatic access control permissions":

lambda-xu-ly-anh    → role-xu-ly-anh    → chỉ Decrypt
lambda-bao-cao      → role-bao-cao      → Decrypt + GenerateDataKey
lambda-luu-tru      → role-luu-tru      → chỉ GenerateDataKey

Quyền cần thiết cho từng role:

{
  "Effect": "Allow",
  "Action": ["kms:Decrypt", "kms:GenerateDataKey"],
  "Resource": "arn:aws:kms:ap-northeast-1:123456789012:key/1234abcd-..."
}

Và đừng quên lớp thứ hai — key policy (không nằm trong các phương án nhưng bắt buộc trong thực tế):

{
  "Effect": "Allow",
  "Principal": {"AWS": "arn:aws:iam::123456789012:role/role-xu-ly-anh"},
  "Action": ["kms:Decrypt", "kms:GenerateDataKey"],
  "Resource": "*"
}

KMS đòi cả IAM policy lẫn key policy cùng cho phép — trừ khi key policy đã uỷ quyền cho tài khoản qua statement Principal: root.

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

• B. Gắn một IAM policy trực tiếp cho từng Lambda function cấp quyền dùng KMS key — đây là phương án gần nhất và sai về mặt kỹ thuật: không gắn IAM policy trực tiếp vào Lambda function được. Policy gắn vào user, group hoặc role; Lambda nhận quyền qua execution role. Ý định của phương án đúng nhưng cơ chế không tồn tại.
• A. Cho mỗi Lambda assume một IAM role cấp quyền dùng AWS-managed KMS key cho Amazon S3 — sai loại khoá: đề nói rõ dữ liệu mã hoá bằng customer managed key. Và AWS managed key (aws/s3) không cho phép sửa key policy, nên không kiểm soát được quyền theo từng function.
• D. Tạo key grant cho service principal của Lambda và điều chỉnh quyền khi cần — sai mức phân giải: grant cho lambda.amazonaws.com áp cho toàn bộ dịch vụ Lambda, không phân biệt được từng function. Trái yêu cầu "each Lambda function has its own permissions". (Grant hữu ích khi cấp quyền tạm thời cho một principal cụ thể, không phải cho service principal chung.)

Ghi nhớ

Ba loại role liên quan tới Lambda — hay bị lẫn: | Loại | Chiều | Việc | |---|---|---| | Execution role | Lambda → dịch vụ khác | quyền Lambda dùng để gọi API ← câu này | | Resource-based policy | dịch vụ khác → Lambda | cho phép ai được GỌI function | | Trust policy của execution role | — | cho phép lambda.amazonaws.com assume role |

Hai dòng đầu ngược chiều nhau và là nguồn nhầm lẫn thường xuyên:

Lambda đọc S3        → EXECUTION ROLE có quyền s3:GetObject
S3 event gọi Lambda  → RESOURCE-BASED POLICY cho phép s3.amazonaws.com

Ba loại KMS key — bảng phân biệt: | Loại | Sửa key policy? | Xoay vòng | Chi phí | |---|---|---|---| | AWS managed (aws/s3) | ❌ KHÔNG | tự động hằng năm | miễn phí | | Customer managed | ✅ CÓ | tuỳ chọn, cấu hình được | 1 USD/tháng + lời gọi | | AWS owned | không thấy được | AWS quản lý | miễn phí |

Cột "sửa key policy" là lý do đề chọn customer managed key: chỉ với nó bạn mới kiểm soát được chính xác role nào dùng được khoá.

Quyền KMS theo thao tác — bảng cần thuộc: | Thao tác | Quyền | |---|---| | Đọc object SSE-KMS | kms:Decrypt | | Ghi object SSE-KMS | kms:GenerateDataKey | | Multipart upload | cả hai |

Ba cách siết chặt quyền KMS cho Lambda:

// Chỉ dùng được khoá THÔNG QUA S3, không gọi trực tiếp KMS
{"Condition": {"StringEquals": {
   "kms:ViaService": "s3.ap-northeast-1.amazonaws.com"}}}

// Ràng buộc theo encryption context
{"Condition": {"StringEquals": {
   "kms:EncryptionContext:ung-dung": "xu-ly-anh"}}}

Và một thực hành nên theo cho môi trường nhiều function: một execution role cho một function, không dùng chung. Dùng chung một role cho mười function nghĩa là quyền của role đó phải là hợp của mọi nhu cầu — và mỗi function đều có nhiều quyền hơn nó cần.

Đáp án

C — Sao chép dữ liệu trực tiếp từ volume EBS đã mã hoá TRƯỚC KHI volume bị tháo khỏi EC2 instance.

Vì sao đúng

Đề mô tả một tình huống không thể cứu vãn theo cách thông thường: CMK đã bị xoá, và cả EBS volume lẫn S3 bucket đều mã hoá bằng khoá đó.

Sự thật quan trọng nhất: KMS key đã xoá là KHÔNG THỂ khôi phục.

Không root user khôi phục được
Không AWS Support khôi phục được
→ AWS không giữ bản sao nào của key material đã xoá

Nhưng có một khe cửa hẹp, và đó chính là đáp án:

Volume EBS đang GẮN vào instance đang CHẠY:
    → data key ở dạng RÕ đã được nạp vào bộ nhớ của hypervisor
    → việc đọc/ghi vẫn hoạt động BÌNH THƯỜNG
    → dù CMK đã bị xoá

Ngay khi volume bị THÁO RA hoặc instance DỪNG/KHỞI ĐỘNG LẠI:
    → hypervisor cần data key mới
    → phải gọi KMS để giải mã data key đã lưu
    → CMK không còn → THẤT BẠI VĨNH VIỄN

Nên hành động duy nhất còn cứu được dữ liệu là: sao chép nó ra ngay, khi máy vẫn đang chạy.

Các bước thực tế:

# Trên chính instance, sao chép sang một volume KHÔNG mã hoá bằng khoá đã mất
rsync -av /du-lieu-quan-trong/ /mnt/volume-moi/
# hoặc đẩy thẳng lên S3 (bucket khác, khoá khác)
aws s3 sync /du-lieu-quan-trong/ s3://bucket-cuu-ho/

Tuyệt đối KHÔNG được làm: dừng instance, khởi động lại, hay tháo volume — mỗi thao tác đó đều xoá sạch cơ hội cuối cùng.

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

• B. Chụp snapshot của volume EBS đã mã hoá trước khi tháo volume — đây là phương án gần nhất và thoạt nhìn rất hợp lý, nhưng nó không hoạt động: tạo snapshot của volume mã hoá đòi gọi KMS để xử lý data key. CMK đã xoá nên lệnh CreateSnapshot thất bại. (Và ngay cả khi tạo được, snapshot đó cũng mã hoá bằng chính CMK đã mất — vô dụng.)
• A. Đăng nhập bằng root user để khôi phục khoá đã xoá rồi dùng nó phục hồi dữ liệu — root user không có đặc quyền này: không ai khôi phục được KMS key đã xoá. (Nếu khoá mới ở trạng thái chờ xoá (pending deletion) thì CancelKeyDeletion cứu được — nhưng đề nói khoá đã bị xoá.)
• D. Mở ticket với AWS Support để khôi phục khoá đã xoá — AWS Support cũng không khôi phục được. Đây là thiết kế có chủ đích: nếu AWS khôi phục được khoá đã xoá thì việc xoá khoá không còn ý nghĩa bảo mật nào.

Ghi nhớ

Vòng đời xoá KMS key — và khe cửa cuối cùng:

① ScheduleKeyDeletion       → trạng thái PendingDeletion (7–30 ngày)
   ↑ CancelKeyDeletion       → CÒN CỨU ĐƯỢC ở bước này
② Hết thời gian chờ         → khoá bị XOÁ VĨNH VIỄN
   → mọi dữ liệu mã hoá bằng nó KHÔNG BAO GIỜ giải mã được

Thời gian chờ 7–30 ngày tồn tại chính vì lý do này — nó là cơ hội để phát hiện và huỷ thao tác nhầm. Nên giám sát ScheduleKeyDeletion là cảnh báo quan trọng nhất trong nhóm KMS:

{"source": ["aws.kms"],
 "detail": {"eventName": ["ScheduleKeyDeletion", "DisableKey"]}}

Hành vi của tài nguyên khi CMK bị xoá: | Tài nguyên | Trước khi tháo/dừng | Sau khi tháo/dừng | |---|---|---| | EBS volume đang gắn | ✅ vẫn đọc ghi được | ❌ mất vĩnh viễn | | S3 object | ❌ mất ngay — mỗi lần đọc đều gọi KMS | ❌ | | RDS instance đang chạy | ✅ tạm thời | ❌ | | Snapshot EBS | ❌ không khôi phục được | ❌ |

Dòng thứ hai đáng chú ý: dữ liệu trên S3 mất ngay lập tức — không có khe cửa nào như EBS, vì S3 gọi KMS ở mỗi lần đọc object. Nên trong tình huống của đề, chỉ dữ liệu trên EBS còn cứu được.

Bốn biện pháp ngăn tình huống này tái diễn: | Biện pháp | Chi tiết | |---|---| | SCP chặn kms:ScheduleKeyDeletion | ← xem câu #7731 | | Cảnh báo EventBridge khi có lịch xoá khoá | có 7–30 ngày để phản ứng | | Đặt thời gian chờ TỐI ĐA 30 ngày | mặc định chỉ 7 | | Quy trình rời việc chặt chẽ | đề nói rõ đây là hành động của nhân viên đã nghỉ |

Dòng cuối là nguyên nhân gốc rễ trong câu chuyện này: một nhân viên sắp rời công ty vẫn còn quyền đặt lịch xoá khoá mã hoá dữ liệu sản xuất. Đó là vấn đề quy trình, không phải vấn đề kỹ thuật — và không có cấu hình AWS nào sửa được nó hoàn toàn.

Và một lưu ý về DisableKey — sự khác biệt cứu người: | Thao tác | Đảo ngược được? | |---|---| | DisableKey | ✅ EnableKey là xong | | ScheduleKeyDeletion | ✅ trong thời gian chờ | | Đã xoá xong | ❌ không bao giờ |

Nếu mục tiêu chỉ là ngăn truy cập tạm thời, luôn dùng DisableKey — nó cho hiệu quả tức thì mà vẫn có đường lui.

Đáp án

A và C.

• A — AWS Security Hub gửi finding của Amazon GuardDuty sang Amazon Detective để trực quan hoá và điều tra
• C — AWS Firewall Manager gửi finding sang Security Hub khi AWS Shield Advanced không đang bảo vệ các tài nguyên

Vì sao đúng

A — chiều tích hợp giữa Security Hub và Detective:

GuardDuty → finding → Security Hub (tổng hợp)
                          ↓ chuyển sang
                      Detective (điều tra sâu, đồ thị quan hệ)

Detective là điểm ĐẾN, không phải nguồn finding. Nó nhận một finding rồi dựng đồ thị hành vi từ VPC Flow Logs, CloudTrail và DNS log để trả lời câu hỏi "chuyện này bắt đầu từ đâu và lan tới đâu". Trong Console, mỗi finding của Security Hub có nút chuyển thẳng sang Detective.

C — Firewall Manager báo tài nguyên chưa được bảo vệ: | Loại finding của Firewall Manager | Ý nghĩa | |---|---| | Tài nguyên không được Shield Advanced bảo vệ | ← đúng phát biểu C | | Tài nguyên thiếu Web ACL của WAF | không tuân thủ chính sách | | Security group không tuân thủ | rule vi phạm chính sách chung |

Đây là vai trò chính của Firewall Manager: phát hiện tài nguyên nằm ngoài vùng bảo vệ trên toàn tổ chức, và báo cáo qua Security Hub.

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

• E. Amazon Detective tự động thu thập log, dùng học máy và lý thuyết đồ thị để điều tra, và gửi các cuộc điều tra sang Security Hub dưới dạng finding JSON — đây là phương án gần nhất và sai chiều tích hợp: Detective NHẬN finding từ Security Hub để điều tra, nó không sinh finding gửi ngược lại. Phần mô tả cơ chế của Detective thì đúng, chỉ chiều dữ liệu là ngược.
• B. AWS Trusted Advisor kiểm tra môi trường và gửi khuyến nghị dưới dạng finding sang Security Hub — Trusted Advisor KHÔNG phải nguồn finding của Security Hub. Nó là dịch vụ khuyến nghị độc lập, kết quả xem trong Console riêng hoặc qua API của chính nó.
• D. Security Hub không phát hiện hồi tố các finding sinh ra trước khi bật. Tuy nhiên, là dịch vụ TOÀN CẦU, Security Hub tổng hợp được finding từ mọi Region vào một bucket S3 — vế đầu đúng, vế sau sai: Security Hub là dịch vụ KHU VỰC, không phải toàn cầu. Tổng hợp đa Region là một tính năng phải cấu hình rõ ràng (cross-Region aggregation), không tự động.

Ghi nhớ

Luồng dữ liệu của Security Hub — nhớ đúng chiều:

NGUỒN (gửi finding VÀO)          Security Hub          ĐÍCH (nhận TỪ)
  GuardDuty                            ↓                  Detective
  Inspector                     ┌──────────────┐          EventBridge
  Macie                         │  tổng hợp    │          đối tác thứ ba
  IAM Access Analyzer     ───→  │  chuẩn hoá   │  ───→    (Splunk, Jira,
  Firewall Manager              │  chấm điểm   │           ServiceNow)
  Config                        └──────────────┘
  Systems Manager Patch Manager
  Health, Audit Manager

Detective nằm ở cột phải — đó là điểm sai của phương án E, và là chi tiết được hỏi thường xuyên.

Ba dịch vụ điều tra và phát hiện — phân biệt vai trò: | Dịch vụ | Trả lời | |---|---| | GuardDuty | "CÓ chuyện gì bất thường không?" | | Security Hub | "Tổng hợp mọi cảnh báo, tôi đang ở mức tuân thủ nào?" | | Detective | "VÌ SAO chuyện đó xảy ra, nó lan tới đâu?" |

Ba câu hỏi khác nhau, ba dịch vụ khác nhau — chúng bổ sung chứ không thay thế nhau.

Phạm vi Region của các dịch vụ bảo mật — bảng hay bị nhầm: | Dịch vụ | Phạm vi | |---|---| | Security Hub | KHU VỰC — cần cross-Region aggregation | | GuardDuty | KHU VỰC — phải bật ở từng Region | | Config | KHU VỰC — aggregator cho đa Region | | CloudTrail | có thể multi-Region trong một trail | | IAM, CloudFront, Route 53 | toàn cầu |

Ba dòng đầu cần bật ở TỪNG Region — bỏ sót một Region là một điểm mù. Đây là lý do nên có cơ chế tự động bật cho Region mới, hoặc tắt hẳn các Region không dùng (xem câu #7733).

Ba khả năng của Amazon Detective: | Khả năng | Chi tiết | |---|---| | Tự động thu thập log | VPC Flow Logs, CloudTrail, GuardDuty finding, EKS audit log | | Đồ thị hành vi | quan hệ giữa tài khoản, IP, instance, người dùng theo thời gian | | Không cần cấu hình nguồn dữ liệu | bật là chạy |

Dòng cuối là ưu điểm vận hành đáng kể: Detective không đòi bạn bật VPC Flow Logs hay cấu hình gì — nó lấy dữ liệu trực tiếp từ hạ tầng AWS.

Và một lưu ý về triển khai đa tài khoản: cả Security Hub, GuardDuty và Detective đều hỗ trợ delegated administrator trong AWS Organizations. Cấu hình mô hình này cho phép một tài khoản bảo mật chuyên trách thấy và điều tra finding của mọi tài khoản thành viên — thay vì phải đăng nhập vào từng tài khoản một.

Đáp án

A, E và F:

• F — Security group của ALB có rule vào từ mọi nơi trên cổng 443
• E — Security group của EC2 instance có rule vào từ security group của ALB trên cổng 80
• A — Security group của RDS có rule vào từ security group của EC2 trong ASG trên cổng 5432

Vì sao đúng

Đề mô tả kiến trúc ba tầng, và ba rule tạo thành một chuỗi liên tiếp:

Internet
   ↓ F: 443 từ 0.0.0.0/0
ALB (chấm dứt HTTPS ở đây)
   ↓ E: 80 từ sg-alb
EC2 trong Auto Scaling Group
   ↓ A: 5432 từ sg-ec2
RDS PostgreSQL

Ba chi tiết quyết định tính đúng của từng rule:

F — cổng 443 vì đề nói ALB "provides HTTPS termination". Người dùng kết nối bằng HTTPS, và ALB là nơi chứng chỉ TLS được cài.

E — cổng 80 vì HTTPS đã kết thúc ở ALB. Chặng từ ALB tới EC2 là HTTP thường:

Người dùng --HTTPS(443)--> ALB --HTTP(80)--> EC2

A — cổng 5432 là cổng mặc định của PostgreSQL. Đây là con số cần thuộc: | Cơ sở dữ liệu | Cổng | |---|---| | PostgreSQL | 5432 | | MySQL, MariaDB, Aurora MySQL | 3306 | | Oracle | 1521 | | SQL Server | 1433 | | Redshift | 5439 |

Và điểm thiết kế quan trọng nhất: tham chiếu SECURITY GROUP thay vì CIDR.

Nguồn = sg-alb   (KHÔNG phải dải IP của ALB)
Nguồn = sg-ec2   (KHÔNG phải dải IP của subnet)

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

• C. Security group của ALB có rule vào từ mọi nơi trên cổng 80 — đây là phương án gần nhất và chỉ cần khi bạn muốn chuyển hướng HTTP sang HTTPS. Đề nói ALB làm HTTPS termination, nên cổng bắt buộc là 443. (Trong thực tế nhiều hệ thống mở cả 80 để redirect — nhưng đó là tuỳ chọn, không phải yêu cầu của đề.)
• B. Security group của EC2 có rule vào từ security group của RDS trên cổng 5432 — ngược chiều: EC2 là bên khởi tạo kết nối tới RDS, nên rule inbound phải nằm ở RDS. Và security group có trạng thái — phản hồi từ RDS về EC2 tự động được phép, không cần rule riêng.
• D. Security group của RDS có rule vào từ security group của EC2 trên cổng 80 — sai cổng: PostgreSQL nghe ở 5432, không phải 80.

Ghi nhớ

Nguyên tắc thiết kế security group cho ứng dụng nhiều tầng:

Mỗi tầng CHỈ chấp nhận kết nối từ TẦNG NGAY TRƯỚC nó
    → không tầng nào nói chuyện vượt cấp
    → instance bị xâm nhập ở tầng web không chạm thẳng được vào CSDL

Bốn đặc điểm của security group cần nhớ: | Đặc điểm | Hệ quả | |---|---| | Có trạng thái (stateful) | chỉ cần rule một chiều — phản hồi tự động qua | | Chỉ có rule Allow | muốn chặn một IP cụ thể phải dùng NACL | | Mặc định: chặn inbound, cho phép mọi outbound | | | Tham chiếu được security group khác | trong cùng VPC, hoặc VPC peering cùng Region |

Dòng đầu giải thích vì sao phương án B thừa: không cần rule cho chiều phản hồi.

So sánh với câu #7690 — hai kiến trúc mã hoá khác nhau: | | Câu này | Câu #7690 | |---|---|---| | Chặng ngoài | HTTPS (443) | HTTPS | | Chặng ALB → EC2 | HTTP (80) | HTTPS (443) | | Gọi là | TLS termination | TLS end-to-end |

Cả hai đều hợp lệ — chọn theo yêu cầu: đề này chỉ nói "HTTPS termination", đề kia yêu cầu bảo vệ dữ liệu "in transit" cho dữ liệu cá nhân nhạy cảm nên cần mã hoá cả chặng nội bộ.

Ba điều nên làm thêm cho tầng CSDL: | Việc | Lợi ích | |---|---| | Đặt RDS trong private subnet, không có route ra Internet | | | Bật mã hoá at-rest và bắt buộc SSL cho kết nối | rds.force_ssl = 1 | | Dùng IAM database authentication | bỏ mật khẩu tĩnh, token hết hạn sau 15 phút |

Dòng cuối đáng biết: RDS hỗ trợ xác thực bằng IAM token, nên ứng dụng không cần lưu mật khẩu CSDL ở đâu cả — kết hợp với execution role thì không còn bí mật nào phải quản lý.

Và về health check: ALB gửi health check từ chính ENI của nó, nên rule E (cho phép 80 từ sg-alb) đã bao gồm cả health check. Với NLB thì khác — health check đến từ IP riêng của subnet NLB và phải cho phép theo CIDR (xem câu #7712).

Đáp án

B — Bật log đầy đủ của WAF, được chuyển tới đích bạn chọn thông qua Amazon Kinesis Data Firehose.

Vì sao đúng

Đề hỏi cách kiểm chứng WAF rule có đang hoạt động không, và log là bằng chứng trực tiếp duy nhất.

Log của WAF ghi chi tiết từng request:

{
  "timestamp": 1756512000000,
  "webaclId": "arn:aws:wafv2:...",
  "terminatingRuleId": "ChanSQLInjection",
  "action": "BLOCK",
  "httpRequest": {
    "clientIp": "203.0.113.45",
    "country": "VN",
    "uri": "/api/dang-nhap",
    "headers": [...]
  },
  "ruleGroupList": [...]
}

Ba trường quan trọng nhất khi kiểm chứng: | Trường | Cho biết | |---|---| | terminatingRuleId | RULE NÀO đã quyết định — chính là thứ cần xác minh | | action | ALLOW, BLOCK, COUNT, CAPTCHA | | httpRequest | request nào bị ảnh hưởng |

Đây là cách kiểm chứng đúng đắn vì nó dựa trên lưu lượng thật, không phải trên mô phỏng — bạn thấy chính xác rule nào khớp với request nào trong môi trường sản xuất.

Và WAF metric trên CloudWatch bổ sung cho log: | Metric | Đo | |---|---| | BlockedRequests | số request bị chặn | | AllowedRequests | số request được cho qua | | CountedRequests | số request khớp rule ở chế độ Count |

Metric cho bức tranh tổng thể, log cho chi tiết từng request — cần cả hai để kiểm chứng đầy đủ.

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

• C. Yêu cầu kiểm thử xâm nhập cho tấn công dồn dập vào trang đăng nhập hoặc API — đây là phương án gần nhất và có thể làm được trong khuôn khổ cho phép, nhưng nó phức tạp và có ràng buộc: mô phỏng tấn công quy mô lớn (DDoS) đòi phê duyệt trước từ AWS và thường phải qua đối tác được uỷ quyền. Bật log là cách kiểm chứng nhanh hơn và không có rủi ro.
• D. WAF gửi metric mỗi phút tới CloudTrail; dùng thống kê trong CloudTrail để hiểu về phản hồi của WAF — sai dịch vụ: WAF gửi metric tới CloudWatch, không phải CloudTrail. CloudTrail ghi lời gọi API quản lý (tạo rule, sửa Web ACL), không ghi kết quả lọc request.
• A. Dùng công cụ iPerf để mô phỏng tấn công DDoS và kiểm tra phản hồi của WAF qua CloudWatch Logs — sai công cụ: iPerf đo băng thông mạng giữa hai điểm, nó không sinh request HTTP và không mô phỏng được tấn công tầng 7 mà WAF xử lý.

Ghi nhớ

Ba đích nhận log của AWS WAF: | Đích | Đặc điểm | |---|---| | Kinesis Data Firehose | linh hoạt nhất — chuyển tiếp sang S3, OpenSearch, Splunk, bên thứ ba | | Amazon S3 trực tiếp | đơn giản, rẻ, truy vấn bằng Athena | | CloudWatch Logs | truy vấn bằng Logs Insights, đặt alarm được |

(Ban đầu WAF chỉ hỗ trợ Firehose; hai đích còn lại được bổ sung sau. Đáp án B nói tới Firehose là đúng, nhưng nếu bạn triển khai mới hôm nay thì S3 trực tiếp hoặc CloudWatch Logs thường gọn hơn — không cần dựng thêm một Firehose delivery stream chỉ để trung chuyển.)

Bốn hành động của WAF rule: | Hành động | Kết quả | |---|---| | Count | chỉ đếm, KHÔNG chặn — chế độ THỬ NGHIỆM | | Allow | cho qua | | Block | chặn, trả 403 | | CAPTCHA / Challenge | phân biệt người và bot |

Count là cách kiểm chứng an toàn nhất trước khi bật chặn:

① Đặt rule ở chế độ Count
② Bật log, quan sát vài ngày
③ Xem có request HỢP LỆ nào bị khớp không
④ Nếu sạch → chuyển sang Block

Bật Block ngay từ đầu trên rule chưa kiểm chứng là cách nhanh nhất để chặn nhầm người dùng thật.

Ba cách phân tích log WAF: | Cách | Dùng khi | |---|---| | Athena trên log trong S3 | phân tích lịch sử, truy vấn SQL linh hoạt | | CloudWatch Logs Insights | điều tra nhanh, gần thời gian thực | | OpenSearch | bảng điều khiển trực quan, cảnh báo |

Truy vấn Athena hữu ích để kiểm chứng rule:

SELECT terminatingruleid, action, count(*) AS so_luot
FROM waf_logs
WHERE date_parse(...) > current_date - interval '1' day
GROUP BY terminatingruleid, action
ORDER BY so_luot DESC;

Nó trả lời trực tiếp câu hỏi của đề: rule nào đang khớp, và chặn hay cho qua.

Ba cân nhắc về chi phí và quyền riêng tư của log WAF: | Cân nhắc | Chi tiết | |---|---| | Khối lượng lớn | log mọi request tốn đáng kể với site lưu lượng cao | | Lọc trước khi ghi | LoggingFilter chỉ ghi request bị BLOCK hoặc COUNT | | Che trường nhạy cảm | RedactedFields cho header Authorization, Cookie |

Hai dòng cuối nên bật cho môi trường sản xuất: chỉ ghi những gì cần điều tra, và không để token hay cookie phiên nằm trong log.

Đáp án

B, C và F:

• B — Lưu dữ liệu trên S3 và dùng Amazon Macie để tự động phát hiện, phân loại và bảo vệ dữ liệu nhạy cảm
• F — Cấu hình AWS Security Hub làm bảng điều khiển trung tâm để có tầm nhìn tổng thể và khắc phục vấn đề nhanh
• C — Dùng Amazon Athena để phân tích dữ liệu trên S3 bằng SQL chuẩn

Vì sao đúng

Đề nêu bốn yêu cầu, và ba đáp án phủ đúng bốn: | Yêu cầu | Dịch vụ | |---|---| | Tự động nhận diện thông tin nhạy cảm | B — Macie | | Bảng điều khiển tổng hợp cảnh báo + khắc phục tự động | F — Security Hub | | Dịch vụ truy vấn tương tác hiệu năng cao | C — Athena | | Chi phí thấp | cả ba đều theo mức dùng |

B — Macie là dịch vụ duy nhất phát hiện dữ liệu nhạy cảm:

Macie quét nội dung object trong S3
    ↓ dùng học máy + mẫu nhận dạng
Phát hiện: số thẻ tín dụng, số an sinh xã hội,
           khoá AWS, hộ chiếu, thông tin y tế
    ↓ finding
Security Hub

Đề nói khách hàng là các tổ chức tài chính — đúng loại dữ liệu mà Macie được thiết kế để tìm.

F — Security Hub cho vế "security dashboard that aggregates alerts":

Macie      ─┐
GuardDuty  ─┼→ Security Hub → bảng điều khiển + EventBridge → khắc phục tự động
Inspector  ─┘

C — Athena cho vế "high-performing interactive query service": | Đặc điểm | Chi tiết | |---|---| | Không cần máy chủ | không quản lý hạ tầng | | SQL chuẩn | không phải học ngôn ngữ mới | | Tính phí theo dữ liệu quét | không truy vấn thì không tốn tiền | | Truy vấn trực tiếp trên S3 | không cần nạp dữ liệu vào đâu |

Dòng thứ ba là điểm "cost-optimal" mà đề nhấn mạnh — khác hẳn với một cụm cơ sở dữ liệu chạy liên tục.

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

• E. Cấu hình Amazon Detective cùng GuardDuty để phân tích và tìm nguyên nhân gốc của vấn đề bảo mật — đây là phương án gần nhất và là bộ công cụ bảo mật giá trị, nhưng nó không đáp ứng yêu cầu nào trong bốn yêu cầu của đề: nó không phát hiện dữ liệu nhạy cảm, không phải bảng điều khiển tổng hợp, không phải dịch vụ truy vấn. Nó phục vụ điều tra sau sự cố.
• D. Dùng Amazon QuickSight để nhúng bảng điều khiển và trực quan hoá tương tác vào ứng dụng — nhầm loại "interactive": QuickSight là công cụ trực quan hoá BI (biểu đồ, bảng điều khiển kinh doanh), không phải dịch vụ truy vấn chạy SQL. Đề nói "high-performing interactive QUERY service" — đó là Athena. (QuickSight thường dùng Athena làm nguồn dữ liệu — chúng bổ sung nhau.)
• A. Dùng S3 kèm S3 Intelligent-Tiering để tự động tiết kiệm chi phí với dữ liệu có mẫu truy cập không rõ ràng — là tối ưu chi phí lưu trữ hợp lý, nhưng nó không giải quyết yêu cầu nào về bảo mật hay truy vấn. Đề hỏi ba việc cụ thể, và tầng lưu trữ không nằm trong số đó.

Ghi nhớ

Bốn dịch vụ bảo mật của AWS — bảng phân biệt cốt lõi: | Dịch vụ | Phát hiện | Nguồn | |---|---|---| | Macie | DỮ LIỆU NHẠY CẢM | nội dung object S3 | | GuardDuty | MỐI ĐE DOẠ đang diễn ra | Flow Logs, DNS, CloudTrail | | Inspector | LỖ HỔNG phần mềm | EC2, ECR, Lambda | | Security Hub | TỔNG HỢP + chấm điểm chuẩn | finding từ ba cái trên |

Câu hỏi phân biệt:

"Dữ liệu nhạy cảm nằm ở đâu?" → Macie "Có ai đang tấn công không?" → GuardDuty "Phần mềm có lỗ hổng không?" → Inspector "Tổng quan tuân thủ ở đâu?" → Security Hub "Vì sao sự cố này xảy ra?" → Detective

Các loại dữ liệu Macie phát hiện: | Nhóm | Ví dụ | |---|---| | Tài chính | số thẻ tín dụng, số tài khoản ngân hàng | | Định danh cá nhân | số an sinh xã hội, hộ chiếu, bằng lái | | Thông tin đăng nhập | AWS access key, private key, chuỗi kết nối CSDL | | Y tế | mã số bảo hiểm y tế | | Tuỳ chỉnh | custom data identifier bằng regex — cho định dạng riêng của bạn |

Dòng cuối quan trọng cho tổ chức Việt Nam: số CCCD, mã số thuế, số tài khoản ngân hàng nội địa không nằm trong bộ nhận dạng sẵn — phải viết custom data identifier bằng biểu thức chính quy.

Ba dịch vụ truy vấn và phân tích — chọn đúng theo nhu cầu: | Dịch vụ | Mô hình | Phù hợp | |---|---|---| | Athena | không máy chủ, SQL trên S3 | truy vấn không thường xuyên, chi phí theo lượt | | Redshift | cụm chạy liên tục | truy vấn nặng, thường xuyên, dữ liệu rất lớn | | QuickSight | trực quan hoá BI | bảng điều khiển cho người dùng cuối |

Athena thắng ở tiêu chí "cost-optimal" khi truy vấn không liên tục — bạn không trả tiền cho thời gian nhàn rỗi.

Ba cách giảm chi phí Athena — đáng biết vì nó tính theo dữ liệu quét: | Cách | Mức tiết kiệm | |---|---| | Dùng định dạng cột (Parquet, ORC) | thường 30–90% | | Phân vùng dữ liệu theo ngày/tháng | chỉ quét phân vùng cần thiết | | Nén dữ liệu | ít byte hơn để quét |

Và một lưu ý về chi phí Macie: nó tính phí theo số object đánh giá và dung lượng quét nội dung. Với hồ dữ liệu lớn, hãy dùng sampling và giới hạn phạm vi theo bucket hoặc prefix thay vì quét toàn bộ — quét mọi thứ mỗi ngày là khoản chi bất ngờ thường gặp nhất khi mới bật Macie.

Đáp án

B — Các AWS Config managed rule liên quan bị xoá. Mọi Web ACL của AWS WAF không còn chứa tài nguyên nào cũng bị xoá.

Vì sao đúng

Đề hỏi hành vi MẶC ĐỊNH của AWS Firewall Manager khi tài nguyên rời khỏi phạm vi của policy.

Firewall Manager dọn dẹp những gì CHÍNH NÓ đã tạo ra:

Tài nguyên rời khỏi phạm vi policy
    ↓
Config managed rule mà policy tạo ra    → XOÁ
Web ACL rỗng (không còn tài nguyên nào) → XOÁ

Logic đằng sau: Firewall Manager quản lý vòng đời của các artifact do nó sinh ra. Khi không còn tài nguyên nào cần bảo vệ, giữ lại một Web ACL rỗng chỉ tốn chi phí (WAF tính phí theo Web ACL) mà không phục vụ mục đích gì.

Và chi tiết "Web ACL KHÔNG CÒN CHỨA TÀI NGUYÊN NÀO" là điều kiện quan trọng: | Tình huống | Web ACL | |---|---| | Còn tài nguyên khác đang dùng | GIỮ LẠI | | Rỗng hoàn toàn | XOÁ |

Nên việc một tài nguyên rời phạm vi không tự động xoá Web ACL đang phục vụ các tài nguyên khác.

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

• C. Web ACL rỗng bị xoá. Tương tự, EC2 instance tự động được gỡ khỏi security group đã sao chép khi rời phạm vi policy — đây là phương án gần nhất và sai ở vế security group: với security group common policy, Firewall Manager KHÔNG tự động gỡ security group đã sao chép khỏi tài nguyên rời phạm vi. Bạn phải gỡ thủ công.
• A. Mọi tài nguyên được bảo vệ khi rời phạm vi đều tự động được tách ra và gỡ bỏ bảo vệ — quá tổng quát và sai: hành vi khác nhau tuỳ loại policy, và với security group policy thì bảo vệ vẫn còn nguyên.
• D. Application Load Balancer được liên kết với Web ACL bị xoá khỏi Web ACL trong khi bảo vệ vẫn còn nguyên; Web ACL rỗng bị xoá — mâu thuẫn nội tại: nếu ALB đã bị gỡ khỏi Web ACL thì bảo vệ không còn. Hai vế loại trừ nhau.

Ghi nhớ

Firewall Manager là gì và không phải gì: | Là | Không phải | |---|---| | Lớp quản lý TẬP TRUNG cho WAF, Shield, security group, Network Firewall, DNS Firewall | một tường lửa riêng | | Áp chính sách cho TOÀN TỔ CHỨC | thay thế cho WAF hay Shield | | Tự động áp cho tài khoản và tài nguyên MỚI | |

Giá trị chính là dòng cuối: tài khoản mới gia nhập tổ chức hoặc ALB mới được tạo tự động nằm trong phạm vi bảo vệ — không cần ai nhớ cấu hình.

Các loại policy của Firewall Manager: | Loại | Quản lý | |---|---| | AWS WAF policy | Web ACL cho CloudFront, ALB, API Gateway | | Shield Advanced policy | bảo vệ DDoS | | Security group policy | common (áp chung), content audit (kiểm tra rule), usage audit (tìm SG không dùng) | | Network Firewall policy | tường lửa mạng VPC | | DNS Firewall policy | chặn truy vấn DNS độc hại | | Palo Alto, Fortinet | tường lửa của đối tác |

Ba biến thể của security group policy là chi tiết đáng nhớ: | Biến thể | Việc | |---|---| | Common | sao chép một security group chuẩn tới mọi tài khoản | | Content audit | kiểm tra rule có vi phạm không (ví dụ mở 22 ra Internet) | | Usage audit | tìm security group thừa, không gắn với tài nguyên nào |

Ba điều kiện tiên quyết để dùng Firewall Manager:

① AWS Organizations đã bật với "all features"
② Chỉ định một tài khoản làm Firewall Manager administrator
③ AWS Config đã bật ở mọi tài khoản và Region cần quản lý

Điều kiện ③ hay bị bỏ sót — Firewall Manager dựa vào Config để biết tài nguyên nào tồn tại và ở trạng thái nào. Config chưa bật thì policy không đánh giá được gì.

Hai chế độ áp policy: | Chế độ | Hành vi | |---|---| | Auto remediation bật | Firewall Manager tự động áp bảo vệ cho tài nguyên trong phạm vi | | Auto remediation tắt | chỉ báo cáo tài nguyên không tuân thủ |

Nên bắt đầu với chế độ tắt để xem policy sẽ chạm vào những gì, rồi mới bật — giống nguyên tắc dùng Count trước Block của WAF.

Và một lưu ý vận hành liên quan trực tiếp tới câu hỏi này: vì Firewall Manager xoá Config rule và Web ACL rỗng mà nó tạo, đừng sửa tay các artifact đó — thay đổi thủ công có thể bị ghi đè hoặc mất khi phạm vi policy thay đổi. Mọi điều chỉnh nên thực hiện qua chính policy của Firewall Manager.

Đáp án

D — Bạn KHÔNG THỂ dùng ID của Internet Gateway làm nguồn tuỳ chỉnh cho rule inbound.

Vì sao đúng

Đề hỏi phương án KHÔNG hợp lệ, và Internet Gateway ID là thứ duy nhất không dùng được.

Những gì security group chấp nhận làm nguồn: | Nguồn hợp lệ | Ví dụ | |---|---| | Một địa chỉ IP | 203.0.113.45/32 | | Dải IP dạng CIDR | 10.0.0.0/16, 0.0.0.0/0 | | ID của security group khác | sg-0abc123 | | ID của chính security group đó | cho phép các instance trong nhóm nói chuyện với nhau | | Prefix list ID | pl-0abc123 — danh sách CIDR có tên |

Vì sao Internet Gateway không nằm trong danh sách:

Internet Gateway là một thành phần ĐỊNH TUYẾN
    → nó cho phép VPC gửi/nhận lưu lượng với Internet
    → nó KHÔNG PHẢI nguồn của lưu lượng
    → lưu lượng đi qua IGW vẫn mang IP nguồn thật của client

Nên muốn cho phép lưu lượng từ Internet, bạn dùng 0.0.0.0/0 — không phải ID của IGW.

Prefix list là mục ít người biết và rất hữu ích: | Loại | Chi tiết | |---|---| | Customer-managed prefix list | danh sách CIDR do bạn đặt tên và quản lý tập trung | | AWS-managed prefix list | dải IP của dịch vụ AWS: com.amazonaws.<region>.s3, ...cloudfront.origin-facing |

Thay vì liệt kê 15 dải IP văn phòng vào mỗi security group:
    → tạo prefix list "van-phong-cong-ty"
    → tham chiếu nó trong mọi security group
    → đổi địa chỉ một nơi, áp dụng khắp nơi

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

(Ba phương án còn lại đều là cấu hình HỢP LỆ — câu hỏi tìm cái không hợp lệ.)

• A. Dùng một security group làm nguồn tuỳ chỉnh — hợp lệ và là thực hành tốt nhất: nó khiến rule không phụ thuộc vào IP, nên Auto Scaling thay instance không cần sửa gì.
• B. Dùng một địa chỉ IP làm nguồn — hợp lệ: khai dạng /32 cho IPv4 hoặc /128 cho IPv6.
• C. Dùng một dải IP dạng CIDR làm nguồn — hợp lệ: cách khai phổ biến nhất.

Ghi nhớ

Năm loại nguồn của security group rule:

① Địa chỉ IP đơn         203.0.113.45/32
② Dải CIDR               10.0.0.0/16
③ Security group ID      sg-0abc123
④ Chính nó (self)        cho phép nội bộ nhóm
⑤ Prefix list ID         pl-0abc123

Ưu tiên dùng ③ khi có thể — nó thể hiện đúng ý định kiến trúc và tự thích ứng khi hạ tầng thay đổi.

Ba giới hạn của việc tham chiếu security group: | Giới hạn | Chi tiết | |---|---| | Cùng VPC | hoặc VPC chia sẻ qua RAM | | VPC peering CÙNG Region | peering liên Region KHÔNG hỗ trợ | | Không dùng được cho lưu lượng từ ngoài VPC | phải dùng CIDR |

Dòng thứ hai là nội dung của câu #7700 — và là lý do phải dùng CIDR trong tình huống peering liên Region.

Security group và NACL — bảng phân biệt nền tảng: | | Security group | Network ACL | |---|---|---| | Mức | ENI | subnet | | Trạng thái | stateful | stateless | | Rule | CHỈ Allow | Allow VÀ Deny | | Đánh giá | tất cả rule | theo thứ tự số, dừng ở rule khớp đầu | | Nguồn chấp nhận | IP, CIDR, SG, prefix list | CHỈ CIDR |

Dòng cuối là khác biệt đáng nhớ: NACL không tham chiếu security group được — nó chỉ làm việc với địa chỉ mạng.

Ba giới hạn số lượng cần biết: | Giới hạn | Mặc định | |---|---| | Security group mỗi ENI | 5 (tăng được tới 16) | | Rule mỗi security group | 60 inbound + 60 outbound | | Tích (SG mỗi ENI × rule mỗi SG) | tối đa 1.000 |

Một prefix list tính là nhiều rule — bằng số mục tối đa (MaxEntries) của nó, không phải số mục thực tế. Đây là chi tiết gây bất ngờ khi bạn chạm giới hạn rule mà không hiểu vì sao.

Và một AWS-managed prefix list rất hữu ích cho bảo mật: com.amazonaws.global.cloudfront.origin-facing. Dùng nó làm nguồn cho security group của ALB đảm bảo chỉ CloudFront kết nối được, không ai đi thẳng vào ALB bỏ qua CDN và WAF — bịt đúng lỗ hổng nhắc tới ở câu #7729.