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

Đáp án

C và E.

• E — Chuyển nội dung tĩnh sang Amazon S3, đặt CloudFront phía trước, và thêm AWS WAF cho CloudFront distribution
• C — Dùng Amazon Route 53 để phân phối lưu lượng

Vì sao đúng

Đề mô tả: website trên một EC2 instance, dữ liệu ở RDS, và phần lớn dữ liệu là ảnh tĩnh. Cần chống DDoS.

E — chuyển ảnh sang S3 + CloudFront giải quyết đúng gốc vấn đề:

Trước:  Mọi request ảnh → một EC2 instance
        → tấn công DDoS đánh thẳng vào máy chủ gốc
        → một máy không chịu nổi

Sau:    Request ảnh → CloudFront (hơn 600 điểm biên toàn cầu)
        → hấp thụ tấn công ở BIÊN, phân tán trên hạ tầng của AWS
        → origin gần như không bị chạm tới

Ba lớp bảo vệ mà E mang lại cùng lúc: | Lớp | Chi tiết | |---|---| | CloudFront hấp thụ ở biên | quy mô toàn cầu, tự động có Shield Standard | | WAF trên CloudFront | lọc tầng 7 theo quy tắc | | S3 thay EC2 cho nội dung tĩnh | giảm hẳn tải lên máy chủ gốc |

C — Route 53 là lớp DNS, và nó cũng là một dịch vụ biên có khả năng chống DDoS: | Đặc điểm | Chi tiết | |---|---| | Hạ tầng anycast phân tán toàn cầu | DNS không thành điểm sập | | Có Shield Standard sẵn | miễn phí | | Health check + failover routing | chuyển hướng khi endpoint gặp sự cố |

Nguyên tắc chung mà hai đáp án này thể hiện:

Đẩy lưu lượng ra các dịch vụ BIÊN của AWS (Route 53, CloudFront, Shield, WAF), giảm diện tích phơi ra của tài nguyên gốc.

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

• D. Cấu hình EC2 với Auto Scaling Group để mở rộng khi bị DDoS; đặt WAF trước ASG — đây là phương án gần nhất và sai ở hai điểm: WAF không gắn được vào Auto Scaling group — nó chỉ gắn vào CloudFront, ALB, API Gateway, AppSync. Và mở rộng để chịu tấn công nghĩa là TRẢ TIỀN cho cuộc tấn công — kẻ tấn công đạt được mục tiêu gây thiệt hại tài chính.
• A. Dùng Global Accelerator để phân phối lưu lượng — là dịch vụ biên hợp lệ và có chống DDoS, nhưng nó tối ưu cho TCP/UDP không phải HTTP (game, VoIP, IoT). Với website nhiều ảnh tĩnh, CloudFront là lựa chọn đúng vì nó cache được nội dung — Global Accelerator chỉ định tuyến chứ không cache.
• B. Cấu hình Amazon Inspector với Security Hub để giảm thiểu DDoS bằng cách quét liên tục và đưa ra phát hiện lỗ hổng gần thời gian thực — sai dịch vụ hoàn toàn: Inspector quét lỗ hổng phần mềm (CVE). Nó không liên quan gì tới DDoS.

Ghi nhớ

Ba lớp phòng thủ DDoS trên AWS: | Lớp | Chống | Chi phí | |---|---|---| | Shield Standard | tầng 3/4 phổ biến | MIỄN PHÍ, bật sẵn cho mọi tài khoản | | AWS WAF | tầng 7 theo quy tắc | tính phí | | Shield Advanced | tầng 3/4/7 nâng cao + SRT + bảo vệ chi phí | 3.000 USD/tháng |

Bốn dịch vụ biên có khả năng chống DDoS tốt nhất: | Dịch vụ | Phù hợp | |---|---| | CloudFront | HTTP/HTTPS, nội dung tĩnh và động ← câu này | | Route 53 | DNS ← câu này | | Global Accelerator | TCP/UDP không phải HTTP | | API Gateway (edge-optimized) | REST API |

Bốn nguyên tắc kiến trúc chống DDoS: | Nguyên tắc | Cách làm | |---|---| | Giảm diện tích phơi ra | origin trong private subnet, chỉ nhận từ CloudFront | | Đẩy ra biên | CloudFront, Route 53 | | Mở rộng để hấp thụ | ASG, nhưng cân nhắc chi phí | | Biết khi nào bị tấn công | alarm trên DDoSDetected của Shield Advanced |

Dòng đầu là việc hay bị quên nhất: đặt CloudFront trước nhưng vẫn để ALB hoặc EC2 nhận lưu lượng từ 0.0.0.0/0 thì kẻ tấn công tìm ra IP gốc và bỏ qua toàn bộ lớp bảo vệ. Bịt bằng cách dùng AWS-managed prefix list trong security group:

Security group của origin:
  Nguồn: com.amazonaws.global.cloudfront.origin-facing

Hoặc dùng custom header bí mật mà chỉ CloudFront gửi, kiểm tra ở ALB.

Vì sao "mở rộng để chịu tấn công" là chiến lược tồi: | Vấn đề | Chi tiết | |---|---| | Chi phí tăng theo quy mô tấn công | kẻ tấn công điều khiển hoá đơn của bạn | | Có giới hạn trên | ASG có MaxSize, và hạn mức tài khoản | | Vẫn chuyển lưu lượng độc hại tới ứng dụng | không lọc gì |

(Shield Advanced có bảo vệ chi phí hoàn lại phần scale do tấn công gây ra — nhưng đó là biện pháp bù đắp, không phải giải pháp.)

Và một lợi ích phụ đáng kể của phương án E ngoài bảo mật: chuyển ảnh sang S3 + CloudFront giảm chi phí và tăng tốc độ tải trang cho người dùng thật, kể cả khi không có tấn công nào. Đó là kiểu thay đổi kiến trúc đúng ở nhiều mặt cùng lúc.

Đáp án

D — Xoá hoặc xoay vòng khoá của người dùng. Rà log CloudTrail ở MỌI Region và xoá mọi tài nguyên trái phép đã được tạo hoặc sửa đổi.

Vì sao đúng

Đề nêu hai yêu cầu tách bạch: vô hiệu hoá khoá ngay lập tức và đánh giá hoạt động của người dùng để tìm dấu hiệu xâm nhập. D là phương án duy nhất làm cả hai.

Vế đầu — chặn nguồn truy cập:

Access key đang nằm công khai trên Internet
    → mỗi giây là một cơ hội bị khai thác
    → vô hiệu hoá hoặc xoá NGAY, không chờ điều tra xong

Vế thứ hai — và cụm "MỌI Region" là chi tiết quan trọng nhất của câu hỏi:

Console mặc định chỉ hiện MỘT Region
    → kẻ tấn công biết điều đó
    → chúng tạo tài nguyên ở Region bạn KHÔNG BAO GIỜ nhìn tới
    → ap-south-1, sa-east-1, eu-north-1...

Đây là mẫu tấn công phổ biến nhất khi access key bị lộ: dựng hàng loạt EC2 instance loại lớn để đào tiền ảo, ở Region xa nhất có thể.

Hai cách rà soát hiệu quả: | Cách | Chi tiết | |---|---| | CloudTrail Event history ở từng Region | xem lời gọi API của access key đó | | Hoá đơn / Cost Explorer | hiện chi phí ở MỌI Region cùng lúc — nhanh nhất |

