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

Tìm thấy 445 câu.

Câu 81 Infrastructure Security

A junior developer has been asked to configure access to an Amazon EC2 instance hosting a web application. The developer has configured a new security group to permit incoming HTTP traffic from 0.0.0.0/0 and retained any default outbound rules. A custom Network Access Control List (NACL) connected with the instance's subnet is configured to permit incoming HTTP traffic from 0.0.0.0/0 and retained any default outbound rules.

As a Security Engineer, which of the following solutions would you suggest if the EC2 instance needs to accept and respond to requests from the internet?

A
An outbound rule must be added to the Network ACL (NACL) to allow the response to be sent to the client on the ephemeral port range
B
An outbound rule on the security group has to be configured, to allow the response to be sent to the client on the HTTP port
C
The configuration is complete on the EC2 instance for accepting and responding to requests
D
Outbound rules need to be configured both on the security group and on the NACL for sending responses to the Internet Gateway

Xem giải thích

Đáp án

A — Phải thêm một rule outbound vào Network ACL để phản hồi gửi được về client trên dải cổng tạm (ephemeral port).

Vì sao đúng

Đề mô tả hai lớp cấu hình, và mấu chốt nằm ở khác biệt stateful/stateless:

Security group:  vào HTTP từ 0.0.0.0/0 ✓, giữ outbound mặc định
NACL TUỲ CHỈNH:  vào HTTP từ 0.0.0.0/0 ✓, giữ outbound mặc định

Hai chữ "mặc định" có ý nghĩa hoàn toàn khác nhau ở hai nơi: | | Outbound mặc định | |---|---| | Security group | CHO PHÉP mọi lưu lượng ra | | NACL tuỳ chỉnh (custom) | TỪ CHỐI mọi lưu lượng ra |

Và vì NACL không có trạng thái, phản hồi bị chặn:

Client (cổng tạm 52341) ──HTTP:80──> EC2
    ✓ NACL inbound cho phép 80
    ✓ SG inbound cho phép 80
    ✓ Ứng dụng xử lý

EC2 ──phản hồi tới cổng 52341──> Client
    ✓ SG outbound: stateful → tự động cho qua
    ✗ NACL outbound: KHÔNG có rule cho 52341 → CHẶN

Rule cần thêm:

Rule 100 | Outbound | Custom TCP | Port 1024-65535 | 0.0.0.0/0 | ALLOW

Dải cổng tạm là gì: khi client mở kết nối, hệ điều hành của nó chọn một cổng nguồn ngẫu nhiên ở dải cao. Máy chủ phải gửi phản hồi về đúng cổng đó, không phải về cổng 80.

Hệ điều hành	Dải cổng tạm
Linux hiện đại	32768–60999
Windows (mới)	49152–65535
Khuyến nghị của AWS cho NACL	1024–65535 (bao trọn mọi trường hợp)

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

D. Cần cấu hình rule outbound trên CẢ security group LẪN NACL để gửi phản hồi tới Internet Gateway — đây là phương án gần nhất và thừa một nửa: security group có trạng thái, nên phản hồi cho kết nối đã được chấp nhận tự động được phép mà không cần rule outbound nào. Chỉ NACL cần.
B. Phải cấu hình rule outbound trên security group để gửi phản hồi tới client trên cổng HTTP — sai cả hai vế: security group không cần rule outbound (stateful), và nếu có thì phản hồi đi tới cổng tạm của client, không phải cổng 80.
C. Cấu hình đã hoàn tất, instance nhận và phản hồi được request từ Internet — sai: NACL tuỳ chỉnh chặn chiều ra, nên request tới được nhưng phản hồi không về được. Triệu chứng là kết nối treo rồi timeout.

Ghi nhớ

Bảng phân biệt quan trọng nhất về mạng trong VPC: | | Security group | Network ACL | |---|---|---| | Trạng thái | STATEFUL — phản hồi tự động qua | STATELESS — phải mở CẢ HAI chiều | | Mức | ENI | subnet | | Rule | chỉ Allow | Allow và Deny | | Mặc định (NACL của VPC) | — | cho phép hết | | Mặc định (NACL TỰ TẠO) | — | CHẶN hết |

Hai dòng cuối là bẫy của câu hỏi này: người ta quen với NACL mặc định (thông suốt) rồi tạo NACL tuỳ chỉnh và tưởng nó cũng vậy.

Bộ rule NACL tối thiểu cho web server công khai:

INBOUND
  100 | HTTP  (80)        | 0.0.0.0/0 | ALLOW
  110 | HTTPS (443)       | 0.0.0.0/0 | ALLOW
  120 | Custom TCP 1024-65535 | 0.0.0.0/0 | ALLOW  ← phản hồi cho kết nối RA
  *   | ALL               | 0.0.0.0/0 | DENY

OUTBOUND
  100 | HTTP  (80)        | 0.0.0.0/0 | ALLOW     ← để server gọi ra ngoài
  110 | HTTPS (443)       | 0.0.0.0/0 | ALLOW
  120 | Custom TCP 1024-65535 | 0.0.0.0/0 | ALLOW  ← phản hồi cho client
  *   | ALL               | 0.0.0.0/0 | DENY

Cả hai chiều đều cần rule cổng tạm — vì kết nối có thể khởi tạo từ hai phía: | Rule cổng tạm ở | Phục vụ | |---|---| | Outbound | phản hồi cho client từ Internet ← câu này | | Inbound | phản hồi cho request mà server gửi RA (yum update, gọi API) |

Ba nguyên tắc dùng NACL: | Nguyên tắc | Lý do | |---|---| | Dùng NACL mặc định (thông suốt) trừ khi có nhu cầu rõ ràng | security group đủ cho hầu hết trường hợp | | Dùng NACL khi cần rule DENY | chặn một IP cụ thể — security group không làm được | | Đánh số rule cách nhau 10 hoặc 100 | chừa chỗ chèn rule sau này |

Dòng đầu là lời khuyên thực dụng nhất: NACL là nguồn gốc của rất nhiều sự cố mạng khó chẩn đoán, và phần lớn nhu cầu phân đoạn mạng được security group đáp ứng tốt hơn. Chỉ siết NACL khi có yêu cầu tuân thủ cụ thể hoặc cần chặn theo danh sách đen.

Và về thứ tự đánh giá: NACL xử lý rule theo thứ tự số tăng dần và dừng ở rule khớp đầu tiên. Nên một rule DENY ở số 50 sẽ thắng rule ALLOW ở số 100 — khác hẳn security group, nơi mọi rule đều được xét và không có DENY.

Câu 82 Chọn nhiều đáp án Identity and Access Management

A project manager has connected with you for the resolution of an issue. Although an AWS Identity and Access Management (IAM) entity has admin permissions, it has received an access denied error.

As an AWS Certified Security Specialist, how will you troubleshoot and resolve this issue? (Select two)

A
A session policy is in place and is causing an authorization issue
B
If the requests are routed through a VPC endpoint, then check for any restrictions coming from the associated VPC endpoint policy
C
A resource-based policy defines the maximum permissions that an identity-based policy can grant to an entity. Check for any restrictive resource-based policies
D
An Organization NACL can restrict access to member account IAM entities. Check for restrictions coming from an NACL using the management account of the Organization
E
If you use a permissions boundary, then the entity can only perform actions that are allowed in both the identity-based policy and the concerned resource-based policy. Check for any restrictive permissions boundary

Xem giải thích

Đáp án

A và B.

A — Có một session policy đang áp dụng và gây ra vấn đề uỷ quyền
B — Nếu request đi qua VPC endpoint, kiểm tra các hạn chế đến từ VPC endpoint policy

Vì sao đúng

Đề mô tả nghịch lý quen thuộc: entity có quyền admin nhưng vẫn nhận Access Denied. Điều đó nghĩa là có một lớp giới hạn khác đang chặn.

A — session policy giới hạn phiên assume role:

sts.assume_role(
    RoleArn='arn:aws:iam::123456789012:role/QuanTri',
    RoleSessionName='phien-lam-viec',
    Policy=json.dumps({          # ← session policy
        "Version": "2012-10-17",
        "Statement": [{"Effect": "Allow", "Action": "s3:GetObject",
                       "Resource": "arn:aws:s3:::bucket-cu-the/*"}]
    })
)

