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

Tìm thấy 445 câu.

Câu 31 Identity and Access Management

To improve the security of private APIs, a Security Engineer has been tasked to configure API Gateway to use an interface VPC endpoint. The VPC endpoint policy should only allow full access to two specific private APIs through the endpoint.

Which policy should be attached to the VPC endpoint to meet the given requirements?

  1. A 
    {
    "Version": "2012-10-17",
    "Statement":[
        {
            "Effect": "Allow",
            "Action":"ec2:*VpcEndpoint*",
            "Resource":[
                "arn:aws:execute-api:us-east-1:123412341234:a1b2c3d4e5/stageName/GET/*",
                "arn:aws:execute-api:us-east-1:123412341234:a1b2c3d4e5/stageName/GET/*"
            ]
        }
    ]
}
  2. B 
    {
    "Statement": [
        {
            "Principal": "*",
            "Action": [
                "execute-api:Invoke"
            ],
            "Effect": "Allow",
            "Resource": [
                "arn:aws:execute-api:us-east-1:123412341234:a1b2c3d4e5/*",
                "arn:aws:execute-api:us-east-1:123412341234:aaaaa11111/*"
            ]
        }
    ]
}
  3. C 
    {
    "Statement": [
        {
            "Principal": "*",
            "Action": [
                "execute-api:Invoke"
            ],
            "Effect": "Allow",
            "Resource": [
                "arn:aws:execute-api:us-east-1:123412341234:a1b2c3d4e5/stageName/GET/*",
                "arn:aws:execute-api:us-east-1:123412341234:a1b2c3d4e5/stageName/GET/*"
            ]
        }
    ]
}
  4. D 
    {
    "Version": "2012-10-17",
    "Statement":[
        {
            "Effect": "Allow",
            "Action":"ec2:*VpcEndpoint*",
            "Resource":[
                "arn:aws:execute-api:us-east-1:123412341234:a1b2c3d4e5/*",
                "arn:aws:execute-api:us-east-1:123412341234:aaaaa11111/*"
            ]
        }
    ]
}
Xem giải thích

Đáp án

B — Cấu hình VPC endpoint policy trên VPC endpoint của API Gateway, cho phép execute-api:Invoke trên API cụ thể chỉ cho các principal cần thiết.

Vì sao đúng

Đề yêu cầu: API riêng tư truy cập được từ VPC nhất định, và chỉ một số principal cụ thể gọi được.

VPC endpoint policy là cơ chế đúng:

{
  "Statement": [{
    "Effect": "Allow",
    "Principal": {"AWS": ["arn:aws:iam::123456789012:role/ung-dung-noi-bo"]},
    "Action": "execute-api:Invoke",
    "Resource": "arn:aws:execute-api:ap-northeast-1:123456789012:abc123/*"
  }]
}

Nó kiểm soát hai chiều cùng lúc: | Chiều | Kiểm soát | |---|---| | Ai | Principal — chỉ role/user được liệt kê | | Cái gì | Resource — chỉ API cụ thể, không phải mọi API |

Và execute-api:Invoke là action đúng cho việc GỌI API — phân biệt với các action quản lý: | Action | Việc | |---|---| | execute-api:Invoke | GỌI API (chạy request) | | apigateway:* | QUẢN LÝ API (tạo, sửa, xoá) | | execute-api:ManageConnections | WebSocket API |

Đây là nhầm lẫn phổ biến: dùng apigateway:GET để cho phép gọi API — không hoạt động, vì đó là quyền đọc cấu hình API.

Vì sao endpoint policy chứ không phải chỉ IAM policy: endpoint policy là lớp kiểm soát tại cửa vào, áp cho mọi request đi qua endpoint đó — kể cả từ principal mà bạn không quản lý IAM policy trực tiếp. Nó là rào chắn tập trung, không phụ thuộc vào việc từng role có policy đúng hay chưa.

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

  • A. Cấu hình IAM policy trên VPC endpoint cho phép apigateway:Invoke trên API cụ thể — đây là phương án gần nhất và sai ở tên action: không có action nào tên apigateway:Invoke. Action đúng là execute-api:Invoke.
  • D. Cấu hình security group trên VPC endpoint chỉ cho phép lưu lượng từ dải IP nhất định trong VPC — sai tầng kiểm soát cho vế "principal": security group lọc theo địa chỉ mạng, không theo danh tính IAM. Nó là lớp bổ sung hữu ích (và cần thiết để cho phép 443), nhưng không đáp ứng được yêu cầu "specific principals".
  • C. Cấu hình network ACL trên subnet của VPC endpoint chỉ cho phép lưu lượng từ dải IP nhất định — cùng vấn đề như D, và NACL còn thô hơn: nó không trạng thái và làm việc ở mức subnet.

Ghi nhớ

Ba loại API endpoint của API Gateway: | Loại | Truy cập từ | Đặc điểm | |---|---|---| | Edge-optimized | Internet, qua CloudFront | mặc định cho REST API | | Regional | Internet, trực tiếp trong Region | tự đặt CDN nếu muốn | | Private | CHỈ từ VPC qua interface endpoint | ← câu này |

Bốn lớp kiểm soát cho private API — nên hiểu vai trò từng lớp: | Lớp | Kiểm soát | |---|---| | VPC endpoint policy | hành động và principal nào qua được endpoint ← câu này | | API Gateway resource policy | VPC/endpoint/IP nào gọi được API | | IAM policy của người gọi | quyền của principal | | Security group của endpoint | lưu lượng mạng (cần cho phép 443) |

Hai lớp đầu bổ sung cho nhau và thường dùng cùng lúc: endpoint policy nhìn từ phía VPC, resource policy nhìn từ phía API.

Resource policy điển hình cho private API:

{"Effect": "Allow", "Principal": "*",
 "Action": "execute-api:Invoke", "Resource": "arn:aws:execute-api:...:abc123/*",
 "Condition": {"StringEquals": {"aws:SourceVpce": "vpce-0abc123"}}}

aws:SourceVpce ràng buộc theo endpoint cụ thể — chặt hơn ràng buộc theo VPC.

Ba cách xác thực người gọi API Gateway: | Cách | Đặc điểm | |---|---| | IAM authorization | request ký SigV4 — dùng cho gọi từ trong AWS | | Cognito authorizer | JWT từ User Pool | | Lambda authorizer | logic tuỳ ý — token, header, mọi thứ | | API key + usage plan | chỉ để đo lường và giới hạn tần suất, KHÔNG phải xác thực |

Dòng cuối đáng nhấn mạnh: API key không phải cơ chế bảo mật — AWS nêu rõ điều này. Dùng nó một mình để bảo vệ API là sai.

Và một chi tiết vận hành: khi bật private DNS trên interface endpoint của API Gateway, VPC đó không gọi được API Gateway CÔNG KHAI nữa — vì tên miền execute-api.<region>.amazonaws.com phân giải về endpoint riêng. Đây là đánh đổi cần cân nhắc, và là nội dung của câu #7705.

Câu 32 Chọn nhiều đáp án Threat Detection and Incident Response

A hybrid AWS network is configured to route internet traffic such that it egresses from an on-premises gateway rather than from a VPC Internet Gateway (IGW). Since enabling Amazon GuardDuty, an error has been repeatedly seen in the GuardDuty findings: UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS. This finding informs you that a host outside of AWS has attempted to run AWS API operations using temporary AWS credentials that were created on an EC2 instance in your AWS environment. The listed EC2 instance might be compromised, and the temporary credentials from this instance might have been exfiltrated to a remote host outside of AWS.

