AWS Cloud Practitioner · Tiếng Việt
Chương 14 / 20

Bảo mật & Tuân thủ (Security & Compliance)

Mô hình trách nhiệm chung giữa AWS và khách hàng, cùng dàn dịch vụ bảo mật/tuân thủ của AWS — từ chống DDoS, mã hóa, đến phát hiện & điều tra mối đe dọa — và cách phân biệt các dịch vụ dễ nhầm với nhau.

Nội dung chương

  1. Mô hình trách nhiệm chung (Shared Responsibility Model)
  2. Tấn công DDoS & AWS Shield
  3. AWS WAF – Web Application Firewall
  4. AWS Network Firewall & AWS Firewall Manager
  5. Kiểm tra xâm nhập (Penetration Testing) trên AWS
  6. Mã hóa dữ liệu: Data at Rest vs Data in Transit
  7. AWS KMS (Key Management Service)
  8. AWS CloudHSM
  9. Các loại khóa trong KMS
  10. AWS Certificate Manager (ACM)
  11. AWS Secrets Manager
  12. AWS Artifact
  13. Amazon GuardDuty
  14. Amazon Inspector
  15. AWS Config
  16. Amazon Macie
  17. AWS Security Hub
  18. Amazon Detective
  19. So sánh các dịch vụ phát hiện & giám sát bảo mật
  20. Root User, AWS Abuse & IAM Access Analyzer

1. Mô hình trách nhiệm chung (Shared Responsibility Model)

Đây là khái niệm nền tảng, xuất hiện xuyên suốt kỳ thi Cloud Practitioner: bảo mật trên AWS không phải là việc của một bên mà là trách nhiệm được chia sẻ giữa AWS và khách hàng.

Nguyên tắc chung dễ nhớ: AWS lo phần "dưới đường ranh giới" (hạ tầng vật lý, phần cứng, và với managed service thì cả phần vận hành dịch vụ), khách hàng lo phần "trên đường ranh giới" (dữ liệu, cấu hình, quyền truy cập).

Ví dụ với Amazon RDS

Ví dụ với Amazon S3

Lưu ý khi thi: nếu đề bài mô tả một vụ rò rỉ dữ liệu do bucket S3 bị để public hoặc do quên vá lỗi hệ điều hành trên EC2 — đó luôn là trách nhiệm của khách hàng, không phải của AWS. Ngược lại, nếu đề bài nói về việc trung tâm dữ liệu AWS bị hỏng phần cứng vật lý — đó là trách nhiệm của AWS.

2. Tấn công DDoS & AWS Shield

DDoS (Distributed Denial-of-Service) là kiểu tấn công trong đó kẻ tấn công điều khiển một mạng lưới máy chủ trung gian ("masters"), các máy này tiếp tục điều khiển hàng loạt máy bị nhiễm mã độc ("bots" — tạo thành "botnet"), rồi đồng loạt gửi một lượng traffic khổng lồ (trộn lẫn với traffic của người dùng bình thường) tới một application server, khiến server đó quá tải, không còn khả năng phục vụ hoặc phản hồi được nữa — giống như hàng nghìn người cùng lúc gọi điện tới một tổng đài chỉ có vài đường dây, khiến khách hàng thật không thể gọi vào được.

AWS cung cấp nhiều tầng bảo vệ chống DDoS phối hợp với nhau:

Chi tiết AWS Shield

Tiêu chíShield StandardShield Advanced
Chi phíMiễn phí, tự động áp dụng cho mọi khách hàngCó phí, khoảng 3.000 USD/tháng cho mỗi Organization
Mức bảo vệChống tấn công SYN/UDP Flood, Reflection attack và các tấn công layer 3/layer 4 khácChống các tấn công tinh vi hơn, nhắm vào EC2, ELB, CloudFront, Global Accelerator, Route 53
Hỗ trợKhông có hỗ trợ chuyên biệtTruy cập 24/7 tới đội ứng cứu DDoS chuyên trách của AWS (DRP – DDoS Response Team)
Bảo vệ chi phíKhôngBảo vệ khỏi phụ phí tăng vọt do traffic tăng bất thường vì bị DDoS (cost protection)
Ví dụ thực tế: một trang thương mại điện tử vừa mở bán flash sale bị tấn công DDoS khiến traffic tăng gấp 50 lần bình thường trong vài phút. Nhờ đã đăng ký Shield Advanced, đội DRP của AWS hỗ trợ 24/7 giúp phân tích và giảm thiểu tấn công ngay lập tức, đồng thời công ty không phải trả thêm phí tăng vọt cho Auto Scaling/CloudFront do lượng traffic độc hại này gây ra.

