购买有证据的控制边界
身份验证平台可以宣传角色、审核日志和租户隔离，但这些标签并不能确定控件在买方预期工作流程中的行为方式。采购评估应询问谁可以读取、导出、更改和管理哪些客户的数据，生命周期变化如何影响访问以及哪些证据记录了这些操作。管理员的成功演示并不是对未经授权的访问的负面测试。
Azure 的多租户身份指南 区分认证、授权和商业权利。使用这些区别来构建买家问题，而不是假设登录角色涵盖所有资源和操作。本文是一个需求框架，而不是声称EmailAuth或其他指定平台实现了建议的控件。没有访问租户、更改权限或购买产品。
首先定义买家的访问矩阵
在查看供应商的角色名称之前，列出预期的用户和服务角色、租户关系和资源。包括域配置、身份验证报告、原始数据、导出、集成、用户管理和相关的商业设置。对于每个组合，请说明是否允许读取、创建、修改、删除或导出。买方的预期边界是评估产品行为的参考。
不要在没有证据的情况下假设“只读”排除导出或“租户管理员”仅限于一名租户。共享服务团队可能合法地需要多个客户，而单个客户用户应该只看到他们批准的范围。明确记录这些异常。接受试验的广泛角色不应默默地成为生产访问设计。要求供应商将实际角色映射到买方矩阵并识别不支持的区别。
验证接口之外的租户绑定
一个租客 选择器 或者隐藏的导航项不足以证明隔离。经过身份验证的身份必须在服务器端边界获得所请求资源的授权。要求应涵盖直接读取、搜索、导出、写入和后台作业，包括对其他租户拥有的资源的引用。使用具有明显不同数据的合成装置，以便可以检测到意外的跨租户结果。
Azure 指南警告称，联合错误配置可能会向非预期租户授予访问权限。因此，审查应包括身份如何与租户关联、谁可以更改该关联以及属于多个租户的用户如何选择范围。请勿仅从电子邮件后缀推断所有权或假设客户提供的租户标识符授权其使用。实际供应商必须解释并展示其支持的型号。
询问审计日志实际记录了什么
Microsoft Entra 的审核日志文档 描述该身份环境中变化的活动记录。这是官方审核日志模型的有用示例，而不是另一个平台记录相同事件的证据。买家应请求与其自身要求相关的准确产品事件目录、字段定义、访问控制、保留行为和导出选项。
询问记录是否足以识别参与者、目标、操作、时间、结果和租户背景以调查变更。区分用户活动和服务身份活动以及成功的操作和被拒绝的尝试。不要假设仅仅因为出现管理更改而记录每次失败的授权尝试。同样，显示请求已提交的日志可能不会显示结果更改是否已完成。需要包含敏感数据并说明限制的实际示例。
检查日志访问和完整性作为控制
审核日志本身可以包含敏感的客户和身份信息。定义谁可以查看它、跨租户搜索、导出它并配置其保留。可以更改设置并删除唯一证据的管理员提供了与独立保留记录不同的问责模型。询问供应商这些控制措施是如何工作的，但在没有现有证据的情况下，不要声称其不变性或防篡改性。
保留期应由产品的实际支持条款和买方义务指定，而不是发明的通用期限。澄清哪些事件在界面、API 和导出的存档中可用，以及这些视图是否具有相同的覆盖范围。检查时区处理和标识符，以便可以在不依赖可能更改的名称的情况下关联记录。未检索到该手稿的审计记录。
测试生命周期变更和服务访问
角色减少、用户禁用和凭证吊销是单独的事件。 RFC 7643 描述 SCIM 活动属性，同时将其最终含义留给服务提供商。这说明了为什么买方不能假设配置更新会撤销所有现有会话或集成凭据。需要对产品会话和非交互式访问行为的最新解释。
接受计划应包括在会话存在时其角色被减少的用户、禁用的身份、有限范围的集成以及授权的管理员。验证每种情况下的预期访问结果，包括导出和直接资源操作。这些是针对授权隔离环境的建议检查，而不是测试供应商的生产服务或其他客户的租户的许可。这里没有执行这样的操作。
买方验收工作表
创建包含需求、业务原因、供应商声明、支持的配置、固定装置标识、租户、操作、预期结果、实际证据和未解决的限制的工作表。将允许的行为的证据与拒绝的行为的证据分开。包括产品版本、测试日期和环境，以便结果在发布后仍然可以解释。如果某个功能是计划的而不是实施的，请记录该状态，而不将其视为当前覆盖范围。
对于审核日志，为需要记录的每个操作添加预期事件和观察到的记录引用。正确拒绝访问但未产生预期审计证据的测试与满足这两个标准的测试具有不同的结果。记录谁接受任何限制以及补偿性控制是否获得批准。不要将采购清单分数变成未来安全的保证。
虚构诊断：可以导出的观众
虚构的买家看到供应商演示，其中查看者无法编辑域设置。买方最初将只读角色标记为满意。然而，预期的矩阵也禁止批量导出原始客户数据。该演示从未测试过导出、直接资源请求或对其他租户报告的访问。观察到的限制仅涵盖一项操作。
建议的应对措施是要求提供缺失操作的授权固定装置证据，并审查由此产生的审计记录。如果产品无法将观看与出口分开，则买方必须决定该限制是否可以接受，而不是重新命名角色并假设风险消失。这是一个虚构的采购活动，而不是关于EmailAuth或任何指定供应商的调查结果。
保持购买结论的界限
有用的结论可以确定证据满足的要求、未满足的要求、所有者接受的限制以及仍然开放的测试。它将配置选择与固有的产品行为区分开来，并且不保证与有限测试集的完美隔离。可以在不声明涵盖每个未来版本或配置的情况下告知决定。
该目录需要访问矩阵以及针对跨租户读取、导出、写入和生命周期更改的负面测试。那些最初的测试仍然开放。人类专家审查、来源适用性、生产路线、可访问性和所有者发布也保持开放。该草案提供的是评估方法，而不是基于已执行证据的购买建议，并且尚未做出任何商业承诺或准入许可。