經過了監控系統的建置，小李的餐廳帝國現在擁有了完整的可觀測性。CloudWatch 就像一雙銳利的眼睛，時刻監控著系統的健康狀況。但就在小李以為一切都在掌控之中時，一個意想不到的事件讓他意識到，監控系統雖然能告訴他「發生了什麼」，卻無法告訴他「是否安全」。
這個故事要從一個平靜的週五下午說起...
2024年3月的一個週五下午，小李正在辦公室裡查看 CloudWatch 儀表板，對於系統穩定運行感到滿意。所有指標都顯示綠燈：CPU 使用率正常、記憶體充足、網路流暢。
突然，他的手機響了。
「小李先生嗎？我是資安公司 SecureTech 的王經理。我們在例行的網路安全掃描中發現，您的系統可能存在一些安全漏洞...」
小李的心一沉。「什麼漏洞？我們的監控系統顯示一切正常啊！」
「監控系統主要關注效能和可用性，但安全是另一個層面的問題，」王經理解釋，「就像您的餐廳可能營業正常，但廚房的食材可能已經過期了。」
小李立刻打電話給小張：「我們的系統被發現有安全漏洞，但 CloudWatch 沒有任何警告！」
小張趕到辦公室，聽完事情經過後說：「這很正常。CloudWatch 是監控系統效能的，不是檢查安全漏洞的。這就像體溫計只能測量體溫，不能檢查是否有癌細胞一樣。」
「那我們該怎麼辦？」小李焦急地問。
「我們需要 AWS Inspector，」小張說，「它就像系統的『健康檢查醫生』，專門檢查安全漏洞和合規性問題。」
小張在白板上畫了兩個圓圈：
監控系統（CloudWatch）
安全檢查（Inspector）
「兩者都很重要，但解決的是不同的問題，」小張說，「一個餐廳可能生意很好（監控正常），但衛生條件很差（安全有問題）。」
「AWS Inspector 就像一位專業的安全醫生，」小張開始解釋，「它會定期檢查你的系統，找出潛在的安全問題，就像醫生做健康檢查一樣。」
小李好奇地問：「它具體檢查什麼？」
小張列出了 Inspector 的主要功能：
1. 漏洞評估
「它會掃描你的應用程式和作業系統，找出已知的安全漏洞。就像檢查餐廳是否使用了過期食材。」
2. 網路可達性分析
「檢查網路配置是否安全，比如是否有不必要的開放端口。就像檢查餐廳的門窗是否都有適當的安全措施。」
3. 合規性檢查
「確保系統符合各種安全標準和最佳實踐。就像確保餐廳符合衛生局的規定。」
小張用餐廳的比喻來解釋 Inspector 的工作原理：
1. 自動發現
「就像衛生檢查員會自動找到所有需要檢查的區域，Inspector 會自動發現你的 EC2 實例和容器映像檔。」
2. 持續掃描
「不是一次性檢查就結束，而是持續監控。就像餐廳需要定期的衛生檢查。」
3. 風險評分
「每個發現的問題都會有風險評分，從低到高，幫你優先處理最重要的問題。」
4. 修復建議
「不只告訴你有問題，還會建議如何修復。就像醫生不只診斷疾病，還會開處方。」
小張打開 AWS Console，展示 Inspector 的實際應用：
「還記得我們的微服務架構嗎？每個服務都打包成 Docker 映像檔存放在 ECR 中。Inspector 會自動掃描這些映像檔。」
她指著螢幕上的掃描結果：
映像檔：payment-service:v2.1
掃描結果：
- 高風險漏洞：2 個
- 中風險漏洞：5 個
- 低風險漏洞：12 個
- 總風險評分：8.5/10
「你看這個支付服務的映像檔，」小張說，「有 2 個高風險漏洞。點進去可以看到詳細資訊。」
漏洞詳情：
「這就像發現餐廳使用的食用油已經變質，需要立即更換，」小張解釋。
「Inspector 發現問題後，我們需要及時收到通知，」小張說，「就像火災警報器發現火災要立即響鈴一樣。」
她展示了如何設定 Inspector 的通知：
1. EventBridge 整合
「Inspector 會將發現的問題發送到 EventBridge，這是 AWS 的事件中心。」
2. SNS 通知
「然後透過 SNS 發送郵件、簡訊或 Slack 通知。」
3. 自動化回應
「甚至可以觸發 Lambda 函數自動處理某些問題。」
小張建議建立分級的告警策略：
緊急告警（Critical）
重要告警（High）
一般告警（Medium/Low）
小李的手機響了，收到一則 Inspector 告警：
🚨 AWS Inspector 安全告警
集群：production-eks
嚴重程度：HIGH
問題：CVE-2024-1234 - OpenSSL 漏洞
影響範圍：
- payment-service 映像檔
- 可能導致資料洩露
建議動作：
1. 更新 OpenSSL 到 3.0.8 版本
2. 重新建置映像檔
3. 部署到生產環境
詳細資訊：https://console.aws.amazon.com/inspector/...
「這個通知很清楚，」小李說，「告訴我問題是什麼、影響範圍、該怎麼處理。」
小張教小李如何有效地處理 Inspector 發現的問題：
1. 風險評估
「不是所有漏洞都需要立即修復，要根據實際風險來排優先順序。」
她展示了風險評估矩陣：
影響程度 × 利用可能性 = 風險等級
高影響 × 高可能性 = 立即修復
高影響 × 低可能性 = 計劃修復
低影響 × 高可能性 = 監控觀察
低影響 × 低可能性 = 接受風險
2. 修復策略
立即修復（Critical）
計劃修復（High）
監控觀察（Medium）
「對於一些常見的問題，我們可以設定自動修復，」小張說。
她展示了幾個自動化範例：
1. 自動更新系統套件
# Lambda 函數自動執行
aws ssm send-command \
--document-name "AWS-RunShellScript" \
--parameters 'commands=["yum update -y"]' \
--targets "Key=tag:Environment,Values=production"
2. 自動重建映像檔
「當 Inspector 發現映像檔漏洞時，可以觸發 CodeBuild 自動重建映像檔。」
3. 自動網路配置修復
「發現不安全的安全群組規則時，自動移除或修改。」
「修復完成後，要驗證問題是否真的解決了，」小張強調。
1. 重新掃描
「Inspector 會在修復後自動重新掃描，確認漏洞已修復。」
2. 功能測試
「確保修復沒有影響系統功能。」
3. 效能測試
「確保修復沒有影響系統效能。」
「Inspector 不是孤立的服務，」小張說，「它可以與其他 AWS 安全服務整合，形成完整的安全管理體系。」
她展示了 Security Hub 的整合：
安全儀表板
「Security Hub 會收集來自 Inspector、GuardDuty、Config 等服務的安全發現，提供統一視圖。」
安全評分
「根據所有安全發現計算整體安全評分，就像信用評分一樣。」
合規性儀表板
「統一顯示各種合規標準的符合狀況。」
「GuardDuty 負責威脅檢測，Inspector 負責漏洞掃描，」小張解釋，「兩者結合可以提供更全面的安全保護。」
GuardDuty：「這是保全人員，監控是否有可疑活動」
Inspector：「這是建築檢查員，檢查建築結構是否安全」
「AWS Config 可以檢查資源配置是否符合安全最佳實踐，」小張說，「與 Inspector 的漏洞掃描互補。」
範例 Config 規則：
經過這次深入了解 AWS Inspector，小李對安全有了全新的認識。
「我以前以為有了監控系統就夠了，」小李感慨地說，「現在才知道安全是另一個重要的維度。」
小張點頭：「監控告訴我們系統是否健康，安全檢查告訴我們系統是否安全。兩者都不可缺少。」
「最重要的是建立安全文化，」小張強調，「讓整個團隊都重視安全，而不只是依賴工具。」
她建議建立以下安全實踐：
1. 定期安全會議
「每週檢討安全發現和修復進度。」
2. 安全培訓
「定期培訓團隊成員安全知識和最佳實踐。」
3. 安全指標
「建立安全 KPI，比如漏洞修復時間、安全評分等。」
4. 事件回應計劃
「制定安全事件的應對流程。」
如果你也想為自己的 AWS 環境建立安全檢查，記住這些要點：
「安全就像健康一樣，」小張最後說，「平時的預防和檢查比生病後的治療更重要。AWS Inspector 就是我們的『健康檢查醫生』，幫助我們及早發現和解決安全問題。」
小李深有感觸地說：「從今天開始，安全檢查將成為我們日常運營的重要組成部分。畢竟，一個不安全的系統，再高的效能也沒有意義。」
這個故事告訴我們，在現代的雲端環境中，安全不是可選項，而是必需品。AWS Inspector 提供了強大的安全掃描能力，但更重要的是建立安全意識和文化。記住，最好的安全策略是預防，而不是事後補救。
iThome鐵人賽
看影片追技術