3. AWS WAF – Web Application Firewall

AWS WAF bảo vệ ứng dụng web khỏi các kiểu khai thác web phổ biến, hoạt động ở tầng Layer 7 (tầng ứng dụng, HTTP) — khác với Shield chủ yếu tập trung ở Layer 3/4 (tầng mạng/vận chuyển, TCP). Nói cách khác, WAF "đọc hiểu" nội dung của từng request HTTP, còn Shield chỉ nhìn vào khối lượng và mẫu traffic ở tầng thấp hơn.

WAF được triển khai (deploy) trên: Application Load Balancer, API Gateway, và CloudFront.

Cách sử dụng WAF là định nghĩa một Web ACL (Web Access Control List) — một tập hợp các rule quyết định request nào được phép, request nào bị chặn. Rule có thể dựa trên: địa chỉ IP, HTTP header, HTTP body, hoặc URI string. WAF giúp chống lại các kiểu tấn công phổ biến như:

Lưu ý khi thi: Shield bảo vệ chống DDoS ở tầng hạ tầng (network/transport), WAF lọc request theo nội dung ở tầng ứng dụng (HTTP) — hai dịch vụ này thường phối hợp với nhau, không thay thế nhau.

4. AWS Network Firewall & AWS Firewall Manager

AWS Network Firewall

Nếu Security Group/NACL chỉ bảo vệ ở mức instance/subnet cơ bản, AWS Network Firewall cung cấp khả năng bảo vệ toàn bộ VPC với mức độ tinh vi hơn — từ Layer 3 đến Layer 7. Nó có thể kiểm tra (inspect) traffic theo mọi hướng: giữa VPC với VPC, từ VPC ra Internet (outbound), từ Internet vào VPC (inbound), và cả traffic đi/đến qua Direct Connect hay Site-to-Site VPN.

AWS Firewall Manager

Khi tổ chức của bạn có nhiều tài khoản AWS (trong một AWS Organization), việc quản lý rule bảo mật riêng lẻ cho từng account sẽ rất tốn công và dễ sai sót. AWS Firewall Manager giúp quản lý các quy tắc bảo mật tập trung trên toàn bộ các account trong Organization. Bạn định nghĩa một security policy — một tập hợp rule chung, có thể bao gồm: Security Group cho EC2/ALB, rule của WAF, cấu hình Shield Advanced, và rule của Network Firewall. Các rule này sẽ được tự động áp dụng cho cả tài nguyên hiện có và tài nguyên mới được tạo trong tương lai trên toàn Organization — rất hữu ích để đảm bảo tuân thủ (compliance) nhất quán.

Ví dụ thực tế: một tập đoàn có 30 tài khoản AWS con cho 30 nhóm dự án khác nhau. Đội bảo mật trung tâm dùng AWS Firewall Manager để bắt buộc mọi tài khoản (cả hiện tại và mới tạo sau này) phải áp dụng cùng một tập luật WAF chặn SQL Injection — mà không cần liên hệ từng nhóm để cấu hình thủ công.

5. Kiểm tra xâm nhập (Penetration Testing) trên AWS

Nhiều khách hàng muốn tự kiểm tra độ an toàn của hạ tầng của mình bằng cách chủ động "tấn công thử" (penetration test/pen test) hệ thống. AWS cho phép khách hàng thực hiện việc này mà không cần xin phép trước đối với 8 nhóm dịch vụ sau:

Danh sách này có thể được AWS mở rộng thêm theo thời gian.

Các hành vi bị cấm khi Pen Test

Dù được phép kiểm tra một số hoạt động vẫn luôn bị cấm, bất kể dịch vụ nào, vì chúng gây ảnh hưởng tới khách hàng khác hoặc hạ tầng chung:

