An attacker accessed AWS accounts belonging to several Qubole customers between 14 and 26 October, exfiltrating stored secrets and data, according to findings disclosed by cloud security firm Wiz and reported by The Hacker News on 9 November.
The intrusion did not depend on a vulnerability in the customers' own infrastructure. Instead, Wiz said, the attacker used credentials for an AWS account that Qubole's data lake platform employs to reach those customers — a cross-account trust relationship that exists by design. Qubole, owned by Idera, operates as a managed platform, and its service model requires programmatic access into customer environments to ingest, process and manage data.
How the attacker obtained those credentials has not been disclosed. Wiz and Qubole have not published details on the initial access vector, the number of customers affected, the categories or volume of data taken, whether the compromised credentials remain valid, or the containment timeline. No details have emerged on any of those points; they remain unknown at time of writing.
A trusted pathway, not a broken lock
The architecture here is unremarkable. Cross-account IAM roles are the standard mechanism by which SaaS vendors operate inside customer environments, and in most deployments they are configured correctly. The failure mode is treating vendor access as permanent, generously permissioned and unmonitored.
Because the traffic arrived over a legitimate, expected channel — a role the customers had deliberately granted — per-account hardening and workload-level detection signals had little to catch. An identity doing exactly what it was authorised to do, in aggregate across many accounts, is a pattern that only becomes visible when the trust relationship itself is monitored rather than the workloads behind it.
Vendor identities function as skeleton keys. One compromised credential in the vendor's environment translated into a blast radius measured in customer accounts, not in one.
Why cloud teams should care
Security questionnaires routinely ask about a vendor's compliance certifications and penetration testing cadence. They rarely ask how the vendor stores the credentials that reach your account, how often those credentials are rotated, or what limits exist on the blast radius if the vendor's own AWS environment is compromised. This breach is the argument for making those questions contractual.
For Hong Kong organisations operating under the Personal Data (Privacy) Ordinance, the exposure of stored secrets and customer data also carries data breach notification considerations — any entity handling personal data through third-party platforms may need to be able to demonstrate which processors hold standing access and how that access is controlled.
A six-point third-party IAM audit checklist
Cloud and security teams can interrogate their environments with the following questions:
- Inventory every cross-account trust relationship in your AWS organisation, including which vendor each one serves.
- Check whether vendor access is standing or just-in-time, and whether sessions have finite duration.
- Scope vendor permissions to least privilege rather than broad administrative roles.
- Monitor the trust itself in CloudTrail — look for assumed-role events and anomalous principals, not just workload anomalies.
- Ask vendors directly how they secure credentials on their side: storage, rotation, and external ID conditions.
- Rehearse revocation: confirm you can sever a vendor trust quickly without disrupting production.
Supporting controls worth enforcing include short-lived credentials, external ID conditions on role assumption, session policy boundaries, per-customer role separation, and continuous auditing of active trusts.
The recurring pattern
Qubole joins a list of SaaS and data-platform vendors whose own compromise became their customers' breach. The lesson repeats because the architecture repeats.
Customers of Qubole should seek direct confirmation of whether their accounts were in the affected set and treat any secrets stored in those environments as potentially exposed until cleared. For everyone else, the takeaway is narrower and more durable: audit third-party IAM trust with the same scrutiny you apply to internal privileged access.
雲端安全公司 Wiz 於 11 月 9 日披露、並由 The Hacker News 報道的調查結果顯示，一名攻擊者在 10 月 14 日至 26 日期間，存取了數個 Qubole 客戶的 AWS 帳戶，竊取了當中儲存的 secrets 及資料。
這次入侵並非利用客戶自身基建的漏洞。Wiz 指出，攻擊者改為使用一個 AWS 帳戶的憑證來存取這些客戶——該帳戶是 Qubole 資料湖平台運作所使用的，而這種 cross-account 信任關係本來就是系統設計的一部分。Qubole 由 Idera 擁有，以託管平台方式營運，其服務模式需要以 programmatic access 進入客戶環境，以進行資料的 ingest、處理及管理。
攻擊者如何取得這些憑證，目前並未披露。Wiz 與 Qubole 均未公布初始入侵途徑（initial access vector）、受影響客戶數目、被竊資料的類別或數量、被洩露的憑證是否仍然有效，以及遏制事件的時間表等細節。上述各點均未有新資料浮現；在撰寫本文時，這些仍然未知。
一條受信任的通道，而不是一把被撬開的鎖
這裡的架構其實並不罕見。cross-account IAM role 是 SaaS 供應商進入客戶環境運作的標準機制，而且在大多數部署中都配置正確。失效模式在於：把供應商的存取權視為永久、權限過寬且缺乏監控。
由於流量是透過一個合法且預期的渠道抵達——也就是客戶主動授予的 role——各帳戶層面的加固措施和工作負載層面的偵測信號幾乎無從攔截。一個身份正在做它被授權去做的所有事情，這點跨越多個帳戶綜合來看，只有在監控對象是信任關係本身、而非其背後的工作負載時，才會顯現出這種模式。
供應商身份就如同萬能鑰匙（skeleton key）。供應商環境中一個被洩露的憑證，造成的 blast radius 是以客戶帳戶計算，而非單一帳戶。
為何雲端團隊需要關注
安全問卷通常會詢問供應商的合規認證及滲透測試頻率，卻極少追問：供應商如何儲存能存取你帳戶的憑證、這些憑證多久輪換一次（rotation），以及一旦供應商自身的 AWS 環境被攻陷，blast radius 有何限制。這次事件正是將這些問題寫入合約條款的理據。
對於依據《個人資料（私隱）條例》運作的香港機構而言，儲存的 secrets 及客戶資料外洩亦涉及資料外洩通知（data breach notification）的考量——任何透過第三方平台處理個人資料的實體，可能需要能夠證明哪些 processor 持有常設存取權限，以及該等存取如何受到管控。
第三方 IAM 審計六點清單
雲端及安全團隊可用以下問題審視自身環境：
- 盤點你的 AWS organisation 內所有 cross-account 信任關係，包括每一項對應哪個供應商。
- 檢查供應商存取是常設（standing）還是 just-in-time，以及 session 是否有有限的持續時間。
- 將供應商權限範圍縮減至 least privilege，而非寬泛的管理員 role。
- 在 CloudTrail 中監控信任關係本身——留意 assumed-role 事件及異常 principal，而非僅監視工作負載異常。
- 直接向供應商查詢其憑證的保護方式：儲存、輪換及 external ID 條件。
- 演練撤銷流程：確認你能迅速切斷供應商信任關係而不影響生產環境。
值得落實的配套措施包括：短期有效的憑證、role assumption 的 external ID 條件、session policy 邊界、按客戶劃分的 role 隔離，以及對現有信任關係的持續審計。
一再重現的模式
Qubole 加入了另一份名單——自身被攻陷最終演變成客戶資料外洩的 SaaS 及資料平台供應商。教訓之所以反覆重現，是因為架構本身不斷重複。
Qubole 的客戶應直接確認其帳戶是否在受影響範圍之內，並在獲得澄清之前，視環境中儲存的任何 secrets 為可能已曝光。對其他人而言，結論更為聚焦且持久：審計第三方 IAM 信任關係時，應以審視內部特權存取的同等嚴格標準來處理。