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

Tìm thấy 1221 câu.

Câu 201 Domain - Design for New Solutions

An enterprise has several development and production AWS accounts managed under its AWS Organization. Consolidated billing is enabled in the organization but the management wants more visibility on the AWS Billing and Cost Management. With the sudden increase in the Amazon RDS and Amazon DynamoDB costs, the management required all CloudFormation templates to enforce a consistent tagging with cost center numbers and project ID numbers on all resources that will be provisioned. The management also wants these tags to be enforced in all existing and future DynamoDB and RDS instances.

Which of the following options is the recommended strategy to meet the company requirements?

A
On the Billing and Cost Management page, create new cost allocation tags for the cost center and project ID. Wait for at least 24 hours to allow AWS to propagate the tags and gather cost reports. Update existing federated roles to deny users from creating resources that do not have the cost center and project ID tags.
B
Create an AWS Config rule to check for any untagged resource and send a notification email to the finance team. Write a Lambda function that has a cross-account role to tag all RDS databases and DynamoDB resources on all accounts under the organization. Schedule this function to run every hour.
C
Tag all existing resources in bulk using the Tag Editor. On the Billing and Cost Management page, create new cost allocation tags for the cost center and project ID. Apply an SCP on the organizational unit that denies users from creating resources that do not have the cost center and project ID tags.
D
Tag all existing resources in bulk using the Tag Editor. On the Billing and Cost Management page, create new cost allocation tags for the cost center and project ID. Wait for at least 24 hours to allow AWS to propagate the tags and gather cost reports.

Xem giải thích

Đáp án

**C — Gắn tag hàng loạt cho tài nguyên đã có bằng Tag Editor; tạo cost allocation tag cho trung tâm chi phí và mã dự án trong trang Billing; và áp SCP trên đơn vị tổ chức để từ chối việc tạo tài nguyên thiếu hai tag đó.

Vì sao đúng

Đề nêu ba yêu cầu, và phương án này khớp từng cái: | Yêu cầu | Cách đáp ứng | |---|---| | Tag trên tài nguyên ĐANG CÓ | Tag Editor gắn hàng loạt | | Thấy chi phí theo tag | cost allocation tag | | Bắt buộc tag cho tài nguyên TƯƠNG LAI | SCP |

⚠ SCP là thứ duy nhất trong bốn phương án BẮT BUỘC được:

Config: phát hiện SAU khi tạo
    → tài nguyên đã tồn tại thiếu tag
        ↓
    Cost allocation tag: chỉ để
      gộp báo cáo
    → không chặn ai cả
        ↓
    SCP: CHẶN ngay lúc gọi API
    → không có tài nguyên nào
      thiếu tag ra đời

SCP bắt buộc tag khi tạo:

{"Version": "2012-10-17", "Statement": [{
  "Effect": "Deny",
  "Action": ["rds:CreateDBInstance",
             "rds:CreateDBCluster",
             "dynamodb:CreateTable"],
  "Resource": "*",
  "Condition": {"Null": {
    "aws:RequestTag/TrungTamChiPhi": "true"}}},
  {"Effect": "Deny",
   "Action": ["rds:CreateDBInstance",
              "rds:CreateDBCluster",
              "dynamodb:CreateTable"],
   "Resource": "*",
   "Condition": {"Null": {
     "aws:RequestTag/MaDuAn": "true"}}}]}

⚠ Null với giá trị true nghĩa là "khoá này KHÔNG tồn tại":

`"Null": {"aws:RequestTag/X": "true"}`
    → khớp khi request KHÔNG có tag X
        ↓
    Kết hợp với `Deny`
    → chặn mọi request thiếu tag đó

⚠ Và SCP áp cho MỌI principal, kể cả quản trị viên tài khoản:

IAM policy: quản trị viên tự gỡ được
    → hoặc gán chính sách rộng hơn
        ↓
    SCP: chỉ tài khoản quản lý sửa được
    → không ai trong tài khoản con
      vượt qua được

Gắn tag hàng loạt cho tài nguyên cũ:

aws resourcegroupstaggingapi tag-resources \
  --resource-arn-list \
    arn:aws:rds:ap-southeast-1:111122223333:db:csdl-01 \
    arn:aws:dynamodb:ap-southeast-1:111122223333:table/DonHang \
  --tags TrungTamChiPhi=CC-1234,MaDuAn=DA-5678

Tìm tài nguyên còn thiếu tag:

aws resourcegroupstaggingapi get-resources \
  --resource-type-filters rds dynamodb \
  --tag-filters Key=TrungTamChiPhi \
  --query 'ResourceTagMappingList[].ResourceARN'

⚠ Kích hoạt cost allocation tag phải làm ở TÀI KHOẢN QUẢN LÝ:

aws ce update-cost-allocation-tags-status \
  --cost-allocation-tags-status \
    TagKey=TrungTamChiPhi,Status=Active \
    TagKey=MaDuAn,Status=Active

Tài khoản thành viên KHÔNG kích hoạt được
    → đây là lý do phương án nói
      "bật ở tài khoản thành viên" là sai

⚠ Và tag không áp ngược cho chi phí quá khứ:

Kích hoạt hôm nay
    → báo cáo tháng trước vẫn không
      có tag đó
        ↓
    Mất tới 24 giờ mới xuất hiện
    → kích hoạt sớm, kể cả khi
      chưa dùng tới

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Tài nguyên cũ được gắn tag ngay | | | Tài nguyên mới không thể thiếu tag | | | Báo cáo chi phí quy được về đúng dự án | |

⚠ Nhưng SCP quá chặt có thể chặn cả dịch vụ AWS:

Auto Scaling tạo instance thay thế
    → không gắn tag của bạn
        ↓
    Bị SCP chặn
    → ASG không mở rộng được
        ↓
    Chừa ngoại lệ cho service-linked role
      hoặc dùng launch template có tag sẵn

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

**D. Gắn tag hàng loạt bằng Tag Editor, tạo cost allocation tag, và chờ 24 giờ để AWS lan truyền — đây là phương án gần nhất và hai bước đầu hoàn toàn đúng, nhưng nó thiếu cơ chế bắt buộc cho tài nguyên tương lai; đề nói rõ "tất cả template CloudFormation phải áp tag nhất quán".
**A. Tạo cost allocation tag, chờ 24 giờ, và sửa vai trò liên kết để từ chối tạo tài nguyên thiếu tag — sửa từng vai trò không phủ được mọi đường tạo tài nguyên, và không xử lý tài nguyên đã có.
**B. Dùng Config rule phát hiện tài nguyên thiếu tag và Lambda chạy mỗi giờ gắn tag xuyên tài khoản — đây là phát hiện và sửa sau, phải tự viết và bảo trì; và có khoảng thời gian tài nguyên tồn tại không có tag.

Ghi nhớ

⚠ Ba tầng quản lý tag — bảng phải thuộc: | Tầng | Công cụ | Thời điểm | |---|---|---| | Bắt buộc | SCP, IAM policy | chặn lúc tạo | | Gắn tự động | CloudFormation, Service Catalog | ngay lúc tạo | | Phát hiện và sửa | Config, Tag Editor | sau khi tạo |

Từ khoá nhận diện:

"enforce tags on existing and future resources" → Tag Editor + SCP "see cost by tag" → cost allocation tag ở tài khoản quản lý "standardise tag keys and values" → tag policy của Organizations "apply tags automatically" → CloudFormation, Service Catalog

⚠ Ba khoá điều kiện về tag — phải phân biệt: | Khoá | Dùng khi | |---|---| | aws:RequestTag/Khoa | tag trong request đang tạo | | aws:ResourceTag/Khoa | tag đã có trên tài nguyên | | aws:TagKeys | danh sách khoá tag trong request |

⚠ Chặn sửa tag cũng quan trọng không kém:

{"Effect": "Deny",
 "Action": ["rds:RemoveTagsFromResource",
            "dynamodb:UntagResource"],
 "Resource": "*",
 "Condition": {"ForAnyValue:StringEquals":
   {"aws:TagKeys": ["TrungTamChiPhi", "MaDuAn"]}}}

Bắt buộc gắn tag lúc tạo
    → nhưng ai đó gỡ tag sau đó
        ↓
    Báo cáo chi phí lại thiếu
    → phải chặn cả việc gỡ tag

Ba lưu ý về tag policy: | Lưu ý | Chi tiết | |---|---| | Chuẩn hoá tên khoá: CostCenter không phải costcenter | | | Giới hạn danh sách giá trị hợp lệ | | | enforced_for chặn thao tác không tuân thủ | |

⚠ Tag policy giải quyết vấn đề SCP không giải quyết:

SCP: bắt buộc CÓ tag
    → giá trị gì cũng được
        ↓
    Tag policy: chuẩn hoá tên khoá
      và giá trị
    → báo cáo chi phí mới gộp đúng

Ba lưu ý về Cost Explorer: | Lưu ý | Chi tiết | |---|---| | Nhóm chi phí theo tag đã kích hoạt | | | Cost Categories gộp nhiều tag thành nhóm | | | Budgets cảnh báo theo từng tag | |

Ba lưu ý về AWS Budgets: | Lưu ý | Chi tiết | |---|---| | Đặt ngân sách theo trung tâm chi phí | | | Budgets Actions tự áp chính sách khi vượt | | | Cảnh báo trước khi vượt, không phải sau | |

Ba lưu ý về SCP: | Lưu ý | Chi tiết | |---|---| | Không áp cho tài khoản quản lý | | | Không áp cho service-linked role | | | Thử ở một OU nhỏ trước khi áp toàn tổ chức | |

⚠ Áp SCP toàn tổ chức mà chưa thử là rủi ro lớn:

SCP chặn nhầm một thao tác thiết yếu
    → mọi tài khoản cùng hỏng
        ↓
    Thử ở OU sandbox trước
    → và luôn có đường gỡ từ tài khoản
      quản lý

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Thử tạo RDS không có tag — phải bị từ chối | | | Dùng Tag Editor tìm tài nguyên còn thiếu tag | | | Kiểm báo cáo chi phí có phân theo tag không | |

Và một lời khuyên: hãy kích hoạt cost allocation tag ngay cả trước khi bạn cần dùng tới nó. Nó không áp ngược cho chi phí quá khứ — và ngày bạn được yêu cầu giải trình chi tiêu ba tháng trước là ngày quá muộn để bật nó.

Câu 202 Chọn nhiều đáp án Domain - Accelerate Workload Migration and Modernization

A company runs its legacy web application in its on-premises data center. The solutions architect has been tasked to move the legacy web application in a virtual machine running inside the data center to the Amazon VPC. However, this application requires a private and dedicated connection to a number of servers hosted on the on-premises network in order for it to work.

Which combination of options provides the most suitable way to configure the web application running inside the VPC to reach back and access its internal dependencies on the company’s on-premises network? (Select TWO.)

A An Internet Gateway to allow a VPN connection.
B An AWS Direct Connect link between the VPC and the network housing the internal services.
C A network device in your data center that supports Border Gateway Protocol (BGP) and BGP MD5 authentication.
D
Set up a Transit VPC between your on-premises data center and your VPC.
E An Elastic IP address on the VPC instance.

Xem giải thích

Đáp án

**B và C — Dựng kết nối AWS Direct Connect giữa VPC và mạng chứa các dịch vụ nội bộ; và có một thiết bị mạng tại trung tâm dữ liệu hỗ trợ BGP cùng xác thực BGP MD5.

Vì sao đúng

Đề nêu hai yêu cầu, và hai đáp án chính là hai điều kiện của cùng một giải pháp: | Yêu cầu | Cách đáp ứng | |---|---| | Kết nối riêng và chuyên dụng | Direct Connect | | Ứng dụng trong VPC gọi ngược về dịch vụ tại chỗ | định tuyến qua BGP |

⚠ BGP là điều kiện BẮT BUỘC của Direct Connect, không phải tuỳ chọn:

Direct Connect trao đổi tuyến bằng BGP
    → thiết bị phía khách hàng PHẢI
      nói BGP
        ↓
    Không có BGP: không dựng được
      virtual interface nào

⚠ Và BGP MD5 là cơ chế xác thực phiên BGP:

Phiên BGP không xác thực
    → ai chen vào đường truyền cũng
      quảng bá tuyến giả được
        ↓
    MD5: hai bên chia sẻ một khoá
    → gói BGP không có chữ ký đúng
      bị bỏ

Yêu cầu kỹ thuật của thiết bị khách hàng: | Yêu cầu | Chi tiết | |---|---| | Kết nối quang single-mode | 1G, 10G hoặc 100G | | VLAN 802.1Q | mỗi virtual interface một VLAN | | BGP và BGP MD5 | bắt buộc | | Auto-negotiation TẮT | với cổng 1G trở lên |