Nếu bạn cần thực hiện một hoạt động mô phỏng khác (ví dụ giả lập sự cố để test khả năng phục hồi), cần liên hệ trước với AWS qua địa chỉ aws-security-simulated-event@amazon.com.

Lưu ý khi thi: nhớ rằng pen test được phép trên 8 dịch vụ kể trên mà không cần xin phép AWS trước, nhưng tấn công DDoS (thật hoặc giả lập) thì luôn bị cấm dù trên dịch vụ nào.

6. Mã hóa dữ liệu: Data at Rest vs Data in Transit

Đây là hai trạng thái cơ bản của dữ liệu mà bạn cần bảo vệ bằng mã hóa (encryption):

Nguyên tắc bảo mật cơ bản: bạn nên mã hóa dữ liệu ở cả hai trạng thái, tận dụng các hệ thống khóa mã hóa (encryption key) do AWS hoặc do bạn tự quản lý. Các phần tiếp theo sẽ giới thiệu các dịch vụ then chốt giúp làm điều này: KMS, CloudHSM, ACM, Secrets Manager.

Ví dụ thực tế: dữ liệu khách hàng lưu trong một bảng RDS được mã hóa bằng KMS (bảo vệ Data at Rest); khi ứng dụng web gọi tới RDS đó, kết nối được thiết lập qua SSL/TLS (bảo vệ Data in Transit) — hai lớp bảo vệ độc lập nhưng cùng cần thiết.

7. AWS KMS (Key Management Service)

Một quy tắc rất hữu ích để nhớ khi học AWS: bất cứ khi nào bạn nghe tới từ "encryption" (mã hóa) gắn với một dịch vụ AWS, nhiều khả năng đó là KMS đang hoạt động phía sau. KMS có nghĩa là AWS quản lý các khóa mã hóa (encryption key) thay cho bạn — bạn không cần tự lo phần hạ tầng phức tạp để tạo, lưu trữ, xoay (rotate) khóa.

Một số dịch vụ AWS cho phép bạn tùy chọn bật (opt-in) mã hóa bằng KMS:

Một số dịch vụ khác lại tự động được mã hóa mà không cần bạn làm gì:

Lưu ý khi thi: nhớ rằng SSE-S3 (mã hóa mặc định của S3, dùng khóa do AWS quản lý hoàn toàn) là bật sẵn, còn muốn dùng khóa KMS của riêng bạn (SSE-KMS) thì phải chủ động chọn.

8. AWS CloudHSM

Nếu KMS là "AWS quản lý phần mềm mã hóa cho bạn", thì CloudHSM đi xa hơn một bước: AWS cung cấp cho bạn phần cứng chuyên dụng để mã hóa (HSM – Hardware Security Module), nhưng chính bạn mới là người quản lý toàn bộ khóa mã hóa của mình — AWS hoàn toàn không can thiệp vào việc quản lý khóa đó. Thiết bị HSM có khả năng chống giả mạo (tamper resistant) và đạt chuẩn FIPS 140-2 Level 3 — một tiêu chuẩn bảo mật phần cứng nghiêm ngặt thường được yêu cầu trong các ngành có quy định chặt như tài chính, chính phủ.

Tiêu chíAWS KMSAWS CloudHSM
Ai quản lý khóaAWS quản lý (dù bạn có thể tạo Customer Managed Key)Bạn tự quản lý hoàn toàn, AWS không can thiệp
Hạ tầngDịch vụ phần mềm dùng chung (multi-tenant)Phần cứng chuyên dụng (dedicated hardware)
Mức độ kiểm soátVừa đủ cho hầu hết nhu cầu, dễ dùng, tích hợp sẵn với nhiều dịch vụKiểm soát tuyệt đối, đáp ứng yêu cầu tuân thủ nghiêm ngặt (FIPS 140-2 Level 3)
Độ phức tạp/chi phíThấp, dễ triển khaiCao hơn, phù hợp khi có yêu cầu compliance đặc thù
Lưu ý khi thi: câu hỏi kinh điển "KMS vs CloudHSM" thường được diễn đạt là: nếu đề bài nói "công ty muốn tự kiểm soát hoàn toàn khóa mã hóa, cần phần cứng chuyên dụng, đạt chuẩn FIPS 140-2 Level 3" → CloudHSM. Nếu chỉ cần "mã hóa dễ dàng, tích hợp sẵn với S3/EBS/RDS" → KMS.

