每個對數(shù)據或服務的請求都應根據策略進行授權。
介紹
零信任架構的強大之處在于您定義的訪問策略。政策還有助于促進與來賓用戶或合作伙伴組織的數(shù)據或服務的風險管理共享。
使用支持持續(xù)身份驗證和授權過程的產品、托管服務和協(xié)議。
示例 - 策略授權的訪問
這是一個用戶訪問服務或公司數(shù)據的簡單理論示例，其中包含授權請求的策略。一個更深入的例子，擴展了授權過程中信號的使用，可以在下面的使用多個信號做出訪問決策中找到。
用戶建立與策略實施點的連接，這將調解他們與請求的服務或數(shù)據的連接。
該策略執(zhí)行點會查詢策略引擎的訪問決定。在向執(zhí)行點提供訪問決定之前，策略引擎將根據訪問策略評估請求。
如果訪問請求被策略引擎接受，策略執(zhí)行點就會允許該請求。如果它被策略引擎拒絕，則連接將被丟棄。
訪問決策正在不斷地實時評估。安全狀態(tài)的變化可能需要終止連接或重新進行身份驗證。
如何使用策略來授權請求取決于部署的零信任技術。例如，使用托管云服務的零信任與本地網絡不同。
在某些方法中，使用的名稱和術語可能與我們上面的示例略有不同。
持續(xù)評估
通過監(jiān)控來自用戶和設備的信號并對其進行持續(xù)評估來支持持續(xù)評估。如果對其安全性的信心下降，則可能會在授權繼續(xù)訪問服務和數(shù)據之前動態(tài)觸發(fā)重新身份驗證。
無論如何設計零信任架構，策略引擎或任何強制執(zhí)行策略的組件都應僅在滿足定義的嚴格策略時才允許連接。
保護策略引擎
必須高度信任任何執(zhí)行訪問策略的產品或服務，這一點很重要。應該確保架構的這些基本元素在設計時考慮了零信任。如果此組件遭到破壞，攻擊者將可以控制誰有權訪問數(shù)據或服務。
重要的是，對策略引擎的訪問僅限于與受信任的策略實施點或提供信號的服務（例如用戶身份服務）進行通信。它不應與不受信任的來源通信，例如未經身份驗證的最終用戶設備。
當策略引擎解析信號時，源應該來自相互認證的可信和已知實體。輸入也應該在解析之前進行驗證。這可確保策略引擎不會消耗任何惡意內容。如果您使用的策略引擎是托管服務，則安全解析信號的過程很可能是服務提供商的責任。
保護導入策略引擎的策略也很重要。限制誰可以將策略導入受信任用戶以及能夠審核和審查策略的能力是關鍵。
使用多個信號來做出訪問決策
策略決策應考慮從歷史信息和實時連接信息中獲取的多個信號。總之，這些能夠構建上下文，因此可以決定是否可以足夠信任訪問請求以繼續(xù)。這些信號被輸入到一個策略引擎中，因此它可以做出明智的訪問決策。
使用多個信號來獲得對訪問請求的信心很重要，因為這將提供更多信息進行分析，并提供更大的信心，即請求者是真實的并且他們的設備處于良好的網絡健康狀態(tài)。
高影響力的操作，例如創(chuàng)建新的管理員級別用戶，必須滿足嚴格的策略要求才能被信任。而相對較低影響的操作，例如查看在線午餐菜單，則必須滿足更寬松的政策要求。
示例 - 向策略引擎評估信號
下圖描述了策略引擎如何評估多個信號的理論示例。信號和用戶訪問（通過策略執(zhí)行點）由策略引擎持續(xù)評估。
根據對零信任的實施和使用的信號類型，細節(jié)可能會發(fā)生變化，但此處說明的原則應該是相同的。
購買零信任技術
在為零信任架構選擇技術時，請評估它們支持的信號類型以及其他相關功能，以便與策略引擎兼容。
策略引擎可以評估的一些示例信號是：
用戶的角色
用戶的物理位置
認證因素
設備健康
一天中的時間
要訪問的服務的價值
所要求的行動的風險
基于風險的引擎
一些策略引擎將允許創(chuàng)建基于風險的訪問策略，可能會提示額外的信號以獲得對連接的更多信心。
基于風險的策略引擎會考慮用戶和設備的置信度，動態(tài)調整訪問策略作為響應。例如，假設用戶在正常工作時間之外首次嘗試訪問高價值服務。在這種情況下，策略引擎可能會要求用戶提供用于身份驗證的第二個因素。
其他注意事項
拒絕訪問
當訪問請求被拒絕時，請考慮如何通知用戶。太多的信息可能會幫助攻擊者，太少可能會挫敗合法用戶。
可能會指出存在身份驗證錯誤，但不會通過說“該賬戶不存在”之類的內容來詳細說明失敗的原因。如果沒有這些線索，攻擊者要枚舉認證信息就困難得多。
打破玻璃
如果出現(xiàn)對數(shù)據訪問至關重要的緊急情況，可能需要制定一個允許建立連接的流程，即使無法滿足訪問策略也是如此。任何使用破玻璃程序的行為都應注意共享媒體，例如群組郵箱或共享聊天頻道。這樣就可以發(fā)現(xiàn)任何濫用憑據的行為并及時采取行動。
在這種情況下，需要謹慎管理風險以防止濫用此功能。例如，限制與緊急訪問相關的風險，只允許從個人用戶帳戶、特定設備上、指定位置在有限的時間內進行此類訪問，并且需要最低權限。
可用性
一旦定義了管理對數(shù)據和服務的訪問控制的策略，應該評估可用性是否因錯誤地阻止合法訪問請求而受到影響。
首次定義策略后，首先在一小段時間內記錄并不拒絕訪問，以確保策略按預期運行。在此評估期間，定期審核日志并在發(fā)生惡意嘗試訪問數(shù)據或服務時立即采取措施非常重要。
可能的情況是，需要一個過渡期，傳統(tǒng)安全控制措施會主動阻止請求，同時正在衡量新違抗策略的有效性。
5、零信任架構設計原則：無處不在的認證和授權
假設網絡是敵對的，驗證和授權所有訪問數(shù)據或服務的連接。
介紹
構建具有強大身份驗證方法的系統(tǒng)并構建應用程序以接受來自策略引擎的訪問決策。
在評估與訪問請求相關的風險時，身份驗證和授權決策應考慮多種信號，例如設備健康狀況、設備位置、用戶身份和狀態(tài)。
多因素
MFA是零信任架構的要求。
這并不意味著用戶體驗一定很差。在現(xiàn)代設備和平臺上，可以通過良好的用戶體驗實現(xiàn)強大的MFA。例如，僅當用戶和設備的信心下降時才觸發(fā) MFA。某些身份驗證應用程序會在受信任的設備上提供推送通知，因此用戶無需為鍵入代碼或查找硬件令牌而煩惱。
值得注意的是，并非所有身份驗證因素對用戶都是可見的，其中一個因素可能是使用內置 FIDO2 （線上快速身份驗證服務）平臺身份驗證器的加密支持的無密碼登錄。
可用性
重要的是，強身份驗證不會妨礙服務的可用性。例如，僅當請求具有較高影響時才提示其他身份驗證因素，例如請求敏感數(shù)據或特權操作，包括創(chuàng)建新用戶。應考慮 SSO，以減少 MFA 的摩擦。
應考慮采用基于風險的方法來減輕額外身份驗證因素造成的更大影響。在上面的示例中，如果用戶的置信水平足夠高，則可以避免其他因素。
無密碼身份驗證（例如 FIDO2）是一種理想的解決方案，因為它提供了強大的安全性和出色的用戶體驗。考慮實施無密碼身份驗證，以在用戶所有服務中獲得強大、一致和積極的用戶體驗。
服務到服務
服務之間的請求也需要進行身份驗證。通常是使用 API 令牌、OAuth 2.0 或公鑰基礎設施 （PKI）等框架來實現(xiàn)的。
使用相互身份驗證，因此用戶可以確信通信的兩個服務都是真實的。這是構建允許列表時的關鍵，以根據身份授權服務之間的連接。