Và một chi tiết dễ bỏ sót: vô hiệu hoá access key không thu hồi token STS đã được cấp từ nó. Chúng còn hiệu lực tới 12 giờ:

{"Effect": "Deny", "Action": "*", "Resource": "*",
 "Condition": {"DateLessThan": {"aws:TokenIssueTime": "2026-08-30T12:00:00Z"}}}

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

• A. Yêu cầu người dùng gỡ thông tin đăng nhập khỏi Internet; xoay vòng khoá và triển khai lại mọi tài nguyên với thông tin mới — đây là phương án gần nhất và có phần xoay vòng khoá đúng, nhưng nó sai thứ tự ưu tiên: gỡ khoá khỏi Internet không cứu được gì — nó đã bị thu thập từ lâu (các bot quét GitHub tìm thấy key trong vài giây). Và nó hoàn toàn thiếu bước điều tra.
• B. Xoá IAM user và mọi tài nguyên người dùng đó đã tạo; tạo thông tin đăng nhập mới và khởi chạy lại tài nguyên — phá huỷ bằng chứng và phá huỷ cả tài nguyên hợp lệ: bạn không phân biệt được đâu là tài nguyên do người dùng tạo hợp pháp, đâu là do kẻ tấn công. Và xoá sạch thì không còn gì để điều tra.
• C. Yêu cầu người dùng gỡ thông tin khỏi Internet; báo cáo lạm dụng cho đội AWS Trust & Safety — nhầm vai trò của Trust & Safety: họ xử lý báo cáo về tài nguyên AWS gây hại cho người khác. Việc khoá của chính bạn bị lộ là sự cố nội bộ của bạn — và phương án này không vô hiệu hoá khoá.

Ghi nhớ

Quy trình xử lý khi access key bị lộ:

① CHẶN     → vô hiệu hoá (Inactive) hoặc xoá access key NGAY
② THU HỒI  → thu hồi token STS đã cấp (chính sách theo aws:TokenIssueTime)
③ RÀ SOÁT  → CloudTrail ở MỌI Region + hoá đơn
④ DỌN DẸP  → xoá tài nguyên trái phép, xoá IAM entity lạ
⑤ KHÔI PHỤC→ khoá mới cho ứng dụng hợp lệ
⑥ NGĂN NGỪA→ chuyển sang IAM role, quét bí mật trong mã nguồn

Inactive khác Delete — và khác biệt có ý nghĩa: | Trạng thái | Đặc điểm | |---|---| | Inactive | ngừng hoạt động NGAY, còn tồn tại để điều tra, bật lại được | | Đã xoá | không khôi phục được |

Ưu tiên Inactive trong lúc còn đang điều tra — nó cho hiệu quả chặn tương đương mà vẫn giữ được dấu vết.

Bốn nơi cần rà soát: | Nơi | Tìm gì | |---|---| | Hoá đơn / Cost Explorer | chi phí bất thường ở Region lạ — nhanh nhất | | CloudTrail (mọi Region) | lời gọi API của khoá đó | | IAM | user, role, access key mới xuất hiện | | EC2 ở MỌI Region | instance lạ, thường là loại compute lớn |

Ba dấu hiệu điển hình của việc lạm dụng khoá bị lộ: | Dấu hiệu | Mục đích của kẻ tấn công | |---|---| | EC2 loại lớn ở Region lạ | đào tiền ảo | | Tạo IAM user/role mới | giữ quyền truy cập lâu dài dù khoá bị thu hồi | | Truy cập hàng loạt S3, tải dữ liệu ra | rò rỉ dữ liệu |

Dòng giữa là mối nguy bị đánh giá thấp nhất: kẻ tấn công thường tạo một IAM user mới ngay lập tức — nên xoá khoá bị lộ mà không rà IAM thì chúng vẫn còn đường vào.

Bốn biện pháp ngăn tái diễn: | Biện pháp | Hiệu quả | |---|---| | Dùng IAM role thay access key dài hạn | loại bỏ hẳn thứ có thể rò rỉ | | IAM Identity Center cho người dùng | thông tin đăng nhập tạm thời | | Quét bí mật trong mã nguồn | git-secrets, GitHub secret scanning | | AWS Budgets cảnh báo chi phí | thường phát hiện sớm hơn cả việc nhìn hoá đơn |

Dòng đầu là cách chữa gốc rễ — không có access key dài hạn thì không có gì để lộ.

Và một điều đáng biết về phản ứng của chính AWS: khi AWS phát hiện access key của bạn bị công khai, họ tự động gắn policy AWSCompromisedKeyQuarantine (hoặc AWSExposedCredentialPolicy_DO_NOT_REMOVE) vào IAM user đó để hạn chế thiệt hại, và gửi email cảnh báo. Thấy policy đó xuất hiện là dấu hiệu chắc chắn rằng khoá đã bị lộ ra ngoài — đừng gỡ nó cho tới khi đã xử lý xong.

Đáp án

A — Thiết lập AWS WAF web ACL; tạo rule từ chối mọi request không xuất phát từ quốc gia được chỉ định; gắn rule vào web ACL và gắn web ACL vào ALB.

Vì sao đúng

Đề nêu ba yêu cầu, và WAF geo match đáp ứng cả ba: | Yêu cầu | Cơ chế | |---|---| | Chỉ người dùng từ một quốc gia truy cập được | geo match statement | | Giám sát được request bị chặn để phân tích | WAF log + metric | | Tối ưu và ít bảo trì | AWS tự duy trì cơ sở dữ liệu GeoIP |

Cấu hình:

{
  "Name": "ChiChoPhepVietNam",
  "Priority": 1,
  "Statement": {
    "NotStatement": {
      "Statement": {"GeoMatchStatement": {"CountryCodes": ["VN"]}}
    }},
  "Action": {"Block": {}}
}

Vế "low-maintenance" là điểm phân biệt quyết định với phương án B:

Geo match:  AWS duy trì bản đồ IP → quốc gia, cập nhật liên tục
            → bạn khai đúng MỘT mã quốc gia
            → không bảo trì gì

IP set:     bạn phải tự liệt kê MỌI dải IP của quốc gia đó
            → hàng nghìn dải CIDR
            → chúng thay đổi liên tục khi ISP được cấp phát mới
            → bảo trì vĩnh viễn, và luôn thiếu sót

Và vế "monitor prohibited requests" được đáp ứng tự nhiên: WAF ghi log mọi request kèm terminatingRuleId và mã quốc gia:

{"action": "BLOCK", "terminatingRuleId": "ChiChoPhepVietNam",
 "httpRequest": {"clientIp": "203.0.113.45", "country": "SG", "uri": "/dat-hang"}}

Đội bảo mật truy vấn được ngay bằng Athena hoặc CloudWatch Logs Insights.

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

• B. Thiết lập WAF web ACL; tạo rule chặn request không thuộc dải IP trong một IP set chứa danh sách dải IP của quốc gia đó — đây là phương án gần nhất và hoạt động về mặt kỹ thuật, nhưng nó trái thẳng yêu cầu "low-maintenance": duy trì danh sách dải IP của cả một quốc gia là công việc không bao giờ kết thúc và luôn có sai sót.
• C. Tạo Global Accelerator và gắn WAF vào nó; tạo rule chặn; đặt Global Accelerator trước ALB hiện có — WAF KHÔNG gắn được vào Global Accelerator. WAF chỉ gắn được vào CloudFront, ALB, API Gateway, AppSync, Cognito User Pool, App Runner.
• D. Thiết lập AWS Shield để chặn request không xuất phát từ quốc gia được chỉ định; gắn Shield vào ALB — Shield không lọc theo quốc gia: nó chống DDoS ở tầng mạng và tầng ứng dụng. Việc lọc theo quy tắc là của WAF.