9. Các loại khóa trong KMS

KMS không chỉ có một loại khóa duy nhất — hiểu rõ sự khác biệt giữa các loại khóa giúp bạn trả lời đúng nhiều câu hỏi tình huống trong đề thi.

Ví dụ thực tế: một công ty fintech cần tuân thủ quy định yêu cầu khóa mã hóa phải xoay (rotate) hằng năm và họ phải chứng minh được quyền kiểm soát khóa — họ dùng Customer Managed Key với rotation policy được bật, thay vì để mặc định S3 tự dùng AWS Managed Key.

10. AWS Certificate Manager (ACM)

AWS Certificate Manager (ACM) giúp bạn dễ dàng cấp phát, quản lý và triển khai chứng chỉ SSL/TLS. Chứng chỉ này được dùng để cung cấp mã hóa "in-flight" (tức là mã hóa Data in Transit) cho website — chính là thứ giúp trang web của bạn chạy được HTTPS thay vì HTTP không mã hóa.

Ví dụ thực tế: một website thương mại điện tử cần HTTPS để bảo vệ thông tin thẻ thanh toán của khách hàng khi truyền qua Internet. Họ dùng ACM để cấp một chứng chỉ TLS public miễn phí, gắn vào Application Load Balancer phía trước các EC2 instance — ACM tự động gia hạn chứng chỉ này mỗi khi gần hết hạn, không cần con người can thiệp.

11. AWS Secrets Manager

AWS Secrets Manager là dịch vụ (tương đối mới hơn so với KMS) được thiết kế chuyên biệt để lưu trữ các thông tin bí mật (secrets) — ví dụ mật khẩu database, API key, token. Khả năng nổi bật của Secrets Manager:

Lưu ý khi thi: khi đề bài nhắc tới nhu cầu "tự động xoay mật khẩu database định kỳ" → nghĩ ngay tới Secrets Manager, chứ không phải Systems Manager Parameter Store (dịch vụ đó lưu tham số cấu hình chung, không có khả năng tự xoay secret gắn với RDS như Secrets Manager).

12. AWS Artifact

AWS Artifact thực chất không phải một "dịch vụ" theo nghĩa kỹ thuật, mà là một cổng thông tin (portal) cho phép khách hàng truy cập theo nhu cầu (on-demand) vào các tài liệu tuân thủ (compliance) và các thỏa thuận của AWS.

AWS Artifact rất hữu ích để hỗ trợ các cuộc kiểm toán nội bộ (internal audit) hoặc chứng minh tuân thủ với đối tác/khách hàng của bạn.

Ví dụ thực tế: một công ty y tế cần chứng minh với đối tác rằng hạ tầng AWS của họ tuân thủ HIPAA — họ vào AWS Artifact, chấp thuận thỏa thuận BAA và tải xuống các báo cáo SOC liên quan để đưa vào hồ sơ kiểm toán tuân thủ nội bộ.

13. Amazon GuardDuty

Amazon GuardDuty là dịch vụ phát hiện mối đe dọa thông minh (Intelligent Threat Discovery) để bảo vệ tài khoản AWS của bạn. GuardDuty sử dụng machine learning, kỹ thuật phát hiện bất thường (anomaly detection), và dữ liệu tình báo mối đe dọa từ bên thứ ba để tìm ra các hành vi đáng ngờ. Chỉ cần một cú click để bật (có bản dùng thử 30 ngày), không cần cài đặt phần mềm gì thêm.

GuardDuty phân tích các nguồn dữ liệu sau (bắt buộc, không cần cấu hình thêm):

Ngoài ra, GuardDuty còn có các tính năng tùy chọn (optional) để mở rộng phạm vi giám sát: EKS Audit Logs, RDS & Aurora, EBS, Lambda, và S3 Data Events.

