Ngân hàng đề — AWS Certified Solutions Architect Professional

Đáp án

C — Dùng AWS Budgets tạo một budget loại RI coverage với ngưỡng 70%, cấu hình cảnh báo gửi cho đội DevOps.

Vì sao đúng

Câu này kiểm tra hai điều rất cụ thể: dịch vụ nào tạo được ngưỡng và cảnh báo, và coverage khác utilization thế nào.

⚠ Điểm mấu chốt: coverage và utilization là hai con số ngược chiều nhau, và đề hỏi cái thứ nhất:

RI COVERAGE: bao nhiêu phần trăm KHỐI LƯỢNG CÔNG VIỆC được RI phủ
        ↓
    "70% giờ chạy EC2 của tôi được tính giá RI"
        ↓
    Coverage thấp → đang trả giá On-Demand nhiều hơn cần thiết

RI UTILIZATION: bao nhiêu phần trăm RI ĐÃ MUA đang được dùng
        ↓
    "RI tôi mua đang được dùng 70%"
        ↓
    Utilization thấp → đã mua thừa, tiền đang lãng phí

Đề nói "RIs should cover 70% of the workload" — đó là coverage, không phải utilization. Đây là lý do phương án B sai.

aws budgets create-budget --account-id 111122223333 \
  --budget '{
    "BudgetName": "ri-coverage-ec2",
    "BudgetType": "RI_COVERAGE",
    "TimeUnit": "MONTHLY",
    "CostFilters": {"Service": ["Amazon Elastic Compute Cloud - Compute"]},
    "BudgetLimit": {"Amount": "70", "Unit": "PERCENTAGE"}}' \
  --notifications-with-subscribers file://canh-bao.json

⚠ Cảnh báo coverage phải là "thấp hơn ngưỡng", không phải "cao hơn":

Budget chi phí thông thường: cảnh báo khi VƯỢT ngưỡng
        ↓
Budget coverage và utilization: cảnh báo khi TỤT DƯỚI ngưỡng
        ↓
    → đặt nhầm chiều so sánh thì cảnh báo không bao giờ kêu,
      và bạn tin rằng mọi thứ vẫn ổn

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

• B (dùng Billing and Cost Management console tạo reservation budget cho RI UTILIZATION, đặt mức 70%) — đây là phương án gần nhất và nó dùng đúng dịch vụ: AWS Budgets thật sự có loại budget cho reservation, và console Billing là nơi truy cập nó. Nó chỉ chọn sai loại chỉ số. Utilization trả lời "RI đã mua có được dùng không", còn đề hỏi "khối lượng công việc có được RI phủ đủ 70% không" — tức là coverage. Hai con số này có thể lệch nhau hoàn toàn: bạn có thể có utilization 100% (mọi RI đều được dùng) trong khi coverage chỉ 30% (phần lớn máy vẫn chạy giá On-Demand vì mua quá ít RI). Đây là bẫy tinh vi nhất của câu hỏi vì mọi thứ khác đều đúng.

• A (dùng AWS Cost Explorer tạo budget cho RI coverage) — chọn đúng chỉ số nhưng sai dịch vụ. Cost Explorer là công cụ phân tích và trực quan hoá — nó hiển thị được báo cáo RI coverage rất tốt, nhưng nó không tạo budget và không gửi cảnh báo. Việc đặt ngưỡng và thông báo thuộc về AWS Budgets. Đây là cặp dịch vụ bị lẫn nhiều nhất trong nhóm quản trị chi phí.

• D (dùng Cost Explorer cấu hình báo cáo RI utilization với mục tiêu 70% và cảnh báo) — gộp cả hai lỗi: sai dịch vụ (Cost Explorer không cảnh báo) và sai chỉ số (utilization thay vì coverage).

Ghi nhớ

⚠ Bốn công cụ chi phí — bảng phải thuộc, đây là chỗ hay lẫn nhất: | Công cụ | Việc | |---|---| | AWS Budgets | đặt ngưỡng và GỬI CẢNH BÁO | | Cost Explorer | phân tích và hiển thị, không cảnh báo | | Cost and Usage Report | dữ liệu chi tiết nhất, xuất ra S3 | | Cost Anomaly Detection | học máy phát hiện chi phí bất thường |

Từ khoá nhận diện:

"alert when ... threshold" → AWS Budgets "RIs should COVER x% of the workload" → RI coverage "RIs I bought are being USED x%" → RI utilization "Cost Explorer to create a budget" → LUÔN SAI, Cost Explorer không tạo budget "report" mà không cần cảnh báo → Cost Explorer là đủ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Coverage hiện tại | Cost Explorer → báo cáo Reservation coverage | | Cảnh báo có kêu không | hạ tạm ngưỡng lên 99% và chờ chu kỳ đánh giá | | Chiều so sánh có đúng không | kiểm ComparisonOperator trong notification |

Và một lời khuyên: hãy theo dõi cả coverage lẫn utilization cùng lúc, đừng chỉ một trong hai. Chúng bắt hai loại lãng phí ngược nhau, và tối ưu một cái mà bỏ cái kia sẽ dẫn bạn đi sai hướng. Nếu chỉ nhìn utilization, con số 100% trông rất đẹp và bạn sẽ kết luận chiến lược RI đang hoàn hảo — trong khi thực tế bạn mua quá ít và phần lớn đội máy vẫn đang trả giá On-Demand. Nếu chỉ nhìn coverage, bạn sẽ mua thêm RI để đẩy con số lên, rồi vô tình mua thừa vào đúng lúc đội máy sắp thu nhỏ. Hai chỉ số cùng cao mới là trạng thái đúng, và không có chỉ số đơn lẻ nào thay thế được cả hai.

Đáp án

C — Dùng VMware vSphere client xuất ứng dụng thành ảnh định dạng OVF; tạo bucket S3 ở Region đích để chứa ảnh; tạo và gán IAM role cho VM Import; dùng AWS CLI chạy lệnh import.

Vì sao đúng

Đề đòi giữ nguyên phần mềm và cấu hình khi chuyển một máy ảo VMware sang EC2. VM Import/Export là dịch vụ dựng riêng cho việc đó.

⚠ Điểm mấu chốt: IAM role tên vmimport với trust policy đặc biệt là bước hay bị quên nhất:

VM Import cần quyền đọc ảnh trong S3 và tạo snapshot EBS
        ↓
    Nhưng nó không dùng quyền của bạn — nó assume một service role
        ↓
    Role đó phải tên `vmimport` và tin service principal vmie.amazonaws.com
        ↓
    → thiếu role này thì lệnh import thất bại ngay, với thông báo về quyền

// Trust policy của role vmimport
{
  "Effect": "Allow",
  "Principal": {"Service": "vmie.amazonaws.com"},
  "Action": "sts:AssumeRole",
  "Condition": {"StringEquals": {"sts:Externalid": "vmimport"}}
}

aws ec2 import-image --description "ung-dung-cu" \
  --disk-containers file://container.json

# theo dõi tiến trình
aws ec2 describe-import-image-tasks --import-task-ids import-ami-0abc123

⚠ Xuất OVF đòi tắt máy ảo — đây là downtime không tránh được với cách này:

vSphere xuất OVF từ máy đang tắt (hoặc snapshot)
        ↓
    Ảnh phản ánh trạng thái tại thời điểm xuất
        ↓
    Dữ liệu thay đổi sau đó KHÔNG có trong ảnh
        ↓
    → nếu cần downtime tối thiểu, dùng AWS MGN với sao chép liên tục thay vì VM Import

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

