Hello,
I'm trying to determine clarity/confirmation on what is considered best practice for users while working within Appian. Currently, our devs use a common "admin.service" account (that I refer to as root as it's a System Administrator role) where everyone shares a password, but this makes it hard to pinpoint any accountability which may arise. I was informed this was recommended by Appian for assigning objects as it makes things easier should a developer leave and the object becomes unassigned, yet from a security point of view, it's very concerning. Looking through any documentation on the Appian website, it appears that the best approach would actually be to create a group and then assign an object to that group instead of an individual user. Which is actually considered the best practice for designers? If the group is preferred, what are the recommended guidelines for creating groups so that users can still have permissions set so they don't encounter issues while working in Appian?
Discussion posts and replies are publicly visible
Is your concern specifically for production or are you currently leveraging a single system administrator across each environment? Having additional context on your processes/concerns in lower level environments, for deployments, and for production support may be beneficial to give additional advice.
In general, every dev should have their own account so actions can be audited. In production the best practice is to deploy under a service account to make sure processes are not disturbed by an account being deactivated. I would not recommend using that service account for anything outside of deployments and I would not share those credentials any further than necessary for deployments.
Hello, thank you for your response.
The concern is at the test/production level, each designer does use their own account at the development level. The primary problem that evolved is extremely poor database design as designers/developers who had no knowledge of proper database structure have created environments that are unable to be imported easily into either MariaDB or MySQL8. We're trying to get this governance back under control and in the process only allow certain users the ability to access the database. By historically using the SysAdmin/service role there's no easy way to prevent them from gaining access but we're wanting to make sure that any changes we do make wouldn't cripple their ability to perform duties outside of the database administration and promotion/deployment process.
For further insight, looking at the following page, this is where some confusion arises
https://docs.appian.com/suite/help/20.3/User_Management.html#manage-user-rights-and-security:~:text=Best%20Practice:
According to (at least my reading of) this page, it seems that for best practice you create a group that is used by the service account and assign objects there, potentially eliminating the ownership issue.
I'm also curious if you can change ownership using a script in a deployment process.
Are you using the AppianCloud database? If so, you are unfortunately pretty limited on how you can lock down access to that vs other administrative privileges, as you are probably already aware. Using the Appian DevOps features may help you prevent some of your access issues, but it will probably depend on what database issues you are currently working through. I would still try to limit production access to system administrator accounts and setup governance that prevent changes in the database outside of a structured deployment (i.e. run the change scripts in lower level environments and then promote). That may be more difficult for you in the short term as you are working through your database design issues though.
docs.appian.com/.../Appian_Administration_Console.html
I would suggest trying to breakout deployment, database management, and Appian support as separate streams in your governance model. While there may be some overlap from an account perspective, I think it is important to maintain separate rules of engagement across those streams. For deployments you should use a service account so all objects are deployed by that account. This will prevent Appian objects from running into issues where a named account did the deployment and then becomes deactivated. The link you referenced is an important best practice, but it is in relation to end users changing roles and losing access. That should really be a part of your development best practices as opposed to deployment.
If you currently have objects deployed under developer accounts, or a mistake is made in the future, there is a plugin that can help republish objects under your service account. This is generally used as a cleanup mechanism and shouldn't be needed if appropriate deployment best practices are being followed.
community.appian.com/.../republish-model-as-different-user
Thank you very much for your response. We will need to consider these comments as we map out our governance model.