購買有證據的控制邊界
身分驗證平台可以宣傳角色、審核日誌和租用戶隔離，但這些標籤並不能確定控制項在買方預期工作流程中的行為方式。採購評估應詢問誰可以讀取、匯出、更改和管理哪些客戶的數據，生命週期變化如何影響存取以及哪些證據記錄了這些操作。管理員的成功演示並不是對未經授權的存取的負面測試。
Azure 的多租用戶身分指南 區分認證、授權和商業權利。使用這些區別來建立買家問題，而不是假設登入角色涵蓋所有資源和操作。本文是一個需求框架，而不是聲稱EmailAuth或其他指定平台實現了建議的控制。沒有存取租戶、更改權限或購買產品。
首先定義買家的訪問矩陣
在查看供應商的角色名稱之前，列出預期的使用者和服務角色、租戶關係和資源。包括網域配置、身份驗證報告、原始資料、匯出、整合、使用者管理和相關的商業設定。對於每個組合，請說明是否允許讀取、建立、修改、刪除或匯出。買方的預期邊界是評估產品行為的參考。
不要在沒有證據的情況下假設「只讀」排除匯出或「租用戶管理員」僅限於一名租用戶。共享服務團隊可能合法地需要多個客戶，而單一客戶用戶應該只看到他們批准的範圍。明確記錄這些異常。接受試驗的廣泛角色不應默默地成為生產訪問設計。要求供應商將實際角色對應到買方矩陣並識別不支援的差異。
驗證介面之外的租用戶綁定
一個租客 選擇器 或隱藏的導航項目不足以證明隔離。經過身份驗證的身份必須在伺服器端邊界獲得所請求資源的授權。要求應涵蓋直接讀取、搜尋、匯出、寫入和後台作業，包括對其他租戶擁有的資源的參考。使用具有明顯不同數據的合成裝置，以便可以檢測到意外的跨租戶結果。
Azure 指南警告稱，聯合錯誤配置可能會向非預期租用戶授予存取權限。因此，審查應包括身份如何與租戶關聯、誰可以更改該關聯以及屬於多個租戶的用戶如何選擇範圍。請勿僅從電子郵件後綴推斷所有權或假設客戶提供的租戶識別碼授權其使用。實際供應商必須解釋並展示其支援的型號。
詢問審計日誌實際記錄了什麼
Microsoft Entra 的審核日誌文檔 描述在該身分環境中變化的活動記錄。這是官方審核日誌模型的有用範例，而不是另一個平台記錄相同事件的證據。買家應要求與其自身要求相關的準確產品事件目錄、欄位定義、存取控制、保留行為和匯出選項。
詢問記錄是否足以識別參與者、目標、操作、時間、結果和租戶背景以調查變更。區分使用者活動和服務身分活動以及成功的操作和被拒絕的嘗試。不要假設僅僅因為出現管理變更而記錄每次失敗的授權嘗試。同樣，顯示請求已提交的日誌可能不會顯示結果變更是否已完成。需要包含敏感資料並說明限制的實際範例。
檢查日誌存取和完整性作為控制
審核日誌本身可以包含敏感的客戶和身分資訊。定義誰可以查看它、跨租戶搜尋、匯出它並配置其保留。可以更改設定並刪除唯一證據的管理員提供了與獨立保留記錄不同的問責模型。詢問供應商這些控制措施是如何運作的，但在沒有現有證據的情況下，不要聲稱其不變性或防篡改性。
保留期應由產品的實際支援條款和買方義務指定，而不是發明的通用期限。澄清哪些事件在介面、API 和匯出的檔案中可用，以及這些視圖是否具有相同的覆蓋範圍。檢查時區處理和標識符，以便可以在不依賴可能變更的名稱的情況下關聯記錄。未檢索到該手稿的審計記錄。
測試生命週期變更和服務訪問
角色減少、使用者停用和憑證吊銷是單獨的事件。 RFC 7643 描述 SCIM 活動屬性，同時將其最終意義留給服務提供者。這說明了為什麼買方不能假設設定更新會撤銷所有現有會話或整合憑證。需要對產品會話和非互動式存取行為的最新解釋。
接受計劃應包括在會話存在時其角色被減少的使用者、禁用的身份、有限範圍的整合以及授權的管理員。驗證每種情況下的預期存取結果，包括匯出和直接資源操作。這些是針對授權隔離環境的建議檢查，而不是測試供應商的生產服務或其他客戶的租戶的許可。這裡沒有執行這樣的操作。
買方驗收工作表
建立包含需求、業務原因、供應商聲明、支援的配置、固定裝置識別、租戶、操作、預期結果、實際證據和未解決的限制的工作表。將允許的行為的證據與拒絕的行為的證據分開。包括產品版本、測試日期和環境，以便結果在發布後仍然可以解釋。如果某個功能是計劃的而不是實施的，請記錄該狀態，而不將其視為當前覆蓋範圍。
對於審核日誌，為需要記錄的每個操作新增預期事件和觀察到的記錄參考。正確拒絕存取但未產生預期審計證據的測試與滿足這兩個標準的測試具有不同的結果。記錄誰接受任何限制以及補償性控制是否獲得批准。不要將採購清單分數變成未來安全的保證。
虛構診斷：可以導出的觀眾
虛構的買家看到供應商演示，其中查看者無法編輯網域設定。買方最初將只讀角色標記為滿意。然而，預期的矩陣也禁止批量匯出原始客戶資料。該演示從未測試過匯出、直接資源請求或對其他租戶報告的存取。觀察到的限制僅涵蓋一項操作。
建議的應對措施是要求提供缺失操作的授權固定裝置證據，並審查由此產生的審計記錄。如果產品無法將觀看與出口分開，則買方必須決定該限制是否可以接受，而不是重新命名角色並假設風險消失。這是一個虛構的採購活動，而不是關於EmailAuth或任何指定供應商的調查結果。
保持購買結論的界限
有用的結論可以確定證據滿足的要求、未滿足的要求、所有者接受的限制以及仍然開放的測試。它將配置選擇與固有的產品行為區分開來，並且不保證與有限測試集的完美隔離。可以在不聲明涵蓋每個未來版本或配置的情況下告知決定。
該目錄需要存取矩陣以及針對跨租戶讀取、匯出、寫入和生命週期變更的負面測試。那些最初的測試仍然開放。人類專家審查、來源適用性、生產路線、可訪問性和所有者發布也保持開放。該草案提供的是評估方法，而不是基於已執行證據的購買建議，並且尚未做出任何商業承諾或准入許可。