Quyền hiệu lực = quyền của role ∩ session policy. Role có AdministratorAccess nhưng session policy chỉ cho s3:GetObject thì phiên đó chỉ làm được đúng chừng đó.

B — VPC endpoint policy chặn ở tầng mạng:

{
  "Effect": "Allow",
  "Principal": "*",
  "Action": ["s3:GetObject"],
  "Resource": "arn:aws:s3:::bucket-duoc-phep/*"
}

Endpoint policy áp cho mọi request đi qua endpoint đó, bất kể principal là ai. Admin gọi API qua endpoint này chỉ làm được những gì endpoint cho phép.

Đây là chỗ đặc biệt khó chẩn đoán vì endpoint policy nằm ở tầng mạng, không phải tầng IAM — người gỡ lỗi thường chỉ nhìn IAM policy và không nghĩ tới nó.

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

E. Nếu dùng permissions boundary, entity chỉ làm được những hành động được phép trong CẢ identity-based policy LẪN resource-based policy liên quan; kiểm tra permissions boundary hạn chế — đây là phương án gần nhất và định nghĩa sai permissions boundary: nó là giao của identity-based policy ∩ permissions boundary, không phải với resource-based policy. (Permissions boundary đúng là một nguyên nhân có thật cho Access Denied — nhưng phát biểu mô tả nó sai.)
C. Resource-based policy định nghĩa quyền TỐI ĐA mà identity-based policy có thể cấp cho một entity; kiểm tra resource-based policy hạn chế — nhầm hai khái niệm: thứ định nghĩa "quyền tối đa" là permissions boundary. Resource-based policy cấp quyền, không đặt trần.
D. Một Organization NACL có thể hạn chế truy cập của IAM entity ở tài khoản thành viên; kiểm tra hạn chế từ NACL bằng tài khoản quản lý — "Organization NACL" không tồn tại. NACL là kiểm soát lưu lượng mạng ở mức subnet, không liên quan tới IAM và không quản lý qua Organizations. Thứ hạn chế ở mức tổ chức là SCP.

Ghi nhớ

Sáu nguyên nhân gây Access Denied dù có quyền admin — danh sách kiểm tra:

① SCP của Organizations từ chối hành động
② Permissions boundary cắt bớt quyền
③ Session policy giới hạn phiên              ← A
④ VPC endpoint policy chặn ở tầng mạng       ← B
⑤ Resource-based policy có explicit Deny
⑥ Điều kiện không thoả (MFA, IP nguồn, Region, thời gian)

Thứ tự đánh giá policy của IAM — hiểu cái này là chẩn đoán được mọi trường hợp:

① Explicit DENY ở BẤT KỲ đâu     → TỪ CHỐI (thắng tuyệt đối)
② SCP có Allow không?             → không có → từ chối
③ Resource-based policy Allow?
④ Identity-based policy Allow?
⑤ Permissions boundary Allow?
⑥ Session policy Allow?
⑦ Qua hết → CHO PHÉP

Ba loại policy đặt TRẦN — không cấp quyền: | Loại | Phạm vi | |---|---| | SCP | tài khoản hoặc OU | | Permissions boundary | một IAM user hoặc role | | Session policy | một phiên assume role |

Công thức quyền hiệu lực:

Quyền = identity-based ∩ SCP ∩ permissions boundary ∩ session policy
        (và không có explicit Deny ở đâu)

Hai công cụ chẩn đoán nên dùng: | Công cụ | Việc | |---|---| | IAM Policy Simulator | mô phỏng một hành động, chỉ ra policy nào chặn | | CloudTrail | errorCode và errorMessage của request bị từ chối | | IAM Access Analyzer | phân tích quyền chưa dùng, tài nguyên chia sẻ ra ngoài |

CloudTrail là nơi bắt đầu tốt nhất trong thực tế: thông báo lỗi thường nêu rõ loại policy nào đã từ chối:

"errorMessage": "User: arn:aws:sts::...:assumed-role/QuanTri/phien
 is not authorized to perform: s3:GetObject ... with an explicit deny
 in a VPC endpoint policy"

Cụm cuối chỉ đúng nguyên nhân — nhưng chỉ khi bạn đọc log thay vì đoán.

Và một lưu ý về session policy: nó không hiện ra ở bất kỳ đâu trong Console IAM vì nó được truyền lúc gọi AssumeRole và chỉ tồn tại trong phiên đó. Nếu ứng dụng hoặc công cụ CI/CD của bạn truyền session policy, người gỡ lỗi nhìn vào IAM sẽ không bao giờ thấy nguyên nhân — phải đọc mã gọi AssumeRole mới biết.

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

A security engineer has configured trusted IP lists and threat lists on Amazon GuardDuty to monitor the security of the AWS environment. Consider the following scenarios:

a) While configuring the lists the engineer mistakenly added the same IP to both lists. What is the outcome of this configuration?

b) To grant the identities full access (such as renaming, deactivating, uploading, activating, deleting) for working with trusted IP lists and threat lists, which managed policy needs to be added? (Select two)

A
Attach AWSServiceRoleForAmazonGuardDuty policy to your IAM entities to provide full access privileges to an identity to work with trusted IP lists and threat lists
B
Attach AmazonGuardDutyFullAccess managed policy to provide full access privileges to an identity to work with trusted IP lists and threat lists. You also need to add the following privileges { "Effect": "Allow", "Action": [ "iam:PutRolePolicy", "iam:DeleteRolePolicy" ], "Resource": "arn:aws:iam::123456789123:role/aws-service-role/guardduty.amazonaws.com/AWSServiceRoleForAmazonGuardDuty" }
C
Attach AmazonGuardDutyFullAccess managed policy to provide full access privileges to an identity to work with trusted IP lists and threat lists
D
The IP will be processed by the trusted IP list first, and will not generate a finding
E
The IP will be processed by the threat IP list first, and will generate findings

Xem giải thích

Đáp án

B và D.

D — IP nằm trong cả hai danh sách sẽ được xử lý bởi TRUSTED IP LIST trước, và không sinh finding
B — Gắn managed policy AmazonGuardDutyFullAccess, và thêm quyền iam:PutRolePolicy và iam:DeleteRolePolicy trên service-linked role AWSServiceRoleForAmazonGuardDuty

Vì sao đúng

D — thứ tự ưu tiên khi một IP nằm trong cả hai danh sách:

GuardDuty đánh giá một IP:
    ① Có trong TRUSTED IP LIST không?  → CÓ → bỏ qua, KHÔNG sinh finding
    ② Có trong THREAT IP LIST không?   → sinh finding

Trusted list luôn thắng — đây là thiết kế hợp lý: danh sách tin cậy là tuyên bố tường minh của bạn về IP đó, nên nó ghi đè mọi cảnh báo tự động.

Hệ quả thực tế cần cẩn thận: thêm nhầm một IP vào trusted list sẽ khiến GuardDuty im lặng hoàn toàn với IP đó — không có cảnh báo nào cho biết bạn vừa tạo ra một điểm mù.

B — quyền bổ sung là chi tiết ít người biết: | Quyền | Vì sao cần | |---|---| | AmazonGuardDutyFullAccess | thao tác cơ bản với GuardDuty | | iam:PutRolePolicy trên service-linked role | GuardDuty phải cập nhật inline policy của SLR để đọc được danh sách trong S3 | | iam:DeleteRolePolicy trên SLR | dọn dẹp khi xoá danh sách |

Lý do kỹ thuật: trusted IP list và threat list được lưu dưới dạng tệp trong S3. Khi bạn thêm một danh sách, GuardDuty phải cấp cho service-linked role của nó quyền đọc đúng object đó — và việc sửa policy của role đòi hai quyền IAM trên.

{
  "Effect": "Allow",
  "Action": ["iam:PutRolePolicy", "iam:DeleteRolePolicy"],
  "Resource": "arn:aws:iam::123456789123:role/aws-service-role/guardduty.amazonaws.com/AWSServiceRoleForAmazonGuardDuty"
}

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

