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

Đáp án

A — Bật managed rule access-keys-rotated của AWS Config với tham số maxAccessKeyAge = 30; cho Config áp dụng khắc phục bằng SSM Automation document cho mọi tài nguyên không tuân thủ, và document này publish thông điệp tuỳ chỉnh lên SNS topic.

Vì sao đúng

Đề hỏi cách ít công nhất (LEAST effort), và A là phương án duy nhất không cần viết một dòng mã nào:

Config managed rule access-keys-rotated  (có sẵn, chỉ bật)
    ↓ đánh giá tự động
Tài nguyên không tuân thủ
    ↓ Config remediation action
SSM Automation document  (có sẵn: AWS-PublishSNSNotification)
    ↓
SNS topic → đội bảo mật

Ba thành phần và cả ba đều có sẵn: | Thành phần | Cần viết mã? | |---|---| | Managed rule access-keys-rotated | ❌ có sẵn của AWS | | SSM Automation document | ❌ AWS-PublishSNSNotification có sẵn | | SNS topic | ❌ cấu hình thuần |

Đây là điểm phân biệt chính với phương án B, vốn dùng Lambda — tức là phải viết mã, đóng gói, tạo execution role, và bảo trì runtime về sau.

Cấu hình remediation:

aws configservice put-remediation-configurations   --remediation-configurations '[{
    "ConfigRuleName": "access-keys-rotated",
    "TargetType": "SSM_DOCUMENT",
    "TargetId": "AWS-PublishSNSNotification",
    "Automatic": true,
    "Parameters": {
      "TopicArn": {"StaticValue": {"Values": ["arn:aws:sns:...:canh-bao"]}},
      "Message": {"StaticValue": {"Values": ["Access key qua 30 ngay chua xoay vong"]}}
    }}]'

Và access-keys-rotated là managed rule có thật với tham số maxAccessKeyAge — không phải thứ bạn phải tự viết logic đánh giá.

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

• B. Bật cùng managed rule đó, nhưng khắc phục bằng AWS Lambda function rồi Lambda publish lên SNS — đây là phương án gần nhất và hoạt động hoàn toàn đúng, nhưng nó nhiều công hơn: phải viết mã, tạo execution role, quản lý phiên bản runtime. Cho một việc chỉ là gửi thông báo, SSM Automation document có sẵn làm được.
• D. Bật managed rule; tạo EventBridge rule chạy theo lịch hằng ngày kích hoạt Lambda đánh giá managed rule đó rồi publish SNS — thêm hai thành phần thừa: Config đã tự đánh giá rồi, không cần lịch riêng để "đánh giá lại". Và vẫn phải viết Lambda.
• C. Cấu hình AWS Trusted Advisor áp dụng khắc phục bằng Lambda cho mọi access key không tuân thủ — Trusted Advisor không có cơ chế remediation: nó chỉ đưa ra khuyến nghị. (Nó có kiểm tra "IAM Access Key Rotation", nhưng chỉ cảnh báo trong bảng điều khiển và không tự hành động.)

Ghi nhớ

Hai chế độ kích hoạt của Config rule: | Chế độ | Chạy khi | |---|---| | Configuration change | ngay khi tài nguyên thay đổi | | Periodic | theo lịch: 1, 3, 6, 12 hoặc 24 giờ |

access-keys-rotated là rule PERIODIC — vì "key đã bao nhiêu ngày tuổi" là thứ thay đổi theo thời gian, không theo sự kiện.

Ba cách khắc phục của AWS Config — theo mức công sức: | Cách | Công sức | Linh hoạt | |---|---|---| | SSM Automation document có sẵn | thấp nhất | vừa | | SSM Automation document tự viết | trung bình | cao | | Lambda function | cao nhất | cao nhất |

Các SSM Automation document có sẵn hay dùng cho khắc phục: | Document | Việc | |---|---| | AWS-PublishSNSNotification | gửi thông báo ← câu này | | AWS-DisableS3BucketPublicReadWrite | khoá bucket công khai | | AWS-EnableS3BucketEncryption | bật mã hoá bucket | | AWSConfigRemediation-RevokeUnusedIAMUserCredentials | thu hồi thông tin đăng nhập không dùng | | AWS-DetachIAMPolicy, AWS-EnableCloudTrail | |

Dòng thứ tư đáng chú ý cho chính bài toán này: nếu chính sách của công ty là tự động vô hiệu hoá key quá hạn chứ không chỉ cảnh báo, đã có document sẵn cho việc đó.

Ba managed rule liên quan tới IAM đáng bật: | Rule | Kiểm tra | |---|---| | access-keys-rotated | key có được xoay vòng trong N ngày không | | iam-user-mfa-enabled | người dùng có bật MFA không | | iam-root-access-key-check | root có access key không — phải KHÔNG có | | iam-password-policy | chính sách mật khẩu đủ mạnh | | iam-user-unused-credentials-check | thông tin đăng nhập lâu không dùng |

Và giải pháp gốc rễ đáng nói: việc phải xoay vòng access key định kỳ tồn tại vì có access key dài hạn. Chuyển sang IAM role (cho ứng dụng trên AWS) và IAM Identity Center (cho người dùng) loại bỏ hẳn nhu cầu này — thông tin đăng nhập tạm thời tự hết hạn sau vài giờ, không cần ai nhớ xoay vòng.

Đáp án

B — Chọn enhanced scanning và đặt filter là scan on push.

Vì sao đúng

Đề nêu hai yêu cầu, và mỗi cái quyết định một nửa đáp án: | Yêu cầu | Quyết định | |---|---| | Quét lỗ hổng cả HỆ ĐIỀU HÀNH lẫn GÓI NGÔN NGỮ LẬP TRÌNH | enhanced scanning | | Chỉ quét MỘT LẦN khi đẩy image lên | filter "scan on push" |

Vế đầu là điểm loại basic scanning: | | Basic scanning | Enhanced scanning | |---|---|---| | Nền tảng | cơ sở dữ liệu CVE nguồn mở (Clair) | Amazon Inspector | | Gói hệ điều hành | ✅ | ✅ | | Gói ngôn ngữ lập trình | ❌ KHÔNG | ✅ CÓ | | Chi phí | miễn phí | tính phí theo image |

"Programming language package vulnerabilities" nghĩa là các gói trong package.json, requirements.txt, pom.xml, go.mod — basic scanning không nhìn tới chúng, chỉ quét gói do trình quản lý gói của hệ điều hành cài (yum, apt).

Vế thứ hai phân biệt hai chế độ của enhanced scanning: | Filter | Hành vi | |---|---| | Scan on push | quét MỘT LẦN khi image được đẩy lên ← câu này | | Continuous scanning | quét lại liên tục khi có CVE mới được công bố |

Đề nói rõ "should only be scanned once when they are pushed" — nên scan on push là đúng, dù continuous scanning về mặt bảo mật thì tốt hơn.

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

