【慢幾拍】Okta遭網絡入侵事件曝光 全因員工私用Google帳戶？
Okta在今年 9 月遭受網絡入侵，經過長達 14 日調查，經整理後終於發表調查報告。官方確認攻擊者存取了 Okta 客戶支援系統內的 134 位客戶相關檔案，其中一些檔案還包含 session token 的檔案。Okta 方面表示這次問題出在公司其中一位員工身上，聲稱因為該員工沒有遵守安全政策，在公司管制的電腦上登入私人 Google 帳戶，結果導致公司遭受攻擊。
至少收到 3 間公司舉報
根據報告顯示，事件發生在今年 9 月尾，Okta 客戶 1Password 在 29 日回報發現可疑活動，似乎有不明人士嘗試登入他們的員工帳戶，而另一間同樣為 Okta 的客戶，專門提供身份驗證服務的 BeyondTrust 亦在 10 月 2 日作出同樣舉報，到 10 月 12 日就輪到第三間公司向 Okta 回報。
而在為期 14 日的調查期間，Okta 起初未有從公司的日誌中找到可疑的下載行為，一直去到 10 月 13 日 BeyondTrust 提供 IP 位置線索，Okta 才在 10 月 16 日鎖定之前未注意到遭竊取的服務帳戶。
Okta 方面解釋，原來這次事件的起因是公司其中一位職員在公司提供的電腦上，私自登入自己的Google 帳戶，令公司帳戶的登入資料同時被儲存到他的雲端帳戶內，而相信這個職員的 Google 帳戶遭受入侵，黑客便能從帳戶內取得 Okta 帳戶的登入 session token，而由於該員工帳戶擁有查看和更新客戶支援檔案的權限，因此黑客亦可讀取 134 個 Okta 客戶的檔案，不過公司就聲稱只得 5 個客戶受到的影響較大。
Okta 被指未有及時處理
Okta 方面在又在報告內解釋，起初他們以為是與存取客戶支援案例有關，才導致調查方向完全出錯，官方指在一般情況下，當使用者開啟並查看支援案例相關的附件時，會產生一個特定的日誌事件類型和 ID，但如果使用者好像這次黑客使用的方法一樣，在客戶支援系統直接導航至檔案標籤，在日誌事件系統中便會產生完全不同的 ID 紀錄，由於忽視了這種可能性，才拖延了調查進度。
不過，這次事件的關注點是 Okta 其實已經發現有問題，但未有及時作出處理，導致另一客戶在兩日後遭受入侵。Cloudflare 指事件中沒有客戶資料被影響，但就公開指責 Okta 反應慢幾拍，才會讓黑客繼續利用。
另外，Okta 其實也無法肯定黑客的入侵方法，只能推斷攻擊行為。作為身分驗證服務供應商，似乎好難解得通。
相關文章：【預算有限？】SailPoint年度報告 揭逾四成企業身分安全屬初期發展
