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

Đáp án

B — Tạo CloudWatch metric filter xử lý log CloudTrail chứa chi tiết lời gọi API, tìm mọi lỗi bằng cách tính đến tất cả các mã lỗi cần theo dõi. Tạo alarm dựa trên TỐC ĐỘ của metric này để gửi thông báo SNS.

Vì sao đúng

Đề nêu hai yêu cầu: cảnh báo gần thời gian thực và tự động hoá, sau khi phát hiện số lượng bất thường các lời gọi API trái phép.

Luồng metric filter là cơ chế đúng vì bài toán cần ĐẾM:

CloudTrail ghi lời gọi API
    ↓ gửi sang CloudWatch Logs
Metric filter đếm các sự kiện có errorCode báo lỗi quyền
    ↓ sinh custom metric
Alarm theo TỐC ĐỘ (số lỗi / khoảng thời gian)
    ↓ vượt ngưỡng
SNS → đội bảo mật

Vế "factoring in all the error codes" là chi tiết quan trọng — lời gọi trái phép hiện ra dưới nhiều mã lỗi khác nhau: | Mã lỗi | Ý nghĩa | |---|---| | AccessDenied | không có quyền | | UnauthorizedOperation | thao tác EC2 không được phép | | *NotAuthorized* | các biến thể khác | | Client.UnauthorizedOperation | dạng của một số dịch vụ |

Filter pattern bao quát:

{ ($.errorCode = "*UnauthorizedOperation") ||
  ($.errorCode = "AccessDenied*") ||
  ($.errorCode = "*NotAuthorized*") }

Và "alarm dựa trên tốc độ" là điểm thiết kế đúng: vài lỗi AccessDenied rải rác là bình thường (ứng dụng thăm dò quyền, người dùng gõ nhầm). Điều bất thường là số lượng lớn trong thời gian ngắn — đúng như đề mô tả.

aws cloudwatch put-metric-alarm   --alarm-name canh-bao-api-trai-phep   --metric-name SoLoiTraiPhep --namespace BaoMat   --statistic Sum --period 300 --threshold 20   --comparison-operator GreaterThanThreshold   --evaluation-periods 1   --alarm-actions arn:aws:sns:...:doi-bao-mat

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

• D. Cấu hình CloudTrail stream dữ liệu sự kiện sang Kinesis; dùng metric mức stream của Kinesis trong CloudWatch để kích hoạt Lambda chạy quy trình xử lý lỗi — đây là phương án gần nhất và sai ở nguồn tín hiệu: metric mức stream của Kinesis đo thông lượng của chính stream (số bản ghi, byte, throttle), không phân biệt được lỗi API với lời gọi thành công. Nó không biết gì về nội dung.
• C. Chạy truy vấn Athena trên log CloudTrail trong S3; dùng QuickSight tạo báo cáo cho bảng điều khiển quản lý — không phải gần thời gian thực: Athena truy vấn theo yêu cầu trên dữ liệu đã lưu, và bảng điều khiển QuickSight là công cụ báo cáo, không phải cảnh báo. Đề yêu cầu "near-real-time warnings".
• A. Trusted Advisor publish metric lên CloudWatch; tạo alarm theo dõi thay đổi trạng thái của các kiểm tra trong nhóm Service Limits — sai loại vấn đề hoàn toàn: Service Limits theo dõi việc chạm hạn mức dịch vụ (số instance, số VPC). Nó không liên quan tới lời gọi API bị từ chối quyền.

Ghi nhớ

Hai cách cảnh báo từ CloudTrail — chọn theo việc có cần đếm hay không: | Cách | Đặc điểm | Dùng khi | |---|---|---| | Metric filter + alarm | ĐẾM và so ngưỡng | cần N lần trong khoảng thời gian ← câu này | | EventBridge rule | phản ứng từng sự kiện, độ trễ thấp | một sự kiện đã đáng báo |

Tiêu chí phân biệt:

"Root user đăng nhập" → EventBridge (một lần đã đáng báo) "20 lỗi AccessDenied trong 5 phút" → metric filter + alarm

Luồng đầy đủ để cảnh báo từ log:

CloudTrail → CloudWatch Logs → Metric Filter → Metric → Alarm → SNS

Bốn mắt xích, mỗi cái một vai trò — bỏ metric filter là không có metric để đặt alarm.

Cú pháp filter pattern cho log JSON:

{ $.eventName = "ConsoleLogin" }                       // một điều kiện
{ ($.errorCode = "AccessDenied*") || ($.errorCode = "*Unauthorized*") }
{ $.userIdentity.type = "Root" }                       // trường lồng nhau
{ $.requestParameters.instanceType = "p4d.24xlarge" }  // tham số cụ thể

Bốn tham số alarm cần hiểu đúng: | Tham số | Ý nghĩa | |---|---| | Period | độ dài mỗi chu kỳ (giây) | | Statistic | Sum cho việc ĐẾM — Average sẽ cho số vô nghĩa | | Threshold | ngưỡng | | EvaluationPeriods | bao nhiêu chu kỳ liên tiếp phải vi phạm | | TreatMissingData | xem câu #7788 — đặt sai gây báo động giả |

Ba mẫu cảnh báo bảo mật đáng có trong mọi tài khoản: | Mẫu | Filter | |---|---| | Lời gọi API trái phép | errorCode chứa AccessDenied hoặc Unauthorized ← câu này | | Root user hoạt động | $.userIdentity.type = "Root" | | Đăng nhập Console thất bại | ConsoleLogin + Failed authentication | | Thay đổi security group | AuthorizeSecurityGroup*, RevokeSecurityGroup* | | CloudTrail bị tắt | StopLogging, DeleteTrail |

Danh sách này gần trùng với chín kiểm soát giám sát của CIS AWS Foundations Benchmark — và Security Hub với chuẩn CIS tự đánh giá xem bạn đã cấu hình chúng chưa.

Vì sao số lượng lớn lỗi trái phép là dấu hiệu đáng lo: | Nguyên nhân | Mức nghiêm trọng | |---|---| | Thông tin đăng nhập bị lộ, kẻ tấn công đang dò quyền | cao — mẫu điển hình | | Ứng dụng mới triển khai thiếu quyền | thấp, nhưng nên biết | | Script cũ dùng API đã đổi | thấp |

Dòng đầu là lý do cảnh báo này quan trọng: khi kẻ tấn công lấy được một access key, việc đầu tiên chúng làm là thử hàng loạt API để xem quyền tới đâu — sinh ra đúng mẫu "nhiều lỗi AccessDenied trong thời gian ngắn" mà alarm này bắt được.

Đáp án

A và D.

• A — Cấu hình CloudWatch Event (EventBridge) lọc finding của GuardDuty khi nghi ngờ có hoạt động độc hại; sự kiện gọi một Lambda function phân tích finding và lưu vào bảng DynamoDB nếu cần
• D — Sau khi kiểm tra các bản ghi đã có trong DynamoDB, Lambda tạo rule trong AWS WAF và trong VPC NACL, và gửi email thông báo qua SNS

Vì sao đúng

Đề yêu cầu tự động phát hiện và khắc phục dựa trên finding của GuardDuty, và cặp A+D dựng một luồng hai giai đoạn hợp lý:

GuardDuty sinh finding
    ↓ A: EventBridge rule lọc theo mức nghiêm trọng