• A. Chọn enhanced scanning và đặt filter là continuous scanning — đây là phương án gần nhất và là lựa chọn tốt hơn về bảo mật, nhưng nó trái yêu cầu cụ thể của đề: image sẽ được quét lại nhiều lần trong suốt vòng đời, không phải "chỉ một lần khi đẩy lên".
• C. Chọn basic scanning với filter scan on push — đúng thời điểm nhưng sai phạm vi quét: basic scanning không phát hiện lỗ hổng trong gói ngôn ngữ lập trình, mà đó là một nửa yêu cầu.
• D. Chọn enhanced scanning và đặt tần suất quét thủ công (manual) — enhanced scanning không có chế độ thủ công: nó chỉ có scan-on-push và continuous. (Chế độ quét thủ công là đặc điểm của basic scanning.)

Ghi nhớ

Hai chế độ quét của Amazon ECR — bảng phân biệt cốt lõi: | | Basic | Enhanced | |---|---|---| | Nền tảng | Clair (nguồn mở) | Amazon Inspector | | Quét gói HĐH | ✅ | ✅ | | Quét gói ngôn ngữ lập trình | ❌ | ✅ | | Chế độ | scan on push, thủ công | scan on push, continuous | | Finding gửi tới Security Hub | ❌ | ✅ | | Chi phí | miễn phí | tính phí |

Cột "quét gói ngôn ngữ" là điểm phân biệt được hỏi nhiều nhất — và nó quan trọng thật: phần lớn lỗ hổng trong ứng dụng hiện đại nằm ở thư viện npm, PyPI, Maven chứ không phải ở gói hệ điều hành.

Ba tuỳ chọn thời lượng của continuous scanning: | Tuỳ chọn | Ý nghĩa | |---|---| | Lifetime (mặc định) | quét lại mãi, suốt vòng đời image | | Days: 30, Days: 180 | ngừng quét lại sau N ngày kể từ lần đẩy cuối |

Tuỳ chọn giới hạn ngày là cách kiểm soát chi phí: image cũ không còn triển khai thì không cần quét lại mỗi khi có CVE mới.

Ba nguồn lỗ hổng mà enhanced scanning phát hiện: | Nguồn | Ví dụ | |---|---| | Gói hệ điều hành | openssl, glibc | | Gói ngôn ngữ | npm, PyPI, Maven, Go module, NuGet, Ruby gem | | Cấu hình (với Inspector đầy đủ) | quyền quá rộng, cổng mở |

Ba thực hành bảo mật cho container image: | Thực hành | Lợi ích | |---|---| | Dùng base image tối giản | ít gói = ít lỗ hổng; distroless, Alpine, Amazon Linux minimal | | Bật scan on push + chặn deploy nếu có CRITICAL | ngăn ở cổng vào | | Bật continuous scanning cho image đang chạy | CVE mới xuất hiện sau khi image đã deploy |

Dòng cuối là lý do continuous scanning tồn tại: một image sạch hôm nay có thể có lỗ hổng nghiêm trọng vào tuần sau khi CVE mới được công bố — và không có gì thay đổi trong chính image đó.

Và một cấu hình đáng bật kèm: ECR image tag immutability. Nó ngăn việc đẩy đè lên một tag đã có, nên image đã được quét và duyệt không thể bị thay bằng nội dung khác dưới cùng tên — một lỗ hổng chuỗi cung ứng mà việc quét không bắt được.

Đáp án

A và C.

• C — Tạo IAM role cho CI/CD pipeline để triển khai tài nguyên ứng dụng
• A — Đội bảo mật tạo permissions boundary policy và gắn nó vào IAM role mà pipeline dùng

Vì sao đúng

Đề mô tả một bài toán uỷ quyền cổ điển: cho đội phát triển tự tạo IAM principal và policy, nhưng đảm bảo mọi thứ họ tạo đều nằm trong giới hạn bảo mật.

Permissions boundary là công cụ được thiết kế đúng cho việc này:

Đội bảo mật đặt permissions boundary (TRẦN quyền)
    ↓
Pipeline tạo IAM role mới cho ứng dụng
    ↓ role mới BẮT BUỘC phải gắn boundary đó
Quyền THỰC TẾ = giao của (policy được gắn) ∩ (permissions boundary)
    → dù đội phát triển viết policy rộng đến đâu,
      boundary vẫn cắt xuống mức đội bảo mật cho phép

Vế "ai tạo boundary" trong phương án A là điểm phân biệt với E: | | A (đúng) | E (sai) | |---|---|---| | Ai tạo boundary | đội BẢO MẬT | đội PHÁT TRIỂN | | Hệ quả | đội phát triển không nới được trần | đội phát triển tự nới trần → boundary vô nghĩa |

Đây không phải chuyện hình thức: nếu đội phát triển kiểm soát boundary, họ sửa nó bất cứ lúc nào và cơ chế kiểm soát biến mất.

Cấu hình đầy đủ cần thêm một statement bắt buộc gắn boundary:

{
  "Effect": "Deny",
  "Action": ["iam:CreateRole", "iam:CreateUser"],
  "Resource": "*",
  "Condition": {
    "StringNotEquals": {
      "iam:PermissionsBoundary":
        "arn:aws:iam::123456789012:policy/RanhGioiQuyenUngDung"
    }
  }
}

Không có statement này, pipeline tạo role KHÔNG gắn boundary — và role đó có toàn quyền mà policy của pipeline cho phép.

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

• E. Đội PHÁT TRIỂN tạo permissions boundary policy và gắn vào IAM role của pipeline — đây là phương án gần nhất và sai ở chủ thể: bên bị kiểm soát không thể tự đặt giới hạn cho mình. Đội phát triển sẽ sửa hoặc gỡ boundary khi nó cản trở họ.
• B. Tạo IAM role cho pipeline; đồng thời tạo resource-based policy cho MỌI tài nguyên mà pipeline tạo ra — không mở rộng được: pipeline tạo đủ loại tài nguyên, và nhiều tài nguyên AWS không hỗ trợ resource-based policy. Và phải viết một policy cho mỗi tài nguyên — trái mục tiêu giảm nút thắt.
• D. Tạo SCP và gắn vào mọi tài khoản thành viên để giám sát và kiểm soát quyền của các IAM role — SCP là công cụ hữu ích nhưng ở sai mức phân giải: nó áp cho toàn bộ tài khoản, nên nó không phân biệt được "role do pipeline tạo" với "role do quản trị viên tạo". (SCP bổ sung tốt cho boundary — nó chặn ở mức tài khoản, boundary chặn ở mức từng entity.)

Ghi nhớ

Permissions boundary — cách hoạt động:

Quyền hiệu lực = (identity-based policy) ∩ (permissions boundary)

