AWS Security Hub: Tự Động Hóa Bảo Mật Cloud Toàn Diện
Danh Mục Bài Viết
- 1. Security Hub là gì và tại sao nó khác với GuardDuty hay Config?
- 2. Kiến trúc triển khai thực tế: Multi-Account với AWS Organizations
- 3. Xây dựng automated response: từ finding đến action trong 5 phút
- 4. Custom Insights và Security Score: đo lường thực chất
- 5. Ổ gà thường gặp khi triển khai Security Hub
- 6. FAQ
- 7. Từ "bơi trong cảnh báo" đến "biết mình đang bảo mật ở đâu"
Mình từng làm việc với một hệ thống AWS có hơn 20 tài khoản, và mỗi lần có security alert là một cơn ác mộng: GuardDuty báo tài khoản A, Config noncompliant tài khoản B, Inspector tìm CVE ở tài khoản C — tất cả đổ về ba bốn chỗ khác nhau. Team mình ngồi triage cả buổi sáng mà vẫn không biết cái nào cần fix trước. Đó là lúc Security Hub trở thành thứ không thể thiếu.
Security Hub là gì và tại sao nó khác với GuardDuty hay Config?
Nhiều bạn nhầm Security Hub với GuardDuty vì cả hai đều liên quan đến bảo mật AWS. Khổ nỗi là chúng làm hai việc hoàn toàn khác nhau.
GuardDuty là threat detection — nó phân tích VPC Flow Logs, CloudTrail, DNS logs để phát hiện hành vi bất thường (ví dụ: EC2 instance đang giao tiếp với IP độc hại, hay có ai đang brute-force SSH). GuardDuty giỏi phát hiện nhưng không có khả năng tổng hợp hay tương quan sự kiện.
AWS Config theo dõi compliance — resource configuration có đúng với policy không. Nếu bạn bật rule "no-public-s3-bucket", Config sẽ cảnh báo khi có bucket public. Nhưng Config không quan tâm đến threat.
AWS Security Hub là lớp orchestration ở trên cùng. Nó thu thập findings từ GuardDuty, Config, Inspector, Firewall Manager, IAM Access Analyzer, Macie và cả third-party tools (Aqua Security, Palo Alto, CrowdStrike…), chuẩn hóa chúng về định dạng ASFF (Amazon Security Finding Format), rồi cho bạn filter, prioritize, tạo insight, và trigger automation từ một nơi duy nhất.
Nói thật thì: nếu bạn chỉ có một tài khoản AWS và traffic thấp, Security Hub là overkill. Nhưng từ 3 tài khoản trở lên hoặc khi bạn phải tuân thủ PCI-DSS / SOC2 / CIS Benchmark, nó là bắt buộc.
Kiến trúc triển khai thực tế: Multi-Account với AWS Organizations
Security Hub hoạt động theo mô hình administrator account + member accounts. Đây là cách setup mình đang dùng trong production:
1. Chọn Security Account làm administrator: Đừng dùng Management Account của Organization — hãy tạo riêng một Security Account (dedicated security tooling account). Account này sẽ aggregate findings từ tất cả member accounts.
2. Enable Security Hub qua Organizations:
# Bật auto-enable cho member accounts mới
aws securityhub update-organization-configuration \
--auto-enable \
--region ap-northeast-1
# Bật cho tất cả existing accounts
aws securityhub create-members \
--account-details '[{"AccountId":"123456789012","Email":"[email protected]"}]'3. Enable các standards phù hợp: AWS Foundational Security Best Practices (FSBP) là điểm khởi đầu tốt nhất. CIS AWS Foundations Benchmark nếu bạn cần compliance report. PCI-DSS nếu xử lý thanh toán.
aws securityhub batch-enable-standards \
--standards-subscription-requests \
'[{"StandardsArn":"arn:aws:securityhub:ap-northeast-1::standards/aws-foundational-security-best-practices/v/1.0.0"}]'4. Tích hợp GuardDuty và Inspector: Nếu bạn đã enable GuardDuty trong Organization, findings sẽ tự động flow vào Security Hub. Inspector 2 cũng tương tự — chỉ cần check "Integration" trong Security Hub console.
Xây dựng automated response: từ finding đến action trong 5 phút
Đây là phần hay nhất và cũng là phần mà hầu hết team bỏ qua. Security Hub integrate với EventBridge — mỗi khi có finding mới hoặc finding thay đổi status, một event sẽ được emit. Từ đó bạn có thể trigger Lambda, Step Functions, hay Systems Manager Automation.
Ví dụ thực tế: Tự động isolate EC2 bị compromise
Khi GuardDuty phát hiện một EC2 instance đang communicate với C2 server, finding sẽ vào Security Hub với severity HIGH. Workflow của mình:
# EventBridge rule
{
"source": ["aws.securityhub"],
"detail-type": ["Security Hub Findings - Imported"],
"detail": {
"findings": {
"Severity": {"Label": ["HIGH", "CRITICAL"]},
"Types": [{"prefix": "TTPs/Command and Control"}]
}
}
}EventBridge trigger Lambda function → Lambda đọc instance ID từ finding → gọi EC2 modify-instance-attribute để thay security group bằng một "quarantine SG" (chỉ allow outbound tới Security account) → gửi alert Slack → tạo Jira ticket → cập nhật finding status sang "IN_PROGRESS".
Toàn bộ quy trình từ lúc GuardDuty detect đến lúc instance bị isolate: dưới 3 phút. So với cách thủ công (ai đó nhìn thấy email, forward, meeting, quyết định…): cả ngày.
AWS Security Hub Automation Rules (ra mắt 2023): Nếu không muốn viết Lambda, AWS có built-in automation rules. Bạn define criteria (severity, finding type, resource type) và action (update workflow status, suppress finding, send notification). Không cần code.
Mẹo: Tạo một "suppression rule" ngay từ đầu để filter noise. Ví dụ: suppress tất cả findings liên quan đến CloudTrail S3 access logging nếu bạn đã có centralized logging setup. Không có suppression rule, dashboard của bạn sẽ ngập trong false positives và team sẽ bắt đầu ignore alerts — đây là recipe cho disaster.
Custom Insights và Security Score: đo lường thực chất
Security Hub có khái niệm Security Score — tính dựa trên % controls đang pass trong các standards bạn enable. Score 100% là impossible trong môi trường production thực tế (luôn có legacy resource hay exception), nhưng nó là metric tốt để track progress theo tuần.
Custom Insights cho phép bạn tạo query trên findings. Một số insight mình dùng thường xuyên:
• Top 10 resources nhiều findings nhất: Identify "problem children" — thường là EC2 instance cũ hoặc S3 bucket chưa được cleanup.
• Findings by severity chưa assign owner: CRITICAL finding mà không có ai nhận? Đây là KPI tracking dành cho team lead.
• Mean time to remediation: Từ khi finding ACTIVE đến RESOLVED mất bao lâu. Target của mình: CRITICAL dưới 4h, HIGH dưới 24h.
Ổ gà thường gặp khi triển khai Security Hub
1. Enable tất cả regions mà không cần: Security Hub billed theo số findings. Nếu bạn enable tất cả 30+ regions AWS nhưng chỉ dùng 3, bạn đang trả tiền cho noise. Chỉ enable region bạn thực sự deploy resources.
2. Không config aggregation: Nếu không setup Cross-Region Aggregation, mỗi region sẽ có một dashboard riêng. Bạn sẽ phải mở 10 tab để xem toàn bộ picture. Enable aggregation vào Security Account với designated aggregation region.
3. Suppress quá tay: Team mới thường suppress mọi finding "phiền" để dashboard trông sạch. Rồi một ngày có breach thực sự và không ai nhìn thấy. Suppression phải có review cycle — ít nhất hàng quý.
4. Không integrate SIEM: Security Hub không lưu findings quá 90 ngày. Nếu cần forensics sau 3 tháng (và bạn sẽ cần, trust me), phải archive findings ra S3 hoặc push về SIEM (Splunk, OpenSearch). Setup S3 export qua EventBridge + Kinesis Firehose từ ngày đầu.
FAQ
Q: Security Hub có tốn kém không?A: Giá tính theo số findings và số control evaluations mỗi tháng. 10,000 findings đầu tiên trong 30 ngày free trial. Sau đó khoảng $0.0010/finding và $0.0008/control evaluation. Với môi trường vừa (5-10 accounts, 50k findings/tháng), tổng khoảng $50-100/tháng — rẻ hơn nhiều so với cost của một security incident không được phát hiện kịp.
Q: Security Hub có thể thay thế SIEM không?A: Không. Security Hub là aggregation và orchestration layer cho AWS findings. SIEM (Splunk, OpenSearch, Datadog) thu thập logs từ mọi nguồn, correlate events phức tạp, và lưu trữ dài hạn. Hai công cụ bổ sung cho nhau chứ không thay thế nhau. Dùng Security Hub làm nguồn data feed vào SIEM của bạn.
Q: Có thể integrate third-party tools không?A: Có. Security Hub hỗ trợ hơn 60 partner integrations, bao gồm Aqua Security, CrowdStrike, Palo Alto Prisma Cloud, Wiz, Tenable. Findings từ các tool này sẽ được normalize về ASFF và hiển thị cùng với AWS-native findings. Đặc biệt hữu ích nếu bạn đang migrate từ on-premise và đã có SIEM/CSPM tool cũ.
Q: Security Hub vs AWS Control Tower Guardrails?A: Control Tower Guardrails là preventive controls — ngăn không cho tạo resource vi phạm policy (ví dụ: SCP chặn không cho tắt CloudTrail). Security Hub là detective controls — phát hiện sau khi vi phạm xảy ra. Best practice là dùng cả hai: Guardrails để prevent, Security Hub để detect những gì Guardrails bỏ sót.
Từ "bơi trong cảnh báo" đến "biết mình đang bảo mật ở đâu"
Cái giá trị lớn nhất của Security Hub không phải là nó catch được nhiều finding hơn — mà là nó giúp bạn hiểu security posture của hệ thống. Từ chỗ có 500 alerts không biết xử lý cái nào, bạn có dashboard, score, và automation để tập trung vào đúng thứ quan trọng.
Nếu bạn đang bắt đầu: enable Security Hub với FSBP standard, integrate GuardDuty, và tạo một automation rule cho CRITICAL findings. Chỉ ba bước đó thôi là đã tốt hơn 80% setup mình từng thấy. Còn muốn đi xa hơn — custom insights, SIEM integration, automated remediation playbooks — thì đó là bài tiếp theo.