Lambda phân tích finding
    ↓ ghi vào DynamoDB (IP độc hại, thời điểm, loại finding)
    ↓ D: kiểm tra bản ghi đã có
    ├─ IP đã bị chặn rồi  → bỏ qua, không làm gì thêm
    └─ IP mới             → tạo rule WAF + rule NACL
                          → gửi SNS

Vai trò của DynamoDB là điểm thiết kế đáng chú ý — nó không phải chỗ chứa dữ liệu cho vui: | Vai trò | Lý do | |---|---| | Chống trùng lặp | GuardDuty sinh nhiều finding cho cùng một IP | | Tránh chạm giới hạn | NACL chỉ có ~20 rule mặc định, WAF IP set có hạn mức | | Lưu vết để dọn dẹp | biết rule nào tạo lúc nào để gỡ sau |

Nếu không kiểm tra trùng lặp: mười finding cho cùng một IP sẽ tạo mười rule giống hệt, và NACL đầy rất nhanh — sau đó mọi rule mới đều thất bại im lặng.

Và hai lớp chặn bổ sung nhau: | Lớp | Chặn ở đâu | |---|---| | WAF rule | tầng 7, trước CloudFront/ALB | | NACL rule | tầng 3/4, ở biên subnet — chặn cả lưu lượng không phải HTTP |

Event pattern cho A:

{
  "source": ["aws.guardduty"],
  "detail-type": ["GuardDuty Finding"],
  "detail": {"severity": [{"numeric": [">=", 7]}]}
}

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

• C. Cấu hình Lambda tạo rule trong WAF và VPC NACL cho MỌI finding của GuardDuty và gửi email qua SNS — đây là phương án gần nhất và thiếu đúng bước kiểm tra trùng lặp: tạo rule cho mọi finding sẽ nhanh chóng làm đầy NACL và IP set, sau đó hệ thống ngừng hoạt động. D khác C ở chỗ có bước "sau khi kiểm tra các bản ghi đã có".
• E. Cấu hình GuardDuty gọi thẳng một Lambda function mỗi khi sinh finding; dùng DynamoDB lưu dữ liệu Lambda nhận được — GuardDuty không gọi Lambda trực tiếp: nó phát finding sang EventBridge, và EventBridge mới là thứ gọi target. Không có tích hợp trực tiếp GuardDuty → Lambda.
• B. Cấu hình GuardDuty xuất finding ra S3 bucket; Lambda được kích hoạt mỗi khi có object mới trong bucket — hoạt động được nhưng chậm hơn nhiều: GuardDuty xuất finding sang S3 theo lô, với độ trễ tới 15 phút hoặc hơn. Đề yêu cầu khắc phục tự động, mà mỗi phút trễ là thêm rủi ro. (Xuất sang S3 hữu ích cho lưu trữ lâu dài và phân tích, không phải cho phản ứng tức thì.)

Ghi nhớ

Luồng chuẩn để tự động khắc phục từ GuardDuty:

GuardDuty → EventBridge → Lambda hoặc SSM Automation → hành động khắc phục
                       ↓
                      SNS → thông báo cho người

GuardDuty KHÔNG gọi Lambda trực tiếp — EventBridge luôn là mắt xích ở giữa.

Ba loại target khắc phục của EventBridge: | Target | Đặc điểm | |---|---| | Lambda function | linh hoạt nhất, viết logic tuỳ ý | | SSM Automation document | hành động chuẩn, KHÔNG cần viết mã | | Step Functions | quy trình nhiều bước có trạng thái |

SSM Automation đáng cân nhắc cho các hành động chuẩn như cách ly instance hay chặn IP — nó có sẵn document và không phải bảo trì mã.

Mức nghiêm trọng của finding GuardDuty: | Mức | Giá trị | Nên phản ứng | |---|---|---| | Low | 1–3.9 | ghi nhận | | Medium | 4–6.9 | điều tra | | High | 7–8.9 | khắc phục tự động | | Critical | 9–10 | khắc phục + báo động |

Lọc theo mức nghiêm trọng là bước đầu tiên nên làm — tự động khắc phục cho mọi finding kể cả mức Low sẽ tạo rất nhiều hành động không cần thiết.