Bạn có thể thiết lập rule trong EventBridge để nhận thông báo mỗi khi có finding (phát hiện) mới, gửi tới đích như Lambda hoặc SNS để xử lý tự động hoặc cảnh báo. GuardDuty cũng có khả năng phát hiện chuyên biệt cho các cuộc tấn công liên quan đến tiền mã hóa (cryptocurrency) — ví dụ khi một instance bị chiếm quyền để "đào" coin trái phép.

Ví dụ thực tế: một EC2 instance bị nhiễm mã độc bắt đầu gửi các truy vấn DNS bất thường chứa dữ liệu đã được mã hóa ra một domain lạ. GuardDuty phát hiện mẫu hành vi này từ DNS Logs, tạo ra một finding, kích hoạt rule EventBridge để gửi cảnh báo qua SNS tới đội bảo mật ngay lập tức.

14. Amazon Inspector

Amazon Inspector thực hiện đánh giá bảo mật tự động (Automated Security Assessments), tập trung vào việc tìm lỗ hổng phần mềm (vulnerability) — khác với GuardDuty (tập trung tìm hành vi/traffic bất thường đang xảy ra).

Inspector có khả năng báo cáo và tích hợp với AWS Security Hub, và gửi finding tới EventBridge để xử lý tự động.

Inspector đánh giá những gì?

Lưu ý khi thi: phân biệt rõ GuardDuty (phát hiện hành vi/traffic đáng ngờ đang diễn ra, dựa trên log) với Inspector (tìm lỗ hổng phần mềm đã biết trước trong EC2/ECR/Lambda, dựa trên quét và CVE database).

15. AWS Config

AWS Config giúp bạn kiểm toán (audit) và ghi lại mức độ tuân thủ (compliance) của các tài nguyên AWS. Nó ghi lại cấu hình của tài nguyên và lịch sử thay đổi cấu hình theo thời gian — trả lời được câu hỏi "tài nguyên này đã bị thay đổi như thế nào, và khi nào".

Dữ liệu cấu hình có thể được lưu vào S3 để sau đó phân tích bằng Athena. Một số câu hỏi điển hình mà AWS Config có thể trả lời:

AWS Config có thể gửi cảnh báo (qua SNS notification) mỗi khi phát hiện thay đổi. AWS Config là dịch vụ hoạt động theo từng Region (per-region), nhưng có thể được tổng hợp (aggregate) xuyên qua nhiều Region và nhiều account. Với mỗi tài nguyên, bạn có thể xem: mức độ tuân thủ theo thời gian, lịch sử cấu hình theo thời gian, và (nếu CloudTrail được bật) lịch sử các API call đã tác động lên tài nguyên đó.

Ví dụ thực tế: đội bảo mật muốn đảm bảo không bao giờ có Security Group nào mở port 22 (SSH) cho toàn bộ Internet (0.0.0.0/0). Họ thiết lập một AWS Config rule để tự động kiểm tra điều này liên tục; ngay khi có ai đó vô tình tạo một rule vi phạm, AWS Config đánh dấu tài nguyên đó là "non-compliant" và gửi cảnh báo qua SNS.

16. Amazon Macie

Amazon Macie là dịch vụ bảo mật và quyền riêng tư dữ liệu (data security & data privacy) được quản lý hoàn toàn, sử dụng machine learning và kỹ thuật so khớp mẫu (pattern matching) để phát hiện và bảo vệ dữ liệu nhạy cảm trên AWS. Ứng dụng chính của Macie là quét các bucket S3 để tìm và cảnh báo khi phát hiện dữ liệu nhạy cảm — điển hình là thông tin định danh cá nhân (PII – Personally Identifiable Information) như số căn cước, số thẻ tín dụng, thông tin y tế.

Macie có thể tích hợp với EventBridge để gửi thông báo khi có phát hiện mới, cho phép tự động hóa quy trình xử lý (ví dụ tự động khóa quyền truy cập bucket đang chứa dữ liệu nhạy cảm bị public).

Lưu ý khi thi: nhớ Macie = "tìm dữ liệu nhạy cảm/PII trong S3" — khác hoàn toàn với GuardDuty (hành vi bất thường) hoặc Inspector (lỗ hổng phần mềm). Nếu đề bài nhắc tới "PII", "dữ liệu cá nhân", "quyền riêng tư dữ liệu trong S3" → nghĩ tới Macie ngay.

