企業投入大量資源強化登入安全。從 SSO、MFA、Passwordless 到裝置驗證，目的都是確保進入企業系統的人確實是被授權的使用者。但有一個問題經常被忽略：如果使用者在登入之後才出現風險呢？
假設一名員工早上正常登入企業系統，密碼正確、MFA 通過、裝置也符合公司的安全政策，整個登入流程沒有任何異常。從傳統身分驗證的角度來看，這是一個可信任的 Session。但半小時之後，如果 Security Team 收到新的風險訊號，顯示這個帳號可能遭到入侵；或者原本合法建立的 Session 被竊取並從另一個環境使用，企業還應該繼續相信早上那一次驗證結果嗎？
這正是現代 Identity Security 面對的關鍵轉變。
Authentication 發生在一個時間點，但 Risk 會在整個 Session 期間持續改變。
因此，真正成熟的 Identity Security 不能只回答「現在要不要讓這個人登入」，還必須持續回答另一個問題：
這個 Identity 現在還值得信任嗎？
通過 MFA，不代表後續 Session 一直安全
MFA 大幅提高帳號遭到未授權登入的難度，但它解決的主要是「登入當下」的驗證問題。當使用者完成驗證並建立 Session 之後，企業面對的風險並沒有因此停止。
例如，攻擊者不一定要重新取得使用者的密碼與 MFA。如果已經建立的 Session 遭到劫持，攻擊者可能嘗試利用既有 Session 繼續存取系統。另一方面，企業也可能是在登入完成之後，才從 Endpoint Security、Network Security、Threat Intelligence 或其他安全工具收到新的訊號，發現這個帳號、裝置或使用者行為已經出現異常。
這代表「登入時是 Low Risk」和「兩小時後仍然是 Low Risk」是兩件不同的事。
Okta Identity Threat Protection with Okta AI（ITP）正是針對這個落差設計。Okta 將風險區分成 Login Risk、Session Risk 與 Entity Risk：Login Risk 評估登入當下的風險；Session Risk 會在既有 Okta Session 期間持續重新評估是否可能遭到入侵；Entity Risk 則從更完整的使用者角度，綜合不同 Session、裝置、應用程式與安全訊號來判斷這個 Identity 是否可能已經受到威脅。
這個差異非常重要。傳統 Authentication 容易形成一種「通過驗證之後就持續信任」的模式；Continuous Identity Security 則認為 Trust 應該隨著最新 Risk Context 持續改變。
Authentication 是一個事件，Trust 則應該是一個持續被重新評估的狀態。
Identity Threat 不一定發生在登入那一刻
很多企業的 Security Control 仍然高度集中在登入入口。使用者輸入帳號密碼、完成 MFA，系統依照 Location、Device、Network 或其他條件決定是否允許登入。這些控制非常重要，但如果 Security Decision 只發生在登入時，就會留下登入後的監控空間。
Session Hijacking 就是一個很好的例子。真正的使用者可能已經合法完成驗證，但如果既有 Session 遭到竊取或被異常使用，企業需要辨識的是「現在這個 Session 是否仍然正常」，而不是重新檢查幾小時前的 MFA 是否成功。
同樣地，帳號遭到入侵的訊號也可能來自其他 Security System。Endpoint 工具可能發現裝置風險，Network Security 平台可能偵測到異常活動，或外部安全訊號顯示這名使用者的 Risk Level 已經改變。如果 Identity Platform 無法接收並利用這些新資訊，企業的 Access Decision 就可能仍然建立在已經過時的信任狀態上。
Okta ITP 會持續監控即時的 Identity-based threats，包括 Session Hijacking、Phishing 與 Compromised Accounts，並可接收其他 Security System 提供的訊號，透過 Dynamic Risk Scoring 重新判斷風險，再依照 Risk Level 採取回應。
這也說明了為什麼 Identity Threat Protection 和上一篇談到的 Identity Security Posture Management（ISPM）並不是同一件事。ISPM 比較關注企業環境裡已經存在的 Stale Account、MFA Gap、過多權限或其他 Identity Misconfiguration，目的是在攻擊發生之前縮小 Attack Surface；ITP 則更進一步處理 Identity 正在被使用時，風險是否發生變化，以及企業應該如何即時反應。
Identity Security 正從一次驗證，走向持續的 Risk Evaluation
傳統模式的邏輯很直覺：使用者提出登入要求，系統進行 Authentication 和 Risk Check，符合 Policy 就允許進入。問題是，這個 Access Decision 很容易被理解成一次性的。
Continuous Identity Security 則把整個 Session 納入判斷。使用者登入後，系統仍然持續接收新的 Context 與 Risk Signal。如果 Session Risk 或整體 Entity Risk 發生變化，就重新評估目前的信任程度以及 Access 是否仍然合理。
這並不代表企業需要不斷要求每位員工重新輸入 MFA。真正的目的恰恰相反：根據風險採取相對應的控制，而不是讓所有使用者承受相同的 Security Friction。
低風險 Session 可以繼續正常工作；當出現值得確認的風險時，可以要求 Step-up Authentication；如果風險已經明顯升高，則可以終止 Session 或進一步撤銷應用程式中的存取。
Okta ITP 的 Post Auth Session Monitoring 正是建立在這個概念上。除了登入風險之外，Security Team 還能透過 Session Violation、Entity Risk Detection 與 At-Risk Users 等資訊持續觀察登入後的風險變化，而不是等到下一次 Login 才重新判斷。
這讓 Identity Security 從單純的：
Authenticate → Allow
轉變成：
Authenticate → Monitor → Re-evaluate → Respond
真正改變的不是 Authentication 本身，而是企業不再假設一次成功的 Authentication 可以代表整個 Session 都值得信任。
發現高風險 Identity 還不夠，企業必須能立即回應
Identity Threat Detection 最容易遇到的問題，是 Security Team 已經知道 User Risk 升高，卻仍然需要透過人工流程才能真正阻止存取。
例如 SOC 收到 Alert 後，由 Analyst 進行調查，再開 Ticket 通知 IT 停用帳號。這套流程在很多企業仍然存在，但對 Session Hijacking 或正在進行中的帳號入侵而言，人工處理的時間差本身就是風險。因此，Identity Threat Protection 的價值不應只停留在 Detection，而應該把 Risk Signal 直接轉成 Access Decision。
Okta ITP 可以依照風險與 Policy 執行不同回應，例如要求使用者重新驗證、終止高風險 Session，或透過 Universal Logout 與 Workflows 啟動更進一步的處理。Okta 目前也利用 Shared Signals Framework 與其他 Security Platform 分享及接收相關 Security Signal，讓 Identity Decision 能夠利用更完整的安全脈絡。
其中 Universal Logout 特別容易被忽略。
如果企業只是停用 Okta 端的帳號或 Session，這主要可以阻止後續的登入，但某些第三方應用程式可能已經建立自己的 Session 或 Token。Okta Universal Logout 的目的，是讓 Identity Provider 在偵測到威脅或處理員工離職等事件時，向支援的應用程式送出 Server-to-Server Logout Request，要求撤銷該使用者現有的 Session 與 Token。
因此：
阻止下一次登入，和停止現在正在進行的 Session，是兩件不同的事。
這也是 Continuous Identity Security 與傳統 Account Control 最大的差異之一。
Zero Trust 的核心，不是永遠不信任，而是 Trust 可以改變
Zero Trust 經常被濃縮成「Never trust, always verify」，但如果 Verify 只發生在早上登入公司的那一次，實際上仍然是一種 Point-in-Time Trust。
更完整的思維應該是：早上 9 點，使用者通過 MFA、使用受管理的裝置，而且沒有異常訊號，因此系統判斷為 Low Risk 並允許存取；到了下午，如果新的 Security Signal 顯示這個帳號可能遭到入侵，原本的 Trust Decision 也應該跟著改變。
換句話說：
Trust should follow Risk.
這也是前三篇文章所談的 Identity Security Journey 再往前的一步。Lifecycle Management 讓 Access 跟著人的工作狀態改變；Identity Governance 持續確認這些 Access 是否仍然合理；ISPM 找出企業已經累積的 Identity Security Risk；而 Identity Threat Protection 則在 Identity 正在被使用的過程中，持續判斷原本的 Trust 是否仍然成立。
MFA、Passwordless、FastPass 和其他 Authentication Method 仍然非常重要，但它們主要回答的是：
「現在要不要讓這個 User 進來？」
Identity Threat Protection 要回答的則是登入之後的另一個問題：
「現在還要不要讓這個 Session 繼續？」
登入成功，只代表這個 Identity 在那一刻通過驗證；真正成熟的 Identity Security，必須持續確認它現在是否仍然值得信任。
如果您的企業已經建立完善的 MFA 與 SSO，但登入後的 Identity Risk 仍然主要依賴 SOC Alert 和人工處理，下一個值得檢視的可能就是 Authentication、Session Monitoring 與 Automated Response 之間的缺口。
歡迎聯絡思想科技 Master Concept 專業顧問一起評估企業目前的 Identity Threat Detection & Response 能力，了解 Okta Identity Threat Protection 如何把登入安全延伸到整個 Session Lifecycle。
FAQ
什麼是 Identity Threat Protection？
Identity Threat Protection 是在使用者登入後持續評估 Identity Risk，並在風險升高時採取重新驗證、終止 Session 或其他安全回應。
MFA 通過後，帳號還可能被攻擊嗎？
可能。MFA 主要保護登入階段，Session Hijacking 或登入後出現的新風險仍可能讓原本可信的 Session 變成高風險。
Continuous Authentication 是什麼？
Continuous Authentication 是根據使用者、Session、裝置與最新 Risk Signal 持續重新評估 Trust，而不是只在登入時驗證一次。
Okta Identity Threat Protection 可以做什麼？
Okta ITP 可以持續評估 Login、Session 與 Entity Risk，並依照風險與 Policy 觸發重新驗證、Session Termination、Universal Logout 或其他自動化回應。
Universal Logout 是什麼？
Universal Logout 可以要求支援的應用程式撤銷使用者現有的 Session 與 Token，協助企業在發現 Identity Threat 時停止目前正在進行的存取。
