4,、零信任架構(gòu)設(shè)計原則：使用策略來授權(quán)請求

　　每個對數(shù)據(jù)或服務(wù)的請求都應(yīng)根據(jù)策略進(jìn)行授權(quán),。

　　介紹

　　零信任架構(gòu)的強大之處在于您定義的訪問策略,。政策還有助于促進(jìn)與來賓用戶或合作伙伴組織的數(shù)據(jù)或服務(wù)的風(fēng)險管理共享,。

　　使用支持持續(xù)身份驗證和授權(quán)過程的產(chǎn)品,、托管服務(wù)和協(xié)議,。

　　示例 - 策略授權(quán)的訪問

　　這是一個用戶訪問服務(wù)或公司數(shù)據(jù)的簡單理論示例,，其中包含授權(quán)請求的策略,。一個更深入的例子,，擴(kuò)展了授權(quán)過程中信號的使用,，可以在下面的使用多個信號做出訪問決策中找到。

　　用戶建立與策略實施點的連接,，這將調(diào)解他們與請求的服務(wù)或數(shù)據(jù)的連接,。

　　該策略執(zhí)行點會查詢策略引擎的訪問決定。在向執(zhí)行點提供訪問決定之前,，策略引擎將根據(jù)訪問策略評估請求,。

　　如果訪問請求被策略引擎接受，策略執(zhí)行點就會允許該請求,。如果它被策略引擎拒絕,，則連接將被丟棄。

　　訪問決策正在不斷地實時評估,。安全狀態(tài)的變化可能需要終止連接或重新進(jìn)行身份驗證,。

　　如何使用策略來授權(quán)請求取決于部署的零信任技術(shù),。例如，使用托管云服務(wù)的零信任與本地網(wǎng)絡(luò)不同,。

　　在某些方法中,，使用的名稱和術(shù)語可能與我們上面的示例略有不同。

　　持續(xù)評估

　　通過監(jiān)控來自用戶和設(shè)備的信號并對其進(jìn)行持續(xù)評估來支持持續(xù)評估,。如果對其安全性的信心下降,，則可能會在授權(quán)繼續(xù)訪問服務(wù)和數(shù)據(jù)之前動態(tài)觸發(fā)重新身份驗證。

　　無論如何設(shè)計零信任架構(gòu),，策略引擎或任何強制執(zhí)行策略的組件都應(yīng)僅在滿足定義的嚴(yán)格策略時才允許連接,。

　　保護(hù)策略引擎

　　必須高度信任任何執(zhí)行訪問策略的產(chǎn)品或服務(wù)，這一點很重要,。應(yīng)該確保架構(gòu)的這些基本元素在設(shè)計時考慮了零信任,。如果此組件遭到破壞，攻擊者將可以控制誰有權(quán)訪問數(shù)據(jù)或服務(wù),。

　　重要的是,，對策略引擎的訪問僅限于與受信任的策略實施點或提供信號的服務(wù)（例如用戶身份服務(wù)）進(jìn)行通信。它不應(yīng)與不受信任的來源通信,，例如未經(jīng)身份驗證的最終用戶設(shè)備,。

　　當(dāng)策略引擎解析信號時，源應(yīng)該來自相互認(rèn)證的可信和已知實體,。輸入也應(yīng)該在解析之前進(jìn)行驗證,。這可確保策略引擎不會消耗任何惡意內(nèi)容。如果您使用的策略引擎是托管服務(wù),，則安全解析信號的過程很可能是服務(wù)提供商的責(zé)任,。

　　保護(hù)導(dǎo)入策略引擎的策略也很重要。限制誰可以將策略導(dǎo)入受信任用戶以及能夠?qū)徍撕蛯彶椴呗缘哪芰κ顷P(guān)鍵,。

　　使用多個信號來做出訪問決策

　　策略決策應(yīng)考慮從歷史信息和實時連接信息中獲取的多個信號,。總之,，這些能夠構(gòu)建上下文,，因此可以決定是否可以足夠信任訪問請求以繼續(xù)。這些信號被輸入到一個策略引擎中,，因此它可以做出明智的訪問決策,。

　　使用多個信號來獲得對訪問請求的信心很重要，因為這將提供更多信息進(jìn)行分析,，并提供更大的信心,，即請求者是真實的并且他們的設(shè)備處于良好的網(wǎng)絡(luò)健康狀態(tài)。

　　高影響力的操作,，例如創(chuàng)建新的管理員級別用戶,，必須滿足嚴(yán)格的策略要求才能被信任,。而相對較低影響的操作，例如查看在線午餐菜單,，則必須滿足更寬松的政策要求,。

　　示例 - 向策略引擎評估信號

　　下圖描述了策略引擎如何評估多個信號的理論示例。信號和用戶訪問（通過策略執(zhí)行點）由策略引擎持續(xù)評估,。

　　根據(jù)對零信任的實施和使用的信號類型,，細(xì)節(jié)可能會發(fā)生變化，但此處說明的原則應(yīng)該是相同的,。

　　購買零信任技術(shù)

　　在為零信任架構(gòu)選擇技術(shù)時,，請評估它們支持的信號類型以及其他相關(guān)功能，以便與策略引擎兼容,。

　　策略引擎可以評估的一些示例信號是：

　　用戶的角色

　　用戶的物理位置

　　認(rèn)證因素

　　設(shè)備健康

　　一天中的時間

