關閉選單
非人身分風險成為企業隱憂

報導摘要

一份由 Entro Security 發布的報告指出,企業資安風險正快速從人類身分轉向「非人類身分」(Non-Human Identities, NHIs),例如各種自動化工具、機器人、服務帳戶等。隨著 AI 和自動化技術的普及,這些非人類身分的數量已遠超過人類,並成為企業環境中成長最快的資安風險來源。由於這些身份通常帶有 API 密鑰和憑證等「機密資料」(secrets),但這些機密資料往往管理不當、被放置於不安全處,或是被賦予過高的權限,從而擴大了攻擊者的可乘之機。


資安風險

非人類身分帶來的資安風險主要有兩點。首先,它們所攜帶的機密資料正從多個意想不到的管道洩漏。雖然硬編碼在原始碼中的機密資料仍是最大宗,但目前已有近半數的洩漏來自其他地方,例如 CI/CD 工作流程、協作工具(如Slack、Microsoft Teams)以及 SharePoint 等雲端辦公文件,攻擊者可以從這些地方輕易地取得憑證。其次,許多非人類身分及其機密資料存在「生命週期」問題。報告指出,近半數的非人類身分都已啟用超過一年,但仍擁有廣泛的權限,卻可能早已不再使用,這使得這些被遺忘的身分成為攻擊者潛伏和擴大攻擊範圍的絕佳目標


安全影響

非人類身分帶來的風險對企業安全產生深遠影響。當這些身分的機密資料外洩後,攻擊者可以利用其高權限的帳戶,在企業內部網路中進行橫向移動攻擊。這可能導致資料外洩、系統被非法存取、甚至部署惡意軟體。更嚴重的安全影響在於,當攻擊者成功利用一個被忽視的非人類身分後,企業的傳統安全防護措施很難偵測到異常,因為這些行為看起來像是合法的內部帳戶操作。這使得企業面臨難以察覺的長期潛在威脅,直到造成重大損失後才發現問題。


行動建議

為有效應對非人類身分風險,企業應採取以下行動:
  1. 擴大機密資料掃描範圍:將機密資料掃描的範圍擴大到不僅限於原始碼,更應涵蓋文件、協作工具和 CI/CD 日誌等非程式碼檔案。
  2. 定期審核非人類身分:針對所有非人類身分進行定期稽核,特別是那些超過一定時間未被使用的帳戶,應立即停用或刪除。
  3. 實施最小權限原則:確保所有非人類身分只被賦予執行其任務所必需的最小權限,避免授予不必要的廣泛管理權限。
  4. 建立生命週期管理:為所有機器身份和機密資料建立明確的所有權和有效期限策略,並在過期後強制自動移除。


結論

Entro Security 的報告為企業資安敲響了警鐘,提醒我們在數位轉型的過程中,非人類身分正成為一個不容忽視的重大威脅。隨著 AI 和自動化的持續發展,這個問題只會變得更加嚴重。傳統的資安思維和工具已不足以應對這種新型風險。企業必須將安全防護的重點從單純的人類帳戶,擴展到包含非人類身分的全面管理,透過擴大掃描、強化審核與最小化權限等措施,才能有效降低由這些自動化身分所帶來的巨大潛在風險,確保企業資產與資料的安全。

備註:
「非人類身分」(Non-Human Identities, NHIs)指的是那些不屬於個人使用者,而是代表應用程式、服務、自動化工具、機器等進行操作的身份。這些身份在現代 IT 環境中無處不在,且數量龐大,管理不當就可能成為安全漏洞。
以下是一些常見的非人類身分及其所代表的設備或系統:
服務帳戶 (Service Accounts)
這是最常見的 NHI 類型之一。它們是應用程式或服務用來與其他系統、資料庫或服務進行互動的身份。
  • 系統/設備:
    • 應用程式伺服器 (Application Servers): 如執行 Web 應用程式、企業資源規劃 (ERP) 系統的伺服器。這些應用程式需要服務帳戶來存取資料庫、檔案分享或外部 API。
    • 資料庫伺服器 (Database Servers): 資料庫服務本身可能使用服務帳戶來執行內部操作,或供應用程式連接。
    • 批次處理系統 (Batch Processing Systems): 用於執行定時任務或大量資料處理的系統,其排程器或執行代理需要服務帳戶來存取所需的資源。
    • 檔案伺服器 (File Servers): 提供檔案共用服務,其底層服務可能需要帳戶來管理權限。
    • 作業系統服務: Windows 或 Linux 上的許多系統服務都需要以特定帳戶身份運行,例如本機系統帳戶 (Local System)、網路服務帳戶 (Network Service) 等。
