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

Tìm thấy 445 câu.

Câu 21 Data Protection

A company wants to secure the objects in S3 using server-side encryption, subject to the constraint that the key material must be generated and stored in a certified FIPS 140-2 Level 3 hardware service modules (HSM) that the company manages itself. In addition, the key material must be available in multiple Regions. The size of objects in S3 ranges from 15 KB to 5 MB.

As an AWS Certified Security Specialist, which of the following would you recommend?

  1. A

    Leverage an AWS KMS customer managed key backed by AWS CloudHSM clusters. Store the key material securely in Amazon S3 with cross-Region replication enabled
  2. B

    Leverage AWS CloudHSM to generate the key material. Copy backups across Regions. Use AWS Encryption SDK to encrypt and decrypt the data
  3. C

    Leverage an AWS KMS custom key store backed by AWS CloudHSM clusters. Copy backups across Regions
  4. D

    Leverage an AWS KMS customer managed key and store the key material in AWS with key replication enabled across Regions
Xem giải thích

Đáp án

C — Dùng AWS KMS custom key store được hậu thuẫn bởi cụm AWS CloudHSM, và sao chép backup qua các Region.

Vì sao đúng

Đề nêu bốn ràng buộc, và chỉ custom key store thoả hết: | Ràng buộc | Cơ chế | |---|---| | Mã hoá phía máy chủ cho S3 | KMS key → SSE-KMS | | Key material sinh và lưu trong HSM FIPS 140-2 Level 3 | CloudHSM đạt chuẩn này | | Công ty TỰ QUẢN LÝ HSM | CloudHSM — bạn kiểm soát cụm | | Key material có ở nhiều Region | sao chép backup của CloudHSM |

Custom key store là cầu nối giữa hai dịch vụ:

AWS KMS (giao diện quen thuộc, tích hợp với S3, EBS, RDS...)
    ↓ custom key store
AWS CloudHSM (key material nằm trong HSM của BẠN)

Vì sao cần cả hai chứ không chỉ CloudHSM: S3 SSE-KMS chỉ làm việc với KMS key, không gọi thẳng CloudHSM được. Custom key store cho phép bạn dùng API của KMS trong khi key material không bao giờ rời khỏi HSM của bạn — đó chính là điều đề yêu cầu.

Và kích thước object 15 KB – 5 MB là chi tiết có ý nghĩa: nó nằm trong khoảng mà SSE-KMS hoạt động hiệu quả. (Với object rất nhỏ và số lượng cực lớn, chi phí lời gọi KMS có thể thành vấn đề — khi đó S3 Bucket Keys giúp giảm đáng kể.)

Về vế đa Region: custom key store gắn với một Region, nên cách đảm bảo key material có ở nhiều Region là sao chép backup của cụm CloudHSM sang Region khác rồi dựng custom key store tương ứng.

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

  • B. Dùng CloudHSM sinh key material, sao chép backup qua Region, dùng AWS Encryption SDK để mã hoá và giải mã — đây là phương án gần nhất và về mặt bảo mật là hợp lệ, nhưng nó chuyển sang mã hoá phía CLIENT: đề yêu cầu server-side encryption cho S3. Với Encryption SDK, ứng dụng phải tự mã hoá trước khi tải lên — nhiều công hơn và không phải SSE.
  • D. Dùng KMS customer managed key và lưu key material trong AWS với key replication qua Region — không thoả ràng buộc HSM tự quản lý: KMS key thường dùng HSM do AWS quản lý ở mức FIPS 140-2 Level 3 cho module, nhưng công ty không kiểm soát cụm. Đề nói rõ "HSM that the company manages itself".
  • A. Dùng KMS customer managed key hậu thuẫn bởi CloudHSM, lưu key material trong Amazon S3 với cross-Region replication — sai nghiêm trọng về mặt bảo mật: key material KHÔNG BAO GIỜ được lưu ra ngoài HSM. Toàn bộ giá trị của HSM là key không rời khỏi phần cứng chuyên dụng.

Ghi nhớ

Ba lựa chọn quản lý khoá trên AWS — theo mức kiểm soát: | Lựa chọn | Ai quản HSM | FIPS | |---|---|---| | KMS (AWS managed key) | AWS | 140-2 Level 3 (module) | | KMS (customer managed key) | AWS | 140-2 Level 3 | | KMS custom key store + CloudHSM | BẠN | 140-2 Level 3, cụm của bạn | | CloudHSM trực tiếp | BẠN | 140-2 Level 3 |

Hai dòng cuối khác nhau ở giao diện sử dụng: | | Custom key store | CloudHSM trực tiếp | |---|---|---| | API | KMS (quen thuộc) | PKCS#11, JCE, CNG | | Tích hợp dịch vụ AWS | ✅ S3, EBS, RDS... | ❌ phải tự tích hợp | | Dùng khi | cần SSE cho dịch vụ AWS ← câu này | ứng dụng tự quản lý mã hoá |

Bốn loại mã hoá phía máy chủ của S3: | Loại | Khoá | Cần quyền KMS? | |---|---|---| | SSE-S3 | AWS quản lý hoàn toàn | ❌ | | SSE-KMS | KMS key | ✅ kms:Decrypt, kms:GenerateDataKey | | SSE-KMS + custom key store | CloudHSM của bạn | ✅ | | SSE-C | bạn cung cấp mỗi request | ❌ | | DSSE-KMS | mã hoá hai lớp | ✅ |

Ba điều cần biết về custom key store: | Điều | Chi tiết | |---|---| | Cụm CloudHSM phải có ít nhất 2 HSM | tính sẵn sàng | | Cụm phải ACTIVE thì key mới dùng được | cụm chết = không giải mã được gì | | Bạn chịu trách nhiệm backup | AWS không khôi phục hộ |

Dòng giữa là rủi ro vận hành thật: với KMS thường, AWS lo tính sẵn sàng; với custom key store, mất cụm là mất khả năng truy cập dữ liệu. Đó là cái giá của việc tự kiểm soát.

Và một tối ưu chi phí đáng biết cho S3 với SSE-KMS: bật S3 Bucket Keys. Nó giảm số lời gọi KMS xuống rất nhiều bằng cách dùng một khoá cấp bucket cho nhiều object — tiết kiệm đáng kể khi số lượng object lớn, và không ảnh hưởng tới mức bảo vệ.

Câu 22 Data Protection

A security engineer must ensure that all certificates imported into AWS Certificate Manager (ACM) in all AWS Regions, must be notified of expiry, 30 days before their actual expiry via a single notification to the security administrator. The notification along with the certificate information should be sent to the security administrator and the Security Hub for centralized management.

Which steps must be taken to perform these tasks optimally?

  1. A

    ACM built-in Certificate Expiration event raised through Amazon EventBridge, can be used to invoke a Lambda function. This event-based function raised from a specific certificate, can be configured to publish the result as a finding to Security Hub, and further to an SNS topic used for email subscriptions. An IT service management system can be configured to automatically open a case or incident through SNS and remediate the issue
  2. B

    Security Hub has a built-in feature to monitor certificate expirations of ACM certificates. Configure the security Hub to trigger SNS notifications 30 days before the actual expiry date of the certificate
  3. C

    Leverage the ACM_CERTIFICATE_EXPIRATION_CHECK managed rule provided by AWS Config to automatically renew the certificates imported into ACM. Forward the rule invocation to trigger SNS notifications to the security administrator
  4. D

    Configure the DaysToExpiry CloudWatch metric to schedule a batch search of expiring ACM certificates and trigger an AWS Lambda function to send the certificates-to-be-expired notification to an SNS topic. This Lambda function can also be configured to log all the expiring certificates as findings in Security Hub
Xem giải thích

Đáp án

