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

Tìm thấy 445 câu.

Câu 131 Chọn nhiều đáp án Security Logging and Monitoring

For auditing purposes, a company needs to showcase a report of changes made to the security group(s) for an Amazon Virtual Private Cloud (Amazon VPC).

What are the different ways to review security group changes in an AWS account? (Select three)

  1. A

    Use CloudTrail Lake to create trails that aggregate information from multiple AWS accounts across regions
  2. B

    Use AWS AppConfig capability of AWS Systems Manager, to create, manage, and quickly deploy application configurations and track changes in them
  3. C

    Create an AWS CloudTrail trail configured to log to an Amazon Simple Storage Service (Amazon S3) bucket. Use Athena to query CloudTrail Logs over the last 30-45 days
  4. D

    Use AWS CloudTrail Event history to review security group changes in your AWS account
  5. E

    Configure CloudTrail with CloudWatch Logs to monitor your trail logs and be notified when security group changes occur. CloudTrail supports sending only data events to CloudWatch Logs. Configure Amazon EventBridge to monitor management events
  6. F

    Use AWS Config to view configuration history for security groups. You must have the AWS Config configuration recorder turned on
Xem giải thích

Đáp án

C, D và F:

  • D — Dùng CloudTrail Event history để xem các thay đổi security group
  • C — Tạo CloudTrail trail ghi vào S3; dùng Athena truy vấn log trong 30–45 ngày gần nhất
  • F — Dùng AWS Config xem lịch sử cấu hình của security group; phải bật configuration recorder

Vì sao đúng

Đề hỏi các cách khác nhau để rà soát thay đổi security group — và ba đáp án là ba công cụ thật, mỗi cái phục vụ một khoảng thời gian và mục đích khác nhau.

D — Event history: nhanh nhất, không cần cấu hình gì:

CloudTrail Event history:
    → BẬT SẴN cho mọi tài khoản, MIỄN PHÍ
    → giữ 90 NGÀY gần nhất
    → lọc theo Event name: AuthorizeSecurityGroupIngress, RevokeSecurityGroupIngress...

Đây là nơi đầu tiên nên nhìn cho một câu hỏi kiểm toán đơn giản.

C — trail + S3 + Athena: cho lưu trữ dài hạn và truy vấn phức tạp:

SELECT eventtime, useridentity.arn, eventname,
       requestparameters
FROM cloudtrail_logs
WHERE eventname LIKE '%SecurityGroup%'
  AND eventtime > '2026-07-01'
ORDER BY eventtime DESC;

Event history chỉ giữ 90 ngày — muốn giữ lâu hơn thì phải có trail ghi vào S3.

F — AWS Config: trả lời loại câu hỏi khác hẳn hai cái trên: | Công cụ | Trả lời | |---|---| | CloudTrail | "AI đã thay đổi, KHI NÀO?" | | AWS Config | "Security group này TRÔNG NHƯ THẾ NÀO vào ngày X?" |

Config lưu ảnh chụp cấu hình đầy đủ theo thời gian — nên nó dựng lại được trạng thái của một security group tại bất kỳ thời điểm nào, và so sánh được hai phiên bản. CloudTrail chỉ có bản ghi từng thao tác riêng lẻ.

Và vế "phải bật configuration recorder" là điều kiện thật: Config không ghi gì nếu recorder chưa chạy, và không dựng lại được quá khứ trước lúc bật.

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

  • A. Dùng CloudTrail Lake để tạo TRAIL tổng hợp thông tin từ nhiều tài khoản và Region — đây là phương án gần nhất và CloudTrail Lake là công cụ có thật và phù hợp, nhưng nó dùng sai thuật ngữ: CloudTrail Lake làm việc với event data store, không phải "trail". Đó là hai khái niệm khác nhau trong cùng dịch vụ.
  • E. Cấu hình CloudTrail với CloudWatch Logs để giám sát và nhận thông báo; CloudTrail chỉ hỗ trợ gửi DATA EVENT sang CloudWatch Logs; cấu hình EventBridge để giám sát management event — sai sự thật: CloudTrail gửi cả management event lẫn data event sang CloudWatch Logs. Và thay đổi security group là management event — nên mệnh đề này còn tự mâu thuẫn với chính giải pháp nó đề xuất.
  • B. Dùng AWS AppConfig của Systems Manager để tạo, quản lý và triển khai cấu hình ứng dụng và theo dõi thay đổi — nhầm dịch vụ hoàn toàn: AppConfig quản lý cấu hình của ỨNG DỤNG của bạn (feature flag, tham số vận hành). Nó không liên quan tới cấu hình tài nguyên AWS.

Ghi nhớ

Bốn cách xem lịch sử thay đổi trên AWS — bảng phân biệt: | Cách | Khoảng thời gian | Chi phí | Trả lời | |---|---|---|---| | CloudTrail Event history | 90 ngày | miễn phí | ai làm gì | | Trail → S3 → Athena | tuỳ bạn giữ | phí lưu trữ + truy vấn | ai làm gì, dài hạn | | CloudTrail Lake | tới 10 năm | phí nạp + truy vấn | ai làm gì, SQL sẵn | | AWS Config | từ lúc bật recorder | phí theo configuration item | tài nguyên TRÔNG THẾ NÀO |

CloudTrail Lake đáng biết thêm (dù phương án A mô tả sai thuật ngữ): nó là kho dữ liệu được quản lý cho phép truy vấn SQL trực tiếp mà không cần dựng Athena, Glue hay S3 — và tổng hợp được nhiều tài khoản, nhiều Region vào một event data store.

Các sự kiện CloudTrail cho 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 — cũng đáng theo dõi | | RevokeSecurityGroupEgress | xoá rule ra | | CreateSecurityGroup, DeleteSecurityGroup | tạo/xoá | | ModifySecurityGroupRules | sửa rule |

Đừng chỉ theo dõi việc THÊM rule — xoá một rule cũng có thể phá vỡ kiểm soát an ninh đang có.

Ba khả năng của AWS Config cho câu hỏi này: | Khả năng | Chi tiết | |---|---| | Configuration history | ảnh chụp cấu hình theo thời gian | | Configuration timeline trong Console | xem trực quan thay đổi qua các mốc | | Config rule | đánh giá tuân thủ liên tục |

Timeline của Config là công cụ mạnh cho kiểm toán: nó hiện từng thay đổi kèm diff giữa hai phiên bản — bạn thấy chính xác rule nào được thêm hay bớt, không phải tự dựng lại từ log.

Ba cách giám sát chủ động (thay vì rà soát sau): | Cách | Đặc điểm | |---|---| | CloudTrail + metric filter + alarm | cảnh báo theo ngưỡng | | EventBridge rule | phản ứng NGAY từng sự kiện | | Config rule + auto remediation | tự động gỡ rule vi phạm |

Dòng cuối mạnh nhất cho rule nguy hiểm rõ ràng — ví dụ managed rule restricted-ssh phát hiện security group mở cổng 22 ra 0.0.0.0/0, và remediation action tự gỡ rule đó trong vài giây.

Và một lưu ý về Config: nó tính phí theo số configuration item được ghi. Ghi mọi loại tài nguyên trong môi trường lớn có thể tốn đáng kể — nên cân nhắc giới hạn loại tài nguyên cần ghi thay vì bật "record all resources", trừ khi có yêu cầu tuân thủ đòi hỏi.

Câu 132 Chọn nhiều đáp án Security Logging and Monitoring

A company manages separate AWS accounts for each of its business units. An enhanced monitoring solution has been proposed by the security team that mandates tracking all the API calls using CloudTrail for all the AWS accounts. The centralized monitoring logs will be available in a new AWS account created for security and audit purposes. Logs of one business unit should be distinguishable from others via its own top-level prefix. Also, any updates to the log files should be traceable.

As a Security Engineer, which of the following options will you combine to implement this requirement? (Select two)

  1. A

    Apply a bucket policy to the new centralized S3 bucket that permits the CloudTrail service to use the s3 PutObject action and the s3 GetBucketACL action, and specify the appropriate resource ARNs for the CloudTrail trails
  2. B

    Create a new Amazon S3 bucket in the centralized account to store all the CloudTrail log files. Enable log file validation on all Trails in all AWS accounts including the centralized account. Use unique log file prefixes for trails in each AWS account
  3. C

    Create a new Amazon S3 bucket in each of the AWS accounts. Use S3 bucket replication to copy the CloudTrail logs to the S3 bucket in the centralized account. Enable log file validation on all Trails in all of the AWS accounts used. Use unique log file prefixes for trails in each AWS account
  4. D

    Apply a bucket policy to all S3 buckets to permit the CloudTrail service to use the s3 PutObject action, s3 GetObjectAcl action, and the s3 GetObject action. Specify the appropriate resource ARNs for the CloudTrail trails
  5. E

    Create a new Amazon S3 bucket in the centralized account to store all the CloudTrail log files. Enable log file validation on all Trails in AWS accounts of all business units. Use unique log file prefixes for trails in each AWS account
Xem giải thích

Đáp án

