Dịch vụ bảo mật: WAF, Shield, GuardDuty, Inspector, Macie, Security Hub, Cognito, IAM Identity Center

Bạn vừa gặp hai loại việc khác nhau: chặn ở biên (brute force, SQL injection đi vào qua ALB) và phát hiện (có ai đang làm gì lạ trong tài khoản không). Bài này gom các dịch vụ bảo mật "có tên riêng" của AWS mà Domain 3 SAA-C03 (Design Secure Architectures, 30% đề, lớn nhất) hay hỏi, chia theo đúng câu hỏi chúng trả lời. IAM, KMS, VPC đã học ở 22.2, 22.3, 22.14; bài này không lặp.

1. Bài toán: shop-app lộ ra Internet qua ALB và CloudFront

Internet ──► CloudFront (assets) ──► S3 shop-app-assets
Internet ──► shop-alb :443 ──► shop-asg :8080 ──► shop-db / shop-cache

Những gì shop-alb-sg cho qua: TCP 80/443 từ 0.0.0.0/0. Nghĩa là:
  - brute force /login              : hợp lệ về mạng, SG không chặn
  - SQL injection trong query string : hợp lệ về mạng
  - bot cào giá sản phẩm 1000 req/s  : hợp lệ về mạng
  - DDoS SYN flood                   : AWS tự chặn phần lớn (Shield Standard)
  - DDoS Layer 7 (HTTP flood)        : ALB vẫn nhận, EC2 vẫn tốn CPU

Và ở phía trong: access key bị lộ lên GitHub, ai đó gọi API từ IP lạ, EC2 bị cài crypto miner, bucket S3 có file chứa số thẻ. IAM và SG đúng vẫn không nói cho bạn biết việc đó đang diễn ra.

2. Vấn đề: SG/NACL làm việc ở Layer 3–4, còn tấn công ở Layer 7 và ở hành vi

• Security Group chỉ biết IP, port, protocol. Không đọc được URL, header, body.
• Rate limit viết trong Spring (bucket4j, Redis) chỉ bảo vệ sau khi request đã tới EC2, đã tốn CPU và kết nối.
• CloudTrail ghi lại mọi API call (22.15) nhưng không ai đọc hàng triệu dòng để tìm cái bất thường.
• Vulnerability trong AMI, trong jar (log4j kiểu cũ) không ai quét định kỳ.
• Dữ liệu nhạy cảm trong S3 không ai biết nằm ở đâu.
• Tự xây đăng nhập người dùng (user/pass, social login, MFA) là việc tốn công và dễ sai.

3. Giải pháp: bản đồ dịch vụ bảo mật theo câu hỏi chúng trả lời

3.1 WAF: cấu trúc

Web ACL (gắn vào 1 ALB / CloudFront / API Gateway stage)
 ├─ Default action: Allow (hoặc Block)
 ├─ Rule 0  : AWSManagedRulesCommonRuleSet        (OWASP top 10 cơ bản, XSS)
 ├─ Rule 1  : AWSManagedRulesSQLiRuleSet          (SQL injection)
 ├─ Rule 2  : AWSManagedRulesKnownBadInputsRuleSet (log4j JNDI, path traversal)
 ├─ Rule 3  : AWSManagedRulesAmazonIpReputationList (IP xấu theo threat intel)
 ├─ Rule 4  : rate-based rule: > 300 req / 5 phút cùng IP tới /login → Block
 ├─ Rule 5  : geo match: country not in [VN, SG] → Count (chỉ đếm để quan sát)
 └─ Rule 6  : custom: header User-Agent chứa "python-requests" → CAPTCHA / Challenge
 Mỗi rule có action: Allow / Block / Count / CAPTCHA / Challenge; có "capacity" (WCU), ACL tối đa 5.000 WCU
 Log: ra CloudWatch Logs (log group bắt đầu bằng aws-waf-logs-), S3, hoặc Firehose