As a Security engineer, what steps would you take to address this issue, so that the VPC's internet traffic that egresses from an on-premises gateway does not trigger the given error? (Select two)

  1. A

    Use suppression rules and create a rule that consists of two filter criteria. The first criterion is finding type, which should be UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS
  2. B

    Use suppression rules and create a rule that consists of two filter criteria. The first criterion is finding type, which should be UnauthorizedAccess:EC2/SSHBruteForce
  3. C

    The second filter criterion is Trusted IP list to which you add the IP address or CIDR range of the on-premises internet gateway
  4. D

    The second filter criterion is API caller IPv4 address with the IP address or CIDR range of the on-premises internet gateway
  5. E

    Create a finding filter from the GuardDuty console for two different criteria. The first criterion is finding type, which should be UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration
Xem giải thích

Đáp án

A và D.

  • A — Tạo suppression rule trong GuardDuty để tự động lưu trữ (archive) các finding khớp tiêu chí đã định
  • D — Định nghĩa tiêu chí lọc dựa trên loại finding, tài nguyên bị ảnh hưởng, hoặc thuộc tính khác

Vì sao đúng

Đề nêu tình huống quen thuộc: quá nhiều finding cho hoạt động đã biết là hợp lệ, và cần giảm nhiễu mà không bỏ sót mối đe doạ thật.

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

GuardDuty sinh finding
    ↓ khớp suppression rule?
    ├─ CÓ  → tự động ARCHIVE (không hiện trong danh sách hoạt động,
    │         không gửi tới EventBridge/Security Hub)
    └─ KHÔNG → hiện bình thường, cảnh báo

Điểm quan trọng: finding bị suppress vẫn được TẠO và LƯU LẠI, chỉ là được lưu trữ tự động. Nghĩa là: | Đặc điểm | Chi tiết | |---|---| | Vẫn truy vấn được về sau | lọc theo trạng thái "archived" | | Không mất dữ liệu điều tra | khác hẳn với việc tắt hẳn một loại phát hiện | | Không kích hoạt cảnh báo | đúng mục tiêu giảm nhiễu |

D là bước cấu hình cụ thể của A — tiêu chí lọc là nội dung của suppression rule:

{
  "Criterion": {
    "type": {"Eq": ["Recon:EC2/Portscan"]},
    "resource.instanceDetails.instanceId": {"Eq": ["i-0abc123"]}
  }
}

Ví dụ thực tế: công cụ quét lỗ hổng nội bộ chạy hằng tuần sinh finding Recon:EC2/Portscan — hợp lệ, đã biết. Suppression rule lọc theo loại finding + ID instance của công cụ quét giữ được cảnh báo cho quét từ nguồn khác.

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

  • C. Xoá thủ công các finding không cần thiết khỏi console GuardDuty — đây là phương án gần nhất và không bền vững: finding mới sinh liên tục, nên phải xoá liên tục. Và quan trọng hơn: nó không ngăn được cảnh báo được gửi đi — thông báo đã tới trước khi bạn kịp xoá.
  • B. Tắt GuardDuty cho các tài khoản hoặc Region sinh nhiều finding nhất — giải pháp phá huỷ: nó mất hoàn toàn khả năng phát hiện ở nơi đó. Trái thẳng yêu cầu "without missing any critical security threats".
  • E. Bỏ qua các finding vì chúng không có tác động bảo mật — không phải một hành động kỹ thuật, và về mặt vận hành thì đây là cách nhanh nhất để đội bảo mật mất niềm tin vào hệ thống cảnh báo.

Ghi nhớ

Ba cách xử lý finding của GuardDuty — phân biệt rõ: | Cách | Hiệu ứng | Dùng khi | |---|---|---| | Suppression rule | tự động archive, VẪN LƯU | hoạt động hợp lệ đã biết ← câu này | | Archive thủ công | archive một finding cụ thể | đã điều tra xong một ca | | Trusted IP list | KHÔNG sinh finding cho IP đó | IP nội bộ tin cậy | | Threat IP list | luôn sinh finding cho IP đó | danh sách đen riêng |

Khác biệt giữa hàng 1 và hàng 3 đáng chú ý:

Suppression rule:  finding VẪN ĐƯỢC TẠO → archive
Trusted IP list:   finding KHÔNG ĐƯỢC TẠO

Suppression rule an toàn hơn vì bạn vẫn có dữ liệu để rà lại; trusted IP list thì không để lại dấu vết nào.

Bốn nguồn dữ liệu của GuardDuty: | Nguồn | Phát hiện | |---|---| | VPC Flow Logs | hoạt động mạng bất thường | | DNS logs | truy vấn tới domain độc hại, DNS exfiltration | | CloudTrail | hoạt động API bất thường, thông tin đăng nhập bị lộ | | Tính năng bảo vệ mở rộng | S3, EKS, Malware, RDS, Lambda |

Ba loại finding hay cần suppress trong thực tế: | Loại | Nguyên nhân hợp lệ | |---|---| | Recon:EC2/Portscan | công cụ quét lỗ hổng nội bộ | | UnauthorizedAccess:EC2/SSHBruteForce | máy quét bảo mật của chính công ty | | Discovery:S3/MaliciousIPCaller | IP bị đánh dấu nhầm |

Ba nguyên tắc khi viết suppression rule: | Nguyên tắc | Lý do | |---|---| | Càng CỤ THỂ càng tốt | suppress theo loại + tài nguyên, không chỉ theo loại | | Ghi lại lý do | người sau cần biết vì sao rule này tồn tại | | Rà lại định kỳ | tài nguyên thay đổi, rule cũ có thể che mất mối đe doạ thật |

Dòng đầu là điểm quan trọng nhất: suppress cả loại Recon:EC2/Portscan là mù trước mọi cuộc quét cổng thật. Ràng buộc thêm ID instance của công cụ quét giữ được khả năng phát hiện.

Và một lưu ý về kiến trúc nhiều tài khoản: trong mô hình GuardDuty administrator account, suppression rule được quản lý tập trung ở tài khoản quản trị và áp cho các tài khoản thành viên — nên không cần cấu hình lặp lại ở từng nơi.

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

An AWS root user has logged in to the AWS account and realized that there is no access to an Amazon S3 bucket under the given AWS account.

What is the reason for this behavior and how will you fix the issue? (Select two)

  1. A

    Modify the bucket policy to allow root user access from the Amazon S3 console or the AWS CLI
  2. B

    If there is a bucket policy on the Amazon S3 bucket that doesn't specify the AWS account root user as a principal, the root user is denied access to that bucket
  3. C

    Only An IAM user with full access to IAM and the S3 bucket will be able to add the root user as principal to the bucket policy
  4. D

    The access key of the root user account could be expired and hence needs to be recreated before accessing the S3 bucket
  5. E

    A root user has full access permissions on all the AWS resources in his user account. Contact the AWS support team to sort out the access issue
Xem giải thích

Đáp án

A và B.

  • A — Root user KHÔNG có quyền truy cập vào tài nguyên nếu policy của tài nguyên đó KHÔNG bao gồm root user
  • B — Root user vẫn KHÔNG truy cập được vào bucket đó dù có quyền admin

Vì sao đúng

Đề mô tả một bẫy thật và nguy hiểm: bucket policy không nêu root user làm principal, và câu hỏi là root có vào được không.

Câu trả lời: KHÔNG. Và lý do nằm ở cách S3 bucket policy hoạt động:

Bucket policy là RESOURCE-BASED POLICY
    → nó là nguồn quyền DUY NHẤT xác định ai truy cập được bucket
      khi truy cập từ ngoài chuỗi IAM thông thường

Root user KHÔNG được miễn trừ khỏi bucket policy
    → nếu policy không cấp quyền cho root, root không vào được

Đây là điểm khác biệt quan trọng so với trực giác thông thường: | Trực giác sai | Thực tế | |---|---| | "Root có toàn quyền, vượt mọi hạn chế" | root vẫn bị bucket policy ràng buộc | | "Root luôn sửa được policy để lấy lại quyền" | đúng — nhưng chỉ nếu policy không Deny cả s3:PutBucketPolicy |