Tạo private virtual interface:

aws directconnect create-private-virtual-interface \
  --connection-id dxcon-abc \
  --new-private-virtual-interface '{
    "virtualInterfaceName":"vif-ung-dung",
    "vlan":101,
    "asn":65000,
    "authKey":"<khoa-md5>",
    "virtualGatewayId":"vgw-abc",
    "addressFamily":"ipv4"}'

⚠ Ba loại virtual interface — chọn đúng loại: | Loại | Tới đâu | |---|---| | Private VIF | VPC qua VGW hoặc Direct Connect Gateway | | Public VIF | dịch vụ công khai của AWS (S3, DynamoDB) | | Transit VIF | Transit Gateway |

Đề nói ứng dụng trong VPC gọi về
  dịch vụ nội bộ
    → private VIF

⚠ Và Internet Gateway KHÔNG dùng cho VPN — đây là lỗi của phương án A:

Site-to-Site VPN dùng
  Virtual Private Gateway
        ↓
    Internet Gateway là cho lưu lượng
      công khai đi ra
    → hai thứ hoàn toàn khác nhau

Bật lan truyền tuyến từ VGW:

aws ec2 enable-vgw-route-propagation \
  --route-table-id rtb-abc --gateway-id vgw-abc

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Băng thông cam kết và độ trễ ổn định | | | Lưu lượng không đi qua Internet công cộng | | | Chi phí truyền dữ liệu thấp hơn qua Internet | |

⚠ Nhưng một kết nối Direct Connect vẫn là MỘT điểm hỏng:

Cáp đứt hoặc thiết bị hỏng
    → mất kết nối hoàn toàn
        ↓
    Mẫu chuẩn: DX làm đường chính
      + VPN làm đường dự phòng
    → BGP tự chuyển khi DX đứt

⚠ Và thời gian cung cấp DX tính bằng tuần tới tháng:

Cần kết nối gấp
    → dựng VPN trước (vài giờ)
        ↓
    Rồi chuyển sang DX khi cáp
      được kéo xong

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

**D. Dựng Transit VPC giữa trung tâm dữ liệu và VPC — đây là phương án gần nhất và Transit VPC là kiến trúc có thật, nhưng nó là mẫu trước khi có Transit Gateway: phải tự vận hành đội router ảo, và nó không cung cấp "kết nối riêng và chuyên dụng" như đề yêu cầu.
**A. Dùng Internet Gateway để cho phép kết nối VPN — VPN dùng Virtual Private Gateway; Internet Gateway là thành phần khác hoàn toàn.
**E. Gán Elastic IP cho instance trong VPC — Elastic IP là địa chỉ công khai; nó không tạo ra kết nối riêng nào tới mạng tại chỗ.

Ghi nhớ

⚠ Bốn cách kết nối lai — bảng phải thuộc: | Cách | Đường đi | Thời gian dựng | |---|---|---| | Site-to-Site VPN | qua Internet, mã hoá | vài giờ | | Direct Connect | đường riêng | tuần tới tháng | | DX + VPN | DX chính, VPN dự phòng | theo DX | | Transit Gateway | hub cho nhiều VPC | vài phút |

Từ khoá nhận diện:

"private and dedicated connection" → Direct Connect "BGP required" → thiết bị khách hàng phải hỗ trợ BGP "cost-effective, quick to set up" → Site-to-Site VPN "many VPCs to on-premises" → Transit Gateway + Transit VIF

Ba lưu ý về Direct Connect: | Lưu ý | Chi tiết | |---|---| | Một kết nối là một điểm hỏng | | | Hai kết nối ở hai vị trí cho HA cao nhất | | | LAG gộp nhiều kết nối thành một | |

⚠ Bốn mức dự phòng của Direct Connect: | Mức | Cấu hình | |---|---| | Phát triển | một kết nối | | Sản xuất tối thiểu | DX + VPN dự phòng | | Cao | hai DX ở một vị trí | | Tối đa | hai DX ở hai vị trí khác nhau |

Ba lưu ý về BGP: | Lưu ý | Chi tiết | |---|---| | Cần ASN cho phía khách hàng (public hoặc private) | | | MD5 xác thực phiên BGP | | | AS path prepending điều khiển đường ưu tiên | |

⚠ Điều khiển đường ưu tiên khi có cả DX và VPN:

BGP mặc định ưu tiên DX hơn VPN
    → AWS coi DX có độ ưu tiên cao hơn
        ↓
    Muốn đổi: dùng AS path prepending
      hoặc quảng bá tiền tố cụ thể hơn

Ba lưu ý về Direct Connect Gateway: | Lưu ý | Chi tiết | |---|---| | Nối một DX tới nhiều VPC ở nhiều Region | | | Miễn phí, chỉ trả tiền DX và truyền dữ liệu | | | VPC không nói chuyện với nhau qua DXGW | |

⚠ Điểm cuối là hạn chế phải nhớ:

Hai VPC cùng gắn vào DXGW
    → cả hai tới được trung tâm dữ liệu
        ↓
    Nhưng KHÔNG nói chuyện được
      với nhau qua đó
    → cần peering hoặc Transit Gateway

Ba lưu ý về hosted connection: | Lưu ý | Chi tiết | |---|---| | Đối tác chia nhỏ băng thông từ 50 Mbps | | | Nhanh hơn xin kết nối chuyên dụng | | | Hợp khi không cần cả 1 Gbps | |

Ba lưu ý về mã hoá: | Lưu ý | Chi tiết | |---|---| | DX KHÔNG mã hoá theo mặc định | | | Chạy VPN qua DX nếu cần mã hoá | | | Hoặc MACsec với kết nối chuyên dụng | |

⚠ Đây là hiểu nhầm phổ biến về Direct Connect:

"Đường riêng nên an toàn"
    → riêng về mặt định tuyến
    → nhưng dữ liệu ở dạng RÕ
        ↓
    Yêu cầu tuân thủ đòi mã hoá
    → phải thêm IPsec hoặc MACsec

Ba lưu ý về giám sát: | Chỉ số | Ý nghĩa | |---|---| | ConnectionState | kết nối lên hay xuống | | ConnectionBpsEgress/Ingress | băng thông đang dùng | | ConnectionErrorCount | lỗi tầng vật lý |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kiểm phiên BGP đã lên | | | Xem tuyến đã lan truyền vào bảng định tuyến | | | Ngắt DX thử, xem VPN có tiếp quản | |

Và một lời khuyên: hãy dựng VPN dự phòng ngay khi Direct Connect đi vào hoạt động. DX cho băng thông và độ trễ mà VPN không có, nhưng nó vẫn là một sợi cáp — và một sợi cáp bị máy xúc cắt đứt là kịch bản xảy ra thường xuyên hơn người ta tưởng.

Câu 203 Domain - Continuous Improvement for Existing Solutions

A company wants to migrate its on-premises application to the AWS cloud. Due to limited manpower, the company wants to utilize fully managed AWS services as much as possible. This way, there will be less maintenance work after the migration. The application processes large files containing sensitive information so the company has the following requirements:

- Data encryption at rest and in transit are both required on all files that will be processed by the application.

- The storage solution must be highly durable and available.

- The company must be able to use its own encryption key and then periodically rotated for improved security.

- Amazon Redshift Spectrum will be used to analyze the migrated data.

Which of the following should the Solutions Architect implement to achieve these requirements?

A
Store the data files on an Amazon DynamoDB table. Leverage on the default SSL connection settings of the DynamoDB table. Use AWS KMS to encrypt the table and enable automatic key rotation.
B
Create an Amazon S3 bucket to store all data. Enable server-side encryption with AWS KMS (SSE-KMS). Apply a bucket policy that enforces HTTPS only connections to the S3 bucket.
C
Provision an AWS Storage Gateway – File Gateway device in the on-premises data center. Enable encryption on the file share with AWS KMS. The data will be transferred securely to an Amazon S3 bucket with SSE-S3 encryption.
D
Store the data files in an Amazon EC2 instance with an encrypted EBS volume. Use AWS KMS to encrypt the EBS volume and enable automatic key rotation.

Xem giải thích

Đáp án

**B — Tạo bucket S3 lưu toàn bộ dữ liệu, bật mã hoá phía máy chủ bằng AWS KMS (SSE-KMS), và áp bucket policy bắt buộc mọi kết nối phải dùng HTTPS.

Vì sao đúng

Đề nêu bốn yêu cầu, và phương án này khớp từng cái: | Yêu cầu | Cách đáp ứng | |---|---| | Mã hoá khi lưu và khi truyền | SSE-KMS + bucket policy HTTPS-only | | Bền vững và sẵn sàng cao | S3: 11 số 9 độ bền | | Dùng khoá riêng, xoay định kỳ | khoá KMS do khách hàng quản lý, xoay tự động | | Redshift Spectrum sẽ phân tích dữ liệu | Spectrum CHỈ đọc từ S3 |

⚠ Yêu cầu cuối cùng loại bỏ mọi phương án khác:

Redshift Spectrum truy vấn dữ liệu
  nằm trên S3
        ↓
    Nó KHÔNG đọc được từ DynamoDB,
      EBS hay file share
        ↓
    Dữ liệu bắt buộc phải ở S3

Bật SSE-KMS với khoá riêng:

aws s3api put-bucket-encryption --bucket du-lieu-lon \
  --server-side-encryption-configuration '{
    "Rules": [{"ApplyServerSideEncryptionByDefault":
      {"SSEAlgorithm": "aws:kms",
       "KMSMasterKeyID": "<arn-khoa-cua-ban>"},
      "BucketKeyEnabled": true}]}'

⚠ Bật xoay khoá tự động:

aws kms enable-key-rotation --key-id <id-khoa>

KMS sinh vật liệu khoá mới mỗi năm
    → dữ liệu cũ vẫn giải mã được
      bằng vật liệu cũ
        ↓
    KMS giữ mọi phiên bản
    → xoay không phải mã hoá lại
      dữ liệu

Bắt buộc HTTPS bằng bucket policy:

{"Version": "2012-10-17", "Statement": [{
  "Effect": "Deny", "Principal": "*",
  "Action": "s3:*",
  "Resource": ["arn:aws:s3:::du-lieu-lon",
               "arn:aws:s3:::du-lieu-lon/*"],
  "Condition": {"Bool": {"aws:SecureTransport": "false"}}}]}

⚠ Phải liệt kê CẢ HAI ARN — bucket và object:

Chỉ có `bucket/*`
    → thao tác trên chính bucket
      (ListBucket) vẫn qua HTTP được
        ↓
    Liệt kê cả hai mới phủ hết

⚠ Và bắt buộc mã hoá đúng loại:

{"Effect": "Deny", "Principal": "*",
 "Action": "s3:PutObject",
 "Resource": "arn:aws:s3:::du-lieu-lon/*",
 "Condition": {"StringNotEquals":
   {"s3:x-amz-server-side-encryption": "aws:kms"}}}

⚠ S3 Bucket Key giảm mạnh chi phí KMS:

Mỗi object gọi KMS một lần
    → tệp lớn với hàng triệu object
    → chi phí KMS đáng kể
        ↓
    Bucket Key: một khoá cấp bucket
    → giảm tới 99% lời gọi KMS

Redshift Spectrum truy vấn thẳng S3:

CREATE EXTERNAL SCHEMA du_lieu_ngoai
FROM DATA CATALOG DATABASE 'catalog_du_lieu'
IAM_ROLE 'arn:aws:iam::111122223333:role/VaiTroSpectrum';

SELECT ngay, SUM(gia_tri)
FROM du_lieu_ngoai.giao_dich
WHERE nam = 2026 GROUP BY ngay;

⚠ Vai trò Spectrum cần quyền KMS:

{"Effect": "Allow",
 "Action": ["s3:GetObject", "s3:ListBucket",
            "kms:Decrypt"],
 "Resource": ["arn:aws:s3:::du-lieu-lon/*",
              "arn:aws:s3:::du-lieu-lon",
              "<arn-khoa-kms>"]}

Thiếu quyền `kms:Decrypt`
    → Spectrum đọc được danh sách tệp
    → nhưng truy vấn thất bại
    → lỗi khó hiểu vì bucket policy
      trông đã đúng

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | S3 rẻ nhất cho tệp lớn | | | Redshift Spectrum truy vấn trực tiếp | | | KMS lo xoay khoá, không phải tự làm | |

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

