我一直是一个完全分离所有环境的证书环境的倡导者。 最近我被要求考虑在我们的产品和非产品Active Directory环境之间build立信任关系的后果，例如一个产品ID可以pipe理DEV和QA环境，但是反过来却不行。
我理解这样做的技术细节，但从最佳实践的angular度来看，我觉得不对。 目前有没有人在生产环境和非生产环境之间有一种信任pipe理的方式？ 你有没有遇到问题或原因不这样做？
- 如果DEV和QA环境信任PROD环境，则业务/最终用户和pipe理员拥有一个用户名和密码来访问所有环境。 +1用户体验。
- 当用户离开组织时，他/她可以在一个环境而不是三个环境中被禁用。 +1用于安全/控制。
- 如果DEV，QA和PROD环境隔离，我假设用户在所有三个环境中都具有相同的一致用户名。 如果他们经常login，他们可能会手动同步他们的密码。 如果他们不经常login（例如，作为应用程序版本的一部分，当他们需要执行应用程序testing时只login到QA环境的业务用户），他们很可能会忘记他们在非PROD环境中的密码，需要密码重置。 这增加了帮助台成本。 -1表示用户体验，-1表示帮助台/支持。
- 如果DEV和QA环境信任PROD环境，并且PROD环境受到威胁，那么DEV和QA环境也是如此。 -2为了安全。
- 但是，请参阅上面的第3点。 能够访问所有三种环境的用户可能会同步他/她的密码，所以如果这个人的密码在一个环境中被破坏，那么另外两个人的密码也可能被破坏。 尤其是在IT中同步他/她的密码的人。 因此，在一个孤立的devise中，您需要查看一些无法parsing的策略级别控制，指出用户在不同的环境中必须拥有不同的密码。
- 任何允许PROD泄密的漏洞（未安装补丁，configuration弱点等）都可能是系统性的，并且即使与PROD隔离，也可能会使DEV和QA受到威胁。
- 扩大第4点，如果PROD环境受到威胁，那么DEV和/或QA是否已经受到威胁是游戏的结果。
在我想要保持三个环境分离的情况下，
- 如果networking层面分离到位，整合这三个环境会导致networking层面分离的失败或破坏。
- 如果基础架构或应用程序体系结构要求将三种环境分开。 例如，如果身份和访问pipe理供应引擎正在使用，我希望能够在DEV和QA中进行彻底和有代表性的testing，然后在PROD中进行相同的更改。 在这种情况下，DEV和QA应该尽可能地接近PROD，如果DEV和QA都信任PROD，他们不会这么做。
基本上，你应该logging需求，架构/操作/用户的优势和劣势，风险，收益等，并能够做出任何方式进行审查的决定。 以更正式的方式来处理这个问题，将有助于你将“从最佳实践angular度来看对我来说感觉不正确”的过去移到一个合理的和有保障的位置。 正如Eugene Spafford所说：“最佳实践”是为那些没有必要的数据或培训来做合理的风险评估的人们设定的默认政策。
祝你好运，采取任何方法。