Tình huống nguy hiểm nhất — tự khoá mình ra khỏi bucket:

{
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:*",
  "Resource": ["arn:aws:s3:::bucket-quan-trong",
               "arn:aws:s3:::bucket-quan-trong/*"]
}

Policy này chặn tất cả mọi người, kể cả root — và vì nó cũng chặn s3:DeleteBucketPolicy, không ai sửa được nó nữa. Lối thoát duy nhất là liên hệ AWS Support.

Vế "sensitive log files" trong đề đáng chú ý: đây là mẫu thiết kế có chủ ý — hạn chế bucket log chỉ cho đúng một role kiểm toán, và cố tình loại root ra để ngay cả người có quyền cao nhất cũng không tự ý đọc log.

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

  • C. Root user vẫn truy cập được bucket đó vì có quyền admin — sai: đây chính là hiểu lầm mà câu hỏi nhắm tới.
  • D. Root user có quyền truy cập vào tài nguyên dù policy của tài nguyên không bao gồm root — cùng lỗi như C, phát biểu dưới dạng tổng quát.

Ghi nhớ

Root user — những gì nó làm được và không làm được: | Root LÀM ĐƯỢC (duy nhất) | Root KHÔNG vượt qua được | |---|---| | Đổi thông tin thanh toán | explicit Deny trong bucket policy | | Đóng tài khoản AWS | explicit Deny trong KMS key policy | | Đổi tên tài khoản, email | SCP của Organizations (với tài khoản thành viên) | | Khôi phục quyền IAM khi tự khoá | | | Đăng ký GovCloud, khôi phục MFA | |

Cột phải là nội dung câu hỏi này — và cả ba dòng đầu đều là những chỗ root có thể bị chặn.

Hai tài nguyên có "policy tự đủ" mà root bị ràng buộc: | Tài nguyên | Rủi ro | |---|---| | S3 bucket policy | Deny toàn bộ = mất bucket vĩnh viễn ← câu này | | KMS key policy | Deny kms:PutKeyPolicy = KHÔNG AI dùng được khoá, không xoá được |

KMS còn nguy hiểm hơn S3: mất quyền với KMS key nghĩa là mất khả năng giải mã mọi dữ liệu đã mã hoá bằng khoá đó. AWS khuyến nghị mọi key policy phải có statement cho phép tài khoản gốc quản lý khoá:

{"Sid": "Cho phep tai khoan quan ly khoa",
 "Effect": "Allow",
 "Principal": {"AWS": "arn:aws:iam::123456789012:root"},
 "Action": "kms:*", "Resource": "*"}

Lưu ý về cú pháp :root trong policy: arn:aws:iam::123456789012:root trong Principal không chỉ nghĩa là root user — nó nghĩa là "tài khoản 123456789012", tức là uỷ quyền cho IAM policy của tài khoản đó quyết định. Đây là chi tiết tinh tế và hay bị hiểu nhầm.

Ba thực hành bắt buộc với root user: | Thực hành | Chi tiết | |---|---| | Bật MFA phần cứng | | | KHÔNG tạo access key | và xoá nếu đã có | | Khoá thông tin đăng nhập ở nơi an toàn | két, quy trình hai người | | Giám sát mọi hoạt động root | ← xem câu #7679 |

Và với AWS Organizations, có thêm một lớp: SCP áp cho tài khoản thành viên ràng buộc CẢ root user của tài khoản đó — nên trong tổ chức, root của tài khoản con không phải là quyền cao nhất. (SCP không áp cho root của tài khoản quản lý.)

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

A retail company has a three-tier web application with separate subnets for Web, Application, and Database tiers. The CTO at the company wants to monitor any malicious activity targeting the web application running on EC2 instances. You have been tasked with developing a solution to notify the security team in case the network exposure of EC2 instances on specific ports violates the security policies of the company.

Which AWS Services would you use to build an automated notification system to meet these requirements with the least development effort? (Select two)

  1. A

    Amazon CloudWatch
  2. B

    AWS Shield
  3. C

    Amazon Inspector
  4. D

    Amazon SNS
  5. E

    VPC Flow Logs
Xem giải thích

Đáp án

C và D.

  • C — Dùng Amazon Inspector đánh giá bảo mật cho ứng dụng chạy trên EC2 instance
  • D — Dùng Amazon SNS gửi thông báo tới đội DevOps sau khi đánh giá xong

Vì sao đúng

Đề yêu cầu: đánh giá bảo mật ứng dụng trên EC2 rồi thông báo cho đội DevOps. Cặp C+D là luồng ngắn nhất:

Amazon Inspector quét EC2 instance
    ↓ phát hiện CVE, cấu hình mạng không an toàn
    ↓ EventBridge bắt finding
SNS topic → đội DevOps

Vì sao Inspector là dịch vụ đúng: | Inspector quét | Chi tiết | |---|---| | Lỗ hổng phần mềm (CVE) | so gói cài đặt với cơ sở dữ liệu CVE | | Khả năng tiếp cận từ mạng | cổng nào mở ra Internet | | Container image trong ECR | quét image | | Lambda function | quét mã và phụ thuộc |

Amazon Inspector v2 quét LIÊN TỤC và tự động — không cần lên lịch hay khởi động thủ công:

Instance mới khởi động → Inspector 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ông bố        → đánh giá lại instance đang có

Và SNS cho vế thông báo: kết hợp với EventBridge để bắt finding theo mức nghiêm trọng:

{
  "source": ["aws.inspector2"],
  "detail-type": ["Inspector2 Finding"],
  "detail": {"severity": ["HIGH", "CRITICAL"]}
}

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

  • A. Dùng Amazon Macie đánh giá bảo mật cho ứng dụng chạy trên EC2 — đây là phương án gần nhất về mặt "dịch vụ bảo mật", nhưng sai phạm vi: Macie phát hiện dữ liệu nhạy cảm trong S3 (số thẻ tín dụng, thông tin cá nhân). Nó không quét EC2 và không tìm lỗ hổng phần mềm.
  • B. Dùng Amazon GuardDuty đánh giá bảo mật cho ứng dụng trên EC2 — nhầm loại công cụ: GuardDuty phát hiện MỐI ĐE DOẠ đang diễn ra (đào tiền ảo, giao tiếp với C2 server, thông tin đăng nhập bị lạm dụng) bằng cách phân tích log. Nó không quét lỗ hổng trong phần mềm cài đặt.
  • E. Dùng Amazon SES gửi thông báo tới đội DevOps — SES là dịch vụ gửi email hàng loạt cho ứng dụng (bản tin, email giao dịch). Cho thông báo vận hành, SNS là lựa chọn đúng: nó tích hợp sẵn với EventBridge, CloudWatch, và hỗ trợ nhiều loại đích (email, SMS, Lambda, SQS, HTTP).

Ghi nhớ

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

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

"Phần mềm có lỗ hổng đã biết không?" → Inspector "Có ai đang tấn công không?" → GuardDuty "Dữ liệu nhạy cảm nằm ở đâu?" → Macie "Tổng quan tuân thủ?" → Security Hub

Ba yêu cầu để Inspector quét được EC2: | Yêu cầu | Chi tiết | |---|---| | SSM Agent cài và chạy | Inspector v2 dùng SSM để thu thập kiểm kê | | Instance là "managed instance" | ← xem câu #7693 | | Hệ điều hành được hỗ trợ | Amazon Linux, Ubuntu, RHEL, Windows... |

Dòng đầu là điểm phụ thuộc quan trọng: Inspector v2 không cần agent riêng (khác v1) — nó dùng SSM Agent sẵn có. Nên 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 đó.

