所以我正在开发我们新的基于角色的站点安全系统的一部分，并且已经达到了“核导弹”的条件。
该系统基于分组的概念，能够根据当前组将用户隐含在组中，如下所示：
汤姆是蛋糕大师
将他放在 Cake Maker 组中，也意味着他在面包师组中，因此他不需要物理上放在该组中。
通过暗示在面包师组中，他可以被放入任何其他烘焙子组。
如果 tom 成为了他的面包店的 CEO，他将被从烘焙组中取出并加入 CEO 组，这意味着他可以访问所有组（烘焙、蛋糕制作等）。
因此，“核导弹”条件是：我是一名网络开发人员，因此我需要访问所有组，以便我可以测试生命周期中可能出现的各种条件和错误。但也可能存在我不应该查看的敏感数据，这可能属于 HR 组或财务组。通过实施核导弹系统，这意味着我可以访问实时页面，人力资源部门或财务部门的人员必须与我的同时提供他们的密码。页面上的 2 个密码字段。
这是一个非常有趣的解决方案，但我不相信完全实用。您通常如何保护流氓系统开发人员免受敏感数据的侵害？您是否对任何敏感内容进行哈希处理，并且仅显示该人是否实际上是属于数据的组的成员。
你甚至在乎吗？
类似的解决方案用于紧急情况，通常称为“破玻璃”解决方案，它通常需要一个单独的管理员级别帐户，将密码分成两半，并将这些密码的文档保存在保险箱中（通常是 IT 人员和高管人员）安全的）
我认为您的用例不属于紧急情况，因为它可能经常发生，因此您发现更常见的是在人员级别实施的控制，包括：
这使工作能够正常进行，而不会受到侵入性安全控制的影响，同时也保护了公司。
当然，上述内容适用于可以访问直播的开发人员。对于运行 BAU 任务的开发人员，首选方法是让他们只拥有经过清理的数据。他们将获取客户帐户数据库，生成替换名称和地址，并在 Dev、UAT、OAT 和 Pre-Prod 环境中使用它们，因此开发人员永远无法访问实时环境。
在过去的 16 年里，我大概可以用一只手来数出这样做的组织的数量，所以回去使用审查和日志记录。抱歉，但这就是它的工作方式。
我最常遇到的解决方案是单层组，因此没有组继承。当一个人属于两个或多个具有冲突权利的群体时，就会出现问题。然后，您可以选择采用一种方式（例如：授予访问权限 > 拒绝访问）或相反的方式。
这是我认为最简单的方法，因为否则您可能会遇到组继承问题（我怀疑您必须提供一个复杂的接口来管理用户组，对吧？）
现在，你的问题让我印象深刻：
但也可能有我不应该查看的敏感数据，这可能属于 HR 组或财务组
无论您的解决方案如何，您都应该处理匿名数据，而不是真实数据。如果您正在处理生产数据库的精确副本，那么第一步是为您或（如果您有幸拥有一个）数据库管理员为您提供数据库的匿名副本。数字可能是随机的，名字也可能是随机的（网上有免费的名字数据库）等等。
这样，您不必担心您在哪个组中，您可能在所有可能的组中，或者在从所有组继承的超级组中，您可以安全地测试您的 Web 应用程序，因为您知道无法了解您的老板有薪水;-)