API 金鑰與令牌 (API Keys & Tokens)
用於授權應用程式或服務之間相互呼叫、存取 API 的憑證。
  • 系統/設備:
    • 雲端服務平台 (Cloud Service Platforms): 如 AWS、Azure、GCP 上的各種服務 (EC2, S3, Blob Storage, Compute Engine),應用程式或腳本會使用 API 金鑰或臨時令牌來調用這些服務。
    • 微服務架構 (Microservices Architectures): 在分散式系統中,不同的微服務之間通過 API 進行通信,並使用令牌進行身份驗證和授權。
    • 第三方應用程式整合: 當企業系統與外部服務 (如支付閘道、CRM 系統、簡訊服務) 整合時,會使用 API 金鑰。
    • 自動化腳本 (Automation Scripts): 用於自動化部署、配置管理、監控等的腳本,會內嵌 API 金鑰來與各種服務互動。
自動化工具與機器人 (Automation Tools & Bots)
這些是專門設計用於執行重複性任務、工作流程自動化的工具或平台。
  • 系統/設備:
    • 機器人流程自動化 (RPA) 平台: 例如 UiPath, Automation Anywhere, Blue Prism 等,這些平台的「機器人」或「自動化代理」會模擬人類行為與應用程式互動,需要帳戶來登入系統。
    • CI/CD 工具 (Continuous Integration/Continuous Deployment): 如 Jenkins, GitLab CI/CD, CircleCI, Travis CI 等,用於自動化程式碼編譯、測試、部署,它們需要憑證來存取程式碼倉庫、部署目標伺服器。
    • 組態管理工具 (Configuration Management Tools): 如 Ansible, Puppet, Chef, SaltStack,用於自動化伺服器配置和軟體部署,需要特權帳戶來在目標機器上執行命令。
    • 排程任務 (Scheduled Tasks): 作業系統內建的排程器 (如 Windows Task Scheduler, Linux Cron Jobs),可以設定在特定時間執行腳本或程式,這些任務通常會以某個用戶身份運行。
裝置身分 (Device Identities)
指的是物聯網 (IoT) 裝置、伺服器、網路設備等本身的數位身分。
  • 系統/設備:
    • 物聯網 (IoT) 裝置: 智慧感測器、智慧家電、工業控制系統 (ICS/OT) 設備,它們需要身份憑證來連接雲端平台或本地網路,發送數據或接收指令。
    • 網路設備 (Network Devices): 路由器、交換機、防火牆,它們可能需要憑證來進行遠端管理、配置更新或與監控系統互動。
    • 伺服器主機 (Server Hosts): 每一台物理或虛擬伺服器,它們有自己的主機名、IP 地址,可能還會有憑證來進行驗證。
    • 容器與虛擬機器 (Containers & VMs): Docker 容器、Kubernetes Pods、虛擬機器本身可以被視為擁有獨立身分,尤其是在微服務環境中,它們會使用服務帳戶或臨時憑證來獲取資源。
程式碼簽章證書 (Code Signing Certificates)
這是一種數位憑證,用於驗證軟體程式碼的來源和完整性,確保程式碼未被篡改。
  • 系統/設備:
    • 開發與建置系統: 軟體開發的建置伺服器 (Build Servers) 會使用程式碼簽章憑證來簽署最終的應用程式、驅動程式或腳本。
    • 軟體發布平台: 應用程式商店或下載網站會依賴這些簽章來驗證軟體的合法性。
機器對機器 (M2M) 憑證
廣義上包含前面提到的 API 金鑰、服務帳戶等,但更強調設備之間直接通信的身份。
  • 系統/設備:
    • 資料中心基礎設施: 伺服器之間、儲存設備與計算單元之間直接的認證與授權。
    • 區塊鏈節點: 參與區塊鏈網路的各個節點需要彼此認證以維持網路安全。

隨著自動化和雲端應用的普及,NHI 的數量已遠超人類用戶,且它們通常擁有高度的權限來執行任務。如果這些身份的憑證(如密碼、金鑰、令牌)管理不善、被盜用或未定期輪換,就會成為攻擊者滲透企業網路、竊取資料或發動勒索軟體的巨大漏洞。因此,對 NHI 進行嚴格的身份和存取管理 (IAM) 是當前企業資安的關鍵挑戰之一。
 

資料來源:https://www.helpnetsecurity.com/2025/07/31/enterprise-non-human-identity-risk/