**C. Dựng Storage Gateway File Gateway tại chỗ, bật mã hoá file share bằng KMS, dữ liệu chuyển sang S3 với SSE-S3 — đây là phương án gần nhất và dữ liệu vẫn kết thúc ở S3, nhưng SSE-S3 dùng khoá của AWS chứ không phải khoá riêng của công ty; đề đòi "dùng khoá của chính mình và xoay định kỳ".
**A. Lưu tệp trong bảng DynamoDB — DynamoDB là CSDL khoá-giá trị với giới hạn 400 KB mỗi mục, không lưu được tệp lớn; và Redshift Spectrum không đọc được DynamoDB.
**D. Lưu trên EBS volume mã hoá gắn vào EC2 — EBS gắn vào một instance, không phải giải pháp lưu trữ chung; và Spectrum không đọc được EBS.

Ghi nhớ

⚠ Ba loại mã hoá phía máy chủ của S3 — bảng phải thuộc: | Loại | Ai giữ khoá | Xoay tự động | |---|---|---| | SSE-S3 | AWS hoàn toàn | AWS lo, không kiểm soát được | | SSE-KMS | KMS, bạn đặt chính sách | CÓ, bật được | | SSE-C | BẠN gửi mỗi request | tự làm |

Đề nói "dùng khoá của chính công ty
  và xoay định kỳ"
        ↓
    SSE-KMS với khoá do khách hàng
      quản lý

Từ khoá nhận diện:

"Redshift Spectrum will analyse the data" → dữ liệu phải ở S3 "own key, rotated periodically" → SSE-KMS customer managed key "encryption in transit" → bucket policy aws:SecureTransport "highly durable and available" → S3

⚠ Ba dịch vụ truy vấn dữ liệu trên S3: | Dịch vụ | Đặc điểm | |---|---| | Athena | serverless, trả theo dữ liệu quét | | Redshift Spectrum | cần cụm Redshift, gộp được với bảng nội bộ | | S3 Select | lọc trong MỘT object |

Ba lưu ý về khoá KMS: | Lưu ý | Chi tiết | |---|---| | Khoá do AWS quản lý: không xoay theo ý bạn | | | Khoá do khách hàng quản lý: kiểm soát đầy đủ | | | Key policy quyết định ai giải mã | |

⚠ Xoay khoá KMS không mã hoá lại dữ liệu cũ:

Xoay: sinh vật liệu khoá mới
    → dữ liệu mới dùng vật liệu mới
        ↓
    Dữ liệu cũ vẫn giải mã bằng
      vật liệu cũ
    → KMS giữ mọi phiên bản
    → trong suốt với ứng dụng

Ba lưu ý về định dạng dữ liệu cho Spectrum: | Lưu ý | Chi tiết | |---|---| | Parquet hoặc ORC nhanh hơn CSV nhiều lần | | | Phân vùng theo cột hay lọc | | | Nén giảm dữ liệu quét | |

⚠ Phân vùng là yếu tố giảm chi phí lớn nhất:

s3://du-lieu/nam=2026/thang=08/ngay=31/
        ↓
    Truy vấn một ngày chỉ quét
      thư mục đó
    → thay vì quét cả năm
    → Spectrum tính phí theo dữ liệu quét

Ba lưu ý về Glue Data Catalog: | Lưu ý | Chi tiết | |---|---| | Spectrum dùng catalog để biết schema | | | Crawler tự phát hiện schema và phân vùng | | | Chia sẻ catalog với Athena và EMR | |

Ba lưu ý về bảo mật S3: | Lưu ý | Chi tiết | |---|---| | Bật Block Public Access | | | Bật versioning cho dữ liệu quan trọng | | | Bật CloudTrail data event nếu cần kiểm toán | |

Ba lưu ý về chi phí: | Lưu ý | Chi tiết | |---|---| | Bật Bucket Key giảm chi phí KMS | | | Lifecycle chuyển dữ liệu cũ sang lớp rẻ | | | Nhưng Spectrum không đọc được Glacier | |

⚠ Điểm cuối là bẫy khi tối ưu chi phí:

Chuyển dữ liệu cũ sang Glacier
    → tiết kiệm lưu trữ
        ↓
    Nhưng Spectrum và Athena
      KHÔNG truy vấn được
    → phải khôi phục trước
        ↓
    Glacier Instant Retrieval thì được

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Thử tải lên qua HTTP — phải bị từ chối | | | Thử tải lên không mã hoá — phải bị từ chối | | | Chạy một truy vấn Spectrum thử | |

Và một lời khuyên: hãy kiểm tra quyền kms:Decrypt trong key policy khi Redshift Spectrum báo lỗi. Bucket policy và IAM policy có thể hoàn toàn đúng mà truy vấn vẫn thất bại — và thông báo lỗi hiếm khi chỉ thẳng vào khoá KMS.

Câu 204 Chọn nhiều đáp án Domain - Design for New Solutions

A company wants to improve the security of its cloud resources by ensuring that all running EC2 instances were launched from pre-approved AMIs only, which are set by the Security team. Their Development team has an agile CI/CD process which should not be stalled by the new automated solution that they’ll implement. Any new application release must be deployed first before the solution could analyze if it is using a pre-approved AMI or not.

Which of the following options enforces the required controls with the LEAST impact on the development process? (Select TWO.)

A
Set up IAM policies to restrict the ability of users to launch EC2 instances based on a specific set of pre-approved AMIs which were tagged by the Security team.
B
Set up a scheduled Lambda function to search through the list of running EC2 instances within your VPC and determine if any of these are based on unauthorized AMIs. Afterward, publish a new message to an SNS topic to inform the Security team that this occurred and then terminate the EC2 instance.
C
Set up the required policies, roles, and permissions to a centralized IT Operations team, which will manually process the security approval steps to ensure that EC2 instances are only launched from pre-approved AMIs.
D
Set up AWS Config rules to determine any launches of EC2 instances based on non-approved AMIs and then trigger an AWS Lambda function to automatically terminate the instance. Afterward, publish a message to an SNS topic to inform the Security team about the occurrence.
E
Set up Amazon Inspector to do regular scans using a custom assessment template to determine if the EC2 instance is based upon a pre-approved AMI. Terminate the instances and inform the Security team by email about the security breach.

Xem giải thích

Đáp án

**B và D — Lập hàm Lambda chạy theo lịch quét danh sách EC2 đang chạy trong VPC, phát hiện instance dùng AMI không được duyệt, gửi thông báo SNS cho đội bảo mật rồi thu hồi instance; và lập quy tắc AWS Config phát hiện instance khởi chạy từ AMI không được duyệt, kích hoạt Lambda tự thu hồi rồi thông báo qua SNS.

Vì sao đúng

Đề có một ràng buộc rất cụ thể quyết định loại giải pháp:

"Mọi bản phát hành mới phải được
  TRIỂN KHAI TRƯỚC rồi giải pháp
  mới phân tích xem có dùng AMI
  được duyệt hay không"
        ↓
    Nghĩa là kiểm soát PHÁT HIỆN,
      không phải PHÒNG NGỪA
        ↓
    Chặn ngay lúc khởi chạy sẽ
      làm đứng CI/CD

⚠ Đây là lý do IAM policy (phương án A) bị loại:

IAM policy chặn `RunInstances` với
  AMI không đúng
    → là kiểm soát PHÒNG NGỪA
        ↓
    Đội phát triển đưa AMI mới lên
    → bị chặn ngay
    → quy trình CI/CD dừng lại
        ↓
    Trái với yêu cầu "không làm
      đứng quy trình"

Quy tắc Config có sẵn:

aws configservice put-config-rule --config-rule '{
  "ConfigRuleName": "ami-duoc-duyet",
  "Source": {"Owner": "AWS",
    "SourceIdentifier": "APPROVED_AMIS_BY_ID"},
  "InputParameters": "{\"amiIds\":\"ami-0abc,ami-0def\"}",
  "Scope": {"ComplianceResourceTypes":
    ["AWS::EC2::Instance"]}}'

⚠ Config đánh giá theo SỰ KIỆN, gần như tức thì:

Instance mới khởi chạy
    → Config nhận sự kiện thay đổi
      cấu hình
        ↓
    Đánh giá quy tắc trong vài phút
    → phát hiện nhanh hơn nhiều
      so với quét theo lịch

Tự sửa bằng Config remediation:

aws configservice put-remediation-configurations \
  --remediation-configurations '[{
    "ConfigRuleName": "ami-duoc-duyet",
    "TargetType": "SSM_DOCUMENT",
    "TargetId": "AWS-TerminateEC2Instance",
    "Automatic": true,
    "MaximumAutomaticAttempts": 3,
    "Parameters": {"InstanceId":
      {"ResourceValue": {"Value": "RESOURCE_ID"}}}}]'

⚠ Và hàm Lambda theo lịch là lưới an toàn thứ hai:

Config có thể bỏ sót nếu recorder
  chưa bật ở Region nào đó
        ↓
    Quét định kỳ toàn bộ đội máy
    → bắt được cả những gì Config
      không thấy
        ↓
    Hai lớp độc lập bổ sung cho nhau

Hàm quét:

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

def handler(su_kien, ngu_canh):
    ds = ssm.get_parameter(Name='/bao-mat/ami-duoc-duyet')
    duoc_duyet = set(ds['Parameter']['Value'].split(','))
    phan_hoi = ec2.describe_instances(
        Filters=[{'Name': 'instance-state-name',
                  'Values': ['running']}])
    for r in phan_hoi['Reservations']:
        for i in r['Instances']:
            if i['ImageId'] not in duoc_duyet:
                sns.publish(TopicArn=ARN_SNS,
                    Message=f"AMI la: {i['InstanceId']}")
                ec2.terminate_instances(
                    InstanceIds=[i['InstanceId']])

⚠ Lưu danh sách AMI trong Parameter Store, không hardcode:

Đội bảo mật duyệt AMI mới
    → cập nhật một tham số
        ↓
    Không phải sửa mã Lambda
      hay quy tắc Config

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không chặn quy trình triển khai | | | Hai lớp phát hiện độc lập | | | Đội bảo mật được thông báo mỗi lần vi phạm | |

⚠ Nhưng phải cảnh báo: thu hồi tự động là hành động NGUY HIỂM:

AMI mới hợp lệ nhưng đội bảo mật
  chưa kịp thêm vào danh sách
        ↓
    Toàn bộ đội máy sản xuất
      bị thu hồi tự động
        ↓
    Cân nhắc: dừng thay vì thu hồi,
      hoặc gắn tag rồi để người quyết định

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

**A. Dùng IAM policy hạn chế người dùng chỉ khởi chạy EC2 từ AMI đã được đội bảo mật gắn tag — đây là phương án gần nhất và là kiểm soát phòng ngừa rất tốt trong nhiều tình huống, nhưng đề nói rõ bản phát hành phải được triển khai trước rồi mới phân tích; chặn ngay lúc khởi chạy sẽ làm đứng CI/CD.
**E. Dùng Amazon Inspector với assessment template tuỳ chỉnh để kiểm tra instance có dùng AMI được duyệt không — Inspector quét lỗ hổng phần mềm (CVE), nó không có khái niệm "AMI được duyệt".
**C. Giao cho đội vận hành xử lý thủ công các bước phê duyệt bảo mật — thủ công không co giãn và chắc chắn làm chậm quy trình phát triển.

Ghi nhớ

⚠ Ba loại kiểm soát bảo mật — bảng phải thuộc: | Loại | Cơ chế | Ví dụ | |---|---|---| | Phòng ngừa | chặn trước khi xảy ra | SCP, IAM policy | | Phát hiện | tìm ra sau khi xảy ra | Config, GuardDuty, Security Hub | | Phản ứng | tự sửa | Config remediation, EventBridge + Lambda |

Đề nói "phải triển khai trước
  rồi mới phân tích"
        ↓
    Loại phòng ngừa
    → chỉ còn phát hiện và phản ứng

Từ khoá nhận diện:

"must deploy first, then analyse" → kiểm soát phát hiện "prevent launch entirely" → IAM policy hoặc SCP "scan for CVE vulnerabilities" → Inspector "check resource configuration" → Config

Ba lưu ý về AWS Config: | Lưu ý | Chi tiết | |---|---| | Phải bật recorder ở mọi Region cần theo dõi | | | Không có dữ liệu quá khứ trước khi bật | | | Aggregator gộp nhiều tài khoản | |

⚠ Bật ở mọi Region là điều hay bị bỏ sót:

Config bật ở ap-southeast-1
    → ai đó khởi chạy instance ở
      us-east-1
        ↓
    Không phát hiện được
    → dùng Conformance Pack triển khai
      qua StackSets cho mọi Region

Ba quy tắc Config quản lý liên quan: | Quy tắc | Kiểm tra | |---|---| | approved-amis-by-id | AMI theo danh sách ID | | approved-amis-by-tag | AMI theo tag | | ec2-instance-managed-by-ssm | instance có SSM Agent không |