Boundary KHÔNG CẤP quyền — nó chỉ giới hạn. Một entity chỉ có boundary mà không có policy nào thì không làm được gì.

Năm loại policy và vai trò — bảng nền tảng: | Loại | Vai trò | |---|---| | Identity-based | CẤP quyền cho user, group, role | | Resource-based | CẤP quyền trên tài nguyên | | SCP | TRẦN cho tài khoản/OU | | Permissions boundary | TRẦN cho MỘT entity ← câu này | | Session policy | giới hạn một phiên |

Ba loại "trần" đều không cấp quyền — chúng chỉ cắt bớt.

SCP và permissions boundary — phân biệt: | | SCP | Permissions boundary | |---|---|---| | Phạm vi | toàn tài khoản hoặc OU | một IAM user hoặc role | | Quản lý ở | tài khoản quản lý Organizations | tài khoản đó | | Áp cho root của tài khoản thành viên | ✅ CÓ | ❌ | | Dùng cho | rào chắn toàn tổ chức | uỷ quyền có kiểm soát ← câu này |

Dòng cuối là tiêu chí chọn: khi bạn muốn cho phép người khác tạo IAM entity mà vẫn giữ trần, đó là bài toán của permissions boundary.

Ba thành phần của mô hình uỷ quyền an toàn: | Thành phần | Ai kiểm soát | |---|---| | Permissions boundary policy | đội bảo mật | | Điều kiện iam:PermissionsBoundary bắt buộc | đội bảo mật | | Deny sửa/xoá boundary | đội bảo mật | | Policy nội dung cho role ứng dụng | đội phát triển |

Ba dòng đầu phải nằm trong tay đội bảo mật — thiếu bất kỳ cái nào là cơ chế bị vô hiệu hoá. Đặc biệt dòng thứ ba: nếu pipeline có iam:DeleteRolePermissionsBoundary, nó gỡ được trần của chính role nó vừa tạo.

Và một điểm về CI/CD nói riêng: đề nói "all teams are only allowed to modify the production environment through their CI/CD pipeline". Đó là ràng buộc quan trọng — nó nên được thực thi bằng SCP chặn mọi thao tác thay đổi từ principal không phải pipeline role, chứ không chỉ bằng quy ước. Nếu người ta vẫn vào Console sửa tay được, mọi kiểm soát ở tầng pipeline đều có đường vòng.

Đáp án

C — Bật enhanced scanning cho ECR registry. Mặc định thời lượng quét là Lifetime. Khi enhanced scanning bật, ECR gửi scan event sang EventBridge, từ đó cấu hình thông báo tới các đội liên quan.

Vì sao đúng

Đề nêu ba yêu cầu, và enhanced scanning với continuous mode thoả cả ba: | Yêu cầu | Cơ chế | |---|---| | Quét lỗ hổng HĐH và gói ngôn ngữ lập trình | enhanced scanning (Amazon Inspector) | | Mọi image được quét LIÊN TỤC | continuous scanning, thời lượng Lifetime | | Thông báo kết quả cho đội liên quan | ECR → EventBridge → SNS |

Vế "continuously scanned" là điểm phân biệt với câu #7725 — nơi yêu cầu là quét đúng một lần:

Scan on push:    quét khi đẩy lên, rồi thôi
Continuous:      quét lại MỖI KHI có CVE mới được công bố
                 → image sạch hôm nay có thể thành có lỗ hổng tuần sau

Đây là giá trị thật của continuous scanning: không có gì thay đổi trong image, nhưng thế giới bên ngoài thay đổi — một CVE mới được công bố cho thư viện mà image đang dùng.

Và Lifetime là giá trị mặc định của thời lượng quét lại — image được theo dõi suốt vòng đời trong registry.

Luồng thông báo:

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

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

• A. Bật basic scanning cho registry, cấu hình repository quét khi đẩy lên; ECR gửi sự kiện sang EventBridge để thông báo — đây là phương án gần nhất và cơ chế thông báo hoàn toàn đúng, nhưng nó sai ở hai yêu cầu: basic scanning không quét gói ngôn ngữ lập trình, và scan on push không phải quét liên tục.
• B. Bật GuardDuty advanced findings để kiểm tra lỗ hổng của ECR registry; dùng tích hợp GuardDuty với Security Hub để thông báo — sai dịch vụ: GuardDuty phát hiện mối đe doạ đang diễn ra, không quét lỗ hổng phần mềm. (GuardDuty có tính năng Malware Protection quét mã độc trong container, nhưng đó là phát hiện phần mềm độc hại, không phải quét CVE.)
• D. Bật Trusted Advisor cho ECR registry; Trusted Advisor publish metric lên CloudWatch, tạo alarm để nhận thông báo — Trusted Advisor không quét container image. Nó đưa ra khuyến nghị về chi phí, hiệu năng, giới hạn dịch vụ và một số kiểm tra bảo mật cơ bản.

Ghi nhớ

Hai chế độ filter của enhanced scanning: | Filter | Quét khi | |---|---| | Scan on push | một lần, lúc đẩy image lên | | Continuous scanning | lúc đẩy lên VÀ mỗi khi có CVE mới ← câu này |

Ba tuỳ chọn thời lượng cho continuous scanning: | Tuỳ chọn | Ngừng quét lại sau | |---|---| | Lifetime (mặc định) | không bao giờ ngừng | | Days: 180 | 180 ngày kể từ lần đẩy cuối | | Days: 30 | 30 ngày |

Hai tuỳ chọn cuối là cách kiểm soát chi phí cho registry có nhiều image cũ không còn triển khai.

Ba dịch vụ AWS liên quan tới bảo mật container — phân biệt vai trò: | Dịch vụ | Việc | |---|---| | ECR enhanced scanning (Inspector) | quét LỖ HỔNG trong image | | GuardDuty Malware Protection | phát hiện MÃ ĐỘC | | GuardDuty EKS/ECS Runtime Monitoring | hành vi bất thường KHI ĐANG CHẠY | | Security Hub | tổng hợp finding từ cả ba |

Ba dòng đầu bổ sung nhau, không thay thế nhau: image có thể không có CVE nào mà vẫn chứa mã độc; và một container sạch lúc khởi động vẫn có thể bị khai thác khi chạy.

Bốn bước của một quy trình bảo mật container đầy đủ:

① Xây dựng  → quét image trong CI, chặn nếu có CRITICAL
② Lưu trữ   → enhanced scanning liên tục trên ECR  ← câu này
③ Triển khai→ chỉ cho phép image đã ký và đã duyệt
④ Chạy      → GuardDuty Runtime Monitoring

Bước ③ đáng nói thêm: ECR image signing (qua AWS Signer và Notation) cho phép xác minh image chưa bị sửa đổi giữa lúc quét và lúc triển khai — bịt một lỗ hổng chuỗi cung ứng mà việc quét không bắt được.

