Home / server / Questions / 251562
Accepted
BoxerBucks
Asked: 2011-03-25 12:24:26 +0800 CST

Creating trusts between environments

  • 772

I have always been a big advocate of complete separation of environments where you manage credentials for all environments separately. Recently I have been asked to think about the ramifications of creating trusts between our prod and non prod Active Directory environments such that a single production ID could manage DEV and QA environments but not the other way around.

I understand the technical details of doing this, but something just doesn't feel right from a best practices perspective for me. Does anyone currently have one way trusts in place for administration purposes between production and non prod environments? Have you encountered issues or reasons not to do this?

security active-directory

1 Answers

  1. Best Answer
    1. If the DEV and QA environments trust the PROD environment then business/end users and admins have a single username and password to access all environments. +1 for user experience.
    2. When a user leaves the organization, s/he can be disabled in one environment rather than three. +1 for security/control.
    3. If DEV, QA and PROD environments are isolated, I assume that users have the same consistent username across all three environments. They are likely to manually synchronize their passwords if they log on frequently. If they log on infrequently (e.g. business users who only log on to the QA environment when they need to perform application testing as part of an application release), they are likely to forget their password in the non-PROD environments, requiring password resets. This increases the helpdesk costs. -1 for user experience, -1 for helpdesk/support.
    4. If the DEV and QA environments trust the PROD environment, and the PROD environment is compromised, then so are the DEV and QA environments. -2 for security.
    5. However, refer to point 3 above. A user with access to all three environments is likely to synchronize his/her passwords, so if this person's password is compromised in one environment the other two are probably compromised as well. Especially is the person synchronizing his/her passwords works in IT. So in an isolated design you'd need to look at unenforcable policy-level controls stating that users must have different passwords for different environments.
    6. Any vulnerabilities (patches not installed, configuration weakenesses, etc.) that allowed PROD to be compromised are likely systemic and would allow DEV and QA to be compromised even if isolated from PROD.
    7. Expanding on point 4, if the PROD environment is compromised, it's game over whether or not DEV and/or QA have been compromised.

    Scenarios off the top of my head where I would want to keep the three environments separated:

    1. If network level separation is in place and integrating the three environments would result in losing or undermining this network level separation.
    2. If infrastructure or application architecture required the three environments to be kept separated. For example, if an Identity & Access Management provisioning engine was in use, I'd want to be able to develop and test thoroughly and representatively in DEV and QA before making the same changes in PROD. In this case, DEV and QA should look as close to PROD as is reasonably possible, which they wouldn't if DEV and QA both trusted PROD.

    Basically, you should document the requirements, architectural / operational / user advantages and disadvantages, risks, benefits, etc. and be able to take a decision that can stand scrutiny either way. Approaching this issue in a more formal manner will help you move past "something just doesn't feel right from a best practices perspective for me" to a justifiable and defensible position. As Eugene Spafford says: “Best practice” is intended as a default policy for those who don’t have the necessary data or training to do a reasonable risk assessment.

    Good luck with whatever approach you adopt.

    • 2