D — Cấu hình CloudWatch metric DaysToExpiry để tìm theo lịch các chứng chỉ ACM sắp hết hạn và kích hoạt Lambda function gửi thông báo tới SNS topic; Lambda này cũng ghi các chứng chỉ sắp hết hạn thành finding trong Security Hub.

Vì sao đúng

Đề nêu bốn yêu cầu, và D đáp ứng cả bốn: | Yêu cầu | Cơ chế | |---|---| | Chứng chỉ NHẬP KHẨU (imported) vào ACM | DaysToExpiry áp cho cả chứng chỉ nhập khẩu | | Ở MỌI Region | Lambda quét qua các Region | | MỘT thông báo duy nhất | gom lại rồi gửi một lần | | Gửi tới cả quản trị viên và Security Hub | SNS + BatchImportFindings |

Vế "một thông báo duy nhất" là điểm phân biệt quan trọng nhất so với phương án A:

Phương án A (event-driven từng chứng chỉ):
  Chứng chỉ 1 sắp hết hạn → 1 event → 1 email
  Chứng chỉ 2 sắp hết hạn → 1 event → 1 email
  ... 50 chứng chỉ → 50 email

Phương án D (quét theo lịch, gom lại):
  Lambda quét mọi Region → gom danh sách → 1 email chứa tất cả

Đề nói rõ "via a single notification to the security administrator".

DaysToExpiry là metric ACM tự phát lên CloudWatch:

Namespace: AWS/CertificateManager
Metric:    DaysToExpiry
Dimension: CertificateArn

Lambda đọc metric này, lọc những cái dưới 30 ngày, rồi gửi kết quả tới hai đích.

Và ghi vào Security Hub bằng BatchImportFindings:

securityhub.batch_import_findings(Findings=[{
    'SchemaVersion': '2018-10-08',
    'Id': arn_chung_chi,
    'ProductArn': f'arn:aws:securityhub:{region}:{acc}:product/{acc}/default',
    'Title': 'Chứng chỉ ACM sắp hết hạn',
    'Severity': {'Label': 'MEDIUM'},
    'Resources': [{'Type': 'AwsCertificateManagerCertificate', 'Id': arn_chung_chi}]}])

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

  • A. Dùng sự kiện "ACM Certificate Expiration" qua EventBridge kích hoạt Lambda; hàm này công bố kết quả thành finding trong Security Hub và gửi tới SNS — đây là phương án gần nhất và cơ chế hoàn toàn hợp lệ (ACM thật sự phát sự kiện này qua EventBridge). Nó thua ở một yêu cầu cụ thể: sự kiện được phát cho từng chứng chỉ riêng lẻ, nên với nhiều chứng chỉ sẽ có nhiều thông báo — trái yêu cầu "a single notification".
  • C. Dùng managed rule ACM_CERTIFICATE_EXPIRATION_CHECK của AWS Config để TỰ ĐỘNG GIA HẠN chứng chỉ nhập khẩu — hai lỗi: Config rule chỉ đánh giá tuân thủ, nó không gia hạn gì cả; và chứng chỉ NHẬP KHẨU không tự gia hạn được — ACM chỉ tự gia hạn chứng chỉ do chính nó cấp.
  • B. Security Hub có tính năng dựng sẵn giám sát hết hạn chứng chỉ ACM; cấu hình Security Hub kích hoạt SNS trước 30 ngày — gán cho Security Hub một tính năng nó không có: Security Hub tổng hợp finding từ các nguồn khác, nó không tự giám sát chứng chỉ.

Ghi nhớ

Hai loại chứng chỉ trong ACM — khác biệt quyết định: | Loại | Tự gia hạn | Cần theo dõi hết hạn? | |---|---|---| | ACM cấp (issued) | ✅ tự động | ít cần | | Nhập khẩu (imported) | ❌ KHÔNG | ✅ bắt buộc |

Đề nói rõ "certificates IMPORTED into ACM" — nên việc theo dõi hết hạn là bắt buộc, và không có cơ chế tự gia hạn nào.

Ba cách theo dõi chứng chỉ ACM sắp hết hạn: | Cách | Đặc điểm | |---|---| | CloudWatch metric DaysToExpiry | quét được theo lịch, gom nhiều chứng chỉ ← câu này | | EventBridge event "ACM Certificate Expiration" | sự kiện riêng cho từng chứng chỉ | | AWS Config ACM_CERTIFICATE_EXPIRATION_CHECK | đánh giá tuân thủ, hiện trong bảng điểm |

Cả ba đều hợp lệ — chọn theo nhu cầu: gom một thông báo thì dùng metric; phản ứng ngay từng cái thì dùng EventBridge; theo dõi tuân thủ thì dùng Config.

Ba khả năng của Security Hub: | Khả năng | Chi tiết | |---|---| | Tổng hợp finding | từ GuardDuty, Inspector, Macie, Config, và bên thứ ba | | Chấm điểm theo chuẩn | CIS, PCI DSS, AWS Foundational Security Best Practices | | BatchImportFindings | đưa finding TỰ ĐỊNH NGHĨA vào ← dùng ở đây |

Dòng cuối là cách tích hợp kiểm tra riêng của bạn vào bảng điều khiển bảo mật chung — thay vì có một hệ thống cảnh báo riêng nằm ngoài.

Và một lưu ý về quét đa Region: ACM có hai phạm vi: | Phạm vi | Region | |---|---| | Chứng chỉ cho CloudFront | bắt buộc us-east-1 | | Chứng chỉ cho ALB, API Gateway | cùng Region với tài nguyên |

Nên Lambda quét phải bao gồm us-east-1 dù ứng dụng chạy ở Region khác — một chỗ dễ bỏ sót khi giám sát.

Câu 23 Data Protection

A company stores its critical business data on Amazon S3 buckets. A customer does not use TLS versions 1.2 or higher and hence is unable to access content stored in Amazon Simple Storage Service (Amazon S3) buckets.

As a Security Engineer, how will you set up a solution to allow the customers to access content in the Amazon S3 buckets using TLS 1.0 or 1.1 while keeping the communication channel secure?

  1. A

    Create a bucket policy that allows secure data access via TLS 1.0 or 1.1
  2. B

    The wildcard domain name feature of AWS Certificate Manager (ACM) can be used to work around the TLS version limitations
  3. C

    Configure a CloudFront distribution with an Amazon S3 bucket as the custom origin. CloudFront supports anonymous and public requests to S3 buckets for undisrupted user access
  4. D

    Create a CloudFront distribution with Origin Access Control (OAC). Make your S3 bucket private and configure access through Amazon CloudFront only by using signed requests to access the S3 bucket
Xem giải thích

Đáp án

D — Tạo CloudFront distribution với Origin Access Control (OAC); đặt S3 bucket ở chế độ riêng tư và cấu hình truy cập chỉ qua CloudFront bằng signed request.

Vì sao đúng

Đề nêu một ràng buộc kỹ thuật cụ thể: khách hàng không dùng TLS 1.2 trở lên, nên không truy cập được S3 trực tiếp.

Nguyên nhân: Amazon S3 yêu cầu TLS 1.2 trở lên cho các endpoint của nó — đây là chính sách của dịch vụ và không tắt được bằng bucket policy.

CloudFront giải quyết bằng cách tách đôi kết nối:

Khách hàng (TLS 1.0/1.1)
    ↓ ① kết nối tới CloudFront — CloudFront hỗ trợ TLS 1.0/1.1 qua security policy
CloudFront
    ↓ ② kết nối tới S3 origin — dùng TLS 1.2+ (CloudFront tự lo)
S3 bucket (riêng tư)

Cả hai chặng đều được mã hoá — nên yêu cầu "keeping the communication channel secure" vẫn được giữ, dù chặng đầu dùng phiên bản TLS cũ hơn.

