上一篇透過 Metrics、Logs 與 Traces，觀察服務是否正常，並追查請求變慢的原因。
除了服務運作狀況，也需要考慮安全風險：資料庫密碼如何妥善保存？AWS 存取憑證遭到盜用時，能否發現異常並追查操作紀錄？
今天沿用 ECS 訂單系統，看看正式上線前，如何安排機密管理、操作稽核與安全事件處理。
以下是一個假設情境：
這裡其實有三種不同需求：
| 需求 | 要回答的問題 |
|---|---|
| 機密管理 | 密碼與 API Key 放在哪裡？更新後程式怎麼取得？ |
| 操作稽核 | 哪個身分在什麼時間，操作了哪些 AWS 資源？ |
| 威脅偵測與處置 | 哪些活動值得懷疑？發現後由誰處理？ |
先把問題分開，才能決定需要哪些能力。
訂單 API 需要讀取 S3，可以替 ECS Task 指定 Task Role（任務角色），讓應用程式透過 AWS SDK 使用暫時憑證，並只允許它存取需要的 Bucket 與物件，不必另外建立 IAM User，再把 Access Key 放進容器。
至於資料庫密碼、第三方物流 API Key，可以透過 AWS Systems Manager Parameter Store（參數存放區） 或 AWS Secrets Manager（機密管理服務） 集中保存，再授權應用程式讀取。
Parameter Store 可以管理一般設定與加密參數；Secrets Manager 則提供機密管理與輪替能力，選擇時除了保存方式，也要考慮這些機密多久更新一次，以及由誰負責更新。
兩者都能保存敏感資料，差異不只是「能不能加密」，還包括後續怎麼更新與維護。
| 需求 | 可以優先評估 | 需要負責的工作 |
|---|---|---|
| 服務網址、逾時秒數等一般設定 | Parameter Store | 設定版本、讀取權限與更新方式 |
| 機密數量少、很少更換，已有可靠的人工更新流程 | Parameter Store 的 SecureString | 自行安排密碼更新及應用程式驗證 |
| 需要定期輪替，且有支援的整合或輪替範本 | Secrets Manager | 設定輪替流程，驗證應用程式能使用新值 |
SecureString 是 Parameter Store 的加密參數類型，透過 AWS KMS 保護內容，但不會自動替資料庫更換密碼。
Secrets Manager 則提供機密版本與輪替能力，不過把密碼放進去，不代表所有服務都能自動完成輪替。
資料庫密碼可以採用 Secrets Manager，搭配 AWS 提供的 PostgreSQL 輪替 Lambda 範本，定期更新應用程式帳號的密碼。
這能減少自行撰寫輪替邏輯的工作，但團隊仍要設定函式權限、資料庫連線路徑，並測試輪替結果。
物流 API Key 則假設只能到廠商後台手動更換，它可以使用 SecureString，本案例為了集中管理兩種機密，選擇一併放進 Secrets Manager(但會產生額外費用)，不過 集中存放不會讓第三方 API Key 自動輪替 ，它的更新流程仍需要配合廠商提供的能力。
機密存放的位置決定了，還要確認應用程式如何讀取。
ECS 常見兩種方式：
| 取得方式 | 適合情況 | 更新時要注意什麼 |
|---|---|---|
| Task 啟動時，將機密注入環境變數 | 更新不頻繁，希望減少程式修改 | 機密更新後，需要啟動新的 Task |
| 應用程式透過 SDK 讀取並快取 | 需要在執行期間取得新值 | 程式要處理快取更新與讀取失敗 |
「注入環境變數」是指 ECS 在容器啟動前，先從 Secrets Manager 取得機密，再放進容器的環境變數，讓程式直接讀取，Secrets Manager 的內容更新後，已執行中的容器不會自動取得新值。
本案例選擇採用：
關鍵是：誰向 Secrets Manager 取得機密？
| 本案例的操作 | 誰取得機密？ | 讀取權限加在哪裡？ |
|---|---|---|
| 程式透過 SDK 取得資料庫密碼 | 容器裡的應用程式 | Task Role（任務角色） |
| 容器啟動前，取得物流 API Key 並注入環境變數 | ECS 代理程式 | Task Execution Role（任務執行角色） |
因本案例的資料庫密碼選擇應用程式透過 SDK 讀取並快取，所以會是 Task Role 需要讀取資料庫密碼的權限；Task Execution Role 則需要讀取物流 API Key 的權限，程式讀取已注入的環境變數時，不會再次向 Secrets Manager 發出請求。
兩個角色都只開放需要的機密，如果機密使用自行管理的 KMS 金鑰加密，也要確認負責取得機密的角色具有對應的解密權限。
使用 SDK 讀取密碼，仍需要設計快取更新機制，如果資料庫已改用新密碼，程式卻繼續拿快取中的舊密碼建立連線，就可能驗證失敗。
因此團隊需要處理快取更新、連線重建與失敗重試，並在上線前實際輪替一次密碼，確認應用程式能取得新值、建立新連線，且服務持續正常運作。
相關角色分工可參考：
假設有人修改訂單 API 的 IAM 權限，或讀取 S3 中的訂單檔案，事後要去哪裡找紀錄？
這是 AWS CloudTrail 負責的範圍。
先分清楚兩類事件：
| 事件類型 | 本案例的例子 |
|---|---|
| Management Events（管理事件） | 修改 IAM Role、Security Group 或 ECS 服務設定 |
| Data Events（資料事件） | 讀取、寫入 S3 中的物件 |
CloudTrail Console 的 Event history（事件歷史記錄） 可以查看目前 Region 最近 90 天的管理事件，但不包含 S3 物件讀寫的資料事件。
因此，只有在 Event history 看得到操作，還不足以完成本案例的稽核需求。
前面提到的 Event history，可以直接查看最近 90 天的管理事件，如果需要持續保存紀錄，或記錄 S3 物件讀寫，就需要另外設定 Trail（追蹤）。
Trail 是 CloudTrail 的一組記錄設定，用來指定「要記錄哪些事件」，以及「將日誌送到哪個 S3 Bucket 保存」。
假設有人使用訂單 API 的角色下載訂單檔案，事後需要知道：哪個角色在什麼時間，讀取了哪個物件？
本案例會選擇建立 Trail，除了管理事件，也啟用訂單 Bucket 的 Data Events（資料事件），記錄物件讀取與寫入，雖然會產生額外費用，但能留下檔案存取的調查依據。
這裡有兩個不同用途的 Bucket：
設定後，可以測試下載一個訂單物件，再到日誌 Bucket 檢查是否留下對應紀錄，這類資料事件通常不會出現在一般的 Event history 頁面。
CloudTrail 能記錄「哪個 AWS 角色讀取檔案」，若要進一步知道「哪位網站使用者觸發下載」，則需要搭配應用程式日誌。
CloudTrail 留下操作紀錄，但團隊通常不可能逐筆閱讀所有事件。
Amazon GuardDuty 會分析 CloudTrail 管理事件、VPC Flow Logs（網路流量紀錄）與 Route 53 Resolver DNS 查詢紀錄等資料來源，並依啟用的防護方案偵測其他資源的可疑活動。
這裡的網路流量紀錄，不代表逐一檢查所有封包內容。
GuardDuty 不需要先建立 CloudTrail Trail，就能使用支援的資料來源進行偵測，但團隊若需要長期保留稽核紀錄，仍必須另外規劃 CloudTrail。
假設 GuardDuty 偵測到：訂單 API 使用的 ECS Task Role 暫時憑證，出現與預期工作負載不符的 AWS API 呼叫行為。
GuardDuty 會產生 Finding（偵測結果），提供需要調查的線索，但此時仍無法確認已遭到入侵，需要做進一步確認。
本案例選擇的處理方式是：
其中，EventBridge 負責「符合條件時觸發後續動作」，SNS 負責「把通知送出去」，但真正的調查與處置，仍需要明確的負責人。
將前面的需求與選擇整理如下：
| 需求 | 本案例選擇 | 選擇原因 |
|---|---|---|
| 避免在容器保存長期 AWS 金鑰 | ECS Task Role | 使用暫時憑證，並依工作負載限制權限 |
| 定期更換資料庫密碼 | Secrets Manager＋PostgreSQL 輪替範本 | 減少自行撰寫輪替邏輯，仍需設定與驗證 |
| 追查設定變更與 S3 物件存取 | CloudTrail Trail＋訂單 Bucket 的資料事件 | 將操作紀錄保存到日誌 Bucket，涵蓋設定變更與物件讀寫 |
| 發現可疑 AWS 活動 | GuardDuty | 從支援的資料來源找出值得調查的活動 |
| 及時通知，又避免誤判中斷服務 | EventBridge＋SNS＋授權人員處置 | 通知自動化，高影響操作保留判斷與核准流程 |
本案例中也不會只因收到一筆 Finding，就自動停止整個訂單服務，限制 IAM 權限、隔離工作負載等操作，都有可能影響正常訂單，需要先確認範圍與回復方式。
上線前至少要確認三件事：密碼輪替後服務仍可運作、測試操作能找到稽核紀錄，以及安全通知確實送到知道如何處理的人!
到這裡，已經討論了系統上線後的部署、監控，以及機密與安全事件管理。
下一篇會進到搬遷篇，看看既有系統搬上 AWS 的情境，應該先維持原架構搬遷，還是同步改造，以及相依服務、資料同步與切換風險如何影響選擇。
iThome鐵人賽
看影片追技術