• Rate-based rule: cửa sổ đánh giá 1, 2, 5 hoặc 10 phút, ngưỡng tối thiểu theo cửa sổ (từ vài chục request); aggregate theo IP, forwarded IP (sau CloudFront), header, cookie, query… Đây là câu trả lời đề thi cho "limit requests per IP", "protect login from brute force".
• Managed rule group: do AWS hoặc Marketplace vendor duy trì, tự cập nhật. Có Bot Control (trả phí thêm) và Account Takeover Prevention cho trang login.
• Scope: REGIONAL (ALB, API Gateway, Cognito, AppSync trong region) hoặc CLOUDFRONT (phải tạo ở us-east-1).
• WAF không gắn được vào NLB hay EC2 trực tiếp. Đề cho NLB mà hỏi WAF → sai, phải đổi sang ALB hoặc đặt CloudFront phía trước.

3.2 Shield

3.3 GuardDuty: bật một nút, không agent (trừ Runtime Monitoring tùy chọn). Nguồn: CloudTrail management events, S3 data events, VPC Flow Logs, Route 53 DNS logs, EKS audit logs, RDS login activity, Lambda network, Malware Protection cho EBS/S3. Finding có severity Low/Medium/High và loại như UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS, CryptoCurrency:EC2/BitcoinTool.B!DNS. Có 30 ngày trial miễn phí, sau đó tính theo lượng log phân tích. Multi-account: delegated administrator trong Organizations.

3.4 Cognito user pool vs identity pool (bẫy kinh điển)

User Pool (Authentication: "bạn là ai")        Identity Pool (Authorization vào AWS: "bạn được gọi gì")
───────────────────────────────────────────    ────────────────────────────────────────────────
- Lưu user, password, attribute                - KHÔNG lưu user
- Sign-up, sign-in, MFA, forgot password       - Nhận token từ: Cognito user pool, Google,
- Hosted UI, OAuth2/OIDC server                  Facebook, Apple, SAML, OIDC, hoặc guest (unauth)
- Federation: Google, Facebook, Apple, SAML    - Đổi token → STS AssumeRoleWithWebIdentity
- Trả JWT: id_token, access_token, refresh     - Trả credential AWS tạm (AccessKey/Secret/Session)
- App/Spring dùng như một OIDC provider        - App gọi S3/DynamoDB trực tiếp, phân quyền bằng
  (resource server validate JWT)                 IAM role + policy variable ${cognito-identity.amazonaws.com:sub}

So với Keycloak (chương 12): user pool làm việc của Keycloak realm (IdP, OIDC, MFA, social login) nhưng do AWS quản lý, ít tùy biến flow hơn; Spring Boot cấu hình spring.security.oauth2.resourceserver.jwt.issuer-uri trỏ sang Cognito giống hệt cách trỏ sang Keycloak (spring-security 08). Identity pool thì Keycloak không có tương đương: nó là cầu nối sang IAM.

3.5 IAM Identity Center vs Cognito vs IAM user

4. Cấu hình từng bước: WAF trước shop-alb

Bước 1: IP set (danh sách IP cần block hẳn, ví dụ dải đang brute force):

aws wafv2 create-ip-set --name shop-blocklist --scope REGIONAL \
  --ip-address-version IPV4 --addresses 203.0.113.0/24 \
  --tags Key=Project,Value=shop-app Key=Env,Value=lab \
  --region $AWS_REGION --profile shop-lab

Bước 2: Web ACL với managed rule + rate-based rule (file JSON ở lab bên dưới).

Bước 3: Gắn vào ALB:

aws wafv2 associate-web-acl --web-acl-arn $WEB_ACL_ARN \
  --resource-arn $ALB_ARN --region $AWS_REGION --profile shop-lab

Bước 4 (Java): đọc đúng IP client sau WAF/ALB. WAF rate-limit theo IP nguồn tới ALB; nếu còn CloudFront phía trước thì dùng forwarded IP (header X-Forwarded-For). Spring Boot cũng nên hiểu header này để log và rate limit tầng app nhất quán:

# application.yml
server:
  forward-headers-strategy: framework   # tin X-Forwarded-* từ ALB
  tomcat:
    remoteip:
      internal-proxies: 10\.0\.\d{1,3}\.\d{1,3}   # chỉ tin proxy trong VPC