• B (dựng hybrid activation trong Systems Manager, cài SSM Agent lên VM, đăng ký làm managed instance, dùng AWS Backup tạo snapshot rồi tạo AMI) — đây là phương án gần nhất và hai bước đầu của nó hoàn toàn hợp lệ: Systems Manager thật sự quản lý được máy tại chỗ qua hybrid activation, và đó là cách tốt để vá lỗi và chạy lệnh từ xa. Nhưng nó không tạo được AMI. AWS Backup không sao lưu máy ảo tại chỗ thành AMI — nó sao lưu tài nguyên AWS (EBS, RDS, EFS, DynamoDB, FSx) và có hỗ trợ VMware qua AWS Backup Gateway, nhưng bản sao lưu đó khôi phục về máy ảo VMware, không thành EC2 AMI. Chuỗi "managed instance → snapshot → AMI" mô tả một đường đi không tồn tại.

• A (Storage Gateway file gateway phơi CIFS share, sao lưu vào đó, rồi tạo AMI từ bản sao) — nhầm lẫn giữa sao lưu tệp và ảnh máy. File gateway đồng bộ tệp lên S3 dưới dạng object; không có cơ chế nào biến một thư mục tệp thành AMI khởi động được. AMI cần một ảnh đĩa hoàn chỉnh với boot sector và bảng phân vùng.

• D (DataSync sao chép data store sang FSx for Windows File Server, dùng SMB share làm datastore của VMware, rồi VM Import/Export) — vòng vèo và sai kỹ thuật. FSx for Windows không dùng làm datastore cho vSphere (VMware cần NFS hoặc VMFS trên khối lưu trữ, không phải SMB). Và chuyển datastore không tạo ra tệp OVF để import.

Ghi nhớ

⚠ Bốn cách đưa máy ảo lên EC2 — bảng phải thuộc: | Cách | Downtime | Khi nào | |---|---|---| | VM Import/Export | bằng thời gian xuất + chuyển + nhập | vài máy, giữ nguyên cấu hình | | AWS MGN | vài phút | nhiều máy, cần downtime tối thiểu | | Dựng lại từ đầu bằng IaC | không áp dụng | khi muốn hiện đại hoá | | VMware Cloud on AWS | không | giữ nguyên nền tảng VMware |

Từ khoá nhận diện:

"preserve software and configuration settings" → VM Import/Export hoặc MGN "OVF / OVA / VMDK" → VM Import/Export "minimize downtime" + nhiều máy → MGN "AWS Backup tạo AMI từ VM tại chỗ" → SAI, không có đường đi đó "file gateway để tạo AMI" → SAI, tệp không thành ảnh máy khởi động được

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Import có xong không | describe-import-image-tasks, xem Status | | Máy có khởi động được không | phóng instance từ AMI và thật sự đăng nhập vào | | Ứng dụng có chạy không | chạy thử toàn bộ luồng nghiệp vụ, không chỉ ping |

Và một lời khuyên: hãy phóng một instance từ AMI vừa import và đăng nhập vào kiểm tra trước khi lên kế hoạch cắt chuyển. Trạng thái completed của tác vụ import chỉ nói rằng ảnh đĩa đã được chuyển đổi thành công — nó không nói gì về việc máy có khởi động được trên nền ảo hoá của AWS hay không. Driver thiếu, cấu hình mạng cứng theo card cũ, phần mềm khoá theo địa chỉ MAC, dịch vụ khởi động phụ thuộc một máy chủ nội bộ không còn với tới được — tất cả đều cho ra một AMI hợp lệ về mặt kỹ thuật và một máy không dùng được về mặt thực tế. Khoảng cách giữa hai điều đó chỉ lộ ra khi bạn đăng nhập và thử.

Đáp án

A — Dựng giám sát ở tài khoản trung tâm bằng AWS Budgets, theo dõi số giờ chạy EC2 với chu kỳ hằng ngày, đặt giới hạn cao hơn 15% so với mức trung bình 45 ngày lấy từ Cost Explorer, và cấu hình cảnh báo cho đội kiến trúc.

Vì sao đúng

Đề đòi ba thứ, và Budgets là dịch vụ duy nhất trong danh sách làm được cả ba: theo dõi lượng dùng EC2 trên nhiều tài khoản, so với một ngưỡng cụ thể, thông báo hằng ngày.

⚠ Điểm mấu chốt: usage budget theo dõi SỐ GIỜ chạy, không theo dõi tiền — đúng thứ đề hỏi:

Đề nói "EC2 resource usage exceeds the average by more than 15%"
        ↓
    Đó là lượng dùng, không phải chi phí
        ↓
    Chi phí có thể đổi vì đổi lớp máy, vì RI, vì Spot — không phản ánh đúng "usage"
        ↓
    → BudgetType = USAGE với đơn vị là giờ instance

Quy trình gồm hai bước, và đó chính là điều phương án A mô tả:

Bước 1: Cost Explorer → xem lượng dùng EC2 trong 45 ngày → tính trung bình
Bước 2: AWS Budgets → tạo usage budget với limit = trung bình × 1,15
        ↓
    → cảnh báo khi vượt

aws budgets create-budget --account-id <management> --budget '{
  "BudgetName": "ec2-usage-daily",
  "BudgetType": "USAGE",
  "TimeUnit": "DAILY",
  "CostFilters": {"Service": ["Amazon Elastic Compute Cloud - Compute"]},
  "BudgetLimit": {"Amount": "1265", "Unit": "Hrs"}}'

⚠ Ngưỡng là con số TĨNH — phải cập nhật lại khi mức nền thay đổi:

Đội mở rộng, mức dùng nền tăng
        ↓
    Ngưỡng cũ bị vượt mỗi ngày
        ↓
    Cảnh báo kêu liên tục → mọi người bắt đầu bỏ qua nó
        ↓
    → xem lại và điều chỉnh ngưỡng theo chu kỳ, ví dụ mỗi quý

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

• C (AWS Cost Anomaly Detection ở tài khoản trung tâm, kiểu giám sát AWS Services lọc theo EC2, cảnh báo khi vượt trung bình 45 ngày 15%) — đây là phương án gần nhất và Cost Anomaly Detection là công cụ thật, rất hợp với việc phát hiện chi tiêu bất thường. Nhưng nó không đáp ứng được yêu cầu cụ thể của đề theo hai cách. Thứ nhất, nó dùng học máy để tự học mẫu chi tiêu và cảnh báo khi phát hiện bất thường — bạn không đặt được một quy tắc chính xác kiểu "trung bình 45 ngày cộng 15%"; ngưỡng bạn khai chỉ là mức tiền tối thiểu để một bất thường đáng báo. Thứ hai, nó theo dõi chi phí, không theo dõi lượng dùng. Đây là bẫy hay vì công cụ nghe rất phù hợp cho tới khi đối chiếu với con số cụ thể mà đề yêu cầu.

• B (bật Trusted Advisor ở tài khoản chính, cấu hình cảnh báo tối ưu chi phí khi EC2 vượt trung bình 45 ngày 15%) — Trusted Advisor không hoạt động theo ngưỡng tuỳ chỉnh. Nó chạy một bộ kiểm tra cố định do AWS định nghĩa — instance chạy nhàn rỗi, RI hết hạn, khối lượng công việc chưa tối ưu — và không có cách nào khai một quy tắc riêng như đề mô tả. Nó cũng không có chu kỳ thông báo hằng ngày theo cách này.