C. Gắn AmazonGuardDutyFullAccess để có toàn quyền làm việc với trusted IP list và threat list — đây là phương án gần nhất và thiếu đúng phần quan trọng: managed policy một mình không đủ cho các thao tác với danh sách IP. Thiếu hai quyền IAM bổ sung thì việc thêm danh sách thất bại.
A. Gắn policy AWSServiceRoleForAmazonGuardDuty cho IAM entity để có toàn quyền — nhầm giữa role và policy: AWSServiceRoleForAmazonGuardDuty là một service-linked role mà chính dịch vụ GuardDuty dùng, không phải policy để gắn cho người dùng của bạn.
E. IP sẽ được xử lý bởi THREAT IP LIST trước và sinh finding — sai thứ tự ưu tiên: trusted list được đánh giá trước và ghi đè.

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, tối đa 2.000 địa chỉ | | Threat IP list | LUÔN sinh finding cho IP này | 6 danh sách, tối đa 250.000 địa chỉ mỗi cái |

Sự bất đối xứng về giới hạn có ý nghĩa: 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.

Định dạng tệp được hỗ trợ: | Định dạng | Ví dụ | |---|---| | Plaintext | mỗi dòng một IP hoặc CIDR | | STIX | chuẩn trao đổi thông tin đe doạ | | OTX CSV, FireEye, Proofpoint, AlienVault | định dạng của các nhà cung cấp |

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ữ được 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, ví dụ dải IP văn phòng cố định.

Ba lưu ý khi dùng trusted IP list: | Lưu ý | Lý do | |---|---| | Rà lại định kỳ | IP được cấp lại cho tổ chức khác | | Chỉ thêm IP tĩnh do bạn kiểm soát | không thêm dải của nhà cung cấp dịch vụ | | Ghi lại lý do từng mục | người sau cần biết vì sao nó ở đó |

Dòng đầu là rủi ro thật: một địa chỉ IP thuê từ nhà cung cấp hôm nay là của bạn, sáu tháng sau có thể thuộc về người khác — và nó vẫn nằm trong trusted list của bạn.

Và một chi tiết về phạm vi: danh sách IP là cấu hình theo Region. Bật GuardDuty ở năm Region nghĩa là phải thêm danh sách ở cả năm — trừ khi bạn dùng mô hình delegated administrator, nơi tài khoản quản trị đặt danh sách áp cho toàn bộ tài khoản thành viên.

Câu 84 Data Protection

A company uses an Amazon S3 bucket to store its business-critical data. Recently, all the members of the development team, that access the given S3 bucket, have been given MFA devices. A security engineer must configure permissions such that access to the given S3 bucket is allowed only after MFA authentication.

How will you implement this requirement?

A
Create an IAM group having the development team users. Add a customer-managed policy with Deny Effect to the group for all s3:*actions with the condition defined as "Condition" : { "Bool" : { "aws:MultiFactorAuthPresent" : "false" } }
B
Create an IAM group having the development team users. Add a customer-managed policy with Deny Effect to the group for all s3:*actions with the condition defined as "Condition" : { "BoolIfExists" : { "aws:MultiFactorAuthPresent" : "false" } }
C
Create an IAM group having the development team users. Add a customer-managed policy with Allow Effect to the group for all s3:*actions with the condition defined as "Condition" : { "BoolIfExists" : { "aws:MultiFactorAuthPresent" : "false" } }
D
Create an IAM group having the development team users. Add a customer managed policy with Allow Effect to the group for all s3:*actions with the condition defined as "Condition": {"BoolIfExists": {"aws:MultiFactorAuthPresent": "true"}}

Xem giải thích

Đáp án

B — Tạo IAM group chứa các thành viên đội phát triển; gắn customer-managed policy với Effect: Deny cho mọi hành động s3:* với điều kiện:

"Condition": { "BoolIfExists": { "aws:MultiFactorAuthPresent": "false" } }

Vì sao đúng

Đề yêu cầu: chỉ cho phép truy cập S3 sau khi xác thực MFA. Có hai quyết định thiết kế, và cả hai đều là bẫy.

Quyết định 1: dùng Deny, không dùng Allow.

Allow có điều kiện MFA:
    → chỉ cấp thêm quyền khi có MFA
    → nếu người dùng đã có quyền S3 từ policy KHÁC, họ vẫn vào được không cần MFA

Deny có điều kiện không-MFA:
    → explicit Deny THẮNG mọi Allow ở mọi nơi
    → chặn chắc chắn

Quyết định 2: dùng BoolIfExists, không dùng Bool — đây là điểm tinh tế nhất: | Toán tử | Khi khoá KHÔNG TỒN TẠI trong request | |---|---| | Bool | điều kiện KHÔNG khớp → Deny KHÔNG áp dụng → cho qua | | BoolIfExists | điều kiện coi như khớp → Deny ÁP DỤNG → chặn |

Vì sao điều đó quan trọng: khoá aws:MultiFactorAuthPresent hoàn toàn vắng mặt trong một số loại request:

Đăng nhập Console có MFA        → aws:MultiFactorAuthPresent = true
Đăng nhập Console không MFA     → aws:MultiFactorAuthPresent = false
Gọi API bằng ACCESS KEY dài hạn → KHOÁ KHÔNG TỒN TẠI  ← chỗ hổng

Với Bool, người dùng chỉ cần dùng access key thay vì Console là đi vòng được toàn bộ chính sách — và không có dấu hiệu nào cho thấy điều đó đang xảy ra.

{
  "Effect": "Deny",
  "Action": "s3:*",
  "Resource": "*",
  "Condition": {
    "BoolIfExists": {"aws:MultiFactorAuthPresent": "false"}
  }
}

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

A. Deny cho s3:* với điều kiện Bool thay vì BoolIfExists — đây là phương án gần nhất và có lỗ hổng vừa phân tích: request bằng access key dài hạn không mang khoá MFA, nên Bool không khớp và Deny không áp dụng.
C. Allow cho s3:* với điều kiện BoolIfExists là false — ngược hoàn toàn: nó CHO PHÉP truy cập khi KHÔNG có MFA. Đúng trái ngược yêu cầu.
D. Allow cho s3:* với điều kiện BoolIfExists là true — ý định đúng nhưng cơ chế yếu: nó cấp quyền khi có MFA, nhưng không chặn các đường vào khác. Nếu người dùng có quyền S3 từ policy khác (managed policy, quyền qua role), họ vẫn truy cập được không cần MFA.

Ghi nhớ

Hai toán tử điều kiện và cách xử lý khoá vắng mặt: | Toán tử | Khoá không tồn tại | |---|---| | Bool | điều kiện thất bại → statement không áp dụng | | BoolIfExists | coi như khớp → statement áp dụng | | Null | kiểm tra chính việc khoá có tồn tại hay không |

Quy tắc thực dụng:

Với statement Deny để bắt buộc một điều kiện bảo mật → luôn dùng ...IfExists. Nếu không, request thiếu khoá đó sẽ lọt qua.

Mẫu này áp cho mọi toán tử: StringEqualsIfExists, ArnEqualsIfExists, NumericLessThanIfExists...

Ba condition key liên quan tới MFA: | Key | Cho biết | |---|---| | aws:MultiFactorAuthPresent | request có dùng MFA không (Bool) | | aws:MultiFactorAuthAge | MFA được xác thực cách đây bao nhiêu GIÂY | | aws:TokenIssueTime | thời điểm token STS được cấp |

Dòng thứ hai chặt hơn dòng đầu cho thao tác nhạy cảm:

{"Condition": {"NumericGreaterThanIfExists": {
   "aws:MultiFactorAuthAge": "3600"}}}

Kết hợp với Deny, nó buộc người dùng xác thực lại MFA nếu phiên đã quá một giờ — ngăn việc dùng một phiên cũ cho thao tác quan trọng.

Một cảnh báo quan trọng khi triển khai chính sách MFA:

Deny s3:* khi không có MFA, áp cho TOÀN BỘ tài khoản
    → EC2 instance dùng IAM role gọi S3 cũng bị chặn
    → Lambda function bị chặn
    → CI/CD pipeline bị chặn

Danh tính dịch vụ không có MFA, và không thể có. Nên chính sách này phải áp đúng nhóm người dùng (như đề mô tả: một IAM group cho đội phát triển), hoặc chừa ngoại lệ cho role dịch vụ:

{"Effect": "Deny", "Action": "s3:*", "Resource": "*",
 "Condition": {
   "BoolIfExists": {"aws:MultiFactorAuthPresent": "false"},
   "ArnNotLike": {"aws:PrincipalArn": "arn:aws:iam::*:role/role-ung-dung-*"}
 }}

Ba loại thiết bị MFA: | Loại | Đặc điểm | |---|---| | Ứng dụng ảo (TOTP) | Google Authenticator, Authy — phổ biến nhất | | Khoá bảo mật (FIDO2/WebAuthn) | YubiKey — chống lừa đảo tốt nhất | | Thiết bị phần cứng TOTP | token vật lý |

Khoá FIDO2 vượt trội cho tài khoản quan trọng: nó ràng buộc vào tên miền thật, nên trang lừa đảo không lấy được mã — điều mà TOTP không chống được.

Câu 85 Chọn nhiều đáp án Identity and Access Management

A financial services company wants to develop a solution called Financial Information System (FIS) on AWS Cloud that would allow the financial institutions and government agencies to collaborate, anticipate and navigate the changing finance landscape. While pursuing this endeavor, the company would like to decrease its IT operational overhead. The solution should help the company eliminate the bottleneck created by manual provisioning of development pipelines while adhering to crucial governance and control requirements. As a means to this end, the company has set up "AWS Organizations" to manage several of these scenarios and would like to use Service Control Policies (SCP) for central control over the maximum available permissions for the various accounts in their organization. This allows the organization to ensure that all accounts stay within the organization’s access control guidelines.

Which of the following scenarios would you identify as correct regarding the given use-case? (Select three)

A
SCPs do not affect service-linked role
B
SCPs affect all users and roles in attached accounts, excluding the root user
C
If a user or role has an IAM permission policy that grants access to an action that is either not allowed or explicitly denied by the applicable SCPs, the user or role can't perform that action
D
SCPs affect service-linked roles
E
SCPs affect all users and roles in attached accounts, including the root user
F
If a user or role has an IAM permission policy that grants access to an action that is either not allowed or explicitly denied by the applicable SCPs, the user or role can still perform that action

Xem giải thích

Đáp án

A, C và E:

A — SCP KHÔNG ảnh hưởng tới service-linked role
C — Nếu một user hoặc role có IAM permission policy cho phép một hành động mà SCP không cho phép hoặc từ chối tường minh, thì user/role đó KHÔNG thực hiện được hành động đó
E — SCP ảnh hưởng tới mọi user và role trong các tài khoản được gắn, BAO GỒM cả root user

Vì sao đúng

Ba phát biểu này mô tả đúng ba đặc tính cốt lõi của SCP.

C — SCP là TRẦN, không phải nguồn quyền:

Quyền hiệu lực = IAM policy ∩ SCP

IAM: Allow s3:*        SCP: Deny s3:DeleteBucket
    → xoá bucket: KHÔNG được
    → các thao tác S3 khác: được

SCP không bao giờ CẤP quyền — nó chỉ giới hạn những gì IAM policy có thể cấp.

E — SCP áp cho cả root user của tài khoản thành viên — đây là điểm mạnh nhất của SCP:

IAM policy:            root user vượt qua được (root không bị IAM policy ràng buộc)
Permissions boundary:  không áp cho root
SCP:                   ÁP CHO CẢ ROOT của tài khoản thành viên ✓

Đây là lý do SCP là rào chắn thật sự — quản trị viên tài khoản thành viên, kể cả với thông tin đăng nhập root, cũng không vượt qua được.

A — ngoại lệ cho service-linked role:

Service-linked role (AWSServiceRoleForAutoScaling, ...ForOrganizations, ...)
    → do chính dịch vụ AWS tạo và quản lý
    → SCP KHÔNG áp dụng

Lý do thiết kế: nếu SCP chặn được SLR, một chính sách quá rộng có thể làm hỏng chính các dịch vụ AWS đang vận hành hạ tầng — ví dụ chặn Auto Scaling khiến ứng dụng không mở rộng được, mà nguyên nhân thì rất khó lần ra.

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

(Ba phương án còn lại là phủ định trực tiếp của ba đáp án đúng.)

B. SCP ảnh hưởng tới mọi user và role trong tài khoản được gắn, LOẠI TRỪ root user — mâu thuẫn với E. Đây là hiểu lầm phổ biến nhất về SCP, có lẽ vì người ta suy từ hành vi của IAM policy sang.
D. SCP CÓ ảnh hưởng tới service-linked role — mâu thuẫn với A.
F. Nếu user/role có IAM policy cho phép một hành động mà SCP không cho phép, user/role đó VẪN thực hiện được — mâu thuẫn với C, và hiểu sai bản chất của SCP như một trần quyền.

Ghi nhớ

Bốn đặc tính của SCP — bảng cần thuộc: | Đặc tính | Chi tiết | |---|---| | KHÔNG cấp quyền | chỉ giới hạn; vẫn cần IAM policy Allow | | ÁP cho root user của tài khoản THÀNH VIÊN | ← điểm mạnh chính | | KHÔNG áp cho tài khoản QUẢN LÝ | rào chắn không bảo vệ chính tài khoản gốc | | KHÔNG áp cho service-linked role | tránh làm hỏng dịch vụ AWS |

Dòng thứ ba là hạn chế quan trọng nhất về mặt kiến trúc: nó dẫn tới khuyến nghị không đặt workload nào trong tài khoản quản lý — tài khoản đó chỉ nên dùng để quản lý tổ chức và thanh toán.

Ba loại policy đặt trần — phân biệt phạm vi: | Loại | Phạm vi | Áp cho root? | |---|---|---| | SCP | tài khoản hoặc OU | ✅ (tài khoản thành viên) | | Permissions boundary | một IAM user/role | ❌ | | Session policy | một phiên | ❌ |

Hai chiến lược viết SCP: | Chiến lược | Cách làm | AWS khuyến nghị | |---|---|---| | Deny list | giữ FullAWSAccess, thêm SCP Deny | ✅ cho hầu hết trường hợp | | Allow list | gỡ FullAWSAccess, chỉ Allow cái cần | chỉ cho môi trường rất hạn chế |

Chiến lược allow list rất dễ gây sự cố: thiếu một dịch vụ phụ thuộc là hỏng vận hành, và dịch vụ AWS mới ra đời sẽ mặc định bị chặn.

Cách SCP kế thừa trong cây tổ chức:

Root
 └── OU Sản xuất        (SCP-A)
      └── OU Tài chính  (SCP-B)
           └── Tài khoản X

Quyền của X = FullAWSAccess ∩ SCP gắn ở Root ∩ SCP-A ∩ SCP-B ∩ SCP gắn trực tiếp

Mọi SCP trên đường đi từ gốc xuống đều áp dụng, và chúng GIAO nhau — không phải hợp. Một Deny ở bất kỳ mức nào là chặn.