Hai kiểu quét của Inspector: | Kiểu | Đặc điểm | |---|---| | Agent-based (qua SSM) | quét sâu gói phần mềm | | Agentless | quét từ snapshot EBS — cho instance không cài SSM Agent |

SNS và SES — phân biệt: | | SNS | SES | |---|---|---| | Mục đích | thông báo pub/sub | gửi email cho người dùng cuối | | Đích | email, SMS, Lambda, SQS, HTTP | chỉ email | | Dùng cho | cảnh báo vận hành ← câu này | bản tin, email giao dịch |

Và một mẫu kiến trúc đáng biết cho việc này: Inspector → EventBridge → Security Hub + SNS. Đưa finding vào Security Hub cho bảng điều khiển tập trung, đồng thời gửi SNS cho cảnh báo tức thì — hai đích cho cùng một sự kiện, không phải chọn một.

Câu 35 Threat Detection and Incident Response

For a threat alert raised by the security team, a company needs content inspection of the traffic passing through an Amazon Route 53 resolver outbound endpoint.

As A Security Specialist, how will you implement a solution for this requirement?

  1. A

    To view traffic passing through Route 53 resolver endpoints, configure Amazon Virtual Private Cloud (Amazon VPC) Traffic Mirroring
  2. B

    Turn on Route 53 public query logging in each public-hosted zone. Amazon Route 53 publishes the logs to Amazon CloudWatch Logs for further analysis and troubleshooting
  3. C

    Enable VPC Flow Logs to capture all network traffic information passing through Route 53 resolver endpoints. Use the Athena integration feature in the Amazon VPC Console to create Athena tables for direct querying
  4. D

    Create a trail in AWS CloudTrail for continuous tracking of all Route 53 events. Deliver the log files to an Amazon S3 bucket and use Athena to query the log data for user patterns and troubleshooting
Xem giải thích

Đáp án

A — Cấu hình VPC Traffic Mirroring trên các ENI liên quan để sao chép lưu lượng DNS tới thiết bị giám sát.

Vì sao đúng

Đề yêu cầu giám sát và ghi lại lưu lượng DNS giữa các instance để phát hiện hoạt động độc hại.

Traffic Mirroring cho phép thu toàn bộ gói tin DNS:

Instance gửi truy vấn DNS
    ↓ ENI của instance là mirror source
Traffic Mirroring sao chép gói
    ↓ mirror filter: chỉ UDP/TCP port 53
Thiết bị giám sát (IDS, phân tích DNS)

Mirror filter cho lưu lượng DNS: | Rule | Direction | Protocol | Port | |---|---|---|---| | 100 | egress | UDP (17) | 53 | | 110 | egress | TCP (6) | 53 | | 120 | ingress | UDP (17) | 53 |

Vì sao Traffic Mirroring phù hợp: phát hiện hoạt động độc hại qua DNS cần nội dung truy vấn, không chỉ metadata: | Kỹ thuật tấn công | Cần nhìn thấy | |---|---| | DNS tunneling (rò rỉ dữ liệu) | nội dung tên miền — chuỗi mã hoá dài bất thường | | Liên lạc với C2 server | tên miền cụ thể được truy vấn | | Domain generation algorithm (DGA) | mẫu tên miền sinh tự động |

Cả ba đều cần payload gói tin — thứ mà chỉ Traffic Mirroring cung cấp.

Đề nói "monitor and LOG the DNS traffic" — mirror lưu lượng tới thiết bị giám sát cho cả hai: phân tích thời gian thực và lưu trữ để điều tra sau.

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

  • B. Bật VPC Flow Logs cho các instance và giám sát log để phát hiện lưu lượng DNS đáng ngờ — đây là phương án gần nhất và hữu ích ở mức cơ bản (thấy được instance nào nói chuyện với resolver nào, bao nhiêu byte), nhưng nó KHÔNG có nội dung truy vấn. Với DNS tunneling, Flow Logs chỉ thấy "có nhiều truy vấn DNS" mà không biết chúng chứa gì.
  • C. Cấu hình Amazon CloudWatch Logs thu thập log DNS từ instance — không có cơ chế sẵn: CloudWatch Logs cần một agent gửi log lên, và hệ điều hành không tự ghi log DNS ở mức truy vấn. Bạn phải cài và cấu hình phần mềm riêng trên từng instance — nhiều công và dễ bị vô hiệu hoá nếu instance bị xâm nhập.
  • D. Bật AWS CloudTrail ghi lại mọi lời gọi API liên quan tới DNS — sai loại dữ liệu: CloudTrail ghi lời gọi API quản lý Route 53 (tạo hosted zone, sửa record), không ghi truy vấn DNS thực tế từ instance.

Ghi nhớ

Ba cách quan sát DNS trên AWS — phân biệt rõ: | Cách | Cung cấp | Dùng khi | |---|---|---| | VPC Traffic Mirroring | TOÀN BỘ gói DNS | phân tích sâu, phát hiện tunneling ← câu này | | Route 53 Resolver Query Logging | tên miền, loại bản ghi, phản hồi | giải pháp gọn nhất cho hầu hết nhu cầu | | VPC Flow Logs | metadata luồng (IP, cổng, byte) | kiểm toán kết nối | | CloudTrail | thao tác quản lý Route 53 | kiểm toán thay đổi cấu hình |

Dòng thứ hai đáng nói thêm: Route 53 Resolver Query Logging là dịch vụ được thiết kế riêng cho việc ghi log truy vấn DNS trong VPC, và với đa số trường hợp nó đơn giản và rẻ hơn Traffic Mirroring rất nhiều:

aws route53resolver create-resolver-query-log-config   --name log-dns-vpc-chinh   --destination-arn arn:aws:logs:...:log-group:/aws/route53/dns

Nó ghi: tên miền được truy vấn, loại bản ghi, phản hồi, instance nào hỏi.

(Query Logging không nằm trong các phương án của câu này, nhưng trong thực tế nó thường là lựa chọn đầu tiên nên cân nhắc. Traffic Mirroring cần thiết khi bạn muốn kiểm tra nội dung ở mức gói hoặc đưa vào thiết bị IDS chuyên dụng.)

Ba dấu hiệu hoạt động DNS độc hại: | Dấu hiệu | Ý nghĩa | |---|---| | Tên miền dài, chuỗi ngẫu nhiên | DNS tunneling — dữ liệu mã hoá trong subdomain | | Số lượng truy vấn TXT bất thường | bản ghi TXT chứa được nhiều dữ liệu | | Truy vấn tới tên miền mới đăng ký | C2 server thường dùng domain vừa tạo |

Hai dịch vụ AWS phát hiện DNS độc hại tự động: | Dịch vụ | Cơ chế | |---|---| | GuardDuty | phân tích DNS log, so với danh sách domain độc hại | | Route 53 Resolver DNS Firewall | CHẶN truy vấn tới domain trong danh sách |

Dòng thứ hai là biện pháp phòng ngừa chứ không chỉ phát hiện — nó chặn hẳn truy vấn, nên đáng bật song song với việc giám sát.

Và một lưu ý về Traffic Mirroring cho DNS: lưu lượng DNS khối lượng nhỏ so với lưu lượng ứng dụng, nên mirror chỉ port 53 là cách dùng hiệu quả — không gây nghẽn băng thông như mirror toàn bộ.

Câu 36 Data Protection

The security team at a company has been assigned the responsibility of configuring outgoing email using Simple Email Service (SES) that leverages the Amazon SES API with mandatory TLS for the secure transfer of data.

Which configuration should the engineer choose to make TLS mandatory for SES API?

  1. A

    Change the behavior of SES by using configuration sets. Set the TlsPolicy property for a configuration set to Require
  2. B

    Configure TLS Wrapper mechanism on SES to establish a secure TLS-encrypted connection with the client
  3. C

    By default, Amazon SES configuration mandates TLS. Custom configurations are not needed to achieve secure communication
  4. D

    Configure STARTTLS mechanism on SES to establish a TLS-encrypted connection with the client