Security policy của CloudFront quyết định phiên bản TLS tối thiểu: | Policy | TLS tối thiểu | |---|---| | TLSv1 | 1.0 | | TLSv1.1_2016 | 1.1 | | TLSv1.2_2021 | 1.2 — mặc định khuyến nghị |

Và OAC là vế bảo mật quan trọng: nó khiến bucket hoàn toàn riêng tư và chỉ CloudFront đọc được:

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

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

  • C. Cấu hình CloudFront với S3 bucket làm CUSTOM ORIGIN; CloudFront hỗ trợ request ẩn danh và công khai tới S3 bucket cho truy cập không gián đoạn — đây là phương án gần nhất và hướng đúng nhưng thiếu bảo mật: dùng S3 làm custom origin (qua website endpoint) đòi bucket phải công khai, và khi đó ai cũng bỏ qua CloudFront để vào thẳng S3 — mất kiểm soát hoàn toàn.
  • **A. Tạo bucket policy cho phép truy cập an toàn qua TLS 1.0 hoặc 1.1 — không làm được: bucket policy có thể YÊU CẦU phiên bản TLS tối thiểu (qua s3:TlsVersion), nhưng không thể HẠ THẤP yêu cầu của chính dịch vụ S3.
  • B. Dùng tính năng wildcard domain của ACM để lách giới hạn phiên bản TLS — không liên quan: wildcard certificate là về phạm vi tên miền (*.example.com), hoàn toàn không ảnh hưởng tới phiên bản giao thức TLS.

Ghi nhớ

Hai cơ chế bảo vệ S3 origin của CloudFront: | Cơ chế | Trạng thái | |---|---| | Origin Access Control (OAC) | KHUYẾN NGHỊ hiện nay | | Origin Access Identity (OAI) | cơ chế cũ, vẫn hoạt động |

OAC hơn OAI ở ba điểm: | Điểm | Chi tiết | |---|---| | Hỗ trợ SSE-KMS | OAI không đọc được object mã hoá bằng KMS | | Hỗ trợ mọi Region | OAI có hạn chế | | Hỗ trợ PUT, DELETE | không chỉ GET |

Dòng đầu là lý do thường gặp nhất để chuyển từ OAI sang OAC.

Ba lợi ích khác của việc đặt CloudFront trước S3: | Lợi ích | Chi tiết | |---|---| | Cache ở edge | giảm độ trễ và chi phí truyền dữ liệu | | Tích hợp WAF | lọc request độc hại | | Kiểm soát truy cập nâng cao | signed URL, signed cookie, geo restriction |

Ba cách kiểm soát phiên bản TLS: | Nơi | Cơ chế | |---|---| | CloudFront | security policy — chọn phiên bản tối thiểu | | S3 | s3:TlsVersion condition trong bucket policy | | ALB | security policy của listener |

Điều kiện bắt TLS trên S3 đáng biết cho hướng ngược lại (siết chặt thay vì nới lỏng):

{"Effect": "Deny", "Action": "s3:*", "Resource": "...",
 "Condition": {"NumericLessThan": {"s3:TlsVersion": 1.2}}}

Và một cân nhắc bảo mật cần nói thẳng: cho phép TLS 1.0/1.1 là hạ thấp mức bảo vệ — hai phiên bản này đã bị coi là lỗi thời và có điểm yếu đã biết. Giải pháp này là cầu nối tạm thời cho khách hàng chưa nâng cấp được; kế hoạch dài hạn nên là giúp họ chuyển lên TLS 1.2, và giới hạn phạm vi distribution dùng policy cũ chỉ cho đúng nhóm khách hàng đó.

Câu 24 Data Protection

A company uses AWS CloudFormation templates to provision all of its AWS infrastructure resources. One such CloudFormation template needs to provide the username and password as credentials to the newly created Amazon Redshift database.

Which is the optimal way to configure the database credentials during the stack creation without compromising these credentials?

  1. A

    Create a separate CloudFormation template for the database resources. The database template should be created with the credentials of the database encrypted into the template. Use this template to create database resources
  2. B

    First create a secret with a password generated by Secrets Manager. Then use a dynamic reference in the CloudFormation template to retrieve the username and password from the secret to use as credentials for the new database created
  3. C

    First create a secret with a password generated by Secrets Manager. Then use a dynamic reference in the CloudFormation template using a backslash as the final value. The backslash will be replaced with the credentials during the new database creation
  4. D

    First create a secret with a password generated by Secrets Manager. Use a dynamic reference for the secret in resource metadata such as AWS::CloudFormation::Init for the new database created
Xem giải thích

Đáp án

B — Trước tiên tạo một secret với mật khẩu do Secrets Manager sinh ra, rồi dùng dynamic reference trong template CloudFormation để lấy username và password từ secret đó làm thông tin đăng nhập cho cơ sở dữ liệu mới.

Vì sao đúng

Đề nêu yêu cầu: cấu hình thông tin đăng nhập CSDL trong lúc tạo stack mà không làm lộ chúng.

Vấn đề với cách làm thông thường:

Parameters:
  DBPassword:
    Type: String        ← giá trị hiện trong Console, trong sự kiện stack,
                          trong CloudTrail, và trong template nếu hard-code

Dynamic reference giải quyết bằng cách CloudFormation lấy giá trị lúc chạy:

Resources:
  MatKhauDB:
    Type: AWS::SecretsManager::Secret
    Properties:
      Name: redshift-thong-tin-dang-nhap
      GenerateSecretString:
        SecretStringTemplate: '{"username": "admin"}'
        GenerateStringKey: 'password'
        PasswordLength: 32
        ExcludeCharacters: '"@/'

  CumRedshift:
    Type: AWS::Redshift::Cluster
    Properties:
      MasterUsername: !Sub '{{resolve:secretsmanager:${MatKhauDB}::username}}'
      MasterUserPassword: !Sub '{{resolve:secretsmanager:${MatKhauDB}::password}}'

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Mật khẩu KHÔNG BAO GIỜ xuất hiện trong template | chỉ có tham chiếu | | Không ai — kể cả người tạo stack — biết mật khẩu | Secrets Manager sinh ra | | Xoay vòng được về sau | secret đã nằm sẵn trong Secrets Manager |

Và GenerateSecretString là chi tiết đáng chú ý: mật khẩu do dịch vụ sinh ngẫu nhiên, nên không có người nào từng nhìn thấy nó — mức bảo vệ cao hơn hẳn so với việc ai đó tự đặt rồi nhập vào.

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

  • D. Tạo secret với mật khẩu do Secrets Manager sinh, rồi dùng dynamic reference cho secret trong resource metadata như AWS::CloudFormation::Init — đây là phương án gần nhất và sai ở nơi đặt tham chiếu: dynamic reference KHÔNG được hỗ trợ trong metadata. AWS nêu rõ giới hạn này — và đặt bí mật vào metadata còn khiến nó hiện ra khi mô tả stack.
  • C. Tạo secret, rồi dùng dynamic reference với dấu gạch chéo ngược làm giá trị cuối; dấu gạch chéo sẽ được thay bằng thông tin đăng nhập — mô tả một cơ chế không tồn tại: không có cú pháp nào như vậy trong CloudFormation.
  • A. Tạo template RIÊNG cho tài nguyên CSDL với thông tin đăng nhập đã MÃ HOÁ trong template — vẫn là bí mật nằm trong template: dù mã hoá, nó vẫn được lưu trong mã nguồn và trong lịch sử Git. Và ai giải mã được thì có mật khẩu.

Ghi nhớ

Cú pháp dynamic reference của CloudFormation:

{{resolve:secretsmanager:ten-secret:SecretString:khoa-json:phien-ban}}
{{resolve:ssm:ten-tham-so:phien-ban}}
{{resolve:ssm-secure:ten-tham-so:phien-ban}}

