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

Tìm thấy 445 câu.

Câu 101 Management and Security Governance

An AWS organization manages its security and compliance units through two different AWS accounts. Both the accounts need AWS Config configuration and compliance data from multiple AWS accounts and Regions to get a centralized view of the resource inventory. Currently, the teams use shared access to the management account to fetch the required data.

To enforce enhanced security measures, the company is looking at eliminating the need to share management account credentials with the team. As a Security Engineer, how will you implement this requirement with the least time and effort?

  1. A

    Configure AWS Systems Manager Explorer with a customizable operations dashboard that displays information from AWS Config
  2. B

    Use the aggregator feature of AWS Config to provide access to AWS Config data to both accounts without the need to share the management account details
  3. C

    Use Configuration snapshots feature of AWS Config to create point-in-time capture of all your resources and their configurations. Save these snapshots in an Amazon S3 bucket and analyze the data using AWS Athena for trends and security aberrations
  4. D

    Use OpsCenter capability of AWS Systems Manager with AWS Config to detect a resource that is out of compliance and automate remediation
Xem giải thích

Đáp án

B — Dùng tính năng aggregator của AWS Config để cấp quyền truy cập dữ liệu Config cho cả hai tài khoản mà không cần chia sẻ thông tin đăng nhập của tài khoản quản lý.

Vì sao đúng

Đề mô tả vấn đề rõ: hai đội đang dùng chung thông tin đăng nhập của tài khoản quản lý để xem dữ liệu Config — một thực hành nguy hiểm cần loại bỏ.

Config aggregator giải quyết đúng vấn đề đó:

Trước:
  Đội bảo mật    ─┐
  Đội tuân thủ   ─┴→ dùng chung tài khoản quản lý → xem Config
                     ✗ chia sẻ thông tin đăng nhập
                     ✗ không phân biệt được ai làm gì

Sau:
  Tài khoản bảo mật  → aggregator riêng → dữ liệu Config của mọi tài khoản/Region
  Tài khoản tuân thủ → aggregator riêng → dữ liệu Config của mọi tài khoản/Region
                     ✓ mỗi đội dùng tài khoản của mình

Aggregator là gì: một tài nguyên trong Config thu thập dữ liệu cấu hình và trạng thái tuân thủ từ nhiều tài khoản và nhiều Region về một chỗ để xem.

Hai chế độ nguồn: | Nguồn | Cách hoạt động | |---|---| | AWS Organizations | tự động lấy mọi tài khoản trong tổ chức, kể cả tài khoản mới | | Danh sách tài khoản cụ thể | từng tài khoản phải cấp quyền (authorization) |

Chế độ đầu là lựa chọn đúng cho đề này — nó bao trọn tổ chức và không cần bảo trì khi có tài khoản mới:

aws configservice put-configuration-aggregator   --configuration-aggregator-name tong-hop-tuan-thu   --organization-aggregation-source     RoleArn=arn:aws:iam::111122223333:role/AWSConfigRole,AllAwsRegions=true

Và điểm quan trọng: aggregator CHỈ ĐỌC. Nó cho phép xem và truy vấn, không cho phép sửa cấu hình Config ở các tài khoản nguồn — đúng với nhu cầu của hai đội bảo mật và tuân thủ.

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

  • C. Dùng configuration snapshot để chụp toàn bộ tài nguyên và cấu hình tại một thời điểm, lưu vào S3 và phân tích bằng Athena — đâ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 cấu hình lịch chụp, quản lý bucket, tạo bảng Athena, và dữ liệu là ảnh chụp tại thời điểm chứ không phải khung nhìn liên tục. Đề đòi "least time and effort".
  • A. Cấu hình AWS Systems Manager Explorer với bảng điều khiển tuỳ chỉnh hiển thị thông tin từ AWS Config — Systems Manager Explorer tổng hợp dữ liệu vận hành (OpsItem, kiểm kê, trạng thái vá) và có hiện một số thông tin từ Config, nhưng nó không phải công cụ để truy cập đầy đủ dữ liệu Config đa tài khoản — đó chính xác là việc của aggregator.
  • D. Dùng OpsCenter của Systems Manager cùng AWS Config để phát hiện tài nguyên không tuân thủ và tự động khắc phục — sai mục tiêu: OpsCenter là nơi quản lý và xử lý sự vụ vận hành. Đề không hỏi về khắc phục, mà hỏi cách cấp quyền xem dữ liệu tập trung mà không chia sẻ thông tin đăng nhập.

Ghi nhớ

Ba khả năng của AWS Config: | Khả năng | Chi tiết | |---|---| | Configuration history | lịch sử cấu hình từng tài nguyên theo thời gian | | Config rules | đánh giá tuân thủ liên tục | | Aggregator | gom dữ liệu đa tài khoản, đa Region về một chỗ xem ← câu này |

Ba khái niệm của Config hay bị nhầm: | Khái niệm | Việc | |---|---| | Configuration item | ảnh chụp cấu hình của MỘT tài nguyên tại một thời điểm | | Configuration snapshot | ảnh chụp MỌI tài nguyên tại một thời điểm, xuất ra S3 | | Aggregator | khung nhìn LIÊN TỤC, đa tài khoản |

Khác biệt giữa dòng hai và dòng ba là "ảnh chụp" so với "khung nhìn sống" — và đó là lý do phương án C thua.

Hai loại nguồn cho aggregator: | Nguồn | Ưu điểm | Nhược điểm | |---|---|---| | Organizations | tự động bao gồm tài khoản mới | cần bật trusted access | | Danh sách tài khoản | dùng được ngoài Organizations | từng tài khoản phải cấp quyền thủ công |

Điều kiện tiên quyết cho chế độ Organizations:

aws organizations enable-aws-service-access   --service-principal config.amazonaws.com

Truy vấn nâng cao trên aggregator — khả năng mạnh nhất:

SELECT accountId, resourceId, resourceType, configuration.instanceType
WHERE resourceType = 'AWS::EC2::Instance'
  AND configuration.state.name = 'running'

Advanced query cho phép truy vấn kiểu SQL trên cấu hình của TOÀN BỘ tổ chức — trả lời được những câu hỏi như "có bao nhiêu bucket chưa bật mã hoá trên mọi tài khoản" trong vài giây.