Xem giải thích

Đáp án

A — Tạo configuration set trong Amazon SES; trong delivery options đặt TlsPolicy là Require; dùng configuration set này khi gửi email.

Vì sao đúng

Đề yêu cầu: mọi email phải được truyền qua kênh mã hoá, và cấu hình phải cho các email trong tương lai chứ không phải từng lần gửi.

TlsPolicy: Require là cơ chế chính xác:

aws sesv2 create-configuration-set   --configuration-set-name bat-buoc-tls   --delivery-options TlsPolicy=REQUIRE

Hành vi của hai giá trị: | TlsPolicy | Hành vi | |---|---| | Optional (mặc định) | thử TLS trước; nếu máy chủ nhận không hỗ trợ thì gửi KHÔNG mã hoá | | Require | BẮT BUỘC TLS; nếu không thiết lập được thì KHÔNG GỬI, trả về lỗi |

Đây là điểm mấu chốt: mặc định Optional sẽ âm thầm gửi email ở dạng rõ khi máy chủ nhận không hỗ trợ TLS — và bạn không biết điều đó xảy ra. Require biến việc này thành lỗi rõ ràng.

Và configuration set áp cho mọi email dùng nó — đúng yêu cầu "future emails", không phải cấu hình lại từng lần:

ses.send_email(
    FromEmailAddress='noreply@congty.vn',
    Destination={'ToAddresses': ['khach@vidu.com']},
    Content={...},
    ConfigurationSetName='bat-buoc-tls'   # ← áp chính sách TLS
)

Configuration set còn có thể đặt làm mặc định cho identity, khi đó mọi email gửi từ tên miền đó tự dùng nó mà không cần khai trong từng lời gọi.

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

  • C. Tạo configuration set; trong delivery options đặt TlsPolicy là Optional — đây là phương án gần nhất và là chính giá trị mặc định không đáp ứng yêu cầu: Optional cho phép gửi không mã hoá khi TLS không khả dụng.
  • B. Tạo event destination trong SES, đặt TlsPolicy là Require trong event destination — sai nơi đặt cấu hình: event destination là nơi SES gửi sự kiện gửi thư (bounce, complaint, delivery) tới CloudWatch, Kinesis Firehose hay SNS. Nó không có tuỳ chọn TlsPolicy.
  • D. Tạo event destination trong SES, đặt TlsPolicy là Optional — sai cả hai mặt: sai nơi đặt và sai giá trị.

Ghi nhớ

Ba khái niệm của SES hay bị nhầm: | Khái niệm | Việc | |---|---| | Configuration set | NHÓM QUY TẮC áp cho email: TLS, IP pool, theo dõi, chặn | | Event destination | nơi GỬI SỰ KIỆN gửi thư (bounce, complaint, open, click) | | Identity | tên miền hoặc địa chỉ email đã xác minh |

Bốn thứ cấu hình được trong configuration set: | Cấu hình | Việc | |---|---| | Delivery options | TlsPolicy, IP pool chuyên dụng ← câu này | | Reputation options | theo dõi bounce và complaint rate | | Sending options | bật/tắt gửi cho toàn bộ set | | Suppression options | danh sách chặn | | Event destinations | nơi gửi sự kiện |

Hai mặt mã hoá email trong SES: | Mặt | Cơ chế | |---|---| | Kết nối tới SES (bạn → SES) | HTTPS API hoặc SMTP over TLS — luôn mã hoá | | SES tới máy chủ nhận | TlsPolicy — Optional hoặc Require ← câu này |

Đề hỏi về mặt thứ hai — chặng mà SES không kiểm soát được đầu kia.

Hai chuẩn xác thực email nên cấu hình song song: | Chuẩn | Việc | |---|---| | SPF | khai IP nào được gửi thư thay mặt tên miền | | DKIM | ký số email — người nhận xác minh không bị sửa đổi | | DMARC | chính sách khi SPF/DKIM thất bại |

Ba cái này bảo vệ TÍNH TOÀN VẸN và chống giả mạo, khác với TlsPolicy (bảo vệ tính bí mật khi truyền) — nên cần cả bốn cho một cấu hình email đầy đủ.

Và một đánh đổi cần biết khi đặt Require: email tới máy chủ không hỗ trợ TLS sẽ THẤT BẠI, không phải gửi ở dạng rõ. Với dữ liệu nhạy cảm đó là hành vi đúng, nhưng nó có nghĩa là bạn phải theo dõi tỷ lệ gửi thất bại — nên bật event destination cho sự kiện REJECT và DELIVERY_DELAY để biết khi có vấn đề.

Câu 37 Data Protection

A company has two VPCs (VPC1 and VPC2) configured in two different AWS Regions that are part of the same AWS account. There is an active VPC peering connection between the VPCs that has been configured in the route tables for both VPCs.

The database is present in VPC1 and the access to the database instance is controlled through a security group defined in VPC1. VPC2 consists of an Auto Scaling group that scales in/out any Amazon EC2 instances based on the CPU usage. Each instance launched as part of the Auto Scaling group belongs to a security group defined specifically for the Auto Scaling group. The launched instances need seamless access to the database instance present in VPC1.

Which additional step is needed for the solution to work if the route tables are already configured for VPC peering?

  1. A

    Configure an outbound rule on the security group of the instances launched in the Auto Scaling Group in VPC2, with the destination as the ID of the security group of the database instance
  2. B

    Configure an outbound rule on the security group of the instances launched in the Auto Scaling Group in VPC2, with the destination as the CIDR block of VPC1 (VPC for the database instance)
  3. C

    Add an inbound rule to the security group of the database instance in VPC1, with the source as the ID of the security group of the instances launched in the Auto Scaling Group in VPC2
  4. D

    Add an inbound rule to the security group of the database instance in VPC1, with the source as the CIDR block of VPC2 (VPC for the instances launched by the Auto Scaling Group)
Xem giải thích

Đáp án

D — Thêm rule vào security group của instance CSDL cho phép lưu lượng vào từ CIDR của VPC ứng dụng trên cổng CSDL.

Vì sao đúng

Đề mô tả tình huống: hai VPC đã có VPC peering, instance ứng dụng ở VPC A cần nói chuyện với instance CSDL ở VPC B, và cần giải pháp an toàn với ít công nhất.

Điểm kỹ thuật mấu chốt: security group KHÔNG tham chiếu chéo được qua VPC peering giữa các VPC khác nhau... trừ một số điều kiện.

Thực tế, AWS có hỗ trợ tham chiếu security group qua VPC peering, nhưng chỉ khi: | Điều kiện | Chi tiết | |---|---| | Cùng Region | peering liên Region KHÔNG hỗ trợ tham chiếu security group | | Phải bật tuỳ chọn trên peering connection | AllowEgressFromLocalVpcToRemoteClassicLink... |

Và đề nói rõ "different VPCs" mà không đảm bảo cùng Region — nên dùng CIDR là cách hoạt động trong mọi trường hợp:

Security group của CSDL (VPC B):
  Type: MySQL/Aurora    Protocol: TCP
  Port: 3306
  Source: 10.1.0.0/16   ← CIDR của VPC A (ứng dụng)

Vì sao đây là "ít công nhất và an toàn": | Tiêu chí | Đánh giá | |---|---| | Ít công | một rule, không thêm hạ tầng gì | | An toàn | chỉ mở đúng cổng CSDL cho đúng dải IP của VPC ứng dụng | | Hoạt động | qua VPC peering đã có sẵn |

