應用零信任重點防護失效的對象級授權(quán)
實施數(shù)字化轉(zhuǎn)型的公司有著明確的業(yè)務需求。這包括借助現(xiàn)代業(yè)務應用改善客戶體驗，采用敏捷實踐以超越市場競爭對手，以及利用市場優(yōu)勢創(chuàng)造新的收入來源。新型應用架構(gòu)不僅可提高開發(fā)效率，而且集容器、微服務和 API 于一體，可幫助滿足這些需求。
對現(xiàn)代應用來說，安全性是現(xiàn)代應用敏捷性和上線時效性至關(guān)重要的一部分。企業(yè)已經(jīng)開始考慮使用 WAAP 解決方案來應對 API 安全隱患，其中 OWASP API Top 10 是 API 安全的關(guān)鍵第一步防線，通過 Salt Security《State of API Security Report, Q3 2022》報告，說明近一半用戶安全團隊都沒有將 OWASP API 安全性前十列為重點領(lǐng)域，對于 OWASP API TOP 1 失效的對象級授權(quán)是防護的關(guān)鍵。
失效的對象就會涉及到 ID 和 Token 概念，ID 和 Token 不得不提就是當今最為關(guān)注的零信任話題。
零信任可以分為兩類，網(wǎng)絡(luò)零信任接入和應用零信任接入：
網(wǎng)絡(luò)零信任 Zero Trust Network Architecture
應用零信任 Zero Trust Application Access
網(wǎng)絡(luò)零信任解決是接入網(wǎng)絡(luò)時安全性，與應用零信任防護在不同的層級。舉例說明；黑客拿著泄露了的用戶名密碼，或者利用業(yè)務系統(tǒng)漏洞，從辦公網(wǎng)直接進來的攻擊流量卻防不勝防，這就是因為微隔離無法判斷這些來自辦公網(wǎng)的流量究竟是誰發(fā)起的，以及是否有權(quán)利有必要訪問那些 API 業(yè)務系統(tǒng)。
所以對接入 API 應用系統(tǒng)需要持續(xù)性認證才能更好的防護 ZTAA - Zero Trust Application Access。通過 ZTAA 要解決接入零信任，同時判斷對象 ID 和 Key Token 的一致性，減少惡意發(fā)起對象枚舉行為造成的數(shù)據(jù)泄露。
API 應用接入控制流程
用戶請求身份認證到 IdP（Identity Provider）身份提供
通過認證頒發(fā)令牌給用戶
用戶攜帶令牌訪問 External APIs 應用接口
External 接口轉(zhuǎn)發(fā)請求到 Internal APIs 接口
通過訪問流程對應關(guān)系，安全加固需要在 External APIs 和 Internal APIs 做到 API 接入持續(xù)驗證，永不信任，確保接入應用的安全性。
F5 API 應用接入控制流程
用戶請求身份認證到 IdP（Identity Provider）身份提供
通過認證頒發(fā)令牌給用戶
用戶攜帶令牌訪問 External APIs 應用接口
通過 F5 APM（Access Policy Manage）接入策略管理功能或 LTM Add-on APM 模塊，實現(xiàn)接入屬性控制策略和重新簽發(fā)內(nèi)部識別的 JWT 令牌
External 接口轉(zhuǎn)發(fā)請求到 Internal APIs 接口
微服務接口使用 NGINX 對 JWT 令牌中的屬性值執(zhí)行接入控制策略
F5 在 External APIs 和 Internal APIs 做到 API 接入持續(xù)驗證，永不信任，可以實現(xiàn)對接入控制權(quán)限限制，其中可以包括地位位置、URL、部門信息、情報信息，作為驗證的屬性閥值，保證接入應用的安全性。
失效的對象級授權(quán)最佳實踐解決方案
用戶請求身份認證到 IdP（Identity Provider）身份提供，為認證用戶分配 GUID，并且可以通過 JWT Claim 添加更多的聲明屬性，比如地理位置、部門、用戶 ID 等信息在 JWT Token，上述案例描述 Claim 包括 userID LU 信息 id=4079a01-d87w1-7682-02ha
用戶攜帶令牌和URL訪問 External APIs 應用接口，并且 URL 標識用戶請求的 ID
通過對外 API F5 BIG-IP APM 可以執(zhí)行訪問控制檢查，比較 JWT的 UserID 和 URL 參數(shù)中的 ID 是否一致性，BIG-IP APM 允許請求并將其轉(zhuǎn)發(fā)到 API 端點，否則拒絕請求
對于微服務內(nèi)部 API 接口，可以通過 NGINX 可以執(zhí)行訪問控制檢查，比較 JWT 的 UserID 和 URL 參數(shù)中的 ID 是否一致性，否則拒絕請求
當您對 API 流量實施身份驗證時，成功證明其身份的客戶端會從受信任的身份提供商那里獲得令牌，然后客戶端再為每個HTTP 請求提供訪問令牌。
在將請求傳遞給應用之前，通過 APM或者 NGINX Plus 會驗證令牌并提取在令牌中編碼的身份和其他數(shù)據(jù)（例如組成員資格），以確保對客戶端進行身份驗證和授權(quán)。
令牌得到驗證并且客戶端獲得訪問資源的授權(quán)后，請求就會被傳遞到應用服務器。驗證方法有很多種，其中使用 OpenID Connect（基于 OAUTH 2.0 協(xié)議構(gòu)建）是一種流行的做法，它可以對 API 請求進行第三方身份驗證。
閩公網(wǎng)安備 35010202001226號