Và một chi tiết vận hành về việc bật enhanced scanning: nó là cài đặt ở mức REGISTRY, không phải mức repository — bật một lần áp cho toàn bộ Region. Bạn dùng filter theo repository để giới hạn phạm vi nếu không muốn quét mọi thứ:

aws ecr put-registry-scanning-configuration   --scan-type ENHANCED   --rules '[{"scanFrequency":"CONTINUOUS_SCAN",
             "repositoryFilters":[{"filter":"prod-*","filterType":"WILDCARD"}]}]'

Đáp án

B — Cho Security Hub thu nhận finding của GuardDuty và gửi sự kiện sang Kinesis Data Streams qua EventBridge; cấu hình một Lambda function xử lý luồng dữ liệu và chặn lưu lượng đi và đến instance đáng ngờ bằng cách cập nhật security group để nó không còn rule inbound và outbound nào.

Vì sao đúng

Đề yêu cầu tự động chặn instance đáng ngờ khi GuardDuty phát hiện tấn công brute force RDP.

Điểm mấu chốt: security group không còn rule nào thì chặn HẾT.

Security group hoạt động theo nguyên tắc:
  - CHỈ có rule Allow, KHÔNG có rule Deny
  - Không có rule khớp = từ chối ngầm định

→ Security group RỖNG = chặn mọi lưu lượng vào VÀ ra

Vì sao đây là cách cách ly đúng, so với phương án D dùng NACL: | | Security group (B) | Network ACL (D) | |---|---|---| | Phạm vi | CHỈ instance đó | TOÀN BỘ subnet | | Hệ quả | cách ly đúng máy cần cách ly | ảnh hưởng mọi instance cùng subnet | | Cần rule Deny? | không — rỗng là đủ | có — phải viết rule deny tường minh |

Đây là lý do thật khiến D sai: chặn ở NACL sẽ cắt luôn các instance vô can trong cùng subnet.

Và vì sao Lambda chứ không phải Kinesis Data Analytics (phương án A): Kinesis Data Analytics chạy truy vấn SQL trên luồng dữ liệu — nó phân tích, không gọi được API AWS để sửa security group. Chỉ Lambda làm được việc đó.

Mã khắc phục:

import boto3
ec2 = boto3.client('ec2')

def cach_ly(instance_id, sg_cach_ly):
    # Gắn security group cách ly (rỗng) thay cho security group hiện tại
    ec2.modify_instance_attribute(
        InstanceId=instance_id, Groups=[sg_cach_ly])

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

• D. Security Hub thu nhận finding, gửi sang EventBridge kích hoạt Lambda chặn lưu lượng bằng cách cập nhật rule của network ACL — đây là phương án gần nhất và kiến trúc gọn hơn (không có Kinesis thừa), nhưng nó chặn nhầm phạm vi: NACL áp cho cả subnet, nên nó cách ly luôn những instance không liên quan.
• C. ... Lambda chặn lưu lượng bằng cách cập nhật WAF web ACL — sai tầng và sai đối tượng: WAF lọc request HTTP tới CloudFront, ALB, API Gateway. Nó không kiểm soát được lưu lượng RDP tới một EC2 instance.
• A. ... cấu hình Kinesis Data Analytics xử lý luồng dữ liệu và chặn lưu lượng bằng cách cập nhật security group — Kinesis Data Analytics không gọi API AWS được: nó chạy SQL hoặc Apache Flink trên luồng dữ liệu để phân tích và biến đổi, rồi ghi kết quả ra đích. Nó không thực hiện hành động khắc phục.

Ghi nhớ

Vì sao security group rỗng chặn được mọi thứ: | Đặc điểm | Hệ quả | |---|---| | CHỈ có rule Allow | không có cách nào viết Deny | | Không khớp rule nào = từ chối | rỗng = chặn hết | | Có trạng thái (stateful) | phản hồi tự động được phép |

So sánh với NACL — bảng nền tảng: | | Security group | Network ACL | |---|---|---| | Mức | ENI/instance | subnet | | Trạng thái | stateful | stateless | | Rule | chỉ Allow | Allow và Deny | | Mặc định | chặn inbound, cho outbound | cho phép hết (mặc định VPC) | | Dùng để cách ly một máy | ✅ | ❌ ảnh hưởng cả subnet |

Ba mức phản ứng khi GuardDuty phát hiện instance bị xâm nhập: | Mức | Hành động | |---|---| | Thông báo | SNS tới đội bảo mật | | Cách ly | gắn security group cách ly ← câu này | | Điều tra | snapshot EBS, chụp RAM, rà CloudTrail |

Thứ tự đúng: cách ly TRƯỚC, KHÔNG tắt máy — tắt máy làm mất bằng chứng trong RAM (xem câu #7703).

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

Bước Kinesis Data Streams trong đáp án là thừa. Kiến trúc đúng và đơn giản hơn là:

GuardDuty → EventBridge → Lambda

EventBridge gọi Lambda trực tiếp được; chèn Kinesis vào giữa chỉ thêm một dịch vụ phải cấu hình, thêm chi phí, và thêm chỗ hỏng. Kinesis Data Streams có ý nghĩa khi bạn cần đệm khối lượng rất lớn, phát lại (replay) sự kiện, hoặc nhiều consumer độc lập cùng đọc — không có nhu cầu nào trong số đó ở đây.

B vẫn là đáp án đúng trong bốn phương án vì nó là cái duy nhất kết hợp đúng công cụ hành động (Lambda) với đúng phạm vi chặn (security group). Nhưng đừng coi luồng có Kinesis là mẫu kiến trúc để học theo.

Một cải thiện quan trọng cho thực tế: đừng XOÁ RULE của security group đang dùng — hãy GẮN một security group cách ly riêng. Security group thường được chia sẻ giữa nhiều instance; xoá sạch rule của nó sẽ ngắt mạng toàn bộ nhóm máy chứ không chỉ máy bị nghi ngờ. Cách an toàn là tạo sẵn một security group rỗng tên sg-cach-ly và dùng modify-instance-attribute để thay thế trên đúng instance đó — đúng như đoạn mã ở trên.

Và nhớ gỡ luôn instance profile hoặc thu hồi phiên STS: instance bị xâm nhập có IAM role, và kẻ tấn công dùng được role đó để chạm tới tài nguyên AWS khác — cách ly mạng không chặn được đường đó.

Đáp án

B — Dùng geographic restrictions (geo restriction) của CloudFront để từ chối lưu lượng từ một số quốc gia.

Vì sao đúng

Đề nêu hai yêu cầu: chặn lưu lượng từ một số quốc gia và giữ chi phí hạ tầng thấp.

Geo restriction là tính năng sẵn có của CloudFront và KHÔNG TỐN THÊM PHÍ:

Người dùng gửi request
    ↓ CloudFront xác định quốc gia từ IP (cơ sở dữ liệu GeoIP)
    ├─ quốc gia nằm trong danh sách chặn → trả 403, KHÔNG chuyển tới origin
    └─ ngược lại → phục vụ bình thường

So sánh chi phí với phương án C (WAF geo match): | | CloudFront geo restriction | AWS WAF geo match | |---|---|---| | Chi phí | MIỄN PHÍ | ~5 USD/tháng mỗi Web ACL + 1 USD/rule + phí theo request | | Cấu hình | vài cú nhấp trên distribution | tạo Web ACL, rule, gắn vào distribution | | Linh hoạt | chỉ chặn/cho phép theo quốc gia | kết hợp được nhiều điều kiện |

Đề nhấn mạnh "maintaining the cost-effectiveness" — và khi yêu cầu chỉ đơn thuần là chặn theo quốc gia, tính năng miễn phí đáp ứng đủ.

Cấu hình:

aws cloudfront update-distribution --id E1ABCDEF   --distribution-config '{
    "Restrictions": {
      "GeoRestriction": {
        "RestrictionType": "blacklist",
        "Quantity": 2,
        "Items": ["CN", "RU"]
      }}}'