Ba nguồn dynamic reference: | Nguồn | Dùng cho | |---|---| | secretsmanager | bí mật cần xoay vòng — mật khẩu CSDL, API key | | ssm | tham số thường (không bí mật) | | ssm-secure | tham số mã hoá (SecureString) |

Giới hạn quan trọng của dynamic reference: | Được dùng ở | Không được dùng ở | |---|---| | Resource properties | Metadata section | | Outputs (một số trường hợp) | Parameters | | | Conditions |

Dòng "Metadata" là điểm loại của phương án D.

Ba cách xử lý bí mật trong CloudFormation — theo mức an toàn: | Cách | An toàn | |---|---| | Secrets Manager + dynamic reference | cao nhất — bí mật do dịch vụ sinh | | NoEcho: true trên parameter | vừa — che trong Console nhưng vẫn truyền qua | | Hard-code trong template | thấp nhất — không bao giờ làm |

NoEcho đáng nói thêm: nó che giá trị trong Console và trong describe-stacks, nhưng giá trị vẫn được truyền vào lúc tạo stack — nên nó không tương đương với dynamic reference.

Và một lợi ích dài hạn của cách làm này: vì secret đã nằm trong Secrets Manager, bạn bật xoay vòng tự động được ngay:

  XoayVongMatKhau:
    Type: AWS::SecretsManager::RotationSchedule
    Properties:
      SecretId: !Ref MatKhauDB
      RotationRules:
        AutomaticallyAfterDays: 30

Với Redshift, Secrets Manager có managed rotation — không cần viết Lambda (khác với API bên thứ ba, xem thêm câu về xoay vòng token).

Câu 25 Security Logging and Monitoring

The security team at a retail company utilizes Amazon EventBridge to monitor Amazon S3 objects, aiming to detect public access and any other changes in S3 bucket policies/settings that result in public access. They configure EventBridge to watch specific CloudTrail API calls (s3:PutObjectAcl, s3:DeleteBucketPolicy, and s3:PutBucketPolicy) and use Amazon SNS for immediate email notifications.

However, during development, the team finds that s3:PutObjectAcl doesn't trigger an EventBridge event, while the other two do. CloudTrail for AWS management events is enabled with a basic configuration in the relevant region, and EventBridge pattern verification is correct.

The team needs a solution to ensure s3:PutObjectAcl triggers an EventBridge event without generating false notifications. What is the appropriate solution for this scenario?

  1. A

    Enable CloudTrail to monitor insights events for S3 buckets
  2. B

    Change the EventBridge event pattern by selecting Amazon S3. Select Data Events as the event type
  3. C

    Enable CloudTrail to monitor data events for read and write operations for S3 buckets
  4. D

    Change the EventBridge event pattern by selecting Amazon S3. Select All Events as the event type
Xem giải thích

Đáp án

C — Bật CloudTrail giám sát DATA EVENT cho thao tác đọc và ghi trên S3 bucket.

Vì sao đúng

Đề mô tả triệu chứng rất cụ thể: s3:DeleteBucketPolicy và s3:PutBucketPolicy kích hoạt được EventBridge, nhưng s3:PutObjectAcl thì không — dù event pattern đã được kiểm chứng đúng.

Nguyên nhân nằm ở phân loại sự kiện của CloudTrail: | Loại sự kiện | Ví dụ | Mặc định | |---|---|---| | Management event | PutBucketPolicy, DeleteBucketPolicy, CreateBucket | BẬT | | Data event | PutObjectAcl, GetObject, PutObject, DeleteObject | TẮT |

Khác biệt về bản chất:

Management event:  thao tác trên chính TÀI NGUYÊN (bucket)
                   → khối lượng thấp → miễn phí trong trail đầu tiên

Data event:        thao tác trên DỮ LIỆU BÊN TRONG (object)
                   → khối lượng RẤT LỚN → tính phí → tắt mặc định

Đề nói "CloudTrail for AWS management events is enabled with a basic configuration" — nên PutObjectAcl không được ghi lại, và EventBridge không có gì để khớp.

aws cloudtrail put-event-selectors   --trail-name trail-bao-mat   --event-selectors '[{
    "ReadWriteType": "All",
    "IncludeManagementEvents": true,
    "DataResources": [{
      "Type": "AWS::S3::Object",
      "Values": ["arn:aws:s3:::kho-du-lieu/"]}]}]'

Và vế "without generating false notifications" được đáp ứng: khi data event được ghi, event pattern hiện có (eventName = PutObjectAcl) khớp chính xác — không cần nới lỏng pattern.

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

  • D. Đổi event pattern bằng cách chọn Amazon S3 và chọn All Events làm event type — đây là phương án gần nhất và là bẫy chính của câu hỏi: nó không giải quyết nguyên nhân (sự kiện vẫn không được ghi), và nó tạo ra thông báo giả vì "All Events" khớp mọi sự kiện S3 — trái thẳng yêu cầu "without generating false notifications".
  • B. Đổi event pattern chọn Amazon S3 và chọn Data Events làm event type — gần đúng về ý tưởng nhưng nhầm chỗ cần sửa: vấn đề nằm ở CloudTrail không ghi, không phải ở EventBridge không khớp. Sửa pattern mà sự kiện không tồn tại thì vẫn không có gì để bắt.
  • A. Bật CloudTrail giám sát Insights events cho S3 bucket — sai loại sự kiện: CloudTrail Insights phát hiện hoạt động API bất thường về khối lượng (đột biến số lời gọi). Nó không ghi từng thao tác cụ thể.

Ghi nhớ

Ba loại sự kiện của CloudTrail — bảng cần thuộc: | Loại | Ghi gì | Mặc định | Chi phí | |---|---|---|---| | Management event | thao tác trên tài nguyên | BẬT | trail đầu tiên miễn phí | | Data event | thao tác trên DỮ LIỆU | TẮT | tính phí theo sự kiện | | Insights event | bất thường về khối lượng API | TẮT | tính phí |

Các data event hay dùng: | Dịch vụ | Data event | |---|---| | S3 | GetObject, PutObject, DeleteObject, PutObjectAcl | | Lambda | Invoke | | DynamoDB | PutItem, GetItem, Query | | S3 Express, EBS Direct API | các thao tác dữ liệu tương ứng |

Quy tắc phân biệt nhanh:

Thao tác trên chính tài nguyên (bucket, function, table) → management event. Thao tác trên nội dung bên trong (object, item, invoke) → data event.

Ba cân nhắc khi bật data event cho S3: | Cân nhắc | Chi tiết | |---|---| | Chi phí | bucket lưu lượng cao sinh hàng triệu sự kiện | | Giới hạn phạm vi | chỉ bật cho bucket cần giám sát, hoặc chỉ prefix cụ thể | | Chọn ReadWriteType | WriteOnly rẻ hơn nhiều nếu chỉ cần theo dõi thay đổi |

Dòng cuối là tối ưu đáng làm cho trường hợp này: đề chỉ quan tâm tới thay đổi quyền truy cập, nên ReadWriteType: WriteOnly là đủ và cắt được phần lớn khối lượng.

Ba cách phát hiện S3 bucket bị công khai — nên dùng nhiều lớp: | Cách | Đặc điểm | |---|---| | S3 Block Public Access | chặn từ đầu — lớp phòng thủ tốt nhất | | IAM Access Analyzer | phát hiện tài nguyên chia sẻ ra ngoài | | CloudTrail + EventBridge | phản ứng khi có thay đổi ← câu này | | AWS Config rule | đánh giá tuân thủ liên tục |

Dòng đầu đáng nhấn mạnh: bật Block Public Access ở mức tài khoản ngăn chặn vấn đề thay vì phát hiện sau — và nó nên là biện pháp đầu tiên, với giám sát làm lớp bổ sung.

Câu 26 Identity and Access Management