Ghi nhớ

Ba cách chặn theo địa lý — chọn theo hoàn cảnh: | Cách | Chi phí | Ngoại lệ theo IP | Dùng với | |---|---|---|---| | CloudFront geo restriction | miễn phí | ❌ | chỉ CloudFront | | WAF geo match | tính phí | ✅ | CloudFront, ALB, API Gateway ← câu này | | Route 53 geolocation routing | phí DNS | — | định tuyến, KHÔNG chặn |

Đề dùng ALB, mà ALB không có geo restriction — nên WAF là lựa chọn duy nhất.

Hai cách viết rule "chỉ cho phép một quốc gia":

// Cách 1: NotStatement bao ngoài geo match — chặn phần còn lại
{"Statement": {"NotStatement": {"Statement": {
   "GeoMatchStatement": {"CountryCodes": ["VN"]}}}},
 "Action": {"Block": {}}}

// Cách 2: Allow cho quốc gia đó, default action của web ACL là Block
{"Statement": {"GeoMatchStatement": {"CountryCodes": ["VN"]}},
 "Action": {"Allow": {}}}
// + DefaultAction: Block

Cách 2 an toàn hơn khi bạn muốn danh sách trắng nghiêm ngặt — mọi thứ không khớp đều bị chặn theo mặc định.

Ba giới hạn của việc chặn theo địa lý: | Giới hạn | Chi tiết | |---|---| | VPN và proxy vượt qua được | không phải biện pháp bảo mật mạnh | | Cơ sở dữ liệu GeoIP không hoàn hảo | vài phần trăm sai sót | | Người dùng hợp lệ đi công tác bị chặn | cần cơ chế ngoại lệ |

Dòng đầu cần nói thẳng: chặn theo quốc gia phù hợp cho tuân thủ quy định và giảm nhiễu, không phải để ngăn kẻ tấn công có chủ đích — họ chỉ cần một VPN.

Dòng cuối là vấn đề vận hành hay gặp: khi cần ngoại lệ, thêm một rule IP set với action Allow ở priority THẤP HƠN (số nhỏ hơn) rule geo match — xem câu #7756 để biết thứ tự rule quyết định thế nào.

Ba cách giám sát request bị chặn: | Cách | Đặc điểm | |---|---| | WAF log (S3/Firehose/CloudWatch Logs) | chi tiết từng request | | CloudWatch metric BlockedRequests | số liệu tổng hợp, đặt alarm được | | Sampled requests trong Console | xem nhanh mẫu request gần đây, miễn phí |

Dòng cuối tiện cho kiểm chứng nhanh: WAF lưu mẫu request trong 3 giờ gần nhất ngay trong Console, không cần bật log.

Và một lời khuyên khi triển khai: đặt rule ở action Count trước. Chạy vài ngày, xem có bao nhiêu request hợp lệ đến từ ngoài quốc gia dự kiến — thường sẽ có người dùng thật đi công tác hoặc dùng mạng doanh nghiệp định tuyến qua nước khác. Bật Block ngay từ đầu là cách nhanh nhất để chặn nhầm khách hàng.

Đáp án

A — Cấu hình AWS WAF gửi log vào S3 bucket qua Amazon Kinesis Data Firehose. Thiết lập AWS Glue crawler và bảng Amazon Athena để truy vấn, rồi tạo trực quan hoá bằng Amazon QuickSight.

Vì sao đúng

Đề nêu ba yêu cầu, và luồng này đáp ứng cả ba: | Yêu cầu | Cơ chế | |---|---| | Kiến trúc không máy chủ (serverless) | Firehose, S3, Glue, Athena, QuickSight — không có máy chủ nào | | Nhiều bảng điều khiển | QuickSight | | Dữ liệu gần thời gian thực | Firehose đẩy theo lô mỗi 60 giây hoặc 1 MB |

Luồng đầy đủ:

WAF web ACL
    ↓ log
Kinesis Data Firehose   (gom theo lô, nén, chuyển định dạng)
    ↓
S3 bucket               (lưu trữ rẻ và bền)
    ↓
Glue crawler            (tự phát hiện schema, tạo bảng trong Data Catalog)
    ↓
Athena                  (truy vấn SQL, không máy chủ)
    ↓
QuickSight              (bảng điều khiển)

Vì sao Glue crawler là mắt xích cần thiết: log WAF là JSON có cấu trúc lồng nhau và phân vùng theo thời gian. Crawler tự nhận diện schema và tự thêm phân vùng mới khi dữ liệu đổ về — nếu không, bạn phải viết CREATE TABLE bằng tay và chạy MSCK REPAIR TABLE liên tục.

Và Firehose là đường duy nhất đúng cho log WAF vào S3 dạng luồng: | Đích của WAF log | Hỗ trợ | |---|---| | Kinesis Data Firehose | ✅ | | S3 trực tiếp | ✅ (bổ sung sau) | | CloudWatch Logs | ✅ | | Kinesis Data STREAMS | ❌ KHÔNG |

Dòng cuối là điểm loại của phương án B — Data Streams và Data Firehose là hai dịch vụ khác nhau, và WAF chỉ hỗ trợ Firehose.

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

• B. Cấu hình WAF gửi log vào S3 qua Kinesis Data STREAMS; Glue crawler + Athena + QuickSight — đây là phương án gần nhất và chỉ sai một mắt xích: WAF không gửi log tới Kinesis Data Streams. Và ngay cả nếu có, Data Streams không tự ghi vào S3 — nó là hàng đợi luồng cần một consumer tự viết.
• C. Cấu hình WAF gửi log tới CloudWatch Logs; dùng Logs Insights để tìm kiếm; publish dữ liệu lên QuickSight qua tích hợp trực tiếp CloudWatch với QuickSight — tích hợp trực tiếp đó không tồn tại: QuickSight không kết nối trực tiếp tới CloudWatch Logs. (Logs Insights là công cụ điều tra tốt, nhưng không phải nguồn dữ liệu cho bảng điều khiển QuickSight.)
• D. Gửi log tới S3; dùng Redshift Spectrum truy vấn trực tiếp từ tệp trên S3; dùng tích hợp Redshift Spectrum với QuickSight — trái yêu cầu "serverless": Redshift Spectrum đòi một cụm Redshift chạy liên tục. Với mục đích truy vấn log không thường xuyên, đó là chi phí lớn và không phải kiến trúc không máy chủ.

Ghi nhớ

Kinesis Data Streams và Kinesis Data Firehose — bảng phân biệt cốt lõi: | | Data Streams | Data Firehose | |---|---|---| | Mô hình | hàng đợi luồng, bạn tự viết consumer | đường ống giao hàng được quản lý | | Đích | tự xử lý | S3, Redshift, OpenSearch, Splunk, HTTP | | Độ trễ | mili giây | tối thiểu ~60 giây (gom theo lô) | | Phát lại (replay) | ✅ giữ 1–365 ngày | ❌ | | Quản lý shard | có | không |

Firehose đúng khi bạn chỉ cần "đưa dữ liệu vào S3" — không cần viết dòng mã nào.

Kiến trúc phân tích log không máy chủ chuẩn của AWS:

Nguồn → Firehose → S3 → Glue Catalog → Athena → QuickSight

Mẫu này dùng được cho nhiều loại log: WAF, VPC Flow Logs, CloudFront, ALB access log, CloudTrail.

