自從上次的安全危機後，小李深刻體會到安全的重要性。在小張的協助下，他們成功部署了 AWS Inspector，就像為餐廳帝國安裝了專業的「建築安全檢查員」，定期檢查系統是否有漏洞。
但就在小李以為安全防護已經足夠時，一個深夜的異常事件讓他意識到，光有「建築檢查員」還不夠，他們還需要一個 24 小時不眠不休的「智能保全」...
2024年4月的一個深夜，小李被手機鈴聲驚醒。看了看時間：凌晨 3:17。
「誰會在這個時候打電話？」小李迷迷糊糊地接起電話。
「小李先生，我是 AWS 技術支援的 David。我們偵測到您的帳戶有異常活動，建議您立即檢查。」
小李瞬間清醒：「什麼異常活動？」
「有人嘗試從俄羅斯的 IP 位址存取您的 S3 儲存桶，而且嘗試了多次不同的存取金鑰。雖然都被拒絕了，但這是典型的攻擊行為。」
小李的心跳加速：「我們的 Inspector 沒有發現這個問題啊！」
「Inspector 主要檢查系統漏洞，但這是即時的威脅攻擊，」David 解釋，「您需要的是 GuardDuty，它專門監控這類威脅行為。」
小李立刻打電話給小張，雖然已經是深夜，但小張還是趕到了辦公室。
「這就是我一直想跟你提的，」小張一邊查看日誌一邊說，「Inspector 就像建築檢查員，檢查房子結構是否安全。但 GuardDuty 就像保全人員，監控是否有小偷想要闖入。」
小李焦急地問：「那我們現在怎麼辦？」
「首先，我們要啟用 GuardDuty，讓它開始監控。然後分析這次攻擊的詳細情況，確保沒有造成實際損害。」
小張開始分析這次攻擊事件：
攻擊時間軸：
「幸好我們的 IAM 權限設定得當，攻擊者沒有成功，」小張說，「但如果我們有 GuardDuty，在 02:45 就會收到警報，而不是等到 AWS 技術支援發現。」
小李恍然大悟：「所以 GuardDuty 就像 24 小時的保全監控系統？」
「沒錯，而且是 AI 智能保全，能夠識別各種攻擊模式。」
小張開始詳細解釋 GuardDuty：
「GuardDuty 就像一個超級智能的保全系統，它會分析你 AWS 環境中的所有活動，識別可疑行為。」
她在白板上畫了一個對比圖：
傳統保全 vs AI 保全
傳統保全：
GuardDuty AI 保全：
「GuardDuty 會監控三大類資料來源，」小張解釋：
1. VPC Flow Logs（網路流量）
「就像監控餐廳的人員進出，看誰在什麼時候從哪裡來，要去哪裡。」
範例威脅：
2. DNS Logs（網域查詢）
「監控系統查詢了哪些網域，就像監控員工撥打了哪些電話號碼。」
範例威脅：
3. CloudTrail Event Logs（API 呼叫）
「記錄所有 AWS API 的使用，就像監控誰使用了哪些鑰匙開了哪些門。」
範例威脅：
「GuardDuty 最厲害的地方是它的機器學習能力，」小張說。
威脅情報整合：
行為分析：
情境感知：
小張展示了 GuardDuty 如何檢測剛才的攻擊：
威脅類型：UnauthorizedAPICall:IAMUser/MaliciousIPCaller.Custom
嚴重程度：HIGH (7.2/10)
描述：來自已知惡意 IP 的 API 呼叫
詳細資訊：
- 攻擊者 IP：185.220.xxx.xxx (俄羅斯)
- 目標資源：S3 儲存桶 'production-data'
- 使用的金鑰：AKIA...（已洩露金鑰）
- 攻擊時間：2024-04-15 02:45:23 UTC
- 威脅情報：此 IP 與 APT 組織相關
「你看，GuardDuty 不只告訴我們有攻擊，還提供了完整的攻擊資訊，」小張指出，「包括攻擊者的背景、使用的工具、攻擊目標等。」
「GuardDuty 不只能檢測外部攻擊，還能發現內部威脅，」小張說。
威脅類型：Stealth:IAMUser/CloudTrailLoggingDisabled
嚴重程度：MEDIUM (5.8/10)
描述：使用者嘗試停用 CloudTrail 日誌記錄
詳細資訊：
- 使用者：john.doe@company.com
- 動作：StopLogging
- 時間：非正常工作時間（週日凌晨 2 點）
- 異常原因：該使用者從未執行過此類操作
「這可能是內部人員想要掩蓋某些行為，或者是帳戶被盜用，」小張分析。
威脅類型：CryptoCurrency:EC2/BitcoinTool.B!DNS
嚴重程度：HIGH (8.2/10)
描述：EC2 實例與已知的加密貨幣挖礦池通訊
詳細資訊：
- 受影響實例：i-1234567890abcdef0
- 挖礦池網域：pool.minergate.com
- 網路流量：異常高的出站流量
- 可能原因：惡意軟體感染或未授權使用
「這種攻擊很常見，」小張說，「攻擊者入侵系統後，利用我們的運算資源挖礦賺錢。」
威脅類型：Exfiltration:S3/MaliciousIPCaller.Custom
嚴重程度：CRITICAL (9.1/10)
描述：大量資料被下載到可疑 IP 位址
詳細資訊：
- 資料量：500 GB
- 下載時間：凌晨 3-4 點（非正常時間）
- 目標 IP：位於中國的 VPN 服務
- 存取模式：異常的批量下載
「這是最嚴重的威脅類型，」小張嚴肅地說，「可能是資料竊取。」
小張解釋 GuardDuty 的告警分級：
LOW (0.1 - 3.9)
MEDIUM (4.0 - 6.9)
HIGH (7.0 - 8.9)
CRITICAL (9.0 - 10.0)
「我們可以設定自動化回應，讓系統在檢測到威脅時自動採取行動，」小張說。
EventBridge 整合：
{
"Rules": [
{
"Name": "GuardDuty-High-Severity",
"EventPattern": {
"source": ["aws.guardduty"],
"detail": {
"severity": [7.0, 8.0, 9.0, 10.0]
}
},
"Targets": [
{
"Id": "1",
"Arn": "arn:aws:lambda:region:account:function:SecurityResponse"
}
]
}
]
}
自動回應動作：
隔離受感染的實例
停用被盜用的金鑰
阻斷惡意 IP
小張展示了如何設定多層次的通知：
即時通知（Critical/High）：
定期報告（Medium/Low）：
通知範例：
🚨 GuardDuty 緊急告警
威脅等級：CRITICAL
檢測時間：2024-04-15 14:30:25 UTC
威脅類型：資料外洩攻擊
受影響資源：
- S3 儲存桶：production-customer-data
- 可疑 IP：203.0.113.xxx (中國)
- 資料量：1.2 TB
自動回應已啟動：
✅ 阻斷可疑 IP
✅ 停用相關存取金鑰
✅ 通知法務和合規團隊
需要人工處理：
❗ 評估資料洩露範圍
❗ 通知受影響客戶
❗ 準備事件報告
詳細資訊：https://console.aws.amazon.com/guardduty/...
「當 GuardDuty 發現威脅時，我們需要進行詳細調查，」小張說，「就像警察調查案件一樣。」
調查步驟：
1. 初步評估
2. 證據收集
3. 攻擊路徑分析
4. 影響評估
「對於複雜的威脅，我們可以使用 Amazon Detective，」小張介紹，「它就像 CSI 的科學鑑識工具。」
Detective 的功能：
調查範例：
攻擊事件：EC2 實例異常行為
Detective 分析結果：
1. 14:20 - 攻擊者透過 SSH 暴力破解成功登入
2. 14:25 - 下載惡意軟體
3. 14:30 - 建立後門帳戶
4. 14:35 - 嘗試橫向移動到其他實例
5. 14:40 - 開始資料收集
6. 14:45 - GuardDuty 檢測到異常並告警
小張強調建立標準事件回應計劃的重要性：
CRITICAL 威脅回應（15 分鐘內）：
HIGH 威脅回應（1 小時內）：
MEDIUM 威脅回應（4 小時內）：
「GuardDuty 還有惡意軟體保護功能，」小張介紹，「可以掃描 EBS 卷中的惡意軟體。」
功能特色：
掃描觸發條件：
掃描結果範例：
惡意軟體掃描報告
實例：i-1234567890abcdef0
掃描時間：2024-04-15 15:30:00 UTC
掃描檔案數：1,245,678
發現威脅：3 個
威脅詳情：
1. Trojan.Win32.Agent.xxx
路徑：/tmp/malware.exe
威脅等級：HIGH
2. Backdoor.Linux.Mirai.xxx
路徑：/var/tmp/bot
威脅等級：CRITICAL
3. Coinminer.Linux.XMRig.xxx
路徑：/usr/bin/xmrig
威脅等級：MEDIUM
「GuardDuty 還可以監控容器和 Lambda 的執行時行為，」小張說。
EKS Runtime Monitoring：
Lambda Protection：
「GuardDuty 會持續更新威脅情報，」小張解釋。
威脅情報來源：
自訂威脅情報：
{
"ThreatIntelSet": {
"Name": "Company-Blacklist",
"Format": "TXT",
"Location": "s3://security-bucket/threat-intel/blacklist.txt",
"Activate": true
}
}
小張展示了 AWS 安全服務的完整架構：
AWS 安全服務生態系統
預防層：
├── IAM (身份和存取管理)
├── WAF (Web 應用程式防火牆)
├── Shield (DDoS 防護)
└── Network Firewall (網路防火牆)
檢測層：
├── GuardDuty (威脅檢測) ← 我們現在在這裡
├── Inspector (漏洞掃描)
├── Config (配置監控)
└── CloudTrail (API 審計)
回應層：
├── Security Hub (統一管理)
├── Detective (調查分析)
├── Systems Manager (修復管理)
└── Incident Manager (事件管理)
「Security Hub 是安全服務的中央控制台，」小張說，「它會收集所有安全服務的發現。」
整合效益：
Security Hub 儀表板範例：
安全狀況總覽
整體安全評分：85/100
服務狀況：
✅ GuardDuty：運行中，24 小時內 3 個發現
✅ Inspector：運行中，發現 12 個漏洞
⚠️ Config：部分合規，5 個配置問題
✅ CloudTrail：運行中，日誌完整
本週趨勢：
- 威脅檢測：↓ 15%（改善）
- 漏洞修復：↑ 30%（改善）
- 合規性：→ 持平
「我們可以建立自動化的安全工作流程，」小張展示。
範例工作流程：GuardDuty → Security Hub → 自動回應
SecurityWorkflow:
Trigger: GuardDuty Finding (Severity >= 7.0)
Steps:
1. Security Hub 接收發現
2. 評估威脅嚴重程度
3. 自動隔離受影響資源
4. 通知安全團隊
5. 建立 JIRA 事件單
6. 啟動調查流程
7. 生成初步報告
Notifications:
- Slack: #security-alerts
- Email: security-team@company.com
- SMS: 緊急聯絡人
經過這次深入了解 GuardDuty，小李對網路安全有了全新的認識。
「我現在明白了，」小李說，「安全不是一個工具，而是一個完整的體系。Inspector 檢查漏洞，GuardDuty 監控威脅，Security Hub 統一管理，每個都有自己的角色。」
小張點頭：「沒錯，就像餐廳的安全體系一樣：」
小張建議小李建立安全成熟度模型：
Level 1：基礎防護
Level 2：主動監控
Level 3：智能防禦
Level 4：自適應安全
小李開始規劃未來的安全改進：
短期目標（1 個月）：
中期目標（3 個月）：
長期目標（6 個月）：
如果你也想建立完整的威脅檢測體系，記住這些要點：
「安全是一場永無止境的戰爭，」小張最後說，「但有了 GuardDuty 這樣的 AI 智能保全，我們至少不用孤軍奮戰。它會 24 小時不眠不休地保護我們的系統，讓我們能夠專注於業務發展。」
小李深有感觸地說：「從監控系統效能，到檢查安全漏洞，再到檢測威脅攻擊，我們的安全防護體系越來越完整了。現在我終於可以安心睡覺，知道有 AI 保全在守護我們的數位帝國。」
這個故事告訴我們，在現代的雲端環境中，威脅檢測是安全防護的重要一環。AWS GuardDuty 提供了強大的 AI 威脅檢測能力，但更重要的是建立完整的安全防護體系和快速回應機制。記住，最好的安全策略是預防和早期檢測，而不是事後補救。
iThome鐵人賽
看影片追技術