In large organizations, to meet the demands of internal processes, security, and the requirements of regulatory bodies, there is often a need for separation of duties.
In large organizations, to meet the demands of internal processes, security, and the requirements of regulatory bodies, there is often a need for separation of duties.
To support these requirements, access to data, particularly live production data, should always be on a need-to-know basis.
The degree of separation is an internal decision for each organization. That decision can be influenced by many factors, such as resourcing or the complexity of the site. Anaplan is able to support separation of duties, as defined by an organization, using workspaces, model roles, selective access, tenant administration, application lifecycle management (ALM), and import source remapping.
This example shows an implementation of application lifecycle management. The purpose is to explain the concepts behind separation of duties and the factors to consider when designing and building environments to support it. These concepts can easily be ported to other scenarios such as workspaces for different geographic locations or to separate functional areas such as sales and marketing.
Separation of duties in ALM begins at the workspace level. A robust design will separate production and non-production activities by placing them in separate workspaces. It’s then necessary to design data flows between those workspaces that ensure data, particularly live production data, is available in only those workspaces in which it is required.
A basic implementation of application lifecycle management contains three workspaces: Development, Test, and Production.
Data flow design should ensure that no live production data is present in either the Development or Test workspaces. Part of the planning for separation of duties may include processes to sanitize and anonymize live data to be used in the Development and Test workspaces.
When deploying to the live Production workspace, only structural information is copied from the Development workspace to the Production workspace, using model synchronization.
Live data in the Production workspace may be imported from either an Anaplan data hub or from external third-party sources. This table shows the data inputs to each workspace in this example:
Workspace 1 Development | Workspace 2 Test | Workspace 3 Production | |
Inputs | Dummy data (.txt files). | Sanitized test data. | Model to model imports of live data. |
Sanitized test data from Test via Import. | Model synchronization from Development. | Third-party sources to model import. | |
Model synchronization from Development |
Workspace administrators can use Source Models to remap production data import sources. For example, the models in the Test workspace might obtain data from a sanitized data model in the Development workspace.
When a model in the Development workspace is synchronized with a model in the Production workspace, Production workspace administrators will need to remap production data import sources to Production rather than Development sources. To do this, those workspace administrators will require access to both the Development and Production workspaces.
Create meaningful model roles that realistically represent the activities of user groups. Permitting some model roles a greater level of access than others ensures that data is secured on a need-to-know basis.
The model roles in a Development workspace may not need to be the same kinds of model roles that are in a Production workspace. Thinking about the activities different user types will undertake, and designing roles accordingly, will make separation of duties much easier to implement.
Selective Access can also be used to control access to data. Selective Access applies at the list level, using Read and Write permissions. As the default is No Access, lists are not accessible until an administrator specifies which roles should have access.
Access to workspaces, and consequently, models is limited by the model role each user is assigned. Access can be limited at a more granular level by applying selective access to lists. All access rights need to support the processes undertaken in the workspace, for example:
This table illustrates a high level of segregation of duties.
Workspace 1 Development | Workspace 2 Test | Workspace 3 Production | |
Access by model role | Anaplan consultants | Internal IT department | Internal IT department |
Internal IT department | Workspace 2/3 Admin | Workspace 2/3 Admin | |
Workspace 1/2 Admin | Testers (appropriate role) | End Users | |
Model Builder | |||
Selective access applied to | Structural information | Structural information | Structural information |
You can see that:
This diagram shows the user architecture together with the synchronizations and data imports for the workspaces. At no point is production data accessible in the Test or Development workspaces. Model roles ensure the site complies with separation of duties.
In environments where a data hub is deployed, the data flow might look like this:
As you can see, production data is still inaccessible to users on other workspaces.
Disclaimer
We update Anapedia content regularly to provide the most up-to-date instructions.