Hai chế độ: | RestrictionType | Hành vi | |---|---| | blacklist | chặn các quốc gia liệt kê ← câu này | | whitelist | chỉ cho phép các quốc gia liệt kê |

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

• C. Dùng AWS WAF web ACL với geo match condition để từ chối lưu lượng, gắn Web ACL vào CloudFront distribution — đây là phương án gần nhất và hoạt động hoàn toàn đúng, nhưng nó tốn thêm chi phí cho một việc mà CloudFront làm được miễn phí. (WAF là lựa chọn đúng khi bạn cần NGOẠI LỆ — ví dụ chặn một nước nhưng cho phép vài IP trong nước đó; xem câu #7756.)
• A. Dùng geolocation routing policy trong CloudFront — nhầm dịch vụ: geolocation routing là chính sách định tuyến của Route 53 (DNS), không phải tính năng của CloudFront. Và nó định tuyến người dùng tới endpoint khác nhau, không chặn họ.
• D. Dùng WAF web ACL với IP match condition để từ chối lưu lượng từ một số quốc gia — sai công cụ cho mục tiêu: IP set liệt kê địa chỉ IP cụ thể. Để chặn theo quốc gia bằng cách này, bạn phải tự duy trì toàn bộ dải IP của quốc gia đó — hàng nghìn dải, thay đổi liên tục.

Ghi nhớ

Ba cách chặn theo địa lý trên AWS — chọn theo nhu cầu: | Cách | Chi phí | Linh hoạt | |---|---|---| | CloudFront geo restriction | miễn phí | chỉ chặn/cho phép theo nước ← câu này | | WAF geo match statement | tính phí | kết hợp với điều kiện khác, có ngoại lệ | | Route 53 geolocation routing | tính phí DNS | định tuyến, KHÔNG chặn |

Tiêu chí chọn giữa hai dòng đầu:

Chặn thuần theo quốc gia, không ngoại lệ → geo restriction (miễn phí) Cần ngoại lệ, hoặc kết hợp với quy tắc khác → WAF geo match

Ba giới hạn của geo restriction cần biết: | Giới hạn | Chi tiết | |---|---| | Chỉ áp cho toàn bộ distribution | không đặt riêng theo đường dẫn hay cache behavior | | Không có ngoại lệ | không cho phép một IP cụ thể trong nước bị chặn | | Dựa trên cơ sở dữ liệu GeoIP | VPN và proxy vượt qua được |

Dòng cuối đáng nói thẳng: chặn theo địa lý không phải biện pháp bảo mật mạnh — bất kỳ ai dùng VPN đều đi vòng được. Nó phù hợp cho tuân thủ quy định (như đề mô tả) và giảm nhiễu, không phải để ngăn kẻ tấn công có chủ đích.

Ba thứ CloudFront trả về khi chặn: | Tình huống | Phản hồi | |---|---| | Geo restriction chặn | 403 Forbidden | | WAF chặn | 403 (tuỳ chỉnh được nội dung) | | Signed URL hết hạn | 403 |

Tuỳ chỉnh trang lỗi 403 đáng làm cho trải nghiệm người dùng: CustomErrorResponses trên distribution cho phép trả về một trang giải thích thay vì thông báo mặc định.

Và một lưu ý về kiến trúc: nếu ứng dụng cũng truy cập được trực tiếp qua ALB hoặc S3 ngoài CloudFront, geo restriction không có tác dụng cho đường đó. Phải đảm bảo origin chỉ nhận lưu lượng từ CloudFront — dùng OAC cho S3 (xem câu #7686) hoặc custom header bí mật kiểm tra ở ALB — nếu không thì hạn chế địa lý chỉ là hình thức.

Đáp án

B — Tạo một cache policy, rồi liên kết cache policy đó với cache behavior cần chuyển tiếp header Authorization.

Vì sao đúng

Đề yêu cầu chuyển tiếp header Authorization tới origin, và CloudFront xử lý header này khác với mọi header khác.

Quy tắc riêng cho Authorization:

Header thông thường:
  → thêm vào ORIGIN REQUEST POLICY để chuyển tiếp

Header Authorization:
  → phải thêm vào CACHE KEY qua CACHE POLICY
  → chỉ khi đó CloudFront mới chuyển tiếp nó tới origin

Lý do nằm ở bản chất của cache: Authorization phân biệt người dùng. Nếu CloudFront chuyển tiếp nó mà không đưa vào cache key, hai người dùng khác nhau sẽ nhận cùng một phản hồi đã cache — rò rỉ dữ liệu giữa các tài khoản. Nên CloudFront bắt buộc: muốn chuyển tiếp Authorization thì phải cache theo nó.

Cấu hình:

aws cloudfront create-cache-policy --cache-policy-config '{
  "Name": "chuyen-tiep-authorization",
  "DefaultTTL": 0,
  "ParametersInCacheKeyAndForwardedToOrigin": {
    "HeadersConfig": {
      "HeaderBehavior": "whitelist",
      "Headers": {"Quantity": 1, "Items": ["Authorization"]}
    },
    "CookiesConfig": {"CookieBehavior": "none"},
    "QueryStringsConfig": {"QueryStringBehavior": "none"},
    "EnableAcceptEncodingGzip": true
  }}'

Hệ quả cần biết: đưa Authorization vào cache key nghĩa là mỗi giá trị token là một mục cache riêng. Với token duy nhất cho mỗi người dùng, tỷ lệ trúng cache gần bằng không — nên thường đặt DefaultTTL: 0 cho các cache behavior này.

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

• A. Cấu hình origin request policy để chuyển tiếp header Authorization tới origin — đây là phương án gần nhất và là cách đúng cho MỌI header khác, nhưng Authorization là ngoại lệ được ghi rõ trong tài liệu CloudFront: nó phải đi qua cache policy.
• C. Cấu hình viewer request policy để chuyển tiếp header — không tồn tại khái niệm này: CloudFront có cache policy, origin request policy và response headers policy. Không có "viewer request policy". (Có viewer request là một sự kiện của CloudFront Functions và Lambda@Edge, nhưng đó là chỗ chạy mã, không phải một loại policy.)
• D. Với origin là S3, cache theo header Authorization chỉ được hỗ trợ khi phản hồi OPTIONS được cache; nên chọn tuỳ chọn bật cache cho phản hồi OPTIONS — đây là một câu trong tài liệu AWS nhưng bị đặt sai ngữ cảnh: nó nói về CORS preflight với origin S3, không phải cách chuyển tiếp Authorization nói chung. Đề không nêu origin là S3 và không nói gì tới CORS.

Ghi nhớ

Ba loại policy của CloudFront — bảng cần thuộc: | Policy | Quyết định | |---|---| | Cache policy | cái gì nằm trong CACHE KEY + TTL | | Origin request policy | cái gì được CHUYỂN TIẾP tới origin (không vào cache key) | | Response headers policy | header nào CloudFront thêm vào phản hồi trả về |

Khác biệt cốt lõi giữa hai cái đầu:

Trong cache policy      → vừa chuyển tiếp, VỪA phân biệt bản cache
Trong origin request policy → CHỈ chuyển tiếp, không ảnh hưởng cache key

Nguyên tắc thiết kế: đưa vào cache key càng ít càng tốt — mỗi giá trị khác nhau tạo một mục cache riêng, làm giảm tỷ lệ trúng cache. Header không ảnh hưởng tới nội dung phản hồi thì đặt ở origin request policy.

Các header đặc biệt mà CloudFront xử lý riêng: | Header | Hành vi | |---|---| | Authorization | phải qua cache policy mới chuyển tiếp ← câu này | | Host | với custom origin, CloudFront đặt thành tên miền origin | | Accept-Encoding | dùng tuỳ chọn EnableAcceptEncodingGzip/Brotli thay vì liệt kê tay | | Connection, Expect, Proxy-* | CloudFront không chuyển tiếp |

Các managed policy có sẵn hay dùng: | Policy | Việc | |---|---| | Managed-CachingOptimized | cache tối đa, không đưa header/cookie vào key | | Managed-CachingDisabled | TTL = 0, cho nội dung động | | Managed-AllViewer (origin request) | chuyển tiếp mọi header, cookie, query string | | Managed-AllViewerExceptHostHeader | như trên, giữ Host gốc |

Managed-CachingDisabled + Managed-AllViewer là cặp thường dùng cho API động — nhưng lưu ý: Managed-AllViewer vẫn không giải quyết được Authorization nếu bạn cần nó vào cache key.

Và một lựa chọn kiến trúc đáng cân nhắc: nếu nội dung hoàn toàn động và phụ thuộc người dùng, việc đặt CloudFront trước nó chủ yếu để lấy kết nối tới edge, tích hợp WAF và chống DDoS, chứ không phải để cache. Khi đó dùng CachingDisabled và chấp nhận không có lợi ích cache là thiết kế đúng — cố ép cache theo Authorization chỉ tạo ra hàng loạt mục cache dùng đúng một lần.

Đáp án

B — Dùng AWS Organizations đặt một Service Control Policy (SCP) từ chối các hành động kms:Delete* và kms:ScheduleKeyDeletion cho mọi tài khoản trong tổ chức.

Vì sao đúng

Đề yêu cầu: không tài khoản nào trong tổ chức được xoá KMS key, và đòi giải pháp hiệu quả nhất về vận hành.

SCP là công cụ duy nhất trong bốn phương án thực sự NGĂN CHẶN được:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "CamXoaKMSKey",
    "Effect": "Deny",
    "Action": ["kms:Delete*", "kms:ScheduleKeyDeletion"],
    "Resource": "*"
  }]
}