Ba việc Glue làm trong luồng này: | Việc | Chi tiết | |---|---| | Crawler phát hiện schema | đọc mẫu dữ liệu, suy ra cấu trúc | | Data Catalog lưu metadata | Athena, Redshift Spectrum, EMR cùng dùng | | Tự thêm phân vùng | chạy theo lịch để nhận dữ liệu mới |

Ba tối ưu quan trọng cho chi phí Athena: | Tối ưu | Mức tiết kiệm | |---|---| | Phân vùng theo năm/tháng/ngày/giờ | truy vấn một ngày chỉ quét một ngày | | Chuyển sang Parquet | thường 30–90% | | Nén (Snappy, GZIP) | ít byte hơn để quét |

Firehose làm được cả hai việc đầu ngay trong đường ống:

{
  "DataFormatConversionConfiguration": {
    "OutputFormatConfiguration": {"Serializer": {"ParquetSerDe": {}}},
    "Enabled": true
  },
  "Prefix": "waf-logs/nam=!{timestamp:yyyy}/thang=!{timestamp:MM}/ngay=!{timestamp:dd}/"
}

Cấu hình này chuyển JSON sang Parquet và phân vùng theo ngày ngay khi ghi — sau đó Athena rẻ hơn nhiều lần mà không cần bước xử lý nào thêm.

Hai cấu hình nên bật cho log WAF trong sản xuất: | Cấu hình | Lý do | |---|---| | LoggingFilter | chỉ ghi request BLOCK/COUNT — giảm mạnh khối lượng và chi phí | | RedactedFields | che Authorization và Cookie |

Và một lưu ý về "gần thời gian thực": Firehose gom theo lô với buffer tối thiểu 60 giây (hoặc 1 MB). Nếu cần độ trễ thấp hơn nữa cho cảnh báo, hãy dùng CloudWatch metric của WAF + alarm song song — metric có sẵn theo phút và không phụ thuộc vào đường ống log.

Đáp án

A và B.

• A — Chỉ định một administrator account trong GuardDuty, rồi dùng tài khoản đó mời các tài khoản khác thành member account. Thêm threat list vào tài khoản quản trị bằng cách tham chiếu object S3 chứa danh sách
• B — Tải threat list lên một S3 bucket và chia sẻ quyền truy cập với tài khoản quản trị

Vì sao đúng

Đề nêu yêu cầu: cấu hình một threat list chung cho mọi tài khoản AWS với công sức tối thiểu.

Điểm mấu chốt: trong mô hình administrator–member của GuardDuty, threat list được cấu hình MỘT LẦN ở tài khoản quản trị và áp cho mọi member.

KHÔNG có mô hình quản trị:
  Tài khoản A → threat list riêng
  Tài khoản B → threat list riêng      ← phải cập nhật N lần mỗi quý
  Tài khoản C → threat list riêng

CÓ administrator account:
  Threat list ở tài khoản quản trị
      → áp tự động cho MỌI member account   ← cập nhật MỘT lần

Đề nói danh sách được cập nhật hằng quý — nên khác biệt giữa "sửa một chỗ" và "sửa ở N tài khoản" là rất lớn theo thời gian.

B là bước chuẩn bị dữ liệu, và nó bắt buộc vì GuardDuty đọc danh sách TỪ S3:

aws guardduty create-threat-intel-set   --detector-id <detector-id>   --name danh-sach-doi-tac-quy-3   --format TXT   --location https://s3.amazonaws.com/bucket-bao-mat/threat-list.txt   --activate

Và quyền đọc object đó phải được cấp cho tài khoản quản trị — nếu bucket nằm ở tài khoản khác thì cần bucket policy cho phép.

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

• C. Tải threat list lên S3 và chia sẻ quyền với delegated administrator của tổ chức cho GuardDuty — đây là phương án gần nhất và là mô hình hiện đại hơn, nhưng nó giả định công ty dùng AWS Organizations — điều đề không hề nói. Đề chỉ nói "maintains separate AWS accounts". Phương án A mô tả mô hình mời (invitation), hoạt động cả khi không có Organizations.
• E. Đưa mọi tài khoản vào AWS Organizations và thêm threat list cho mọi thành viên bằng AWS RAM — RAM không chia sẻ threat list của GuardDuty: nó chia sẻ subnet, Transit Gateway, License Manager configuration, Route 53 Resolver rule — không có GuardDuty trong danh sách.
• D. Tải threat list lên S3 và kích hoạt EventBridge mỗi khi có danh sách mới; đặt GuardDuty làm target của EventBridge để tự động cấu hình — GuardDuty không phải target hợp lệ của EventBridge. Muốn tự động hoá thì phải qua Lambda gọi API update-threat-intel-set. (Ý tưởng tự động hoá là tốt, nhưng cơ chế mô tả không tồn tại.)

Ghi nhớ

Hai loại danh sách IP của GuardDuty: | Danh sách | Hiệu ứng | Giới hạn | |---|---|---| | Trusted IP list | KHÔNG sinh finding cho IP này | 1 danh sách, 2.000 địa chỉ | | Threat IP list | LUÔN sinh finding cho IP này | 6 danh sách, 250.000 địa chỉ mỗi cái |