Ba nhóm hành động nên chặn bằng SCP ở gốc tổ chức: | Nhóm | Ví dụ | |---|---| | Bảo vệ cơ chế giám sát | cloudtrail:StopLogging, guardduty:DeleteDetector, config:DeleteConfigurationRecorder | | Bảo vệ tổ chức | organizations:LeaveOrganization | | Bảo vệ dữ liệu | kms:ScheduleKeyDeletion, s3:DeleteBucket cho bucket log | | Giới hạn Region | NotAction + aws:RequestedRegion (xem câu #7733) |

Và một lưu ý khi kiểm thử: Deny trong SCP không hiện trong IAM Policy Simulator theo mặc định ở mọi trường hợp. Cách chắc chắn là áp lên một OU thử nghiệm với một tài khoản không quan trọng, rồi mới mở rộng — SCP sai có thể làm ngưng vận hành cả tổ chức, và bản thân việc sửa nó cũng cần quyền ở tài khoản quản lý.

Câu 86 Chọn nhiều đáp án Management and Security Governance

A company's security policy mandates enforcing VPC Flow Logs for all the VPCs defined on AWS. A Security Engineer has been tasked to automate this compliance check and subsequently inform the governance teams if any VPC is found to be non-compliant.

Which steps will you combine for automating the process to meet the compliance guidelines? (Select two)

A
Create a Lambda function that polls Config to detect non-compliant resources daily and send notifications via Amazon SNS
B
Create a Lambda function containing the logic to determine if a resource is compliant or non-compliant. Create an Amazon CloudWatch Event rule that triggers when the state of the earlier declared Lambda function changes to non-compliant
C
Create a Lambda function that checks the AWS Athena query status on a daily basis for detecting any non-compliant resources daily and sending notifications via Amazon SNS
D
Create a Lambda function containing the logic to determine if a resource is compliant or non-compliant. Create a custom Config rule that uses this Lambda function as its source
E
Publish VPC Flow Logs to Amazon S3 bucket and query the data with AWS Athena for determining the non-compliant resources

Xem giải thích

Đáp án

A và D.

D — Tạo một Lambda function chứa logic xác định tài nguyên có tuân thủ hay không; tạo một custom Config rule dùng Lambda đó làm nguồn
A — Tạo một Lambda function hỏi Config để phát hiện tài nguyên không tuân thủ hằng ngày và gửi thông báo qua SNS

Vì sao đúng

Đề yêu cầu tự động kiểm tra tuân thủ (mọi VPC phải bật Flow Logs) và thông báo cho đội quản trị nếu có VPC vi phạm. Cặp D+A tách rõ hai việc:

D: ĐÁNH GIÁ
   Config rule (nguồn là Lambda) → xác định VPC nào không tuân thủ
        ↓
A: THÔNG BÁO
   Lambda hằng ngày đọc kết quả Config → SNS → đội quản trị

Vì sao AWS Config là công cụ đúng cho phần đánh giá: | Đặc điểm | Chi tiết | |---|---| | Đánh giá liên tục | không phải quét thủ công | | Lưu lịch sử tuân thủ | trả lời được "VPC này có tuân thủ hồi tháng trước không" | | Áp cho tài nguyên mới tự động | VPC mới tạo được đánh giá ngay | | Tích hợp Security Hub | finding hiện trong bảng điều khiển chung |

Cấu trúc một custom Config rule:

def lambda_handler(event, context):
    config = boto3.client('config')
    item = json.loads(event['invokingEvent'])['configurationItem']
    vpc_id = item['resourceId']

    logs = boto3.client('ec2').describe_flow_logs(
        Filters=[{'Name': 'resource-id', 'Values': [vpc_id]}])
    tuan_thu = 'COMPLIANT' if logs['FlowLogs'] else 'NON_COMPLIANT'

    config.put_evaluations(
        Evaluations=[{
            'ComplianceResourceType': item['resourceType'],
            'ComplianceResourceId': vpc_id,
            'ComplianceType': tuan_thu,
            'OrderingTimestamp': item['configurationItemCaptureTime']}],
        ResultToken=event['resultToken'])

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

**B. Tạo Lambda chứa logic đánh giá; tạo CloudWatch Event rule kích hoạt khi TRẠNG THÁI CỦA LAMBDA FUNCTION đổi sang non-compliant — mô tả một cơ chế không tồn tại: Lambda function không có "trạng thái tuân thủ". Trạng thái tuân thủ là thuộc tính của tài nguyên được đánh giá bởi Config, không phải của hàm đánh giá.
E. Publish VPC Flow Logs lên S3 và truy vấn bằng Athena để xác định tài nguyên không tuân thủ — vòng luẩn quẩn: bạn đang tìm những VPC CHƯA BẬT Flow Logs. VPC không tuân thủ thì không có log nào để truy vấn — Athena chỉ thấy được các VPC đã tuân thủ.
C. Tạo Lambda kiểm tra trạng thái truy vấn Athena hằng ngày để phát hiện tài nguyên không tuân thủ — thừa hưởng cùng lỗi logic của E, và thêm một tầng gián tiếp không cần thiết.

Ghi nhớ

Hai loại Config rule: | Loại | Nguồn | |---|---| | Managed rule | AWS viết sẵn — hàng trăm rule | | Custom rule | Lambda function hoặc Guard policy của bạn |

Hai chế độ kích hoạt: | Chế độ | Chạy khi | |---|---| | Configuration change | tài nguyên thay đổi — phản ứng nhanh | | Periodic | theo lịch: 1, 3, 6, 12, 24 giờ |

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

Có một managed rule sẵn cho đúng bài toán này: vpc-flow-logs-enabled. AWS đã viết nó, nên không cần viết custom rule như phương án D mô tả:

aws configservice put-config-rule --config-rule '{
  "ConfigRuleName": "vpc-flow-logs-enabled",
  "Source": {"Owner": "AWS", "SourceIdentifier": "VPC_FLOW_LOGS_ENABLED"}}'

Và phương án A (Lambda hỏi Config hằng ngày) cũng không phải cách gọn nhất. Config phát sự kiện thay đổi tuân thủ trực tiếp sang EventBridge:

{
  "source": ["aws.config"],
  "detail-type": ["Config Rules Compliance Change"],
  "detail": {
    "configRuleName": ["vpc-flow-logs-enabled"],
    "newEvaluationResult": {"complianceType": ["NON_COMPLIANT"]}
  }
}

Đặt target là SNS là xong — không cần Lambda, không cần lịch chạy hằng ngày, và thông báo tới ngay thay vì chờ tới lượt quét kế tiếp.

Nên giải pháp gọn nhất trong thực tế là:

Managed rule vpc-flow-logs-enabled  →  EventBridge  →  SNS

Không có Lambda nào cả.

D+A vẫn là cặp đúng trong bốn phương án — chúng là hai bước duy nhất hoạt động về mặt logic, còn B mô tả cơ chế không có thật và C, E mắc lỗi vòng luẩn quẩn. Nhưng nếu bạn triển khai thật, đừng lấy chúng làm mẫu.

Ba managed rule liên quan tới mạng đáng bật: | Rule | Kiểm tra | |---|---| | vpc-flow-logs-enabled | VPC có bật Flow Logs không | | vpc-default-security-group-closed | security group mặc định không có rule nào | | restricted-ssh | không có SG nào mở cổng 22 ra 0.0.0.0/0 | | vpc-sg-open-only-to-authorized-ports | chỉ mở các cổng được duyệt |

Và một khả năng của Config đáng dùng kèm: remediation action với SSM Automation document — nó tự bật Flow Logs cho VPC vi phạm thay vì chỉ báo. Với một yêu cầu tuân thủ bắt buộc như đề mô tả, tự khắc phục hợp lý hơn là gửi email rồi chờ người xử lý.

Câu 87 Security Logging and Monitoring

A security specialist with administrator permissions is using the AWS management console to access the CloudWatch logs for a Lambda function named "myFunc". However, upon choosing the option to view the logs in the AWS Lambda console, the specialist encountered an error message reading "error loading Log Streams". The specialist was unable to retrieve the logs as desired and must now find a solution to this issue.

Following is an example IAM policy for the Lambda function's execution role:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "logs:CreateLogGroup",
            "Resource": "arn:aws:logs:<region>:<accountId>:*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "logs:PutLogEvents"
            ],
            "Resource": [
                "arn:aws:logs:<region>:<accountId>:log-group:/aws/lambda/myFunc:*"
            ]
        }
    ]
}

Which of the following solutions would you suggest to the specialist for addressing the issue?

A
Add the logs:GetLogEvents action to the second Allow statement
B
Add the logs:DescribeLogStreams action to the second Allow statement
C
Move the logs:CreateLogGroup action to the second Allow statement
D
Add the logs:CreateLogStream action to the second Allow statement

Xem giải thích

Đáp án

D — Thêm hành động logs:CreateLogStream vào statement Allow thứ hai.

Vì sao đúng

Đề đưa ra một IAM policy và một thông báo lỗi cụ thể — và mấu chốt nằm ở chỗ thiếu đúng một quyền.

Policy hiện tại có gì:

✓ logs:CreateLogGroup   → tạo được LOG GROUP
✗ logs:CreateLogStream  → KHÔNG tạo được LOG STREAM
✓ logs:PutLogEvents     → ghi được sự kiện... nếu có stream

Ba cấp bậc trong CloudWatch Logs — và vì sao thiếu cấp giữa là hỏng:

Log group    /aws/lambda/myFunc          ← tạo được ✓
    └── Log stream  2026/08/30/[$LATEST]abc123   ← KHÔNG tạo được ✗
            └── Log event  "dòng log thực tế"     ← không có chỗ để ghi

Mỗi lần Lambda chạy trên một execution environment mới, nó cần tạo một log stream mới. Không có quyền đó thì: | Hậu quả | Chi tiết | |---|---| | Log group tồn tại nhưng RỖNG | không có stream nào bên trong | | Console báo "error loading Log Streams" | ← đúng thông báo trong đề | | Lambda vẫn CHẠY BÌNH THƯỜNG | ghi log thất bại không làm hàm lỗi |

Dòng cuối là điều khiến lỗi này khó phát hiện: hàm hoạt động đúng, chỉ là không có log — nên vấn đề thường chỉ lộ ra khi ai đó cần gỡ lỗi.

Policy sau khi sửa:

{
  "Effect": "Allow",
  "Action": ["logs:CreateLogStream", "logs:PutLogEvents"],
  "Resource": ["arn:aws:logs:<region>:<accountId>:log-group:/aws/lambda/myFunc:*"]
}

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

B. Thêm logs:DescribeLogStreams vào statement thứ hai — đây là phương án gần nhất và liên quan tới việc ĐỌC log, không phải GHI: DescribeLogStreams là quyền mà người xem cần để liệt kê stream. Nhưng đề nói rõ chuyên viên có quyền admin, nên họ đã có quyền đọc. Vấn đề là không có stream nào để liệt kê.
A. Thêm logs:GetLogEvents vào statement thứ hai — cùng loại nhầm lẫn: đó là quyền đọc nội dung log, thuộc về người xem chứ không phải execution role của Lambda.
C. Chuyển logs:CreateLogGroup sang statement thứ hai — không thêm quyền nào cả: nó chỉ đổi phạm vi Resource của một quyền đã có, và CreateLogStream vẫn thiếu.

Ghi nhớ

Ba quyền CloudWatch Logs mà mọi Lambda execution role cần:

logs:CreateLogGroup    → tạo log group (một lần)
logs:CreateLogStream   → tạo stream cho mỗi execution environment  ← hay thiếu
logs:PutLogEvents      → ghi từng dòng log

Managed policy AWSLambdaBasicExecutionRole chứa đúng ba quyền này — dùng nó là cách an toàn nhất:

{
  "Effect": "Allow",
  "Action": ["logs:CreateLogGroup", "logs:CreateLogStream", "logs:PutLogEvents"],
  "Resource": "arn:aws:logs:*:*:*"
}

Ba cấp bậc của CloudWatch Logs: | Cấp | Ví dụ | Ai tạo | |---|---|---| | Log group | /aws/lambda/myFunc | một lần, khi hàm chạy lần đầu | | Log stream | 2026/08/30/[$LATEST]abc | mỗi execution environment một cái | | Log event | một dòng log | mỗi lần ghi |

Ba triệu chứng thiếu quyền log và nguyên nhân: | Triệu chứng | Thiếu | |---|---| | "error loading Log Streams" | logs:CreateLogStream ← câu này | | Không có log group nào | logs:CreateLogGroup | | Có stream nhưng rỗng | logs:PutLogEvents |

Ba managed policy cho Lambda execution role: | Policy | Quyền | |---|---| | AWSLambdaBasicExecutionRole | ba quyền log cơ bản | | AWSLambdaVPCAccessExecutionRole | + tạo/xoá ENI cho Lambda trong VPC | | AWSLambdaSQSQueueExecutionRole | + đọc từ SQS | | AWSXRayDaemonWriteAccess | + gửi trace sang X-Ray |

Dòng thứ hai đáng nhớ: Lambda chạy trong VPC cần thêm ec2:CreateNetworkInterface, DescribeNetworkInterfaces, DeleteNetworkInterface — thiếu chúng thì hàm không khởi động được và lỗi khá tối nghĩa.

Hai cân nhắc về chi phí log của Lambda: | Cân nhắc | Chi tiết | |---|---| | Log không có hạn giữ mặc định | giữ VĨNH VIỄN — chi phí tích luỹ mãi | | Đặt retention cho mọi log group | 7, 14, 30 ngày tuỳ nhu cầu |

Dòng đầu là khoản chi bất ngờ rất phổ biến: hàng trăm log group của Lambda giữ log từ nhiều năm trước. Nên đặt retention ngay từ đầu:

aws logs put-retention-policy   --log-group-name /aws/lambda/myFunc --retention-in-days 14

Và một mẹo vận hành: tạo sẵn log group với retention và mã hoá KMS trước khi triển khai hàm. Nếu để Lambda tự tạo, log group sẽ không có retention và không mã hoá — và sửa sau thì phải nhớ làm cho từng hàm một.

Câu 88 Security Logging and Monitoring

An application hosted on an Amazon EC2 instance writes its request logs, availability logs, and threat logs to a text file. This file is read by a custom program to track and process any security issues inferred from the logs. An increase in log data has resulted in the malfunctioning of the custom program. The company is looking at a scalable solution to collect and analyze log files.

Which design will ensure that the aforementioned criteria are met with the LEAST amount of effort?

A
Create a scheduled process to copy the application log files to AWS CloudTrail. Configure a Lambda function that processes CloudTrail logs and sends an SNS notification whenever a log file is created
B
Create a cron job on the Amazon EC2 instance to copy the logs into the Amazon S3 bucket. Use S3 events to trigger a Lambda function that refreshes Amazon CloudWatch metrics with the log data. Set up CloudWatch alerts based on the metrics
C
Install and configure the unified CloudWatch agent on the application's EC2 instance. Create a CloudWatch metric filter to monitor the application logs. Configure CloudWatch alerts based on these metrics
D
Configure Amazon Inspector to collect all log files from the EC2 instance. Use Amazon EventBridge integration with Amazon Inspector to trigger Lambda function that can read the logs and raise notifications for events on security

Xem giải thích

Đáp án

C — Cài và cấu hình unified CloudWatch agent trên EC2 instance của ứng dụng; tạo CloudWatch metric filter để giám sát log; cấu hình CloudWatch alarm dựa trên các metric đó.

Vì sao đúng

Đề mô tả vấn đề rõ: chương trình tự viết đọc tệp log đã quá tải, và cần giải pháp mở rộng được với ít công nhất.

CloudWatch agent giải quyết đúng nguyên nhân:

Trước:  Ứng dụng ghi tệp log
            ↓
        Chương trình tự viết đọc tệp  ← nghẽn ở đây
            ↓
        Xử lý vấn đề bảo mật

Sau:    Ứng dụng ghi tệp log
            ↓ CloudWatch agent đẩy lên liên tục
        CloudWatch Logs (không giới hạn dung lượng)
            ↓ metric filter đếm mẫu
        Metric → Alarm → SNS

Bốn lý do đây là "ít công nhất": | Lý do | Chi tiết | |---|---| | Không phải viết mã | agent + metric filter là cấu hình thuần | | Không cần lịch chạy hay cron | agent đẩy log liên tục | | Không giới hạn quy mô | CloudWatch Logs là dịch vụ được quản lý | | Không sửa ứng dụng | agent đọc chính tệp log đang có |

Cấu hình agent:

{
  "logs": {
    "logs_collected": {
      "files": {
        "collect_list": [{
          "file_path": "/var/log/ung-dung/bao-mat.log",
          "log_group_name": "/ung-dung/bao-mat",
          "log_stream_name": "{instance_id}"
        }]
      }}}}

Metric filter tìm mẫu bảo mật:

[..., trang_thai = "THREAT", ...]
{ $.loai = "canh_bao_bao_mat" && $.muc_do = "CAO" }

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

