Orca Research Pod 團隊一整年深入調查雲端資安現況，掃描了數十億個雲端資產，分析了數十萬個程式碼儲存庫，他們揭露了相當關鍵的發現。

他們正式公開研究結果，揭示五個 2025 年雲端基礎架構中最嚴重、卻往往被忽略的資安風險。這些風險幾乎在每一家組織中都反覆出現，也是企業在迎接新的一年前，必須先行理解與正視的關鍵議題。

關鍵發現一、被遺忘的權限

「給出過多的金鑰。」

從調查身份與存取權限開始，調查人員發現令人震驚的情況。許多組織已經完全掌握不了誰能在基礎架構中執行哪種操作。

問題始於服務帳號（service accounts）。這些是負責雲端關鍵運作的非人類身份，理應只擁有完成工作所需的最小權限，但 93% 的組織至少有一個服務帳號權限過高。在某個環節它們被賦予了遠超實際需求的權限，「最小權限原則」也早已形同虛設。

還有更嚴重的第二個隱憂：78% 的組織至少有一個 IAM 角色超過 90 天未使用。這些「閒置卻依然有效」的憑證，依然擁有高權限靜靜存在系統中，就像被遺忘的金鑰一樣。資安團隊可能早已忽略它們，但攻擊者可不會。更驚人的是在12% 的組織中，一個高權限角色竟綁定超過 50 個執行個體。這意味著一旦單一憑證被入侵，開啟的不僅僅是一個門，而是打開了數十扇門。

調查人員清楚這代表攻擊者根本不用費力強行闖入，門早就被留著沒鎖。

關鍵發現二、外洩的機密

「這些機密本不該離開保管庫。」

應用程式安全調查的線索指向更嚴重的問題：機敏資訊散落在程式碼庫、設定檔與雲端服務中，仍保持有效，攻擊者隨時可以存取使用。

事情是這樣發生的：開發人員撰寫程式碼，需要憑證來連接資料庫、API 或各種服務，於是把憑證寫死在程式碼裡。一開始只是暫時使用或為了測試。但這些憑證往往從未被移除。調查顯示，85% 的組織在原始碼儲存庫中仍嵌入明文機敏資訊，包括 API 金鑰、OAuth 權杖、資料庫憑證，全都以明文存在。

情況更糟的是 36% 的這些機敏資訊仍然活躍並直接存在主分支的程式碼裡，而非埋藏在過往的提交紀錄中。也就是說一旦程式庫被入侵，攻擊者即可立即存取線上系統。

即便是已刪除的機敏資訊也會留存，58% 的明文機敏資訊仍保存在 Git 歷史中，攻擊者可用簡單工具挖出。而最讓資安團隊夜不能寐的是這些歷史機敏資訊中有 14% 仍有效，使攻擊者在這些資訊理應被移除後數週甚至數月，仍能取得真實存取權限。

時間線更是驚人，攻擊者只需兩分鐘就能在 GitHub 上找到並利用外洩機敏資訊，組織修補平均要 94 天，這等於攻擊者可持續存取系統 4,496 小時。

關鍵發現三、被忽視的資產

「失去對許多資產的掌控。」

雲端基礎架構中有三分之一的資產早已被遺忘。還沒有被入侵也沒有遭受主動攻擊，只是被遺忘。

被遺忘的樣貌是這樣的：開發團隊為了測試某個功能而啟動一台伺服器，本應是暫時使用。但他們很快就轉向下一個專案，伺服器卻繼續運行。多年過去，作業系統不再獲得供應商支援，安全性修補程式也不再發佈，沒有人在監控，甚至沒人記得它的存在。

平均而言，有 32% 的雲端資產處於被忽視的狀態，其中包含不受支援的作業系統，以及超過 180 天未安裝修補程式。這些正是攻擊者積極獵捕的軟目標。以俄羅斯情報組織 APT29 為例，他們就是靠尋找這類被遺忘的資產建立的。有高達 89% 的組織至少有一個對外公開且被忽視的資產。一台被遺忘的伺服器，加上預設的公開存取權限，這就是入侵所需的全部條件。

更糟的是這些漏洞並非是新出現的問題，58% 的組織仍在面對超過 20 年歷史的漏洞。像是Log4Shell、Spring4Shell，這些在 2021、2022 年爆發的漏洞利用，至今仍然危險並被積極利用中。此外，在受 Log4Shell 漏洞影響的雲端資產中，高達 59% 是 對外公開的，這讓攻擊者能直接從網際網路觸發這些漏洞 。

一個被遺忘的資產、一個舊漏洞、一個攻擊立足點。事情就是從這裡開始的。

關鍵發現四、危險的組合

「風險間的連結，形成更大的威脅。」

調查人員發現比起單一風險，更令人擔憂的是這些風險之間的連結與相互放大。問題不只是某個漏洞，而是風險間如何相互串聯，形成更大的威脅。

可以這麼想：單一過度權限的角色本身不致命；單一暴露的資料庫雖然糟，但還在可控範圍；單一被遺忘的伺服器雖然是風險，但也只是潛在責任。但當它們被串聯起來呢，並串聯成一條供應鏈時，原本獨立的小問題就會變成通往災難的高速公路。