• D (CloudWatch ở tài khoản trung tâm, tạo custom metric theo dõi bất thường, cảnh báo khi tăng 15% so với trung bình 45 ngày) — về lý thuyết bạn tự dựng được, nhưng đó là rất nhiều việc: phải tự thu thập số liệu sử dụng từ nhiều tài khoản, tự đẩy vào custom metric, tự tính trung bình trượt 45 ngày. CloudWatch không giữ chỉ số chi tiết tới 45 ngày ở độ phân giải cao và anomaly detection của nó dùng cửa sổ ngắn hơn. Đây là tự xây lại thứ Budgets có sẵn.

Ghi nhớ

⚠ Bốn công cụ giám sát chi phí — bảng phải thuộc: | Công cụ | Ngưỡng tuỳ chỉnh | Theo dõi | |---|---|---| | AWS Budgets | có, bạn tự đặt | chi phí, lượng dùng, RI/SP | | Cost Anomaly Detection | không (học máy tự học) | chi phí | | Trusted Advisor | không (kiểm tra cố định) | tối ưu hoá nói chung | | CloudWatch | có | chỉ số vận hành, không phải chi phí theo mặc định |

Từ khoá nhận diện:

"exceeds X% of the N-day average" → AWS Budgets với ngưỡng tự đặt "resource usage" (giờ chạy) → usage budget, không phải cost budget "daily notification" → TimeUnit: DAILY "Cost Anomaly Detection" khi cần ngưỡng chính xác → SAI, nó dùng học máy "Trusted Advisor" với quy tắc tuỳ chỉnh → LUÔN SAI, kiểm tra cố định

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Trung bình 45 ngày là bao nhiêu | Cost Explorer, lọc EC2, chọn đơn vị Usage quantity | | Cảnh báo có tới không | hạ tạm ngưỡng xuống rất thấp và chờ một chu kỳ | | Budget có phủ mọi tài khoản không | kiểm CostFilters — không lọc LinkedAccount nghĩa là phủ hết |

Và một lời khuyên: hãy đặt lịch xem lại ngưỡng mỗi quý, và ghi ngay trong tên budget ngày nó được tính. Một ngưỡng tĩnh dựa trên trung bình lịch sử bắt đầu chính xác rồi lệch dần theo mọi thay đổi của tổ chức — thêm một đội, ra mắt một sản phẩm, hay chỉ là tăng trưởng bình thường. Khi ngưỡng đã lỗi thời, nó hỏng theo cách tệ nhất: cảnh báo kêu mỗi ngày, ai đó tạo một quy tắc lọc email, và từ đó cảnh báo thật cũng đi vào cùng thư mục ấy. Một budget kêu liên tục còn nguy hiểm hơn một budget không tồn tại, vì nó tạo cảm giác đang có người canh chừng.

Đáp án

A, C — hai bước bật quorum authentication (M của N) cho CloudHSM lần đầu:

• A — Dùng cloudhsm_mgmt_util, bật kênh truyền mã hoá, đăng nhập với vai CO, đăng ký khoá dùng để ký bằng lệnh registerMofnPubKey.
• C — Dùng cloudhsm_mgmt_util, bật kênh truyền mã hoá, đăng nhập với vai CO, đặt giá trị Quorum tối thiểu bằng 2 bằng lệnh setMValue.

Vì sao đúng

Quorum authentication yêu cầu hai thứ, và mỗi bước lo một cái: HSM phải biết ai có quyền phê duyệt (khoá công khai của từng CO), và phải biết cần bao nhiêu chữ ký (giá trị M).

⚠ Điểm mấu chốt: mỗi CO phải đăng ký khoá công khai TRƯỚC, nếu không HSM không xác minh được chữ ký của họ:

Mỗi CO sinh một cặp khoá RSA
        ↓
    registerMofnPubKey đăng ký khoá CÔNG KHAI của họ vào HSM
        ↓
    setMValue đặt số chữ ký tối thiểu = 2
        ↓
    Từ đó: mọi thao tác quản trị cần token được KÝ bởi ít nhất 2 CO
        ↓
    → HSM dùng khoá công khai đã đăng ký để xác minh từng chữ ký

Thứ tự này quan trọng: không thể đặt M lớn hơn số CO đã đăng ký khoá.

# Trong cloudhsm_mgmt_util
aws-cloudhsm> enable_e2e
aws-cloudhsm> loginHSM CO officer1 <mat-khau>
aws-cloudhsm> registerMofnPubKey 1 /home/officer1/khoa-cong-khai.pem
aws-cloudhsm> setMValue 3 2      # dịch vụ 3 (user management), M = 2
aws-cloudhsm> getMValue 3        # xác nhận

⚠ enable_e2e (kênh mã hoá đầu-cuối) là bước bắt buộc, không phải tuỳ chọn:

Thao tác quorum truyền token và chữ ký giữa client và HSM
        ↓
    Không bật kênh mã hoá → dữ liệu nhạy cảm đi ở dạng rõ trong mạng
        ↓
    → cả hai phương án đúng đều nhắc tới bước này, và đó không phải chi tiết thừa

Về getToken (phương án E): lệnh này có thật và là một phần của quy trình quorum — nhưng nó thuộc về lúc thực hiện một thao tác, không thuộc về lúc thiết lập. Đề hỏi các bước để bật quorum authentication.

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

• E (dùng cloudhsm_mgmt_util, bật kênh mã hoá, đăng nhập CO, lấy quorum token bằng lệnh getToken) — đây là phương án gần nhất và getToken là một lệnh thật trong đúng công cụ, thuộc đúng quy trình quorum. Nó chỉ sai về thời điểm. Lấy token là bước đầu tiên khi bạn muốn thực hiện một thay đổi quản trị đã được bảo vệ bởi quorum: lấy token, cho các CO khác ký, rồi nộp token đã ký. Nhưng đề nói rõ "This is the first time this configuration has been setup" — tức là đang hỏi các bước thiết lập, mà lúc đó chưa có gì để lấy token cả. Đây là bẫy phân biệt giữa cấu hình và sử dụng.

• D (dùng AWS IAM tạo policy yêu cầu tối thiểu ba CO) — sai tầng hoàn toàn. IAM không quản lý người dùng bên trong HSM. CloudHSM có hệ thống người dùng riêng (PRECO, CO, CU, AU) hoàn toàn tách biệt với IAM; AWS không có quyền truy cập vào HSM của bạn, đó là điểm bán hàng chính của dịch vụ. Ngoài ra con số ba mâu thuẫn với yêu cầu hai trong đề.

• B (sửa tệp cloudhsm_client.cfg để import khoá và đăng ký khoá ký) — sai công cụ. cloudhsm_client.cfg là tệp cấu hình kết nối — nó khai địa chỉ HSM, chứng chỉ, cổng. Việc đăng ký khoá quorum là một thao tác quản trị trên HSM, phải thực hiện qua cloudhsm_mgmt_util với danh tính CO đã xác thực, không phải bằng cách sửa tệp trên máy khách.

Ghi nhớ

⚠ Bốn vai người dùng của CloudHSM — bảng phải thuộc: | Vai | Quyền | |---|---| | PRECO | vai tạm khi HSM mới, đổi mật khẩu xong thành CO | | CO (Crypto Officer) | quản lý người dùng, cấu hình quorum | | CU (Crypto User) | tạo và dùng khoá — thao tác mật mã thật sự | | AU (Appliance User) | do AWS dùng để đồng bộ và sao lưu, không đọc được khoá |