B. Tạo cron job trên EC2 sao chép log vào S3; dùng S3 event kích hoạt Lambda cập nhật CloudWatch metric; đặt alarm dựa trên metric — đây là phương án gần nhất và hoạt động được, nhưng nó nhiều công hơn hẳn: phải viết cron, viết Lambda, quản lý execution role. Và cron job chạy theo chu kỳ nên có độ trễ, trong khi agent đẩy log liên tục.
A. Tạo tiến trình theo lịch sao chép tệp log vào AWS CloudTrail; Lambda xử lý log CloudTrail và gửi SNS — không thực hiện được: CloudTrail không nhận log do bạn đẩy vào. Nó là dịch vụ ghi lời gọi API AWS, tự sinh dữ liệu chứ không phải nơi lưu trữ log tuỳ ý.
D. Cấu hình Amazon Inspector thu thập mọi tệp log từ EC2 instance; dùng tích hợp EventBridge kích hoạt Lambda đọc log — sai chức năng: Inspector quét lỗ hổng bảo mật (CVE, cấu hình mạng). Nó không thu thập tệp log ứng dụng.

Ghi nhớ

Ba khả năng của unified CloudWatch agent: | Khả năng | Chi tiết | |---|---| | Thu thập LOG | tệp log tuỳ ý, Windows Event Log, systemd journal | | Thu thập METRIC hệ thống | bộ nhớ, dung lượng đĩa — những thứ CloudWatch KHÔNG tự có | | Thu thập trace | qua OpenTelemetry, X-Ray |

Dòng giữa đáng nhớ: CloudWatch mặc định không đo được RAM và dung lượng đĩa còn trống của EC2 — vì đó là thông tin bên trong hệ điều hành. Phải có agent.

Ba thành phần của cảnh báo dựa trên log:

Log group  →  Metric filter  →  Metric  →  Alarm  →  SNS

Cú pháp filter pattern:

// Log dạng văn bản thường
"ERROR"                                    // chứa chuỗi
[ip, user, timestamp, request, status_code = 5*]  // theo vị trí trường

// Log dạng JSON
{ $.muc_do = "LOI" }
{ $.muc_do = "LOI" && $.ma_loi != 404 }
{ $.thoi_gian_phan_hoi > 3000 }

Ghi log dạng JSON đáng làm ngay từ đầu: filter pattern cho JSON mạnh hơn nhiều (so sánh số, kết hợp điều kiện, truy cập trường lồng nhau) so với khớp chuỗi thuần.

Ba lựa chọn phân tích log — chọn theo nhu cầu: | Công cụ | Dùng khi | |---|---| | Metric filter + alarm | cảnh báo theo ngưỡng, gần thời gian thực ← câu này | | CloudWatch Logs Insights | điều tra ad-hoc bằng truy vấn | | Xuất sang S3 + Athena | phân tích lịch sử dài hạn, chi phí lưu trữ thấp | | OpenSearch | bảng điều khiển trực quan, tìm kiếm toàn văn |

Ba lựa chọn đầu thường dùng cùng nhau: alarm cho cảnh báo tức thì, Insights cho điều tra khi có cảnh báo, S3+Athena cho lưu trữ lâu dài và phân tích xu hướng.

Ba lưu ý về chi phí CloudWatch Logs: | Lưu ý | Chi tiết | |---|---| | Tính phí theo dữ liệu NẠP VÀO | lọc bớt ở phía agent nếu log quá ồn | | Đặt retention cho mọi log group | mặc định là giữ VĨNH VIỄN | | Chuyển log cũ sang S3 | rẻ hơn nhiều cho lưu trữ dài hạn |

Và một cải thiện đáng cân nhắc cho chính bài toán của đề: thay vì để ứng dụng ghi ra tệp rồi agent đọc lại, có thể dùng CloudWatch Logs SDK ghi thẳng hoặc cấu hình awslogs driver nếu ứng dụng chạy trong container — bỏ hẳn khâu tệp trung gian. Nhưng cách đó đòi sửa ứng dụng, nên với yêu cầu "least effort" của đề thì agent là lựa chọn đúng.

Câu 89 Identity and Access Management

The security team at a company has recently decided that CloudTrail logs of each department will be prefixed with the department code. Currently, CloudTrail logs are created with similar names across the company with no immediate way of identifying the departments sending those logs. When the security team tried to add the prefix to the log files in the CloudTrail console, the following error popped up: 'There is a problem with the bucket policy'.

How will you fix this issue?

A
Update the permissions of all users in the security team to AWSCloudTrail_FullAccess policy to impart all the necessary permissions to the users on CloudTrail logs
B
Use the Amazon S3 console to update the prefix in the current bucket policy, and then use the CloudTrail console to specify the same prefix for the bucket in the trail
C
Manually edit your Amazon S3 bucket policy to add an aws:SourceArn condition key to the policy statement attached for CloudTrail
D
Update the service-specific context keys used in the Condition element of the Amazon S3 bucket policy statements

Xem giải thích

Đáp án

B — Dùng Console của Amazon S3 để cập nhật prefix trong bucket policy hiện tại, rồi dùng Console của CloudTrail để khai đúng prefix đó cho bucket trong trail.

Vì sao đúng

Đề mô tả lỗi rất cụ thể: thêm prefix trong CloudTrail Console thì hiện "There is a problem with the bucket policy".

Nguyên nhân: bucket policy ràng buộc theo đường dẫn CỤ THỂ, và prefix mới không khớp.

