雲端安全警報： OWASP 發布非人類身份 十大資安風險
這些非人類身份在雲端運算中扮演了關鍵角色，它們讓各種關鍵應用能夠順利運作，同時提升作業效率。主要原因是這些數位身份具備特定的權限與存取能力，能夠替應用程式或自動化任務完成需要的操作。
然而，非人類身份同時也成為了對攻擊者說極具吸引力的目標。根據 Enterprise Strategy Group 先前的一項研究指出， 有高達 66% 的企業都曾因 NHI 遭入侵而導致資安事件發生。NHIs 通常具備高度權限、可存取多種系統與資源，然而在權限控管上卻常存在弱點。一旦設定完成，這些帳號往往因缺乏持續監控與管理而被忽視，使得攻擊面擴大，為威脅行為者提供了可乘之機，NHIs 的潛在風險已成為資安團隊在雲端環境中亟需重視的重要挑戰。
隨著非人類身份（NHI）的快速增長及其潛在風險日益受到重視，因此 OWASP 啟動最新的「非人類身分十大風險（OWASP Non-Human Identities Top 10）」計畫。為推動這項重要計畫， OWASP 特別邀請 Orca Security 以及多家領先的資安廠商共同參與，攜手制定相關的風險指引與最佳實務。
本文將深入探討 OWASP「非人類身份十大風險（Non-Human Identities Top 10）」，說明其在雲端資安領域的應用，以及 Orca Security 研究團隊所揭示的關鍵研究發現。同時，我們也將分享實用的最佳實務建議，協助企業有效因應 2025 年最常見的 NHI 資安風險，強化整體防護能力。
深入剖析OWASP Non-Human Identities Top 10
OWASP 非人類身份十大風險（NonHuman Identities Top 10）提供最為關鍵的 NHI 資安風險排名，並為資安與開發團隊提供實用的指引。此清單運用了 OWASP 風險評估方法（Risk Rating Methodology），並結合了來自資安領域頂尖專家與組織的研究，其中包括 Orca Security 的研究團隊。
NHI 1 不當撤銷 ( Improper Offboarding)
「不當撤銷」指的是組織未能在非人類身份（NHI）不再需要時，適當地刪除或停用這些身份。這種疏忽會使過時的服務處於持續存在但未監控的狀態，容易遭受攻擊者利用，進而非法存取敏感數據和系統。
根據分析，不當撤銷是雲端環境中常見的風險。以 AWS 為例，近一半（47%） 的企業仍然有至少一個 IAM 角色與第三方集成相關聯，且該集成在過去 90 天內未曾使用。
NHI 2 密鑰洩漏（Secret Leakage）
密鑰洩漏是指當敏感的 NHI（如 API 金鑰、加密金鑰和身分憑證）在軟體開發生命週期（SDLC）中，不小心暴露在未經授權的資料儲存區。這種情況通常是因為將密鑰被「硬編碼」 到原始碼，將其存儲在純文本配置文件中，或者透過不安全的通訊管道共享，這些做法增加了密鑰被惡意攻擊者發現並加以利用的風險。
在過去幾年中，密鑰洩漏導致了數起備受矚目的資安事件，包括 2022 年 Uber 和 2023 年 Mercedes 的資安漏洞事件。根據 Orca Security 的研究調查發現，密鑰洩漏是企業中普遍存在的高風險問題。70% 的企業在其原始碼儲存庫中嵌入了純文本密鑰，其中 2% 的洩漏密鑰是活躍的，並且存儲在當前的主分支中，而 50% 的密鑰則保存在 Git 歷史紀錄中，其中 4% 的密鑰仍然有效。
此外，密鑰洩漏的風險也適用於在雲端公開暴露的資產。Orca Security 研究團隊分析發現，22% 的企業至少有一個在雲端公開暴露的資產，其中包含長期有效的供應商密鑰，例如雲服務提供商的存取金鑰。攻擊者可利用這些資產，便能竊取有效的金鑰並利用金鑰進行帳戶接管。
NHI 3 第三方 NHI 存在漏洞（Vulnerable Third-Party NHI）
第三方 NHI 已被廣泛整合進開發流程中，常見於整合式開發環境（IDEs）、IDE 擴充功能以及第三方 SaaS 服務中。如果這些第三方擴充功能因存在安全漏洞或遭到惡意更新而被攻擊者入侵，就可能被利用來竊取憑證資訊，或濫用其被授予的權限。
過去曾有幾起與此風險相關的重大資安事件，包括 JetBrains 惡意外掛以及 CircleCI 供應商遭入侵，導致第三方存取金鑰外洩與客戶密鑰洩漏。根據 Orca Security 分析顯示，企業平均會使用四種與 NHI 有關的第三方整合，說明這類 NHI 的使用非常普遍，也突顯出其所帶來的潛在風險。
NHI 4 不安全的身份驗證（Insecure Authentication）
開發人員經常會在應用程式中整合第三方服務，而這些服務通常需要驗證憑證來存取系統資源。然而，部分身分驗證方式本身存在重大風險，包括容易受到已知攻擊、依賴過時的安全做法或是已經不再支援的驗證技術。若持續使用這類不安全或過時的身分驗證機制，將大幅提高企業遭到攻擊與滲透的風險。
NHI 5 過度授權的 NHI（Overprivileged NHI）
在應用程式開發與維運過程中，使用者常會給予 NHI（如自動化工具、服務帳號等）超出實際需求的權限。一旦這些權限過高的 NHI 透過應用程式漏洞、惡意軟體或其他方法被入侵，攻擊者就能利用這些過度授權的權限對系統造成嚴重威脅。
在雲端環境中，非人類身分成為「權限過高」的情況如下：第一種是直接賦予這些身分過高的存取權限。根據 Orca Security 研究指出，有 13% 的雲端角色屬於高權限角色，而有 53% 的組織有超過 10% 的角色被賦予了高權限。第二種是為分配給角色的權限超過其真實需求。Orca Security 調查發現，在過去 30 天內曾被使用的 AWS IAM 角色中，實際被使用到的權限僅占其原先設定的 55%，這表示許多權限設定其實可以被大幅精簡，而不影響功能。
NHI 6 不安全的雲端部署配置（Insecure Cloud Deployment Configurations）
持續整合與持續部署（CI/CD）工具可大幅簡化開發流程，讓開發人員能自動化建置、 測試並部署程式碼到生產環境中。這些工具通常需要透過靜態憑證或 OpenID Connect （OIDC）來與雲端服務進行身份驗證。
然而，使用靜態憑證是存在風險的，這些憑證可能會暴露在組態檔、程式碼儲存庫或日誌中，進而讓攻擊者獲得對生產環境的持久且具權限的存取權。而即便是 OIDC 這類較安全的選項，若在驗證身份憑證（Token） 時處理不當，或設定了過於寬鬆的憑證聲明條件，仍可能被未授權的使用者所利用，造成安全風險。
NHI 7 長期存在的密鑰（Long-Lived Secrets）
「長期存在的密鑰」是指一些具敏感性的 NHI，例如 API 金鑰、加密金鑰、或身分憑證，其有效期限非常長，甚至沒有設定過期日。一旦這類密鑰遭到洩漏，攻擊者就可能長期利用它們，取得機敏系統或服務的存取權限。
在大規模環境中管理這些密鑰資訊是一項非常複雜的工作，因此各大雲端服務供應商都建議使用自家提供的密鑰儲存服務（例如 AWS Secrets Manager、Azure Key Vault、GCP Secrets Manager） 來進行自動化管理。
這些工具也支援「 密鑰輪換（secret rotation）」功能，以符合資安最佳實踐。 雖然這些功能相當實用，但實際使用率卻偏低。根據Orca Security研究團隊分析， 僅有 0.5% 儲存在 GCP Secrets Manager 的密鑰設定了自動輪換日期，而 AWS Secrets Manager 則僅有 1.5%。
NHI 8 環境隔離不足（Environment Isolation）
在雲端應用程式的安全部署中，「環境隔離」是一項基本要求，通常會將開發 （Development）、測試（Testing）、預備 （Staging）和正式（Production）等環境分開設置。雖然 NHI 在整個應用程式開發生命週期中都扮演著關鍵角色，但如果企業在多個環境中重複使用相同的 NHI， 尤其是在測試與正式環境間共用，就可能造成嚴重的安全風險。這種做法容易讓攻擊者藉由較低安全控管的環境進入核心系統，進而威脅正式環境的安全。
NHI 9 NHI 重複使用（NHI Reuse）
在多個應用程式、服務或元件之間重複使用相同的 NHI，即便它們是同時部署的，也會帶來重大的安全風險。若其中一個 NHI 遭到入侵，攻擊者就能藉此取得使用相同憑證的其他系統的存取權。
在雲端環境中，角色重複使用的情況相當普遍。根據 Orca Secuirt 分析顯示， 有 13% 的組織至少有一個特權 Instance Profile 為 50 個以上的不同 EC2 執行個體提供服務，其中 11% 的甚至擁有管理員等級的權限。
NHI 10 NHI 用於人為操作（Human Use of NHI）
在應用程式開發與維護過程中，開發人員或系統管理員有時會誤將原本設計給系統自動化使用的 NHI 拿來執行手動操作。 這種做法會導致 NHI 被賦予不必要的使用權限，進而產生安全風險，尤其是特權過高的情況，容易被濫用或成為攻擊者的目標。
如何防範NHI風險？
為降低來自 OWASP NHI Top 10 的威脅， 建議企業採取以下資安實踐：
① 盤點並保護敏感憑證（Secrets）：建立完整的憑證清單，確保這些敏感資訊未被暴露於網際網路或以明文形式儲存。
② 落實最小權限原則（PoLP）：僅授予每個 NHI 完成任務所需的最低限度權限， 以降低橫向移動與權限升級的風險。
③ 採用即時授權（Just-In-Time, JIT）機制：只在必要時間內授予臨時性存取權限，有效控制雲端環境中過度授權問 題。
④ 定期輪換憑證：定期更新 API 金鑰、身分憑證等敏感資訊，減少憑證洩漏後的影響範圍。
⑤ 盤點第三方整合項目：全面盤點第三方工具與服務整合情況，審查其所擁有的權限，並建立明確的移除與下線流程。
⑥ 移除未使用或被忽略的角色：關閉或刪除 90 天內未使用的角色帳號，避免成為潛在攻擊入口，縮小攻擊面。
Orca Security如何提供協助？
Orca Security 的 Cloud Security Platform 是整合性雲端安全平台，能夠針對 AWS、Azure、Google Cloud、 Oracle Cloud、Alibaba Cloud 及 Kubernetes 等多雲環境，全面識別、優先排序並修復安全風險與合規問題。 此平台內建高度整合的雲端基礎架構權限管理（CIEM）解決方案，可針對您雲端中的所有身份、配置、存取政策、授權、權限與活動，提供細緻且具情境性的可視性，協助企業全面掌握雲端環境中的安全狀態。
透過 Cloud Security Platform，您可以全面掌握雲端環境中所有 NHI，包括與供應商關聯的任何服務身份，以便立即了解您的供應鏈風險。對每個身分，平台都會顯示其所附加的 IAM 策略、與其他雲端資產之間的權限關聯地圖、潛在風險、合規影響以及其他相關資訊。若有過度授權的情況，平台也會依照最小權限原則 （PoLP）提出最佳化建議，協助您調整權限設定、強化雲端資安防護。
了解Orca Security 雲端原生應用程式防護平台>>>https://www.gss.com.tw/product-services-nav/info-security/orca