Trusted list được xử lý TRƯỚC threat list — IP nằm trong cả hai thì không sinh finding (xem câu #7746, #7799).

Hai mô hình quản lý đa tài khoản của GuardDuty: | Mô hình | Cách thiết lập | Phù hợp | |---|---|---| | Invitation (mời) | admin mời, member chấp nhận | không dùng Organizations ← câu này | | Organizations | delegated administrator, tự động thêm tài khoản mới | có Organizations — nên ưu tiên |

Mô hình thứ hai tốt hơn khi có thể: tài khoản mới gia nhập tổ chức tự động được bảo vệ, không cần ai nhớ mời.

Định dạng tệp threat list được hỗ trợ: | Định dạng | Đặc điểm | |---|---| | Plaintext (TXT) | mỗi dòng một IP hoặc CIDR — đơn giản nhất | | STIX | chuẩn trao đổi thông tin đe doạ | | OTX CSV, FireEye, Proofpoint, AlienVault | định dạng của nhà cung cấp |

Ba việc admin account làm được cho member account: | Việc | Chi tiết | |---|---| | Cấu hình threat list và trusted IP list | ← câu này | | Xem toàn bộ finding của member | một bảng điều khiển duy nhất | | Bật/tắt tính năng bảo vệ mở rộng | S3 Protection, Malware Protection, Runtime Monitoring |

Member account KHÔNG sửa được danh sách do admin đặt — đó là điểm mạnh về mặt quản trị: chính sách bảo mật được áp từ trên xuống.

Ba lưu ý khi làm việc với threat list: | Lưu ý | Chi tiết | |---|---| | Danh sách là cấu hình theo REGION | bật GuardDuty ở 5 Region thì phải thêm ở cả 5 | | Chỉ hỗ trợ IPv4 công khai | không nhận IP riêng | | Cần quyền iam:PutRolePolicy trên service-linked role | xem câu #7746 |

Dòng đầu là công việc lặp lại đáng tự động hoá: viết một script hoặc Lambda gọi update-threat-intel-set cho mọi Region khi tệp trên S3 thay đổi — đó chính là ý tưởng đúng nằm sau phương án D, chỉ là D mô tả sai cơ chế.

Và một lưu ý về việc dùng danh sách của bên thứ ba: kiểm tra chất lượng trước khi kích hoạt. Một danh sách quá rộng (ví dụ chứa dải IP của một nhà cung cấp đám mây lớn) sẽ sinh hàng loạt finding giả và làm đội bảo mật mất niềm tin vào hệ thống cảnh báo — vấn đề nghiêm trọng hơn là không có danh sách nào.

Đáp án

A, C và F:

• A — Tạo access key mới và sửa ứng dụng dùng khoá mới. Vô hiệu hoá khoá bị lộ ngay lập tức. Chỉ xoá khoá cũ sau khi đã xác nhận ứng dụng chạy đúng
• C — Nếu phải giữ EC2 instance vì lý do quy định, pháp lý hoặc tuân thủ, hãy tạo EBS snapshot TRƯỚC KHI terminate
• F — Trong Console IAM, tab Permissions, tìm policy tên AWSExposedCredentialPolicy_DO_NOT_REMOVE. Nếu user có policy này thì xoay vòng access key của họ

Vì sao đúng

A — thứ tự thao tác là toàn bộ nội dung của phát biểu này:

① Tạo khoá mới          → chuẩn bị thay thế
② Sửa ứng dụng          → dùng khoá mới
③ VÔ HIỆU HOÁ khoá cũ   → chặn kẻ tấn công (NGAY, không chờ)
④ XOÁ khoá cũ           → chỉ sau khi xác nhận mọi thứ chạy đúng

Vì sao Inactive trước Delete: | Trạng thái | Đặc điểm | |---|---| | Inactive | ngừng hoạt động NGAY, còn tồn tại, BẬT LẠI ĐƯỢC | | Đã xoá | không khôi phục được |

Bước ④ tách riêng là cách phòng ngừa sự cố: nếu phát hiện còn một dịch vụ nào đó vẫn dùng khoá cũ, bạn bật lại được trong lúc sửa — thay vì gây gián đoạn không đảo ngược.

C — snapshot trước khi terminate là nguyên tắc pháp chứng:

Terminate instance → volume EBS gốc bị xoá theo (nếu DeleteOnTermination=true)
                   → MẤT SẠCH bằng chứng
Snapshot trước    → giữ được bản sao chỉ-đọc tại thời điểm sự cố

F — AWSExposedCredentialPolicy_DO_NOT_REMOVE là policy có thật mà AWS tự gắn khi họ phát hiện access key của bạn bị công khai trên Internet. | Ý nghĩa | Chi tiết | |---|---| | AWS đã tự phát hiện khoá bị lộ | họ quét các kho mã công khai | | Policy hạn chế thiệt hại tạm thời | chặn các thao tác tốn kém | | Tên có DO_NOT_REMOVE | đừng gỡ cho tới khi đã xoay vòng khoá |

Thấy policy này là bằng chứng chắc chắn khoá đã ra ngoài — không cần phỏng đoán gì thêm.

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

• B. Để hạn chế truy cập khi access key bị xâm nhập, có thể vô hiệu hoá hoặc xoá khoá. Lưu ý một IAM principal có thể có tới NĂM access key cùng lúc — đây là phương án gần nhất và sai ở con số: giới hạn là HAI access key mỗi IAM user. (Phần đầu của phát biểu đúng, nhưng con số sai làm cả mệnh đề sai.)
• D. Nếu không tắt được EC2 instance bị lộ, chuyển nó sang một Isolation VPC — không thực hiện được: EC2 instance không di chuyển được giữa các VPC. Cách cách ly đúng là gắn một security group cách ly (xem câu #7796) hoặc dùng NACL.
• E. Không cần thu hồi bất kỳ thông tin đăng nhập IAM tạm thời nào — sai và nguy hiểm: vô hiệu hoá access key không thu hồi token STS đã được cấp từ nó — chúng còn hiệu lực tới 12 giờ. Phải thu hồi tường minh.

Ghi nhớ

Cách thu hồi token STS — thao tác mà phương án E phủ nhận:

{"Effect": "Deny", "Action": "*", "Resource": "*",
 "Condition": {"DateLessThan": {"aws:TokenIssueTime": "2026-08-30T12:00:00Z"}}}

Không thu hồi từng token được — phải gắn inline policy từ chối mọi hành động với token cấp trước một thời điểm. Console IAM có nút "Revoke active sessions" làm đúng việc này.

Giới hạn IAM cần thuộc: | Đối tượng | Giới hạn | |---|---| | Access key mỗi IAM user | 2 | | IAM user mỗi tài khoản | 5.000 | | IAM role mỗi tài khoản | 1.000 | | Managed policy gắn cho một entity | 10 (tăng được tới 20) | | Group mỗi user | 10 |

Con số 2 tồn tại chính là để hỗ trợ xoay vòng — tạo khoá thứ hai, chuyển ứng dụng sang, rồi xoá khoá cũ.

Quy trình ứng phó khi thông tin đăng nhập bị lộ:

① Tạo khoá mới, chuyển ứng dụng sang
② VÔ HIỆU HOÁ khoá cũ (Inactive, chưa xoá)
③ Thu hồi token STS đang còn hiệu lực
④ Rà CloudTrail ở MỌI Region
⑤ Snapshot trước khi terminate tài nguyên nghi ngờ
⑥ Xoá tài nguyên trái phép, xoá IAM entity lạ
⑦ Xoá khoá cũ sau khi xác nhận ổn định
⑧ Gỡ AWSExposedCredentialPolicy sau khi hoàn tất

Nguyên tắc pháp chứng khi xử lý instance nghi bị xâm nhập: | Nên | Không nên | |---|---| | Cách ly bằng security group | tắt máy — MẤT bằng chứng trong RAM | | Snapshot EBS trước khi terminate | terminate ngay | | Gỡ instance profile / thu hồi phiên | xoá IAM role (ảnh hưởng máy khác) | | Chụp dump bộ nhớ nếu có công cụ | |

Ba biện pháp ngăn tái diễn: | Biện pháp | Hiệu quả | |---|---| | Dùng IAM role thay access key dài hạn | không có gì để rò rỉ | | IAM Identity Center cho người dùng | thông tin đăng nhập tạm thời | | Quét bí mật trong mã nguồn | git-secrets, GitHub secret scanning |

Và một chi tiết về policy của AWS: hiện nay AWS dùng tên AWSCompromisedKeyQuarantineV3 cho cùng cơ chế. Dù tên có thay đổi, ý nghĩa không đổi — sự xuất hiện của nó nghĩa là AWS đã xác nhận khoá của bạn bị lộ, và bạn nên bắt đầu quy trình ở trên ngay lập tức thay vì chờ điều tra thêm.

Đáp án

D — Thu hồi mọi phiên đang hoạt động của IAM role. Cập nhật bucket policy để từ chối truy cập cho role đó. Gỡ IAM role khỏi instance profile của EC2.

Vì sao đúng

Đề nêu ràng buộc quan trọng: instance chạy ứng dụng quan trọng và không thể terminate ngay, nên phải chặn truy cập dữ liệu nhạy cảm bằng cách nhanh nhất.

Ba bước trong đáp án bịt ba đường khác nhau, và thứ tự có ý nghĩa:

① Thu hồi phiên đang hoạt động
   → token STS đã cấp cho instance có thể còn sống tới 6 giờ
   → GỠ ROLE KHÔNG LÀM CHÚNG HẾT HẠN

② Deny trong bucket policy
   → chặn NGAY ở phía tài nguyên
   → explicit Deny thắng mọi Allow, kể cả token còn hiệu lực

③ Gỡ role khỏi instance profile
   → ngăn instance lấy thông tin đăng nhập MỚI

Bước ① là điểm phân biệt quyết định — và là hiểu lầm phổ biến nhất:

Gỡ IAM role khỏi instance profile
    → instance KHÔNG lấy được thông tin đăng nhập MỚI
    → NHƯNG token đang giữ trong bộ nhớ vẫn dùng được tới khi hết hạn
    → kẻ tấn công đã lấy token về máy của họ vẫn dùng được

Cách thu hồi:

{
  "Effect": "Deny",
  "Action": "*",
  "Resource": "*",
  "Condition": {"DateLessThan": {"aws:TokenIssueTime": "2026-08-30T12:00:00Z"}}
}

Console IAM có nút "Revoke active sessions" gắn đúng inline policy này.

Và bước ② cho hiệu quả tức thì ở phía dữ liệu:

{"Effect": "Deny", "Principal": {"AWS": "arn:aws:iam::111122223333:role/role-ung-dung"},
 "Action": "s3:*", "Resource": ["arn:aws:s3:::du-lieu-nhay-cam",
                                 "arn:aws:s3:::du-lieu-nhay-cam/*"]}

Explicit Deny thắng tuyệt đối — kể cả token còn hiệu lực cũng không đọc được nữa.

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

• A. Cập nhật bucket policy từ chối role; gỡ role khỏi instance profile; dùng S3 Access Points để tạo bộ quyền giới hạn truy cập trong mạng riêng — đây là phương án gần nhất và có hai bước đúng, nhưng nó thiếu bước thu hồi phiên — chính là bước quan trọng nhất về mặt thời gian. Và dựng Access Point là việc tái cấu trúc dài hạn, không phải phản ứng khẩn cấp.
• C. Cập nhật bucket policy từ chối role; tạo EBS snapshot của instance và TERMINATE instance — trái thẳng ràng buộc của đề: instance chạy ứng dụng quan trọng và không thể terminate ngay. (Snapshot trước khi terminate là nguyên tắc đúng — nhưng không áp dụng được ở đây.)
• B. Gỡ role khỏi instance profile; chặn mọi truy cập công khai vào bucket; dùng pre-signed URL để cho phép thực thể tin cậy bên ngoài truy cập — không giải quyết vấn đề: bucket đâu có bị truy cập công khai — nó bị truy cập bởi một role hợp lệ trên instance bị xâm nhập. Block Public Access không chặn được điều đó. Và cấp pre-signed URL là mở thêm đường, không phải đóng bớt.

Ghi nhớ

Ba đường truy cập cần bịt khi instance có IAM role bị xâm nhập: | Đường | Cách bịt | |---|---| | Token đã cấp, còn hiệu lực | thu hồi phiên (aws:TokenIssueTime) | | Lấy token mới qua IMDS | gỡ instance profile | | Truy cập từ phía tài nguyên | explicit Deny trong resource policy |

Bịt cả ba mới an toàn — bỏ sót đường nào cũng để lại cửa.

Vòng đời thông tin đăng nhập từ instance profile:

SSM/IMDS cấp token   → hiệu lực ~6 giờ
Tự động làm mới       → khoảng 5 phút trước khi hết hạn
Gỡ instance profile   → không làm mới được nữa
                      → nhưng token HIỆN TẠI vẫn sống tới hết hạn

Ba cách thu hồi quyền của một role — theo tốc độ có hiệu lực: | Cách | Hiệu lực | |---|---| | Explicit Deny trong resource policy | TỨC THÌ | | Revoke active sessions (inline policy) | TỨC THÌ | | Gỡ instance profile | tức thì cho token mới, không ảnh hưởng token cũ | | Xoá role | tức thì, nhưng ảnh hưởng mọi nơi dùng role đó |

Hai dòng đầu là công cụ ứng phó khẩn cấp — chúng có hiệu lực ngay lập tức trên toàn bộ AWS.

Quy trình xử lý instance bị xâm nhập mà không được dừng:

① Cách ly mạng      → gắn security group cách ly (KHÔNG xoá rule SG đang dùng chung)
② Thu hồi quyền     → revoke sessions + Deny trong resource policy
③ Ngắt nguồn token  → gỡ instance profile
④ Giữ bằng chứng    → snapshot EBS, chụp RAM nếu có công cụ
⑤ Điều tra          → CloudTrail xem role đã gọi API gì
⑥ Khôi phục         → dựng instance mới từ AMI sạch, chuyển tải sang

Bước ⑤ đặc biệt quan trọng: role của instance có thể đã được dùng để chạm tới tài nguyên khác ngoài bucket này — phạm vi sự cố thường rộng hơn chỗ phát hiện đầu tiên.

Và một biện pháp phòng ngừa liên quan trực tiếp: giới hạn quyền của instance role bằng Resource cụ thể và điều kiện aws:SourceVpce (xem câu #7734). Khi đó, ngay cả khi kẻ tấn công lấy được token về máy của họ, token đó không dùng được từ ngoài VPC — biến một sự cố nghiêm trọng thành một sự cố hạn chế.

Đáp án

B, C và D:

• D — Xác nhận dịch vụ EC2Launch v2 đang chạy. Tháo EBS root volume khỏi instance
• B — Khởi chạy một instance tạm và gắn volume đó làm volume phụ. Xoá tệp .run-once tại %ProgramData%/Amazon/EC2Launch/state/.run-once
• C — Gắn lại volume vào instance gốc làm root volume, kết nối bằng key pair để lấy mật khẩu administrator

Vì sao đúng

Đề hỏi quy trình đặt lại mật khẩu Windows bằng EC2Launch v2 — và ba bước này là quy trình chính thức của AWS.

Cơ chế đằng sau: tệp .run-once là cờ đánh dấu "đã khởi tạo xong".

Lần khởi động ĐẦU TIÊN của instance Windows:
    EC2Launch v2 chạy các tác vụ khởi tạo
        → sinh mật khẩu administrator ngẫu nhiên
        → mã hoá bằng PUBLIC KEY của key pair
        → ghi vào console output
    → tạo tệp .run-once để không chạy lại

Xoá .run-once:
    → EC2Launch v2 tưởng đây là lần khởi động đầu tiên
    → SINH LẠI mật khẩu mới
    → mã hoá bằng key pair → bạn giải mã được bằng private key

Vì sao phải tháo volume ra và gắn sang máy khác: bạn không đăng nhập được vào máy gốc (đó chính là vấn đề), nên không xoá tệp đó tại chỗ được. Gắn volume làm ổ phụ ở máy khác cho phép thao tác trên hệ thống tệp của nó.

Quy trình đầy đủ theo thứ tự:

① Dừng instance gốc, xác nhận EC2Launch v2 có chạy      ← D
② Tháo root volume
③ Gắn volume vào instance tạm làm ổ PHỤ                 ← B
④ Xoá %ProgramData%/Amazon/EC2Launch/state/.run-once    ← B
⑤ Tháo khỏi instance tạm, gắn lại vào instance gốc
   làm ROOT volume (/dev/sda1 hoặc xvda)                 ← C
⑥ Khởi động instance gốc → mật khẩu mới được sinh
⑦ Lấy mật khẩu bằng private key của key pair            ← C

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

• F. Khi khởi chạy instance tạm, để tránh xung đột chữ ký đĩa (disk signature collision), bạn phải chọn AMI cho CÙNG phiên bản Windows — đây là phương án gần nhất và sai ngược hoàn toàn: tài liệu AWS nêu rõ phải chọn AMI cho một PHIÊN BẢN WINDOWS KHÁC. Hai đĩa cùng phiên bản có cùng chữ ký, và Windows sẽ đưa một trong hai vào trạng thái offline.
• A. Chọn Offline Instance Option → Diagnose and Rescue → Reset Administrator Password; gắn lại volume và khởi động lại — đó là quy trình của công cụ EC2Rescue for Windows Server, không phải EC2Launch v2. Đề hỏi cụ thể về EC2Launch v2.
• E. Tải EC2Rescue for Windows Server, giải nén và chạy EC2Rescue.exe — cùng vấn đề: đây là một công cụ khác. (EC2Rescue là giải pháp hợp lệ cho bài toán này, nhưng không phải quy trình EC2Launch v2 mà đề hỏi.)

Ghi nhớ

Ba thế hệ agent khởi tạo Windows trên EC2: | Agent | Phiên bản Windows | Tệp đánh dấu | |---|---|---| | EC2Config | Server 2012 R2 trở về trước | Ec2ConfigService | | EC2Launch v1 | Server 2016, 2019 | Ec2Launch (PowerShell) | | EC2Launch v2 | Server 2022 và AMI mới | .run-once ← câu này |

Quy trình đặt lại mật khẩu khác nhau cho từng thế hệ — nên câu hỏi luôn nêu rõ agent nào.

Cảnh báo về xung đột chữ ký đĩa — chi tiết quan trọng nhất:

Gắn hai volume Windows CÙNG phiên bản vào một instance
    → cùng disk signature
    → Windows đưa volume thứ hai vào OFFLINE
    → không thao tác được với tệp trên đó

Cách tránh: instance tạm phải dùng phiên bản Windows KHÁC với volume cần sửa.

(Nếu bắt buộc dùng cùng phiên bản, có thể đưa đĩa online thủ công bằng diskpart và đổi chữ ký — nhưng chọn phiên bản khác đơn giản hơn nhiều.)

Ba cách đặt lại mật khẩu Windows trên EC2: | Cách | Đặc điểm | |---|---| | Xoá .run-once (EC2Launch v2) | thủ công, cần instance tạm ← câu này | | EC2Rescue for Windows Server | công cụ chuyên dụng, có giao diện | | SSM Automation AWSSupport-ResetAccess | TỰ ĐỘNG HOÁ TOÀN BỘ — ít công nhất |

Dòng cuối đáng biết cho thực tế: nếu instance là managed instance của Systems Manager, chạy một document là xong — không cần tháo lắp volume gì cả:

aws ssm start-automation-execution   --document-name AWSSupport-ResetAccess   --parameters "InstanceId=i-0abc123"

Cách lấy mật khẩu administrator sau khi sinh lại:

aws ec2 get-password-data --instance-id i-0abc123   --priv-launch-key ~/khoa-cua-toi.pem

Mật khẩu được mã hoá bằng public key của key pair — mất private key thì không giải mã được, và quy trình này cũng vô nghĩa.

Ba biện pháp tránh rơi vào tình huống này: | Biện pháp | Lợi ích | |---|---| | Dùng Systems Manager Session Manager | không cần mật khẩu, không cần RDP mở | | Nối instance vào AWS Managed Microsoft AD | đăng nhập bằng tài khoản domain | | Lưu private key ở nơi an toàn có sao lưu | mất private key là mất cả đường này |

Dòng đầu là giải pháp gốc rễ: Session Manager hỗ trợ Windows, cho phép mở phiên PowerShell mà không cần mật khẩu, không mở cổng 3389, và có ghi log toàn bộ phiên. Dùng nó thì mất mật khẩu administrator không còn là sự cố chặn đường nữa.

Đáp án

B — Nếu tuỳ chọn "auto remediate any non-compliant resources" KHÔNG được bật, thì web ACL do Firewall Manager tạo sẽ không được gắn vào các tài nguyên trong phạm vi.

Vì sao đúng

Đề mô tả triệu chứng: web ACL đã được tạo nhưng không gắn được vào tài nguyên trong phạm vi.

Nguyên nhân nằm ở chế độ hoạt động của Firewall Manager policy:

Auto remediation TẮT (mặc định):
  Firewall Manager TẠO web ACL
      → PHÁT HIỆN tài nguyên nào chưa được bảo vệ
      → BÁO CÁO chúng là non-compliant
      → KHÔNG tự gắn web ACL vào chúng     ← triệu chứng của đề

Auto remediation BẬT:
  Firewall Manager TẠO web ACL
      → TỰ ĐỘNG gắn vào mọi tài nguyên trong phạm vi

Đây là thiết kế có chủ đích, không phải lỗi: | Chế độ | Vai trò | |---|---| | Tắt | chế độ QUAN SÁT — xem policy sẽ ảnh hưởng những gì | | Bật | chế độ THỰC THI — tự động áp bảo vệ |

Vì sao AWS mặc định để tắt: gắn một web ACL vào tài nguyên sản xuất có thể chặn lưu lượng hợp lệ nếu rule chưa được kiểm chứng. Chế độ quan sát cho bạn thấy phạm vi ảnh hưởng trước khi cam kết.

Cách bật:

aws fms put-policy --policy '{
  "PolicyName": "waf-toan-to-chuc",
  "RemediationEnabled": true,
  "ResourceType": "AWS::ElasticLoadBalancingV2::LoadBalancer",
  ...
}'

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

• C. Nếu CHỈ bật "auto remediate", Firewall Manager gắn web ACL vào mọi tài nguyên non-compliant BẤT KỂ nó đã có web ACL hay chưa — đây là phương án gần nhất và sai ở vế "bất kể": khi chỉ bật auto remediation, Firewall Manager chỉ gắn cho tài nguyên CHƯA CÓ web ACL nào. Muốn thay thế web ACL đang có thì phải bật thêm tuỳ chọn thứ hai.
• A. Nếu bật cả auto remediate lẫn "Replace web ACLs..." và tài nguyên đã có web ACL do chính Firewall Manager WAF policy tạo, thì nó bị thay thế — mô tả một hành vi không phải nguyên nhân của lỗi, và Firewall Manager không thay thế web ACL do chính một policy khác của nó quản lý theo cách này.
• D. Nếu bật cả hai tuỳ chọn và tài nguyên có web ACL do AWS Shield Advanced policy tạo, thì không thay thế được — đây là một chi tiết về thứ tự ưu tiên giữa các loại policy, không giải thích được triệu chứng của đề (web ACL không gắn được vào bất kỳ tài nguyên nào).

Ghi nhớ

Hai tuỳ chọn khắc phục của Firewall Manager WAF policy: | Tuỳ chọn | Việc | |---|---| | RemediationEnabled | có tự động gắn web ACL không | | "Replace web ACLs currently associated" | có ghi đè web ACL đang có sẵn không |

Ma trận hành vi: | Remediation | Replace | Tài nguyên CHƯA có web ACL | Tài nguyên ĐÃ có web ACL | |---|---|---|---| | Tắt | — | chỉ báo cáo | chỉ báo cáo | | Bật | Tắt | được gắn | giữ nguyên web ACL cũ | | Bật | Bật | được gắn | bị THAY THẾ |

Bảng này giải thích cả B lẫn C — và là thứ đáng thuộc khi triển khai Firewall Manager.

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. Config chưa bật thì policy không thấy tài nguyên nào cả, và triệu chứng cũng là "không gắn được".

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, content audit, usage audit | | 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 đối tác |

Danh sách kiểm tra khi Firewall Manager policy không áp dụng được:

① RemediationEnabled đã bật chưa?               ← nguyên nhân của câu này
② AWS Config đã bật ở tài khoản và Region đó chưa?
③ Tài khoản có nằm trong phạm vi policy không?  (OU, tag, danh sách tài khoản)
④ Loại tài nguyên có khớp ResourceType không?
⑤ Tài nguyên có web ACL khác và Replace chưa bật?
⑥ Firewall Manager admin account có quyền đủ không?

Ba cách xác định phạm vi policy: | Cách | Chi tiết | |---|---| | Toàn bộ tổ chức | mọi tài khoản | | Theo OU | chỉ các OU được chọn | | Theo tag của tài nguyên | include hoặc exclude theo tag |

Lọc theo tag rất hữu ích cho triển khai từng bước: gắn tag fms-managed=true cho một nhóm tài nguyên thử nghiệm, áp policy cho nhóm đó trước, rồi mở rộng dần — an toàn hơn nhiều so với bật cho cả tổ chức ngay lần đầu.

Và nhớ hành vi khi tài nguyên rời khỏi phạm vi: Config rule do policy tạo bị xoá, và web ACL rỗng cũng bị xoá — nhưng security group đã sao chép thì KHÔNG tự gỡ (xem câu #7742).

Đáp án

B và E.

• B — Khi Owner tải object lên, sự kiện xảy ra trong tài khoản Owner và khớp cấu hình trail của Owner. Trail đó xử lý và ghi log trong tài khoản Owner
• E — Khi Bob tải object lên, sự kiện xảy ra trong tài khoản Bob và khớp cấu hình trail của Bob. Trail của Bob ghi log. Cấu hình trail của Owner CŨNG khớp, nên sự kiện cũng được ghi trong trail của Owner

Vì sao đúng

Đề dựng một tình huống chéo tài khoản chính xác, và đáp án phản ánh quy tắc bất đối xứng của CloudTrail data event.

Hai quy tắc quyết định:

① NGƯỜI GỌI API nhận log trong trail của mình
② CHỦ SỞ HỮU BUCKET nhận log cho MỌI thao tác trên bucket của mình,
   kể cả khi người gọi ở tài khoản khác

Áp vào hai sự kiện của đề: | Sự kiện | Trail của Bob | Trail của Owner | |---|---|---| | Bob tải lên | ✅ (Bob là người gọi) | ✅ (Owner là chủ bucket) | | Owner tải lên | ❌ (Bob không phải người gọi, cũng không phải chủ bucket) | ✅ (vừa là người gọi vừa là chủ) |

Sự bất đối xứng là điểm cốt lõi: Owner thấy mọi thứ xảy ra với bucket của mình; Bob chỉ thấy những gì chính anh ta làm.

Vì sao thiết kế như vậy hợp lý: chủ sở hữu tài nguyên cần khả năng kiểm toán đầy đủ tài nguyên của mình — nếu không, một tài khoản bên ngoài có quyền ghi có thể hoạt động mà chủ bucket không hề biết. Ngược lại, Bob không có lý do gì để thấy hoạt động của Owner.

Và điều kiện để cả hai cùng ghi log: cả hai đều phải bật data event cho bucket đó với prefix khớp. Đề nói rõ cả hai đều cấu hình với empty object prefix — tức là khớp mọi object.

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

• A. Khi Bob tải lên, trail của Bob ghi log. Cấu hình trail của Owner KHÔNG khớp nên không được ghi — đây là phương án gần nhất và mâu thuẫn trực tiếp với E: chủ bucket luôn nhận được log cho thao tác trên bucket của mình.
• D. Khi Owner tải lên, trail của Owner ghi log. Sự kiện cũng khớp cấu hình trail của Bob nên trail của Bob cũng ghi — sai chiều bất đối xứng: Bob không phải người gọi và không phải chủ bucket, nên không có cơ sở nào để trail của anh ta ghi sự kiện đó.
• C. Trong cả hai sự kiện, log chỉ được ghi trong tài khoản của người tải lên — bỏ qua hoàn toàn quy tắc chủ sở hữu bucket: nó phủ nhận việc Owner nhận log khi Bob tải lên.

Ghi nhớ

Quy tắc ghi data event của S3 trong CloudTrail:

Người gọi API        → nhận log trong trail của MÌNH
Chủ sở hữu bucket    → nhận log cho MỌI thao tác trên bucket của mình

Khi cả hai là một (Owner tự tải lên), chỉ có một trail ghi — vì chỉ có một tài khoản liên quan.

Ba loại sự kiện của CloudTrail: | Loại | Ví dụ | Mặc định | |---|---|---| | Management event | CreateBucket, PutBucketPolicy | BẬT | | Data event | PutObject, GetObject, DeleteObject | TẮT | | Insights event | bất thường về khối lượng API | TẮT |

Data event phải bật tường minh và tính phí theo số sự kiện — nên với bucket lưu lượng cao, cân nhắc: | Tối ưu | Chi tiết | |---|---| | ReadWriteType: WriteOnly | cắt phần lớn khối lượng nếu chỉ cần theo dõi thay đổi | | Giới hạn theo prefix | chỉ giám sát thư mục nhạy cảm | | Chỉ bật cho bucket cần thiết | không bật cho mọi bucket |

Cấu hình data event cho một prefix cụ thể:

aws cloudtrail put-event-selectors --trail-name trail-bao-mat   --event-selectors '[{
    "ReadWriteType": "WriteOnly",
    "IncludeManagementEvents": true,
    "DataResources": [{
      "Type": "AWS::S3::Object",
      "Values": ["arn:aws:s3:::kho-nhay-cam/ho-so/"]
    }]}]'

Empty prefix (arn:aws:s3:::bucket/) khớp MỌI object — đúng như tình huống trong đề.

Hai loại data event hay dùng khác: | Dịch vụ | Data event | |---|---| | Lambda | Invoke | | DynamoDB | PutItem, GetItem, Query | | S3 Express, EBS Direct API | các thao tác tương ứng |

Hệ quả thực tế của quy tắc bất đối xứng — điều đáng nhớ nhất từ câu này:

Nếu bạn cho tài khoản khác quyền ghi vào bucket của mình, hãy BẬT data event. Đó là cách duy nhất để biết họ đã làm gì với dữ liệu của bạn.

Ba biện pháp kiểm soát khi chia sẻ bucket với tài khoản ngoài: | Biện pháp | Lợi ích | |---|---| | Data event của CloudTrail | thấy mọi thao tác trên object ← câu này | | BucketOwnerEnforced | bạn sở hữu mọi object, kể cả do người khác ghi | | Điều kiện aws:PrincipalOrgID | chỉ tài khoản trong tổ chức truy cập được |

Dòng giữa giải quyết một vấn đề kinh điển: với thiết lập cũ (ObjectWriter), tài khoản A ghi object vào bucket của B, và B không đọc được object trong chính bucket của mình — vì A là chủ object. BucketOwnerEnforced là mặc định cho bucket tạo mới và loại bỏ hẳn vấn đề đó.

Và một lưu ý về chi phí trong tình huống của đề: cả Owner lẫn Bob đều bị tính phí data event cho cùng những sự kiện đó — mỗi bên trả cho trail của mình. Đó là điều đáng biết trước khi cả hai cùng bật giám sát toàn bộ một bucket có lưu lượng lớn.