在环境之间创建信任

在环境之间创建信任

我一直非常提倡完全分离环境,即分别管理所有环境的凭据。最近有人让我考虑在生产和非生产 Active Directory 环境之间建立信任的后果,这样单个生产 ID 就可以管理 DEV 和 QA 环境,但反过来不行。

我了解这样做的技术细节,但从最佳实践的角度来看,我觉得有些事情不对劲。目前是否有人在生产和非生产环境之间建立单向信任以进行管理?您是否遇到过不这样做的问题或理由?

答案1

  1. 如果 DEV 和 QA 环境信任 PROD 环境,那么业务/最终用户和管理员就拥有一个用户名和密码来访问所有环境。用户体验+1。
  2. 当用户离开组织时,他/她可以在一个环境而不是三个环境中被禁用。安全/控制+1。
  3. 如果 DEV、QA 和 PROD 环境是隔离的,我假设用户在这三个环境中都使用相同的用户名。如果他们频繁登录,他们很可能会手动同步密码。如果他们不经常登录(例如,业务用户仅在需要执行应用程序测试作为应用程序发布的一部分时才登录 QA 环境),他们很可能会忘记非 PROD 环境中的密码,需要重置密码。这会增加帮助台成本。用户体验为 -1,帮助台/支持为 -1。
  4. 如果 DEV 和 QA 环境信任 PROD 环境,并且 PROD 环境受到损害,那么 DEV 和 QA 环境也会受到损害。-2 表示安全。
  5. 但是,请参阅上面的第 3 点。有权访问所有三个环境的用户可能会同步其密码,因此如果此人的密码在一个环境中被泄露,其他两个环境也可能被泄露。尤其是同步其密码的人在 IT 部门工作。因此,在独立设计中,您需要查看无法执行的策略级控制,规定用户必须针对不同的环境使用不同的密码。
  6. 任何导致 PROD 受到损害的漏洞(未安装补丁、配置薄弱等)都可能是系统性的,即使与 PROD 隔离,也会使 DEV 和 QA 受到损害。
  7. 扩展第 4 点,如果 PROD 环境受到损害,那么 DEV 和/或 QA 是否受到损害就都结束了。

我想将三个环境分开的情况如下:

  1. 如果存在网络级别分离,那么整合这三种环境将导致丢失或破坏这种网络级别分离。
  2. 如果基础架构或应用程序架构要求将三个环境分开。例如,如果使用身份和访问管理配置引擎,我希望能够在 DEV 和 QA 中进行全面且有代表性的开发和测试,然后再在 PROD 中进行相同的更改。在这种情况下,DEV 和 QA 应该尽可能接近 PROD,如果 DEV 和 QA 都信任 PROD,则不会这样做。

基本上,您应该记录需求、架构/操作/用户优势和劣势、风险、好处等,并能够做出经得起任何一方审查的决定。以更正式的方式处理这个问题将帮助您摆脱“从最佳实践的角度来看,有些事情对我来说感觉不对劲”的思维,转而采取合理且可辩护的立场。正如 Eugene Spafford 所说:“最佳实践”旨在作为那些没有必要数据或培训来进行合理风险评估的人的默认政策。

无论您采用何种方法,祝您好运。

相关内容