⚠ approved-amis-by-tag linh hoạt hơn:

{"InputParameters": "{\"amisByTagKeyAndValue\":\"DuyetBoiBaoMat:true\"}"}

Đội bảo mật gắn tag cho AMI mới
    → không phải cập nhật danh sách ID
        ↓
    Quy tắc tự nhận AMI mới được duyệt

Ba lưu ý về EC2 Image Builder: | Lưu ý | Chi tiết | |---|---| | Dựng AMI theo pipeline có kiểm thử | | | Tự gắn tag khi ảnh qua kiểm thử | | | Phân phối sang nhiều Region và tài khoản | |

⚠ Image Builder giải quyết vấn đề gốc:

Đội phát triển tự dựng AMI
    → đội bảo mật phải chạy theo duyệt
        ↓
    Image Builder: chỉ AMI qua pipeline
      mới được gắn tag duyệt
    → phòng ngừa mà không chặn CI/CD

Ba lưu ý về hành động tự động: | Lưu ý | Chi tiết | |---|---| | Thu hồi là hành động không đảo ngược | | | Cân nhắc dừng hoặc cô lập thay vì thu hồi | | | Luôn thông báo trước hoặc cùng lúc | |

⚠ Cô lập là lựa chọn an toàn hơn:

Gắn security group không cho
  lưu lượng nào
    → instance vẫn tồn tại để điều tra
        ↓
    Thu hồi: mất luôn bằng chứng
    → và mất dữ liệu trên instance store

Ba lưu ý về Security Hub: | Lưu ý | Chi tiết | |---|---| | Gom phát hiện từ Config, GuardDuty, Inspector | | | Có sẵn bộ chuẩn CIS và AWS Foundational | | | Delegated administrator cho toàn tổ chức | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Khởi chạy instance với AMI lạ, xem có bị bắt | | | Đo thời gian từ khởi chạy tới khi phát hiện | | | Kiểm đội bảo mật có nhận thông báo không | |

Và một lời khuyên: hãy cân nhắc dừng hoặc cô lập instance thay vì thu hồi tự động. Một quy tắc thu hồi hoạt động đúng như thiết kế nhưng dựa trên danh sách AMI lỗi thời sẽ xoá sạch đội máy sản xuất trong vài phút — và đó là loại sự cố tự gây ra tệ nhất.

Câu 205 Domain - Design Solutions for Organizational Complexity

A large software company has an on-premises LDAP server and has established an IPSec VPN connection between its on-premises network and its VPC in AWS. The company wants to enable employees to access AWS resources using the same corporate account used inside the company network.

Which of the following actions should the solutions architect implement to achieve the company’s requirements?

A
Integrate the on-premises LDAP server with AWS IAM so the employees can log into IAM using their corporate LDAP credentials. Once authenticated, they can use the temporary credentials to access any AWS resource.
B
Create an identity broker that authenticates against the on-premises LDAP server and then calls AWS STS to get IAM federated user credentials. The employees can use these credentials to access AWS resources.
C
Set up a federation between the on-premises LDAP server and AWS IAM. When employees authenticate against the LDAP server, retrieve the name of an IAM role associated with the user. Use AWS STS to assume that IAM role and provide the employees with temporary credentials to access AWS resources.
D
Create an identity broker that authenticates against the on-premises LDAP server and then calls AWS STS to assume an IAM role, generating temporary AWS security credentials. The employees can use these credentials to access AWS resources.

Xem giải thích

Đáp án

**D — Tạo một identity broker xác thực với máy chủ LDAP tại chỗ rồi gọi STS để giả nhận một vai trò IAM, sinh ra credential AWS tạm thời; nhân viên dùng credential đó truy cập tài nguyên AWS.

Vì sao đúng

Đề nêu hai điều kiện, và phương án này thoả cả hai: | Điều kiện | Cách đáp ứng | |---|---| | Xác thực bằng tài khoản công ty (LDAP) | broker hỏi LDAP | | Truy cập tài nguyên AWS | STS cấp credential tạm |

⚠ LDAP thuần KHÔNG nói SAML — đây là lý do phải có broker:

LDAP: giao thức thư mục
    → trả về thuộc tính người dùng
    → không có khái niệm assertion
      đã ký
        ↓
    `AssumeRoleWithSAML` cần một
      assertion SAML hợp lệ
    → LDAP không sinh ra được
        ↓
    Phải có thành phần trung gian

Đây là lý do phương án C sai — nó nói "thiết lập liên kết giữa LDAP và IAM", mà IAM chỉ liên kết được với IdP nói SAML hoặc OIDC.

⚠ Và IAM không nhận credential LDAP:

"Đăng nhập vào IAM bằng thông tin
  LDAP"
        ↓
    Không có luồng nào như vậy
    → IAM chỉ nhận credential của
      chính nó, hoặc token liên kết

Đây là lý do phương án A sai.

Broker thực hiện:

import boto3, ldap3

sts = boto3.client('sts')

def dang_nhap(ten, mat_khau):
    ket_noi = ldap3.Connection('ldaps://ldap.congty.com',
                               user=ten, password=mat_khau,
                               auto_bind=True)
    ket_noi.search('ou=NhanVien,dc=congty,dc=com',
                   f'(uid={ten})', attributes=['vaiTroAws'])
    ten_vai_tro = ket_noi.entries[0].vaiTroAws.value

    return sts.assume_role(
        RoleArn=f'arn:aws:iam::111122223333:role/{ten_vai_tro}',
        RoleSessionName=ten,
        DurationSeconds=3600)['Credentials']

⚠ RoleSessionName phải là định danh người dùng thật:

CloudTrail ghi tên phiên này
    → truy được thao tác về đúng
      một con người
        ↓
    Đặt tên chung như "phien-app"
    → mọi hoạt động trông giống nhau
    → mất khả năng truy vết

Trust policy của vai trò:

{"Version": "2012-10-17", "Statement": [{
  "Effect": "Allow",
  "Principal": {"AWS":
    "arn:aws:iam::111122223333:role/IdentityBroker"},
  "Action": "sts:AssumeRole"}]}

⚠ Broker chạy ở đâu là quyết định quan trọng:

Broker phải tới được LDAP tại chỗ
    → đề nói đã có IPSec VPN
        ↓
    Đặt broker trên EC2 trong VPC
    → dùng vai trò IAM, không dùng
      khoá tĩnh
        ↓
    Hoặc đặt tại chỗ với
      IAM Roles Anywhere

⚠ Và ánh xạ theo NHÓM chứ đừng theo từng người:

Thuộc tính LDAP ghi tên vai trò
    → nhưng nên lấy từ NHÓM
      mà người đó thuộc về
        ↓
    Tuyển người mới: thêm vào nhóm
    → không phải sửa gì ở AWS

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không tạo IAM user cho nhân viên | | | Nghỉ việc: khoá ở LDAP là mất quyền ngay | | | Credential tạm, tự hết hạn | |

⚠ Nhưng broker là thành phần cực kỳ nhạy cảm:

Nó có quyền cấp credential cho
  mọi người
        ↓
    Chiếm được broker = chiếm được
      quyền của tất cả
        ↓
    Subnet riêng, ghi log mọi lời gọi,
      giới hạn tần suất, vai trò hẹp

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

⚠ Bộ đề này chấm hai câu gần như giống nhau theo hai cách khác nhau.

Ở một câu khác trong cùng ngân hàng (mã #10440, cùng bối cảnh LDAP tại chỗ), phương án mô tả "tạo identity broker giả nhận vai trò IAM và lấy credential tạm qua STS" bị chấm là SAI, trong khi hai phương án khác gần như tương đương được chấm đúng.

Ở câu này, chính mô tả đó là đáp án ĐÚNG.

Cùng một kiến trúc
    → câu này: đúng
    → câu kia: sai
        ↓
    Khác biệt duy nhất là cách
      diễn đạt các phương án còn lại

Điều này không làm câu nào sai hẳn — trong mỗi câu, đáp án được chấm vẫn là lựa chọn hợp lý nhất trong bốn phương án của chính câu đó. Nhưng người luyện thi nên biết: nhóm câu về identity broker trong bộ đề này không nhất quán, và cách an toàn là đọc kỹ từng phương án trong phạm vi một câu chứ đừng ghi nhớ "mẫu câu trả lời" từ câu trước.

Và về mặt thiết kế hiện nay, cả hai câu đều mô tả cách cũ:

Dựng identity broker thủ công
    ↓
IAM Identity Center nối thẳng
  AD hoặc IdP
    → có cổng đăng nhập, permission set
    → không phải viết và vận hành
      broker nào

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

**B. Tạo identity broker xác thực LDAP rồi gọi STS lấy IAM federated user credentials — đây là phương án gần nhất và GetFederationToken là API có thật, nhưng nó đòi người gọi phải là IAM user (không dùng được với vai trò), và quyền hiệu lực bị giới hạn bởi chính quyền của user đó; giả nhận vai trò linh hoạt và sạch hơn.
**C. Thiết lập liên kết giữa LDAP và IAM trực tiếp — IAM chỉ liên kết được với IdP nói SAML 2.0 hoặc OIDC; LDAP thuần không phải một trong hai.
**A. Tích hợp LDAP với IAM để nhân viên đăng nhập IAM bằng thông tin LDAP — không có cơ chế nào cho phép IAM xác thực trực tiếp với LDAP.

Ghi nhớ

⚠ Bốn API cấp credential tạm — bảng phải thuộc: | API | Nguồn danh tính | Người gọi phải là | |---|---|---| | AssumeRole | danh tính AWS | bất kỳ principal được tin | | AssumeRoleWithSAML | IdP SAML 2.0 | không cần credential trước | | AssumeRoleWithWebIdentity | OIDC: Google, Facebook | không cần credential trước | | GetFederationToken | broker tự dựng | IAM USER (không phải vai trò) |

⚠ AssumeRole và GetFederationToken — khác biệt cốt lõi: | Tiêu chí | AssumeRole | GetFederationToken | |---|---|---| | Trả về | credential của một VAI TRÒ | credential của USER liên kết | | Thời hạn tối đa | 12 giờ | 36 giờ | | Người gọi | user hoặc role | chỉ IAM user |

Từ khoá nhận diện:

"on-premises LDAP" → identity broker + STS "SAML 2.0 IdP" → AssumeRoleWithSAML "social login" → AssumeRoleWithWebIdentity hoặc Cognito "many accounts, central login" → IAM Identity Center

Ba lưu ý về identity broker: | Lưu ý | Chi tiết | |---|---| | Chạy ở nơi tới được LDAP | | | Vai trò của broker phải hẹp nhất có thể | | | Ghi log mọi lần cấp credential | |

Ba lưu ý về LDAP: | Lưu ý | Chi tiết | |---|---| | Dùng LDAPS, không dùng LDAP thuần | | | LDAP sập là không ai đăng nhập được | | | Giữ một đường vào khẩn cấp độc lập | |

⚠ Rủi ro phụ thuộc phải cân nhắc:

Mọi quyền truy cập AWS phụ thuộc
  LDAP tại chỗ
        ↓
    LDAP hoặc VPN sập
    → không ai vào AWS được
        ↓
    Kể cả để sửa chính sự cố đó

Ba lưu ý về phạm vi theo người dùng: | Cách | Chi tiết | |---|---| | Một vai trò mỗi nhóm | đơn giản, đủ cho hầu hết | | Chính sách phiên truyền vào | thu hẹp thêm khi giả nhận | | Thẻ phiên + ABAC | một chính sách cho mọi người |

sts.assume_role(
    RoleArn='...:role/NhanVien',
    RoleSessionName=ten,
    Tags=[{'Key': 'PhongBan', 'Value': phong_ban}])

Ba lưu ý về thời hạn phiên: | Lưu ý | Chi tiết | |---|---| | Mặc định 1 giờ, tối đa 12 giờ | | | Đặt ngắn nhất mà quy trình chịu được | | | Chuỗi giả nhận vai trò tối đa 1 giờ | |

Ba lưu ý về IAM Identity Center: | Lưu ý | Chi tiết | |---|---| | Nối AD hoặc IdP ngoài một lần | | | Permission set thay cho vai trò từng tài khoản | | | aws sso login thay access key trong CLI | |

Ba lưu ý về giám sát: | Lưu ý | Chi tiết | |---|---| | CloudTrail ghi mọi lần giả nhận | | | sessionContext truy về người gốc | | | Cảnh báo khi vai trò quyền cao được giả nhận | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đăng nhập qua broker và kiểm quyền | | | Khoá tài khoản LDAP, thử lại — phải bị từ chối | | | Kiểm CloudTrail ghi đúng RoleSessionName | |

Và một lời khuyên: hãy chuyển sang IAM Identity Center nếu môi trường của bạn cho phép. Identity broker tự dựng là một dịch vụ nữa phải vận hành, bảo mật và trực — trong khi nó chỉ làm đúng việc mà AWS đã đóng gói sẵn và cung cấp miễn phí.

Câu 206 Domain - Accelerate Workload Migration and Modernization

A fashion company in France sells bags, clothes, and other luxury items in its online web store. The online store is currently hosted on the company’s on-premises data center. The company has recently decided to move all of its on-premises infrastructure to the AWS cloud. The main application is running on an NGINX web server and a database with an Oracle Real Application Clusters (RAC) One Node configuration.

Which of the following is the best way to migrate the application to AWS and set up an automated backup?

A
Launch an EC2 instance for both the NGINX server as well as for the database. Attach EBS volumes to the EC2 instance of the database and then use the Data Lifecycle Manager to automatically create scheduled snapshots against the EBS volumes.
B
Launch an On-Demand EC2 instance and run an NGINX server to host the application. Deploy an RDS instance with a Multi-AZ deployment configuration and enable automated backups on the RDS RAC cluster.
C
Launch an EC2 instance for both the NGINX server as well as for the database. Attach EBS Volumes on the EC2 instance of the database and then write a shell script that runs the manual snapshot of the volumes.
D
Launch an EC2 instance and run an NGINX server to host the application. Deploy an RDS instance and enable automated backups on the RDS RAC cluster.

Xem giải thích

Đáp án

**A — Khởi chạy EC2 cho cả máy chủ NGINX lẫn CSDL; gắn EBS volume vào instance CSDL rồi dùng Data Lifecycle Manager tự động tạo ảnh chụp theo lịch.

Vì sao đúng

Đề cho một dữ kiện quyết định mọi thứ:

CSDL chạy Oracle Real Application
  Clusters (RAC) One Node
        ↓
    Amazon RDS KHÔNG hỗ trợ RAC
      dưới bất kỳ dạng nào
        ↓
    Muốn giữ cấu hình đó
    → phải tự chạy trên EC2

⚠ Và "RDS RAC cluster" trong phương án B và D là thứ KHÔNG TỒN TẠI:

RAC cần lưu trữ dùng chung giữa
  các node (Oracle ASM)
        ↓
    RDS không cung cấp mô hình đó
    → không có tuỳ chọn nào bật RAC
      trên RDS
        ↓
    "Enable automated backups on the
      RDS RAC cluster" mô tả một
      thứ không có thật

⚠ Data Lifecycle Manager là công cụ đúng cho việc tự động chụp ảnh:

Tự viết shell script (phương án C)
    → phải tự lo lịch chạy, xử lý lỗi,
      dọn ảnh cũ, ghi log
        ↓
    DLM: khai một chính sách
    → AWS lo tất cả

Chính sách chụp ảnh tự động:

aws dlm create-lifecycle-policy \
  --description "Chup anh volume CSDL Oracle" \
  --state ENABLED --execution-role-arn <arn> \
  --policy-details '{
    "ResourceTypes": ["VOLUME"],
    "TargetTags": [{"Key":"SaoLuu","Value":"CSDL"}],
    "Schedules": [{
      "Name": "hang-ngay",
      "CreateRule": {"Interval": 12, "IntervalUnit": "HOURS",
                     "Times": ["02:00"]},
      "RetainRule": {"Count": 30},
      "CopyTags": true,
      "CrossRegionCopyRules": [{
        "TargetRegion": "eu-central-1",
        "Encrypted": true,
        "RetainRule": {"Interval": 30, "IntervalUnit": "DAYS"}}]}]}'