A company is planning to launch a mobile application for its business critical functions. Mobile users should have access to AWS resources without having to define an AWS identity for each of them. Guest user access is a necessity for the application.

As a Security Engineer, which of the following would you suggest as the most optimal way of configuring the security credentials for mobile users?

  1. A

    Use Access Control Lists (ACLs) with AWS SDKs for mobile development to create unique identities for the users
  2. B

    Create access keys for any IAM user belonging to the AWS account that holds the resources needed for the mobile application. Use these access keys to sign programmatic requests with AWS SDKs for mobile development
  3. C

    Use the AWS Security Token Service (AWS STS) to create and provide trusted users with temporary security credentials that can control access to your AWS resources
  4. D

    Use Amazon Cognito with AWS SDKs for mobile development to create unique identities for the users
Xem giải thích

Đáp án

D — Dùng Amazon Cognito để xác thực và cấp thông tin đăng nhập tạm thời, cho phép khách truy cập tài nguyên AWS.

Vì sao đúng

Đề nêu ba yêu cầu, và Cognito thoả cả ba: | Yêu cầu | Cơ chế | |---|---| | Ứng dụng di động | Cognito được thiết kế cho ứng dụng web và di động | | Người dùng chưa xác thực (guest) | Identity Pool có "unauthenticated identity" | | Truy cập tài nguyên AWS | cấp thông tin đăng nhập tạm thời qua STS |

Vế "unauthenticated access" là điểm mấu chốt — và Cognito Identity Pool là dịch vụ AWS duy nhất hỗ trợ trực tiếp:

Ứng dụng di động khởi động (chưa đăng nhập)
    ↓ GetId + GetCredentialsForIdentity
Cognito Identity Pool
    ↓ assume UNAUTHENTICATED ROLE
Thông tin đăng nhập tạm thời (giới hạn quyền)
    ↓
Đọc catalog sản phẩm từ S3 hoặc DynamoDB

Identity Pool có HAI role riêng biệt: | Role | Dành cho | Quyền điển hình | |---|---|---| | Unauthenticated role | khách chưa đăng nhập | chỉ đọc dữ liệu công khai | | Authenticated role | người đã đăng nhập | đọc và ghi dữ liệu cá nhân |

Đây đúng là mô hình mà đề mô tả: khách xem được sản phẩm, và sau khi đăng nhập thì làm được nhiều hơn.

Và Cognito loại bỏ nhu cầu nhúng thông tin đăng nhập vào ứng dụng — điều tối quan trọng với ứng dụng di động, vì mã ứng dụng di động có thể bị dịch ngược.

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

  • C. Dùng IAM role có Web Identity Federation để xác thực người dùng và cấp thông tin đăng nhập tạm thời — đây là phương án gần nhất và là cơ chế nền tảng mà Cognito dùng bên dưới, nhưng nó đòi một nhà cung cấp danh tính bên ngoài (Facebook, Google, Amazon) để xác thực trước. Nó không hỗ trợ truy cập ẨN DANH — mà đó chính là yêu cầu của đề.
  • A. Tạo IAM user cho từng người dùng và cấp quyền cần thiết — không mở rộng được: ứng dụng di động có thể có hàng triệu người dùng, còn IAM giới hạn 5.000 user mỗi tài khoản. Và không thể tạo IAM user cho "khách ẩn danh".
  • B. Dùng Amazon Inspector cấp thông tin đăng nhập tạm thời cho khách chưa xác thực — Inspector là dịch vụ quét lỗ hổng bảo mật, hoàn toàn không liên quan tới xác thực hay cấp thông tin đăng nhập.

Ghi nhớ

Hai thành phần của Amazon Cognito — hay bị nhầm với nhau: | Thành phần | Việc | |---|---| | User Pool | THƯ MỤC NGƯỜI DÙNG — đăng ký, đăng nhập, MFA, cấp JWT token | | Identity Pool (Federated Identities) | ĐỔI token lấy thông tin đăng nhập AWS tạm thời |

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

"Cần quản lý tài khoản người dùng (đăng ký, đăng nhập)?" → User Pool "Cần cho phép người dùng gọi API AWS trực tiếp?" → Identity Pool "Cần cả hai?" → User Pool làm IdP cho Identity Pool

Câu này cần Identity Pool vì yêu cầu là truy cập tài nguyên AWS, và cần chế độ unauthenticated.

Ba nguồn danh tính mà Identity Pool chấp nhận: | Nguồn | Chi tiết | |---|---| | Cognito User Pool | người dùng do bạn quản lý | | Nhà cung cấp mạng xã hội | Google, Facebook, Apple, Amazon | | SAML hoặc OIDC | doanh nghiệp | | Unauthenticated | khách — không cần nguồn nào ← câu này |

Ba thực hành khi dùng unauthenticated role: | Thực hành | Lý do | |---|---| | Quyền TỐI THIỂU tuyệt đối | bất kỳ ai trên Internet cũng lấy được role này | | Chỉ đọc, không ghi | tránh bị lạm dụng làm nơi lưu trữ miễn phí | | Giới hạn tài nguyên cụ thể | không dùng Resource: "*" |

Dòng đầu cần nhấn mạnh: unauthenticated role không có rào chắn nào — chỉ cần biết Identity Pool ID (thường nằm trong mã ứng dụng) là lấy được. Nên coi mọi quyền của nó là công khai.

Và một cơ chế hạn chế đáng biết: cognito-identity.amazonaws.com:amr trong trust policy phân biệt được hai loại phiên:

{"Condition": {"ForAnyValue:StringLike": {
   "cognito-identity.amazonaws.com:amr": "unauthenticated"}}}

Nó đảm bảo role dành cho khách không thể bị người đã xác thực assume, và ngược lại.

Câu 27 Chọn nhiều đáp án Management and Security Governance

A company uses Amazon EC2 instances (fronted by an Application Load Balancer) with Amazon RDS MySQL as the database. Now, the company wants to store sensitive client data and needs to follow strict security and compliance guidelines. Data must be end-to-end secured while in-transit, as well as, at-rest. The company needs a solution that can implement strict security guidelines while keeping the cost and operational overhead to a minimum.

Which combination of steps will meet all the requirements? (Select three)

  1. A

    Use TLS certificates from AWS Certificate Manager (ACM) with an Application Load Balancer. Deploy self-signed certificates on the EC2 instances
  2. B

    Ensure that the database client software uses a TLS connection to Amazon RDS. Enable encryption of the Amazon RDS DB instance
  3. C

    Use AWS CloudHSM to generate TLS certificates for the Amazon EC2 instances. Install the TLS certificates on the Amazon EC2 instances
  4. D

    Use Amazon CloudFront with AWS Web Application Firewall (AWS WAF). Send HTTP connections to the origin Amazon EC2 instances
  5. E

    Use TLS certificates from a third-party vendor with an Application Load Balancer. Configure the same certificates on the Amazon EC2 instances
  6. F

    Enable encryption on the Amazon Elastic Block Store (Amazon EBS) volumes that support the Amazon EC2 instances
Xem giải thích

Đáp án

A, B và F:

  • A — Cấu hình ALB chuyển hướng mọi lưu lượng HTTP sang HTTPS
  • B — Cấu hình EC2 instance chỉ chấp nhận lưu lượng HTTPS, cài chứng chỉ trên từng instance
  • F — Cấu hình volume EBS mã hoá cho các instance trong Auto Scaling group

Vì sao đúng

Đề yêu cầu bảo vệ dữ liệu cả khi truyền lẫn khi lưu, và ba phương án này phủ đúng ba chặng:

Người dùng
   ↓ ① A: HTTP → chuyển hướng sang HTTPS (mã hoá chặng ngoài)
ALB
   ↓ ② B: HTTPS tới EC2 (mã hoá chặng trong — end-to-end)