Đây không phải mở rộng rãi: CIDR của VPC ứng dụng là một dải riêng tư cụ thể, không phải 0.0.0.0/0. Và cổng chỉ mở đúng cổng CSDL.

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

  • B. Thêm rule vào security group của instance CSDL cho phép lưu lượng vào từ security group của instance ứng dụng — đây là phương án gần nhất và là cách làm ĐÚNG trong CÙNG một VPC, nhưng qua VPC peering nó chỉ hoạt động khi hai VPC cùng Region và đã cấu hình đúng. Với peering liên Region thì không dùng được — nên nó không phải giải pháp phổ quát.
  • A. Tạo VPC endpoint trong VPC ứng dụng và cấu hình nó kết nối tới instance CSDL — không phù hợp: VPC endpoint dùng cho dịch vụ AWS hoặc dịch vụ PrivateLink, không phải để kết nối tới một EC2 instance qua peering đã có. (Có thể dựng PrivateLink với NLB trước CSDL — nhưng đó là nhiều công hơn hẳn, trái yêu cầu "least effort".)
  • C. Tạo NAT gateway trong VPC ứng dụng và định tuyến lưu lượng CSDL qua đó — sai mục đích hoàn toàn: NAT gateway cho phép instance private đi ra Internet. Lưu lượng qua VPC peering là nội bộ, không cần NAT — và định tuyến qua NAT còn không hoạt động cho đích riêng tư.

Ghi nhớ

Hai cách chỉ định nguồn trong security group rule: | Cách | Đặc điểm | Hạn chế | |---|---|---| | Security group ID | tự động theo instance, không phụ thuộc IP | cùng VPC, hoặc peering CÙNG REGION | | CIDR block | hoạt động mọi nơi | phải cập nhật khi dải IP đổi |

Trong cùng một VPC, tham chiếu security group luôn là lựa chọn tốt hơn: instance thay đổi IP (autoscaling, thay thế) mà rule không cần sửa.

Ba yêu cầu để VPC peering hoạt động:

① Peering connection đã ACTIVE (bên kia chấp nhận)
② ROUTE TABLE ở CẢ HAI VPC có đường tới CIDR của bên kia
③ SECURITY GROUP cho phép lưu lượng

Bước ② hay bị quên: peering ở trạng thái active mà không có route thì gói tin không đi đâu cả — và triệu chứng là timeout, không có thông báo lỗi rõ ràng.

Ba hạn chế của VPC peering cần nhớ: | Hạn chế | Chi tiết | |---|---| | KHÔNG bắc cầu (transitive) | A↔B và B↔C KHÔNG cho A↔C | | CIDR KHÔNG được chồng lấn | hai VPC cùng dải 10.0.0.0/16 không peering được | | Tham chiếu security group chỉ trong cùng Region | ← điểm của câu này |

Dòng đầu là lý do Transit Gateway ra đời: với nhiều hơn vài VPC, số peering connection tăng theo cấp số nhân (n×(n−1)/2), và không cái nào bắc cầu được. Transit Gateway là hub trung tâm giải quyết chuyện đó.

Security group và NACL — phân biệt: | | Security group | Network ACL | |---|---|---| | Mức | ENI/instance | subnet | | Trạng thái | có trạng thái (stateful) | không trạng thái | | Rule | CHỈ Allow | Allow VÀ Deny | | Đánh giá | tất cả rule | theo thứ tự số |

Dòng "chỉ Allow" đáng nhớ: security group không có rule deny — muốn chặn một IP cụ thể thì phải dùng NACL. Đây là nội dung của một câu hỏi khác trong bộ này.

Và một thực hành nên theo cho CSDL: đặt instance CSDL trong private subnet không có route ra Internet, chỉ mở đúng cổng cho đúng nguồn. Kết hợp với việc dùng IAM database authentication (RDS hỗ trợ) thay cho mật khẩu tĩnh là một cấu hình chặt chẽ hơn nữa.

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

A company has recently set up AWS Organizations to get all its AWS accounts under one organization to standardize the monitoring and compliance needs of the company. The company has the following requirements:

a) All user actions have to be logged. b) Based on the company's security needs, define alarms that respond to specific user actions. c) Send real-time alerts for the alarms raised.

Which of the following options can be combined to create an optimal solution for the given requirements? (Select two)

  1. A

    Use Amazon Athena to analyze the logs and trigger notification to an Amazon Simple Notification Service (Amazon SNS) topic
  2. B

    Implement an AWS CloudTrail trail as an organizational trail. Configure the trail to store logs in an Amazon S3 bucket
  3. C

    Implement an AWS CloudTrail trail as an organizational trail. Configure the trail to forward the trail data to an Amazon CloudWatch Logs log group
  4. D

    In CloudWatch Logs, set a metric filter for any user action event the company needs to track. Create an Amazon CloudWatch alarm against the metric. When triggered, the alarm sends notifications to the subscribed users through an Amazon Simple Notification Service (Amazon SNS) topic
  5. E

    Define an AWS Lambda function to process the logs and send messages to an Amazon Simple Queue Service (Amazon SQS) queue
Xem giải thích

Đáp án

C và D.

  • C — Tạo organizational CloudTrail trail trong tài khoản quản lý, ghi log của mọi tài khoản thành viên vào một bucket S3 tập trung
  • D — Bật log file validation để đảm bảo tính toàn vẹn của log

Vì sao đúng

Đề nêu ba yêu cầu, và cặp C+D thoả cả ba: | Yêu cầu | Cơ chế | |---|---| | Ghi log mọi hoạt động API trong TẤT CẢ tài khoản | organizational trail | | Lưu trữ tập trung | một bucket S3 duy nhất | | Đảm bảo tính toàn vẹn | log file validation |

C — organizational trail là tính năng riêng cho AWS Organizations:

aws cloudtrail create-trail   --name trail-toan-to-chuc   --s3-bucket-name log-kiem-toan-tap-trung   --is-organization-trail   --is-multi-region-trail

Ưu điểm so với tạo trail riêng ở từng tài khoản: | Ưu điểm | Chi tiết | |---|---| | Cấu hình MỘT LẦN ở tài khoản quản lý | áp cho mọi tài khoản thành viên | | Tài khoản mới tự động được bao phủ | không cần nhớ cấu hình thủ công | | Tài khoản thành viên KHÔNG tắt được | quan trọng cho kiểm toán | | Tập trung vào một bucket | dễ phân tích và lưu trữ |

Dòng thứ ba là giá trị bảo mật cốt lõi: kẻ tấn công chiếm được một tài khoản thành viên không thể tắt trail để xoá dấu vết — chỉ tài khoản quản lý mới làm được.

D — log file validation cho tính toàn vẹn:

aws cloudtrail update-trail --name trail-toan-to-chuc   --enable-log-file-validation

Cơ chế: CloudTrail tạo file digest mỗi giờ, chứa hash SHA-256 của từng file log trong giờ đó, và file digest được ký số bằng khoá riêng của CloudTrail.

Log files (mỗi 5 phút)
    ↓ hash SHA-256
Digest file (mỗi giờ) — chứa hash của mọi log file
    ↓ ký số bằng private key của CloudTrail
    ↓ digest file cũng tham chiếu digest file TRƯỚC ĐÓ (chuỗi liên kết)

Chuỗi liên kết giữa các digest file là chi tiết quan trọng: nó khiến việc xoá cả một file log và file digest tương ứng cũng bị phát hiện — vì digest kế tiếp trỏ ngược lại cái đã mất.