Ba hành động khắc phục tự động thường dùng: | Hành động | Chống | |---|---| | Chặn IP trong WAF IP set / NACL | ← câu này | | Gắn security group cách ly cho instance | instance bị xâm nhập (xem câu #7796) | | Thu hồi phiên IAM, vô hiệu hoá access key | thông tin đăng nhập bị lạm dụng |

Ba giới hạn cần biết khi tự động tạo rule chặn: | Giới hạn | Giá trị mặc định | |---|---| | Rule mỗi NACL | 20 (tăng được tới 40) | | Địa chỉ trong một WAF IP set | 10.000 | | Rule mỗi WAF Web ACL | 1.500 WCU |

Giới hạn NACL là chặt nhất và dễ chạm nhất — đó là lý do bước kiểm tra trùng lặp trong đáp án D là bắt buộc, không phải tối ưu.

Và một cơ chế dọn dẹp cần có mà đề không nhắc tới: rule chặn IP nên có thời hạn. Địa chỉ IP được cấp lại cho người khác, và một IP bị chặn vĩnh viễn từ hai năm trước có thể đang thuộc về khách hàng thật. Dùng TTL của DynamoDB kết hợp một Lambda dọn định kỳ để gỡ rule quá hạn.

Và nhớ dùng WAF IP set thay vì tạo rule mới cho mỗi IP: IP set là một tài nguyên chứa nhiều địa chỉ, cập nhật bằng một lời gọi API — sạch hơn nhiều so với sinh ra hàng trăm rule riêng lẻ.

Đáp án

D — Vì CMK mới bị xoá một ngày trước, nó phải đang ở trạng thái "pending deletion" — nên chỉ cần huỷ lệnh xoá để khôi phục khoá.

Vì sao đúng

Đề cho một chi tiết thời gian quyết định: CMK bị xoá MỘT NGÀY trước.

Vì sao con số đó cứu được tình hình:

ScheduleKeyDeletion:
    thời gian chờ TỐI THIỂU = 7 ngày
    thời gian chờ tối đa   = 30 ngày

Mới một ngày trôi qua
    → khoá đang ở trạng thái PendingDeletion
    → CHƯA bị xoá thật
    → CancelKeyDeletion khôi phục được

Thời gian chờ 7–30 ngày tồn tại chính xác vì tình huống này: nó là cửa sổ để phát hiện và đảo ngược thao tác nhầm hoặc độc hại.

# ① Huỷ lệnh xoá
aws kms cancel-key-deletion --key-id 1234abcd-12ab-34cd-56ef-1234567890ab

# ② BẮT BUỘC: bật lại khoá — huỷ xoá chỉ đưa khoá về trạng thái Disabled
aws kms enable-key --key-id 1234abcd-12ab-34cd-56ef-1234567890ab

Bước ② là chi tiết hay bị bỏ sót: sau CancelKeyDeletion, khoá ở trạng thái Disabled, không phải Enabled. Quên bật lại thì mọi thao tác giải mã vẫn thất bại — và người vận hành tưởng việc khôi phục không thành công.

Trạng thái của KMS key: | Trạng thái | Dùng được? | |---|---| | Enabled | ✅ | | Disabled | ❌ — trạng thái sau khi huỷ xoá | | PendingDeletion | ❌ nhưng CÒN CỨU ĐƯỢC | | Đã xoá | ❌ vĩnh viễn |

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

• C. Công ty nên đăng thông báo trên ứng dụng web báo cho người dùng biết dữ liệu đã mất — đây là phương án gần nhất về mặt "nếu khoá đã thực sự bị xoá", nhưng nó bỏ qua cửa sổ 7 ngày. Chấp nhận mất dữ liệu khi còn khôi phục được là sai lầm nghiêm trọng.
• **A. Liên hệ AWS Support để lấy CMK từ bản sao lưu của họ — AWS không giữ bản sao lưu key material đã xoá. Nếu họ giữ thì việc xoá khoá không còn ý nghĩa bảo mật nào.
• B. Root user có thể khôi phục CMK — root không có đặc quyền này. Với KMS, root user cũng bị ràng buộc bởi key policy và không có khả năng khôi phục khoá đã xoá thật.

Ghi nhớ

Vòng đời xoá KMS key:

① ScheduleKeyDeletion    → PendingDeletion (7–30 ngày)
   ↑ CancelKeyDeletion + EnableKey   → CÒN CỨU ĐƯỢC ở đây
② Hết thời gian chờ      → XOÁ VĨNH VIỄN
   → mọi dữ liệu mã hoá bằng nó KHÔNG BAO GIỜ giải mã được

Đối chiếu với câu #7737 — hai tình huống, hai kết cục: | | Câu này | Câu #7737 | |---|---|---| | Trạng thái khoá | PendingDeletion (1 ngày) | đã xoá thật | | Cứu được không | ✅ CancelKeyDeletion | ❌ chỉ cứu được dữ liệu trên EBS đang gắn | | Bài học | thời gian chờ là cứu cánh | không có gì khôi phục được khoá |

Hành vi của dữ liệu khi CMK ở trạng thái PendingDeletion: | Tài nguyên | Trong thời gian chờ | |---|---| | S3 object SSE-KMS | KHÔNG đọc được (mỗi lần đọc gọi KMS) | | EBS volume đang gắn | vẫn đọc ghi được (data key đã nạp vào hypervisor) | | EBS volume tháo ra rồi gắn lại | không được | | RDS đang chạy | vẫn chạy, nhưng khởi động lại thì hỏng |

Nghĩa là dịch vụ đã bị gián đoạn ngay từ lúc đặt lịch xoá, không phải chờ tới ngày thứ 7 — đó là lý do sự cố được phát hiện nhanh.

Bốn biện pháp ngăn tình huống này: | Biện pháp | Chi tiết | |---|---| | SCP chặn kms:ScheduleKeyDeletion | ← xem câu #7731 | | EventBridge cảnh báo khi có lịch xoá | có 7–30 ngày để phản ứng | | Đặt thời gian chờ TỐI ĐA 30 ngày | mặc định chỉ 7 | | Bật multi-Region key hoặc sao lưu key material | với khoá nhập khẩu |

Cảnh báo EventBridge là biện pháp rẻ nhất và hiệu quả nhất:

{"source": ["aws.kms"],
 "detail": {"eventName": ["ScheduleKeyDeletion", "DisableKey",
                          "DeleteImportedKeyMaterial"]}}

Ba thao tác KMS nguy hiểm cần giám sát: | Thao tác | Hậu quả | Đảo ngược | |---|---|---| | DisableKey | ngừng hoạt động NGAY | ✅ EnableKey | | ScheduleKeyDeletion | ngừng ngay, xoá sau 7–30 ngày | ✅ trong thời gian chờ | | DeleteImportedKeyMaterial | ngừng NGAY, vĩnh viễn (khoá nhập khẩu) | ❌ trừ khi còn bản gốc |

Dòng cuối nguy hiểm nhất — với khoá dùng key material nhập khẩu, không có thời gian chờ nào cả (xem câu #7702).

Và một điểm về quy trình: đề nói "một thành viên đội bảo mật vô tình xoá". Đó là dấu hiệu quyền kms:ScheduleKeyDeletion đang được cấp quá rộng. Sau khi khôi phục, việc đáng làm là giới hạn quyền đó cho một role riêng cần phê duyệt, chứ không phải chỉ nhắc nhở cẩn thận hơn.

Đáp án

B — Thiết lập một Service Control Policy (SCP) cấm thay đổi CloudTrail, và gắn nó vào các tài khoản của lập trình viên.

Vì sao đúng

Đề nêu ràng buộc quyết định: lập trình viên có quyền ở mức ROOT USER trong tài khoản của chính họ, nhưng cấu hình CloudTrail bắt buộc không được sửa đổi.

Chỉ SCP làm được điều đó:

IAM policy         → root user KHÔNG bị ràng buộc bởi IAM policy
Permissions boundary → KHÔNG áp cho root user
SCP                → ÁP CHO CẢ ROOT USER của tài khoản thành viên  ✓

Đây là đặc tính riêng và quan trọng nhất của SCP — nó là loại chính sách duy nhất mà root user của một tài khoản thành viên không vượt qua được.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "BaoVeCloudTrail",
    "Effect": "Deny",
    "Action": [
      "cloudtrail:StopLogging",
      "cloudtrail:DeleteTrail",
      "cloudtrail:UpdateTrail",
      "cloudtrail:PutEventSelectors"
    ],
    "Resource": "*"
  }]
}

Và vì sao root user không sửa được SCP: SCP được quản lý ở tài khoản quản lý của AWS Organizations. Lập trình viên là root của tài khoản thành viên, không có quyền gì ở tài khoản quản lý.

Tài khoản quản lý (đội bảo mật)
    └── OU Lập trình viên  ←  SCP gắn ở đây
            ├── Tài khoản của A   (A là root ở đây, nhưng vẫn bị SCP ràng buộc)
            ├── Tài khoản của B
            └── Tài khoản của C

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

• A. Thiết lập một IAM policy cấm thay đổi CloudTrail và gắn nó vào root user — đây là phương án gần nhất và không thực hiện được về mặt kỹ thuật: không gắn IAM policy vào root user được. Root user là danh tính đặc biệt, không phải IAM user, và không bị IAM policy ràng buộc.
• C. Cấu hình một trail mới từ bên trong tài khoản của lập trình viên với tuỳ chọn organization trail bật — sai nơi tạo: organization trail chỉ tạo được từ tài khoản quản lý hoặc delegated administrator. Và nếu trail được tạo từ tài khoản của lập trình viên thì họ vẫn sửa được nó.
• D. Thiết lập service-linked role cho CloudTrail với điều kiện policy chỉ cho phép thay đổi từ ARN thuộc tài khoản master — hiểu sai service-linked role: SLR là role mà chính dịch vụ AWS dùng để thao tác thay mặt bạn. Nó không phải cơ chế kiểm soát ai được sửa cấu hình.

Ghi nhớ

Bảng so sánh ba loại chính sách theo khả năng ràng buộc root: | Loại | Áp cho root của tài khoản thành viên | |---|---| | IAM policy | ❌ root không bị ràng buộc | | Permissions boundary | ❌ không áp cho root | | SCP | ✅ CÓ | | Resource-based policy (S3, KMS) | ✅ có — nhưng chỉ cho tài nguyên đó |