⚠ Nhưng ảnh chụp CSDL đang chạy cần một bước nữa:

Chụp volume trong lúc Oracle đang ghi
    → ảnh chụp "crash-consistent"
    → khôi phục được nhưng có thể
      phải phục hồi giao dịch dở
        ↓
    Đúng cách: `ALTER DATABASE BEGIN BACKUP`
      hoặc đóng băng hệ thống tệp
      TRƯỚC khi chụp

Đóng băng bằng Run Command:

aws ssm send-command --document-name "AWS-RunShellScript" \
  --targets Key=tag:Vaitro,Values=CSDL \
  --parameters 'commands=[
    "sqlplus / as sysdba <<< \"ALTER DATABASE BEGIN BACKUP;\"",
    "fsfreeze -f /oradata"]'

⚠ Và cần chụp NHIỀU volume cùng lúc nếu CSDL trải trên nhiều volume:

{"Parameters": {"ExcludeBootVolume": false},
 "CreateRule": {"Interval": 12, "IntervalUnit": "HOURS"}}

Oracle thường dùng volume riêng cho
  dữ liệu, redo log, archive log
        ↓
    Ảnh chụp không đồng thời
    → các volume lệch thời điểm nhau
    → khôi phục không nhất quán
        ↓
    Dùng chính sách kiểu INSTANCE
      để chụp mọi volume cùng lúc

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Giữ được cấu hình RAC hiện có | | | DLM tự chụp, tự dọn ảnh cũ | | | Sao chép xuyên Region cho DR | |

⚠ Và AWS Backup là lựa chọn rộng hơn DLM: | Tiêu chí | DLM | AWS Backup | |---|---|---| | Phạm vi | EBS, EC2 AMI | EBS, RDS, EFS, DynamoDB, FSx... | | Vault Lock chống xoá | không | CÓ | | Báo cáo tuân thủ | hạn chế | có |

Cần chống xoá bản sao lưu
    → AWS Backup với Vault Lock
      chế độ compliance

⚠ Và RDS Custom for Oracle lấp một phần khoảng trống:

RDS Custom: có quyền truy cập
  hệ điều hành và CSDL
    → cài agent, sửa tham số hệ thống
        ↓
    Vẫn KHÔNG hỗ trợ RAC
    → nhưng lo được nhiều việc
      vận hành hơn EC2 thuần

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

**C. EC2 cho cả hai tầng, gắn EBS volume, và viết shell script chụp ảnh thủ công — đây là phương án gần nhất và kiến trúc EC2 hoàn toàn đúng, nhưng đề đòi sao lưu tự động; script tự viết phải tự lo lịch, xử lý lỗi và dọn ảnh cũ.
**B. Chạy NGINX trên EC2 và triển khai RDS Multi-AZ với sao lưu tự động cho cụm RDS RAC — RDS không hỗ trợ Oracle RAC; "cụm RDS RAC" không tồn tại.
**D. Chạy NGINX trên EC2 và triển khai RDS với sao lưu tự động cho cụm RDS RAC — cùng lỗi.

Ghi nhớ

⚠ Ba tính năng Oracle mà RDS KHÔNG hỗ trợ — phải thuộc: | Tính năng | Ghi chú | |---|---| | Real Application Clusters (RAC) | phải chạy EC2 | | Automatic Storage Management (ASM) | | | Truy cập hệ điều hành trực tiếp | RDS Custom lấp một phần |

Từ khoá nhận diện:

"Oracle RAC" → EC2, KHÔNG phải RDS "automate EBS snapshots" → Data Lifecycle Manager hoặc AWS Backup "managed database, least effort" → RDS nếu tính năng cho phép "ransomware-proof backups" → AWS Backup Vault Lock |

Ba mức trách nhiệm khi chạy CSDL: | Cách chạy | AWS lo | Bạn lo | |---|---|---| | Aurora | gần như mọi thứ | schema, truy vấn | | RDS | vá, sao lưu, chuyển đổi | schema, tinh chỉnh | | EC2 | phần cứng | HỌ ĐIỀU HÀNH, CSDL, HA, sao lưu |

Ba lưu ý về Data Lifecycle Manager: | Lưu ý | Chi tiết | |---|---| | Chọn tài nguyên theo tag | | | Chính sách kiểu VOLUME hoặc INSTANCE | | | Sao chép xuyên Region tự động | |

⚠ Chính sách kiểu INSTANCE chụp mọi volume cùng lúc:

{"PolicyType": "EBS_SNAPSHOT_MANAGEMENT",
 "ResourceTypes": ["INSTANCE"],
 "Parameters": {"ExcludeBootVolume": false}}

Bảo đảm mọi volume của một instance
  được chụp ở cùng thời điểm
        ↓
    Điều kiện tiên quyết để khôi phục
      CSDL nhất quán

Ba lưu ý về sao lưu CSDL nhất quán: | Lưu ý | Chi tiết | |---|---| | Ảnh chụp lúc đang ghi là crash-consistent | | | Đặt CSDL vào chế độ backup trước khi chụp | | | Hoặc dùng RMAN ghi thẳng lên S3 | |

Ba lưu ý về sẵn sàng cao cho Oracle trên EC2: | Lưu ý | Chi tiết | |---|---| | RAC cần lưu trữ dùng chung | | | EBS Multi-Attach chỉ io1/io2, MỘT AZ | | | Data Guard là lựa chọn thay thế nhiều AZ | |

⚠ RAC One Node đơn giản hơn RAC đầy đủ:

RAC One Node: một node hoạt động
    → chuyển sang node khác khi hỏng
        ↓
    Không phải cụm nhiều node
      cùng phục vụ
    → nhưng vẫn cần lưu trữ dùng chung

Ba lưu ý về giấy phép Oracle: | Lưu ý | Chi tiết | |---|---| | BYOL trên EC2 theo quy định của Oracle | | | Dedicated Host giúp đếm lõi vật lý | | | RAC cần giấy phép riêng, rất đắt | |

⚠ License Manager theo dõi giấy phép:

aws license-manager create-license-configuration \
  --name giay-phep-oracle \
  --license-counting-type vCPU \
  --license-count 64 --license-count-hard-limit

Ba lưu ý về vá lỗi trên EC2: | Lưu ý | Chi tiết | |---|---| | Patch Manager cho hệ điều hành | | | Vá Oracle vẫn phải tự làm | | | Chụp ảnh trước khi vá | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Khôi phục thử từ ảnh chụp và mở CSDL | | | Kiểm mọi volume chụp cùng thời điểm | | | Xem ảnh chụp có sang Region dự phòng chưa | |

Và một lời khuyên: hãy hỏi xem có thật sự cần Oracle RAC không trước khi cam kết vận hành nó trên EC2. Rất nhiều hệ thống dùng RAC vì lý do lịch sử chứ không vì yêu cầu kỹ thuật — và với những hệ thống đó, RDS Multi-AZ cho khả năng sẵn sàng tương đương với một phần nhỏ công sức và chi phí giấy phép.

Câu 207 Domain - Design Solutions for Organizational Complexity

A multinational manufacturing company has multiple AWS accounts in multiple AWS regions across North America, Europe, and Asia. The solutions architect has been tasked to set up AWS Organizations to centrally manage policies and have full administrative control across the multiple AWS accounts owned by the company.

Which of the following options is the recommended implementation to achieve this requirement with the LEAST effort?

A
Use AWS Control Tower from the master account and enroll all the member AWS accounts of the company. AWS Control Tower will automatically provision the needed IAM permissions to have full administrative control across all member accounts.
B
Set up AWS Organizations by sending an invitation to the master account of your organization from each of the member accounts of the company. Create an OrganizationAccountAccessRole IAM role in the member account and grant permission to the master account to assume the role.
C
Set up AWS Organizations by sending an invitation to all member accounts of the company from the master account of your organization. Create an OrganizationAccountAccessRole IAM role in the member account and grant permission to the master account to assume the role.
D
Set up AWS Organizations by establishing cross-account access from the master account to all member AWS accounts of the company. The master account will automatically have full administrative control across all member accounts.

Xem giải thích

Đáp án

**C — Thiết lập AWS Organizations bằng cách gửi lời mời từ tài khoản quản lý tới tất cả tài khoản thành viên; tạo vai trò IAM OrganizationAccountAccessRole trong tài khoản thành viên và cấp quyền cho tài khoản quản lý giả nhận vai trò đó.

Vì sao đúng

Đề nêu hai việc, và phương án này khớp chiều của cả hai: | Việc | Chiều đúng | |---|---| | Mời vào tổ chức | tài khoản QUẢN LÝ gửi lời mời | | Cấp quyền quản trị | vai trò nằm ở tài khoản THÀNH VIÊN |

⚠ Chiều lời mời là điểm phân biệt với phương án B:

Tài khoản quản lý gửi lời mời
    → tài khoản thành viên chấp nhận
        ↓
    KHÔNG có chiều ngược lại
    → thành viên không "mời" tài khoản
      quản lý vào tổ chức của mình

⚠ Và vai trò phải nằm ở tài khoản CHỨA TÀI NGUYÊN:

Muốn thao tác trong tài khoản thành viên
    → vai trò phải được tạo TRONG
      tài khoản đó
        ↓
    Trust policy nói "tôi tin tài khoản
      quản lý"
    → tài khoản quản lý giả nhận

Gửi lời mời:

aws organizations invite-account-to-organization \
  --target Id=444455556666,Type=ACCOUNT \
  --notes "Moi tham gia to chuc cong ty"

⚠ Điểm mấu chốt: tài khoản TẠO qua Organizations tự có vai trò, tài khoản MỜI thì KHÔNG: | Cách tài khoản vào tổ chức | OrganizationAccountAccessRole | |---|---| | Tạo bằng create-account | AWS TỰ TẠO | | Mời tài khoản đã có sẵn | PHẢI tạo tay |

Đề nói công ty đã có nhiều tài khoản
    → chúng được MỜI vào
        ↓
    Phải tự tạo vai trò trong từng
      tài khoản thành viên
    → đây chính là điều đáp án mô tả

Tạo vai trò trong tài khoản thành viên:

{"Version": "2012-10-17", "Statement": [{
  "Effect": "Allow",
  "Principal": {"AWS": "arn:aws:iam::111122223333:root"},
  "Action": "sts:AssumeRole",
  "Condition": {"Bool":
    {"aws:MultiFactorAuthPresent": "true"}}}]}

⚠ :root ở đây KHÔNG có nghĩa là tài khoản gốc:

`arn:aws:iam::111122223333:root`
    → nghĩa là "bất kỳ principal nào
      TRONG tài khoản đó được chính
      tài khoản đó cho phép"
        ↓
    Vẫn cần IAM policy ở phía tài khoản
      quản lý cho phép `sts:AssumeRole`
    → cần CẢ HAI phía đồng ý

Giả nhận vai trò:

aws sts assume-role \
  --role-arn arn:aws:iam::444455556666:role/OrganizationAccountAccessRole \
  --role-session-name phien-quan-tri \
  --serial-number arn:aws:iam::111122223333:mfa/quantri \
  --token-code 123456

⚠ Và Consolidated Billing KHÔNG cấp quyền gì:

Thanh toán gộp: một hoá đơn,
  chiết khấu dùng chung
        ↓
    KHÔNG tạo ra bất kỳ quyền
      truy cập nào
    → đây là hiểu nhầm rất phổ biến

Đây là lý do phương án D sai — không có "cross-account access tự động".

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Một điểm quản trị cho mọi tài khoản | | | Credential tạm, hết hạn tự động | | | CloudTrail ở tài khoản đích ghi rõ ai thao tác | |

⚠ Nhưng vai trò quyền quản trị đầy đủ nên có điều kiện MFA:

Không có MFA: access key rò rỉ là đủ
  để chiếm mọi tài khoản trong tổ chức
        ↓
    Thêm điều kiện MFA
    → và cân nhắc giới hạn IP nguồn

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

**B. Thiết lập Organizations bằng cách gửi lời mời từ mỗi tài khoản thành viên tới tài khoản quản lý — đây là phương án gần nhất và phần vai trò OrganizationAccountAccessRole hoàn toàn đúng, nhưng đảo ngược chiều lời mời: chỉ tài khoản quản lý mới gửi lời mời được.
**A. Dùng AWS Control Tower ghi danh mọi tài khoản, Control Tower tự cấp quyền IAM để quản trị đầy đủ — Control Tower dựng landing zone với guardrail và ghi danh tài khoản được, nhưng nó không tự cấp quyền quản trị đầy đủ vào mọi tài khoản; và đề hỏi cách ít công sức nhất, trong khi Control Tower là một triển khai lớn hơn nhiều.
**D. Thiết lập Organizations bằng cách lập cross-account access từ tài khoản quản lý, và tài khoản quản lý tự động có quyền quản trị đầy đủ — không có cơ chế tự động nào như vậy.

Ghi nhớ

⚠ Hai cách đưa tài khoản vào Organizations — bảng phải thuộc: | Cách | Vai trò truy cập | |---|---| | create-account | AWS tự tạo OrganizationAccountAccessRole | | invite-account-to-organization | PHẢI tự tạo vai trò |

Từ khoá nhận diện:

"existing accounts, central admin access" → mời + tạo vai trò tay "new accounts with guardrails" → Control Tower Account Factory "restrict what accounts can do" → SCP "one bill, shared discounts" → Consolidated Billing

⚠ Ba thứ Organizations cho và không cho: | Tính năng | Cho gì | |---|---| | Consolidated Billing | một hoá đơn, chiết khấu chung | | SCP | đặt TRẦN quyền, KHÔNG cấp quyền | | Vai trò xuyên tài khoản | CẤP quyền truy cập |

Ba lưu ý về AWS Control Tower: | Lưu ý | Chi tiết | |---|---| | Dựng landing zone theo thực hành tốt | | | Guardrail phòng ngừa và phát hiện sẵn | | | Account Factory tạo tài khoản chuẩn hoá | |

⚠ Control Tower phù hợp khi bắt đầu từ đầu:

Tổ chức mới, chưa có tài khoản
    → Control Tower dựng cấu trúc chuẩn
        ↓
    Đã có nhiều tài khoản đang chạy
    → ghi danh chúng vào Control Tower
      là dự án riêng, không "ít công sức"

Ba lưu ý về OrganizationAccountAccessRole: | Lưu ý | Chi tiết | |---|---| | Quyền AdministratorAccess mặc định | | | Nên thu hẹp cho môi trường sản xuất | | | Thêm điều kiện MFA vào trust policy | |

Ba lưu ý về thiết kế OU: | Lưu ý | Chi tiết | |---|---| | Nhóm theo yêu cầu chính sách, không theo phòng ban | | | OU Sandbox tách hẳn với SCP lỏng hơn | | | OU Bảo mật cho tài khoản log và kiểm toán | |

⚠ Nhóm theo chính sách là nguyên tắc quan trọng nhất:

Nhóm theo phòng ban
    → mỗi OU cần nhiều SCP khác nhau
        ↓
    Nhóm theo "cần chính sách giống nhau"
    → một SCP cho cả OU
    → cấu trúc tự giải thích được

Ba lưu ý về SCP: | Lưu ý | Chi tiết | |---|---| | KHÔNG áp cho tài khoản quản lý | | | Không áp cho service-linked role | | | Deny luôn thắng Allow | |

⚠ Điểm đầu là lý do phải giữ tài khoản quản lý sạch:

Tài khoản quản lý không bị SCP chặn
    → đừng đặt tài nguyên sản xuất ở đó
        ↓
    Chỉ dùng để quản lý tổ chức
    → và khoá chặt quyền vào nó

Ba lưu ý về IAM Identity Center: | Lưu ý | Chi tiết | |---|---| | Cách hiện đại thay cho vai trò từng tài khoản | | | Permission set gán cho nhóm ở nhiều tài khoản | | | Có cổng đăng nhập chung | |

Ba lưu ý về giám sát: | Lưu ý | Chi tiết | |---|---| | Organization trail cho CloudTrail toàn tổ chức | | | Config aggregator gộp tuân thủ | | | Security Hub delegated administrator | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Giả nhận vai trò vào một tài khoản thành viên | | | Thử không có MFA — phải bị từ chối | | | Kiểm CloudTrail ở tài khoản đích ghi đúng người | |

Và một lời khuyên: hãy thu hẹp quyền của OrganizationAccountAccessRole cho các tài khoản sản xuất. Vai trò mặc định có AdministratorAccess trên mọi tài khoản trong tổ chức — đó là chìa khoá vạn năng, và nó không nên nằm sau một lớp xác thực yếu hơn tất cả những gì nó mở ra.

Câu 208 Domain - Design Solutions for Organizational Complexity

A financial services company operates a multi-account AWS environment managed by AWS Control Tower. The security team must centralize the management of compliance and security findings across all accounts. The solution should implement preventive, detective, and responsive controls to align with AWS best practices for securing multi-account environments and ensuring compliance with organizational policies.

Which of the following options will meet the given requirements?

A
Enable AWS CloudTrail in each account to log and analyze all API activity. Compile the security findings in a central report.
B
Set up Amazon GuardDuty in each account and export the findings to a central Amazon S3 bucket for aggregation and analysis.
C
Create a new member account in AWS Organizations. Enable AWS Security Hub and designate the account as the delegated administrator.
D
Use AWS Config conformance packs with AWS Control Tower and deploy them using AWS CloudFormation StackSets to apply organizational compliance rules across all accounts.

Xem giải thích

Đáp án

**C — Tạo một tài khoản thành viên mới trong AWS Organizations, bật AWS Security Hub và chỉ định tài khoản đó làm delegated administrator.

Vì sao đúng

Đề nêu ba yêu cầu, và Security Hub là dịch vụ được thiết kế đúng cho cả ba: | Yêu cầu | Cách đáp ứng | |---|---| | Tập trung phát hiện bảo mật và tuân thủ mọi tài khoản | Security Hub gom từ nhiều nguồn | | Kiểm soát phòng ngừa, phát hiện và phản ứng | tích hợp SCP, Config, GuardDuty, EventBridge | | Theo thực hành tốt cho môi trường nhiều tài khoản | delegated administrator |

⚠ Security Hub là lớp GOM, không phải nguồn phát hiện:

GuardDuty: phát hiện hành vi đe doạ
Inspector: lỗ hổng phần mềm
Macie: dữ liệu nhạy cảm
Config: cấu hình sai
        ↓
    Security Hub: gom tất cả về
      MỘT màn hình, MỘT định dạng
    → và chấm điểm theo chuẩn

⚠ Định dạng chung là điều làm việc gom có giá trị:

Mỗi dịch vụ có định dạng phát hiện
  riêng
        ↓
    Security Hub chuẩn hoá về ASFF
      (AWS Security Finding Format)
    → lọc, xếp hạng, định tuyến
      bằng cùng một bộ quy tắc

⚠ Và delegated administrator là thực hành tốt bắt buộc:

Bật Security Hub ở tài khoản quản lý
    → tài khoản quản lý phải mở rộng
      quyền cho đội bảo mật
        ↓
    Delegated administrator: một tài
      khoản THÀNH VIÊN chuyên trách
    → đội bảo mật chỉ vào tài khoản đó
    → tài khoản quản lý giữ sạch

Chỉ định delegated administrator:

aws organizations register-delegated-administrator \
  --account-id 444455556666 \
  --service-principal securityhub.amazonaws.com

aws securityhub enable-organization-admin-account \
  --admin-account-id 444455556666

Bật tự động cho tài khoản mới:

aws securityhub update-organization-configuration \
  --auto-enable --auto-enable-standards DEFAULT

⚠ auto-enable là chi tiết quan trọng:

Công ty mở tài khoản mới
    → tự động nằm trong Security Hub
        ↓
    Không phải nhớ bật thủ công
    → không có tài khoản nào lọt lưới

Ba chuẩn bảo mật có sẵn: | Chuẩn | Nội dung | |---|---| | AWS Foundational Security Best Practices | thực hành tốt của AWS | | CIS AWS Foundations Benchmark | chuẩn CIS | | PCI DSS | cho ngành thanh toán |

⚠ Và Security Hub bao phủ cả ba loại kiểm soát:

Phòng ngừa: kết quả kiểm tra chỉ ra
  SCP hoặc chính sách cần siết
        ↓
    Phát hiện: gom phát hiện từ
      GuardDuty, Config, Inspector
        ↓
    Phản ứng: EventBridge bắt phát hiện
      rồi gọi Lambda hoặc SSM Automation

Phản ứng tự động:

{"source": ["aws.securityhub"],
 "detail-type": ["Security Hub Findings - Imported"],
 "detail": {"findings": {
   "Severity": {"Label": ["CRITICAL", "HIGH"]},
   "Workflow": {"Status": ["NEW"]}}}}

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Một màn hình cho toàn tổ chức | | | Chuẩn hoá định dạng phát hiện | | | Tài khoản mới tự được phủ | |

⚠ Và Security Hub tự động tổng hợp xuyên Region:

aws securityhub create-finding-aggregator \
  --region-linking-mode ALL_REGIONS

Phát hiện ở mọi Region gom về
  một Region tổng hợp
        ↓
    Không phải mở từng Region
      để xem

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