aws cloudtrail validate-logs   --trail-arn arn:aws:cloudtrail:...:trail/trail-toan-to-chuc   --start-time 2026-08-01T00:00:00Z

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

  • A. Bật CloudTrail ở TỪNG tài khoản riêng lẻ và cấu hình mỗi cái ghi vào bucket S3 riêng — đây là phương án gần nhất và hoạt động được, nhưng nó thua ở ba mặt: nhiều công (cấu hình từng tài khoản), tài khoản mới dễ bị bỏ sót, và log phân tán trái yêu cầu tập trung. Quan trọng hơn: quản trị viên của mỗi tài khoản tắt được trail của mình.
  • B. Dùng AWS Config ghi lại mọi thay đổi cấu hình trên tất cả tài khoản — sai loại dữ liệu: Config theo dõi cấu hình tài nguyên, không ghi lời gọi API. Đề yêu cầu "all API activity". (Config là bổ sung tốt, nhưng không thay thế được CloudTrail.)
  • E. Dùng Amazon Macie giám sát và bảo vệ dữ liệu nhạy cảm trong log — sai phạm vi: Macie phát hiện dữ liệu nhạy cảm trong S3, nó không liên quan tới việc thu thập log hay đảm bảo tính toàn vẹn.

Ghi nhớ

Ba loại trail của CloudTrail: | Loại | Phạm vi | |---|---| | Single-Region trail | một Region | | Multi-Region trail | mọi Region trong một tài khoản | | Organization trail | mọi tài khoản × mọi Region ← câu này |

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

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

Dòng thứ ba là thiết kế được khuyến nghị: đặt bucket log ở một tài khoản Log Archive riêng trong Organizations, nơi rất ít người có quyền. Đây là mẫu chuẩn của AWS Control Tower.

Ba điều cần biết về organizational trail: | Điều | Chi tiết | |---|---| | Chỉ tạo từ tài khoản quản lý hoặc delegated administrator | | | Tài khoản thành viên THẤY được log của mình | nhưng không sửa được trail | | Áp tự động cho tài khoản mới gia nhập | |