Dòng cuối đáng nhớ thêm: bucket policy và key policy cũng ràng buộc được root (xem câu #7696) — nhưng phạm vi hẹp, chỉ cho một tài nguyên.

Bốn đặc tính của SCP: | Đặc tính | Chi tiết | |---|---| | KHÔNG cấp quyền | chỉ giới hạn; vẫn cần IAM policy Allow | | ÁP cho root của tài khoản thành viên | ← điểm mấu chốt câu này | | KHÔNG áp cho tài khoản QUẢN LÝ | nên đừng đặt workload ở đó | | KHÔNG áp cho service-linked role | tránh làm hỏng dịch vụ AWS |

Bộ SCP nền tảng nên có ở mọi tổ chức — bảo vệ chính các cơ chế kiểm soát: | Nhóm | Hành động cần chặn | |---|---| | Bảo vệ CloudTrail | StopLogging, DeleteTrail, UpdateTrail ← câu này | | Bảo vệ dịch vụ phát hiện | guardduty:Delete*, config:Delete*, securityhub:Disable* | | Bảo vệ tổ chức | organizations:LeaveOrganization | | Bảo vệ dữ liệu | kms:ScheduleKeyDeletion, xoá bucket log | | Giới hạn Region | NotAction + aws:RequestedRegion |

Mô hình kiến trúc đúng cho tình huống của đề:

Tài khoản quản lý
    ├── Organization trail (áp cho MỌI tài khoản, member KHÔNG tắt được)
    ├── SCP bảo vệ CloudTrail
    └── OU Lập trình viên
            └── các tài khoản cá nhân

Organization trail là mảnh ghép còn thiếu mà đề chưa nhắc tới: nó tạo từ tài khoản quản lý, tự động áp cho mọi tài khoản thành viên (kể cả tài khoản mới), và tài khoản thành viên không tắt được — kết hợp với SCP thì hai lớp bảo vệ chồng lên nhau.

Ba lưu ý khi viết SCP bảo vệ CloudTrail: | Lưu ý | Lý do | |---|---| | Chặn UpdateTrail, không chỉ StopLogging | sửa trail để trỏ sang bucket khác cũng là né tránh | | Chặn cả PutEventSelectors | tắt data event cũng làm mất khả năng giám sát | | Cân nhắc ngoại lệ cho một role vận hành | dùng ArnNotLike với aws:PrincipalArn |

Và một điểm về mô hình mà đề mô tả: cấp tài khoản AWS riêng cho từng lập trình viên với quyền root là mô hình hợp lệ và được AWS khuyến khích cho môi trường thử nghiệm — miễn là có SCP làm rào chắn và tài khoản đó tách biệt hoàn toàn khỏi sản xuất. Không có SCP thì mô hình này rất rủi ro.

Đáp án

D — CloudWatch alarm có thể đang được cấu hình coi điểm dữ liệu thiếu là điểm vi phạm. Hãy cấu hình alarm đánh giá điểm dữ liệu thiếu là NOT BREACHING.

Vì sao đúng

Đề mô tả triệu chứng chính xác: alarm được đặt để chỉ báo khi metric vi phạm ngưỡng nhiều chu kỳ liên tiếp, nhưng nó báo ngay sau một lần vi phạm.

Nguyên nhân: điểm dữ liệu THIẾU đang được tính là VI PHẠM.

Cấu hình: EvaluationPeriods = 3, DatapointsToAlarm = 3

Thực tế xảy ra:
  Chu kỳ 1: metric KHÔNG có dữ liệu  → coi là BREACHING  ✗
  Chu kỳ 2: metric KHÔNG có dữ liệu  → coi là BREACHING  ✗
  Chu kỳ 3: metric vi phạm thật      → BREACHING         ✓
      → đủ 3/3 → ALARM

→ Người vận hành thấy: "chỉ vi phạm MỘT lần mà đã báo động"

Đổi sang notBreaching thì hai chu kỳ thiếu dữ liệu không còn tính vào, và alarm chỉ kích hoạt khi có đủ ba lần vi phạm thật.

aws cloudwatch put-metric-alarm   --alarm-name canh-bao-cpu   --treat-missing-data notBreaching   --evaluation-periods 3 --datapoints-to-alarm 3   ...

Vì sao dữ liệu bị thiếu ngay từ đầu: đây là chuyện bình thường với nhiều loại metric: | Nguyên nhân | Ví dụ | |---|---| | Metric chỉ phát khi có hoạt động | 4xxErrorRate không có dữ liệu khi không có lỗi nào | | Custom metric phát không đều | ứng dụng chỉ gửi khi có sự kiện | | Instance dừng hoặc bị thay thế | ASG thay máy | | Agent gián đoạn | mất kết nối tạm thời |

Dòng đầu là trường hợp phổ biến nhất — và cũng là lý do notBreaching thường là lựa chọn đúng.

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

• C. Alarm có thể chưa được cấu hình coi điểm thiếu là vi phạm; hãy cấu hình đánh giá điểm thiếu là BREACHING — đây là phương án gần nhất và sai ngược hoàn toàn: đặt thành breaching sẽ làm vấn đề nặng thêm, khiến alarm kích hoạt còn dễ dàng hơn.
• A. Nếu alarm không truy cập được metric cần theo dõi thì alarm được kích hoạt như hành vi mặc định — sai về hành vi mặc định: khi không có dữ liệu, giá trị mặc định của TreatMissingData là missing, nghĩa là chu kỳ đó bị bỏ qua khi đánh giá, không phải kích hoạt alarm.
• B. Metric hẳn là chỉ báo cáo dữ liệu ngắt quãng theo thiết kế; với loại metric đó cần dùng Lambda gửi dữ liệu liên tục — chẩn đoán đúng một nửa nhưng giải pháp sai: metric ngắt quãng đúng là nguyên nhân gốc, nhưng cách xử lý là cấu hình TreatMissingData cho phù hợp, không phải viết một Lambda bơm dữ liệu giả.

Ghi nhớ

Bốn giá trị của TreatMissingData — bảng cần thuộc: | Giá trị | Hành vi khi thiếu dữ liệu | |---|---| | missing (mặc định) | BỎ QUA chu kỳ đó — không tính vào đánh giá | | notBreaching | coi như BÌNH THƯỜNG ← đáp án | | breaching | coi như VI PHẠM | | ignore | giữ nguyên trạng thái alarm hiện tại |

Cách chọn:

Metric ngắt quãng, thiếu dữ liệu là bình thường → notBreaching Metric phải luôn có dữ liệu; thiếu = hệ thống chết → breaching Không chắc, muốn alarm ổn định → ignore

Ví dụ cho breaching: metric heartbeat của một tiến trình. Không có dữ liệu nghĩa là tiến trình đã chết — đúng là tình huống cần báo động.

Bốn tham số quyết định hành vi alarm: | Tham số | Ý nghĩa | |---|---| | Period | độ dài mỗi chu kỳ (giây) | | EvaluationPeriods | số chu kỳ được XEM XÉT | | DatapointsToAlarm | số chu kỳ phải VI PHẠM để báo động | | TreatMissingData | xử lý chu kỳ thiếu dữ liệu |

DatapointsToAlarm khác EvaluationPeriods — đây là cơ chế "M trên N":

EvaluationPeriods = 5, DatapointsToAlarm = 3
    → xem 5 chu kỳ gần nhất
    → báo động nếu 3 trong 5 chu kỳ vi phạm
    → chịu được biến động ngắn, vẫn bắt được vấn đề kéo dài

Đây là cấu hình đáng dùng cho metric hay nhiễu — nó giảm báo động giả mà không làm chậm phản ứng với sự cố thật.

Ba trạng thái của alarm: | Trạng thái | Ý nghĩa | |---|---| | OK | trong ngưỡng | | ALARM | vượt ngưỡng | | INSUFFICIENT_DATA | chưa đủ dữ liệu để kết luận |

Trạng thái thứ ba đáng chú ý: alarm mới tạo luôn bắt đầu ở đây. Nếu alarm mắc kẹt ở INSUFFICIENT_DATA, nguyên nhân thường là sai tên metric, sai namespace, hoặc sai dimension — không phải vấn đề dữ liệu.

Ba lỗi cấu hình alarm thường gặp: | Lỗi | Hậu quả | |---|---| | TreatMissingData sai | báo động giả hoặc bỏ sót ← câu này | | Dùng Average để đếm sự kiện | con số vô nghĩa — phải dùng Sum | | Period nhỏ hơn tần suất phát metric | nhiều chu kỳ thiếu dữ liệu |

Dòng cuối liên quan trực tiếp tới câu này: metric của EC2 mặc định phát mỗi 5 phút (basic monitoring). Đặt Period = 60 sẽ tạo ra bốn chu kỳ thiếu dữ liệu trong mỗi năm phút — và nếu TreatMissingData là breaching thì alarm gần như báo động liên tục. Bật detailed monitoring (1 phút) hoặc đặt Period khớp tần suất thật.

Đáp án

A, D và E:

• A — Nếu đăng ký Shield Advanced, bạn có thể đăng ký Elastic IP làm Protected Resource
• D — Khi dùng CloudFront và WAF với API Gateway, cấu hình cache behavior chuyển tiếp MỌI header tới regional endpoint của API Gateway
• E — Security group gắn cho ALB nên được cấu hình để KHÔNG dùng connection tracking

Vì sao đúng

Ba phát biểu này đều đến từ tài liệu AWS Best Practices for DDoS Resiliency.

A — Shield Advanced bảo vệ Elastic IP: | Tài nguyên bảo vệ được | Ghi chú | |---|---| | Elastic IP | ← phát biểu A | | CloudFront distribution | | | Route 53 hosted zone | | | ALB, NLB, Classic Load Balancer | | | Global Accelerator | |

E — connection tracking là điểm tinh tế nhất và cũng thực tế nhất:

Security group có TRẠNG THÁI → nó THEO DÕI từng kết nối
    → mỗi kết nối chiếm một mục trong bảng theo dõi
    → bảng này có DUNG LƯỢNG GIỚI HẠN theo loại instance
    → DDoS tạo hàng triệu kết nối → BẢNG ĐẦY
    → kết nối hợp lệ mới bị từ chối, dù CPU và băng thông còn dư

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

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

Đánh đổi cần hiểu rõ: | | Tracked | Untracked | |---|---|---| | Bảo vệ khỏi cạn bảng theo dõi | ❌ | ✅ | | Lọc theo cổng và nguồn | ✅ | ❌ phải mở toàn bộ | | Phù hợp | hầu hết trường hợp | ALB đứng trước, có WAF lọc ở tầng 7 |

Đây là lý do khuyến nghị chỉ áp cho ALB: ALB đã có WAF phía trước lọc tầng 7, nên việc security group của nó mở rộng không làm giảm mức bảo vệ tổng thể — trong khi nó loại bỏ một nút thắt khi bị tấn công.

D — chuyển tiếp header khi đặt CloudFront trước API Gateway: dùng regional endpoint (không phải edge-optimized) và chuyển tiếp header để API Gateway nhận đúng ngữ cảnh request.

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

• C. Dùng Network Load Balancer định tuyến theo NỘI DUNG và chỉ chấp nhận web request đúng định dạng; NLB chặn nhiều tấn công DDoS phổ biến như SYN flood hay UDP reflection — đây là phương án gần nhất và trộn hai sự thật thành một mệnh đề sai: NLB hoạt động ở tầng 4, KHÔNG định tuyến theo nội dung — đó là việc của ALB. (Vế "chặn SYN flood, UDP reflection" thì đúng.)
• B. Cấu hình API Gateway với edge-optimized endpoint bất cứ khi nào có thể và gắn nó với CloudFront distribution của bạn — mâu thuẫn nội tại: edge-optimized endpoint đã dùng một CloudFront distribution do API Gateway quản lý. Bạn không gắn thêm distribution của mình vào đó. Khi tự đặt CloudFront phía trước, phải dùng regional endpoint — đúng như phát biểu D nói.
• F. Dùng WAF để cấu hình web ACL trên các S3 bucket chứa dữ liệu quan trọng — WAF không gắn được vào S3 bucket. Muốn bảo vệ nội dung S3 bằng WAF thì đặt CloudFront phía trước rồi gắn web ACL vào CloudFront.

Ghi nhớ

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

Connection tracking — cơ chế đằng sau phát biểu E: | Điều | Chi tiết | |---|---| | Security group là stateful | phản hồi tự động được phép | | Cái giá: phải theo dõi từng luồng | mỗi luồng một mục trong bảng | | Bảng có giới hạn theo loại instance | đầy bảng = từ chối kết nối mới | | Rule cho phép mọi thứ hai chiều = untracked | không tốn mục nào |

Hệ quả liên quan tới ứng phó sự cố: vì kết nối đã được theo dõi không bị ngắt khi bạn đổi rule, gắn security group cách ly không cắt được kết nối đang mở — đó chính là nội dung câu #7796.

Ba dịch vụ biên và tấn công chúng chống được: | Dịch vụ | Chống | |---|---| | CloudFront | HTTP flood, hấp thụ ở hơn 600 điểm biên | | Route 53 | tấn công vào DNS | | Global Accelerator | TCP/UDP không phải HTTP | | Shield Standard | SYN flood, UDP reflection (tự động, miễn phí) |

Hai loại endpoint của API Gateway và cách dùng với CloudFront: | Endpoint | Khi nào | |---|---| | Edge-optimized | để API Gateway tự quản CloudFront | | Regional | khi bạn tự đặt CloudFront phía trước ← phát biểu D |

Chọn sai gây ra hai tầng CloudFront chồng nhau — tăng độ trễ và làm việc gỡ lỗi rối rắm.

Ba metric của Shield Advanced để giám sát: | Metric | Cho biết | |---|---| | DDoSDetected | có tấn công hay không (0/1) | | DDoSAttackBitsPerSecond | quy mô tầng 3/4 | | DDoSAttackRequestsPerSecond | quy mô tầng 7 |

Và một cấu hình đáng bật cùng Shield Advanced: proactive engagement — đội SRT của AWS tự vào cuộc khi phát hiện tấn công, thay vì chờ bạn mở ticket. Trong một cuộc tấn công, khác biệt về thời gian phản ứng là rất lớn.

Đáp án

C và D.

• C — Tạo AWS WAF ACL dùng IP match condition chỉ cho phép các IP đang được cho phép trong security group của EC2, và gắn WAF ACL vào CloudFront distribution
• D — Cấu hình Origin Access Identity (OAI) gắn với CloudFront distribution; đặt bucket policy sao cho chỉ OAI đọc được object

Vì sao đúng

Đề mô tả một bài toán chuyển đổi: quyền truy cập trước đây do security group của EC2 kiểm soát, giờ nội dung nằm trên S3 sau CloudFront — cần giữ nguyên hạn chế theo IP.

Hai đáp án bịt hai đường khác nhau, và cần cả hai:

① Người dùng → CloudFront
   C: WAF ACL với IP set → chỉ IP của nhà cung cấp đi qua được

② CloudFront → S3
   D: OAI + bucket policy → chỉ CloudFront đọc được S3

Thiếu C: ai cũng truy cập được nội dung qua CloudFront. Thiếu D: kẻ tấn công gọi thẳng URL của S3, bỏ qua CloudFront và bỏ qua luôn WAF.

Dòng thứ hai là lỗ hổng hay bị bỏ sót nhất khi đặt CDN trước kho lưu trữ: mọi biện pháp ở tầng CDN đều vô nghĩa nếu origin vẫn nhận request trực tiếp.

Bucket policy với OAI:

{
  "Effect": "Allow",
  "Principal": {"AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity E1ABCDEF"},
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::kho-noi-dung-tinh/*"
}

Kết hợp với Block Public Access bật ở mức bucket, S3 trở nên hoàn toàn riêng tư.

Và WAF là nơi đúng để lọc IP vì CloudFront không có security group:

{
  "Name": "ChiChoPhepNhaCungCap",
  "Statement": {"NotStatement": {"Statement": {
    "IPSetReferenceStatement": {"ARN": "arn:aws:wafv2:us-east-1:...:global/ipset/nha-cung-cap"}}}},
  "Action": {"Block": {}}
}

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

• A. Tạo WAF ACL với IP match condition và gắn WAF ACL vào BUCKET POLICY của S3 — đây là phương án gần nhất và sai ở nơi gắn: WAF không gắn được vào S3 bucket, và không có khái niệm "gắn WAF ACL vào bucket policy". WAF chỉ gắn vào CloudFront, ALB, API Gateway, AppSync, Cognito User Pool, App Runner.
• E. Tạo security group mới cho phép cùng dải IP và gắn vào CloudFront distribution — CloudFront không có security group: nó là dịch vụ biên toàn cầu, không nằm trong VPC nào của bạn.
• B. Tạo NACL mới cho phép cùng dải IP và gắn vào CloudFront distribution — cùng lỗi khái niệm: NACL gắn với subnet trong VPC, không gắn được vào CloudFront.

Ghi nhớ

Bảng công cụ kiểm soát theo loại tài nguyên — nhóm hay bị nhầm: | Tài nguyên | Kiểm soát bằng | |---|---| | EC2, ENI | security group | | Subnet | NACL | | CloudFront, ALB, API Gateway | AWS WAF | | S3 bucket | bucket policy, Block Public Access | | CloudFront → S3 | OAC (hoặc OAI) |

Ba dòng đầu là ba tầng khác nhau — dùng nhầm công cụ cho nhầm tầng là lỗi phổ biến nhất trong nhóm câu hỏi này.

OAC và OAI — nên biết cả hai: | | OAI (cũ) | OAC (khuyến nghị hiện nay) | |---|---|---| | Hỗ trợ SSE-KMS | ❌ KHÔNG | ✅ CÓ | | Hỗ trợ mọi Region | có hạn chế | ✅ | | Hỗ trợ PUT, DELETE | ❌ chỉ GET | ✅ | | Cơ chế | principal đặc biệt của CloudFront | ký SigV4, ràng buộc theo AWS:SourceArn |

Dòng đầu là lý do chính để chuyển sang OAC: nếu bucket dùng SSE-KMS, OAI không đọc được object — và triệu chứng là lỗi 403 khó hiểu.

(Đáp án dùng OAI vì đó là cơ chế có trong các phương án. Triển khai mới hôm nay nên dùng OAC.)

Bucket policy cho OAC:

{
  "Effect": "Allow",
  "Principal": {"Service": "cloudfront.amazonaws.com"},
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::kho-noi-dung-tinh/*",
  "Condition": {"StringEquals": {
    "AWS:SourceArn": "arn:aws:cloudfront::111122223333:distribution/E1ABCDEF"}}
}

Ba cách hạn chế truy cập ở CloudFront: | Cách | Đặc điểm | |---|---| | WAF IP set | theo địa chỉ IP ← câu này | | Geo restriction | theo quốc gia, MIỄN PHÍ | | Signed URL / signed cookie | theo từng người dùng, có thời hạn |

Signed URL đáng cân nhắc cho tình huống của đề: nếu danh sách IP của nhà cung cấp thay đổi thường xuyên, ràng buộc theo IP sẽ thành gánh nặng bảo trì. Signed URL gắn quyền vào danh tính và thời hạn thay vì vào vị trí mạng — bền hơn nhiều.

Lưu ý về phạm vi WAF cho CloudFront: Web ACL dùng cho CloudFront phải được tạo ở us-east-1 với scope là CLOUDFRONT. Tạo ở Region khác thì không gắn được — một lỗi hay gặp khi triển khai lần đầu:

aws wafv2 create-web-acl --scope CLOUDFRONT --region us-east-1 ...

Và nhớ bật Block Public Access ở mức bucket song song với OAI/OAC: nó đảm bảo rằng ngay cả khi ai đó vô tình thêm một ACL công khai, bucket vẫn không lộ ra.

Đáp án

A — Thêm hành động kms:GenerateDataKey vào IAM policy.

Vì sao đúng

Đề mô tả triệu chứng rõ ràng: lấy object hiện có thì được, tải object mới lên thì bị từ chối, với policy đã có kms:Decrypt và kms:Encrypt.

Nguyên nhân nằm ở cách mã hoá phía client hoạt động — nó dùng MÃ HOÁ PHONG BÌ:

Đọc object (hoạt động ✓):
    Client lấy bản mã của data key từ metadata object
        → gọi kms:Decrypt để mở data key
        → dùng data key giải mã dữ liệu

Ghi object (thất bại ✗):
    Client cần một DATA KEY MỚI
        → gọi kms:GenerateDataKey   ← KHÔNG CÓ QUYỀN NÀY
        → nhận về data key dạng RÕ + dạng MÃ HOÁ
        → mã hoá dữ liệu cục bộ bằng bản rõ
        → lưu bản mã hoá của data key cùng object

Điểm mấu chốt: kms:Encrypt KHÔNG thay thế được kms:GenerateDataKey. | Hành động | Việc | |---|---| | kms:Encrypt | mã hoá một mẩu dữ liệu nhỏ TRỰC TIẾP bằng KMS key (tối đa 4 KB) | | kms:GenerateDataKey | SINH một khoá đối xứng mới, trả về cả bản rõ lẫn bản mã |

Vì sao mã hoá phong bì tồn tại: KMS giới hạn 4 KB cho dữ liệu mã hoá trực tiếp, và mỗi lời gọi đều tốn thời gian và tiền. Với tệp lớn, client sinh một data key, mã hoá dữ liệu cục bộ — nhanh hơn nhiều và không giới hạn kích thước.

Policy sau khi sửa:

{
  "Sid": "KMS",
  "Effect": "Allow",
  "Action": ["kms:Decrypt", "kms:Encrypt", "kms:GenerateDataKey"],
  "Resource": "arn:aws:kms:us-west-1:111122223333:key/keyid-12345"
}

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

• **D. Thêm kms:GetDataKey — đây là phương án gần nhất về mặt tên gọi và là bẫy chính: không tồn tại hành động nào tên kms:GetDataKey. Tên đúng là GenerateDataKey.
• **B. Thêm kms:GetPublicKey — dành cho khoá BẤT ĐỐI XỨNG: nó lấy public key của một KMS key RSA hoặc ECC để mã hoá hoặc xác minh chữ ký ở phía client. Không liên quan tới mã hoá đối xứng thông thường.
• **C. Thêm kms:GetKeyPolicy — hành động QUẢN TRỊ: nó đọc key policy của khoá. Không liên quan gì tới việc mã hoá dữ liệu.

Ghi nhớ

Ba hành động KMS liên quan tới mã hoá — bảng cần thuộc: | Hành động | Việc | Giới hạn | |---|---|---| | Encrypt | mã hoá TRỰC TIẾP bằng KMS key | tối đa 4 KB | | GenerateDataKey | sinh data key: trả về bản RÕ + bản MÃ | không giới hạn dữ liệu | | GenerateDataKeyWithoutPlaintext | chỉ trả bản mã | dùng khi chưa cần mã hoá ngay | | Decrypt | giải mã bản mã | 4 KB |

Quy tắc thực dụng:

Dữ liệu nhỏ (mật khẩu, token) → Encrypt / Decrypt trực tiếp Dữ liệu lớn (tệp, object) → GenerateDataKey + mã hoá cục bộ

Mã hoá phía client và phía máy chủ — bảng quyền: | Kiểu | Ghi cần | Đọc cần | |---|---|---| | Client-side (SDK) | GenerateDataKey | Decrypt | | SSE-KMS (một phần) | GenerateDataKey | Decrypt | | SSE-KMS (multipart) | GenerateDataKey + Decrypt | Decrypt |

Cả ba dòng đều cần GenerateDataKey để ghi — nên đó là quyền quan trọng nhất trong nhóm này, và cũng là quyền hay bị thiếu nhất.

Triệu chứng thiếu quyền KMS và nguyên nhân: | Triệu chứng | Thiếu | |---|---| | Đọc được, GHI thất bại | kms:GenerateDataKey ← câu này | | Ghi được, ĐỌC thất bại | kms:Decrypt | | Tệp nhỏ được, tệp LỚN thất bại | kms:Decrypt (multipart) — xem câu #7723 |

Ba triệu chứng, ba nguyên nhân khác nhau — nhận diện đúng tiết kiệm rất nhiều thời gian gỡ lỗi.

Client-side và server-side encryption — khi nào chọn cái nào: | | Client-side | Server-side (SSE-KMS) | |---|---|---| | Ai mã hoá | ứng dụng của bạn | S3 | | AWS có thấy dữ liệu rõ không | ❌ KHÔNG BAO GIỜ | ✅ trong bộ nhớ tạm thời | | Công sức | cao — dùng SDK, quản lý luồng | thấp — bật một cờ | | Phù hợp | yêu cầu tuân thủ nghiêm ngặt nhất | hầu hết trường hợp |

Đề chọn client-side vì đó là yêu cầu của đội bảo mật — và cái giá là ứng dụng phải tự lo mã hoá, cùng với việc gặp đúng lỗi quyền trong câu hỏi này.

Và nhớ key policy là lớp thứ hai: quyền KMS đòi cả IAM policy lẫn key policy cùng cho phép. Đề chỉ hỏi về IAM policy, nhưng nếu sửa xong mà vẫn lỗi thì chỗ tiếp theo cần kiểm tra là key policy có statement uỷ quyền cho tài khoản (Principal: root) hay không.

Đáp án

C — Tạo bucket S3 MỚI ở us-east-1 với replication bật sang bucket ở us-west-1. Bật SSE-KMS trên bucket mới bằng một AWS KMS MULTI-REGION KEY. Sao chép dữ liệu hiện có từ bucket cũ sang bucket mới này.

Vì sao đúng

Đề nêu một yêu cầu rất cụ thể: dữ liệu phải được mã hoá và giải mã bằng CÙNG MỘT KHOÁ ở cả hai Region.

Multi-Region key (MRK) là tính năng duy nhất của KMS đáp ứng điều đó:

KMS key thông thường:
  us-east-1: key-A  (key material X)
  us-west-1: key-B  (key material Y, KHÁC HOÀN TOÀN)
  → replication phải GIẢI MÃ bằng A rồi MÃ HOÁ LẠI bằng B

Multi-Region key:
  us-east-1: mrk-abc123  ┐
  us-west-1: mrk-abc123  ┴ CÙNG key material, cùng key ID
  → bản mã tạo ở Region này giải mã được ở Region kia

Và vì sao phải tạo bucket MỚI chứ không sửa bucket cũ — đây là điểm cốt lõi:

KHÔNG chuyển đổi được một KMS key đơn Region thành multi-Region key.

Tính chất multi-Region được quyết định lúc TẠO khoá (--multi-region true) và không thay đổi được sau đó.

Nên quy trình bắt buộc là:

① Tạo MRK ở us-east-1
② Nhân bản (replicate) MRK sang us-west-1
③ Tạo bucket MỚI ở us-east-1, đặt mã hoá mặc định = MRK
④ Sao chép dữ liệu cũ sang → được mã hoá lại bằng MRK
⑤ Bật replication sang bucket ở us-west-1 với MRK bản sao

# Tạo multi-Region key
aws kms create-key --multi-region --region us-east-1

# Nhân bản sang Region khác
aws kms replicate-key --key-id mrk-abc123   --replica-region us-west-1 --region us-east-1

Bước ④ là chỗ tốn công nhất — mọi object hiện có phải được ghi lại để mang khoá mới. Nhưng không có đường tắt: object đã mã hoá bằng khoá cũ vẫn gắn với khoá cũ cho tới khi được ghi lại.

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

• B. Chuyển đổi KMS key đơn Region hiện tại thành multi-Region key; bật S3 Batch Replication cho dữ liệu hiện có — đây là phương án gần nhất và thất bại ở bước đầu tiên: không có API nào chuyển đổi khoá đơn Region thành multi-Region. Tính chất này bất biến từ lúc tạo.
• D. Bật replication cho bucket hiện tại sang us-west-1; chia sẻ KMS key từ us-east-1 sang us-west-1 — KMS key là tài nguyên KHU VỰC: không "chia sẻ sang Region khác" được. Bạn chia sẻ được với tài khoản khác trong cùng Region, nhưng không vượt Region.
• A. CloudWatch scheduled rule gọi Lambda sao chép dữ liệu hằng ngày; cấp quyền KMS cho Lambda ở cả hai bucket — hoạt động được nhưng sai về nhiều mặt: nó không đáp ứng yêu cầu cùng một khoá (mỗi Region vẫn một khoá riêng); nó không phải thời gian thực (mỗi ngày một lần); và nó là mã tự viết thay cho tính năng có sẵn của S3.

Ghi nhớ

Multi-Region key — đặc điểm cần thuộc: | Đặc điểm | Chi tiết | |---|---| | Cùng key material ở mọi Region | bản mã giải được ở bất kỳ bản sao nào | | Cùng key ID (tiền tố mrk-) | ARN khác nhau theo Region | | Key policy và grant ĐỘC LẬP | mỗi bản sao quản lý quyền riêng | | Xoay vòng đồng bộ | primary xoay thì replica theo | | Phải tạo với --multi-region | KHÔNG chuyển đổi được sau |

Dòng thứ ba là điểm quan trọng về bảo mật: hai bản sao dùng chung key material nhưng quyền truy cập độc lập — bạn cấp quyền giải mã ở us-west-1 cho một đội mà không ảnh hưởng us-east-1.

Khi nào cần MRK và khi nào không: | Tình huống | Cần MRK? | |---|---| | Cross-Region Replication với yêu cầu CÙNG khoá | ✅ ← câu này | | Khôi phục thảm hoạ đa Region | ✅ — giải mã được ở Region dự phòng | | Ứng dụng client-side encryption chạy nhiều Region | ✅ | | CRR thông thường | ❌ — S3 tự mã hoá lại bằng khoá đích |

Dòng cuối đáng nhớ: S3 CRR hoạt động bình thường với hai khoá khác nhau — nó giải mã ở nguồn và mã hoá lại ở đích. MRK chỉ cần khi có yêu cầu tường minh về cùng một khoá, như đề này nêu.

Ba quyền KMS cần cho CRR với SSE-KMS: | Bên | Quyền | |---|---| | Replication role ở nguồn | kms:Decrypt trên khoá nguồn | | Replication role ở đích | kms:Encrypt, kms:GenerateDataKey trên khoá đích | | Bucket đích | chấp nhận object đã mã hoá |

Thiếu một trong hai là replication thất bại im lặng — object không được sao chép và triệu chứng chỉ hiện trong metric ReplicationLatency và OperationsFailedReplication.

Hai cách xử lý dữ liệu ĐÃ CÓ khi bật replication: | Cách | Đặc điểm | |---|---| | S3 Batch Replication | sao chép object có sẵn qua một job được quản lý | | Sao chép thủ công (aws s3 sync, CopyObject) | đơn giản cho lượng nhỏ |

S3 CRR thông thường chỉ áp cho object MỚI — object có trước khi bật replication không tự sao chép. Đây là điều hay gây bất ngờ.

Và một lưu ý về chi phí MRK: mỗi bản sao của multi-Region key tính phí như một khoá riêng (khoảng 1 USD/tháng mỗi Region), cộng phí lời gọi API. Với hai Region thì không đáng kể, nhưng nhân lên nhiều Region và nhiều khoá thì nên cân nhắc — và nhớ rằng CRR thông thường không đòi MRK.

Đáp án

B — Dùng Console EC2 bật mã hoá mặc định cho volume EBS mới. Dùng tính năng instance refresh của Auto Scaling group để thay thế các instance hiện có bằng instance mới.

Vì sao đúng

Đề nêu hai yêu cầu, và chữ "và trong tương lai" quyết định đáp án: | Yêu cầu | Cơ chế | |---|---| | Mã hoá volume HIỆN CÓ | instance refresh — thay máy cũ bằng máy mới | | Đảm bảo mọi volume tương lai đều được mã hoá | bật mã hoá mặc định ở mức TÀI KHOẢN |

Vì sao "encryption by default" mạnh hơn sửa launch template:

Sửa launch template:
    → chỉ áp cho instance do ASG NÀY tạo
    → ai đó tạo EC2 bằng tay      → volume KHÔNG mã hoá
    → ASG khác dùng template khác → volume KHÔNG mã hoá
    → tạo volume rời qua Console  → KHÔNG mã hoá

Bật mã hoá mặc định (mức tài khoản + Region):
    → MỌI volume EBS mới đều được mã hoá
    → không ai vô tình tạo được volume không mã hoá

Đề nói "ensures all EBS volumes are encrypted both now AND IN THE FUTURE" — cụm sau chỉ được đảm bảo bằng cài đặt ở mức tài khoản.

aws ec2 enable-ebs-encryption-by-default --region ap-northeast-1
aws ec2 modify-ebs-default-kms-key-id --kms-key-id alias/khoa-ebs-cong-ty

Và instance refresh xử lý vế "hiện tại" một cách có kiểm soát:

aws autoscaling start-instance-refresh   --auto-scaling-group-name asg-ung-dung   --preferences '{"MinHealthyPercentage": 90, "InstanceWarmup": 300}'

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

• D. Sửa launch template đặt cờ encrypted = true cho mọi volume EBS; dùng instance refresh để thay thế instance — đây là phương án gần nhất và giải quyết được ASG này, nhưng nó không đảm bảo "in the future" cho volume tạo ngoài ASG. (Và về mặt kỹ thuật, launch template là bất biến — bạn tạo một phiên bản mới, không "sửa" nó.)
• A. Tạo launch template MỚI từ template cũ với cờ encrypted = true; cập nhật ASG dùng template mới; để ASG thay thế dần các instance cũ theo thời gian — cùng hạn chế như D, cộng thêm việc chờ thay thế tự nhiên là không xác định thời gian: instance cũ có thể chạy hàng tháng nếu không có sự kiện scaling nào.
• C. Bật mã hoá mặc định trong Console EC2; truyền cài đặt này xuống ASG để nó tự động thay thế instance hiện có — mô tả một cơ chế không tồn tại: bật mã hoá mặc định không kích hoạt ASG thay thế instance. Phải chủ động dùng instance refresh.

Ghi nhớ

Ba đặc điểm của "EBS encryption by default": | Đặc điểm | Chi tiết | |---|---| | Phạm vi: TÀI KHOẢN × REGION | phải bật ở TỪNG Region | | Chỉ áp cho volume MỚI | volume có sẵn không đổi | | Không tắt được ở mức từng volume | một khi bật thì không có ngoại lệ |

Dòng đầu là việc hay bị bỏ sót: bật ở ap-northeast-1 không bảo vệ us-east-1. Nên bật cho mọi Region đang dùng, và cân nhắc tắt hẳn các Region không dùng (xem câu #7733).

Vì sao không mã hoá được volume tại chỗ:

Volume EBS đã tồn tại → KHÔNG bật mã hoá trực tiếp được
Quy trình:
  ① Chụp snapshot của volume
  ② SAO CHÉP snapshot với tuỳ chọn mã hoá
  ③ Tạo volume mới từ snapshot đã mã hoá
  ④ Tháo volume cũ, gắn volume mới

Bốn bước và có thời gian ngừng dịch vụ — đó là lý do bật mã hoá từ đầu tiết kiệm rất nhiều công.

Ba cách thay thế instance trong ASG: | Cách | Đặc điểm | |---|---| | Instance refresh | có kiểm soát, giữ tỷ lệ lành mạnh, huỷ được ← câu này | | Tăng rồi giảm desired capacity | thủ công, thô | | Chờ thay thế tự nhiên | không xác định thời gian |

Bốn tuỳ chọn quan trọng của instance refresh: | Tuỳ chọn | Việc | |---|---| | MinHealthyPercentage | giữ bao nhiêu phần trăm dịch vụ trong lúc thay | | InstanceWarmup | chờ bao lâu trước khi coi instance mới là sẵn sàng | | CheckpointPercentages | dừng ở các mốc để kiểm tra | | SkipMatching | bỏ qua instance đã dùng cấu hình mới nhất |

CheckpointPercentages đáng dùng cho môi trường sản xuất: thay 20% rồi dừng, kiểm tra, rồi tiếp tục — thay vì để chạy hết một mạch.

Ba lớp đảm bảo mã hoá EBS — nên dùng nhiều lớp: | Lớp | Vai trò | |---|---| | Encryption by default | ngăn chặn từ đầu | | SCP chặn ec2:CreateVolume không mã hoá | rào chắn cấp tổ chức | | AWS Config rule encrypted-volumes | phát hiện vi phạm còn sót |

Lớp thứ hai bằng điều kiện:

{"Effect": "Deny", "Action": "ec2:CreateVolume", "Resource": "*",
 "Condition": {"Bool": {"ec2:Encrypted": "false"}}}

Và một lưu ý về khoá dùng để mã hoá: mặc định là AWS managed key aws/ebs, nhưng nó không chia sẻ snapshot chéo tài khoản được (xem câu #7801). Nếu có nhu cầu đó, hãy đặt modify-ebs-default-kms-key-id trỏ vào một CMK do bạn quản lý ngay từ đầu.