這就是所謂的攻擊路徑（attack path），一連串漏洞利用的順序，將單一錯誤變成全面入侵。而這種情況無處不在。

調查顯示，13% 的組織中，僅僅一個雲端資產就可能產生超過 1,000 條攻擊路徑。單一錯誤配置的資源，就可能讓攻擊者通過上千條不同路徑入侵高價值目標。調查中最誇張的案例？單一資產竟能產生 165,142 條攻擊路徑。攻擊者只需找到其中一條，就能成功入侵。

這些路徑 54% 通往暴露的資料庫，23% 通往廣泛權限的存取權，23% 通往受駭的主機。但對攻擊者而言，最終的目標幾乎永遠都是資料。

在擁有敏感資料庫的組織中，有 38% 同時將這些資料庫暴露在公開網路上。財務紀錄、客戶資訊、醫療紀錄全數外露。對醫療機構而言，違反 HIPAA 的罰款最高可達 150 萬美元，但這並非醫療產業獨有的問題，而是普遍存在於各行各業。

正是在這裡數字開始變得駭人，原本看似零散的風險，一旦串聯就會演變成災難。一個錯誤設定、一組外洩憑證、一項被忽視的資產，透過攻擊路徑彼此連結，最終形成直通全面入侵的捷徑。

關鍵發現五、應用程式流程崩潰

「真正的問題不在雲端身上，而是在程式碼進入雲端之前就已經被打造出來。」

攻擊並非從生產環境開始，而是在開發階段就已經形成。它們早早被嵌入程式碼中，甚至在程式碼送入雲端之前就存在。

調查顯示，72% 的組織在程式碼庫中至少有一個存在嚴重漏洞的套件，CVSS 評分 7 以上，屬於關鍵等級。更令人震驚的是，97% 的這些漏洞套件都有修補方法可用，組織卻不在投入生產前套用修補程式，且明知存在漏洞卻仍部署到生產環境。

問題透過基礎架構即程式碼（Infrastructure-as-Code）進一步擴散。開發人員撰寫程式碼來定義雲端基礎架構，但程式碼中往往包含錯誤配置，將風險大規模傳播：

20% 的組織建立的 IAM 角色允許跨帳號存取，卻未設定多重驗證或外部 ID。攻擊者只要猜中正確的 AWS ARN，就能跨帳號取得高權限角色。

17% 的 S3 儲存桶設定為對任何人公開讀取，敏感資料暴露在網路上，等待自動掃描程式發現。

40% 的 GitHub Actions 工作流程允許自動批准 Pull Request，程式碼審查被跳過，惡意程式碼可能會被植入，並在沒有人工介入的情況下，被自動合併至主分支。

供應鏈受損的原因並非雲端本身，而是在程式碼送入雲端之前做出的決策。而這些錯誤直到程式碼進入生產環境並暴露在真實攻擊者的威脅下，才被發現。

調查結論

分析數十億筆數據，結果無可否認：

雲端有其問題但責任並非單純，這同時反映了人為的選擇，追求速度而犧牲安全、系統複雜卻缺乏可視性、只顧創新而忽視防護。這些模式在各行各業、不同規模的組織，以及各大雲端服務商，同樣的模式都在不斷上演。

Orca Research Pod 的調查不僅揭露了問題，也指出了前進的方向。組織必須優先掌握攻擊路徑而非僅關注單一風險，徹底落實最小權限原則，在機密資料離開儲程式碼儲存庫前就加以保護，不再忽視資產，清楚掌握敏感資料的位置，並將安全整合至整個開發流程，建立跨多雲環境的完整可視性。

這份調查揭示了 2025 年的資安危機，但真正的解方來自於立即採取行動。

你的調查行動現在開始

Orca Research Pod 花了一整年時間，橫跨數十億筆真實世界的雲端資產，深入解析整個雲端生態系，並發現相同的風險模式一再重現。但你的環境並不相同，你所面對的風險也具有高度專屬性，攻擊路徑更是因你而異。

想知道你的雲端環境中潛藏了哪些問題嗎？Orca 調查團隊已全面就位，將針對你的多雲環境進行完整掃描，涵蓋 AWS、Azure、Google Cloud 以及其他平台，挖掘隱身在可視性死角的風險，重建攻擊路徑，並聚焦那些真正值得優先處理的威脅。

準備好看清你雲端環境中的真實風險了嗎？

若想深入了解本次調查背後的完整證據、研究方法與詳細結論，歡迎下載白皮書⟪2025 雲端安全狀況報告⟫ ➤ https://www.gss.com.tw/whitepaper/4653-orca

所有數據與案例，皆來自 AWS、Azure、Google Cloud、Oracle Cloud 與阿里雲等平台，數十億筆生產環境雲端資產的實證分析。

若對 Orca 有興趣，歡迎於網頁中留下資訊，將會有專人與您聯繫 ➤ https://www.gss.com.tw/product-services-nav/info-security/orca