// Khi WAF block, client nhận 403 từ WAF, request không tới app.
// Khi WAF ở chế độ Count, app vẫn nhận; có thể đọc header để biết:
@GetMapping("/login")
public ResponseEntity<?> login(HttpServletRequest req) {
    String clientIp = req.getRemoteAddr();            // đã được RemoteIpValve chỉnh
    log.info("login from ip={} ua={}", clientIp, req.getHeader("User-Agent"));
    ...
}

Bước 5 (Java): Cognito làm IdP cho shop-app thay hoặc song song Keycloak:

spring:
  security:
    oauth2:
      resourceserver:
        jwt:
          issuer-uri: https://cognito-idp.${AWS_REGION}.amazonaws.com/${COGNITO_USER_POOL_ID}
          # jwk-set-uri tự suy ra: {issuer}/.well-known/jwks.json

// Cognito đặt group vào claim "cognito:groups", map sang ROLE_
@Bean
JwtAuthenticationConverter jwtAuthenticationConverter() {
    JwtGrantedAuthoritiesConverter groups = new JwtGrantedAuthoritiesConverter();
    groups.setAuthoritiesClaimName("cognito:groups");
    groups.setAuthorityPrefix("ROLE_");
    JwtAuthenticationConverter c = new JwtAuthenticationConverter();
    c.setJwtGrantedAuthoritiesConverter(groups);
    return c;
}

Chú ý: access token của Cognito không có claim aud (chỉ id token có), nên nếu bật kiểm tra audience phải dùng claim client_id.

5. Cách hoạt động: request đi qua lớp nào, finding chảy về đâu

            Internet
               │
   Shield Standard (L3/4, luôn bật) ──── Shield Advanced (L7, SRT, cost protection)
               │
         CloudFront ── WAF (scope CLOUDFRONT)      ← assets, có thể cả API
               │
          shop-alb ──── WAF (scope REGIONAL)       ← web ACL shop-waf
               │          ├─ managed: SQLi, XSS, bad inputs, IP reputation
               │          ├─ rate-based: 300 req/5min/IP trên /login → Block
               │          └─ log → CloudWatch Logs aws-waf-logs-shop
               ▼
         shop-asg (EC2)  ◄── Inspector quét CVE qua SSM agent
               │          ◄── GuardDuty Runtime Monitoring (tùy chọn)
               ▼
   shop-db / shop-cache / S3 shop-app-assets ◄── Macie quét PII trong S3

   Nguồn log                 Phát hiện              Gom & hành động
   CloudTrail ─┐             GuardDuty ──┐          Security Hub
   VPC Flow ───┼───────────► (ML/intel)  ├────────► (ASFF, score, standards)
   DNS logs ───┘             Inspector ──┤               │ EventBridge rule
   EKS audit                 Macie ──────┤               ▼
   S3 data events            Config ─────┘          SNS shop-security-alerts
                             Access Analyzer        Lambda tự động remediate
                                                    (vd: tắt public bucket)
                                                    Detective: điều tra sâu

Thứ tự "đọc" sơ đồ này trong đề: chặn ở WAF/Shield; phát hiện ở GuardDuty/Inspector/Macie; tổng hợp ở Security Hub; điều tra ở Detective; tự động xử lý qua EventBridge + Lambda/SSM Automation.

6. So sánh kiểu đề thi

7. Khi nào dùng / không

• WAF: bật managed Common + SQLi + Known Bad Inputs cho mọi ALB/CloudFront public; thêm rate-based cho /login, /api/checkout. Chạy Count 1–2 tuần trước khi Block để tránh chặn khách thật. Không dùng WAF thay validation trong code.
• Shield Advanced: chỉ khi doanh thu phụ thuộc uptime và chịu được phí tháng; shop-app giai đoạn này dùng Standard + WAF rate limit + CloudFront là đủ.
• GuardDuty: bật ở mọi account, mọi region (kể cả region không dùng: kẻ tấn công thích region vắng). Rẻ so với giá trị.
• Inspector: bật khi có EC2/ECR; cho pipeline fail nếu image shop-app có CVE Critical (xem 22.13, ECR enhanced scanning chính là Inspector).
• Macie: khi S3 chứa dữ liệu khách hàng (hồ sơ, hóa đơn); không cần cho bucket chỉ có ảnh sản phẩm.
• Security Hub: khi có từ 2 account hoặc cần báo cáo compliance; một account lab cũng dùng để học cách đọc finding.
• Cognito: khi muốn bỏ tự vận hành Keycloak và chấp nhận ít tùy biến; không hợp khi cần flow phức tạp, theme sâu, hoặc chạy on-prem.