EC2 instance
   ↓ ③ F: EBS mã hoá (dữ liệu KHI LƯU)
Volume EBS

A — chuyển hướng HTTP sang HTTPS ở ALB: người dùng gõ http:// vẫn được đưa sang HTTPS thay vì truyền dữ liệu ở dạng rõ.

Listener HTTP :80  → Action: redirect to HTTPS :443, status 301
Listener HTTPS :443 → Action: forward to target group

B — mã hoá chặng ALB → EC2 là điểm phân biệt quan trọng:

Chỉ TLS termination ở ALB:
  Người dùng --HTTPS--> ALB --HTTP--> EC2
                              ^^^^ dạng RÕ trong VPC

End-to-end (đề yêu cầu):
  Người dùng --HTTPS--> ALB --HTTPS--> EC2

Đề nói "in transit" không giới hạn ở chặng ngoài — và với dữ liệu cá nhân nhạy cảm, mã hoá cả chặng nội bộ là thực hành đúng.

F — EBS mã hoá cho vế "at rest": dữ liệu ghi xuống volume, snapshot của nó, và dữ liệu truyền giữa instance với volume đều được mã hoá — trong suốt với ứng dụng, không cần sửa mã.

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

  • C. Cấu hình CloudFront với ALB làm origin và bắt buộc HTTPS — đây là phương án gần nhất và hữu ích trong thực tế (CDN, WAF, chống DDoS), nhưng nó thêm một tầng không cần thiết cho yêu cầu này và không giải quyết chặng ALB → EC2 lẫn vế at-rest.
  • D. Bật mã hoá phía máy chủ trên S3 cho dữ liệu người dùng — sai tầng lưu trữ: đề nói dữ liệu nằm trên EC2 với volume EBS, không phải S3.
  • E. Dùng AWS Certificate Manager cấp chứng chỉ cho CHÍNH EC2 instance — không làm được: ACM không xuất private key cho chứng chỉ công khai, nên không cài lên EC2 được. Chứng chỉ ACM chỉ dùng được với ALB, NLB, CloudFront, API Gateway. Muốn chứng chỉ trên EC2 thì dùng ACM Private CA hoặc chứng chỉ tự ký cho chặng nội bộ.

Ghi nhớ

Hai mặt của bảo vệ dữ liệu — luôn kiểm cả hai: | Mặt | Cơ chế trên AWS | |---|---| | In transit | TLS/HTTPS, VPN IPsec, mã hoá chặng nội bộ | | At rest | EBS encryption, S3 SSE, RDS encryption, KMS |

Ba mô hình xử lý TLS ở load balancer: | Mô hình | Chặng ngoài | Chặng trong | |---|---|---| | TLS termination | HTTPS | HTTP (dạng rõ) | | TLS end-to-end (re-encryption) | HTTPS | HTTPS ← câu này | | TLS passthrough (NLB) | HTTPS | HTTPS, LB không giải mã |

Dòng cuối đáng biết: NLB ở tầng 4 chuyển tiếp nguyên gói TLS, nên chứng chỉ nằm hẳn trên backend — đây là mô hình bắt buộc khi cần mutual TLS đầu-cuối.

Giới hạn của ACM — bảng cần thuộc: | Việc | ACM công khai | ACM Private CA | |---|---|---| | Cài lên ALB, NLB, CloudFront, API Gateway | ✅ | ✅ | | Xuất private key để cài lên EC2 | ❌ KHÔNG | ✅ được | | Tự gia hạn | ✅ | ✅ | | Chi phí | miễn phí | tính phí theo CA và chứng chỉ |

Dòng thứ hai là điểm loại của phương án E — và là một trong những giới hạn ACM bị hỏi nhiều nhất.

Ba đặc điểm của EBS encryption: | Đặc điểm | Chi tiết | |---|---| | Trong suốt với ứng dụng | không cần sửa mã, không ảnh hưởng hiệu năng đáng kể | | Mã hoá cả snapshot | và mọi volume tạo từ snapshot đó | | Bật mặc định ở mức tài khoản được | ec2:EnableEbsEncryptionByDefault |

Dòng cuối là thực hành nên áp dụng: bật mã hoá mặc định cho toàn Region đảm bảo không ai vô tình tạo volume không mã hoá — mạnh hơn việc dựa vào từng launch template nhớ bật.

Và một lưu ý về volume đã tồn tại: không mã hoá tại chỗ được. Quy trình là chụp snapshot → sao chép snapshot với mã hoá → tạo volume mới từ snapshot đã mã hoá — nên bật mã hoá từ đầu tiết kiệm rất nhiều công.

Câu 28 Data Protection

A business maintains its business-critical customer data on an on-premises system in an encrypted format. Over the years, the business has moved from using a single encryption key to multiple encryption keys by dividing the data into logical chunks. With the decision to move all data to the Amazon S3 bucket, the business is looking for a technique to encrypt each file with a different encryption key to provide maximum security to the migrated on-premises data.

How will you implement this requirement without adding the overhead of splitting the data into logical groups?

  1. A

    Use Multi-Region keys for client-side encryption in the AWS S3 Encryption Client to generate unique keys for each file of data
  2. B

    Store the logically divided data into different Amazon S3 buckets. Use server-side encryption with Amazon S3 managed keys (SSE-S3) to encrypt the data
  3. C

    Configure a single Amazon S3 bucket to hold all data. Use server-side encryption with AWS KMS (SSE-KMS) and use encryption context to generate a different key for each file/object that you store in the S3 bucket
  4. D

    Configure a single Amazon S3 bucket to hold all data. Use server-side encryption with Amazon S3 managed keys (SSE-S3) to encrypt the data
Xem giải thích

Đáp án

D — Dùng mã hoá phía máy chủ với khoá do Amazon S3 quản lý (SSE-S3).

Vì sao đúng

Đề nêu hai yêu cầu, và SSE-S3 thoả cả hai với công sức thấp nhất: | Yêu cầu | Cơ chế | |---|---| | Mỗi tệp mã hoá bằng khoá KHÁC NHAU | SSE-S3 sinh MỘT DATA KEY DUY NHẤT cho MỖI OBJECT | | Không phải chia dữ liệu thành nhóm logic | tự động, không cần phân nhóm gì |

Điểm mấu chốt mà nhiều người không biết: SSE-S3 vốn đã dùng khoá riêng cho từng object.

S3 nhận object
    ↓ sinh một data key NGẪU NHIÊN, DUY NHẤT cho object này
    ↓ mã hoá object bằng data key đó (AES-256)
    ↓ mã hoá data key bằng root key của S3
    ↓ lưu data key đã mã hoá cùng object

Đây là mã hoá phong bì (envelope encryption), và mỗi object có data key riêng — đúng yêu cầu "different encryption key for each file" mà không cần bạn làm gì cả.

Và vế "without the overhead of splitting data into logical groups" là gợi ý loại trừ: nó ám chỉ những phương án đòi bạn tổ chức dữ liệu theo nhóm để gán khoá khác nhau — cách làm tốn công mà SSE-S3 không cần.