Ba mô hình tập trung dữ liệu bảo mật đa tài khoản — cùng một ý tưởng, khác dịch vụ: | Dịch vụ | Cơ chế tập trung | |---|---| | AWS Config | aggregator | | Security Hub | delegated administrator + cross-Region aggregation | | GuardDuty, Detective, Inspector | delegated administrator | | CloudTrail | organizational trail (xem câu #7701) |

Mẫu chung: một tài khoản chuyên trách bảo mật có khung nhìn toàn tổ chức, không ai phải dùng thông tin đăng nhập của tài khoản quản lý.

Và một nguyên tắc kiến trúc mà đề chạm tới: tài khoản quản lý của Organizations không nên được dùng cho công việc hằng ngày. Nó có quyền cao nhất trong tổ chức và SCP không áp cho nó (xem câu #7748) — nên mỗi lần ai đó đăng nhập vào đó là một rủi ro. Chuyển sang mô hình delegated administrator cho mọi dịch vụ hỗ trợ là cách giảm hẳn số lần cần chạm tới tài khoản đó.

Câu 102 Data Protection

A healthcare company has recently completed a security review that has highlighted several gaps in the security standards mandated by the company while using the AWS Key Management Service (AWS KMS) keys. As an initial step to address the gap, the security team has decided that access to AWS KMS keys should be restricted to only the principals belonging to their AWS Organizations.

How will you implement this requirement?

  1. A

    The aws:PrincipalOrgID global condition key can be used with the Principal element in a resource-based policy with AWS KMS. List all the AWS account IDs in the Condition element
  2. B

    The aws:PrincipalOrgID global condition context key can be used to restrict access to an AWS service principal
  3. C

    The aws:PrincipalIsAWSService global condition key can be used with the Principal element in a resource-based policy with AWS KMS. List all the AWS account IDs in the Condition element
  4. D

    The aws:PrincipalOrgID global condition key can be used with the Principal element in a resource-based policy with AWS KMS. You need to specify the Organization ID in the Condition element
Xem giải thích

Đáp án

D — Dùng global condition key aws:PrincipalOrgID cùng với phần tử Principal trong resource-based policy của AWS KMS; khai ID của tổ chức trong phần tử Condition.

Vì sao đúng

Đề yêu cầu: chỉ principal thuộc AWS Organizations của công ty mới dùng được KMS key.

aws:PrincipalOrgID là condition key được thiết kế đúng cho việc này:

{
  "Sid": "ChiChoPhepTrongToChuc",
  "Effect": "Allow",
  "Principal": {"AWS": "*"},
  "Action": ["kms:Decrypt", "kms:GenerateDataKey", "kms:DescribeKey"],
  "Resource": "*",
  "Condition": {
    "StringEquals": {"aws:PrincipalOrgID": "o-abc123def4"}
  }
}

Giá trị là ID của TỔ CHỨC — một chuỗi duy nhất dạng o-xxxxxxxxxx, không phải danh sách tài khoản.

Vì sao đây là cách đúng thay vì liệt kê account ID: | | aws:PrincipalOrgID | Liệt kê account ID | |---|---|---| | Tài khoản mới gia nhập | ✅ tự động được phép | ❌ phải sửa policy | | Tài khoản rời tổ chức | ✅ tự động mất quyền | ❌ phải nhớ gỡ | | Độ dài policy | một dòng | dài dần theo số tài khoản | | Giới hạn kích thước policy | không lo | key policy có giới hạn 32 KB |

Dòng thứ hai là lợi ích bảo mật quan trọng: khi một tài khoản bị tách khỏi tổ chức (bán đi, ngừng hoạt động), quyền của nó biến mất ngay mà không cần ai nhớ dọn dẹp.

Và Principal: "*" kết hợp với điều kiện là mẫu chuẩn — nó không có nghĩa là "cho phép tất cả mọi người": điều kiện thu hẹp lại đúng những principal thuộc tổ chức.

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

  • A. Dùng aws:PrincipalOrgID cùng phần tử Principal trong resource-based policy của KMS. Liệt kê tất cả AWS account ID trong phần tử Condition — đây là phương án gần nhất và sai ở giá trị truyền vào: aws:PrincipalOrgID nhận ID của TỔ CHỨC, không phải danh sách account ID. Liệt kê account ID vào đó thì điều kiện không bao giờ khớp và policy chặn tất cả. (Condition key nhận danh sách account là aws:PrincipalAccount.)
  • C. Dùng aws:PrincipalIsAWSService cùng phần tử Principal; liệt kê tất cả account ID trong Condition — sai condition key hoàn toàn: aws:PrincipalIsAWSService là giá trị Bool cho biết request có đến từ một dịch vụ AWS hay không (ví dụ CloudTrail gọi KMS thay bạn). Nó không liên quan gì tới tổ chức.
  • B. aws:PrincipalOrgID có thể dùng để hạn chế truy cập cho một AWS service principal — nhầm mục đích: service principal (như cloudtrail.amazonaws.com) không thuộc về tổ chức nào, nên aws:PrincipalOrgID không áp dụng cho chúng. Ràng buộc service principal dùng aws:SourceArn hoặc aws:SourceAccount.

Ghi nhớ

Ba condition key liên quan tới tổ chức: | Key | Giá trị | Dùng khi | |---|---|---| | aws:PrincipalOrgID | o-xxxxxxxxxx | mọi tài khoản trong tổ chức ← câu này | | aws:PrincipalOrgPaths | o-xxx/r-yyy/ou-zzz/ | chỉ một OU cụ thể và cây con của nó | | aws:PrincipalAccount | account ID | tài khoản cụ thể |

Dòng giữa hữu ích khi cần chi tiết hơn: cho phép OU Sản xuất nhưng không cho OU Thử nghiệm:

{"Condition": {"ForAnyValue:StringLike": {
   "aws:PrincipalOrgPaths": ["o-abc123/r-xyz/ou-san-xuat/*"]}}}

Ba condition key hữu ích khác cho key policy của KMS: | Key | Việc | |---|---| | kms:ViaService | chỉ dùng được khoá THÔNG QUA một dịch vụ | | kms:EncryptionContext:<khoá> | ràng buộc theo ngữ cảnh (xem câu #7758) | | kms:CallerAccount | tài khoản của người gọi |

kms:ViaService rất mạnh cho việc thu hẹp phạm vi:

{"Condition": {"StringEquals": {
   "kms:ViaService": "s3.ap-northeast-1.amazonaws.com"}}}

Nó đảm bảo khoá chỉ dùng để mã hoá/giải mã object S3, không ai gọi thẳng API KMS để giải mã tuỳ ý — kể cả role bị xâm nhập.

Cấu trúc key policy đầy đủ nên có ba statement:

[
  {"Sid": "ChoPhepTaiKhoanQuanLyKhoa",
   "Principal": {"AWS": "arn:aws:iam::111122223333:root"},
   "Action": "kms:*", "Resource": "*"},

  {"Sid": "ChoPhepDungTrongToChuc",
   "Principal": {"AWS": "*"},
   "Action": ["kms:Decrypt", "kms:GenerateDataKey", "kms:DescribeKey"],
   "Resource": "*",
   "Condition": {"StringEquals": {"aws:PrincipalOrgID": "o-abc123def4"}}},

  {"Sid": "BatBuocTLS",
   "Effect": "Deny", "Principal": {"AWS": "*"},
   "Action": "kms:*", "Resource": "*",
   "Condition": {"Bool": {"aws:SecureTransport": "false"}}}
]

Statement đầu là bắt buộc phải giữ — không có nó, bạn có thể tự khoá mình ra khỏi khoá vĩnh viễn (xem câu #7719, #7696).

Ba nơi khác nên dùng aws:PrincipalOrgID: | Nơi | Lợi ích | |---|---| | S3 bucket policy | chỉ tài khoản trong tổ chức đọc được | | Secrets Manager resource policy | bí mật không ra ngoài tổ chức | | SNS, SQS, Lambda resource policy | ngăn chia sẻ ngoài ý muốn | | ECR repository policy | image chỉ dùng nội bộ |

Đây là một trong những rào chắn hiệu quả nhất chống rò rỉ dữ liệu ra ngoài tổ chức — và nên là mẫu mặc định cho mọi resource-based policy trong môi trường nhiều tài khoản.

Và một lưu ý khi kiểm chứng: dùng IAM Access Analyzer để rà xem tài nguyên nào đang được chia sẻ ra ngoài ranh giới tin cậy của bạn. Nếu bạn khai vùng tin cậy là tổ chức, Access Analyzer sẽ báo mọi policy cho phép principal bên ngoài — cách nhanh nhất để tìm những chỗ còn thiếu điều kiện này.

Câu 103 Management and Security Governance

A financial services company is evaluating storage options on Amazon S3 standard storage to meet regulatory guidelines. The data should be stored in such a way on S3 that it cannot be deleted until the regulatory period has expired.

As an AWS Certified Security Specialist, which of the following would you recommend for the given requirement?

  1. A

    Use S3 Object Lock
  2. B

    Use S3 Glacier Vault Lock
  3. C

    Activate MFA delete on the S3 bucket
  4. D

    Use S3 cross-Region Replication
Xem giải thích

Đáp án

A — Dùng S3 Object Lock.

Vì sao đúng

Đề nêu hai ràng buộc, và chúng cùng chỉ tới một tính năng: | Ràng buộc | Yêu cầu | |---|---| | Dữ liệu trên S3 Standard | giải pháp phải hoạt động với S3, không phải Glacier vault | | Không xoá được cho tới khi hết thời hạn quy định | WORM — write once, read many |

S3 Object Lock thực thi mô hình WORM ở mức object:

Object được ghi với retention period
    → KHÔNG ai xoá được cho tới khi hết hạn
    → KHÔNG ai ghi đè được
    → kể cả ROOT USER của tài khoản

Hai chế độ, và khác biệt rất quan trọng: | Chế độ | Ai gỡ được trước hạn | |---|---| | GOVERNANCE | người có quyền s3:BypassGovernanceRetention | | COMPLIANCE | KHÔNG AI — kể cả root user, kể cả AWS |

Với yêu cầu tuân thủ quy định như đề mô tả, COMPLIANCE là chế độ đúng — nó là bằng chứng với cơ quan quản lý rằng dữ liệu không thể bị sửa đổi, kể cả bởi người trong công ty có quyền cao nhất.

aws s3api put-object --bucket ho-so-tai-chinh   --key giao-dich-2026.csv --body du-lieu.csv   --object-lock-mode COMPLIANCE   --object-lock-retain-until-date 2033-08-30T00:00:00Z

Ba điều kiện để dùng Object Lock: | Điều kiện | Chi tiết | |---|---| | Versioning phải BẬT | và không tắt được khi Object Lock đang dùng | | Bật lúc TẠO bucket | (bật cho bucket có sẵn cần qua AWS Support) | | Đặt retention cho từng object hoặc mặc định cho bucket | |

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

  • B. Dùng S3 Glacier Vault Lock — đây là phương án gần nhất và cũng là cơ chế WORM thật, nhưng nó áp cho Glacier vault, không phải S3 Standard. Đề nói rõ "storage options on Amazon S3 standard storage". (Vault Lock là cơ chế cũ hơn, dành cho kho lưu trữ Glacier truyền thống.)
  • C. Bật MFA Delete trên S3 bucket — thêm rào cản, không phải ngăn chặn tuyệt đối: nó yêu cầu mã MFA khi xoá phiên bản object hoặc tắt versioning. Nhưng người có thiết bị MFA vẫn xoá được — không đáp ứng "cannot be deleted until the regulatory period has expired".
  • D. Dùng S3 Cross-Region Replication — giải quyết vấn đề khác: sao chép sang Region khác phục vụ khôi phục thảm hoạ và độ bền dữ liệu, không ngăn việc xoá. Xoá ở nguồn có thể (tuỳ cấu hình) lan sang bản sao.

Ghi nhớ

Hai cơ chế WORM của AWS — chọn theo tầng lưu trữ: | Cơ chế | Áp cho | Mức | |---|---|---| | S3 Object Lock | S3 (mọi lớp lưu trữ) | từng OBJECT ← câu này | | S3 Glacier Vault Lock | Glacier vault | cả VAULT |

Hai chế độ của Object Lock — bảng cần thuộc: | | GOVERNANCE | COMPLIANCE | |---|---|---| | Gỡ trước hạn | ✅ với quyền s3:BypassGovernanceRetention | ❌ KHÔNG AI | | Rút ngắn thời hạn | ✅ | ❌ | | Kéo dài thời hạn | ✅ | ✅ (chỉ được kéo DÀI) | | Dùng khi | bảo vệ khỏi xoá nhầm | yêu cầu pháp lý |

Cảnh báo về COMPLIANCE: đặt nhầm thời hạn 10 năm cho một object nghĩa là bạn phải trả tiền lưu trữ nó suốt 10 năm — không có cách nào xoá, và AWS cũng không gỡ hộ. Hãy kiểm thử ở chế độ GOVERNANCE trước.

Hai loại thời hạn: | Loại | Cơ chế | |---|---| | Retention period | khoá tới một ngày cụ thể | | Legal hold | khoá VÔ THỜI HẠN cho tới khi được gỡ tường minh |

Legal hold độc lập với retention period — dùng khi có tranh chấp pháp lý và chưa biết khi nào kết thúc:

aws s3api put-object-legal-hold --bucket ho-so --key tai-lieu.pdf   --legal-hold Status=ON

Bốn lớp bảo vệ dữ liệu quan trọng — nên dùng cùng nhau: | Lớp | Chống lại | |---|---| | Object Lock (COMPLIANCE) | xoá và sửa đổi — kể cả từ bên trong | | Versioning | ghi đè vô ý (điều kiện tiên quyết của Object Lock) | | MFA Delete | xoá vô ý phiên bản | | Cross-Region Replication | mất mát do sự cố Region | | SSE-KMS | truy cập trái phép vào nội dung |

Object Lock là lớp duy nhất chống được kẻ tấn công đã chiếm quyền quản trị — và đó là lý do nó quan trọng cho cả chống ransomware, không chỉ cho tuân thủ.

Ba ứng dụng thực tế của Object Lock: | Ứng dụng | Chi tiết | |---|---| | Tuân thủ quy định | SEC 17a-4, FINRA, CFTC — lưu trữ bất biến ← câu này | | Bảo vệ log kiểm toán | CloudTrail log không bị xoá (xem câu #7701) | | Chống ransomware | bản sao lưu không bị mã hoá hay xoá |

Dòng giữa là ứng dụng nên làm cho mọi tổ chức: bucket chứa log CloudTrail bật Object Lock chế độ COMPLIANCE khiến kẻ tấn công không xoá được dấu vết của chính mình — ngay cả khi chúng đã chiếm được quyền root.

Và một lưu ý về chi phí: object bị khoá vẫn tính phí lưu trữ bình thường trong suốt thời hạn. Nên kết hợp với lifecycle rule chuyển sang lớp lưu trữ rẻ hơn (Glacier Instant Retrieval, Glacier Deep Archive) — Object Lock hoạt động ở mọi lớp, nên bạn giữ được tính bất biến mà vẫn giảm được chi phí đáng kể cho dữ liệu ít truy cập.

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

The security team at a company has set up an IAM user with full permissions for the EC2 service, yet the user is unable to start an Amazon EC2 instance after it was stopped for maintenance purposes. The instance would change its state to "Pending" but would eventually switch back to "Stopped" with the error "client error on launch". Upon investigating the issue, it was discovered that the EC2 instance had attached Amazon EBS volumes that were encrypted using a Customer Master Key (CMK). Detaching the encrypted volumes from the EC2 instance resolved the issue and allowed the user to start the instance successfully.

Following is a snippet of the existing IAM user policy:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                    <action>
            ],
            "Resource": "arn:aws:kms:<region>:<accountId>:key/kms-encryption-key-for-ebs",
            "Condition": <condition>
        }
    ]
}

You have been tasked to build a solution to fix this issue. What do you recommend? (Select two)

  1. A

    Add the <action> as kms:CreateKey to the IAM user policy
  2. B

    Add the <action> as kms:CreateGrant to the IAM user policy
  3. C

    Add the <action> as kms:DescribeKey to the IAM user policy
  4. D

    Add the condition as { "Bool": { "kms:GrantIsForAWSResource": true } to the IAM user policy
  5. E

    Add the condition as { "Bool": { "kms:ViaService": "ec2.<region>.amazonaws.com"} to the IAM user policy
Xem giải thích

Đáp án

B và D.

  • B — Thêm <action> là kms:CreateGrant vào IAM policy
  • D — Thêm điều kiện { "Bool": { "kms:GrantIsForAWSResource": true } } vào IAM policy

Vì sao đúng

Đề cho một manh mối quyết định: tháo volume mã hoá ra thì instance khởi động được. Vậy vấn đề nằm ở quyền dùng CMK, không phải ở quyền EC2.

Vì sao cần kms:CreateGrant chứ không phải Decrypt:

EC2 khởi động instance có EBS mã hoá:
    ① EC2 cần dùng CMK để giải mã volume — nhưng KHÔNG dùng quyền của bạn
    ② EC2 tạo một GRANT trên CMK cho chính dịch vụ EC2
    ③ Grant đó cho phép EC2 giải mã volume TRONG SUỐT vòng đời instance

Người khởi động instance phải có quyền kms:CreateGrant — vì chính họ là người uỷ quyền cho EC2 thay mặt mình dùng khoá.

Triệu chứng đặc trưng "Pending → Stopped, client error on launch" chính là dấu hiệu của việc EC2 không tạo được grant. Instance không bao giờ chạy tới bước khởi động hệ điều hành.

Và kms:GrantIsForAWSResource là điều kiện thu hẹp phạm vi rất quan trọng:

{
  "Effect": "Allow",
  "Action": "kms:CreateGrant",
  "Resource": "arn:aws:kms:...:key/kms-encryption-key-for-ebs",
  "Condition": {"Bool": {"kms:GrantIsForAWSResource": true}}
}
Không có điều kiện Có điều kiện
Người dùng tạo grant cho BẤT KỲ principal nào chỉ tạo được grant khi một DỊCH VỤ AWS yêu cầu thay mặt họ
có thể tự cấp quyền dùng khoá vĩnh viễn không tự nâng quyền được

Vì sao đó là vấn đề bảo mật thật: kms:CreateGrant không kèm điều kiện cho phép người dùng tạo grant cấp quyền giải mã cho chính mình — tức là đi vòng qua mọi hạn chế trong key policy.

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

  • C. Thêm <action> là kms:DescribeKey — đây là phương án gần nhất và là quyền thật sự cần có trong bộ quyền đầy đủ, nhưng nó không phải nguyên nhân của lỗi này: DescribeKey chỉ đọc metadata của khoá. Thiếu nó không gây "client error on launch".
  • A. Thêm <action> là kms:CreateKey — sai hoàn toàn: CreateKey là quyền tạo khoá MỚI. Khoá đã tồn tại; vấn đề là quyền dùng nó.
  • **E. Thêm điều kiện { "Bool": { "kms:ViaService": "ec2.<region>.amazonaws.com" } } — sai kiểu dữ liệu và sai vai trò: kms:ViaService là chuỗi, phải dùng với StringEquals chứ không phải Bool. Và nó ràng buộc thao tác mã hoá/giải mã đi qua dịch vụ nào, không phải điều kiện chuẩn cho CreateGrant.

Ghi nhớ

Bộ quyền KMS đầy đủ để khởi chạy EC2 với EBS mã hoá bằng CMK:

{
  "Effect": "Allow",
  "Action": [
    "kms:Encrypt", "kms:Decrypt", "kms:ReEncrypt*",
    "kms:GenerateDataKey*", "kms:DescribeKey"
  ],
  "Resource": "arn:aws:kms:...:key/<key-id>"
},
{
  "Effect": "Allow",
  "Action": "kms:CreateGrant",
  "Resource": "arn:aws:kms:...:key/<key-id>",
  "Condition": {"Bool": {"kms:GrantIsForAWSResource": true}}
}

Hai statement riêng biệt — vì điều kiện GrantIsForAWSResource chỉ áp cho CreateGrant.

Grant là gì và khi nào dùng: | Đặc điểm | Chi tiết | |---|---| | Cấp quyền TẠM THỜI, chi tiết | không sửa key policy | | Dịch vụ AWS dùng nhiều | EBS, RDS, DynamoDB, Lambda tự tạo grant khi bật mã hoá | | Thu hồi được | RetireGrant hoặc RevokeGrant | | Ràng buộc theo encryption context | GrantConstraints |

Ba cơ chế cấp quyền của KMS: | Cơ chế | Vai trò | |---|---| | Key policy | BẮT BUỘC — gốc của mọi quyền | | IAM policy | chỉ có tác dụng nếu key policy uỷ quyền cho tài khoản | | Grant | cấp quyền tạm thời, thường do dịch vụ AWS tạo ← câu này |

Ba condition key hữu ích cho CreateGrant: | Key | Ràng buộc | |---|---| | kms:GrantIsForAWSResource | chỉ dịch vụ AWS tạo grant thay mặt bạn | | kms:GrantOperations | grant chỉ được cấp những thao tác nào | | kms:GranteePrincipal | grant chỉ cấp cho principal nào |

Và nhớ kiểm tra key policy song song với IAM policy: nếu key policy không có statement uỷ quyền cho tài khoản (Principal: root), thì mọi IAM policy cấp quyền KMS đều vô hiệu — triệu chứng giống hệt và rất dễ đi lạc hướng.

Một biến thể hay gặp cùng lỗi này: Auto Scaling group không khởi chạy được instance khi launch template dùng EBS mã hoá bằng CMK. Nguyên nhân giống hệt, nhưng principal cần quyền là service-linked role AWSServiceRoleForAutoScaling chứ không phải người dùng — nên phải thêm nó vào key policy.

Câu 105 Chọn nhiều đáp án Data Protection

A media company stores all of its business data on Amazon S3 buckets. Since a massive growth in the number of customers has resulted in complicated bucket policies, the company has now hired you as an AWS Certified Security Specialist for simplifying the company's S3 buckets configuration to facilitate access for the company's customers as well as other connected applications.

What are the important configuration characteristics to consider while defining access points for the S3 buckets? (Select three)

  1. A

    Access points support access over HTTP and HTTPS alone. It does not offer support over TCP and UDP protocols
  2. B

    You can only use access points to perform operations on objects. You can't use access points to perform Amazon S3 operations, such as modifying or deleting buckets
  3. C

    The cross-account access points don’t grant access to data until you are granted permissions from the bucket owner
  4. D

    You can't configure Cross-Region Replication to operate through an access point
  5. E

    After you create an access point, you can't change its virtual private cloud (VPC) configuration from the console anymore. An AWS CLI has to be used for modifying the configuration
  6. F

    Aliases for S3 Access Points are interchangeable with S3 bucket names. Aliases can be used as a logging destination for AWS CloudTrail logs and S3 server access logs. However, an alias cannot be used in AWS Identity and Access Management (IAM) policies
Xem giải thích

Đáp án

B, C và D:

  • B — Access point chỉ dùng để thao tác trên OBJECT; không dùng access point để thực hiện các thao tác trên bucket như sửa hay xoá bucket
  • C — Access point chéo tài khoản không cấp quyền truy cập dữ liệu cho tới khi bạn được chủ bucket cấp quyền
  • D — Không cấu hình được Cross-Region Replication hoạt động qua access point

Vì sao đúng

Đề hỏi về các đặc điểm cấu hình cần cân nhắc khi định nghĩa access point, và ba phát biểu này là ba giới hạn được ghi rõ trong tài liệu AWS.

S3 Access Point giải quyết vấn đề gì:

Trước:  MỘT bucket policy khổng lồ phục vụ mọi ứng dụng và khách hàng
        → hàng trăm statement, khó đọc, dễ sai
        → chạm giới hạn 20 KB của bucket policy

Sau:    Mỗi ứng dụng/khách hàng có một ACCESS POINT riêng
        → mỗi access point có policy riêng, hẹp và dễ hiểu
        → bucket policy chỉ còn một statement uỷ quyền cho access point

B — access point chỉ thao tác trên object: | Làm được qua access point | KHÔNG làm được | |---|---| | GetObject, PutObject, DeleteObject, ListObjectsV2 | DeleteBucket, PutBucketPolicy, PutBucketVersioning |

Đây là ranh giới thiết kế có chủ đích: access point là cửa truy cập dữ liệu, không phải công cụ quản trị bucket.

C — mô hình uỷ quyền hai lớp:

Access point policy CHO PHÉP  ∩  Bucket policy CHO PHÉP  =  quyền thực tế

Access point không tự cấp quyền vượt quá những gì chủ bucket cho phép. Với truy cập chéo tài khoản, chủ bucket phải chủ động uỷ quyền:

{
  "Effect": "Allow",
  "Principal": {"AWS": "*"},
  "Action": "s3:*",
  "Resource": ["arn:aws:s3:::kho-du-lieu", "arn:aws:s3:::kho-du-lieu/*"],
  "Condition": {"StringEquals": {"s3:DataAccessPointAccount": "111122223333"}}
}

D — CRR không đi qua access point: replication cấu hình ở mức bucket, không qua access point.

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

  • F. Alias của access point dùng thay được tên bucket, dùng được làm đích ghi log CloudTrail và server access log; nhưng không dùng được trong IAM policy — đây là phương án gần nhất và sai ở vế giữa: alias KHÔNG dùng được làm đích ghi log. Tài liệu AWS liệt kê đích ghi log là một trong các trường hợp không dùng alias được — cùng nhóm với IAM policy.
  • E. Sau khi tạo access point, không đổi được cấu hình VPC từ Console nữa; phải dùng AWS CLI — sai: cấu hình VPC của access point KHÔNG đổi được bằng bất kỳ cách nào sau khi tạo. Muốn đổi thì phải xoá và tạo lại. Không phải chuyện Console hay CLI.
  • A. Access point chỉ hỗ trợ HTTP và HTTPS; không hỗ trợ TCP và UDP — nhầm lẫn về tầng giao thức: HTTP và HTTPS chạy TRÊN NỀN TCP. Nói "hỗ trợ HTTP nhưng không hỗ trợ TCP" là mâu thuẫn nội tại. Và đây không phải một "đặc điểm cấu hình cần cân nhắc" — mọi API của S3 đều là HTTP.

Ghi nhớ

Ba loại access point của S3: | Loại | Đặc điểm | |---|---| | Internet access point | truy cập từ Internet, kiểm soát bằng policy | | VPC access point | chỉ truy cập được từ một VPC cụ thể | | Multi-Region Access Point | một endpoint toàn cầu, định tuyến tới bucket gần nhất |

VPC access point rất mạnh cho bảo mật: nó gắn cứng vào một VPC lúc tạo và không đổi được — nên nó là ràng buộc mạng không thể lách.

Ba thành phần của access point: | Thành phần | Chi tiết | |---|---| | Tên | duy nhất trong tài khoản và Region | | Access point policy | resource-based policy riêng | | Network origin | Internet hoặc VPC — cố định vĩnh viễn |

Giới hạn của access point — bảng cần thuộc: | Giới hạn | Chi tiết | |---|---| | Chỉ thao tác OBJECT | không quản trị bucket | | Không dùng cho CRR | replication ở mức bucket | | Network origin bất biến | tạo sai phải xoá làm lại | | 10.000 access point mỗi Region mỗi tài khoản | | | Alias không dùng trong IAM policy, không làm đích ghi log | |

Cấu trúc ARN và alias:

ARN:   arn:aws:s3:ap-northeast-1:111122223333:accesspoint/ten-diem-truy-cap
Alias: ten-diem-truy-cap-abc123-s3alias

Alias dùng thay tên bucket được trong hầu hết lời gọi S3 API — nên ứng dụng cũ chuyển sang access point mà gần như không sửa mã.

Ba trường hợp access point đáng dùng: | Trường hợp | Lợi ích | |---|---| | Nhiều ứng dụng dùng chung một bucket lớn | mỗi ứng dụng một policy hẹp, dễ kiểm toán | | Bucket policy chạm giới hạn 20 KB | tách bớt ra access point | | Cần ràng buộc truy cập theo VPC | VPC access point |

Và một tính năng liên quan đáng biết: S3 Object Lambda access point cho phép biến đổi dữ liệu ngay khi đọc — che thông tin cá nhân, đổi định dạng, thay đổi nội dung theo người gọi — mà không cần lưu nhiều bản sao. Nó dựng trên chính cơ chế access point này.

Câu 106 Security Logging and Monitoring

A web application is hosted on Amazon EC2 instances that are fronted by Application Load Balancer (ALB) configured with an Auto Scaling group (ASG). Enhanced security is provided to the ALB by AWS WAF web ACLs. As per the company's security policy, AWS CloudTrail is activated and logs are configured to be stored on Amazon S3 and CloudWatch Logs.

A discount sales offer was run on the application for a week. The support team has noticed that a few of the instances have rebooted taking down the log files and all temporary data with them. Initial analysis has confirmed that the incident took place during off-peak hours. Even though the incident did not cause any sales or revenue loss, the CTO has asked the security team to fix the security error that has allowed the incident to go unnoticed and eventually untraceable.

As Security Engineer, which series of steps will you implement to permanently record all traffic coming into the application?

  1. A

    Configure the WAF web ACL to deliver logs to Amazon Kinesis Data Firehose, which should be configured to eventually store the logs in an Amazon S3 bucket. Use Athena to query the logs for errors and tracking
  2. B

    To capture information about the IP traffic going to and from network interfaces, configure VPC Flow Logs to be directly streamed to Kinesis Data Streams and create alarms for automatic monitoring
  3. C

    Configure Elastic Load Balancing to write access logs to Amazon Kinesis Data Firehose. The logs can be further directed from Firehose into an Amazon S3 bucket for further analysis and reporting
  4. D

    Configure the WAF web ACL to deliver logs to Amazon CloudTrail and create a trail that applies to all Regions. This delivers log files from all Regions to an S3 bucket. Use Athena to query the logs for errors and tracking
Xem giải thích

Đáp án

A — Cấu hình WAF web ACL gửi log tới Amazon Kinesis Data Firehose, và Firehose lưu log vào S3 bucket. Dùng Athena truy vấn log để tìm lỗi và truy vết.

Vì sao đúng

Đề mô tả vấn đề rất rõ: instance khởi động lại làm mất log và dữ liệu tạm — nên sự cố không truy vết được.

Nguyên nhân gốc: log nằm trên chính máy sẽ chết cùng máy.

Trước:  Request → ALB → EC2 (log nằm trên đĩa cục bộ)
                          ↓ instance reboot
                        MẤT SẠCH

Sau:    Request → WAF (ghi log NGAY tại tầng biên)
                    ↓ Firehose
                  S3 (bền vững, độc lập với vòng đời instance)
                    ↓
                  Athena truy vấn

Vì sao WAF log là nguồn đúng cho "ghi lại toàn bộ lưu lượng vào ứng dụng": | Đặc điểm | Chi tiết | |---|---| | Ghi MỌI request đi qua web ACL | kể cả request bị chặn lẫn được cho qua | | Nằm ở tầng biên, trước EC2 | instance chết không ảnh hưởng gì | | Chi tiết đầy đủ | IP, quốc gia, URI, header, rule nào khớp |

Một bản ghi WAF log:

{
  "timestamp": 1756512000000,
  "action": "ALLOW",
  "terminatingRuleId": "Default_Action",
  "httpRequest": {
    "clientIp": "203.0.113.45", "country": "VN",
    "uri": "/khuyen-mai", "httpMethod": "GET", "headers": [...]
  }
}

Và tổ hợp Firehose + S3 + Athena là mẫu chuẩn: Firehose gom và nén theo lô, S3 lưu rẻ và bền, Athena truy vấn bằng SQL mà không cần dựng máy chủ nào.

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

  • C. Cấu hình ELB ghi access log vào Kinesis Data Firehose, rồi từ Firehose vào S3 — đây là phương án gần nhất và ALB access log là nguồn dữ liệu hợp lý, nhưng nó sai ở đường đi: ALB ghi access log THẲNG vào S3, không đi qua Firehose. Cấu hình như mô tả không tồn tại.
  • D. Cấu hình WAF gửi log tới CloudTrail và tạo trail áp cho mọi Region — sai đích hoàn toàn: CloudTrail không nhận log do dịch vụ khác đẩy vào. Nó ghi lời gọi API quản lý AWS (tạo rule, sửa web ACL), không ghi request HTTP của người dùng.
  • B. Cấu hình VPC Flow Logs stream thẳng vào Kinesis Data Streams và tạo alarm — hai vấn đề: Flow Logs chỉ có metadata mạng (IP, cổng, số byte), không có URI, header hay nội dung request — không đủ để truy vết sự cố ứng dụng. Và Flow Logs xuất được sang CloudWatch Logs, S3 hoặc Firehose, không phải thẳng vào Data Streams.

Ghi nhớ

Ba nguồn log cho ứng dụng web trên AWS — mỗi cái một tầng: | Nguồn | Ghi gì | Đích | |---|---|---| | WAF log | mọi request qua web ACL + rule nào khớp | Firehose, S3, CloudWatch Logs | | ALB access log | mọi request qua load balancer | CHỈ S3 | | VPC Flow Logs | metadata luồng mạng | CloudWatch Logs, S3, Firehose | | CloudTrail | lời gọi API quản lý AWS | S3, CloudWatch Logs |

Cột "đích" là chỗ hay bị hỏi: ALB access log chỉ ghi được vào S3 — đó là điểm loại của phương án C.

Nguyên tắc thiết kế log quan trọng nhất mà câu này dạy:

Log phải sống lâu hơn tài nguyên sinh ra nó.

Lưu ở Rủi ro
Đĩa cục bộ của EC2 mất khi instance reboot, terminate, hoặc bị thay bởi ASG
CloudWatch Logs (qua agent) an toàn — nhưng cần agent hoạt động đúng
S3 qua dịch vụ biên an toàn nhất — không phụ thuộc gì vào instance

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

(Ban đầu WAF chỉ hỗ trợ Firehose — đáp án A phản ánh điều đó. Triển khai mới hôm nay thì ghi thẳng vào S3 thường gọn hơn, bớt được một dịch vụ trung gian.)

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

Ba cách tối ưu chi phí Athena khi truy vấn log: | Cách | Tiết kiệm | |---|---| | Phân vùng theo ngày | chỉ quét khoảng thời gian cần | | Chuyển sang Parquet | 30–90% dữ liệu quét | | Nén | ít byte hơn |

Và một biện pháp nên làm song song cho chính tình huống của đề: instance reboot bất thường cũng là dấu hiệu đáng điều tra riêng. Bật CloudWatch agent đẩy log hệ thống lên CloudWatch Logs (xem câu #7751) để lần sau biết được vì sao máy khởi động lại — WAF log cho biết chuyện gì đến từ bên ngoài, còn log hệ thống cho biết chuyện gì xảy ra bên trong.

Câu 107 Data Protection

A financial services company wants to share sensitive accounting data that is stored in an Amazon RDS DB instance with an external auditor. The auditor has another AWS account and must own a copy of the database.

Which of the following would you recommend to securely share the database with the auditor?

  1. A

    Set up a read replica of the database and configure IAM standard database authentication to grant the auditor access
  2. B

    Create an encrypted snapshot of the database, share the snapshot, and allow access to the AWS Key Management Service (AWS KMS) encryption key
  3. C

    Create a snapshot of the database in Amazon S3 and assign an IAM role to the auditor to grant access to the object in that bucket
  4. D

    Export the database contents to text files, store the files in Amazon S3, and create a new IAM user for the auditor with access to that bucket
Xem giải thích

Đáp án

B — Tạo snapshot đã mã hoá của cơ sở dữ liệu, chia sẻ snapshot đó, và cấp quyền truy cập khoá mã hoá KMS.

Vì sao đúng

Đề nêu yêu cầu cốt lõi: kiểm toán viên ở tài khoản AWS khác và phải sở hữu một bản sao của cơ sở dữ liệu.

Chia sẻ snapshot là cơ chế chuẩn của RDS cho việc này:

Tài khoản công ty                    Tài khoản kiểm toán viên
  RDS DB instance
      ↓ CreateDBSnapshot
  Snapshot (mã hoá bằng CMK)
      ↓ ModifyDBSnapshotAttribute — chia sẻ
      ↓ key policy cho phép tài khoản kia
                                  →  CopyDBSnapshot (bản sao của họ)
                                  →  RestoreDBInstanceFromDBSnapshot
                                       ↓
                                     DB instance ĐỘC LẬP, họ SỞ HỮU

Hai điều kiện bắt buộc, và cả hai đều nằm trong đáp án: | Điều kiện | Vì sao | |---|---| | Chia sẻ snapshot | ModifyDBSnapshotAttribute với restore = account ID kia | | Chia sẻ quyền dùng KMS key | snapshot mã hoá thì không giải mã được nếu thiếu khoá |

Vế thứ hai là chỗ hay bị quên — và có một ràng buộc quan trọng:

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

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. Muốn chia sẻ snapshot thì bắt buộc phải dùng CMK do bạn quản lý.

Và vế "must own a copy" được đáp ứng đúng nghĩa: sau khi khôi phục, kiểm toán viên có một DB instance hoàn toàn độc lập trong tài khoản của họ — không còn phụ thuộc gì vào hệ thống của công ty.

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

  • A. Dựng read replica và cấu hình IAM database authentication để cấp quyền cho kiểm toán viên — đây là phương án gần nhất và cấp được quyền đọc, nhưng nó không đáp ứng yêu cầu "must own a copy": read replica vẫn nằm trong tài khoản của công ty và vẫn gắn với instance gốc. Kiểm toán viên chỉ đọc qua mạng chứ không sở hữu gì. (Và read replica chéo tài khoản không phải cấu hình được hỗ trợ trực tiếp.)
  • D. Xuất nội dung CSDL ra tệp văn bản, lưu vào S3, tạo IAM user mới cho kiểm toán viên — hai vấn đề: tệp văn bản mất cấu trúc quan hệ, chỉ mục và ràng buộc — không còn là cơ sở dữ liệu; và tạo IAM user trong tài khoản của bạn cho người ngoài là thực hành sai — nên dùng role với sts:AssumeRole hoặc chia sẻ tài nguyên.
  • C. Tạo snapshot của CSDL trong Amazon S3 và gán IAM role cho kiểm toán viên để truy cập object trong bucket đó — mô tả một cơ chế không tồn tại: CreateDBSnapshot không tạo object trong bucket S3 của bạn. Snapshot của RDS được RDS quản lý và chỉ thao tác qua API của RDS. (Có tính năng export snapshot sang S3 dạng Parquet — nhưng đó là dữ liệu phân tích, không khôi phục lại thành CSDL được.)

Ghi nhớ

Ba cách chia sẻ dữ liệu RDS chéo tài khoản: | Cách | Kết quả | Phù hợp | |---|---|---| | Chia sẻ snapshot | bản sao ĐỘC LẬP ở tài khoản kia | kiểm toán, sao lưu, di chuyển ← câu này | | Read replica | bản sao chỉ đọc, vẫn của bạn | phân tải đọc trong cùng tài khoản | | Cấp quyền kết nối trực tiếp | truy cập qua mạng | truy vấn trực tiếp, dữ liệu vẫn của bạn |

Ba bước chia sẻ snapshot mã hoá:

# ① Chia sẻ snapshot
aws rds modify-db-snapshot-attribute   --db-snapshot-identifier snapshot-kiem-toan   --attribute-name restore --values-to-add 999988887777

# ② Cấp quyền dùng CMK trong key policy
#    Principal: arn:aws:iam::999988887777:root
#    Action: kms:Decrypt, kms:CreateGrant, kms:DescribeKey

# ③ Bên nhận SAO CHÉP snapshot sang khoá của họ rồi khôi phục
aws rds copy-db-snapshot --source-db-snapshot-identifier <arn>   --target-db-snapshot-identifier ban-sao --kms-key-id <cmk-cua-ho>

Bước ③ đáng chú ý: bên nhận nên sao chép snapshot sang CMK của chính họ trước khi khôi phục — nếu không, DB instance của họ vẫn phụ thuộc vào khoá của bạn, và bạn thu hồi quyền là họ mất truy cập.

Bảng ràng buộc chia sẻ snapshot — cần thuộc: | Loại khoá | Chia sẻ được? | |---|---| | Không mã hoá | ✅ chia sẻ được, kể cả công khai | | AWS managed key (aws/rds) | ❌ KHÔNG | | Customer managed key (CMK) | ✅ nếu chia sẻ cả quyền dùng khoá |

Dòng giữa là ràng buộc quan trọng nhất — và nó áp cho cả EBS snapshot (xem câu #7801) lẫn RDS snapshot. Nếu bạn dự tính có lúc phải chia sẻ, hãy mã hoá bằng CMK ngay từ đầu.

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

Ba việc nên làm khi chia sẻ dữ liệu với kiểm toán viên bên ngoài: | Việc | Lý do | |---|---| | Dùng CMK riêng cho dữ liệu chia sẻ | thu hồi quyền không ảnh hưởng dữ liệu khác | | Ghi lại thời điểm và phạm vi chia sẻ | dấu vết kiểm toán | | Gỡ chia sẻ khi xong việc | --values-to-remove |

Và một cân nhắc về dữ liệu nhạy cảm: đề nói đây là dữ liệu kế toán nhạy cảm. Nếu kiểm toán viên chỉ cần một phần, hãy cân nhắc khôi phục snapshot vào một instance tạm, xoá hoặc che các cột không cần thiết, rồi mới chụp snapshot để chia sẻ — chia sẻ toàn bộ CSDL khi họ chỉ cần vài bảng là cấp quyền rộng hơn mức cần thiết.

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

A security engineer has configured a unified CloudWatch agent to push Amazon EC2 logs to Amazon CloudWatch Logs. However, the security team can't see any logs in the CloudWatch Logs console.

Why isn't the unified CloudWatch agent pushing log events? (Select two)

  1. A

    IAM user or IAM role policy should include the following IAM permissions:

    "logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:PutLogEvents",
"logs:DescribeLogStreams"
  2. B

    If the CloudWatch Logs endpoint is configured to be a public endpoint using an internet gateway the connectivity fails. VPC endpoints have to be used to keep the log files in AWS network
  3. C

    Creating an Amazon Machine Image (AMI) after the CloudWatch agent is installed can lead to errors in the CloudWatch agent
  4. D

    CloudWatch agent runs into errors if run_as_user parameter is any user other than the root user
  5. E

    Installing the CloudWatch agent after creating the Amazon Machine Image (AMI) can lead to errors in the CloudWatch agent
Xem giải thích

Đáp án

A và C.

  • A — IAM policy của user hoặc role phải có các quyền: logs:CreateLogGroup, logs:CreateLogStream, logs:PutLogEvents, logs:DescribeLogStreams
  • C — Tạo AMI SAU KHI đã cài CloudWatch agent có thể gây lỗi cho agent

Vì sao đúng

Đề mô tả: agent đã cấu hình nhưng không thấy log nào trong CloudWatch Logs. Hai nguyên nhân phổ biến nhất là quyền và trạng thái AMI.

A — thiếu quyền là nguyên nhân số một:

logs:CreateLogGroup     → tạo log group
logs:CreateLogStream    → tạo stream cho mỗi instance
logs:PutLogEvents       → ghi từng dòng log
logs:DescribeLogStreams → agent kiểm tra stream đã tồn tại chưa

logs:DescribeLogStreams là quyền hay bị bỏ sót — agent gọi nó để lấy sequenceToken trước khi ghi. Thiếu nó thì agent khởi động được nhưng không ghi được gì, và lỗi chỉ hiện trong log của chính agent:

# Log của agent — nơi cần nhìn đầu tiên khi gỡ lỗi
cat /opt/aws/amazon-cloudwatch-agent/logs/amazon-cloudwatch-agent.log

C — vấn đề AMI là nguyên nhân tinh vi hơn nhiều:

Instance gốc: cài agent → agent CHẠY → sinh các tệp trạng thái
                          ↓ tạo AMI ở trạng thái này
AMI mang theo cả TỆP TRẠNG THÁI của agent
                          ↓ khởi chạy 10 instance từ AMI
10 instance cùng mang một trạng thái cũ
    → agent bối rối về danh tính và vị trí đọc tiếp
    → không ghi log, hoặc ghi nhầm stream

Cách làm đúng: | Bước | Chi tiết | |---|---| | Cài agent | nhưng KHÔNG khởi động | | Dọn tệp trạng thái nếu agent đã chạy | /opt/aws/amazon-cloudwatch-agent/logs/state | | Tạo AMI | | | Khởi động agent qua user data hoặc SSM | mỗi instance sinh trạng thái riêng |

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

  • E. Cài CloudWatch agent SAU KHI tạo AMI có thể gây lỗi — đây là phương án gần nhất và là mệnh đề ngược của C: cài agent sau khi tạo AMI (tức là cài trên từng instance đang chạy) chính là cách làm ĐÚNG, không phải nguyên nhân lỗi.
  • D. Agent gặp lỗi nếu tham số run_as_user là user nào khác ngoài root — sai: giá trị mặc định của run_as_user là cwagent, không phải root. Chạy dưới user không đặc quyền là thực hành được khuyến nghị. (Chỉ cần user đó có quyền đọc các tệp log cần thu thập.)
  • B. Nếu endpoint CloudWatch Logs là endpoint công khai qua Internet Gateway thì kết nối thất bại; phải dùng VPC endpoint — sai: instance có đường ra Internet (qua IGW hoặc NAT) gọi được endpoint công khai của CloudWatch Logs bình thường. VPC endpoint là lựa chọn cho instance không có đường ra Internet, không phải điều kiện bắt buộc.

Ghi nhớ

Danh sách kiểm tra khi CloudWatch agent không đẩy log:

① IAM role có đủ 4 quyền logs:* chưa?
② Đọc log của chính agent — nơi có thông báo lỗi thật
③ Agent có đang chạy không?  amazon-cloudwatch-agent-ctl -a status
④ Đường dẫn tệp log trong cấu hình có đúng không?
⑤ User chạy agent có quyền ĐỌC tệp log đó không?
⑥ Instance có đường tới endpoint CloudWatch Logs không?
⑦ AMI có mang theo trạng thái agent cũ không?

Bước ② là bước hiệu quả nhất và hay bị bỏ qua — agent ghi rõ lý do vào log của chính nó.

Managed policy nên dùng: | Policy | Chứa | |---|---| | CloudWatchAgentServerPolicy | đủ quyền logs, metric, và đọc tham số SSM cho cấu hình |

Ba tệp và lệnh quan trọng của agent: | Đường dẫn | Việc | |---|---| | /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json | cấu hình | | /opt/aws/amazon-cloudwatch-agent/logs/amazon-cloudwatch-agent.log | log của agent — nơi gỡ lỗi | | /opt/aws/amazon-cloudwatch-agent/logs/state | tệp trạng thái — nguồn gốc vấn đề AMI |

# Kiểm tra trạng thái
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a status

# Nạp cấu hình từ SSM Parameter Store
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl   -a fetch-config -m ec2 -c ssm:cau-hinh-agent -s

Lưu cấu hình trong SSM Parameter Store là thực hành đáng theo: sửa một chỗ, mọi instance nạp lại được — thay vì phải sửa tệp trên từng máy.

Hai thứ agent thu thập mà CloudWatch không tự có: | Metric | Vì sao cần agent | |---|---| | mem_used_percent | CloudWatch không nhìn được vào trong hệ điều hành | | disk_used_percent | tương tự |

Đây là lý do chính người ta cài agent — CPU, network và disk I/O thì CloudWatch đã có sẵn từ tầng hypervisor (xem câu #8117).

Và một lưu ý về đóng gói AMI nói chung: mọi thứ sinh ra định danh riêng cho từng máy đều phải được dọn trước khi tạo AMI — không chỉ CloudWatch agent, mà cả SSM Agent (/var/lib/amazon/ssm), khoá SSH host, và machine-id của systemd. Bỏ sót một cái là gặp những lỗi rất khó hiểu ở quy mô lớn.

Câu 109 Security Logging and Monitoring

The latest guidelines issued by the security team at a company mandate an application to block HTTP requests that don't have a User-Agent header or have a specific User-Agent in the request.

How will you block these requests using AWS WAF?

  1. A

    Block requests that contain a specific User-Agent in the request using AWS Managed Rules. Block requests that don’t contain a User-Agent header using security group rules
  2. B

    Block requests that contain a specific User-Agent in the request using custom rules. Block requests that don’t contain a User-Agent header using security group rules
  3. C

    Block requests that contain a specific User-Agent in the request using AWS Managed Rules. Block requests that don’t contain a User-Agent header using either AWS Managed Rules or custom rules
  4. D

    Block requests that contain a specific User-Agent in the request using custom Rules. Block requests that don’t contain a User-Agent header using either AWS Managed Rules or custom rules
Xem giải thích

Đáp án

D — Chặn request chứa User-Agent cụ thể bằng CUSTOM RULE; chặn request không có header User-Agent bằng AWS Managed Rules HOẶC custom rule.

Vì sao đúng

Đề nêu hai yêu cầu khác nhau, và mỗi cái cần một loại rule khác nhau.

Yêu cầu 1: chặn một User-Agent CỤ THỂ → bắt buộc custom rule.

Chuỗi User-Agent cụ thể là thông tin RIÊNG của bạn
    → AWS không thể biết trước bạn muốn chặn chuỗi nào
    → Managed Rules KHÔNG làm được

{
  "Name": "ChanUserAgentXau",
  "Statement": {
    "ByteMatchStatement": {
      "SearchString": "BotXau/1.0",
      "FieldToMatch": {"SingleHeader": {"Name": "user-agent"}},
      "PositionalConstraint": "CONTAINS",
      "TextTransformations": [{"Priority": 0, "Type": "LOWERCASE"}]
    }},
  "Action": {"Block": {}}
}

Yêu cầu 2: chặn request KHÔNG CÓ User-Agent → làm được bằng CẢ HAI cách.

AWS Managed Rules:
  AWSManagedRulesCommonRuleSet  →  rule NoUserAgent_HEADER  ✓

Hoặc custom rule:
  SizeConstraintStatement trên header user-agent, size = 0  ✓

NoUserAgent_HEADER là một rule có thật trong bộ quy tắc phổ biến nhất của AWS — nên phương án nói "managed rules hoặc custom rule" cho vế này là chính xác.

Vì sao request không có User-Agent đáng chặn: trình duyệt thật luôn gửi header này. Request thiếu nó gần như chắc chắn là script tự động, công cụ quét, hoặc bot được viết cẩu thả.

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

  • C. Chặn User-Agent cụ thể bằng AWS Managed Rules; chặn request không có User-Agent bằng managed rules hoặc custom rule — đây là phương án gần nhất và sai ở vế đầu: Managed Rules là bộ quy tắc do AWS viết sẵn cho các mối đe doạ phổ biến. Chúng không biết chuỗi User-Agent riêng mà bạn muốn chặn.
  • B. Chặn User-Agent cụ thể bằng custom rule; chặn request không có User-Agent bằng security group rule — sai tầng: security group hoạt động ở tầng 3/4 (IP, cổng, giao thức). Nó không nhìn thấy header HTTP nào cả.
  • A. Chặn User-Agent cụ thể bằng Managed Rules; chặn request không có User-Agent bằng security group rule — sai cả hai vế, kết hợp lỗi của B và C.

Ghi nhớ

Hai loại rule của AWS WAF: | Loại | Ai viết | Dùng cho | |---|---|---| | AWS Managed Rules | AWS và đối tác | mối đe doạ phổ biến, cập nhật tự động | | Custom rule | bạn | logic riêng của ứng dụng |

Nguyên tắc chọn:

Mối đe doạ phổ biến ai cũng gặp (SQL injection, XSS, bot đã biết) → Managed Rules Điều kiện riêng của bạn (chuỗi cụ thể, đường dẫn cụ thể, IP của bạn) → custom rule

Các bộ Managed Rule đáng biết: | Bộ | Bảo vệ | |---|---| | AWSManagedRulesCommonRuleSet | OWASP phổ biến — gồm cả NoUserAgent_HEADER | | AWSManagedRulesKnownBadInputsRuleSet | mẫu khai thác đã biết (Log4j...) | | AWSManagedRulesSQLiRuleSet | SQL injection | | AWSManagedRulesAmazonIpReputationList | IP có tiếng xấu | | AWSManagedRulesBotControlRuleSet | nhận diện và phân loại bot | | AWSManagedRulesAnonymousIpList | VPN, Tor, proxy ẩn danh |

Vài rule bên trong CommonRuleSet đáng nhớ: | Rule | Chặn | |---|---| | NoUserAgent_HEADER | request không có User-Agent ← câu này | | UserAgent_BadBots_HEADER | User-Agent của bot đã biết | | SizeRestrictions_BODY | body quá lớn | | CrossSiteScripting_BODY | XSS |

Bảy nơi WAF khớp được (FieldToMatch):

SingleHeader     — một header cụ thể         ← câu này
Headers          — nhiều header
UriPath          — đường dẫn
QueryString      — chuỗi truy vấn
Body             — thân request (giới hạn kích thước)
Method           — phương thức HTTP
Cookies, JsonBody

Text transformation là bước quan trọng chống né tránh: | Transformation | Chống | |---|---| | LOWERCASE | BotXau với botxau | | URL_DECODE | mã hoá URL để giấu chuỗi | | COMPRESS_WHITE_SPACE | chèn khoảng trắng | | HTML_ENTITY_DECODE | mã hoá thực thể HTML |

Không có transformation thì rule rất dễ bị lách — kẻ tấn công chỉ cần đổi hoa thường.

Và một cảnh báo về việc chặn theo User-Agent: nó dễ giả mạo. Bất kỳ client nào cũng đặt được User-Agent tuỳ ý. Nên đây là biện pháp giảm nhiễu, không phải cơ chế bảo mật mạnh — dùng nó để lọc bot cẩu thả, còn chống bot có chủ đích thì cần Bot Control, rate-based rule, hoặc Challenge/CAPTCHA.

Câu 110 Management and Security Governance

An organization has added virtual machine images, software, and a few databases to its AWS Service Catalog. These will be used by multiple development teams to build their business workloads. The organization does not want the end users to launch and manage products using their own IAM credentials.

How will you address this requirement and implement it in the least possible time?

  1. A

    Create a new portfolio and add the new products to it. Attach a launch constraint to this portfolio
  2. B

    Use the service actions feature of the service catalog to define rules and constraints for the products in the portfolio. A CloudFormation template can also be used for easier implementation
  3. C

    Add launch constraint(s) to each product in the service catalog portfolio
  4. D

    Add the newly added products under a single tag. Add tag constraints to control the end user behavior and permissions on the products
Xem giải thích

Đáp án

C — Thêm launch constraint cho TỪNG sản phẩm trong portfolio của Service Catalog.

Vì sao đúng

Đề nêu yêu cầu chính xác: người dùng cuối không được khởi chạy và quản lý sản phẩm bằng thông tin đăng nhập IAM của chính họ, và cần triển khai trong thời gian ngắn nhất.

Launch constraint là cơ chế được thiết kế đúng cho việc này:

KHÔNG có launch constraint:
  Người dùng khởi chạy sản phẩm
      → CloudFormation dùng QUYỀN CỦA CHÍNH HỌ
      → họ phải có quyền tạo EC2, RDS, VPC...
      → tức là có quyền tạo mọi thứ, kể cả ngoài Service Catalog

CÓ launch constraint:
  Người dùng khởi chạy sản phẩm
      → Service Catalog ASSUME một IAM ROLE được chỉ định
      → CloudFormation dùng quyền của ROLE ĐÓ
      → người dùng CHỈ cần quyền dùng Service Catalog

Đây là mô hình uỷ quyền rất gọn: | Đối tượng | Quyền cần có | |---|---| | Người dùng cuối | chỉ servicecatalog:* để duyệt và khởi chạy | | Launch role | quyền tạo tài nguyên thật (EC2, RDS, S3...) |

Kết quả: người dùng tạo được đúng những gì sản phẩm cho phép, không hơn — họ không dùng được quyền đó cho việc gì khác vì nó không thuộc về họ.

Và vế "least possible time" quyết định chọn C thay vì A: đề nói sản phẩm đã được thêm vào Service Catalog rồi. Chỉ cần gắn launch constraint cho chúng — không cần dựng portfolio mới rồi thêm lại sản phẩm.

aws servicecatalog create-constraint   --portfolio-id port-abc123   --product-id prod-xyz789   --type LAUNCH   --parameters '{"RoleArn":"arn:aws:iam::111122223333:role/ServiceCatalogLaunchRole"}'

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

  • A. Tạo portfolio MỚI, thêm sản phẩm mới vào đó, và gắn launch constraint cho portfolio — đây là phương án gần nhất và sai ở hai điểm: sản phẩm đã có sẵn nên tạo portfolio mới là công thừa; và launch constraint gắn cho cặp sản phẩm–portfolio, không gắn cho cả portfolio như một khối.
  • B. Dùng tính năng service actions để định nghĩa quy tắc và ràng buộc cho sản phẩm; có thể dùng CloudFormation template cho dễ triển khai — nhầm chức năng: service action cho phép người dùng thực hiện thao tác vận hành trên tài nguyên đã cấp phát (khởi động lại instance, chạy SSM document). Nó không kiểm soát quyền lúc khởi chạy.
  • D. Đặt các sản phẩm mới dưới một tag chung; dùng tag constraint để kiểm soát hành vi và quyền của người dùng cuối — nhầm mục đích của tag constraint: nó bắt buộc gắn tag lên tài nguyên được cấp phát (để phân bổ chi phí, để quản trị). Nó không thay đổi danh tính mà CloudFormation dùng khi tạo tài nguyên.

Ghi nhớ

Bốn loại constraint của AWS Service Catalog: | Loại | Việc | |---|---| | Launch constraint | chỉ định IAM ROLE mà Service Catalog assume khi khởi chạy ← câu này | | Template constraint | giới hạn giá trị tham số (chỉ cho phép t3.micro, t3.small) | | Notification constraint | gửi thông báo SNS về sự kiện của stack | | Tag update constraint | cho phép hay cấm người dùng sửa tag | | StackSet constraint | triển khai ra nhiều tài khoản và Region |

Launch constraint là loại quan trọng nhất về mặt bảo mật — nó là thứ tách quyền của người dùng khỏi quyền tạo tài nguyên.

Bốn khái niệm nền tảng của Service Catalog: | Khái niệm | Là gì | |---|---| | Product | một CloudFormation template đã được duyệt | | Portfolio | tập hợp sản phẩm, chia sẻ cho người dùng hoặc tài khoản | | Constraint | quy tắc áp cho cặp sản phẩm–portfolio | | Provisioned product | thực thể đã được cấp phát (một stack) |

Quyền tối thiểu cho người dùng cuối — gọn đến bất ngờ:

{
  "Effect": "Allow",
  "Action": [
    "servicecatalog:DescribeProduct",
    "servicecatalog:ProvisionProduct",
    "servicecatalog:TerminateProvisionedProduct",
    "servicecatalog:SearchProducts"
  ],
  "Resource": "*"
}

Không một quyền ec2:* hay rds:* nào — đó chính là điều đề yêu cầu.

(AWS cũng có managed policy AWSServiceCatalogEndUserFullAccess cho mục đích này.)

Trust policy của launch role:

{
  "Effect": "Allow",
  "Principal": {"Service": "servicecatalog.amazonaws.com"},
  "Action": "sts:AssumeRole"
}

Ba lợi ích của mô hình này: | Lợi ích | Chi tiết | |---|---| | Đặc quyền tối thiểu thật sự | người dùng không bao giờ cầm quyền tạo tài nguyên | | Hạ tầng chuẩn hoá | mọi thứ được tạo từ template đã duyệt | | Kiểm toán rõ ràng | CloudTrail ghi ai cấp phát sản phẩm nào |

Kết hợp launch constraint với template constraint cho mức kiểm soát chặt hơn nữa: launch constraint quyết định có quyền gì, template constraint quyết định được chọn giá trị nào — ví dụ chỉ cho tạo instance từ danh sách loại máy được duyệt, tránh ai đó cấp phát một máy GPU đắt tiền.

Và một mẫu thường gặp trong tổ chức nhiều tài khoản: portfolio được chia sẻ từ một tài khoản trung tâm sang các tài khoản thành viên. Khi đó launch role phải tồn tại ở tài khoản thành viên — đây là chi tiết hay gây lỗi "role không tồn tại" khi mới triển khai.