Không thừa, vì hai cái bảo vệ hai thứ khác nhau. Bạn đang có "rate limit nghiệp vụ" ở tầng app; WAF là "rate limit sinh tồn" ở biên.

1. Hai lớp, hai mục đích

                 WAF rate-based rule                      bucket4j + Redis trong app
Chỗ đứng         trước ALB, request bị chặn không tới EC2  trong EC2, request đã tốn CPU/thread
Đơn vị           IP (hoặc forwarded IP, header, cookie)    user id, API key, tenant
Ngưỡng           cao, thô: 300–2000 req/5 phút             thấp, tinh: 10 req/giây/user
Mục đích         chống flood, brute force, bot cào         công bằng giữa user, bảo vệ DB
Phản hồi         403 từ WAF (hoặc CAPTCHA/Challenge)       429 + Retry-After từ app
Khi EC2 chết     vẫn chặn                                  không còn ai chặn

Rate limit trong app không bảo vệ bạn khi 10.000 req/s đổ vào: mỗi request vẫn mở connection, chạy filter chain, hỏi Redis. WAF chặn ở biên nên EC2 không thấy gì. Ngược lại WAF không biết user A đang lạm dụng API bằng 50 IP khác nhau; bucket4j theo user id mới bắt được. Xem lại thiết kế rate limiting ở system-design 04.

2. Đặt ngưỡng để không chặn NAT công ty