Bốn lý do SCP là lựa chọn đúng: | Lý do | Chi tiết | |---|---| | Cấu hình MỘT LẦN ở gốc tổ chức | áp cho mọi tài khoản hiện tại và tương lai | | NGĂN CHẶN, không phải phát hiện sau | thao tác bị từ chối ngay | | Áp cho CẢ root user của tài khoản thành viên | không ai trong tài khoản đó vượt qua được | | Không cần bảo trì gì | không có mã, không có lịch chạy |

Dòng thứ ba là điểm mạnh riêng của SCP: quản trị viên của tài khoản thành viên không sửa được SCP — chỉ tài khoản quản lý mới làm được. Đây là rào chắn thật, khác với IAM policy vốn có thể bị chính admin của tài khoản đó gỡ.

Và vì xoá KMS key là hành động không thể đảo ngược — mất khoá nghĩa là mất vĩnh viễn mọi dữ liệu mã hoá bằng nó — thì ngăn chặn đúng đắn hơn nhiều so với phát hiện và khắc phục sau.

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

• A. Dùng AWS Config đặt rule gửi cảnh báo khi có lời gọi kms:Delete* và kms:ScheduleKeyDeletion, và tự động khắc phục — đây là phương án gần nhất và là cơ chế phát hiện hợp lệ, nhưng nó phản ứng SAU KHI hành động đã xảy ra. Với ScheduleKeyDeletion thì còn cứu được (huỷ lịch xoá trong thời gian chờ), nhưng đây vẫn là chữa cháy chứ không phải phòng ngừa. (Và Config đánh giá cấu hình tài nguyên, không theo dõi lời gọi API — vai trò đó thuộc về CloudTrail.)
• C. Dùng AWS Organizations đặt permissions boundary từ chối các hành động đó cho mọi tài khoản trong tổ chức — nhầm loại policy: permissions boundary được gắn cho một IAM user hoặc role cụ thể, không đặt qua Organizations và không áp cho cả tài khoản.
• D. Dùng Amazon Inspector giám sát các lời gọi API đó và ngăn chặn trước — sai dịch vụ: Inspector quét lỗ hổng bảo mật cho EC2, container và Lambda. Nó không giám sát lời gọi API và không ngăn chặn được hành động nào.

Ghi nhớ

Ba loại "trần quyền" — phân biệt phạm vi: | Loại | Phạm vi | Đặt ở đâu | |---|---|---| | SCP | toàn bộ tài khoản hoặc OU | AWS Organizations | | Permissions boundary | một IAM user hoặc role | IAM của tài khoản đó | | Session policy | một phiên assume role | truyền khi gọi AssumeRole |

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

Dòng thứ hai là hạn chế cần nhớ: nếu tài nguyên quan trọng nằm trong tài khoản quản lý, SCP không bảo vệ chúng. Thực hành khuyến nghị là không đặt workload nào trong tài khoản quản lý.

