Add default 'Security Admin' and 'Data Admin' roles to support formal segregation of duties

Ernie_Goff

Many enterprise customers have security policies require different administrative roles to support segregation of duties. Today, when we encounter these, we need to build them from scratch and manage them at the model level.

 

I propose that in addition to 'Workspace Administrator'', we also have  'Security Admin' and 'Data Admin' designations.

 

Security Admin would have admin access to 'Users' in order to support user maintenance and the assignment of users to model roles. If an additional capacity of tagging models as 'security models' could be created then this role would also have the ability to view any security logic deployed.

 

Data Admin would have the combined ability to execute Processes and Actions and to view all data in a workspace. They would not have access to security components nor would they be able to change models or Actions.

 

 

Miran

Status changed to: In Review

Ethan_Rold1

Have you checked into whether your clients have tenant administration enabled for the security portion of your question? The following link may help with that requirement since it does standardize and control security across apps in the workspace from a centralized admin view. https://help.anaplan.com/anapedia/Content/Administration_and_Security/Tenant_Administration.html

 

For the data admin component, I have seen where a "blank" IT or master admin owned user is established in the workspace, with its own role created and restricted from having workspace administrator privileges. This causes you to keep the data admin functions consistent by user but performed at the individual model level. Each model within the workspace will have its own requirements in terms of data and process and since your master data in the model should be dependent on your data hub, the "user"'s only role is to execute those prescribed actions. This will keep the data hub process separate, and assigned to its manager user, and allow a single "user" to import standardized data out of the hub into your spoke models as they require invididually.

 

Please let me know if you think either of these might be helpful in getting your enterprise customers answers. I would be interested in your feedback as to whether or not these recommendations might help with those needs.

 

 

Ernie_Goff

Hi Ethan -

Thanks for the feedback! This request is more about providing Anaplan with a capacity to support formal separation of duties in a standardized way out of the box than about methods for creating similar roles.

Today, I agree that we do solve for both of the incremental roles in numerous ways, but that can leave customers unclear how to maintain those designs going forward. One is also dependent on a given SA's skill at designing these roles within a given project so the design can vary. While the Tenant Admin role does offer some related capabilities, it does not offer the same defined separation of role that is often needed. So when it comes to defined separation of duties on Anaplan your results can vary. 

The idea here is to provide a standard feature set that:

1. satisfies common separation requests
2. can be understood by anyone who understands the separation requirements and who has Launchpad under their belt
3. can be quickly deployed & maintained

This enhancement would help to keep Anaplan systems compliant with customer's audit & controls policies.

Here's a quick link for IT policy context: https://www.isaca.org/Journal/archives/2012/Volume-6/Pages/What-Every-IT-Auditor-Should-Know-About-Proper-Segregation-of-Incompatible-IT-Activities.aspx 

There are also many articles on separation/segregation of duties in a Sarbanes-Oxley internal controls compliance context out there too.

Does my reply give you more context on the nature of this enhancement idea?

Best,

Ernie

Ethan_Rold1

Understood and agreed - I phrased my reponse poorly as an answer (got a little carried away) rather than a contribution but thank you for responding in the way that you did! 

 

I agree completely with your idea on the simplification of the roles - as mentioned it is difficult to manage and can lead to vastly different results through the process that I described (as you well know).

 

I do have a couple of additional thoughts that correlate to my last post that your article brings up in context to my thought process from the last. I suppose I bring up tenant admin because it seems as if that would be better incorporated there and made available to all subscribing orgs - not just enterprise - if Anaplan was to make that enhancement? I see similar issues if the structure you are proposing isn't centralized since you would have to designate those roles by the user at the model/workspace level - especially where there are multiple workspaces present. In that way you could have your IT administrator, DBA, and modelers segregated within those centralized functions - as you suggest - and keep it out of the model user settings altogether. 

 

While there are needs for continuing to maintain data process integrity at the model level (per my post), I do agree that the process is very involved and shouldn't necessarily be owned by the folks participating in Launchpad already. Since that level of access and admin is inherently a different skill and not one that I would add to your enhancement request that this become an IT function that can be trained independently of Launchpad. I don't know about the projects that you have lead but generally these responsibilities are outside the scope of the launchpad model builders that I incorporate into customer projects and I would want that put in the hands of the IT function and those auditors more easily than it is done now. 

 

Ernie_Goff

Hi Ethan -

I think that we're on the same page!

It's likely that a CoE will encompass some degree of formal segregation of duties. My reference to Launchpad here refers to the skill level of a given user in a CoE role and not a business user per se. It has been my observation that CoEs can pull from both IT and Business user groups depending on how segregation of duties policies influence an Anaplan deployment. The idea is that this enhancement be usable by someone with Launchpad training within their defined Anaplan role.

Best,

Ernie

AndrewClark

Hi Ernie, this is something (or something similar) that our company has been crying out for for a while! We supposedly have segregation of duties, but our 'Access Admin' person in theory has the ability to do anything to a model in Production.

Also, with an increasing number of Model Builder/Workspace Admin users in our company, there is the risk that they can change individual settings (or their own) such as turing off their SSO functionality or changing their role to see data which they shouldn't have access to. If the 'User Admin' role was separated out to a different person, then this risk would be stopped, rather than relying on us to set up processes internally to manually review user access changes etc.

 

Thanks, Andrew.

Gwen.pryor

Status changed to: In Review

VickiA

Status changed to: In Review