　　要訪問的服務(wù)的價值

　　所要求的行動的風(fēng)險

　　基于風(fēng)險的引擎

　　一些策略引擎將允許創(chuàng)建基于風(fēng)險的訪問策略,，可能會提示額外的信號以獲得對連接的更多信心。

　　基于風(fēng)險的策略引擎會考慮用戶和設(shè)備的置信度,，動態(tài)調(diào)整訪問策略作為響應(yīng),。例如，假設(shè)用戶在正常工作時間之外首次嘗試訪問高價值服務(wù),。在這種情況下,，策略引擎可能會要求用戶提供用于身份驗證的第二個因素。

　　其他注意事項

　　拒絕訪問

　　當(dāng)訪問請求被拒絕時,，請考慮如何通知用戶,。太多的信息可能會幫助攻擊者，太少可能會挫敗合法用戶,。

　　可能會指出存在身份驗證錯誤,，但不會通過說“該賬戶不存在”之類的內(nèi)容來詳細(xì)說明失敗的原因,。如果沒有這些線索,，攻擊者要枚舉認(rèn)證信息就困難得多。

　　打破玻璃

　　如果出現(xiàn)對數(shù)據(jù)訪問至關(guān)重要的緊急情況,，可能需要制定一個允許建立連接的流程,，即使無法滿足訪問策略也是如此。任何使用破玻璃程序的行為都應(yīng)注意共享媒體,，例如群組郵箱或共享聊天頻道,。這樣就可以發(fā)現(xiàn)任何濫用憑據(jù)的行為并及時采取行動。

　　在這種情況下,，需要謹(jǐn)慎管理風(fēng)險以防止濫用此功能,。例如，限制與緊急訪問相關(guān)的風(fēng)險,，只允許從個人用戶帳戶,、特定設(shè)備上,、指定位置在有限的時間內(nèi)進(jìn)行此類訪問，并且需要最低權(quán)限,。

　　可用性

　　一旦定義了管理對數(shù)據(jù)和服務(wù)的訪問控制的策略,，應(yīng)該評估可用性是否因錯誤地阻止合法訪問請求而受到影響。

　　首次定義策略后,，首先在一小段時間內(nèi)記錄并不拒絕訪問,，以確保策略按預(yù)期運行。在此評估期間,，定期審核日志并在發(fā)生惡意嘗試訪問數(shù)據(jù)或服務(wù)時立即采取措施非常重要,。

　　可能的情況是，需要一個過渡期,，傳統(tǒng)安全控制措施會主動阻止請求,，同時正在衡量新違抗策略的有效性。

　　5,、零信任架構(gòu)設(shè)計原則：無處不在的認(rèn)證和授權(quán)

　　假設(shè)網(wǎng)絡(luò)是敵對的,，驗證和授權(quán)所有訪問數(shù)據(jù)或服務(wù)的連接。

　　介紹

　　構(gòu)建具有強大身份驗證方法的系統(tǒng)并構(gòu)建應(yīng)用程序以接受來自策略引擎的訪問決策,。

　　在評估與訪問請求相關(guān)的風(fēng)險時,，身份驗證和授權(quán)決策應(yīng)考慮多種信號，例如設(shè)備健康狀況,、設(shè)備位置,、用戶身份和狀態(tài)。

　　多因素

　　MFA是零信任架構(gòu)的要求,。

　　這并不意味著用戶體驗一定很差,。在現(xiàn)代設(shè)備和平臺上，可以通過良好的用戶體驗實現(xiàn)強大的MFA,。例如,，僅當(dāng)用戶和設(shè)備的信心下降時才觸發(fā) MFA。某些身份驗證應(yīng)用程序會在受信任的設(shè)備上提供推送通知,，因此用戶無需為鍵入代碼或查找硬件令牌而煩惱,。

　　值得注意的是，并非所有身份驗證因素對用戶都是可見的,，其中一個因素可能是使用內(nèi)置 FIDO2 （線上快速身份驗證服務(wù)）平臺身份驗證器的加密支持的無密碼登錄,。

　　可用性

　　重要的是，強身份驗證不會妨礙服務(wù)的可用性,。例如,，僅當(dāng)請求具有較高影響時才提示其他身份驗證因素，例如請求敏感數(shù)據(jù)或特權(quán)操作，包括創(chuàng)建新用戶,。應(yīng)考慮 SSO,，以減少 MFA 的摩擦。

　　應(yīng)考慮采用基于風(fēng)險的方法來減輕額外身份驗證因素造成的更大影響,。在上面的示例中,，如果用戶的置信水平足夠高，則可以避免其他因素,。

　　無密碼身份驗證（例如 FIDO2）是一種理想的解決方案,，因為它提供了強大的安全性和出色的用戶體驗?？紤]實施無密碼身份驗證,，以在用戶所有服務(wù)中獲得強大、一致和積極的用戶體驗,。

　　服務(wù)到服務(wù)

　　服務(wù)之間的請求也需要進(jìn)行身份驗證,。通常是使用 API 令牌、OAuth 2.0 或公鑰基礎(chǔ)設(shè)施 （PKI）等框架來實現(xiàn)的,。

　　使用相互身份驗證,，因此用戶可以確信通信的兩個服務(wù)都是真實的。這是構(gòu)建允許列表時的關(guān)鍵,，以根據(jù)身份授權(quán)服務(wù)之間的連接,。