Từ khoá nhận diện:

"M of N" / "quorum authentication" → registerMofnPubKey + setMValue "first time setup" → các bước cấu hình, không phải bước sử dụng getToken → thuộc lúc THỰC HIỆN thao tác, không phải lúc thiết lập "IAM policy để yêu cầu N crypto officers" → LUÔN SAI, IAM không quản người dùng HSM "sửa cloudhsm_client.cfg" để cấu hình quorum → SAI, đó là tệp cấu hình kết nối

Ba việc kiểm chứng: | Việc | Cách | |---|---| | M đã đặt đúng chưa | getMValue <service> | | Khoá nào đã đăng ký | listUsers xem cột MofnPubKey | | Quorum có hiệu lực không | thử một thao tác quản trị với chỉ một chữ ký — phải bị từ chối |

Và một lời khuyên: hãy đăng ký khoá cho nhiều CO hơn giá trị M, và sao lưu khoá riêng của họ ở nơi tách biệt. Đây là chỗ quorum authentication tự khoá bạn ra ngoài vĩnh viễn: nếu bạn đặt M bằng 2 và chỉ có đúng 2 CO đăng ký khoá, thì việc một người nghỉ việc, mất khoá riêng, hay đơn giản là đi nghỉ mất liên lạc, có nghĩa là không ai còn thực hiện được thao tác quản trị nào trên HSM nữa — kể cả thao tác thêm một CO mới, vì chính nó cũng cần quorum. AWS không thể can thiệp, vì đó chính xác là điều CloudHSM cam kết. Cách thoát duy nhất là khôi phục từ bản sao lưu cũ hơn thời điểm bật quorum.

Đáp án

B, D, E — ba bước để mã hoá cả khi truyền lẫn khi lưu:

• D — Cấu hình CloudFront chuyển hướng request HTTP sang HTTPS.
• E — Bật server-side encryption cho bucket S3 đang dùng.
• B — Tạo bucket policy từ chối mọi thao tác không mã hoá trên bucket đó.

Vì sao đúng

Đề đòi hai lớp mã hoá, và ba bước đúng chia nhau đúng hai lớp đó cộng với cơ chế cưỡng chế.

⚠ Điểm mấu chốt: bật mã hoá là một chuyện, CHẶN đường không mã hoá là chuyện khác:

Bật default encryption (E)
        ↓
    Object mới được mã hoá — nhưng ai đó vẫn PUT được qua HTTP
        ↓
Bucket policy Deny (B)
        ↓
    Chặn hẳn request không dùng TLS và request không kèm mã hoá
        ↓
    → chuyển từ "mặc định an toàn" sang "không thể không an toàn"