17. AWS Security Hub

Khi một tổ chức dùng nhiều dịch vụ bảo mật khác nhau (GuardDuty, Inspector, Macie...) trên nhiều account, việc theo dõi tất cả các cảnh báo riêng lẻ ở từng nơi sẽ rất mất công. AWS Security Hub là công cụ bảo mật trung tâm, giúp quản lý bảo mật xuyên suốt nhiều account AWS và tự động hóa các kiểm tra bảo mật (security checks).

Security Hub cung cấp dashboard tích hợp, cho thấy tình trạng bảo mật và tuân thủ hiện tại để bạn nhanh chóng có hành động phù hợp. Nó tự động tổng hợp (aggregate) các cảnh báo (findings) theo một định dạng chuẩn (predefined) hoặc tùy biến (personal), từ nhiều dịch vụ AWS và cả công cụ của bên thứ ba (partner tools):

Điều kiện tiên quyết quan trọng: bạn phải bật AWS Config trước mới có thể sử dụng đầy đủ Security Hub.

Lưu ý khi thi: hãy hiểu Security Hub là "màn hình tổng hợp" (dashboard tập trung), không tự nó phát hiện mối đe dọa hay lỗ hổng — nó thu thập và hiển thị kết quả từ các dịch vụ khác như GuardDuty, Inspector, Macie, Config.

18. Amazon Detective

GuardDuty, Macie, và Security Hub giúp bạn phát hiện các vấn đề bảo mật tiềm ẩn (findings). Nhưng đôi khi, một finding chỉ là "dấu hiệu bề mặt" — để hiểu rõ nguyên nhân gốc rễ (root cause) của một sự cố bảo mật hoặc hành vi đáng ngờ, bạn cần đào sâu, liên kết dữ liệu từ nhiều nguồn khác nhau — một quá trình vốn rất phức tạp và tốn thời gian nếu làm thủ công.

Amazon Detective được thiết kế chuyên biệt để giải quyết bài toán này: nó phân tích, điều tra (investigate), và nhanh chóng xác định nguyên nhân gốc rễ của các vấn đề bảo mật hoặc hoạt động đáng ngờ, sử dụng machine learning và biểu diễn dạng đồ thị (graph). Detective tự động thu thập và xử lý dữ liệu sự kiện từ VPC Flow Logs, CloudTrail, và GuardDuty, tạo ra một "cái nhìn thống nhất" (unified view) về toàn bộ hoạt động liên quan. Kết quả là các hình ảnh trực quan (visualization) giàu chi tiết và ngữ cảnh, giúp đội bảo mật nhanh chóng lần ra nguyên nhân gốc.

Ví dụ thực tế: GuardDuty phát hiện một finding cảnh báo "traffic bất thường từ một EC2 instance". Đội bảo mật mở Amazon Detective, nó tự động hiển thị đồ thị liên kết: instance này đã giao tiếp với IP nào, tại thời điểm nào, cùng với các API call liên quan trong CloudTrail — giúp xác định nhanh rằng nguyên nhân là một IAM Role bị lộ credential, thay vì phải tự lọc log thủ công qua nhiều dịch vụ.

19. So sánh các dịch vụ phát hiện & giám sát bảo mật

Đây là nhóm dịch vụ dễ gây nhầm lẫn nhất trong toàn bộ chương trình học Cloud Practitioner, vì tên nghe có vẻ tương tự nhau (đều là "phát hiện", "giám sát", "bảo mật"). Bảng dưới đây tổng hợp lại điểm khác biệt cốt lõi để bạn dễ phân biệt nhanh khi làm bài thi.