So sánh công sức: | Cách | Việc phải làm | |---|---| | SSE-S3 | bật một lần, xong | | SSE-KMS với nhiều CMK | tạo và quản lý nhiều khoá, gán từng nhóm | | SSE-C | tự sinh, tự lưu, tự gửi khoá mỗi request |

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

  • C. Dùng SSE-KMS với ENCRYPTION CONTEXT trong lời gọi API để mã hoá và giải mã — đây là phương án gần nhất và hiểu sai vai trò của encryption context: nó là dữ liệu xác thực bổ sung (AAD) dùng để ràng buộc bản mã với ngữ cảnh, KHÔNG sinh ra khoá khác nhau. (SSE-KMS cũng sinh data key riêng cho từng object — nhưng encryption context không phải cơ chế tạo ra điều đó, và SSE-KMS tốn thêm chi phí lời gọi KMS.)
  • B. Dùng SSE-C (khoá do khách hàng cung cấp) và cấu hình S3 dùng khoá khác nhau cho mỗi tệp — đúng về mặt kỹ thuật nhưng công sức cực lớn: bạn phải tự sinh, tự lưu trữ an toàn, và gửi khoá theo TỪNG request. Mất khoá là mất dữ liệu vĩnh viễn. Trái thẳng yêu cầu "least effort".
  • A. Dùng mã hoá phía CLIENT với khoá do khách hàng cung cấp — công sức còn lớn hơn nữa: ứng dụng phải tự mã hoá trước khi tải lên và tự giải mã sau khi tải xuống, và tự quản lý toàn bộ vòng đời khoá.

Ghi nhớ

Bốn cách mã hoá dữ liệu trên S3 — theo công sức tăng dần: | Cách | Ai quản khoá | Khoá riêng mỗi object | Công sức | |---|---|---|---| | SSE-S3 | AWS hoàn toàn | ✅ tự động | thấp nhất | | SSE-KMS | bạn (qua KMS) | ✅ tự động | thấp, có kiểm toán | | SSE-C | bạn hoàn toàn | ✅ nếu bạn làm vậy | cao | | Client-side | bạn hoàn toàn | ✅ nếu bạn làm vậy | cao nhất |

Cột "khoá riêng mỗi object" là nội dung của câu hỏi — và hai dòng đầu đều đạt, nhưng SSE-S3 tốn ít công và chi phí nhất.

Cơ chế mã hoá phong bì — nền tảng của cả SSE-S3 lẫn SSE-KMS:

Data key (ngẫu nhiên, duy nhất mỗi object)
    → mã hoá DỮ LIỆU
Root key (KMS key hoặc khoá của S3)
    → mã hoá DATA KEY

Lợi ích: xoay vòng root key không cần mã hoá lại toàn bộ dữ liệu — chỉ cần mã hoá lại các data key.

Encryption context là gì và không phải gì: | Là | Không phải | |---|---| | Cặp khoá-giá trị dạng rõ, được xác thực | cơ chế sinh khoá | | Ghi vào CloudTrail — hữu ích cho kiểm toán | bí mật (nó KHÔNG được mã hoá) | | Dùng làm điều kiện trong key policy | thay thế cho quyền IAM |

Ví dụ dùng đúng:

{"Condition": {"StringEquals": {
   "kms:EncryptionContext:phong-ban": "ke-toan"}}}

Nó ràng buộc: chỉ giải mã được nếu request nêu đúng context — hữu ích cho phân tách theo bên thuê (tenant).

Khi nào chọn SSE-KMS thay vì SSE-S3: | Nhu cầu | Chọn | |---|---| | Cần kiểm toán từng lần dùng khoá | SSE-KMS (CloudTrail ghi mọi lời gọi) | | Cần kiểm soát ai giải mã được bằng key policy | SSE-KMS | | Cần tự xoay vòng khoá theo lịch của mình | SSE-KMS | | Chỉ cần "dữ liệu được mã hoá", đơn giản nhất | SSE-S3 ← câu này |

Và một tối ưu cho SSE-KMS khi có nhiều object: bật S3 Bucket Keys — giảm mạnh số lời gọi KMS và chi phí, mà không thay đổi mức bảo vệ.

Câu 29 Data Protection

The development team at a company accesses resources across all AWS Regions. The management wants only the security team to have access to resources from all AWS Regions. Any access to members of the development team needs to be restricted to the resources in a single AWS Region (us-west-2) except for the global AWS services. The development team is sized at 40 members, with all members being part of the developers IAM group. The company needs to implement this access restriction immediately.

What is the optimal way to meet this requirement?

  1. A

    Create an identity-based policy with the IAM aws:RequestedRegion condition key that denies access to all actions outside the specified Region, except for actions related to the global AWS services specified using NotAction. Attach the policy to the developers IAM group
  2. B

    Create an identity-based policy with the IAM aws:SourceIp that denies access to all actions outside the specified IP address range of the given AWS Region, except for actions related to the global AWS services. Attach the policy to the developers IAM group
  3. C

    Create an identity-based policy that allows adding and removing the IAM tag with the tag key Region from IAM entities. Restrict the access using the defined tags. Attach the policy to the developers IAM group
  4. D

    Create a Service control policy (SCP) that denies access to any operations outside of the specified AWS Regions. Apart from the Condition and Resource elements, configure the NotAction element to allow access to the needed AWS services only. Attach the policy to the developers IAM group
Xem giải thích

Đáp án

A — Dùng IAM policy có NotAction với điều kiện aws:RequestedRegion để từ chối truy cập vào tài nguyên ngoài các Region được duyệt.

Vì sao đúng

Đề yêu cầu: hạn chế tài nguyên chỉ ở các Region được duyệt, và cấu trúc Deny + NotAction + aws:RequestedRegion là cách chuẩn:

{
  "Effect": "Deny",
  "NotAction": [
    "iam:*", "organizations:*", "cloudfront:*",
    "route53:*", "support:*", "waf:*", "sts:*"
  ],
  "Resource": "*",
  "Condition": {
    "StringNotEquals": {
      "aws:RequestedRegion": ["ap-northeast-1", "ap-southeast-1"]
    }
  }
}

Vì sao cần NotAction chứ không phải Action: "*": | Loại dịch vụ | Vấn đề | |---|---| | Dịch vụ TOÀN CẦU | IAM, CloudFront, Route 53, Organizations | | Chúng hoạt động ở endpoint us-east-1 | nếu us-east-1 không nằm trong danh sách duyệt, chúng bị chặn |

Hậu quả nếu dùng Action: "*":

Deny mọi hành động ngoài ap-northeast-1
    → iam:CreateUser bị chặn (vì IAM ở us-east-1)
    → không quản lý được người dùng
    → có thể tự khoá chính mình ra khỏi tài khoản

NotAction giải quyết bằng cách chừa các dịch vụ toàn cầu ra: "từ chối mọi hành động NGOẠI TRỪ những cái liệt kê, khi Region không nằm trong danh sách duyệt".

Và aws:RequestedRegion là condition key đúng: nó chứa Region mà request nhắm tới, không phải Region mà người gọi đang đứng.

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

  • C. Dùng IAM policy có Action với điều kiện aws:RequestedRegion để từ chối truy cập — đây là phương án gần nhất và đúng ý tưởng nhưng thiếu ngoại lệ: với Action: "*", các dịch vụ toàn cầu bị chặn theo, gây hỏng vận hành như phân tích ở trên.
  • B. Dùng IAM policy có Action với điều kiện aws:PrincipalArn để từ chối truy cập — sai condition key: aws:PrincipalArn là ARN của người gọi, không liên quan gì tới Region.
  • D. Dùng IAM policy có NotAction với điều kiện aws:PrincipalArn để từ chối truy cập — cùng lỗi condition key như B.

Ghi nhớ

Action và NotAction — khác biệt và khi nào dùng: | Phần tử | Ý nghĩa | |---|---| | Action | áp dụng cho các hành động ĐƯỢC LIỆT KÊ | | NotAction | áp dụng cho MỌI hành động TRỪ những cái liệt kê |

Cùng cặp cho tài nguyên: Resource và NotResource.

Cảnh báo quan trọng về NotAction với Effect: Allow:

{"Effect": "Allow", "NotAction": "iam:*", "Resource": "*"}

Câu này cho phép mọi thứ trừ IAM — cực kỳ rộng, và mọi dịch vụ AWS mới ra đời cũng tự động được cho phép. NotAction an toàn với Deny, nguy hiểm với Allow.