A và E.

  • E — Tạo một S3 bucket mới ở tài khoản tập trung để lưu mọi tệp log CloudTrail. Bật log file validation trên mọi trail ở các tài khoản của đơn vị kinh doanh. Dùng prefix riêng cho trail của từng tài khoản
  • A — Gắn bucket policy cho bucket tập trung, cho phép dịch vụ CloudTrail dùng hành động s3:PutObject và s3:GetBucketAcl, và khai đúng resource ARN cho các trail

Vì sao đúng

Đề nêu ba yêu cầu, và cặp E+A đáp ứng cả ba: | Yêu cầu | Cơ chế | |---|---| | Log tập trung ở một tài khoản audit | một bucket S3 duy nhất | | Phân biệt được đơn vị kinh doanh | prefix riêng cho từng tài khoản | | Mọi cập nhật vào tệp log phải truy vết được | log file validation |

A — hai action là chính xác những gì CloudTrail cần, không hơn không kém:

[
  {
    "Sid": "AWSCloudTrailAclCheck",
    "Effect": "Allow",
    "Principal": {"Service": "cloudtrail.amazonaws.com"},
    "Action": "s3:GetBucketAcl",
    "Resource": "arn:aws:s3:::log-tap-trung"
  },
  {
    "Sid": "AWSCloudTrailWrite",
    "Effect": "Allow",
    "Principal": {"Service": "cloudtrail.amazonaws.com"},
    "Action": "s3:PutObject",
    "Resource": "arn:aws:s3:::log-tap-trung/don-vi-a/AWSLogs/111122223333/*",
    "Condition": {"StringEquals": {"s3:x-amz-acl": "bucket-owner-full-control"}}
  }
]
Action Vì sao cần
s3:GetBucketAcl CloudTrail kiểm tra bucket tồn tại và có quyền — lúc TẠO trail
s3:PutObject ghi tệp log

Và s3:GetObject KHÔNG cần — CloudTrail chỉ ghi, không đọc lại. Đây là điểm loại của phương án D.

E — log file validation cho vế "traceable":

CloudTrail tạo file DIGEST mỗi giờ
    → chứa hash SHA-256 của mọi tệp log trong giờ đó
    → digest được KÝ SỐ bằng khoá riêng của CloudTrail
    → mỗi digest tham chiếu ngược tới digest TRƯỚC ĐÓ (chuỗi liên kết)

Chuỗi liên kết là điểm mạnh: xoá cả một tệp log lẫn digest của nó vẫn bị phát hiện, vì digest kế tiếp trỏ vào cái đã mất.

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

  • B. Tạo bucket mới ở tài khoản tập trung; bật log file validation trên mọi trail ở TẤT CẢ tài khoản, BAO GỒM cả tài khoản tập trung; dùng prefix riêng — đây là phương án gần nhất và gần như giống hệt E, chỉ khác ở phạm vi: nó thêm cả tài khoản tập trung. (Xem ghi chú cuối bài — đây là một phân biệt yếu.)
  • D. Gắn bucket policy cho MỌI bucket S3 cho phép CloudTrail dùng s3:PutObject, s3:GetObjectAcl và s3:GetObject — sai action: CloudTrail cần s3:GetBucketAcl (quyền trên BUCKET), không phải s3:GetObjectAcl (quyền trên OBJECT). Và s3:GetObject là thừa — cấp quyền đọc cho dịch vụ không cần đọc là vi phạm đặc quyền tối thiểu.
  • C. Tạo bucket ở TỪNG tài khoản; dùng S3 bucket replication sao chép log sang bucket tập trung — phức tạp không cần thiết: CloudTrail ghi thẳng chéo tài khoản được. Thêm một tầng replication làm tăng chi phí, tăng độ trễ, và tạo thêm chỗ hỏng — trong khi log vẫn tồn tại ở tài khoản gốc nơi có thể bị xoá.

Ghi nhớ