Ba hành động KMS đáng chặn bằng SCP: | Hành động | Hậu quả nếu thực hiện | |---|---| | kms:ScheduleKeyDeletion | xoá khoá sau 7–30 ngày — mất dữ liệu | | kms:DisableKey | khoá ngừng hoạt động ngay — mọi thao tác thất bại | | kms:DeleteImportedKeyMaterial | vô hiệu hoá TỨC THÌ khoá dùng key material nhập khẩu | | kms:PutKeyPolicy | có thể tự khoá mình ra khỏi khoá |

Dòng thứ hai đáng thêm vào SCP: DisableKey không phá huỷ gì nhưng gây gián đoạn ngay lập tức, và nó không nằm trong mẫu kms:Delete*.

Một cách viết SCP chặt hơn — cho phép ngoại lệ có kiểm soát:

{"Effect": "Deny",
 "Action": ["kms:ScheduleKeyDeletion", "kms:DisableKey"],
 "Resource": "*",
 "Condition": {
   "ArnNotLike": {"aws:PrincipalArn": "arn:aws:iam::*:role/QuanTriKhoaKhanCap"}
 }}

Cách này chặn mọi người trừ một role được chỉ định — hữu ích khi vẫn cần khả năng xoá khoá trong trường hợp hợp lệ (khoá thử nghiệm, dọn dẹp môi trường cũ), mà không mở cho tất cả.

Và một biện pháp bổ sung nên có song song: giám sát ScheduleKeyDeletion qua EventBridge. Nếu SCP có ngoại lệ, bạn muốn biết ngay khi ngoại lệ đó được dùng — và thời gian chờ 7–30 ngày cho bạn đủ thời gian huỷ nếu đó là thao tác nhầm hoặc độc hại.

Đáp án

B và E.

• E — Tạo Service Control Policy (SCP) từ chối mọi request không dùng SSL/TLS và ngăn tài khoản tự rời khỏi tổ chức; áp SCP vào gốc (root) của tổ chức
• B — Đội ứng dụng tạo IAM role trong Account A1 để ứng dụng trên EC2 dùng khi lấy object từ bucket ở Account A2; gắn resource-based policy vào bucket ở Account A2 cấp quyền ĐỌC cho role đó

Vì sao đúng

Đề nêu hai yêu cầu tách biệt, và mỗi đáp án giải quyết một cái.

E — yêu cầu (a): mã hoá khi truyền + không rời tổ chức

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "BatBuocTLS",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {"Bool": {"aws:SecureTransport": "false"}}
    },
    {
      "Sid": "CamRoiToChuc",
      "Effect": "Deny",
      "Action": "organizations:LeaveOrganization",
      "Resource": "*"
    }
  ]
}

Vì sao SCP chứ không phải permissions boundary (phương án A): | | SCP | Permissions boundary | |---|---|---| | Phạm vi | toàn bộ tài khoản/OU | một IAM entity | | Gắn vào gốc tổ chức được? | ✅ | ❌ không có khái niệm này | | Áp cho root user tài khoản thành viên | ✅ | ❌ |

Phương án A nói "áp permissions boundary vào gốc của tổ chức" — điều không tồn tại.

B — yêu cầu (b): đặc quyền tối thiểu cho truy cập chéo tài khoản

// Bucket policy ở Account A2 (Data Lake)
{
  "Effect": "Allow",
  "Principal": {"AWS": "arn:aws:iam::A1:role/ung-dung-ec2"},
  "Action": ["s3:GetObject", "s3:ListBucket"],
  "Resource": ["arn:aws:s3:::ho-du-lieu", "arn:aws:s3:::ho-du-lieu/*"]
}

Vế "đặc quyền tối thiểu" là điểm phân biệt với phương án C: đề nói ứng dụng chỉ ĐỌC từ Account A2, nên cấp read access chứ không phải full access.

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

• C. Cùng cấu trúc như B nhưng resource-based policy cấp FULL access cho role của Account A1 — đây là phương án gần nhất và chỉ sai ở mức quyền: đề nêu rõ ứng dụng "reads (but doesn't write) files" từ Account A2, và yêu cầu (b) là đặc quyền tối thiểu. Cấp quyền ghi là vi phạm trực tiếp.
• D. Tạo IAM role ở Account A1; rồi tạo một identity-based role ở Account A2 cấp quyền cho ứng dụng ở Account A1 — sai loại policy cho truy cập chéo tài khoản: cấp quyền trên tài nguyên của tài khoản khác cần resource-based policy (bucket policy) có phần tử Principal. Một identity-based policy ở A2 cấp quyền cho chính các danh tính của A2, không cho principal của A1.
• A. Tạo permissions boundary từ chối request không dùng SSL và ngăn rời tổ chức; áp vào gốc của tổ chức — không thực hiện được: permissions boundary gắn cho một IAM user hoặc role, không gắn được vào OU hay gốc tổ chức.

Ghi nhớ

Điều kiện bắt buộc TLS — mẫu nên có trong mọi tổ chức:

{"Effect": "Deny", "Action": "*", "Resource": "*",
 "Condition": {"Bool": {"aws:SecureTransport": "false"}}}

aws:SecureTransport là true khi request dùng HTTPS. Đặt statement này ở SCP gốc tổ chức đảm bảo không tài khoản nào gọi API AWS qua HTTP — một rào chắn rẻ và hiệu quả.

(Mẫu tương đương cho từng bucket S3 dùng cùng condition key trong bucket policy — hữu ích khi bạn không quản lý cả tổ chức.)

Hai cách truy cập chéo tài khoản S3: | Cách | Cơ chế | |---|---| | Bucket policy cấp trực tiếp cho role của tài khoản kia | ít bước nhất ← câu này | | Assume role sang tài khoản đích | kiểm soát chặt hơn, ràng buộc được MFA và thời hạn |

Cả hai đều cần HAI phía cùng cho phép — IAM policy ở phía gọi và resource-based policy (hoặc trust policy) ở phía nhận.

Ba hành động nên chặn ở SCP gốc tổ chức: | Hành động | Lý do | |---|---| | organizations:LeaveOrganization | tài khoản tự rời = thoát khỏi mọi SCP | | Vô hiệu hoá CloudTrail | StopLogging, DeleteTrail, UpdateTrail | | Vô hiệu hoá GuardDuty, Config, Security Hub | mất khả năng phát hiện | | Xoá hoặc sửa role dành cho tổ chức | AWSControlTowerExecution, service-linked role |

Bốn nhóm này là "rào chắn nền tảng" mà AWS khuyến nghị cho mọi tổ chức — chúng bảo vệ chính các cơ chế kiểm soát khỏi bị gỡ bỏ.