Các dịch vụ toàn cầu cần chừa ra khi chặn theo Region: | Dịch vụ | Ghi chú | |---|---| | iam | bắt buộc chừa — nếu không sẽ mất khả năng quản lý quyền | | organizations | quản lý tổ chức | | cloudfront | CDN toàn cầu | | route53 | DNS toàn cầu | | sts | cần cho assume role | | support, waf, shield | dịch vụ toàn cầu khác |

Ba condition key toàn cục hay dùng: | Key | Chứa | |---|---| | aws:RequestedRegion | Region mà request nhắm tới | | aws:PrincipalArn | ARN của principal đang gọi | | aws:SourceIp | IP nguồn | | aws:PrincipalOrgID | ID tổ chức của principal | | aws:CurrentTime | thời điểm hiện tại |

Ba nơi áp ràng buộc Region — theo mức mạnh: | Nơi | Phạm vi | Ai bỏ được | |---|---|---| | SCP trong Organizations | toàn tài khoản/OU | không ai — kể cả root của tài khoản đó | | Permissions boundary | một IAM entity | admin của tài khoản | | IAM policy | một user/role | admin của tài khoản |

SCP là lựa chọn đúng cho chính sách toàn tổ chức — và ở đó, cấu trúc Deny + NotAction + aws:RequestedRegion cũng là mẫu chuẩn, dùng y hệt như trong IAM policy.

Và một lưu ý khi triển khai: kiểm tra trước bằng IAM Policy Simulator hoặc áp lên một OU thử nghiệm. Chính sách chặn Region sai có thể khiến cả đội mất quyền vận hành, và trong trường hợp xấu nhất là mất luôn khả năng sửa chính sách đó.

Câu 30 Chọn nhiều đáp án Data Protection

The security team at a company is working to create VPC endpoints so that the AWS Systems Manager can be used to manage private EC2 instances without internet access.

As an AWS Certified Security Specialist, which options will you combine to build a solution to meet the given requirements? (Select three)

  1. A

    Create an AWS Identity and Access Management (IAM) instance profile for Systems Manager. Attach the IAM role to the VPC endpoint policy
  2. B

    Create an AWS Identity and Access Management (IAM) instance profile for Systems Manager. Attach the IAM role to your private EC2 instance
  3. C

    Allow outbound internet access on your managed instances. The managed instances must be configured to also allow HTTPS (port 443) outbound traffic to the following endpoints: ssm.[region].amazonaws.com, ssmmessages.[region].amazonaws.com, ec2messages.[region].amazonaws.com
  4. D

    Create three virtual private cloud (VPC) endpoints for Systems Manager with service names: com.amazonaws.[region].ssm, com.amazonaws.[region].ec2messages, com.amazonaws.[region].ssmmessages
  5. E

    Create a virtual private cloud (VPC) endpoint for Systems Manager with service name com.amazonaws.[region].ssm
  6. F

    Verify that SSM Agent is installed on the instance
Xem giải thích

Đáp án

B, D và F:

  • B — Tạo VPC interface endpoint cho Systems Manager trong VPC của instance
  • D — Gắn instance profile có AmazonSSMManagedInstanceCore vào EC2 instance
  • F — Đảm bảo SSM Agent đang chạy trên instance

Vì sao đúng

Đề mô tả: instance trong private subnet, không có đường ra Internet, và cần dùng Session Manager để truy cập.

Session Manager cần ba điều kiện, và ba đáp án tương ứng đúng ba:

① Đường mạng tới dịch vụ SSM   → B: VPC interface endpoint
② Quyền IAM                     → D: instance profile
③ Phần mềm trên instance        → F: SSM Agent đang chạy

B — ba endpoint cần thiết (chi tiết mà nhiều người bỏ sót): | Endpoint | Việc | |---|---| | com.amazonaws.<region>.ssm | API chính của Systems Manager | | com.amazonaws.<region>.ssmmessages | BẮT BUỘC cho Session Manager — kênh dữ liệu phiên | | com.amazonaws.<region>.ec2messages | cho Run Command và các tính năng khác |

Endpoint ssmmessages là cái quan trọng nhất cho Session Manager — thiếu nó thì instance hiện là "managed" nhưng không mở được phiên.

D — quyền qua instance profile:

AmazonSSMManagedInstanceCore cấp:
  ssm:UpdateInstanceInformation, ssm:ListAssociations
  ssmmessages:CreateControlChannel, CreateDataChannel
  ssmmessages:OpenControlChannel, OpenDataChannel
  ec2messages:*

F — SSM Agent: cài sẵn trên Amazon Linux 2/2023, Ubuntu và Windows AMI gần đây, nhưng phải đang chạy.

Và điểm đáng nhấn mạnh: Session Manager KHÔNG cần cổng 22 mở, không cần key pair, không cần bastion host. Instance khởi tạo kết nối ra ngoài tới dịch vụ SSM — nên security group không cần rule inbound nào cả.

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

  • A. Đảm bảo instance có địa chỉ IP công khai — trái thẳng thiết kế: Session Manager tồn tại chính là để không cần IP công khai. Gán IP công khai cho instance trong private subnet còn làm tăng diện tích tấn công.
  • C. Cập nhật security group của instance cho phép lưu lượng vào từ dịch vụ SSM — hiểu sai chiều kết nối: SSM không kết nối VÀO instance. Chính instance (qua SSM Agent) kết nối RA tới dịch vụ. Security group chỉ cần cho phép outbound 443.
  • E. Cấu hình NAT gateway cho phép instance truy cập Internet — hoạt động được nhưng không phải cách đúng ở đây: nó cho instance đường ra Internet công cộng, trong khi VPC endpoint giữ toàn bộ lưu lượng trong mạng AWS. Với instance trong private subnet có yêu cầu bảo mật, endpoint là lựa chọn đúng.

Ghi nhớ

Ba yêu cầu để instance thành "managed instance" của Systems Manager:

① SSM Agent cài và ĐANG CHẠY
② IAM instance profile có quyền SSM
③ Đường mạng tới endpoint SSM (Internet HOẶC VPC endpoint)

Thiếu bất kỳ cái nào thì instance không hiện trong Fleet Manager — và đây là danh sách kiểm tra khi gỡ lỗi.

Ba endpoint SSM và tính năng phụ thuộc: | Endpoint | Cần cho | |---|---| | ssm | mọi tính năng — API chính | | ssmmessages | Session Manager | | ec2messages | Run Command, State Manager | | s3 (gateway) | nếu lưu log phiên vào S3 hoặc dùng patch từ S3 | | kms | nếu mã hoá phiên bằng KMS | | logs | nếu gửi log phiên tới CloudWatch Logs |

Ba dòng cuối hay bị bỏ sót khi bật ghi log phiên — phiên mở được nhưng log không ghi được, và lỗi khá khó lần.

Lợi ích của Session Manager so với SSH bastion: | Lợi ích | Chi tiết | |---|---| | Không cần mở cổng inbound | security group không có rule vào nào | | Không cần quản lý SSH key | không có key để mất hay xoay vòng | | Không cần bastion host | bớt một máy phải vá và giám sát | | Kiểm toán đầy đủ | CloudTrail ghi ai mở phiên, log ghi cả nội dung phiên | | Kiểm soát bằng IAM | phân quyền theo tag của instance |

Dòng thứ tư là giá trị lớn nhất về mặt tuân thủ: bật session logging ghi lại toàn bộ lệnh gõ trong phiên vào S3 hoặc CloudWatch Logs — điều mà SSH truyền thống rất khó làm.

Và một cấu hình đáng bật cho môi trường nhạy cảm: mã hoá phiên bằng KMS. Nó bảo vệ dữ liệu phiên ngay cả trong mạng AWS, và ràng buộc thêm một lớp quyền (kms:Decrypt) cho người mở phiên.