Và một lưu ý về chi phí: organizational trail với management event thì trail đầu tiên miễn phí cho mỗi tài khoản. Nhưng data event tính phí theo số sự kiện trên mọi tài khoản — nên bật data event ở mức tổ chức cần cân nhắc kỹ về khối lượng (xem thêm câu #7688).

Câu 39 Infrastructure Security

At XYZ Corporation, the IT team had recently discovered a security loophole that could potentially allow unauthorized access to sensitive data. To fix the issue and ensure the protection of their company's information, the team wants to establish the ability to delete an AWS KMS Customer Master Key (CMK) within a 24-hour timeframe. This would prevent the key from being used for encrypt or decrypt operations and keep their data secure.

Which of the following solutions will address the given use case?

  1. A

    Utilize the scheduled key deletion feature in KMS to set the minimum wait time for deletion
  2. B

    Use the manual key rotation feature within KMS to instantly create a new CMK
  3. C

    Alter the KMS CMK alias to immediately stop any services from utilizing the CMK
  4. D

    Implement the KMS import key function to perform an immediate delete operation
Xem giải thích

Đáp án

D — Triển khai chức năng nhập khẩu khoá (import key) của KMS để thực hiện thao tác xoá TỨC THÌ.

Vì sao đúng

Đề nêu yêu cầu rất cụ thể: có khả năng xoá khoá mã hoá trong vòng 24 giờ khi có sự cố bảo mật.

Vấn đề với KMS key thông thường:

schedule-key-deletion:
    thời gian chờ TỐI THIỂU = 7 ngày
    thời gian chờ tối đa   = 30 ngày
    → KHÔNG đáp ứng được yêu cầu 24 giờ

Thời gian chờ này là có chủ đích và KHÔNG rút ngắn được — AWS đặt ra để tránh mất dữ liệu vĩnh viễn do thao tác nhầm.

Giải pháp: khoá với key material NHẬP KHẨU.

Tạo KMS key với Origin = EXTERNAL
    ↓ nhập key material của bạn vào
Khi cần xoá khẩn cấp:
    ↓ DeleteImportedKeyMaterial
    → key material bị xoá NGAY LẬP TỨC
    → CMK chuyển sang trạng thái PendingImport
    → mọi thao tác mã hoá/giải mã THẤT BẠI ngay

aws kms delete-imported-key-material --key-id 1234abcd-...

Hiệu quả tức thì: khác với schedule-key-deletion, lệnh này không có thời gian chờ. Dữ liệu đã mã hoá bằng khoá đó lập tức không giải mã được nữa.

Và có đường lui: bản thân CMK vẫn tồn tại (trạng thái PendingImport) — nếu sự cố được xử lý và bạn còn giữ bản sao key material, nhập lại được và dữ liệu truy cập lại bình thường. Đây là ưu điểm so với việc xoá hẳn CMK.

Cách thứ hai đạt hiệu quả tương tự: đặt thời hạn hết hạn cho key material lúc nhập — nó tự xoá khi tới hạn.

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

  • A. Dùng tính năng xoá khoá của KMS để thực hiện thao tác xoá tức thì — đây là phương án gần nhất và sai ở "tức thì": ScheduleKeyDeletion có thời gian chờ tối thiểu 7 ngày, không có chế độ xoá ngay.
  • B. Dùng tính năng xoay vòng khoá (key rotation) để thực hiện thao tác xoá tức thì — hiểu sai hoàn toàn về xoay vòng: xoay vòng tạo key material MỚI nhưng GIỮ LẠI key material cũ để giải mã dữ liệu đã mã hoá trước đó. Nó không xoá gì cả — ngược với mục đích.
  • C. Dùng tính năng nhập khẩu khoá của KMS để thực hiện thao tác xoay vòng khoá — nhầm thao tác: nhập khẩu khoá là đúng cơ chế, nhưng thao tác cần dùng là xoá key material, không phải xoay vòng.

Ghi nhớ

Ba nguồn key material cho KMS key: | Origin | Ai sinh key material | Xoá tức thì được? | |---|---|---| | AWS_KMS (mặc định) | AWS KMS | ❌ tối thiểu 7 ngày | | EXTERNAL | BẠN — nhập vào | ✅ DeleteImportedKeyMaterial | | AWS_CLOUDHSM | cụm CloudHSM của bạn | tuỳ cấu hình cụm |

Cột cuối là nội dung của câu hỏi — và là lý do chính để chọn key material nhập khẩu.

Bốn lý do dùng key material nhập khẩu: | Lý do | Chi tiết | |---|---| | Xoá tức thì | ← câu này | | Yêu cầu tuân thủ về nguồn gốc khoá | tổ chức phải tự sinh key material | | Giữ bản sao ngoài AWS | escrow key ở nơi khác | | Hết hạn tự động | đặt ValidTo khi nhập |

Bốn hạn chế đi kèm — cái giá phải trả: | Hạn chế | Hệ quả | |---|---| | BẠN chịu trách nhiệm bảo quản | mất key material = mất dữ liệu vĩnh viễn | | KHÔNG tự xoay vòng được | phải tự nhập key material mới | | Không dùng được với multi-Region key nhập tự động | phải nhập riêng từng Region | | Quy trình nhập phức tạp | tải public key + import token, mã hoá key material, nhập |

Dòng đầu là rủi ro nghiêm trọng nhất: với AWS_KMS, AWS đảm bảo độ bền của key material. Với EXTERNAL, không có bản sao nào ở AWS ngoài cái đang dùng — nếu bạn xoá và không còn bản gốc, dữ liệu mất vĩnh viễn.

Quy trình nhập key material:

① GetParametersForImport → nhận public key + import token
② Mã hoá key material của bạn bằng public key đó
③ ImportKeyMaterial với key material đã mã hoá + import token
   (tuỳ chọn: đặt ExpirationModel và ValidTo)

Xoay vòng khoá — làm rõ vì phương án B hiểu sai: | Đặc điểm | Chi tiết | |---|---| | Tạo key material MỚI | cho mọi thao tác mã hoá từ đó trở đi | | GIỮ key material cũ | để giải mã dữ liệu đã mã hoá trước đó | | Key ID và ARN KHÔNG đổi | ứng dụng không cần sửa gì | | Tự động hằng năm (hoặc chu kỳ tuỳ chọn) | chỉ với AWS_KMS origin |

Dòng thứ hai là điểm cốt lõi: xoay vòng không bao giờ làm mất khả năng giải mã — đó là lý do nó không dùng được cho mục đích thu hồi khẩn cấp.

Và một lựa chọn thay thế cho yêu cầu "vô hiệu hoá nhanh" mà không phá huỷ: DisableKey làm khoá ngừng hoạt động ngay lập tức và bật lại được. Nếu yêu cầu thực sự là "ngăn truy cập trong 24 giờ" chứ không phải "xoá vĩnh viễn", đó là công cụ nhẹ hơn và an toàn hơn nhiều.

Câu 40 Threat Detection and Incident Response

During regular maintenance tasks, an application support team noticed an abnormal activity on an Amazon EC2 instance that is configured with an EBS volume. The team immediately informed a Security Engineer of the anomaly. The instance is part of an Auto Scaling Group fronted by an Elastic Load Balancer.

What immediate steps should the Security Engineer take for preventing any further attacks to secure the connecting systems and understand the root cause?

  1. A

    Remove the instance from the Auto Scaling group and deregister the instance from the Elastic Load Balancer. Place the instance within an isolation security group. Launch a new EC2 instance with a forensic toolkit, and allow the forensic toolkit image to connect to the suspicious instance to perform the investigation
  2. B

    Remove the instance from the Auto Scaling group and deregister the instance from the Elastic Load Balancer. Place the instance within an isolation security group and snapshot the Amazon EBS data volumes that are attached to the EC2 instance. Launch an EC2 instance with a forensic toolkit and attach an EBS volume created from the snapshot of the suspicious EBS volume
  3. C

    Remove the instance from the Auto Scaling group. Place the instance within an isolation security group. Launch an EC2 instance with a forensic toolkit, and use the forensic toolkit image to deploy another ENI to inspect all traffic coming from the suspicious instance
  4. D

    Detach the instance from the Auto Scaling group and place it within an isolation security group. Detach the suspicious EBS volume. Launch an EC2 instance with a forensic toolkit and attach the detached EBS volume to investigate
Xem giải thích

Đáp án

B — Tạo snapshot của volume EBS trên instance bị xâm nhập, rồi gắn snapshot đó vào một instance phân tích riêng để điều tra.

Vì sao đúng

Đề yêu cầu điều tra pháp chứng (forensic) một instance bị xâm nhập, và mấu chốt là giữ nguyên bằng chứng.

Vì sao snapshot là cách đúng: | Nguyên tắc pháp chứng | Cách snapshot đáp ứng | |---|---| | Không làm thay đổi bằng chứng gốc | snapshot là bản sao chỉ-đọc tại một thời điểm | | Phân tích trên bản sao | gắn snapshot vào instance khác | | Giữ được instance gốc | vẫn cách ly để điều tra thêm | | Có thể tạo nhiều bản sao | mỗi điều tra viên một bản |

Quy trình xử lý sự cố đầy đủ:

① CÁCH LY  → đổi security group sang một cái không cho phép gì
              (KHÔNG tắt máy — mất dữ liệu trong RAM)
② CHỤP RAM → dump bộ nhớ nếu có công cụ (bằng chứng dễ mất nhất)
③ SNAPSHOT → chụp mọi volume EBS
④ GẮN TAG  → đánh dấu instance và snapshot là bằng chứng
⑤ PHÂN TÍCH→ gắn snapshot (chỉ đọc) vào instance forensic riêng
⑥ Rà log   → CloudTrail, VPC Flow Logs, GuardDuty finding

Và instance phân tích nên nằm ở môi trường tách biệt: | Yêu cầu | Lý do | |---|---| | VPC riêng, không nối với production | tránh lây lan nếu malware còn hoạt động | | Gắn volume ở chế độ chỉ đọc | không sửa bằng chứng | | KHÔNG khởi động từ volume đó | không chạy mã của kẻ tấn công |

Dòng cuối quan trọng: gắn volume làm ổ dữ liệu phụ để đọc, không boot từ nó — boot lên là chạy chính hệ điều hành đã bị xâm nhập.

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

  • A. Chấm dứt (terminate) instance bị xâm nhập và khởi chạy instance mới từ AMI sạch — đây là phương án gần nhất và là bước khôi phục ĐÚNG, nhưng nó phá huỷ toàn bộ bằng chứng. Đề yêu cầu điều tra, và terminate là điều không thể đảo ngược. (Bước này nên làm SAU khi đã snapshot và điều tra xong.)
  • C. Dùng AWS Config rà lịch sử cấu hình của instance — hữu ích nhưng không đủ: Config cho biết cấu hình của tài nguyên AWS đã thay đổi thế nào (security group, IAM role), nhưng không cho biết gì về nội dung bên trong instance — file nào bị sửa, tiến trình nào chạy, dữ liệu nào bị lấy.
  • D. Dùng VPC Flow Logs phân tích lưu lượng mạng tới và từ instance — cũng hữu ích và nên làm, nhưng nó chỉ cho metadata mạng. Nó trả lời "instance đã kết nối tới đâu" chứ không trả lời "chuyện gì xảy ra trên đĩa". Không phải "cách tốt nhất" cho điều tra pháp chứng.

Ghi nhớ

Thứ tự ưu tiên khi xử lý instance bị xâm nhập — cách ly trước, đừng tắt: | Việc | Nên | Không nên | |---|---|---| | Ngăn lây lan | đổi security group thành cái chặn hết | tắt máy — mất RAM | | Giữ bằng chứng | snapshot EBS | terminate instance | | Ngắt quyền | gỡ IAM instance profile hoặc thu hồi phiên | xoá role (ảnh hưởng instance khác) |

Dòng đầu là điểm dễ làm sai nhất: phản xạ tự nhiên là tắt máy, nhưng bộ nhớ RAM chứa bằng chứng quý nhất (khoá mã hoá, tiến trình đang chạy, kết nối mạng đang mở) và mất hết khi tắt.

Ba thứ cần thu thập cho điều tra, theo độ dễ mất: | Bằng chứng | Độ dễ mất | Cách thu | |---|---|---| | RAM | mất ngay khi tắt | dump bộ nhớ | | Kết nối mạng đang mở | mất khi tắt | netstat, VPC Flow Logs | | Đĩa (EBS) | bền | snapshot | | Log ở dịch vụ AWS | bền | CloudTrail, GuardDuty |

Ba nguồn log AWS cho điều tra: | Nguồn | Trả lời | |---|---| | CloudTrail | thông tin đăng nhập của instance đã gọi API nào? | | VPC Flow Logs | instance nói chuyện với đâu? | | GuardDuty | có dấu hiệu đe doạ nào đã được phát hiện? |

Dòng đầu đặc biệt quan trọng: nếu instance có IAM role, kẻ tấn công dùng được role đó để truy cập tài nguyên AWS khác. CloudTrail cho biết chúng đã làm gì — và phạm vi sự cố có thể rộng hơn nhiều so với một instance.

Ba biện pháp chuẩn bị trước cho điều tra pháp chứng: | Biện pháp | Lợi ích | |---|---| | Chuẩn bị sẵn tài khoản forensic riêng | không phải dựng lúc khẩn cấp | | Tự động hoá bằng SSM Automation runbook | cách ly + snapshot + gắn tag bằng một lệnh | | Bật sẵn CloudTrail data event và Flow Logs | log không có sẵn thì không dựng lại được quá khứ |

Dòng cuối là điều đáng nhớ nhất: mọi biện pháp điều tra chỉ hoạt động nếu log đã được bật trước khi sự cố xảy ra. Bật sau thì không có gì để xem.