Dịch vụTrả lời câu hỏi gìNguồn dữ liệu chính
GuardDutyCó ai/cái gì đang hành xử đáng ngờ trong account của tôi không?CloudTrail, VPC Flow Logs, DNS Logs (+ tùy chọn EKS, RDS, Lambda, S3)
InspectorEC2/container image/Lambda của tôi có lỗ hổng phần mềm đã biết không?SSM Agent, CVE database, quét image ECR, quét code Lambda
MacieTôi có đang lưu dữ liệu nhạy cảm (PII) không an toàn trong S3 không?Nội dung object trong S3 (machine learning + pattern matching)
ConfigCấu hình tài nguyên của tôi có tuân thủ rule không, và đã thay đổi thế nào?Snapshot cấu hình tài nguyên theo thời gian
Security HubTình trạng bảo mật tổng thể của tôi trên nhiều account như thế nào?Tổng hợp finding từ Config, GuardDuty, Inspector, Macie, và các bên thứ ba
DetectiveNguyên nhân gốc rễ của một finding/sự cố cụ thể là gì?VPC Flow Logs, CloudTrail, GuardDuty (kết hợp, phân tích bằng graph)
Lưu ý khi thi: một cách ghi nhớ nhanh theo "động từ chính" của từng dịch vụ — GuardDuty = phát hiện hành vi; Inspector = quét lỗ hổng; Macie = tìm dữ liệu nhạy cảm; Config = theo dõi cấu hình/tuân thủ; Security Hub = tổng hợp dashboard; Detective = điều tra nguyên nhân gốc. Một quy trình thực tế thường đi theo thứ tự: Config/GuardDuty/Inspector/Macie tạo ra finding → Security Hub tổng hợp hiển thị → Detective giúp điều tra sâu nguyên nhân.

20. Root User, AWS Abuse & IAM Access Analyzer

AWS Abuse

Nếu bạn phát hiện tài nguyên AWS (thuộc về người khác) đang được dùng cho mục đích lạm dụng hoặc bất hợp pháp, bạn có thể báo cáo cho AWS. Các hành vi bị coi là lạm dụng và bị cấm bao gồm: spam, quét cổng (port scanning), tấn công DoS/DDoS, hành vi xâm nhập (intrusion attempt), host nội dung phản cảm hoặc vi phạm bản quyền, và phát tán mã độc (malware). Có thể liên hệ đội AWS Abuse qua form báo cáo abuse của AWS hoặc email abuse@amazonaws.com.

Đặc quyền của Root User

Root user chính là chủ tài khoản (Account Owner), được tạo ra ngay khi bạn tạo tài khoản AWS. Root user có toàn quyền truy cập vào mọi dịch vụ và tài nguyên AWS trong tài khoản. Chính vì quyền lực tuyệt đối này, nguyên tắc bảo mật quan trọng là: khóa chặt (lock away) access key của root user, và không dùng root account cho công việc hằng ngày — kể cả các công việc quản trị thông thường (hãy dùng IAM user/role có quyền phù hợp thay thế).

Một số hành động đặc biệt chỉ có thể thực hiện bởi root user — không IAM user hay role nào khác có thể làm, dù có full admin permission:

IAM Access Analyzer

IAM Access Analyzer giúp bạn phát hiện những tài nguyên nào đang được chia sẻ ra bên ngoài (externally shared) — điều mà đôi khi xảy ra ngoài ý muốn và tạo ra lỗ hổng bảo mật nghiêm trọng. Các loại tài nguyên được kiểm tra bao gồm: S3 bucket, IAM Role, KMS Key, Lambda function và Lambda Layer, SQS queue, và Secrets Manager secret.

Cách hoạt động: bạn định nghĩa một Zone of Trust — có thể là một AWS Account hoặc cả một AWS Organization. Bất kỳ quyền truy cập nào tới các tài nguyên trên mà đến từ bên ngoài Zone of Trust này sẽ được ghi nhận thành một finding để bạn xem xét và xử lý.

Ví dụ thực tế: một lập trình viên vô tình cấu hình bucket policy cho phép Principal: * (bất kỳ ai) đọc được một bucket S3 chứa dữ liệu nội bộ. IAM Access Analyzer với Zone of Trust là toàn bộ Organization sẽ phát hiện ngay rằng bucket này đang bị chia sẻ ra ngoài phạm vi tin cậy, tạo finding cảnh báo trước khi dữ liệu bị rò rỉ thực sự.
Lưu ý khi thi: danh sách "chỉ root user mới làm được" là nội dung hay bị hỏi trực tiếp — ít nhất nhớ các mục nổi bật: đóng tài khoản, thay đổi/hủy Support Plan, đăng ký GovCloud, và bật MFA Delete cho S3.

Tổng kết chương

← Chương trước Chương sau →