**D. Dùng Config conformance pack với Control Tower, triển khai bằng CloudFormation StackSets — đây là phương án gần nhất và thật sự áp được quy tắc tuân thủ cho mọi tài khoản, nhưng nó chỉ phủ kiểm soát phát hiện về cấu hình; nó không gom phát hiện từ GuardDuty, Inspector hay Macie, và không cho "một nơi tập trung mọi phát hiện bảo mật".
**B. Bật GuardDuty ở từng tài khoản rồi xuất phát hiện về một bucket S3 — GuardDuty chỉ là một nguồn phát hiện; và tự gom vào S3 rồi tự phân tích là làm lại thứ Security Hub đã có.
**A. Bật CloudTrail ở từng tài khoản và tự tổng hợp báo cáo — CloudTrail ghi lời gọi API, nó không đánh giá bảo mật hay tuân thủ; và tổng hợp báo cáo thủ công không co giãn.

Ghi nhớ

⚠ Năm dịch vụ bảo mật và vai trò — bảng phải thuộc: | Dịch vụ | Trả lời câu hỏi | |---|---| | Security Hub | "tổng thể tình hình bảo mật thế nào?" | | GuardDuty | "có ai đang tấn công không?" | | Inspector | "có lỗ hổng phần mềm nào?" | | Macie | "có dữ liệu nhạy cảm nào trong S3?" | | Config | "cấu hình có đúng chuẩn không?" |

Từ khoá nhận diện:

"centralise security findings across accounts" → Security Hub delegated admin "detect threats from logs" → GuardDuty "enforce configuration rules" → Config conformance pack "prevent actions entirely" → SCP

⚠ Ba loại kiểm soát — phải phân biệt: | Loại | Cơ chế | |---|---| | Phòng ngừa | SCP, IAM policy, permission boundary | | Phát hiện | Config, GuardDuty, Security Hub | | Phản ứng | EventBridge + Lambda, SSM Automation |

Ba lưu ý về delegated administrator: | Lưu ý | Chi tiết | |---|---| | Nhiều dịch vụ hỗ trợ: Security Hub, GuardDuty, Config, Macie | | | Giữ tài khoản quản lý sạch | | | Đội bảo mật chỉ cần quyền ở tài khoản đó | |

⚠ Kiến trúc tài khoản chuẩn cho bảo mật:

Tài khoản quản lý: chỉ quản lý tổ chức
    ↓
Tài khoản bảo mật: delegated admin
  cho Security Hub, GuardDuty, Config
    ↓
Tài khoản log: bucket CloudTrail,
  chỉ nhận ghi
    ↓
Tài khoản khối lượng công việc

Ba lưu ý về Security Hub: | Lưu ý | Chi tiết | |---|---| | Tính phí theo số kiểm tra và số phát hiện nạp vào | | | Tắt bớt kiểm tra không liên quan để giảm chi phí | | | Insight nhóm phát hiện theo tiêu chí | |

⚠ Tắt kiểm tra không liên quan:

aws securityhub batch-disable-standards \
  --standards-subscription-arns <arn-pci-dss>

Không thuộc ngành thanh toán
    → chuẩn PCI DSS chỉ tạo nhiễu
    → và tính phí theo số kiểm tra

Ba lưu ý về xử lý phát hiện: | Lưu ý | Chi tiết | |---|---| | Đặt Workflow.Status để theo dõi tiến độ | | | Suppress phát hiện đã chấp nhận rủi ro | | | Automation rule tự gán mức độ và trạng thái | |

⚠ Không suppress thì bảng điều khiển mất tác dụng:

Hàng nghìn phát hiện đã chấp nhận
  rủi ro nằm lẫn với phát hiện mới
        ↓
    Không ai nhìn nữa
    → suppress có ghi chú lý do

Ba lưu ý về conformance pack: | Lưu ý | Chi tiết | |---|---| | Đóng gói nhiều quy tắc Config | | | Triển khai qua tổ chức bằng một lệnh | | | Có mẫu sẵn cho nhiều chuẩn | |

Ba lưu ý về chi phí: | Lưu ý | Chi tiết | |---|---| | Security Hub, GuardDuty, Config đều tính phí riêng | | | Config tính theo số bản ghi cấu hình | | | Ước tính trước khi bật toàn tổ chức | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tạo một cấu hình sai cố ý, xem có hiện lên | | | Kiểm tài khoản mới có tự được bật không | | | Xem phát hiện từ mọi Region có gom về không | |

Và một lời khuyên: hãy đặt delegated administrator ở một tài khoản bảo mật riêng chứ đừng bật ở tài khoản quản lý. Tài khoản quản lý không bị SCP chặn và là mục tiêu giá trị nhất trong tổ chức — càng ít người cần vào đó, càng ít đường để nó bị chiếm.

Câu 209 Domain - Design for New Solutions

A company is running its enterprise resource planning application in AWS that handles supply chain, order management, and delivery tracking. The architecture has a set of RESTful web services that enable third-party companies to search for data that will be consumed by their respective applications. The public web services consist of several AWS Lambda functions. DynamoDB is used for its database tier and is integrated with an Amazon OpenSearch domain, which stores the indexes and supports the search feature. A Solutions Architect has been instructed to ensure that in the event of a failed deployment, there should be no downtime, and a system should be in place to prevent subsequent deployments. The service must strictly maintain full capacity during API deployment without any reduced compute capacity to avoid degradation of the service.

Among the options below, which can the Architect use to meet the requirements in the MOST efficient way?

A
Do a blue/green deployment on all upcoming changes using AWS CodeDeploy. Using AWS CloudFormation, launch the Amazon DynamoDB tables, AWS Lambda functions, and Amazon OpenSearch domain in your AWS VPC. Host the web application in AWS Elastic Beanstalk and set the deployment policy to Immutable.
B
Do an in-place deployment on all upcoming changes using AWS CodeDeploy. Using AWS SAM, launch the Amazon DynamoDB tables, Lambda functions, and Amazon OpenSearch domain in your AWS VPC. Host the web application in AWS Elastic Beanstalk and set the deployment policy to Rolling.
C
Do a blue/green deployment on all upcoming changes using AWS CodeDeploy. Using AWS SAM, launch the DynamoDB tables, Lambda functions, and Amazon OpenSearch domain in your AWS VPC. Host the web application in AWS Elastic Beanstalk and set the deployment policy to All at Once.
D
Do a blue/green deployment on all upcoming changes using Amazon Lightsail. Let Amazon Lightsail handle the provisioning of database instances, EC2 instances, and load balancers needed by the web application. Use CloudFormation to deploy the AWS Lambda functions, provision DynamoDB tables, and create an Amazon OpenSearch domain in your VPC.

Xem giải thích

Đáp án

**A — Dùng blue/green deployment với AWS CodeDeploy cho mọi thay đổi; dùng CloudFormation dựng bảng DynamoDB, hàm Lambda và domain OpenSearch trong VPC; chạy ứng dụng web trên Elastic Beanstalk với chính sách triển khai Immutable.

Vì sao đúng

Đề nêu ba yêu cầu về triển khai, và chính sách Immutable là chính sách duy nhất thoả cả ba: | Yêu cầu | Immutable đáp ứng | |---|---| | Không có thời gian chết | instance mới lên trước, cũ gỡ sau | | GIỮ NGUYÊN công suất, không giảm | không gỡ máy nào trước khi có máy mới | | Ngăn triển khai tiếp theo khi thất bại | tự huỷ và giữ nguyên bản cũ |

⚠ Đây là điểm phân biệt cốt lõi giữa Immutable và Rolling:

Rolling: GỠ một phần instance cũ
    → cài bản mới lên chúng
        ↓
    Trong lúc đó công suất GIẢM
    → vi phạm "không giảm công suất
      tính toán"
        ↓
    Immutable: dựng ASG tạm với
      instance MỚI
    → công suất luôn đủ hoặc dư

Đây là lý do phương án B sai.

⚠ Và All at Once còn tệ hơn:

Thay TOÀN BỘ instance cùng lúc
    → có thời gian chết thật sự
        ↓
    Vi phạm yêu cầu đầu tiên

Đây là lý do phương án C sai.

Cấu hình chính sách Immutable:

aws elasticbeanstalk update-environment \
  --environment-name moi-truong-san-xuat \
  --option-settings \
    Namespace=aws:elasticbeanstalk:command,\
OptionName=DeploymentPolicy,Value=Immutable

⚠ Cách Immutable hoạt động:

1. Dựng một ASG TẠM trong cùng môi trường
2. Khởi chạy MỘT instance với bản mới
3. Instance đó qua health check
        ↓
4. Mở rộng ASG tạm lên đủ công suất
5. Chuyển instance mới sang ASG chính
6. Gỡ toàn bộ instance cũ

⚠ Bước 3 chính là cơ chế "ngăn triển khai hỏng":

Instance đầu tiên không qua
  health check
        ↓
    Beanstalk DỪNG NGAY
    → huỷ ASG tạm
    → môi trường cũ nguyên vẹn
        ↓
    Chỉ tốn thời gian của MỘT instance
      chứ không phải cả đội

⚠ Và đề nói API là Lambda — CodeDeploy blue/green cho Lambda:

Lambda alias trỏ tới hai version
  với trọng số
        ↓
    CodeDeploy chuyển dần lưu lượng
    → alarm kích hoạt thì tự quay lui

DeploymentPreference:
  Type: Canary10Percent5Minutes
  Alarms:
    - !Ref CanhBaoLoi
  Hooks:
    PreTraffic: !Ref HamKiemThuTruoc

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Công suất không bao giờ giảm | | | Triển khai hỏng bị chặn ở instance đầu tiên | | | Quay lui bằng cách huỷ ASG tạm, rất nhanh | |

⚠ Đổi lại: Immutable tốn gấp đôi tài nguyên trong lúc triển khai:

ASG chính đầy đủ + ASG tạm đầy đủ
    → cần đủ hạn ngạch vCPU
        ↓
    Và triển khai chậm hơn Rolling
    → đây là giá của việc an toàn

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

⚠ Đáp án dùng CloudFormation cho hàm Lambda, trong khi SAM là công cụ phù hợp hơn.

Hai phương án B và C dùng AWS SAM — vốn là phần mở rộng của CloudFormation dành riêng cho ứng dụng không máy chủ, và là công cụ chuẩn để khai DeploymentPreference cho Lambda. Phương án A dùng CloudFormation thuần.

SAM: cú pháp ngắn gọn cho Lambda,
  API Gateway, DynamoDB
    → và tích hợp sẵn với CodeDeploy
      cho triển khai dần
        ↓
    CloudFormation thuần: làm được
      nhưng dài dòng hơn nhiều

Điều quyết định vẫn là chính sách triển khai của Beanstalk — Immutable chỉ có ở phương án A, còn B là Rolling (giảm công suất) và C là All at Once (có thời gian chết). Nhưng nếu đề chỉ khác nhau ở IaC thì SAM sẽ là lựa chọn tốt hơn.

Và một chi tiết nữa:

Đề nói "đặt OpenSearch domain
  trong VPC"
        ↓
    Đúng về mặt bảo mật
    → nhưng khi đó Lambda cũng phải
      nằm trong VPC để gọi tới
    → thêm ENI và khởi động nguội
      lâu hơn

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

**C. Blue/green với CodeDeploy, dùng SAM dựng tài nguyên, Beanstalk với chính sách All at Once — đây là phương án gần nhất và SAM thậm chí phù hợp hơn cho Lambda, nhưng All at Once thay toàn bộ instance cùng lúc và có thời gian chết, vi phạm yêu cầu đầu tiên.
**B. In-place deployment với CodeDeploy và Beanstalk chính sách Rolling — in-place không cho quay lui nhanh, và Rolling làm giảm công suất trong lúc triển khai.
**D. Blue/green bằng Amazon Lightsail — Lightsail là VPS đơn giản giá cố định, nó không tích hợp với CodeDeploy hay quy trình CI/CD kiểu này.

Ghi nhớ

⚠ Năm chính sách triển khai của Elastic Beanstalk — bảng phải thuộc: | Chính sách | Thời gian chết | Công suất trong lúc triển khai | |---|---|---| | All at once | CÓ | giảm về 0 | | Rolling | không | GIẢM | | Rolling with additional batch | không | giữ nguyên | | Immutable | không | giữ nguyên hoặc dư | | Blue/Green (swap URL) | không | gấp đôi |

"Không giảm công suất"
    → loại All at once và Rolling
        ↓
    Còn lại: additional batch,
      Immutable, Blue/Green

Từ khoá nhận diện:

"no reduced capacity during deployment" → Immutable hoặc additional batch "quickest rollback" → Blue/Green swap URL "prevent subsequent deployments on failure" → Immutable "gradual traffic shift for Lambda" → CodeDeploy Canary/Linear

⚠ Immutable so với Rolling with additional batch: | Tiêu chí | Additional batch | Immutable | |---|---|---| | Instance cũ và mới lẫn nhau | CÓ | không | | Tài nguyên thêm | một lô | toàn bộ đội | | Quay lui | triển khai lại | huỷ ASG tạm | | An toàn | cao | cao nhất |