Bucket policy làm cả hai việc trong một chính sách:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ChanKhongDungTLS",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": ["arn:aws:s3:::sach-online", "arn:aws:s3:::sach-online/*"],
      "Condition": {"Bool": {"aws:SecureTransport": "false"}}
    },
    {
      "Sid": "ChanPutKhongMaHoa",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::sach-online/*",
      "Condition": {"Null": {"s3:x-amz-server-side-encryption": "true"}}
    }
  ]
}

⚠ aws:SecureTransport là điều kiện đúng cho việc bắt buộc TLS — và nó nằm trong BUCKET POLICY, không nằm trong ACL:

ACL của S3 chỉ cấp quyền đọc/ghi cho principal
        ↓
    Nó KHÔNG có cú pháp Condition
        ↓
    → không thể thêm "aws:SecureTransport": "true" vào ACL
        ↓
    → đây chính là chỗ phương án C sai

Ngoài ra, ACL đã tắt theo mặc định với bucket tạo từ tháng 4/2023.

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

• C (thêm điều kiện "aws:SecureTransport": "true" vào các thao tác đọc ghi trong ACL của S3) — đây là phương án gần nhất và nó dùng đúng điều kiện IAM: aws:SecureTransport chính là khoá để bắt buộc TLS. Nó chỉ đặt điều kiện đó vào sai nơi. ACL của S3 là cơ chế cấp quyền cũ, không hỗ trợ mệnh đề Condition — chúng chỉ liệt kê grantee và quyền (READ, WRITE, FULL_CONTROL), không có cấu trúc để diễn đạt điều kiện. Điều kiện thuộc về bucket policy hoặc IAM policy. Đây là bẫy tinh vi vì nửa nội dung của phương án hoàn toàn chính xác.

• A (cấu hình mã hoá at rest trên CloudFront bằng SSE-KMS) — CloudFront không lưu trữ dữ liệu của bạn theo cách cần mã hoá at rest do bạn cấu hình. Nó là mạng phân phối, cache tại điểm biên; các bản cache do AWS quản lý và mã hoá, nhưng không có tuỳ chọn "SSE-KMS cho CloudFront" như phương án mô tả. Mã hoá at rest là thuộc tính của nơi lưu dữ liệu gốc — tức là S3.

• F (dùng tuỳ chọn RequireSSL khi tạo presigned URL cho bucket) — không tồn tại tuỳ chọn nào tên như vậy. Presigned URL được tạo với endpoint HTTPS theo mặc định, nhưng bản thân URL không mang cơ chế cưỡng chế nào. Cách bắt buộc TLS vẫn là điều kiện aws:SecureTransport trong bucket policy.

Ghi nhớ

⚠ Bốn lớp mã hoá cần phân biệt — bảng phải thuộc: | Lớp | Cách làm | |---|---| | Truyền: người dùng → CloudFront | Viewer protocol policy = Redirect HTTP to HTTPS | | Truyền: CloudFront → origin | Origin protocol policy = HTTPS Only | | Lưu: trong S3 | SSE-S3, SSE-KMS, hoặc DSSE-KMS | | Cưỡng chế | bucket policy với aws:SecureTransport và điều kiện mã hoá |

Từ khoá nhận diện:

"encrypted in transit" → HTTPS ở CloudFront + aws:SecureTransport ở bucket policy "encrypted at rest" → SSE trên S3 "deny unencrypted operations" → bucket policy, đây là bước cưỡng chế "điều kiện trong ACL" → LUÔN SAI, ACL không có Condition "mã hoá at rest trên CloudFront" → SAI, CloudFront không phải nơi lưu dữ liệu gốc

Ba việc kiểm chứng: | Việc | Cách | |---|---| | HTTP có bị chặn không | curl http://<bucket>.s3.amazonaws.com/... — phải bị từ chối | | Object có được mã hoá không | aws s3api head-object, xem ServerSideEncryption | | Policy có chặn đúng không | thử put-object không kèm header mã hoá |

Và một lời khuyên: hãy kiểm tra policy bằng cách thật sự gửi một request HTTP và một request PUT không mã hoá, đừng chỉ đọc lại chính sách. Bucket policy là nơi rất dễ viết ra một mệnh đề trông đúng mà không bao giờ khớp: thiếu ARN của chính bucket trong danh sách Resource khiến các thao tác cấp bucket lọt qua, một Condition đặt sai khoá khiến mệnh đề Deny không bao giờ được kích hoạt. Trong cả hai trường hợp, chính sách vẫn lưu thành công, vẫn hiển thị đầy đủ trong console, và mọi thao tác hợp lệ vẫn chạy bình thường — nên bạn không có lý do gì để nghi ngờ. Thứ duy nhất khác biệt là đường đi mà bạn tưởng đã chặn thì vẫn mở, và nó chỉ mở cho người đi tìm nó.

Đáp án

B — Dùng bucket S3 cho ảnh tĩnh với lớp Intelligent-Tiering; đặt CloudFront distribution trước bucket đó và dùng AWS Lambda để xử lý ảnh.

Vì sao đúng

Đề nêu hai mục tiêu — kiểm soát chi phí và cải thiện hiệu năng — và ba dữ kiện chỉ thẳng tới lời giải: người dùng toàn cầu, mô hình truy cập khó đoán, EFS đang gánh ảnh.

⚠ Điểm mấu chốt: Intelligent-Tiering sinh ra đúng cho mô hình truy cập KHÔNG ĐOÁN ĐƯỢC — điều đề nói thẳng:

Ảnh mới tải lên: được xem nhiều trong vài ngày đầu
        ↓
    Rồi phần lớn rơi vào quên lãng, nhưng vài tấm bỗng lan truyền trở lại
        ↓
    Không có lifecycle policy tĩnh nào bắt được mẫu đó
        ↓
Intelligent-Tiering
        ↓
    Tự theo dõi từng object, tự chuyển tầng, tự chuyển ngược khi được truy cập lại
        ↓
    → không có phí truy xuất khi ảnh nguội bỗng nóng lại

Vì sao Lambda cho phần xử lý ảnh (điểm phân biệt với phương án C). Đề nói ứng dụng có vấn đề hiệu năng lúc cao điểm; nếu vẫn để EC2 sau ALB làm việc xử lý thì nút thắt còn nguyên. Lambda co giãn theo từng ảnh và không tốn gì khi rảnh.

aws s3api put-bucket-intelligent-tiering-configuration \
  --bucket anh-ung-dung --id auto-tier \
  --intelligent-tiering-configuration '{
    "Id":"auto-tier","Status":"Enabled","Filter":{},
    "Tierings":[{"Days":90,"AccessTier":"ARCHIVE_ACCESS"},
                {"Days":180,"AccessTier":"DEEP_ARCHIVE_ACCESS"}]}'

⚠ Intelligent-Tiering tính phí giám sát theo từng object — không hợp với object rất nhỏ:

Phí monitoring tính theo 1.000 object mỗi tháng
        ↓
    Với hàng triệu object vài KB, phí giám sát có thể vượt phần tiết kiệm
        ↓
    → object dưới 128 KB KHÔNG bị chuyển tầng và không tính phí giám sát,
      nhưng cũng không tiết kiệm được gì
        ↓
    → Intelligent-Tiering đáng dùng khi object đủ lớn — ảnh thì hợp

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

• C (S3 với Intelligent-Tiering, CloudFront trước bucket S3 VÀ trước ALB) — đây là phương án gần nhất và nó chỉ khác B ở đúng thành phần cuối: cùng dùng S3 Intelligent-Tiering, cùng đặt CloudFront lên trước. Nhưng nó giữ ALB và đội EC2 làm phần xử lý ảnh, tức là giữ nguyên nút thắt hiệu năng mà đề mô tả. Đặt CloudFront trước ALB có giúp giảm tải phần nội dung cache được, nhưng việc xử lý ảnh vẫn chạy trên một đội máy phải co giãn thủ công và vẫn tốn tiền 24/7. Với một ứng dụng có mô hình truy cập khó đoán và đỉnh tải, Lambda là lựa chọn vừa rẻ hơn vừa co giãn tốt hơn.

• A (Global Accelerator trước ALB, chuyển nội dung tĩnh sang FSx for Windows File Server, Lambda giảm kích cỡ ảnh trong lúc chuyển) — sai kho lưu trữ. FSx for Windows File Server là hệ thống tệp SMB cho máy Windows, đắt hơn S3 rất nhiều và hoàn toàn không phù hợp để phục vụ ảnh cho ứng dụng di động toàn cầu. Global Accelerator tối ưu đường mạng nhưng không cache, nên nó không giải quyết bài toán nội dung tĩnh như CloudFront.

• D (CloudFront với ALB đứng sau, lưu nội dung tĩnh trong S3 lớp Infrequent Access) — vấn đề nằm ở lớp lưu trữ. Standard-IA tính phí truy xuất cho mỗi lần đọc và có phí lưu trữ tối thiểu 30 ngày mỗi object. Với mô hình truy cập khó đoán như đề mô tả, một ảnh nguội bỗng được chia sẻ rộng sẽ tạo ra hàng loạt phí truy xuất — đúng thứ Intelligent-Tiering tránh được. Phương án này cũng giữ ALB làm nơi xử lý.

Ghi nhớ

⚠ Bốn lớp lưu trữ S3 hay gặp — bảng phải thuộc: | Lớp | Phí truy xuất | Hợp với | |---|---|---| | Standard | không | truy cập thường xuyên | | Intelligent-Tiering | không | mô hình truy cập KHÔNG ĐOÁN ĐƯỢC | | Standard-IA | có | ít truy cập nhưng biết chắc là ít | | Glacier Instant / Flexible / Deep Archive | có, cao dần | lưu trữ dài hạn |

Từ khoá nhận diện:

"unpredictable access patterns" → Intelligent-Tiering "global users" + nội dung tĩnh → CloudFront "control costs and improve performance" → S3 + CloudFront + serverless "Standard-IA" khi truy cập khó đoán → SAI, phí truy xuất sẽ đắt "FSx for Windows" để phục vụ ảnh web → SAI, đắt và sai giao thức

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Object đang ở tầng nào | S3 Storage Lens hoặc S3 Inventory | | Tỷ lệ trúng cache | CacheHitRate của CloudFront | | Có tiết kiệm thật không | so hoá đơn S3 trước và sau, tính cả phí giám sát |

Và một lời khuyên: hãy kiểm kích cỡ object trung bình trước khi bật Intelligent-Tiering trên toàn bộ bucket. Đây là chỗ một tối ưu chi phí biến thành một khoản chi phí mới: phí giám sát tính theo số lượng object, không theo dung lượng, nên một bucket chứa hàng chục triệu tệp nhỏ — ảnh thumbnail, tệp metadata, log vụn — có thể tốn thêm nhiều hơn phần nó tiết kiệm được. Không có cảnh báo nào cho chuyện đó; S3 vẫn hoạt động hoàn hảo, các object vẫn được chuyển tầng đúng như thiết kế, và dòng chi phí mới xuất hiện lặng lẽ dưới một mục riêng trên hoá đơn mà không ai đối chiếu với phần đã tiết kiệm.

Đáp án

A, D — hai khuyến nghị cho cấu trúc đa tài khoản có kiểm toán tập trung:

• A — Tạo tài khoản người dùng trong chính tài khoản Production và Development.
• D — Bật AWS CloudTrail và giữ toàn bộ trail cùng log trong tài khoản quản lý.

Vì sao đúng

Đề đòi kiểm toán mọi hành động API trên tất cả tài khoản. Đó là bài toán của organization trail, và nó quyết định phương án D.

⚠ Điểm mấu chốt: log kiểm toán phải nằm NGOÀI tài khoản bị kiểm toán, nếu không nó không đáng tin:

Trail và log lưu trong chính tài khoản Production
        ↓
    Người có quyền quản trị ở đó xoá hoặc sửa được log
        ↓
    → dấu vết của một hành động sai có thể bị xoá bởi chính người gây ra nó
        ↓
Organization trail ở tài khoản quản lý
        ↓
    Log gom vào một bucket tập trung, tài khoản thành viên không xoá được
        ↓
    → đây mới là kiểm toán theo đúng nghĩa

Đây là lý do phương án C sai dù nó cũng bật CloudTrail.

# Ở tài khoản quản lý — một trail phủ cả tổ chức
aws cloudtrail create-trail --name to-chuc-trail \
  --s3-bucket-name log-kiem-toan-trung-tam \
  --is-organization-trail --is-multi-region-trail

aws cloudtrail start-logging --name to-chuc-trail

Về phương án A. Đặt danh tính người dùng trong chính tài khoản họ làm việc là mô hình đơn giản và trực tiếp: quyền được cấp tại chỗ, không cần thiết lập chuỗi assume role. (Với tổ chức lớn, IAM Identity Center thường là lựa chọn tốt hơn, nhưng nó không có trong danh sách phương án.)

⚠ Bật thêm ba lớp bảo vệ cho bucket log, nếu không "tập trung" vẫn chưa đủ:

Log file validation → phát hiện log bị sửa
S3 Object Lock       → không xoá được trong thời hạn giữ
Bucket ở tài khoản riêng (Log Archive) → tách khỏi cả tài khoản quản lý
        ↓
    → đây là mô hình Control Tower dựng sẵn

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

• C (bật CloudTrail và giữ trail cùng log TRONG TỪNG tài khoản) — đây là phương án gần nhất và nó vẫn ghi lại đầy đủ mọi hành động API: về mặt dữ liệu, không thiếu gì. Nhưng nó hỏng ở đúng thuộc tính làm nên giá trị của kiểm toán — tính bất khả xâm phạm. Log nằm trong tài khoản mà nó đang giám sát, nên bất kỳ ai có quyền quản trị ở đó đều có thể dừng trail, xoá log, hoặc sửa bucket policy. Ngoài ra việc điều tra một sự cố trải qua nhiều tài khoản trở thành cơn ác mộng: phải đăng nhập từng nơi, gom log thủ công, không truy vấn chéo được. Đây là bẫy hay vì nó đúng ở phần "bật CloudTrail" và chỉ sai ở phần "để log ở đâu".

• E (tạo tài khoản người dùng trong tài khoản quản lý và dùng cross-account access để vào tài nguyên) — mô hình này chạy được và thậm chí phổ biến, nhưng nó đặt danh tính vào tài khoản quản lý — nơi đáng ra chỉ nên chứa rất ít thứ và được bảo vệ nghiêm ngặt nhất. Tài khoản quản lý không bị SCP ràng buộc, nên một danh tính bị chiếm ở đó có tác động lớn hơn hẳn. Thực hành được khuyến nghị là giữ tài khoản quản lý gần như trống.

• B (tạo mọi tài nguyên trong tài khoản quản lý rồi cấp quyền cho Production và Development) — đi ngược chính lý do tồn tại của cấu trúc đa tài khoản. Dồn mọi tài nguyên vào một chỗ là xoá bỏ ranh giới cách ly về bảo mật, về hạn mức dịch vụ và về chi phí — ba lợi ích chính của việc tách tài khoản. Và một lần nữa, đó lại là tài khoản quản lý.

Ghi nhớ

⚠ Bốn điều về CloudTrail — bảng phải thuộc: | Điều | Nội dung | |---|---| | Organization trail | một trail ở tài khoản quản lý, phủ mọi tài khoản thành viên | | Event history | 90 ngày miễn phí, có sẵn kể cả khi chưa tạo trail | | Management event | thao tác trên tài nguyên — trail đầu tiên miễn phí | | Data event | thao tác trên dữ liệu (object S3, item DynamoDB) — tính phí, phải bật riêng |

Từ khoá nhận diện:

"auditing for all API actions across accounts" → organization trail ở tài khoản quản lý "keep logs within each account" → SAI, log bị sửa được bởi chính tài khoản đó "tạo mọi tài nguyên trong management account" → LUÔN SAI, mất cách ly "user accounts in the management account" → không nên, giữ tài khoản quản lý trống cần chống sửa log → log file validation + Object Lock + tài khoản Log Archive riêng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Trail có phủ mọi tài khoản không | describe-trails, xem IsOrganizationTrail | | Có tài khoản nào thiếu log không | so danh sách tài khoản với các tiền tố trong bucket log | | Log có bị sửa không | aws cloudtrail validate-logs |

Và một lời khuyên: hãy bật log file validation và chạy validate-logs định kỳ, đừng chỉ tin rằng bucket đã được khoá đúng. Kiểm toán tồn tại để dùng vào ngày xấu nhất, và giá trị của nó phụ thuộc hoàn toàn vào việc bạn chứng minh được log chưa bị đụng tới. Một bucket policy chặt chẽ là cần thiết nhưng không phải bằng chứng — chính sách có thể đã bị đổi rồi đổi lại, và không có gì trong bản thân tệp log cho biết điều đó. Tệp digest ký số thì có: nó cho phép bạn khẳng định một cách kiểm chứng được rằng nội dung log hôm nay đúng bằng nội dung được ghi ra ngày hôm đó, và đó chính là điều một cuộc điều tra cần nghe.

Đáp án

A — Tạo AWS WAF web ACL với luật cho phép các địa chỉ IP mà các công ty đối tác dùng, gắn web ACL vào API; tạo usage plan có giới hạn request và gắn với API; tạo API key và thêm vào usage plan.

Vì sao đúng

Đề mô tả một API có tập người dùng đóng và biết trước — vài trăm công ty, mỗi công ty gọi hai lần mỗi ngày — đang bị botnet tấn công. Với mô hình đó, cách rẻ nhất là chặn ở tầng ngoài cùng và cấp danh tính cho từng khách.

⚠ Điểm mấu chốt: danh sách CHO PHÉP hợp lý ở đây vì tập người dùng đóng và biết trước:

Với API công khai cho người dùng bất kỳ
        ↓
    Allow list theo IP là không khả thi
        ↓
Với API dành cho vài trăm công ty đã biết
        ↓
    Mỗi công ty gọi từ dải IP văn phòng cố định
        ↓
    → allow list chặn được 100% lưu lượng botnet ngay ở tầng đầu

Vì sao usage plan chứ không phải resource policy (điểm phân biệt với D). Usage plan là cơ chế dựng riêng để giới hạn tần suất theo từng khách hàng: throttle rate, burst, và quota theo ngày/tuần/tháng — tất cả gắn với một API key cụ thể.

aws apigateway create-usage-plan --name khach-hang \
  --throttle rateLimit=2,burstLimit=5 \
  --quota limit=60,period=MONTH \
  --api-stages apiId=abc123,stage=prod

aws apigateway create-api-key --name cong-ty-a --enabled
aws apigateway create-usage-plan-key --usage-plan-id <id> \
  --key-id <key-id> --key-type API_KEY

⚠ API key KHÔNG phải cơ chế xác thực — nó là cơ chế nhận diện để đo và giới hạn:

API key đi trong header x-api-key, dạng chuỗi tĩnh
        ↓
    Không ký, không hết hạn tự động, lộ ra là dùng được
        ↓
    → nó dùng để BIẾT ai đang gọi và ÁP hạn mức cho họ
        ↓
    → xác thực thật phải là IAM, Cognito, hoặc Lambda authorizer

Trong bài này, lớp bảo vệ thật là WAF allow list; API key lo phần đo đếm và hạn mức.

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

• C (CloudFront trước API, WAF chặn client gọi quá mười lần mỗi ngày, thêm custom header chứa API key, API yêu cầu API key ở phương thức GET) — đây là phương án gần nhất và về mặt bảo mật nó rất chắc chắn: CloudFront hấp thụ tấn công ở tầng biên, rate-based rule chặn kẻ gọi quá nhiều, custom header ngăn đường vòng. Nhưng đề nêu thẳng "while minimizing cost", và phương án này thêm hẳn một CloudFront distribution cùng chi phí đi kèm cho một API mà mỗi khách chỉ gọi hai lần mỗi ngày — tổng lưu lượng hợp lệ rất nhỏ. Ngoài ra rate-based rule của WAF hoạt động trên cửa sổ 5 phút, không phải theo ngày, nên luật "quá mười request mỗi ngày" không diễn đạt được trực tiếp bằng WAF; giới hạn theo ngày là việc của usage plan quota.

• B (CloudFront + WAF rate-based, dùng OAI để chỉ CloudFront gọi được API) — cùng vấn đề chi phí, cộng thêm một lỗi kỹ thuật rõ ràng: OAI chỉ dùng cho origin là S3. Không có cách nào cấu hình API Gateway để "chỉ OAI mới gọi được phương thức GET". Muốn khoá API Gateway sau CloudFront thì dùng custom header bí mật hoặc resource policy, không phải OAI.

• D (WAF allow list theo IP, tạo RESOURCE POLICY có giới hạn request, yêu cầu API key ở phương thức POST) — hai lỗi. Resource policy của API Gateway kiểm soát ai được gọi API (theo IP, VPC endpoint, tài khoản AWS) — nó không có khả năng giới hạn tần suất; đó là việc của usage plan. Và đề nói khách hàng lấy dữ liệu mỗi ngày, tức là dùng GET; đặt yêu cầu API key trên POST là gắn vào phương thức không được dùng.

Ghi nhớ

⚠ Bốn lớp bảo vệ API Gateway — bảng phải thuộc: | Lớp | Việc | |---|---| | WAF | chặn theo IP, địa lý, tốc độ, mẫu tấn công | | Resource policy | ai được gọi — IP, VPC endpoint, tài khoản | | Usage plan + API key | giới hạn tần suất và quota theo từng khách | | Authorizer (IAM, Cognito, Lambda) | xác thực danh tính thật |

Từ khoá nhận diện:

"botnet" + tập khách hàng đóng → WAF allow list theo IP "limit requests per customer" → usage plan với throttle và quota "minimizing cost" → loại phương án thêm CloudFront cho API lưu lượng thấp "OAI" cho API Gateway → LUÔN SAI, OAI chỉ dùng với S3 "resource policy with a request limit" → SAI, resource policy không giới hạn tần suất

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Botnet còn gọi được không | chỉ số BlockedRequests của WAF | | Khách có vượt quota không | báo cáo usage của từng API key | | Chi phí có giảm không | so số request tính tiền trước và sau |

Và một lời khuyên: hãy yêu cầu các công ty đối tác báo trước khi họ đổi dải IP, và đặt lịch rà soát allow list định kỳ. Danh sách cho phép theo IP là lớp bảo vệ hiệu quả nhất trong bài này, nhưng nó cũng là lớp mục ruỗng nhanh nhất: một đối tác chuyển văn phòng, đổi nhà mạng, hay bắt đầu gọi API qua một cổng ra mới — và từ đó họ bị chặn hoàn toàn. Với một API mà mỗi bên chỉ gọi hai lần mỗi ngày, sự cố đó có thể không được phát hiện trong nhiều tuần: không có ai ngồi nhìn màn hình lúc nó xảy ra, phía đối tác chỉ thấy dữ liệu không về, và phía bạn thì mọi chỉ số đều bình thường vì số request bị chặn tăng thêm vài đơn vị mỗi ngày trông chẳng khác gì nhiễu từ botnet.

Đáp án

D — Tạo customer managed policy cho từng dự án, cấp toàn quyền trên tài nguyên thuộc dự án đó; gắn policy vào một IAM group; đổi thành viên group khi lập trình viên chuyển dự án; cập nhật policy khi tập tài nguyên thay đổi.

Vì sao đúng

Đề đòi giảm tối đa việc bảo trì chính sách trong hai tình huống: người chuyển dự án, và tài nguyên mới được thêm.

⚠ Điểm mấu chốt: gắn policy vào GROUP tách hai việc hay thay đổi ra khỏi nhau:

Người thay đổi thường xuyên  → quản bằng thành viên group
Tài nguyên thay đổi thường xuyên → quản bằng nội dung policy
        ↓
    Hai trục độc lập, sửa cái này không đụng cái kia
        ↓
    Gắn policy thẳng vào user → mỗi lần chuyển dự án phải gỡ và gắn lại policy
      cho từng người, và mỗi lần đổi tài nguyên phải sửa nhiều bản sao

Vì sao customer managed policy chứ không phải inline policy. Managed policy là một đối tượng độc lập, gắn được vào nhiều thực thể; sửa một lần là mọi nơi dùng nó đều đổi theo. Inline policy nhúng thẳng vào một thực thể, nên nếu ba group cùng cần một bộ quyền thì bạn có ba bản sao phải giữ đồng bộ.

aws iam create-group --group-name du-an-serverless
aws iam attach-group-policy --group-name du-an-serverless \
  --policy-arn arn:aws:iam::111122223333:policy/QuyenDuAnServerless

# chuyển người: hai lệnh, không đụng policy
aws iam remove-user-from-group --user-name lan --group-name du-an-analytics
aws iam add-user-to-group    --user-name lan --group-name du-an-serverless

⚠ Nếu tài nguyên được gắn tag nhất quán, dùng ABAC còn ít bảo trì hơn nữa:

Policy dựa trên điều kiện: aws:ResourceTag/DuAn = aws:PrincipalTag/DuAn
        ↓
    Thêm tài nguyên mới → chỉ cần gắn đúng tag, KHÔNG sửa policy
        ↓
    Chuyển người → đổi tag trên principal
        ↓
    → nhưng phải ép được chuẩn tag, và đề không nói tag có sẵn

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

• B (policy theo tag dự án, gắn vào IAM ROLE của dự án, đổi role gán cho user khi chuyển dự án, gắn tag cho tài nguyên mới) — đây là phương án gần nhất và nó thực ra là mô hình ABAC, về lý thuyết còn ít bảo trì hơn D: thêm tài nguyên mới chỉ cần gắn tag, không phải sửa policy. Nhưng nó vướng một câu sai về khái niệm: "đổi role gán cho IAM user" — role không được "gán" cho user như policy hay group. User assume role, và điều đó đòi lập trình viên phải chủ động chuyển vai mỗi lần làm việc, thay đổi hẳn quy trình hằng ngày của họ. Ngoài ra mô hình này chỉ hoạt động nếu mọi tài nguyên đều được gắn tag đúng — mà đề nói tài nguyên trong mỗi dự án thay đổi theo thời gian và không đảm bảo có chuẩn tag. Với những gì đề cho, D là lựa chọn chắc chắn hơn.

• C (customer managed policy cho từng dự án, gắn THẲNG vào IAM user khi họ chuyển dự án) — đúng về policy nhưng sai về nơi gắn. Mỗi lần chuyển dự án phải gỡ policy cũ và gắn policy mới cho từng người — nhiều thao tác hơn, dễ sót hơn (quên gỡ policy cũ là người đó có quyền ở cả hai dự án), và IAM có giới hạn số policy gắn được vào một user.

• A (IAM role cho mỗi dự án với inline policy liệt kê những user được assume) — nhiều bảo trì nhất. Danh sách user nằm bên trong trust policy, nên mỗi lần có người chuyển dự án là phải sửa policy của hai role. Inline policy cũng không dùng lại được. Đây chính là mô hình mà câu hỏi muốn bạn loại.

Ghi nhớ

⚠ Bốn nơi gắn quyền trong IAM — bảng phải thuộc: | Gắn vào | Khi nào | |---|---| | Group | nhiều người cùng một bộ quyền — dễ bảo trì nhất | | User | ngoại lệ cá nhân, hạn chế dùng | | Role | ứng dụng, dịch vụ, truy cập liên tài khoản, danh tính liên kết | | Resource policy | trên chính tài nguyên (bucket, queue, key) |

Từ khoá nhận diện:

"minimize policy maintenance" → group + managed policy "developers move between projects frequently" → đổi thành viên group "attach the policy to the IAM user" → nhiều thao tác hơn, dễ sót "đổi role gán cho user" → SAI khái niệm, role được assume chứ không gán tài nguyên có tag nhất quán → cân nhắc ABAC

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Quyền hiệu dụng của một người | aws iam simulate-principal-policy | | Ai đang ở group nào | aws iam get-group --group-name <ten> | | Có quyền thừa không | IAM Access Analyzer — xem quyền chưa dùng tới |

Và một lời khuyên: hãy rà soát định kỳ những người thuộc nhiều group cùng lúc. Đây là chỗ quyền tích luỹ âm thầm trong mô hình dựa trên group: khi một người chuyển dự án, việc thêm họ vào group mới luôn được làm ngay vì họ cần quyền để làm việc — còn việc gỡ khỏi group cũ thì không ai bị chặn nếu quên, nên nó hay bị bỏ sót. Sau vài lần luân chuyển, một lập trình viên có thể có toàn quyền trên cả ba dự án mà không ai nhận ra, vì không có màn hình nào cảnh báo rằng một người đang ở nhiều group hơn mức cần thiết. Một truy vấn liệt kê user thuộc từ hai group trở lên, chạy mỗi quý, đủ để bắt hết.

Đáp án

C — Ở mỗi tài khoản khu vực, tạo IAM role SecurityAudit và cấp quyền cho tài khoản trung tâm được assume role đó.

Vì sao đúng

Đề nói tổ chức đã dựng AWS Organizations và mời các tài khoản khu vực vào. Bước tiếp theo là tạo đường cho đội IT trung tâm nhìn được vào từng tài khoản — và cách chuẩn cho việc đó là role liên tài khoản.

⚠ Điểm mấu chốt: role liên tài khoản cho thông tin đăng nhập TẠM THỜI, thu hồi tức thì và truy vết được:

Đội trung tâm gọi sts:AssumeRole vào tài khoản khu vực
        ↓
    Nhận thông tin đăng nhập có hạn 1-12 giờ
        ↓
    Mọi thao tác ghi vào CloudTrail của TÀI KHOẢN ĐÓ, kèm role session name
        ↓
    → biết ai làm gì, và gỡ quyền chỉ cần sửa trust policy

SecurityAudit là AWS managed policy có sẵn, gồm quyền đọc cấu hình bảo mật trên toàn bộ dịch vụ — đúng thứ một đội kiểm toán cần, và AWS tự cập nhật khi có dịch vụ mới.

// Trust policy của role trong tài khoản khu vực
{
  "Effect": "Allow",
  "Principal": {"AWS": "arn:aws:iam::<tai-khoan-trung-tam>:root"},
  "Action": "sts:AssumeRole",
  "Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}}
}

⚠ Với tổ chức nhiều tài khoản, triển khai role bằng StackSets chứ đừng làm tay:

Tạo role thủ công ở từng tài khoản
        ↓
    Tài khoản mới gia nhập → ai đó phải nhớ tạo role
        ↓
    → CloudFormation StackSets triển khai role ra mọi tài khoản trong OU,
      và tự áp cho tài khoản mới

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

• A (ở mỗi tài khoản khu vực, tạo IAM policy SecurityAudit và gắn cho quản trị viên khu vực) — đây là phương án gần nhất và nó dùng đúng policy. Nhưng nó gắn quyền cho chính người ở khu vực đó, không tạo ra đường nào cho đội trung tâm. Đề nói mục tiêu là để đội IT trung tâm giám sát — phương án này chỉ cấp thêm quyền đọc cho những người vốn đã quản lý tài khoản của họ, nên không thay đổi gì về khả năng giám sát tập trung. Nó cũng đi ngược mục tiêu độc lập của kiểm toán: người bị kiểm toán không nên là người chạy báo cáo kiểm toán.

• D (tạo IAM user riêng cho đội IT trung tâm ở mỗi tài khoản, với quyền quản trị) — sai theo hai hướng. IAM user nghĩa là thông tin đăng nhập dài hạn phải phân phối, xoay vòng và bảo vệ ở hàng chục tài khoản — đúng thứ role sinh ra để thay thế. Và quyền quản trị vượt xa nhu cầu kiểm toán; đề nói giám sát và tuân thủ, không nói sửa đổi.

• B (viết Lambda ở tài khoản trung tâm để tự động áp chính sách bảo mật lên mọi tài khoản khu vực) — tự dựng lại thứ Organizations đã có. Áp chính sách tập trung là việc của SCP, còn giám sát tuân thủ là việc của Security Hub và AWS Config. Ngoài ra, Lambda ở tài khoản trung tâm vẫn cần một role ở mỗi tài khoản khu vực để làm việc — tức là nó vẫn phải dựa trên chính phương án C.

Ghi nhớ

⚠ Bốn cách quản trị bảo mật đa tài khoản — bảng phải thuộc: | Cách | Việc | |---|---| | Cross-account role | truy cập để đọc và điều tra | | SCP | áp trần quyền cho tài khoản và OU | | Security Hub | gom phát hiện bảo mật, chấm điểm theo chuẩn | | AWS Config (aggregator) | trạng thái cấu hình và tuân thủ trên nhiều tài khoản |

Từ khoá nhận diện:

"central team needs oversight of member accounts" → cross-account role "SecurityAudit" → AWS managed policy chỉ đọc, dành cho kiểm toán "tạo IAM user ở mỗi tài khoản" → SAI, dùng role "gắn policy cho quản trị viên khu vực" → không tạo đường cho đội trung tâm "Lambda tự áp chính sách" → đó là việc của SCP

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Role có assume được không | aws sts assume-role từ tài khoản trung tâm | | Ai đã dùng role | CloudTrail ở tài khoản khu vực, sự kiện AssumeRole | | Tài khoản nào còn thiếu role | so danh sách tài khoản với danh sách stack instance của StackSet |

Và một lời khuyên: hãy đặt RoleSessionName mang tên người thật khi assume role, và bắt buộc điều đó trong quy trình. Đây là chỗ dấu vết kiểm toán biến mất trong mô hình truy cập liên tài khoản: mọi thao tác của đội trung tâm sẽ xuất hiện trong CloudTrail của tài khoản khu vực dưới danh nghĩa cùng một role, nên nếu tên phiên là một chuỗi chung chung như audit-session, bạn biết được "ai đó ở đội trung tâm" đã làm gì nhưng không bao giờ biết là ai. Với một cuộc điều tra sự cố, khoảng cách giữa hai điều đó là toàn bộ giá trị của bản ghi. Điều kiện sts:RoleSessionName trong trust policy ép được chuyện này ngay từ đầu.