Bucket policy hiện tại cho phép ghi vào:
    arn:aws:s3:::bucket-log/AWSLogs/123456789012/*

CloudTrail với prefix "phong-ke-toan" muốn ghi vào:
    arn:aws:s3:::bucket-log/phong-ke-toan/AWSLogs/123456789012/*
                            ^^^^^^^^^^^^^ không khớp policy

→ CloudTrail kiểm tra trước khi lưu trail và báo lỗi

Điểm đáng khen của CloudTrail ở đây: nó kiểm tra quyền TRƯỚC. Nếu không, trail sẽ được tạo thành công rồi âm thầm không ghi được log nào — một lỗi nguy hiểm hơn nhiều cho một hệ thống kiểm toán.

Thứ tự sửa quan trọng: bucket policy TRƯỚC, CloudTrail SAU.

① Sửa bucket policy để chấp nhận prefix mới
② Rồi mới khai prefix trong CloudTrail

Làm ngược lại thì bước ② vẫn báo đúng lỗi đó.

Bucket policy sau khi sửa:

{
  "Sid": "AWSCloudTrailWrite",
  "Effect": "Allow",
  "Principal": {"Service": "cloudtrail.amazonaws.com"},
  "Action": "s3:PutObject",
  "Resource": "arn:aws:s3:::bucket-log/phong-ke-toan/AWSLogs/123456789012/*",
  "Condition": {
    "StringEquals": {"s3:x-amz-acl": "bucket-owner-full-control"}
  }
}

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

C. Sửa tay bucket policy để thêm condition key aws:SourceArn vào statement cho CloudTrail — đây là phương án gần nhất và là thực hành bảo mật tốt (chống confused deputy), nhưng nó không giải quyết vấn đề của đề: lỗi nằm ở đường dẫn Resource không khớp prefix, không phải ở việc thiếu ràng buộc nguồn.
D. Cập nhật các service-specific context key dùng trong phần Condition của bucket policy — mơ hồ và không đúng chỗ: vấn đề nằm ở phần Resource, không phải phần Condition.
A. Cập nhật quyền của mọi người dùng trong đội bảo mật thành AWSCloudTrail_FullAccess — nhầm chủ thể: lỗi không phải do người dùng thiếu quyền, mà do bucket policy không cho phép DỊCH VỤ CloudTrail ghi vào đường dẫn mới. Cấp thêm quyền cho người dùng không thay đổi gì.

Ghi nhớ

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

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

Prefix nằm TRƯỚC AWSLogs/ — đây là chi tiết cần nhớ khi viết Resource trong bucket policy.

Ba statement bắt buộc trong bucket policy cho CloudTrail: | Sid | Action | Mục đích | |---|---|---| | AWSCloudTrailAclCheck | s3:GetBucketAcl | CloudTrail kiểm tra bucket tồn tại và có quyền | | AWSCloudTrailWrite | s3:PutObject | ghi tệp log | | — | với s3:x-amz-acl = bucket-owner-full-control | đảm bảo chủ bucket sở hữu tệp |

Thiếu statement đầu là lỗi hay gặp: nó không ghi log nhưng CloudTrail cần nó để xác nhận cấu hình lúc tạo trail.

Condition key nên có cho bảo mật:

"Condition": {
  "StringEquals": {
    "s3:x-amz-acl": "bucket-owner-full-control",
    "aws:SourceArn": "arn:aws:cloudtrail:ap-northeast-1:123456789012:trail/trail-chinh"
  }}

Key	Chống lại
`s3:x-amz-acl`	tệp log thuộc sở hữu người khác
`aws:SourceArn`	confused deputy — trail của tài khoản khác ghi vào bucket của bạn

aws:SourceArn là điều AWS khuyến nghị bổ sung cho mọi bucket policy của CloudTrail — nội dung của phương án C, đúng về bảo mật nhưng không phải nguyên nhân lỗi ở đây.

Ba lỗi bucket policy thường gặp với CloudTrail: | Lỗi | Nguyên nhân | |---|---| | "There is a problem with the bucket policy" | Resource không khớp đường dẫn thật (prefix) ← câu này | | Trail tạo được nhưng không có log | thiếu s3:PutObject cho đúng đường dẫn | | Ghi được nhưng không đọc được | thiếu quyền KMS nếu bucket mã hoá SSE-KMS |

Dòng cuối liên quan tới cấu hình đầy đủ: nếu bucket dùng SSE-KMS, key policy phải cho phép cloudtrail.amazonaws.com gọi kms:GenerateDataKey*.

Bốn thực hành cho bucket lưu log CloudTrail: | Thực hành | Lý do | |---|---| | Đặt ở tài khoản Log Archive riêng | kẻ chiếm tài khoản không với tới log | | Bật S3 Object Lock (WORM) | không ai xoá được, kể cả root | | Bật log file validation | phát hiện sửa đổi (xem câu #7701) | | Đặt lifecycle chuyển sang Glacier | giảm chi phí lưu trữ dài hạn |

Và về chính nhu cầu của đề — thêm prefix theo phòng ban: cách này hoạt động, nhưng với tổ chức nhiều tài khoản thì organizational trail (xem câu #7701) là mô hình gọn hơn. CloudTrail đã tự phân chia log theo account ID trong đường dẫn, nên nếu mỗi phòng ban có tài khoản riêng thì việc phân biệt đã có sẵn mà không cần prefix.

Câu 90 Infrastructure Security

A standard three-tier application is hosted on Amazon EC2 instances that are fronted by an Application Load Balancer. The application maintenance team has reported several small-scale malicious attacks on the application. The project manager has decided to ramp up the security of the application.

As an AWS Certified Security Specialist, which of the following would you recommend as part of the best practices to scan and mitigate the known vulnerabilities?

A
Configure the application security groups to ensure that only the necessary ports are open. Use Amazon Inspector to periodically scan the EC2 instances for vulnerabilities
B
Install AWS Certificate Manager (ACM) SSL/TLS certificate on the EC2 instances to secure traffic moving to and from the application servers
C
Configure the application security groups to ensure that only the necessary ports are open. Use Amazon Systems Manager to periodically scan the EC2 instances for vulnerabilities
D
Use AWS Key Management Services to encrypt all the traffic between the client and application servers. Configure the application security groups to ensure that only the necessary ports are open

Xem giải thích

Đáp án

A — Cấu hình security group của ứng dụng để chỉ mở các cổng cần thiết; dùng Amazon Inspector quét định kỳ các EC2 instance để tìm lỗ hổng.

Vì sao đúng

Đề yêu cầu quét và giảm thiểu các lỗ hổng đã biết, và A kết hợp đúng hai biện pháp: | Biện pháp | Vai trò | |---|---| | Security group chỉ mở cổng cần thiết | giảm bề mặt tấn công | | Amazon Inspector quét lỗ hổng | phát hiện CVE trong phần mềm cài đặt |

Vì sao Inspector là dịch vụ đúng cho "known vulnerabilities":

Amazon Inspector v2 quét:
    ├─ Gói hệ điều hành      → so với cơ sở dữ liệu CVE
    ├─ Gói ngôn ngữ lập trình → npm, PyPI, Maven, Go...
    └─ Khả năng tiếp cận mạng → cổng nào mở ra Internet

Cụm từ "known vulnerabilities" trong đề chính là định nghĩa của CVE — lỗ hổng đã được công bố và có mã định danh. Đó là phạm vi của Inspector.

Và Inspector v2 quét LIÊN TỤC tự động: | Sự kiện | Hành vi | |---|---| | Instance mới khởi động | tự phát hiện qua SSM Agent, quét ngay | | Gói phần mềm cập nhật | quét lại | | CVE mới được công bố | đánh giá lại instance đang chạy |

Dòng cuối là giá trị lớn nhất: một instance sạch hôm nay có thể có lỗ hổng nghiêm trọng vào tuần sau, mà không có gì thay đổi trên chính máy đó.

Vế thứ hai của đáp án — security group — là biện pháp giảm thiểu: ngay cả khi có lỗ hổng chưa vá, kẻ tấn công vẫn cần đường tới được dịch vụ có lỗ hổng đó. Đóng cổng không cần thiết cắt đường đó.

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

C. Cấu hình security group chỉ mở cổng cần thiết; dùng AWS Systems Manager quét định kỳ EC2 instance tìm lỗ hổng — đây là phương án gần nhất và sai ở dịch vụ quét: Systems Manager quản lý và VÁ instance (Patch Manager), nhưng không quét lỗ hổng. (Hai dịch vụ bổ sung nhau: Inspector tìm lỗ hổng, Patch Manager vá chúng.)
B. Cài chứng chỉ ACM SSL/TLS lên EC2 instance để bảo vệ lưu lượng đi và đến máy chủ ứng dụng — hai vấn đề: mã hoá đường truyền không liên quan tới việc quét lỗ hổng; và ACM không xuất private key cho chứng chỉ công khai, nên không cài lên EC2 được (xem câu #7690).
D. Dùng AWS KMS mã hoá toàn bộ lưu lượng giữa client và máy chủ ứng dụng; cấu hình security group — KMS không mã hoá lưu lượng mạng: nó quản lý khoá cho dữ liệu khi lưu (at rest). Mã hoá đường truyền dùng TLS.

Ghi nhớ

Bốn dịch vụ bảo mật AWS — bảng phân biệt cốt lõi: | Dịch vụ | Phát hiện | |---|---| | Inspector | LỖ HỔNG (CVE) và khả năng tiếp cận mạng | | GuardDuty | MỐI ĐE DOẠ đang diễn ra | | Macie | DỮ LIỆU NHẠY CẢM trong S3 | | Security Hub | tổng hợp và chấm điểm chuẩn |

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

"Phần mềm có lỗ hổng đã biết không?" → Inspector "Có ai đang tấn công không?" → GuardDuty

Inspector và Systems Manager 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 cửa sổ bảo trì → 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.

Ba yêu cầu để Inspector quét được EC2:

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

Instance không phải "managed instance" thì không được quét — và không có cảnh báo nào cho biết điều đó. Nên kiểm tra số lượng instance được quét so với tổng số instance là bước xác nhận quan trọng.

(Inspector cũng có chế độ agentless quét từ snapshot EBS — hữu ích cho instance không cài được SSM Agent.)

Bốn lớp phòng thủ cho ứng dụng web trên EC2: | Lớp | Công cụ | |---|---| | Biên | WAF (lọc tầng 7), Shield (chống DDoS) | | Mạng | security group, NACL, private subnet | | Máy chủ | Inspector (tìm), Patch Manager (vá) | | Dữ liệu | mã hoá EBS, TLS cho đường truyền |

Đề nói tới "several small-scale malicious attacks" — điều đó gợi ý nên xem xét cả lớp đầu: AWS WAF trước ALB lọc được SQL injection, XSS và các mẫu tấn công phổ biến mà việc vá lỗ hổng không chặn được (ví dụ tấn công vào logic ứng dụng chứ không vào thư viện).

Và một lưu ý về security group trong ngữ cảnh này: bên cạnh việc đóng cổng, hãy dùng AWS-managed prefix list com.amazonaws.global.cloudfront.origin-facing nếu có CloudFront phía trước — nó đảm bảo ALB chỉ nhận lưu lượng từ CDN, không ai đi thẳng vào bỏ qua WAF.

Trang 9 / 45 — tổng 445 câu hỏi