Ba lưu ý về Immutable: | Lưu ý | Chi tiết | |---|---| | Cần đủ hạn ngạch cho gấp đôi instance | | | Chậm hơn các chính sách khác | | | Instance đầu tiên là cổng kiểm tra | |

Ba lưu ý về CodeDeploy cho Lambda: | Kiểu | Cách chuyển | |---|---| | Canary | X% trước, chờ, rồi phần còn lại | | Linear | X% mỗi N phút | | All-at-once | 100% ngay |

⚠ Alarm là phần làm triển khai dần có ý nghĩa:

Không có alarm
    → vẫn chuyển nốt lưu lượng
      sang bản hỏng đúng lịch
        ↓
    Có alarm: tự quay lui khi tỷ lệ
      lỗi tăng

Ba lưu ý về CloudFormation và SAM: | Lưu ý | Chi tiết | |---|---| | SAM là phần mở rộng của CloudFormation | | | sam deploy dựng change set rồi thực thi | | | DeploymentPreference chỉ có trong SAM | |

Ba lưu ý về Lambda trong VPC: | Lưu ý | Chi tiết | |---|---| | Cần ENI, khởi động nguội lâu hơn | | | Cần VPC endpoint để gọi dịch vụ AWS | | | Chỉ đặt trong VPC khi thật sự cần | |

⚠ Lambda trong VPC là quyết định phải cân nhắc:

OpenSearch trong VPC
    → Lambda phải vào VPC để gọi
        ↓
    Mất đường ra Internet trừ khi
      có NAT gateway
    → và mọi lời gọi AWS cần endpoint

Ba lưu ý về health check: | Lưu ý | Chi tiết | |---|---| | Beanstalk enhanced health kiểm sâu hơn | | | Đường dẫn health check phải phản ánh sức khoẻ thật | | | Đừng gọi phụ thuộc bên ngoài trong đó | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Triển khai một bản hỏng cố ý, xem có bị chặn | | | Theo dõi số instance trong lúc triển khai | | | Đo thời gian triển khai của từng chính sách | |

Và một lời khuyên: hãy kiểm tra hạn ngạch vCPU trước khi chọn chính sách Immutable. Nó dựng một đội máy thứ hai đầy đủ trong lúc triển khai — và một triển khai thất bại vì chạm hạn ngạch trông giống hệt một triển khai thất bại vì lỗi ứng dụng.

Câu 210 Domain - Design for New Solutions

A company runs a finance-related application on a fleet of Amazon EC2 instances inside a private subnet of a VPC in AWS. To access the application, the instances are behind an internet-facing Application Load Balancer (ALB). As part of security compliance, the company is required to have a solution that allows it to inspect network payloads that are being sent to the application. Analyzing the network payloads will help in reverse-engineering sophisticated network attacks that the application may experience.

Which of the following options should the solutions architect implement to meet the company requirements?

A
Configure Traffic Mirroring on the elastic network interface of the EC2 instances. Send the mirrored traffic to a monitoring appliance for storage and inspection.
B
Go to the Amazon VPC console and create a VPC flow log. Set the destination of flow log data to an Amazon S3 bucket for analysis.
C
Create a new AWS web ACL with blank rules and a default “Allow” action. Associate the ALB to this web ACL. Enable logging on web ACL and send them to Amazon CloudWatch Logs for analysis.
D
Go to the Amazon EC2 console and enable “Access logs” for the ALB. Send the ALB access logs to Amazon AppFlow for payload inspection and to an Amazon S3 bucket for long-term storage.

Xem giải thích

Đáp án

**A — Cấu hình Traffic Mirroring trên elastic network interface của các EC2, gửi lưu lượng đã sao chép tới một thiết bị giám sát để lưu và phân tích.

Vì sao đúng

Đề nêu một yêu cầu rất cụ thể, và chỉ một dịch vụ đáp ứng được:

"Kiểm tra NỘI DUNG gói tin
  (network payload)"
        ↓
    Cần bản sao TOÀN BỘ gói tin,
      kể cả phần dữ liệu
        ↓
    Chỉ VPC Traffic Mirroring làm
      được điều đó

⚠ Đây là điểm phân biệt với VPC Flow Logs: | Công cụ | Ghi lại gì | |---|---| | VPC Flow Logs | METADATA: IP nguồn/đích, cổng, byte, ACCEPT/REJECT | | Traffic Mirroring | TOÀN BỘ gói tin, gồm cả payload |

Flow log cho biết "có kết nối từ
  A tới B, 5 KB"
        ↓
    Traffic Mirroring cho biết
      5 KB đó CHỨA GÌ
    → đây mới là thứ dùng để
      phân tích ngược tấn công

Đây là lý do phương án B sai.

Tạo bản sao lưu lượng:

aws ec2 create-traffic-mirror-target \
  --network-load-balancer-arn <arn-nlb-giam-sat> \
  --description "Thiet bi giam sat"

aws ec2 create-traffic-mirror-filter \
  --description "Loc luu luong ung dung"

aws ec2 create-traffic-mirror-session \
  --network-interface-id eni-abc \
  --traffic-mirror-target-id tmt-abc \
  --traffic-mirror-filter-id tmf-abc \
  --session-number 1 \
  --packet-length 8500

⚠ Ba thành phần của Traffic Mirroring — phải phân biệt: | Thành phần | Vai trò | |---|---| | Source | ENI của instance cần theo dõi | | Target | nơi nhận bản sao: ENI, NLB hoặc GWLB | | Filter | quy tắc chọn lưu lượng nào được sao |

Lọc để giảm khối lượng:

aws ec2 create-traffic-mirror-filter-rule \
  --traffic-mirror-filter-id tmf-abc \
  --traffic-direction ingress --rule-number 100 \
  --rule-action accept --protocol 6 \
  --destination-port-range FromPort=443,ToPort=443 \
  --source-cidr-block 0.0.0.0/0 \
  --destination-cidr-block 10.0.0.0/16

⚠ Không lọc là sao chép toàn bộ lưu lượng — rất tốn:

Bản sao đi qua mạng VPC
    → tiêu băng thông của chính
      instance nguồn
        ↓
    Ứng dụng tải cao
    → sao chép hết làm chậm chính nó
        ↓
    Lọc theo cổng và giao thức
      thật sự cần điều tra

⚠ Và packet-length cắt bớt gói tin nếu chỉ cần header:

`--packet-length 8500`: sao toàn bộ
    → `--packet-length 100`: chỉ
      100 byte đầu
        ↓
    Đủ cho header, giảm mạnh
      băng thông
    → nhưng đề cần PAYLOAD
      nên phải lấy đủ

⚠ Traffic Mirroring có ràng buộc về loại instance:

Ban đầu chỉ hỗ trợ instance
  dùng Nitro
        ↓
    Nay hỗ trợ rộng hơn nhưng vẫn
      không phải mọi loại
    → kiểm tra danh sách trước
      khi thiết kế

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Thấy toàn bộ nội dung gói tin | | | Không cần cài agent lên instance | | | Ứng dụng không biết đang bị theo dõi | |

⚠ Lợi ích thứ ba quan trọng với điều tra sự cố:

Cài agent trên instance
    → kẻ tấn công đã vào máy có thể
      tắt agent
        ↓
    Traffic Mirroring làm ở tầng
      hạ tầng
    → không tắt được từ bên trong máy

⚠ Nhưng phải chú ý vấn đề mã hoá:

Lưu lượng HTTPS được sao chép
    → nhưng vẫn ở dạng MÃ HOÁ
        ↓
    Thiết bị giám sát cần khoá
      để giải mã
    → hoặc đặt nguồn sao chép SAU
      điểm chấm dứt TLS

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

**B. Tạo VPC flow log và gửi dữ liệu về bucket S3 để phân tích — đây là phương án gần nhất và flow log thật sự là công cụ giám sát mạng của VPC, nhưng nó chỉ ghi metadata của luồng, không ghi nội dung gói tin; không dùng để phân tích ngược tấn công được.
**C. Tạo web ACL rỗng với hành động mặc định "Allow", gắn vào ALB và bật logging — log của WAF ghi thông tin request HTTP, không phải toàn bộ payload ở tầng mạng; và web ACL rỗng không mang lại giá trị phân tích nào.
**D. Bật access log của ALB và gửi tới Amazon AppFlow — access log ghi dòng tóm tắt mỗi request, không có payload; và AppFlow là dịch vụ chuyển dữ liệu giữa SaaS và AWS, không phân tích gói tin.

Ghi nhớ

⚠ Bốn công cụ quan sát mạng — bảng phải thuộc: | Công cụ | Mức chi tiết | |---|---| | VPC Flow Logs | metadata luồng | | Traffic Mirroring | toàn bộ gói tin | | ALB access log | tóm tắt request HTTP | | WAF log | request HTTP đã lọc |

Từ khoá nhận diện:

"inspect network payloads" → Traffic Mirroring "which flows were accepted or rejected" → VPC Flow Logs "HTTP request details" → ALB access log hoặc WAF log "third-party security appliance inline" → Gateway Load Balancer

⚠ Traffic Mirroring và GWLB — hai mô hình khác nhau: | Tiêu chí | Traffic Mirroring | Gateway Load Balancer | |---|---|---| | Vị trí | NGOÀI luồng (out-of-band) | TRONG luồng (inline) | | Chặn được lưu lượng | KHÔNG | có | | Ảnh hưởng độ trễ | không | có | | Dùng cho | phân tích, điều tra | tường lửa, IPS |

Đề nói "phân tích ngược tấn công"
    → không cần chặn
    → Traffic Mirroring đúng
        ↓
    Cần CHẶN tấn công
    → GWLB với thiết bị IPS

Ba lưu ý về Traffic Mirroring: | Lưu ý | Chi tiết | |---|---| | Lọc để giảm khối lượng và chi phí | | | Bản sao tiêu băng thông của instance nguồn | | | Kiểm loại instance có hỗ trợ không | |

Ba lưu ý về đích nhận: | Đích | Khi nào | |---|---| | ENI đơn lẻ | một thiết bị giám sát | | NLB | đội thiết bị, có cân bằng tải | | GWLB endpoint | tích hợp với thiết bị bên thứ ba |

Ba lưu ý về giải mã: | Lưu ý | Chi tiết | |---|---| | HTTPS được sao ở dạng mã hoá | | | Đặt nguồn sau điểm chấm dứt TLS | | | Hoặc cung cấp khoá cho thiết bị giám sát | |

⚠ Đặt nguồn ở đâu quyết định thấy được gì:

Sao ở ENI của EC2 (sau khi ALB
  đã chấm dứt TLS)
        ↓
    Lưu lượng ALB → EC2 có thể
      là HTTP thuần
    → thấy được payload
        ↓
    Sao ở trước ALB: chỉ thấy
      dữ liệu mã hoá

Ba lưu ý về lưu trữ và phân tích: | Lưu ý | Chi tiết | |---|---| | Gói tin sinh khối lượng rất lớn | | | Chỉ giữ trong thời gian điều tra | | | Dùng công cụ như Suricata, Zeek, Wireshark | |

Ba lưu ý về quyền riêng tư: | Lưu ý | Chi tiết | |---|---| | Payload có thể chứa dữ liệu cá nhân | | | Mã hoá nơi lưu bản sao | | | Giới hạn ai truy cập được | |

⚠ Đây là rủi ro tuân thủ thật sự:

Sao chép toàn bộ lưu lượng
  ứng dụng tài chính
        ↓
    Bản sao chứa dữ liệu giao dịch,
      thông tin khách hàng
    → nơi lưu bản sao phải được bảo vệ
      chặt như chính hệ thống gốc

Ba lưu ý về VPC Flow Logs: | Lưu ý | Chi tiết | |---|---| | Định dạng tuỳ chỉnh thêm được nhiều trường | | | Gửi tới S3, CloudWatch Logs hoặc Firehose | | | Bổ sung cho Traffic Mirroring, không thay thế | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Gửi một request thử, xem có xuất hiện ở thiết bị giám sát | | | Kiểm băng thông của instance nguồn có bị ảnh hưởng | | | Xác nhận thấy được payload chứ không chỉ header | |

Và một lời khuyên: hãy luôn dùng filter chứ đừng sao chép toàn bộ lưu lượng. Bản sao đi qua chính giao diện mạng của instance nguồn — sao chép không lọc trên một ứng dụng tải cao là cách chắc chắn để biến công cụ giám sát thành nguyên nhân của sự cố tiếp theo.

Trang 21 / 123 — tổng 1221 câu hỏi