• Scope down rule: rate-based rule chỉ áp cho path nhạy cảm (/login, /api/auth/*, /api/checkout) thay vì toàn site. Khách thật không đăng nhập 300 lần trong 5 phút, kể cả cả văn phòng chung một IP.
• Aggregate key tinh hơn IP: WAF cho phép gộp theo IP + header (vd X-Device-Id) hoặc theo cookie session. Cùng NAT nhưng khác cookie thì tính riêng.
• Action CAPTCHA/Challenge thay Block cho path trang web: người thật giải được, bot dừng. API thuần thì Block hoặc trả custom response 429 với body JSON.
• Chạy Count trước: để rule ở Count 1–2 tuần, xem log aws-waf-logs-shop bằng Logs Insights đếm có IP thật nào vượt ngưỡng, rồi mới đổi Block.
• Allowlist IP set cho IP văn phòng, đối tác, health checker, đặt rule Allow này ở priority trước rate rule.

# Logs Insights trên log group aws-waf-logs-shop: IP nào bị rule rate-login đánh dấu
fields @timestamp, httpRequest.clientIp, httpRequest.uri, terminatingRuleId, action
| filter terminatingRuleId = "rate-login" or ispresent(nonTerminatingMatchingRules.0.ruleId)
| stats count(*) as hits by httpRequest.clientIp
| sort hits desc | limit 20

3. Phía CloudFront

Nếu đặt CloudFront trước ALB, IP tới ALB là IP edge của CloudFront. Rate rule ở ALB phải dùng ForwardedIPConfig (header X-Forwarded-For), hoặc tốt hơn là gắn WAF vào CloudFront. Và khóa ALB chỉ nhận từ CloudFront: SG của ALB dùng managed prefix list com.amazonaws.global.cloudfront.origin-facing cộng custom header bí mật mà CloudFront thêm vào, ALB listener rule kiểm tra header đó.

Finding này nghĩa đen là: credential của role EC2 shop-app-ec2-role (vốn chỉ được dùng từ instance) đang được dùng từ một IP ngoài AWS. Thường là ai đó đã lấy được credential tạm từ instance (SSRF vào 169.254.169.254, hoặc dump từ máy bị xâm nhập) và mang về máy họ gọi API. Đây là một trong những finding nghiêm trọng nhất.

1. GuardDuty biết bằng cách nào

CloudTrail ghi: API call X, bởi role session của shop-app-ec2-role,
                từ source IP 198.51.100.7
GuardDuty so:   198.51.100.7 không phải IP của AWS; role này là instance profile role
                → credential đang chạy ngoài EC2 → finding High

GuardDuty đọc thẳng CloudTrail, VPC Flow Logs, DNS logs từ bên trong AWS (không cần bạn bật Flow Logs hay tạo trail; nó dùng nguồn độc lập), nên "không cài gì" vẫn thấy. Phiên bản .InsideAWS là credential bị dùng từ account AWS khác.

2. Xử lý ngay (runbook ngắn)

1. Cô lập instance bị nghi: đổi SG của nó sang SG "quarantine" không cho inbound/outbound, không terminate (giữ bằng chứng), snapshot EBS.
2. Thu hồi credential: IAM → role shop-app-ec2-role → Revoke sessions. Nó thêm inline policy deny mọi call có aws:TokenIssueTime trước thời điểm đó. Instance khỏe mạnh sẽ tự lấy credential mới qua IMDS.

   aws iam put-role-policy --role-name shop-app-ec2-role --policy-name AWSRevokeOlderSessions \
     --policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Deny","Action":"*","Resource":"*",
       "Condition":{"DateLessThan":{"aws:TokenIssueTime":"'$(date -u +%Y-%m-%dT%H:%M:%SZ)'"}}}]}' \
     --profile shop-lab

3. Xem kẻ đó đã làm gì: CloudTrail Lake / Athena lọc theo userIdentity.sessionContext.sessionIssuer.userName = shop-app-ec2-role và sourceIPAddress lạ. Detective dựng graph nhanh hơn nếu đã bật.
4. Bịt lỗ: bắt buộc IMDSv2 (HttpTokens=required) trên launch template shop-lt, SSRF kiểu GET đơn giản không lấy được token; giới hạn HttpPutResponseHopLimit=1 để container không với tới. Sửa code nếu có SSRF.
5. Tự động hóa: EventBridge rule bắt finding GuardDuty severity ≥ 7 → Lambda gắn SG quarantine + SNS shop-security-alerts. Security Hub có custom action gửi sang SSM Automation runbook.

aws ec2 modify-launch-template ... # hoặc sửa trực tiếp instance đang chạy:
aws ec2 modify-instance-metadata-options --instance-id $INSTANCE_ID \
  --http-tokens required --http-put-response-hop-limit 1 --http-endpoint enabled \
  --region $AWS_REGION --profile shop-lab

3. Trong đề thi

"GuardDuty finding shows EC2 credentials used from outside AWS, what should SA do FIRST?" → cô lập instance và revoke session/rotate credential; đáp án bẫy thường là "terminate instance" (mất bằng chứng) hoặc "disable GuardDuty". "Prevent SSRF from stealing instance credentials" → IMDSv2 required.

Bạn hiểu đúng ở điểm quan trọng nhất: nếu backend chỉ validate JWT thì user pool là đủ, không cần identity pool. Identity pool chỉ xuất hiện khi frontend/mobile cần gọi dịch vụ AWS trực tiếp.

1. Keycloak → Cognito user pool: được và mất

Đáng đổi khi: team nhỏ không muốn vận hành IdP, cần social login/MFA nhanh, chạy toàn bộ trên AWS. Không đáng khi: đã có flow phức tạp trên Keycloak, cần SAML IdP cho đối tác, hoặc cần multi-cloud. Với Spring, phần resource server gần như không đổi: chỉ đổi issuer-uri và tên claim group (cognito:groups thay realm_access.roles).

2. Khi nào thêm identity pool

Trường hợp A: Web/mobile ──JWT──► Spring Boot ──SDK──► S3 (presigned URL, upload qua backend)
   → chỉ cần user pool. Backend dùng role ECS/EC2 để gọi S3.

Trường hợp B: Mobile app upload ảnh 50 MB thẳng lên S3, không muốn đi qua backend
   Mobile ──id_token──► Identity pool ──AssumeRoleWithWebIdentity──► credential tạm 1 giờ
          ──credential──► S3 PutObject s3://shop-app-assets-123/users/${sub}/avatar.jpg
   IAM policy của role "authenticated":
     Resource: arn:aws:s3:::shop-app-assets-${ACCOUNT_ID}/users/${cognito-identity.amazonaws.com:sub}/*
   → mỗi user chỉ ghi được thư mục của mình, không cần backend trung gian.

Trường hợp C: Khách chưa đăng nhập xem catalog trong DynamoDB qua AppSync/API trực tiếp
   → identity pool với "unauthenticated identities" (guest role chỉ có quyền đọc).

Với shop-app hiện tại, upload ảnh đi qua presigned URL do backend cấp (22.6) là đủ và kiểm soát tốt hơn; identity pool để khi làm mobile app nặng offline/direct-to-AWS. Đề thi: cứ thấy "mobile users need temporary AWS credentials to access S3/DynamoDB directly" là identity pool; "sign-up/sign-in, MFA, social login" là user pool.

Lab 22.20: WAF trước shop-alb, GuardDuty và Security Hub

Mục tiêu

• Web ACL shop-waf gắn vào shop-alb với 2 managed rule group và 1 rate-based rule trên /login; bắn 400 request trong 1 phút từ một IP thì bắt đầu nhận 403.
• WAF log ghi vào CloudWatch Logs group aws-waf-logs-shop; Logs Insights đếm được số request bị block theo IP.
• GuardDuty bật (trial 30 ngày), sinh sample findings và thấy ít nhất 1 finding High.
• Security Hub bật với standard AWS Foundational Security Best Practices, nhận finding từ GuardDuty; EventBridge rule đẩy finding High về SNS email.

Chi phí & thời gian

• WAF: không Free Tier. Web ACL tính theo tháng (khoảng vài USD/tháng, prorate theo giờ), mỗi rule/rule group tính thêm theo tháng, và tính theo triệu request. Lab vài giờ chỉ tốn cent.
• ALB shop-alb và EC2 phải chạy: ALB không Free Tier (theo giờ + LCU).
• GuardDuty: 30 ngày trial miễn phí lần đầu bật trong account/region; sau đó tính theo GB log. Security Hub: 30 ngày trial; sau đó theo số security check và finding ingest. Inspector (thử thêm): 15 ngày trial.
• Thời gian: 60–75 phút.

Chuẩn bị

• ALB shop-alb + target group shop-tg + ASG shop-asg đang chạy từ 22.5; app trả 200 ở /actuator/health và có endpoint /login (trả 401 hoặc 200 đều được, miễn ALB forward).
• Profile shop-lab; jq và hey hoặc ab (ApacheBench) để bắn tải.

export AWS_REGION=ap-southeast-1
export ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text --profile shop-lab)
export MY_EMAIL=you@example.com
export ALB_ARN=$(aws elbv2 describe-load-balancers --names shop-alb \
  --query 'LoadBalancers[0].LoadBalancerArn' --output text --region $AWS_REGION --profile shop-lab)
export ALB_DNS=$(aws elbv2 describe-load-balancers --names shop-alb \
  --query 'LoadBalancers[0].DNSName' --output text --region $AWS_REGION --profile shop-lab)
curl -s -o /dev/null -w "%{http_code}\n" http://$ALB_DNS/actuator/health   # 200

Các bước

Bước 1. Tạo Web ACL với managed rules + rate-based rule.

cat > shop-waf-rules.json <<'EOF'
[
  {
    "Name": "aws-common",
    "Priority": 0,
    "OverrideAction": {"None": {}},
    "Statement": {"ManagedRuleGroupStatement": {
      "VendorName": "AWS", "Name": "AWSManagedRulesCommonRuleSet"}},
    "VisibilityConfig": {"SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true,
                         "MetricName": "aws-common"}
  },
  {
    "Name": "aws-sqli",
    "Priority": 1,
    "OverrideAction": {"None": {}},
    "Statement": {"ManagedRuleGroupStatement": {
      "VendorName": "AWS", "Name": "AWSManagedRulesSQLiRuleSet"}},
    "VisibilityConfig": {"SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true,
                         "MetricName": "aws-sqli"}
  },
  {
    "Name": "rate-login",
    "Priority": 2,
    "Action": {"Block": {"CustomResponse": {"ResponseCode": 429}}},
    "Statement": {"RateBasedStatement": {
      "Limit": 300,
      "EvaluationWindowSec": 60,
      "AggregateKeyType": "IP",
      "ScopeDownStatement": {"ByteMatchStatement": {
        "FieldToMatch": {"UriPath": {}},
        "PositionalConstraint": "STARTS_WITH",
        "SearchString": "/login",
        "TextTransformations": [{"Priority": 0, "Type": "LOWERCASE"}]}}}},
    "VisibilityConfig": {"SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true,
                         "MetricName": "rate-login"}
  }
]
EOF

aws wafv2 create-web-acl --name shop-waf --scope REGIONAL \
  --default-action Allow={} \
  --rules file://shop-waf-rules.json \
  --visibility-config SampledRequestsEnabled=true,CloudWatchMetricsEnabled=true,MetricName=shop-waf \
  --tags Key=Project,Value=shop-app Key=Env,Value=lab \
  --region $AWS_REGION --profile shop-lab

export WEB_ACL_ARN=$(aws wafv2 list-web-acls --scope REGIONAL \
  --query "WebACLs[?Name=='shop-waf'].ARN" --output text --region $AWS_REGION --profile shop-lab)
export WEB_ACL_ID=$(aws wafv2 list-web-acls --scope REGIONAL \
  --query "WebACLs[?Name=='shop-waf'].Id" --output text --region $AWS_REGION --profile shop-lab)

Console: WAF & Shield → Web ACLs → Region: Asia Pacific (Singapore) → Create web ACL → Name shop-waf, Resource type: Regional → Add rules: Add managed rule groups (Core rule set, SQL database) → Add my own rules: Rule builder → Rate-based rule, limit 300, window 1 minute, Only consider requests that match: URI path starts with /login → Action Block, custom response 429.

Ghi chú: ngưỡng tối thiểu của rate-based rule phụ thuộc cửa sổ (1 phút: tối thiểu khoảng vài chục request); nếu API báo lỗi ngưỡng, tăng Limit lên theo thông báo.

Bước 2. Gắn Web ACL vào ALB.

aws wafv2 associate-web-acl --web-acl-arn $WEB_ACL_ARN --resource-arn $ALB_ARN \
  --region $AWS_REGION --profile shop-lab

aws wafv2 get-web-acl-for-resource --resource-arn $ALB_ARN \
  --query 'WebACL.Name' --region $AWS_REGION --profile shop-lab   # "shop-waf"

Console: Web ACL shop-waf → Associated AWS resources → Add AWS resources → Application Load Balancer → shop-alb.

Bước 3. Bật WAF logging ra CloudWatch Logs. Tên log group bắt buộc bắt đầu bằng aws-waf-logs-.

aws logs create-log-group --log-group-name aws-waf-logs-shop \
  --tags Project=shop-app,Env=lab --region $AWS_REGION --profile shop-lab
aws logs put-retention-policy --log-group-name aws-waf-logs-shop --retention-in-days 7 \
  --region $AWS_REGION --profile shop-lab

aws wafv2 put-logging-configuration --logging-configuration "{
  \"ResourceArn\": \"$WEB_ACL_ARN\",
  \"LogDestinationConfigs\": [\"arn:aws:logs:$AWS_REGION:$ACCOUNT_ID:log-group:aws-waf-logs-shop\"]
}" --region $AWS_REGION --profile shop-lab

Console: Web ACL shop-waf → Logging and metrics → Enable → CloudWatch Logs log group → aws-waf-logs-shop.

Bước 4. Thử SQL injection và brute force.

# SQLi: mong đợi 403 (managed rule SQLi block)
curl -s -o /dev/null -w "%{http_code}\n" "http://$ALB_DNS/api/products?id=1'%20OR%201=1--"

# Request bình thường: 200
curl -s -o /dev/null -w "%{http_code}\n" "http://$ALB_DNS/api/products?id=1"

# Brute force /login: 400 request trong ~60 giây từ 1 IP
hey -n 400 -c 10 -q 7 http://$ALB_DNS/login
# hoặc: ab -n 400 -c 10 http://$ALB_DNS/login
# Sau đó:
for i in $(seq 1 5); do curl -s -o /dev/null -w "%{http_code} " http://$ALB_DNS/login; done; echo
# Mong đợi: 429 429 429 429 429 (rate rule cần ~30–60 giây để kích hoạt sau khi vượt ngưỡng)

Bước 5. Bật GuardDuty và sinh sample findings.

DETECTOR_ID=$(aws guardduty create-detector --enable \
  --finding-publishing-frequency FIFTEEN_MINUTES \
  --tags Project=shop-app,Env=lab \
  --query DetectorId --output text --region $AWS_REGION --profile shop-lab)
echo $DETECTOR_ID

# Sinh finding mẫu (không có tấn công thật, chỉ để học cách đọc)
aws guardduty create-sample-findings --detector-id $DETECTOR_ID \
  --finding-types UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS \
                  CryptoCurrency:EC2/BitcoinTool.B!DNS \
                  Recon:EC2/PortProbeUnprotectedPort \
  --region $AWS_REGION --profile shop-lab

aws guardduty list-findings --detector-id $DETECTOR_ID \
  --finding-criteria '{"Criterion":{"severity":{"Gte":7}}}' \
  --region $AWS_REGION --profile shop-lab

Console: GuardDuty → Get Started → Enable GuardDuty (30-day free trial) → Settings → Sample findings → Generate sample findings → Findings (lọc "[SAMPLE]").

Bước 6. Bật Security Hub và standard.

aws securityhub enable-security-hub --enable-default-standards \
  --tags Project=shop-app,Env=lab --region $AWS_REGION --profile shop-lab

aws securityhub get-enabled-standards --query 'StandardsSubscriptions[].StandardsArn' \
  --region $AWS_REGION --profile shop-lab
# Mong đợi có aws-foundational-security-best-practices và cis-aws-foundations-benchmark

# GuardDuty tự tích hợp; kiểm tra:
aws securityhub list-enabled-products-for-import --region $AWS_REGION --profile shop-lab | grep -i guardduty

Console: Security Hub → Go to Security Hub → Enable AWS Foundational Security Best Practices → Enable Security Hub. Sau 15–30 phút: Findings → filter Product name = GuardDuty.

Bước 7. EventBridge: finding High → SNS email.

TOPIC_ARN=$(aws sns create-topic --name shop-security-alerts \
  --tags Key=Project,Value=shop-app Key=Env,Value=lab \
  --query TopicArn --output text --region $AWS_REGION --profile shop-lab)
aws sns subscribe --topic-arn $TOPIC_ARN --protocol email --notification-endpoint $MY_EMAIL \
  --region $AWS_REGION --profile shop-lab   # confirm trong email

aws events put-rule --name shop-sechub-high \
  --event-pattern '{
    "source": ["aws.securityhub"],
    "detail-type": ["Security Hub Findings - Imported"],
    "detail": {"findings": {"Severity": {"Label": ["HIGH","CRITICAL"]},
                            "RecordState": ["ACTIVE"]}}
  }' --tags Key=Project,Value=shop-app Key=Env,Value=lab \
  --region $AWS_REGION --profile shop-lab

aws events put-targets --rule shop-sechub-high \
  --targets "Id=sns,Arn=$TOPIC_ARN,InputTransformer={InputPathsMap={title=\$.detail.findings[0].Title,sev=\$.detail.findings[0].Severity.Label,res=\$.detail.findings[0].Resources[0].Id},InputTemplate='\"[]