27天！揭秘身份管理中憑證修復為何如此艱難？
責編：gltian ｜2024-11-21 14:36:00根據GitGuardian和CyberArk的研究顯示，79%的IT決策者報告經歷過憑證泄露事件，較上年的75%有所上升。與此同時，泄露的憑證數量達到歷史新高，僅在GitHub公共倉庫中就發現超過1270萬個硬編碼憑證。更令人擔憂的是，超過90%組織已經知曉泄露的有效憑證在5天后仍然有效。研究還表明，組織平均需要27天才能修復泄露的憑證。
憑證修復那么緊迫，為什么卻那么難？
安全和合規的雙重壓力
憑證修復是網絡安全的重要方面,主要關注識別和解決受損憑證以防止未經授權的訪問和數據泄露。隨著數十億受損憑證在網上流傳,各組織越來越重視制定有效的修復策略來降低憑證盜竊和賬戶接管的風險。
修復憑證擴散事件意味著，要在不破壞任何功能的情況下安全地替換憑證，同時避免授予過大的新權限，否則可能會給公司帶來更多安全風險。組織必須優先采取主動措施來快速檢測和解決受損憑證,因為延遲可能引發一系列安全事件，包括數據泄露、身份冒充、系統中斷等，造成重大的財務、法律和聲譽后果。
憑證一旦被盜或泄露，攻擊者可以利用這些憑證進行身份冒充、數據竊取、橫向移動等惡意活動。如果憑證修復不及時，攻擊者可能繼續使用這些憑證進行進一步的攻擊，導致企業遭受更大的損失。據統計，僅2022年美國身份欺詐損失就高達約520億美元。
未能及時修復受損憑證可能嚴重損害組織聲譽，不遵守數據保護法的組織可能面臨重大罰款和受影響方的法律訴訟，由此還可能導致品牌聲譽和客戶關系的長期損害。
憑證填充攻擊的頻率激增,使組織必須迅速響應任何憑證泄露的跡象。2023年,利用漏洞的成功攻擊達到32%,突顯了有效修復策略的緊迫性。
與此同時，合規要求驅動組織優化憑證管理，加速憑證修復。GDPR和CCPA等數據保護法規都要求組織建立健全的憑證管理實踐，未能充分保護敏感用戶信息的組織將面臨重大處罰。
非人類身份憑證帶來的新挑戰
隨著應用程序數量的增加和云服務的廣泛使用，企業面臨著管理大量憑證的挑戰。每個應用程序、服務和用戶都可能需要不同的訪問權限，這使得權限管理變得更加復雜。如果沒有清晰的策略和工具來管理這些憑證，很容易導致憑證擴散，即同一憑證被多個用戶或服務使用，從而增加了被攻擊的風險。
非人類身份憑證（如機器、應用程序或服務帳戶的憑證）修復引入了新的復雜性。有統計顯示，非人類身份（NHI）比人類身份至少多45倍。這讓越來越多組織意識到，要遏制憑證擴散，必須找到應對非人類身份危機的方法。
非人類身份憑證通常涉及多個系統和服務，而每個系統可能有不同的安全要求和管理流程，同時可能還面臨不同的合規性要求，管理這些憑證的生命周期變得更加復雜。不僅如此，隨著云計算和微服務架構的普及，非人類身份憑證在動態環境中使用頻繁，這使得識別和應對潛在漏洞變得更加困難。
而與此形成鮮明對比的是，許多組織對非人類身份憑證使用情況缺乏全面可見性。這種缺乏透明度可能導致未能及時發現被濫用或過期的憑證，從而增加安全風險。更為嚴重的是，許多NHI依賴于很少更新的靜態憑證，如API密鑰或密碼，這增加了憑證被惡意利用的風險。
責任歸屬不清
根據GitGuardian最新的報告顯示，65%的受訪者將修復責任完全歸于IT安全團隊。同時，44%的IT領導者報告稱開發人員沒有遵循憑證管理的最佳實踐。
在許多組織中，IT安全團隊被視為網絡安全的主要負責人，負責監控和修復潛在的安全漏洞。然而，這種單一的責任歸屬可能導致開發團隊對安全問題缺乏足夠的重視。
開發人員通常專注于功能開發和交付，而忽視了憑證管理和權限控制的重要性。這種現象在快速迭代的DevOps環境中尤為明顯，開發人員可能在壓力下忽略安全最佳實踐，從而導致憑證泄露和過度授權的問題。
開發人員面臨著快速構建和部署功能的巨大壓力。然而，按照安全最佳實踐謹慎管理權限是一項耗時的工作。每個項目或應用程序通常都有其獨特的訪問需求，這需要時間研究和正確設置，感覺像是其在正常工作之外的另一份全職工作。最佳實踐往往在團隊間執行不均衡，很少得到適當記錄，或在開發人員使應用程序運行后被完全遺忘。
雪上加霜的是，在太多情況下，開發人員簡單地為這些機器身份授予了過于寬泛的權限。一份報告發現，只有2%的授予權限實際被使用。仔細觀察他們面臨的情況，就很容易理解其中的原因。
例如， AWS的身份和訪問管理（IAM）策略以其靈活性而聞名，但也復雜且難以駕馭。IAM支持多種策略類型（基于身份的、基于資源的和權限邊界），所有這些都需要精確配置。AWS還為憑證提供多種訪問路徑，包括IAM角色和KMS授權，每種都有其獨特的訪問配置。掌握這個系統絕非易事。
安全團隊不能承受之重
將監控和輪換憑證的責任分配給安全團隊看似合理，畢竟這是一個安全問題。但現實是這些團隊往往缺乏安全更改所需的細粒度項目級知識。例如，一個看似微小的權限更改可能會破壞CI/CD管道，擾亂生產環境，甚至在錯誤的服務消失時導致公司范圍的級聯故障。
每個應用程序都有其獨特的需求和依賴關系，安全團隊并不總是能夠理解保持應用程序運行所必需的具體權限。
一個微小的權限更改可能會對其功能產生重大影響。例如，在CI/CD管道中，某個服務需要特定的權限來執行構建或部署任務。如果這些權限被錯誤地調整或撤銷，可能會導致整個管道的中斷，從而影響到生產環境的穩定性。
在復雜的系統架構中，一個服務的故障可能會引發級聯效應。例如，如果一個關鍵服務失去訪問另一個服務所需的權限，這不僅會導致該服務無法正常運行，還可能影響到依賴于它的其他服務。這樣的級聯故障不僅會影響用戶體驗，還可能導致財務損失和品牌聲譽受損。因此，安全團隊在進行權限管理時，很難充分考慮這些潛在風險。
憑證權限管理與修復的幾點建議
考慮到非人類身份權限、憑證責任不清等問題，為了有效管理權限，安全牛建議組織在進行憑證權限管理與修復時，應該關注以下幾點：
1鼓勵跨部門協作
要鼓勵安全團隊與開發團隊之間進行跨部門協作，安全團隊可以提供關于最佳實踐和合規性的指導，而開發團隊則可以提供關于應用程序需求的重要信息。這種合作能夠確保在進行任何權限變更時，都能充分考慮到業務需求與安全風險之間的平衡。
在跨團隊合作中，要重點關注幾個問題：1. 誰創建了憑證？2. 它訪問哪些資源？3. 它授予什么權限？4. 如何撤銷或輪換它？5. 憑證是否活躍？
2引入自動化工具
引入自動化工具，可以提高權限管理的效率與準確性。
通過使用基于角色的訪問控制（RBAC）模型，可以為不同角色定義清晰的權限集，從而簡化管理流程。
此外，自動化工具還可以幫助跟蹤和記錄所有權限變更，便于后續審計和合規檢查。比如，開發人員通過適當的工具（如CyberArk的Conjur Secrets Manager或HashiCorp的Vault）更負責地持續管理其權限，同時更好地記錄項目級別所需權限的范圍。安全團隊應該通過努力實現憑證輪換自動化、投資適當的可觀察性工具以明確了解憑證狀態，并與IT合作完全消除長期存在的憑證來幫助開發人員。
3強化教育與培訓
特別是要提高員工對非人類身份憑證管理重要性的認識，確保他們了解最佳實踐并遵循安全政策，以減少人為錯誤導致的安全隱患。
4做好修復后審查工作
采取修復行動后，評估所實施措施的有效性。這包括評估變更是否成功降低了風險，以及是否出現任何新的漏洞。利用從修復過程中獲得的見解來改進未來的實踐。根據過去事件中吸取的教訓定期更新政策和程序。