Ba statement cần có trong bucket policy cho CloudTrail: | Sid | Action | Resource | |---|---|---| | AWSCloudTrailAclCheck | s3:GetBucketAcl | arn:aws:s3:::bucket (không có /*) | | AWSCloudTrailWrite | s3:PutObject | arn:aws:s3:::bucket/prefix/AWSLogs/<account-id>/* | | (điều kiện) | s3:x-amz-acl = bucket-owner-full-control | |

Chú ý sự khác nhau ở Resource: statement đầu trỏ vào bucket, statement sau trỏ vào object có prefix cụ thể. Nhầm chỗ này là lỗi cấu hình phổ biến.

Cấu trúc đường dẫn log CloudTrail:

s3://<bucket>/<prefix>/AWSLogs/<account-id>/CloudTrail/<region>/<năm>/<tháng>/<ngày>/

Prefix nằm TRƯỚC AWSLogs/ — nên Resource trong bucket policy phải bao gồm nó (xem câu #7752 về lỗi khi hai chỗ không khớp).

Hai cách tập trung log CloudTrail: | Cách | Đặc điểm | |---|---| | Từng tài khoản một trail ghi vào bucket chung | linh hoạt, dùng được ngoài Organizations ← câu này | | Organization trail | cấu hình MỘT lần, tài khoản mới tự động được bao phủ, member KHÔNG tắt được |

Organization trail là lựa chọn tốt hơn khi có AWS Organizations — và nó tự phân chia theo account ID trong đường dẫn, nên nhu cầu "prefix riêng cho mỗi đơn vị" được đáp ứng sẵn (xem câu #7701).

Bốn biện pháp bảo vệ tính toàn vẹn của log kiểm toán: | Biện pháp | Chống lại | |---|---| | Log file validation | phát hiện sửa đổi hoặc xoá | | S3 Object Lock (COMPLIANCE) | NGĂN xoá — không ai xoá được, kể cả root | | Bucket ở tài khoản RIÊNG | kẻ chiếm tài khoản không với tới log | | SSE-KMS với key policy chặt | chỉ đội kiểm toán giải mã được |

Hai dòng đầu bổ sung nhau: validation phát hiện, Object Lock ngăn chặn. Với yêu cầu tuân thủ nghiêm ngặt, cần cả hai.

aws cloudtrail validate-logs   --trail-arn arn:aws:cloudtrail:...:trail/trail-don-vi-a   --start-time 2026-08-01T00:00:00Z

Ghi chú về chất lượng câu hỏi

Phân biệt giữa B và E rất mỏng. Cả hai đều mô tả cùng một kiến trúc; khác biệt duy nhất là B nói "bật log file validation trên mọi trail ở tất cả tài khoản, bao gồm cả tài khoản tập trung" còn E nói "ở các tài khoản của đơn vị kinh doanh".

Cách đọc bênh cho E: yêu cầu của đề nói về các đơn vị kinh doanh, và tài khoản tập trung là nơi lưu trữ, không phải một đơn vị kinh doanh. E khớp đúng phạm vi được nêu.

Nhưng trong thực tế, bạn NÊN có trail cho cả tài khoản audit — nó cũng cần được kiểm toán, và thường còn cần chặt hơn vì nó giữ dữ liệu nhạy cảm nhất. Nên nếu bạn thiết kế hệ thống này, hãy làm theo B, dù đáp án của đề là E.

Câu 133 Threat Detection and Incident Response

A Security Engineer received a GuardDuty security alert pertaining to one of the Amazon EC2 instances that is attempting to communicate with the IP address of a remote host known to hold credentials and stolen data captured by malware. The Security Engineer immediately tried to isolate the instance by activating the isolation security group on the instance. However, within a few minutes, the engineer received a similar alert again.

Which of the following represents the underlying reason for this behavior and what is the solution to remediate the issue?

  1. A

    When you change a security group rule, its tracked connections are not immediately interrupted. The tracked connections need to be configured to change to untracked connections and then apply the isolation security group to isolate the compromised instance
  2. B

    When you associate multiple security groups with an instance, rules with deny access need to be mutually exclusive. Delete all the security groups and create only the isolation security group to isolate the compromised instance
  3. C

    If you send a request from your instance, the response traffic for that request is allowed to flow in regardless of inbound security group rules. Hence, to isolate the instance, cut off Internet Gateway from the instance
  4. D

    When the isolation security group is unable to isolate an instance, the immediate fix is to shut down the compromised instance to cut off further damage to your AWS resources
Xem giải thích

Đáp án

A — Khi bạn thay đổi rule của security group, các kết nối đang được theo dõi (tracked connections) KHÔNG bị ngắt ngay lập tức. Phải cấu hình để các kết nối đó chuyển thành untracked, rồi mới áp security group cách ly.

Vì sao đúng

Đề mô tả một triệu chứng rất cụ thể: gắn security group cách ly nhưng vài phút sau vẫn nhận cảnh báo tương tự.

Nguyên nhân: security group có TRẠNG THÁI, và trạng thái đó tồn tại độc lập với rule.

Instance đã mở kết nối tới máy chủ độc hại
    → kết nối được ghi vào BẢNG THEO DÕI (connection tracking table)

Bạn gắn security group cách ly (không có rule nào)
    → rule MỚI áp cho KẾT NỐI MỚI
    → kết nối ĐANG MỞ vẫn nằm trong bảng theo dõi
    → dữ liệu vẫn tiếp tục chảy   ← đúng triệu chứng của đề

Đây là hệ quả trực tiếp của tính stateful: security group cho phép lưu lượng phản hồi của một kết nối đã được chấp nhận mà không cần kiểm tra lại rule — và nó không biết rằng rule vừa thay đổi.

Cách khiến kết nối trở thành untracked:

Nếu có rule cho phép toàn bộ lưu lượng (0.0.0.0/0) trên MỌI cổng ở một chiều, và rule tương ứng ở chiều ngược lại, thì luồng đó không được theo dõi — và thay đổi rule có hiệu lực ngay lập tức.

Cách thực tế hơn để cắt kết nối đang mở — dùng NACL:

NACL là STATELESS
    → mỗi gói tin được kiểm tra ĐỘC LẬP
    → thêm rule DENY vào NACL của subnet
    → kết nối đang mở bị cắt NGAY
Công cụ Cắt được kết nối đang mở?
Security group (tracked) ❌ không
Security group (untracked) ✅ có
NACL ✅ có — stateless

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

  • C. Nếu bạn gửi request từ instance, lưu lượng phản hồi được phép vào bất kể rule inbound; nên để cách ly, hãy cắt Internet Gateway khỏi instance — đây là phương án gần nhất và mô tả đúng tính stateful, nhưng giải pháp sai: gỡ IGW ảnh hưởng toàn bộ subnet và mọi instance trong đó, không chỉ máy bị xâm nhập. Và nó không nhắm vào cơ chế connection tracking.
  • B. Khi gắn nhiều security group cho một instance, các rule deny access phải loại trừ lẫn nhau; hãy xoá mọi security group và chỉ tạo security group cách ly — sai kiến thức nền tảng: security group KHÔNG CÓ rule deny. Nó chỉ có rule Allow, và không khớp rule nào nghĩa là từ chối ngầm định.
  • D. Khi security group cách ly không cách ly được, cách khắc phục tức thì là tắt instance bị xâm nhập — phá huỷ bằng chứng: tắt máy làm mất toàn bộ dữ liệu trong RAM — khoá mã hoá, tiến trình đang chạy, kết nối đang mở. Đó là những bằng chứng quan trọng nhất cho điều tra.

Ghi nhớ

Bảng phân biệt nền tảng nhất về mạng trong VPC: | | Security group | Network ACL | |---|---|---| | Trạng thái | STATEFUL — theo dõi kết nối | STATELESS — kiểm tra từng gói | | Mức | ENI | subnet | | Rule | CHỈ Allow | Allow VÀ Deny | | Cắt kết nối đang mở | ❌ | ✅ | | Đánh giá | mọi rule | theo thứ tự số, dừng ở rule khớp đầu |

Dòng "cắt kết nối đang mở" là nội dung chính của câu hỏi này.

Connection tracking — cơ chế và hệ quả: | Điều | Chi tiết | |---|---| | Mỗi luồng chiếm một mục trong bảng | bảng có dung lượng theo loại instance | | Bảng đầy → từ chối kết nối mới | nút thắt khi bị DDoS (xem câu #7789) | | Rule cho phép mọi thứ hai chiều = untracked | không tốn mục nào | | Thay đổi rule không ảnh hưởng luồng đã tracked | ← câu này |

Cùng một cơ chế gây ra hai vấn đề khác nhau — cạn bảng khi bị tấn công, và cách ly không có hiệu lực tức thì.

Quy trình cách ly instance bị xâm nhập — đầy đủ và đúng thứ tự:

① Gắn security group cách ly           → chặn kết nối MỚI
② Thêm NACL DENY cho IP độc hại        → cắt kết nối ĐANG MỞ
③ Gỡ instance profile / thu hồi phiên  → chặn đường tới tài nguyên AWS
④ Snapshot EBS, chụp RAM nếu có thể    → giữ bằng chứng
⑤ KHÔNG tắt máy cho tới khi thu xong bằng chứng
⑥ Rà CloudTrail xem role đã gọi API gì

Bước ② là mảnh ghép mà nhiều quy trình bỏ sót — và là lý do sự cố trong đề vẫn tiếp diễn.

Cảnh báo quan trọng về security group cách ly: đừng xoá rule của security group đang dùng chung. Nhiều instance thường gắn chung một security group; xoá sạch rule của nó sẽ ngắt mạng toàn bộ nhóm máy. Cách đúng là tạo sẵn một security group rỗng và thay thế trên đúng instance đó:

aws ec2 modify-instance-attribute   --instance-id i-0abc123 --groups sg-cach-ly-rong

Ba thứ cần thu thập trước khi tắt máy, theo độ dễ mất: | Bằng chứng | Mất khi | |---|---| | RAM | tắt máy — mất ngay | | Kết nối mạng đang mở | tắt máy | | Đĩa (EBS) | bền — snapshot được |

Và một biện pháp chuẩn bị trước đáng làm: viết sẵn một SSM Automation runbook thực hiện các bước ①–④ bằng một lệnh. Trong lúc xảy ra sự cố, việc nhớ đúng thứ tự và không bỏ sót bước nào là khó — có runbook thì không phải nhớ.

Câu 134 Security Logging and Monitoring

During an internal IT Audit, the security team realized that AWS CloudTrail was disabled for a few AWS Regions leading to security and audit lapses. Now, the management wants to tighten the security measures across the company. As an AWS Certified Security Specialist, you have been tasked to build a solution for automatic re-enabling of AWS CloudTrail in any AWS Region if it happens to be turned off.

What is the most optimal way of addressing this requirement?

  1. A

    Use AWS Security Hub with a managed rule cloudtrail-enabled to trigger a remediation action to fix the non-compliant status using AWS Systems Manager Automation documents
  2. B

    Use AWS Config with a managed rule cloudtrail-enabled to trigger a remediation action to fix the non-compliant status using AWS Systems Manager Automation documents
  3. C

    Create an Amazon CloudWatch alarm with a cloudtrail.amazonaws.com event source and a StartLogging event name to trigger an AWS Lambda function to call the StartLogging API
  4. D

    Use AWS Trusted Advisor security check on AWS CloudTrail Logging to trigger a Lambda function in case logging is disabled. The Lambda function implements the functionality to enable CloudTrail logging if it is disabled
Xem giải thích

Đáp án

B — Dùng AWS Config với managed rule cloudtrail-enabled để kích hoạt hành động khắc phục, sửa trạng thái không tuân thủ bằng SSM Automation document.

Vì sao đúng

Đề yêu cầu tự động bật lại CloudTrail ở bất kỳ Region nào nếu nó bị tắt, với cách tối ưu nhất.

Config với managed rule + remediation là luồng khép kín không cần viết mã:

AWS Config đánh giá liên tục
    ↓ managed rule cloudtrail-enabled
Phát hiện Region không có trail đang hoạt động
    ↓ trạng thái NON_COMPLIANT
    ↓ remediation action tự động
SSM Automation document → gọi StartLogging hoặc tạo trail
    ↓
Trở lại COMPLIANT

Ba lý do đây là cách tối ưu: | Lý do | Chi tiết | |---|---| | Managed rule có sẵn | AWS đã viết cloudtrail-enabled — chỉ cần bật | | SSM Automation document có sẵn | không phải viết Lambda | | Đánh giá liên tục | không cần lịch chạy riêng |

aws configservice put-config-rule --config-rule '{
  "ConfigRuleName": "cloudtrail-enabled",
  "Source": {"Owner": "AWS", "SourceIdentifier": "CLOUD_TRAIL_ENABLED"},
  "MaximumExecutionFrequency": "One_Hour"
}'

aws configservice put-remediation-configurations   --remediation-configurations '[{
    "ConfigRuleName": "cloudtrail-enabled",
    "TargetType": "SSM_DOCUMENT",
    "TargetId": "AWS-EnableCloudTrail",
    "Automatic": true,
    "MaximumAutomaticAttempts": 3
  }]'

Và cloudtrail-enabled là rule kiểu PERIODIC — nó kiểm tra theo lịch (1, 3, 6, 12 hoặc 24 giờ) vì "có trail đang chạy hay không" là trạng thái toàn tài khoản, không gắn với một tài nguyên cụ thể thay đổi.

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

  • A. Dùng AWS Security Hub với managed rule cloudtrail-enabled để kích hoạt khắc phục bằng SSM Automation document — đây là phương án gần nhất và nhầm dịch vụ sở hữu rule: Security Hub có control (kiểm tra theo chuẩn), không có "managed rule". Managed rule là khái niệm của AWS Config. (Security Hub thực ra dựa vào Config để chạy phần lớn control của nó — nhưng rule thuộc về Config.)
  • C. Tạo CloudWatch alarm với event source cloudtrail.amazonaws.com và event name StartLogging để kích hoạt Lambda gọi API StartLogging — hai lỗi: "event source" và "event name" là khái niệm của EventBridge, không phải CloudWatch alarm. Và StartLogging là sự kiện BẬT log — bắt nó rồi bật lại là vô nghĩa; sự kiện cần bắt là StopLogging.
  • D. Dùng Trusted Advisor security check về CloudTrail Logging để kích hoạt Lambda bật lại logging — Trusted Advisor không kích hoạt Lambda trực tiếp và chạy theo chu kỳ dài, nên phản ứng chậm. (Nó có kiểm tra "AWS CloudTrail Logging" thật, nhưng chỉ để khuyến nghị.)

Ghi nhớ

Ba cách phát hiện CloudTrail bị tắt — theo độ trễ: | Cách | Độ trễ | Có tự sửa? | |---|---|---| | EventBridge bắt StopLogging | vài giây | cần Lambda hoặc SSM | | Config rule cloudtrail-enabled | theo chu kỳ (1–24 giờ) | ✅ remediation có sẵn | | Trusted Advisor | chu kỳ dài | ❌ |

Kết hợp hai cách đầu là cấu hình mạnh nhất: EventBridge cho cảnh báo tức thì, Config cho đảm bảo trạng thái cuối cùng luôn đúng.

Event pattern cho EventBridge:

{
  "source": ["aws.cloudtrail"],
  "detail": {"eventName": ["StopLogging", "DeleteTrail", "UpdateTrail"]}
}

Bắt cả UpdateTrail — sửa trail để trỏ sang bucket khác cũng là cách né tránh giám sát.

Ba cách khắc phục của AWS Config — theo công sức: | Cách | Công sức | |---|---| | SSM Automation document có sẵn | thấp nhất | | SSM Automation document tự viết | trung bình | | Lambda function | cao nhất |

Các SSM Automation document có sẵn hay dùng: | Document | Việc | |---|---| | AWS-EnableCloudTrail | bật CloudTrail ← câu này | | AWS-EnableS3BucketEncryption | bật mã hoá bucket | | AWS-DisableS3BucketPublicReadWrite | khoá bucket công khai | | AWS-PublishSNSNotification | gửi thông báo | | AWSConfigRemediation-* | bộ document chuyên cho Config |

Nhưng biện pháp mạnh nhất không phải là sửa sau — mà là NGĂN từ đầu:

{
  "Effect": "Deny",
  "Action": ["cloudtrail:StopLogging", "cloudtrail:DeleteTrail",
             "cloudtrail:UpdateTrail", "cloudtrail:PutEventSelectors"],
  "Resource": "*"
}

SCP này khiến không ai tắt được CloudTrail — kể cả root user của tài khoản thành viên (xem câu #7787). Tự động bật lại là lớp phòng thủ thứ hai, không nên là lớp duy nhất.

Ba lớp bảo vệ CloudTrail — nên có đủ: | Lớp | Vai trò | |---|---| | SCP chặn StopLogging | NGĂN CHẶN | | Organization trail | member account không tắt được trail của tổ chức | | Config rule + remediation | phát hiện và sửa ← câu này | | EventBridge + SNS | cảnh báo cho người |

Dòng thứ hai đáng nhấn mạnh: organization trail được quản lý từ tài khoản quản lý, và tài khoản thành viên không có quyền sửa hay tắt nó — nó giải quyết vấn đề của đề ngay từ thiết kế thay vì phải giám sát và sửa chữa.

Và một lưu ý về phạm vi: Config là dịch vụ khu vực, nên rule này phải được triển khai ở mọi Region. Dùng Config conformance pack hoặc CloudFormation StackSets để triển khai đồng loạt — cấu hình thủ công từng Region là chỗ dễ bỏ sót, và Region bị bỏ sót chính là Region mà kẻ tấn công sẽ dùng.

Câu 135 Management and Security Governance

As part of the organization-wide security best practices, a company has mandated that all software installed on the EC2 instances should be upgraded to its most recent authorized version every 30 days. For this requirement, the Security Administrator has to provide a weekly report that lists all the instances that do not have the latest software updates deployed.

What is the most optimal way to implement this requirement?

  1. A

    Use Patch Manager, a capability of AWS Systems Manager to automatically scan your instances and report compliance on a schedule, install available software updates on a schedule, and scan targets on demand
  2. B

    Use Change Manager, a capability of AWS Systems Manager to automatically scan your instances and report compliance on a schedule and install available software updates on a schedule through automated runbooks
  3. C

    Use Amazon Inspector to determine the systems that do not have the latest patches applied after a time of 30 days and configure Inspector to redeploy these instances with the latest AMI version
  4. D

    Use Version Manager, a capability of AWS Systems Manager to automatically scan your instances and report compliance on a schedule, install available software versions on a schedule, and scan targets on demand
Xem giải thích

Đáp án

A — Dùng Patch Manager, một khả năng của AWS Systems Manager, để tự động quét instance và báo cáo tuân thủ theo lịch, cài bản cập nhật phần mềm theo lịch, và quét theo yêu cầu.

Vì sao đúng

Đề nêu hai yêu cầu, và Patch Manager đáp ứng cả hai bằng chính các tính năng dựng sẵn: | Yêu cầu | Tính năng | |---|---| | Phần mềm phải được cập nhật mỗi 30 ngày | patch baseline + maintenance window | | Báo cáo hằng tuần các instance thiếu bản vá | patch compliance report |

Ba thành phần của Patch Manager: | Thành phần | Việc | |---|---| | Patch baseline | quy tắc bản vá nào được duyệt tự động, sau bao nhiêu ngày | | Patch group | nhóm instance áp cùng một baseline (theo tag) | | Maintenance window | khi nào được phép cài đặt |

Patch baseline khớp trực tiếp với yêu cầu "30 ngày":

{
  "Name": "baseline-cong-ty",
  "ApprovalRules": {
    "PatchRules": [{
      "PatchFilterGroup": {"PatchFilters": [
        {"Key": "CLASSIFICATION", "Values": ["Security", "Critical"]}]},
      "ApproveAfterDays": 7,
      "ComplianceLevel": "CRITICAL"
    }]
  }
}

Và hai chế độ chạy phục vụ hai yêu cầu khác nhau: | Chế độ | Việc | |---|---| | Scan | chỉ QUÉT và báo cáo tuân thủ — không cài gì | | Install | quét và cài bản vá |

Chế độ Scan là thứ tạo ra báo cáo hằng tuần mà quản trị viên cần — chạy nó theo lịch mà không gây gián đoạn:

aws ssm create-association   --name AWS-RunPatchBaseline   --parameters "Operation=Scan"   --schedule-expression "cron(0 2 ? * MON *)"   --targets "Key=tag:MoiTruong,Values=production"

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

  • B. Dùng Change Manager của Systems Manager để tự động quét, báo cáo tuân thủ theo lịch và cài cập nhật qua runbook tự động — đây là phương án gần nhất và là một khả năng có thật của Systems Manager, nhưng nó phục vụ mục đích khác: Change Manager quản lý quy trình phê duyệt thay đổi (ai yêu cầu, ai duyệt, chạy khi nào). Nó không quét bản vá và không báo cáo tuân thủ bản vá.
  • D. Dùng Version Manager của Systems Manager — không tồn tại khả năng nào tên như vậy trong AWS Systems Manager.
  • C. Dùng Amazon Inspector để xác định hệ thống chưa được vá sau 30 ngày và cấu hình Inspector triển khai lại các instance đó với AMI mới nhất — Inspector không triển khai gì cả: nó quét lỗ hổng và sinh finding. Việc vá hoặc thay thế instance là của Systems Manager hoặc quy trình CI/CD.

Ghi nhớ

Các khả năng chính của AWS Systems Manager: | Khả năng | Việc | |---|---| | Patch Manager | vá lỗi và báo cáo tuân thủ bản vá ← câu này | | Session Manager | truy cập shell không cần SSH | | Run Command | chạy lệnh trên nhiều instance | | State Manager | duy trì cấu hình mong muốn | | Automation | runbook tự động hoá | | Parameter Store | lưu tham số và bí mật | | Inventory | kiểm kê phần mềm cài đặt | | Change Manager | quy trình phê duyệt thay đổi | | Fleet Manager | quản lý máy chủ qua giao diện |

Ba dòng đầu và Parameter Store là những cái được hỏi nhiều nhất.

Inspector và Patch Manager — hai nửa của một quy trình: | Dịch vụ | Việc | |---|---| | Inspector | TÌM lỗ hổng, xếp hạng mức nghiêm trọng | | Patch Manager | VÁ lỗ hổng theo baseline và cửa sổ bảo trì |

Inspector phát hiện CVE-2026-xxxx (CRITICAL)
    ↓ finding sang Security Hub
    ↓ EventBridge
Patch Manager chạy trong maintenance window → vá
    ↓
Inspector quét lại → finding đóng

Đây là vòng khép kín đáng dựng cho môi trường sản xuất.

Bốn cấu hình quan trọng của patch baseline: | Cấu hình | Việc | |---|---| | ApproveAfterDays | tự duyệt bản vá sau N ngày kể từ khi phát hành | | ApprovedPatches | danh sách duyệt thủ công | | RejectedPatches | danh sách CẤM — cho bản vá gây lỗi đã biết | | ComplianceLevel | mức nghiêm trọng khi thiếu bản vá này |

ApproveAfterDays là cơ chế cân bằng rủi ro: chờ vài ngày để cộng đồng phát hiện bản vá lỗi, nhưng không chờ quá lâu để lỗ hổng bị khai thác. Bảy ngày là giá trị thường dùng cho bản vá bảo mật.

Ba yêu cầu để Patch Manager hoạt động:

① 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)

Giống hệt yêu cầu của Session Manager và Inspector v2 — vì cả ba đều dựa trên SSM Agent.

Ba cách xem báo cáo tuân thủ bản vá: | Cách | Đặc điểm | |---|---| | Console Systems Manager → Compliance | trực quan, lọc được | | describe-instance-patch-states | API, xuất báo cáo tự động | | Tích hợp Security Hub | finding hiện trong bảng điều khiển bảo mật chung |

Dòng cuối đáng bật: Patch Manager gửi finding sang Security Hub, nên tình trạng vá lỗi nằm cùng chỗ với các phát hiện bảo mật khác thay vì ở một bảng điều khiển riêng.

Và một lưu ý về maintenance window: đặt nó vào giờ thấp điểm và dùng MaxConcurrency để vá theo lô. Vá đồng loạt toàn bộ đội máy — nhất là khi bản vá đòi khởi động lại — là cách nhanh nhất để biến một việc bảo trì thường lệ thành sự cố ngừng dịch vụ.

Câu 136 Chọn nhiều đáp án Infrastructure Security

A Security Engineer has followed the best practices to set up a trusted IP address list for Amazon GuardDuty. However, GuardDuty is generating alert findings for the configured trusted IP addresses.

Which of the following checks will you perform to ensure GuardDuty works as expected? (Select two)

  1. A

    Ensure that the trusted IP lists are uploaded in the same AWS Region as your GuardDuty findings
  2. B

    Ensure that in multi-account environments, GuardDuty generates findings for member accounts based on activity that involves IP addresses from the administrator's trusted IP lists
  3. C

    Ensure that the same IP is not enlisted on both a trusted IP list as well as a threat list, as it will be processed by the threat list on priority, thereby resulting in a finding
  4. D

    Ensure that multiple trusted IP lists per AWS account per Region have been configured
  5. E

    Ensure that IP addresses added in the trusted IP list are publicly routable IPv4 addresses
Xem giải thích

Đáp án

A và E.

  • A — Đảm bảo trusted IP list được tải lên ở CÙNG Region với các finding của GuardDuty
  • E — Đảm bảo các địa chỉ trong trusted IP list là địa chỉ IPv4 định tuyến công khai (publicly routable)

Vì sao đúng

Đề mô tả: đã cấu hình trusted IP list theo đúng hướng dẫn, nhưng GuardDuty vẫn sinh finding cho các IP đó.

A — GuardDuty và danh sách IP đều là cấu hình THEO REGION:

GuardDuty detector ở ap-northeast-1  →  trusted IP list của ap-northeast-1
GuardDuty detector ở us-east-1       →  trusted IP list RIÊNG

Tải danh sách lên chỉ một Region
    → các Region khác KHÔNG có danh sách đó
    → vẫn sinh finding bình thường  ← triệu chứng của đề

Đây là lỗi cấu hình phổ biến nhất với GuardDuty: người ta bật dịch vụ ở nhiều Region nhưng chỉ cấu hình danh sách ở một chỗ, rồi bối rối khi finding vẫn xuất hiện.

E — chỉ IP công khai được chấp nhận: | Loại địa chỉ | Chấp nhận | |---|---| | IPv4 công khai | ✅ | | IP riêng (10.x, 172.16–31.x, 192.168.x) | ❌ bị bỏ qua | | IPv6 | ❌ không hỗ trợ cho trusted IP list | | CIDR công khai | ✅ |

Vì sao thiết kế như vậy hợp lý: GuardDuty phân tích lưu lượng đi ra Internet và lời gọi API từ bên ngoài. Địa chỉ riêng không có ý nghĩa trong ngữ cảnh đó — cùng một dải 10.0.0.0/8 tồn tại trong hàng triệu VPC khác nhau.

Nên nếu bạn thêm dải IP nội bộ vào trusted list, nó bị bỏ qua âm thầm — không có lỗi nào, và finding vẫn tiếp tục.

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

  • C. Đảm bảo cùng một IP không nằm trên cả trusted list lẫn threat list, vì nó sẽ được threat list xử lý trước và sinh finding — đây là phương án gần nhất và sai ở thứ tự ưu tiên: trusted IP list được xử lý TRƯỚC. IP nằm trong cả hai thì không sinh finding (xem câu #7746). (Lời khuyên "đừng để trùng" thì hợp lý, nhưng lý do đưa ra là sai.)
  • **D. Đảm bảo đã cấu hình NHIỀU trusted IP list cho mỗi tài khoản mỗi Region — không làm được: GuardDuty chỉ cho phép MỘT trusted IP list cho mỗi tài khoản mỗi Region. (Threat list thì được tới sáu.)
  • B. Đảm bảo rằng trong môi trường nhiều tài khoản, GuardDuty sinh finding cho member account dựa trên hoạt động liên quan tới IP trong trusted list của administrator — mô tả ngược hành vi đúng: trusted list của administrator có tác dụng ngăn sinh finding cho member account, không phải gây ra chúng.

Ghi nhớ

Hai loại danh sách IP của GuardDuty — bảng cần thuộc: | Danh sách | Hiệu ứng | Số lượng | Địa chỉ tối đa | |---|---|---|---| | Trusted IP list | KHÔNG sinh finding | 1 mỗi tài khoản mỗi Region | 2.000 | | Threat IP list | LUÔN sinh finding | 6 mỗi tài khoản mỗi Region | 250.000 mỗi cái |

Sự bất đối xứng có lý do: trusted list tạo điểm mù nên AWS giới hạn chặt; threat list chỉ thêm cảnh báo nên rộng rãi hơn nhiều.

Thứ tự xử lý:

① Trusted IP list  → nếu khớp, DỪNG, không sinh finding
② Threat IP list   → nếu khớp, sinh finding
③ Phân tích thông thường

Danh sách kiểm tra khi trusted IP list không có tác dụng:

① Danh sách đã tải lên ĐÚNG Region chưa?          ← A
② Địa chỉ có phải IPv4 CÔNG KHAI không?           ← E
③ Danh sách đã được ACTIVATE chưa?
④ GuardDuty có quyền đọc object S3 đó không?
⑤ Trong mô hình đa tài khoản, danh sách đặt ở
   ADMINISTRATOR account chưa?
⑥ Định dạng tệp có đúng không?

Bước ③ hay bị quên: tạo danh sách và kích hoạt là hai thao tác riêng:

aws guardduty update-ip-set --detector-id <id>   --ip-set-id <ip-set-id> --activate

Bước ⑤ liên quan tới câu #7778: trong mô hình administrator–member, danh sách phải đặt ở tài khoản quản trị — đặt ở member account thì không có tác dụng.

Trusted IP list và suppression rule — phân biệt: | | Trusted IP list | Suppression rule | |---|---|---| | Finding có được TẠO không | ❌ không tạo | ✅ tạo rồi tự archive | | Truy vấn lại được | ❌ không có dấu vết | ✅ lọc theo trạng thái archived | | Lọc theo | chỉ địa chỉ IP | loại finding, tài nguyên, mọi thuộc tính |

Suppression rule an toàn hơn cho hầu hết trường hợp (xem câu #7695) — bạn vẫn giữ dữ liệu để rà lại. Trusted IP list chỉ nên dùng cho IP mà bạn hoàn toàn chắc chắn, như dải IP tĩnh của văn phòng.

Ba rủi ro của trusted IP list: | Rủi ro | Chi tiết | |---|---| | Tạo điểm mù hoàn toàn | không có cảnh báo nào cho biết bạn đang mù | | IP được cấp lại cho tổ chức khác | rà soát định kỳ | | Không phân biệt loại hoạt động | tin cậy IP đó cho mọi loại finding |

Dòng cuối là lý do nên ưu tiên suppression rule: nó cho phép nói "bỏ qua finding quét cổng từ IP này" thay vì "bỏ qua mọi thứ từ IP này" — chính xác hơn nhiều.

Và nhớ rằng danh sách được lưu dưới dạng tệp trong S3, nên việc cập nhật hằng quý như câu #7778 mô tả nên được tự động hoá bằng Lambda gọi update-ip-set cho mọi Region — làm thủ công qua nhiều Region là chỗ chắc chắn sẽ có sai sót.

Câu 137 Chọn nhiều đáp án Infrastructure Security

The development team at an e-commerce company has recently migrated to AWS Cloud from its on-premises data center. The team is evaluating CloudFront to be used as a CDN for its flagship application. The team has hired you as an AWS Certified Security Specialist to advise on CloudFront capabilities on routing and security.

Which of the following would you identify as correct regarding CloudFront? (Select three)

  1. A

    Use geo-restriction to configure CloudFront for high-availability and failover
  2. B

    Use an origin group with primary and secondary origins to configure CloudFront for high-availability and failover
  3. C

    Use field-level encryption in CloudFront to protect sensitive data for specific content
  4. D

    Use KMS encryption in CloudFront to protect sensitive data for specific content
  5. E

    CloudFront can route to multiple origins based on the content type
  6. F

    CloudFront can route to multiple origins based on the price class
Xem giải thích

Đáp án

B, C và E:

  • B — Dùng origin group với origin chính và origin phụ để cấu hình CloudFront cho tính sẵn sàng cao và chuyển đổi dự phòng
  • C — Dùng field-level encryption trong CloudFront để bảo vệ dữ liệu nhạy cảm cho nội dung cụ thể
  • E — CloudFront định tuyến tới nhiều origin dựa trên loại nội dung

Vì sao đúng

B — origin group là cơ chế failover của CloudFront:

Origin group:
  Origin chính:  ALB ở ap-northeast-1
  Origin phụ:    S3 bucket (trang tĩnh dự phòng)

CloudFront nhận mã lỗi từ origin chính (500, 502, 503, 504, 403, 404)
    → tự động thử origin PHỤ
    → người dùng không thấy lỗi

Điều kiện kích hoạt failover là mã trạng thái bạn cấu hình — nên bạn kiểm soát được khi nào chuyển đổi.

C — field-level encryption bảo vệ trường nhạy cảm ở tầng biên:

Người dùng gửi form có số thẻ tín dụng
    ↓ CloudFront MÃ HOÁ NGAY trường đó bằng public key của bạn
Origin và mọi hệ thống trung gian chỉ thấy BẢN MÃ
    ↓
Chỉ dịch vụ có PRIVATE KEY mới đọc được

Giá trị thật của nó: dữ liệu nhạy cảm được mã hoá ngay tại điểm biên gần người dùng nhất, nên các thành phần trung gian (load balancer, ứng dụng web, log) không bao giờ chạm vào dữ liệu rõ — thu hẹp đáng kể phạm vi tuân thủ PCI DSS.

E — nhiều origin theo loại nội dung, qua cache behavior:

/api/*      → origin là ALB          (nội dung động)
/images/*   → origin là S3           (ảnh tĩnh)
/video/*    → origin là MediaPackage (video)
*           → origin mặc định

Cache behavior khớp theo path pattern, và mỗi cái trỏ tới một origin khác nhau — đây là cách một distribution phục vụ cả ứng dụng động lẫn nội dung tĩnh.

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

  • A. Dùng geo-restriction để cấu hình CloudFront cho tính sẵn sàng cao và chuyển đổi dự phòng — đây là phương án gần nhất về mặt là một tính năng có thật, nhưng nó phục vụ mục đích hoàn toàn khác: geo restriction chặn truy cập theo quốc gia. Nó không liên quan gì tới tính sẵn sàng.
  • D. Dùng mã hoá KMS trong CloudFront để bảo vệ dữ liệu nhạy cảm cho nội dung cụ thể — field-level encryption KHÔNG dùng KMS: nó dùng một cặp khoá RSA mà bạn tự sinh và tải public key lên CloudFront. Private key do bạn giữ và dùng ở phía ứng dụng.
  • F. CloudFront định tuyến tới nhiều origin dựa trên price class — nhầm chức năng của price class: nó quyết định CloudFront dùng những nhóm điểm biên nào (chỉ Bắc Mỹ và châu Âu, hay toàn cầu) để cân đối chi phí và độ trễ. Nó không ảnh hưởng tới việc chọn origin.

Ghi nhớ

Bốn khái niệm định tuyến của CloudFront: | Khái niệm | Việc | |---|---| | Origin | nguồn nội dung: S3, ALB, EC2, máy chủ ngoài AWS | | Cache behavior | khớp path pattern → chọn origin + chính sách cache | | Origin group | cặp origin chính–phụ cho failover | | Price class | nhóm điểm biên được dùng — ảnh hưởng CHI PHÍ |

Cache behavior được đánh giá theo thứ tự ưu tiên, và path pattern cụ thể phải đứng trước pattern chung — /api/* phải có priority cao hơn *.

Ba tính năng bảo mật của CloudFront: | Tính năng | Bảo vệ | |---|---| | Field-level encryption | trường dữ liệu nhạy cảm, mã hoá bằng RSA tại biên | | Signed URL / signed cookie | giới hạn ai xem được, trong bao lâu | | OAC (hoặc OAI) | chỉ CloudFront đọc được origin S3 | | Geo restriction | chặn theo quốc gia (miễn phí) | | Tích hợp WAF | lọc tầng 7 |

Signed URL và signed cookie — phân biệt: | | Signed URL | Signed cookie | |---|---|---| | Phạm vi | một tệp | nhiều tệp khớp một pattern | | Dùng khi | tải một tệp cụ thể | truy cập cả một thư viện nội dung |

Ba điều cần biết về field-level encryption: | Điều | Chi tiết | |---|---| | Dùng cặp khoá RSA 2048-bit | bạn sinh, tải public key lên CloudFront | | Tối đa 10 trường mỗi cấu hình | | | Chỉ áp cho POST với application/x-www-form-urlencoded | giới hạn quan trọng |

Dòng cuối hay bị bỏ sót: field-level encryption không hoạt động với JSON body — nếu ứng dụng của bạn gửi JSON, tính năng này không dùng được và phải mã hoá ở tầng ứng dụng.

Cấu hình origin group cho failover:

{
  "OriginGroups": {
    "Items": [{
      "Id": "nhom-chinh-phu",
      "FailoverCriteria": {"StatusCodes": {"Items": [500, 502, 503, 504]}},
      "Members": {"Items": [{"OriginId": "alb-chinh"}, {"OriginId": "s3-du-phong"}]}
    }]}}

Giới hạn của origin group cần biết: | Giới hạn | Chi tiết | |---|---| | Chỉ 2 origin mỗi group | không có origin thứ ba | | Chỉ áp cho GET, HEAD, OPTIONS | request ghi KHÔNG failover | | Failover theo mã trạng thái hoặc timeout | không theo health check chủ động |

Dòng giữa quan trọng: origin group không bảo vệ được thao tác ghi — với ứng dụng động, cần chiến lược dự phòng khác (Route 53 failover routing tới một Region khác chẳng hạn).

Và một lưu ý về price class: chọn PriceClass_100 (chỉ Bắc Mỹ và châu Âu) giảm chi phí đáng kể nhưng người dùng ở châu Á sẽ được phục vụ từ điểm biên xa hơn. Với đề này — một công ty thương mại điện tử vừa chuyển lên AWS — nên đo lường vị trí thật của người dùng trước khi chọn, thay vì mặc định PriceClass_All.

Câu 138 Data Protection

A retail company recently faced a cyber attack and lost all its data stored in the EBS volumes for the EC2 instances. However, the EBS snapshots were not manipulated. The company could restore the data from the EBS snapshots. However, the incident highlighted the security gaps in the current security plan. An immediate need is to protect the EBS snapshots from any manipulation or deletion.

As a Security Engineer, what measures will you take to protect these AWS KMS Customer Master Keys (CMKs) encrypted snapshots?

  1. A

    Create a new AWS account with limited privileges. Allow the newly created account to access the AWS KMS CMK key used to encrypt the EBS snapshots. Copy the encrypted snapshots to the new account on a regular basis
  2. B

    Create a new AWS account with limited privileges. Configure the snapshot to use encryption with the default AWS-managed key while copying the encrypted snapshots to the new account. Since default encryption is used, you don't need to share access to the AWS KMS CMK key
  3. C

    Use S3 Lifecycle transitions to regularly copy EBS snapshots to Amazon S3 through automation
  4. D

    Create a new Amazon S3 bucket. Use AWS Systems Manager to move EBS snapshots to the new S3 bucket. Use S3 lifecycle policies to move the snapshots to Amazon S3 Glacier and subsequently apply Glacier Vault policies to prevent deletion
Xem giải thích

Đáp án

A — Tạo một tài khoản AWS mới với quyền hạn chế. Cho phép tài khoản mới đó truy cập KMS CMK dùng để mã hoá snapshot. Sao chép snapshot đã mã hoá sang tài khoản mới định kỳ.

Vì sao đúng

Đề nêu tình huống: dữ liệu EBS đã mất vì tấn công, snapshot cứu được ngày hôm đó, và giờ cần bảo vệ chính snapshot khỏi bị sửa đổi hoặc xoá.

Nguyên tắc cốt lõi: bản sao lưu phải nằm NGOÀI phạm vi mà kẻ tấn công chạm tới được.

Snapshot nằm cùng tài khoản với dữ liệu gốc:
    → kẻ chiếm được tài khoản có quyền xoá cả snapshot
    → sao lưu và bản gốc cùng chết một lúc

Snapshot sao chép sang TÀI KHOẢN RIÊNG:
    → thông tin đăng nhập bị lộ ở tài khoản sản xuất
      KHÔNG chạm tới tài khoản sao lưu
    → ranh giới tài khoản là ranh giới bảo mật mạnh nhất của AWS

Đây chính là mô hình chống ransomware được AWS khuyến nghị — và nó hiệu quả vì tài khoản AWS là đơn vị cách ly cao nhất, mạnh hơn mọi IAM policy trong cùng một tài khoản.

Và vế "cho phép truy cập CMK" là điều kiện bắt buộc, không phải chi tiết thừa:

Snapshot mã hoá bằng AWS managed key (aws/ebs)  → KHÔNG chia sẻ được
Snapshot mã hoá bằng CUSTOMER MANAGED KEY (CMK) → chia sẻ được ✓

Lý do: AWS managed key không cho sửa key policy, nên không cấp quyền cho tài khoản khác được. Đây là điểm loại của phương án B.

Quy trình:

# ① Chia sẻ snapshot với tài khoản sao lưu
aws ec2 modify-snapshot-attribute --snapshot-id snap-0abc   --attribute createVolumePermission --operation-type add --user-ids 999988887777

# ② Key policy của CMK cho phép tài khoản đó kms:Decrypt, kms:CreateGrant

# ③ Tài khoản sao lưu TỰ SAO CHÉP sang khoá của CHÍNH NÓ
aws ec2 copy-snapshot --source-snapshot-id snap-0abc   --source-region ap-northeast-1 --encrypted --kms-key-id <cmk-cua-tai-khoan-sao-luu>

Bước ③ quan trọng: sau khi sao chép sang khoá riêng, bản sao lưu hoàn toàn độc lập — tài khoản sản xuất bị xâm nhập và khoá bị xoá cũng không ảnh hưởng.

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

  • B. Tạo tài khoản mới; cấu hình snapshot dùng mã hoá bằng AWS managed key mặc định khi sao chép sang tài khoản mới; vì dùng mã hoá mặc định nên không cần chia sẻ quyền CMK — đây là phương án gần nhất và thất bại ở đúng chỗ mấu chốt: snapshot mã hoá bằng AWS managed key KHÔNG chia sẻ chéo tài khoản được. Toàn bộ phương án dựa trên một điều không thực hiện được.
  • D. Tạo bucket S3 mới; dùng Systems Manager chuyển snapshot EBS sang bucket đó; dùng lifecycle policy chuyển sang Glacier rồi áp Vault Lock — Systems Manager không chuyển snapshot EBS sang S3 bucket. Snapshot do EBS quản lý và chỉ thao tác qua API của EC2. (Có EBS direct API đọc được nội dung snapshot, nhưng đó là công cụ lập trình chứ không phải tính năng của SSM.)
  • C. Dùng S3 Lifecycle transitions để sao chép snapshot EBS sang S3 định kỳ qua tự động hoá — cùng lỗi khái niệm: lifecycle rule chỉ chuyển đổi lớp lưu trữ của object trong S3. Nó không đụng tới snapshot EBS, vốn không nằm trong bucket nào của bạn.

Ghi nhớ

Quy tắc 3-2-1 áp cho AWS:

3 bản sao dữ liệu
2 loại lưu trữ khác nhau
1 bản ở nơi TÁCH BIỆT  ← tài khoản riêng hoặc Region riêng

Bốn lớp bảo vệ bản sao lưu — theo độ mạnh: | Lớp | Chống lại | |---|---| | Tài khoản AWS riêng | kẻ chiếm tài khoản sản xuất | | Region riêng | sự cố toàn Region | | S3 Object Lock / Vault Lock (WORM) | xoá, kể cả bởi root | | IAM policy hạn chế | thao tác nhầm |

Dòng đầu mạnh nhất vì ranh giới tài khoản là ranh giới bảo mật cao nhất trên AWS.

Ràng buộc chia sẻ snapshot — bảng cần thuộc: | Loại mã hoá | Chia sẻ chéo tài khoản | |---|---| | Không mã hoá | ✅ kể cả công khai | | AWS managed key (aws/ebs) | ❌ KHÔNG | | Customer managed key (CMK) | ✅ nếu chia sẻ cả quyền dùng khoá |

Áp cho cả EBS snapshot lẫn RDS snapshot (xem câu #7770) — nếu bạn dự tính có lúc phải chia sẻ hoặc sao lưu chéo tài khoản, hãy dùng CMK ngay từ đầu.

Và snapshot mã hoá KHÔNG chia sẻ công khai được — chỉ chia sẻ với tài khoản cụ thể. Đây là ràng buộc có chủ đích.

Ba cách tự động hoá sao lưu chéo tài khoản: | Cách | Đặc điểm | |---|---| | AWS Backup với cross-account backup | được quản lý, có vault lock, hỗ trợ nhiều dịch vụ | | Data Lifecycle Manager (DLM) | chuyên cho EBS snapshot, có cross-account copy | | Lambda + EventBridge theo lịch | tự viết, linh hoạt nhất |

AWS Backup là lựa chọn đáng cân nhắc nhất cho môi trường thật: nó có Backup Vault Lock — chế độ WORM cho vault, nghĩa là không ai xoá được bản sao lưu trước hạn, kể cả root. Đó là mảnh ghép bảo vệ mạnh nhất mà đề không nhắc tới:

aws backup put-backup-vault-lock-configuration   --backup-vault-name vault-sao-luu   --min-retention-days 30 --max-retention-days 365   --changeable-for-days 3

Ba nguyên tắc cho tài khoản sao lưu: | Nguyên tắc | Lý do | |---|---| | Không dùng chung thông tin đăng nhập với tài khoản sản xuất | ← toàn bộ mục đích | | Quyền tối thiểu, bật MFA cho mọi truy cập | | | Chỉ cho phép GHI VÀO, không cho xoá | kẻ tấn công vào được cũng không phá được |

Dòng cuối là thiết kế đáng học: cấp cho tiến trình sao chép quyền CopySnapshot nhưng không có DeleteSnapshot — việc dọn dẹp bản cũ do một quy trình riêng với quyền riêng thực hiện.

Và một điều cần kiểm chứng định kỳ: thử khôi phục thật từ bản sao lưu. Một bản sao lưu chưa từng được khôi phục thử không phải là bản sao lưu — nó chỉ là một giả định.

Câu 139 Identity and Access Management

As a Security Specialist, you have been asked to create an AWS Identity and Access Management (IAM) policy that explicitly grants permissions to an IAM role for creating and managing Amazon Elastic Compute Cloud (Amazon EC2) instances in a specified VPC. The policy must limit permissions so that the IAM role can only create EC2 instances with specific tags and then manage those EC2 instances in a VPC by using those tags.

Which of the following solutions will meet this requirement?

  1. A

    Apply a custom IAM policy to restrict the permissions of the IAM role for creating EC2 instances in a specified VPC with tags using the policy condition ec2:ResourceTags to limit control to instances
  2. B

    Apply a custom IAM policy to restrict the permissions of the IAM role for creating EC2 instances in a specified VPC with tags using the policy condition aws:sourceVPC so that it also limits the instances within the specified VPC
  3. C

    Apply a custom IAM policy to restrict the permissions of the IAM role for creating EC2 instances in a specified VPC with tags. Use policy condition ec2:CreateTags to limit control to instances
  4. D

    Apply a custom IAM policy to restrict the permissions of the IAM role for creating EC2 instances in a specified VPC with tags. Replace the TAG-KEY or TAG-VALUE parameters with the IAM policy variable ${aws:username}
Xem giải thích

Đáp án

A — Áp một IAM policy tuỳ chỉnh hạn chế quyền của IAM role để tạo EC2 instance trong một VPC cụ thể với các tag, dùng điều kiện ec2:ResourceTag để giới hạn quyền kiểm soát đối với instance.

Vì sao đúng

Đề nêu hai yêu cầu, và cả hai đều xoay quanh tag: | Yêu cầu | Cơ chế | |---|---| | Chỉ tạo được EC2 với tag cụ thể | aws:RequestTag — tag trong request | | Chỉ quản lý được những EC2 mang tag đó | ec2:ResourceTag — tag trên tài nguyên |

ec2:ResourceTag là condition key đúng cho vế thứ hai:

{
  "Effect": "Allow",
  "Action": ["ec2:StartInstances", "ec2:StopInstances",
             "ec2:RebootInstances", "ec2:TerminateInstances"],
  "Resource": "arn:aws:ec2:*:*:instance/*",
  "Condition": {
    "StringEquals": {"ec2:ResourceTag/DuAn": "he-thong-thanh-toan"}
  }
}

Cách hoạt động: khi role gọi StopInstances trên một instance, IAM đọc tag của chính instance đó và so với điều kiện. Instance không có tag đúng thì thao tác bị từ chối.

Đây là ABAC (kiểm soát truy cập dựa trên thuộc tính) — và ưu điểm là không cần liệt kê ARN của từng instance. Instance mới được tạo với tag đúng tự động nằm trong phạm vi quyền.

Và vế "trong một VPC cụ thể" dùng thêm một điều kiện nữa:

{
  "Effect": "Allow",
  "Action": "ec2:RunInstances",
  "Resource": "arn:aws:ec2:*:*:subnet/*",
  "Condition": {
    "StringEquals": {"ec2:Vpc": "arn:aws:ec2:ap-northeast-1:111122223333:vpc/vpc-0abc123"}
  }
}

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

  • C. Áp IAM policy hạn chế quyền tạo EC2 trong VPC với tag. Dùng điều kiện ec2:CreateTags để giới hạn quyền kiểm soát — đây là phương án gần nhất và nhầm hành động với điều kiện: ec2:CreateTags là một HÀNH ĐỘNG (quyền gắn tag), không phải condition key. Không đặt nó vào phần Condition được.
  • B. Dùng điều kiện aws:sourceVPC để giới hạn instance trong VPC được chỉ định — sai ngữ cảnh của condition key: aws:SourceVpc cho biết request ĐI QUA VPC endpoint nào — nó ràng buộc đường đi của lời gọi API, không ràng buộc VPC mà tài nguyên được tạo trong đó. Key đúng cho việc sau là ec2:Vpc.
  • **D. Thay tham số TAG-KEY hoặc TAG-VALUE bằng biến policy ${aws:username} — không phù hợp với yêu cầu: biến này thay thế bằng tên của IAM user đang gọi. Đề nói về một IAM role quản lý instance theo tag của dự án, không phải theo tên từng người dùng. (Và role không có aws:username.)

Ghi nhớ

Ba condition key về tag — bảng cần thuộc: | Key | Tag ở đâu | Dùng cho hành động | |---|---|---| | aws:RequestTag/<key> | trong REQUEST | RunInstances, CreateTags — lúc TẠO | | ec2:ResourceTag/<key> hoặc aws:ResourceTag/<key> | trên TÀI NGUYÊN | StartInstances, TerminateInstances — lúc QUẢN LÝ | | aws:TagKeys | danh sách khoá tag trong request | bắt buộc/cấm khoá nhất định |

Yêu cầu của đề cần CẢ HAI key đầu — một cho lúc tạo, một cho lúc quản lý:

[
  {
    "Sid": "TaoInstancePhaiCoTagDung",
    "Effect": "Allow",
    "Action": "ec2:RunInstances",
    "Resource": "arn:aws:ec2:*:*:instance/*",
    "Condition": {"StringEquals": {"aws:RequestTag/DuAn": "he-thong-thanh-toan"}}
  },
  {
    "Sid": "ChiQuanLyInstanceCoTagDung",
    "Effect": "Allow",
    "Action": ["ec2:StartInstances", "ec2:StopInstances", "ec2:TerminateInstances"],
    "Resource": "arn:aws:ec2:*:*:instance/*",
    "Condition": {"StringEquals": {"ec2:ResourceTag/DuAn": "he-thong-thanh-toan"}}
  }
]

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 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 nếu quên:

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

Không có statement này, bất kỳ ai cũng đổi tag DuAn của một instance thành giá trị của mình và chiếm quyền điều khiển nó.

Lưu ý về ec2:RunInstances: nó là một hành động phức tạp, cần quyền trên nhiều loại tài nguyên cùng lúc — instance, volume, network interface, subnet, security group, image, key pair. Policy thiếu một loại nào đó sẽ bị từ chối với thông báo khá tối nghĩa.

Điều kiện ràng buộc theo VPC và subnet: | Key | Ràng buộc | |---|---| | ec2:Vpc | ARN của VPC mà tài nguyên thuộc về | | ec2:Subnet | ARN của subnet | | ec2:InstanceType | loại instance được phép |

(Nguồn của đề viết "ec2:ResourceTags" ở dạng số nhiều. Tên đúng trong tài liệu AWS là ec2:ResourceTag/<tên-khoá> — số ít và kèm tên khoá cụ thể. Ý nghĩa của đáp án không đổi, nhưng nếu bạn sao chép nguyên văn vào policy thì nó sẽ không khớp gì cả.)

Và một công cụ nên dùng khi thiết kế loại policy này: IAM Policy Simulator. Policy dựa trên tag rất dễ sai theo cách khó thấy — mô phỏng vài tình huống cụ thể (instance có tag đúng, có tag sai, không có tag) trước khi triển khai tiết kiệm nhiều thời gian gỡ lỗi về sau.

Câu 140 Infrastructure Security

An e-commerce company is using Amazon Macie, AWS Shield Advanced, Amazon Inspector and AWS Firewall Manager in its AWS account. The company wants to receive alerts in case a DDoS attack occurs against the account.

As an AWS Certified Security Specialist, what would you recommend?

  1. A

    Set up an Amazon CloudWatch alarm that monitors Shield Advanced metrics for an active DDoS event
  2. B

    Set up an Amazon CloudWatch alarm that monitors Amazon Macie findings for an active DDoS event
  3. C

    Set up an Amazon CloudWatch alarm that monitors Amazon Inspector findings for an active DDoS event
  4. D

    Set up an Amazon CloudWatch alarm that monitors AWS Firewall Manager metrics for an active DDoS event
Xem giải thích

Đáp án

A — Thiết lập một CloudWatch alarm giám sát metric của Shield Advanced cho sự kiện DDoS đang diễn ra.

Vì sao đúng

Đề cho một manh mối quyết định: công ty đã dùng AWS Shield Advanced. Và Shield Advanced là dịch vụ duy nhất trong bốn cái được nêu phát metric về DDoS.

Metric cần theo dõi:

Namespace: AWS/DDoSProtection
Metric:    DDoSDetected
Giá trị:   1 = đang có tấn công, 0 = bình thường
Dimension: ResourceArn

aws cloudwatch put-metric-alarm   --alarm-name canh-bao-ddos   --namespace AWS/DDoSProtection --metric-name DDoSDetected   --dimensions Name=ResourceArn,Value=arn:aws:cloudfront::111122223333:distribution/E1ABC   --statistic Maximum --period 60 --threshold 1   --comparison-operator GreaterThanOrEqualToThreshold   --evaluation-periods 1   --alarm-actions arn:aws:sns:...:doi-bao-mat

--statistic Maximum là lựa chọn đúng: metric là cờ 0/1, nên Maximum cho biết có xảy ra tấn công tại bất kỳ thời điểm nào trong chu kỳ không. Average sẽ làm loãng tín hiệu và có thể không vượt ngưỡng.

Và đây là tính năng CHỈ CÓ ở Shield Advanced: | | Shield Standard | Shield Advanced | |---|---|---| | Bảo vệ DDoS tầng 3/4 | ✅ | ✅ | | CloudWatch metric DDoS | ❌ KHÔNG | ✅ CÓ | | Thông báo tấn công | ❌ | ✅ | | Đội ứng phó SRT | ❌ | ✅ | | Bảo vệ chi phí | ❌ | ✅ |

Shield Standard bảo vệ nhưng im lặng — bạn được che chắn mà không biết gì đang xảy ra. Đó là lý do câu hỏi này chỉ có một đáp án hợp lệ.

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

  • D. CloudWatch alarm giám sát metric của AWS Firewall Manager cho sự kiện DDoS — đây là phương án gần nhất và Firewall Manager có liên quan tới Shield Advanced (nó quản lý Shield Advanced policy ở quy mô tổ chức), nhưng nó không phát metric về tấn công đang diễn ra. Nó báo cáo tài nguyên nào chưa được bảo vệ, không phải "đang bị tấn công".
  • B. CloudWatch alarm giám sát finding của Amazon Macie — sai dịch vụ: Macie phát hiện dữ liệu nhạy cảm trong S3 (số thẻ tín dụng, thông tin cá nhân). Không liên quan tới DDoS.
  • C. CloudWatch alarm giám sát finding của Amazon Inspector — sai dịch vụ: Inspector quét lỗ hổng phần mềm (CVE). Nó cho biết máy nào có thể bị tấn công, không cho biết máy nào đang bị tấn công.

Ghi nhớ

Bốn dịch vụ trong đề và vai trò thật của từng cái: | Dịch vụ | Phát hiện | |---|---| | Shield Advanced | tấn công DDoS đang diễn ra ← câu này | | Macie | dữ liệu nhạy cảm trong S3 | | Inspector | lỗ hổng phần mềm (CVE) | | Firewall Manager | tài nguyên chưa được bảo vệ trong tổ chức |

Bốn câu hỏi hoàn toàn khác nhau — và đây là nhóm hay bị nhầm nhất trong đề Security Specialty.

Bốn metric của Shield Advanced: | Metric | Cho biết | |---|---| | DDoSDetected | có tấn công hay không (0/1) | | DDoSAttackBitsPerSecond | quy mô tầng 3/4 theo băng thông | | DDoSAttackPacketsPerSecond | quy mô theo gói tin | | DDoSAttackRequestsPerSecond | quy mô tầng 7 (tấn công ứng dụng) |

Metric thứ nhất để báo động; ba metric còn lại để đánh giá mức nghiêm trọng — nên đặt alarm trên cái đầu và ghi biểu đồ ba cái sau.

Tài nguyên bảo vệ được bằng Shield Advanced: | Tài nguyên | |---| | CloudFront distribution | | Route 53 hosted zone | | ALB, NLB, Classic Load Balancer | | Elastic IP | | Global Accelerator |

Ba cấu hình nên bật cùng Shield Advanced: | Cấu hình | Lợi ích | |---|---| | Proactive engagement | SRT tự vào cuộc khi phát hiện tấn công — không cần bạn mở ticket | | Health-based detection | dùng Route 53 health check để phát hiện chính xác hơn | | Alarm trên DDoSDetected | ← câu này |

Dòng đầu là khác biệt lớn nhất về thời gian phản ứng: thay vì bạn phát hiện → mở ticket → chờ tiếp nhận, đội SRT đã đang xử lý từ trước khi bạn kịp đọc email cảnh báo.

Ba lớp phòng thủ DDoS:

Shield Standard   → tầng 3/4, MIỄN PHÍ, tự động cho mọi khách hàng
WAF               → tầng 7 theo quy tắc
Shield Advanced   → nâng cao + SRT + bảo vệ chi phí + METRIC

Và một lưu ý khi đọc metric: DDoSDetected chỉ được phát khi Shield Advanced xác định đây là DDoS. Một đợt tăng tải bất thường do chiến dịch marketing sẽ không kích hoạt nó — nên nên đặt song song alarm trên metric tải thông thường (RequestCount, TargetResponseTime, CPUUtilization) để không bỏ sót vấn đề dung lượng không phải do tấn công.