靜態密碼造成甚麼資安問題？
在實務開發中，為了方便測試或快速上線，許多團隊會將資料庫帳號與密碼直接寫在程式碼中，這種做法稱為「硬編碼」，也就是把密碼寫死在程式裡。表面上系統正常運作，但只要原始碼在某個時間點外流，這些資訊就可能成為直接的入侵入口。
然而，真正的問題並不在於「程式是否過期」，而在於密碼管理方式本身是否存在結構性缺陷。核心風險通常集中在兩個關鍵點：
- 第一，密碼被硬編碼在程式中。
只要原始碼包含明文密碼，一旦被取得，就等於取得完整存取權限。程式本身不再只是應用邏輯，而是成為攜帶憑證的媒介。 - 第二，密碼是長期有效的靜態憑證。
如果密碼長期不更換，即使多年後才被外洩，仍然可以被使用。只要沒有自然失效機制，風險就會持續存在。
當這兩種情況同時存在時，資安事件往往不是偶發，而是遲早會發生的結果。
攻擊者如何利用舊程式碼入侵系統
在業務開發中，為了方便測試或快速完成部署，部分開發者會將資料庫帳號與密碼直接寫在程式碼或設定檔中。這種做法看似提升效率，卻同時讓機密資訊與應用程式綁在一起，一旦原始碼外流，風險也會同步暴露。從範例程式碼可以看到資料庫的：
- 主機位置（RDS endpoint）
- 連接埠（3306）
- 使用者名稱（admin）
- 密碼（明文寫在程式中）
全部都清楚地記錄在 DB_CONFIG 內。這代表只要有人取得這份程式碼，就等於拿到完整的資料庫連線資訊。
如果這組密碼自建立以來從未更換，那麼即使程式版本早已過期，攻擊者仍然可以成功連線到現在正在使用的正式資料庫。這代表他不只是看到程式碼，而是真的進入了系統。
一旦成功登入，後續就可能發生：
- 資料被下載或竊取
- 資料被刪除或竄改
- 系統成為進一步滲透的跳板
畫面中可以看到，攻擊者透過 mysql 指令成功登入資料庫。
優化與預防：如何避免同樣的事件再次發生？
如果要真正解決硬編碼與靜態密鑰的問題，就不能只修補程式碼，而是必須調整整體的密鑰管理方式。正確的方向，是建立一套集中化管理與動態輪換的機制也就是動態密碼。
這套機制的核心包含三個要素。
- 密鑰必須存放在獨立且安全的儲存環境中，而不是放在原始碼或設定檔裡。這樣即使程式外流，也不會直接暴露憑證。
- 應用程式在需要時，應透過 API 動態取得密鑰，而不是讀取固定字串。密碼不再是程式的一部分，而是由系統在執行當下安全取得。
- 整個存取過程必須結合身份驗證與授權機制，例如角色與權限控管。只有被授權的系統或人員，才能讀取密鑰。
靜態密碼與動態密碼的差異比較
靜態密碼與動態密碼的差異在於「是否具備更新與失效機制」。要理解為何需要動態輪換機制，必須先看清楚靜態與動態密碼的本質差異。
| 比較項目 | 靜態密碼 | 動態密碼 |
|---|---|---|
| 儲存方式 | 寫在程式碼或設定檔 | 存放於安全的密鑰管理服務 |
| 更新機制 | 長期不變，需人工修改 | 定期自動輪換 |
| 失效機制 | 無自然失效時間 | 具備生命週期與更新機制 |
| 外洩風險 | 一旦外洩可長期使用 | 即使外洩，舊密碼很快失效 |
| 安全等級 | 高風險 | 風險可控 |
勤英科技的觀點：如何用 AWS Secrets Manager 解決密鑰管理問題
要避免密碼硬編碼與永久有效的靜態密鑰，就必須建立集中化管理與自動輪換機制。但如果從零開始自行開發這整套系統，不僅開發成本高，後續維運與安全控管也相當複雜。因此，與其自行開發整套系統，不如利用成熟的雲端服務，快速建立動態密碼機制。這樣既能降低開發負擔，也能快速落地安全機制。
以 AWS 為例，其提供的服務可以完整覆蓋前面提到的需求：
- AWS KMS：負責密鑰的加密儲存
- IAM：負責細緻的身份與存取控制
- Secrets Manager：負責安全存放密鑰，並結合 Lambda 實現自動輪換
透過這三者的搭配，就能同時做到加密保護、權限控管與定期更換，讓密鑰不再是長期暴露的風險來源。接下來將示範如何利用這些服務，為 RDS 建立完整的密鑰管理與自動輪換機制。
步驟一：進入 Secrets Manager 建立密鑰
進入 AWS 管理主控台，選擇 Secrets Manager → Secrets → Create secret。
步驟二：填入登入資訊
在這個畫面中，需要填入：
- RDS 使用者名稱
- RDS 密碼
Secrets Manager 會預設使用 AWS 帳戶的預設 KMS 金鑰進行加密，也可以選擇自訂 KMS Key 強化控管。
步驟三：設定密鑰名稱
接著為這組密鑰命名，例如：sys_admin
步驟四：設定自動輪換策略
可設定輪換頻率，例如：
- 每 30 天輪換一次
系統會透過 Lambda 函數自動更新資料庫密碼，並同步更新密鑰內容。
⚠ 重要提醒：
第一次輪換通常會在下一個排程時間才執行，而不是立即生效。如果需要立即更新，可以手動點擊「立即輪換」。
確認輪換函數設定
步驟五：修改程式碼，改為動態取得密鑰
完成密鑰建立後，Secrets Manager 會在最後提供一段「連線範例程式碼」。你只需要把這段程式碼放進原本的專案中，取代原本寫死的密碼，就可以開始使用。如果想了解更詳細的使用方式，例如不同語言的範例或 API 說明，可以查閱 AWS 官方的 SDK 文件與 API 手冊，裡面有完整的開發說明與工具介紹。
透過集中化密鑰管理與自動輪換機制，密碼不再寫死在程式碼中，也不再長期有效。即使原始碼外流，攻擊者也無法直接取得可用憑證。從勤英科技的實務經驗來看，企業在強化資安的同時，也需要兼顧雲端成本治理。勤英科技作為 AWS 認證合作夥伴提供資安健檢與雲端節費優化服務，透過雲端雙效健檢工具協助企業找出潛在風險與資源浪費，讓安全與成本優化同步推進。
