Non-human Account Management - lacking use case for mock users

[jambellops]

Along side Service & Server accounts - to configure infrastructure and operate as the application; there are other users that are provisioned for reasonable development of new features. Mock or test users are provisioned to act like humans but are not derived from any human's attributes. A developer may run tests using the mock user for initial UAT. The mock user may have their access tailored to fit a specific profile, to show a user with a defined set of permission can take only authorized actions. Some applications incorporate this into an impersonate feature, foregoing the need to provision a mock user. Please discuss how the use case of the Mock user fits into the Non-human account management paradigm. Define the best practices for usage, lifecycle, and access control. Note the challenges that arise from trying to fit this use case into a "service account" or a "human user" provisioned lifecycle. If there are any frameworks that account for this use case please cite them.

[GrahamWilliamson]

You bring up a good point. I think the whole DevOps area deserves its own article. INHO traditionally CIOs have ignored DevOps and let developers 'do their own thing' - provided they didn;t mess with Prod they could do what they like in the Dev and Test environments. This was not too bad in on-premise situations but with cloud deployments this got a whole lot more complex in the absence of tight controls on privileged accounts in various environments.
Originally the article was not about interactive accounts but we were asked to comment on system accounts so these were included. I'll include a paragraph on Mock accounts for completeness. Thanks for your comments.

[hlflanagan]

Addressed in v3 of the article. See https://bok.idpro.org/article/id/52/