Ba nguyên tắc khi thiết kế SCP: | Nguyên tắc | Lý do | |---|---| | Dùng Deny, không dùng Allow hẹp | SCP mặc định có FullAWSAccess; thay nó bằng Allow hẹp dễ chặn nhầm | | Kiểm thử trên OU thử nghiệm trước | SCP sai có thể làm ngưng vận hành cả tổ chức | | Chừa dịch vụ toàn cầu khi chặn theo Region | dùng NotAction (xem câu #7692, #7733) |

Và một lưu ý về mô hình trách nhiệm mà đề mô tả rất chuẩn: Central Cloud Team đặt rào chắn (SCP), đội ứng dụng tự vận hành trong rào chắn đó. Đây là mô hình quản trị đúng cho tổ chức nhiều tài khoản — kiểm soát tập trung ở mức chính sách, tự chủ ở mức triển khai.

Đáp án

B — Tạo các Service Control Policy (SCP) từ chối mọi thao tác ngoài các Region được chỉ định. Ngoài phần tử Condition và Resource, cấu hình phần tử NotAction để cho phép truy cập các dịch vụ AWS cần thiết.

Vì sao đúng

Đề yêu cầu: các đội chỉ truy cập được một số dịch vụ AWS ở một số Region nhất định, với ít công vận hành nhất.

Cấu trúc Deny + NotAction + aws:RequestedRegion là mẫu chuẩn:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "ChanNgoaiRegionDuocDuyet",
    "Effect": "Deny",
    "NotAction": [
      "iam:*", "organizations:*", "sts:*",
      "cloudfront:*", "route53:*", "support:*",
      "waf:*", "shield:*", "budgets:*"
    ],
    "Resource": "*",
    "Condition": {
      "StringNotEquals": {
        "aws:RequestedRegion": ["ap-southeast-1", "ap-northeast-1"]
      }
    }
  }]
}

Vì sao NotAction là bắt buộc chứ không phải tuỳ chọn: | Vấn đề | Chi tiết | |---|---| | Dịch vụ toàn cầu chạy ở endpoint us-east-1 | IAM, CloudFront, Route 53, Organizations, STS | | Nếu us-east-1 không nằm trong danh sách duyệt | chúng bị chặn theo | | Hậu quả | không quản lý được người dùng, không assume role được — có thể tự khoá cả tổ chức |

NotAction chừa các dịch vụ đó ra, nên chính sách chỉ áp cho các dịch vụ thực sự gắn với Region.

Và vì sao SCP là "ít công vận hành nhất":

Đặt MỘT SCP ở gốc tổ chức hoặc ở OU
    → áp cho MỌI tài khoản, MỌI người dùng, MỌI role
    → tài khoản mới gia nhập tự động được áp
    → không ai trong tài khoản thành viên gỡ được

So với việc gắn IAM policy cho từng người dùng qua AWS SSO, đây là một điểm cấu hình duy nhất.

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

• D. Tạo SCP theo chiến lược danh sách từ chối (deny list) để chặn dịch vụ và Region; loại trừ quản trị viên của các tài khoản thành viên khỏi SCP này — đây là phương án gần nhất và sai ở vế loại trừ: SCP KHÔNG loại trừ được quản trị viên — nó áp cho mọi principal trong tài khoản thành viên, kể cả root user. Đó vừa là điểm mạnh vừa là ràng buộc của SCP.
• A. Tạo SCP cho phép (Allow) người dùng truy cập một số dịch vụ ở các Region được chỉ định — cách tiếp cận rủi ro: SCP mặc định gắn FullAWSAccess; thay nó bằng một Allow hẹp sẽ chặn mọi thứ không được liệt kê, bao gồm cả dịch vụ toàn cầu và các dịch vụ mà bạn quên. Chiến lược deny list an toàn và dễ bảo trì hơn nhiều.
• C. Tạo SCP bắt buộc MFA để truy cập các dịch vụ ở Region được chỉ định; chia sẻ thông tin MFA chỉ cho những người cần — hai lỗi: MFA không giới hạn được Region hay dịch vụ, nó chỉ xác thực; và chia sẻ thông tin MFA giữa nhiều người là thực hành sai nghiêm trọng — MFA mất hết ý nghĩa nếu nhiều người dùng chung một thiết bị.

Ghi nhớ

Hai chiến lược viết SCP: | Chiến lược | Cách làm | Rủi ro | |---|---|---| | Deny list | giữ FullAWSAccess, thêm SCP Deny cho thứ cần chặn | thấp — mặc định là cho phép | | Allow list | gỡ FullAWSAccess, chỉ Allow những gì cần | cao — quên một dịch vụ là chặn nhầm |

AWS khuyến nghị deny list cho hầu hết trường hợp — allow list chỉ hợp với môi trường cực kỳ hạn chế và đã được kiểm thử kỹ.

Action và NotAction — và cảnh báo quan trọng: | Kết hợp | Nghĩa | An toàn? | |---|---|---| | Deny + NotAction | cấm mọi thứ TRỪ danh sách | ✅ dùng ở đây | | Deny + Action | cấm những thứ trong danh sách | ✅ | | Allow + Action | cho phép những thứ trong danh sách | ✅ | | Allow + NotAction | cho phép mọi thứ TRỪ danh sách | ⚠️ rất rộng — dịch vụ AWS mới cũng tự động được phép |

Các dịch vụ toàn cầu phải chừa khi chặn theo Region: | Dịch vụ | Hậu quả nếu chặn | |---|---| | iam | không quản lý được quyền — nguy hiểm nhất | | sts | không assume role được — hỏng gần như mọi thứ | | organizations | không quản lý tổ chức | | cloudfront, route53, waf, shield | dịch vụ toàn cầu ngừng quản lý được | | support, budgets, ce | mất truy cập hỗ trợ và chi phí |

sts là dòng dễ quên nhất và gây hậu quả rộng nhất — mọi cơ chế federation và assume role đều đi qua nó.

Ba nơi áp ràng buộc Region — theo mức mạnh: | Nơi | Ai gỡ được | |---|---| | SCP | chỉ tài khoản quản lý ← câu này | | Permissions boundary | admin của tài khoản đó | | IAM policy | admin của tài khoản đó |

Và một biện pháp bổ sung đáng biết: ngoài SCP, AWS còn cho phép tắt hẳn Region ở mức tài khoản (account:DisableRegion). Region đã tắt thì không gọi API tới đó được bằng bất kỳ cách nào — mạnh hơn SCP, nhưng cũng khó đảo ngược hơn và mất tới vài phút để có hiệu lực. Kết hợp cả hai là cấu hình chặt nhất: tắt Region không dùng, và dùng SCP cho các Region còn lại.

Nhớ kiểm thử trước khi áp lên gốc tổ chức. SCP chặn Region sai có thể khiến cả đội mất quyền vận hành — dùng IAM Policy Simulator và áp thử lên một OU thử nghiệm là bước không nên bỏ.