Idea ID 1794044
With a large organization there are often a large number of service owners who should be able to model their own services but shouldn’t be able to manipulate models for services they are not responsible for.
Access to modelling services is to be restricted to the UCMDB Browser by way of using widgets to impose a particular method of modelling upon the numerous service owners however there is no control over the security of what services can be modelled by the user if they have write access.
While general write access may be OK for small organizations with few services, with an enterprise system the services themselves should be able to be restricted from a modelling perspective using the data as a key, or allowing restricted modelling to be CI specific (within reason).
Creating restricted views in the UCMDB for assisted modelling doesn’t seem to pass through the restrictions to the browser, so for example limiting a model to only particular business service CI’s is ignored and any business service CI can be used for modelling.
A better approach would be that one or more user CIs are linked to the services which means they are responsible for the services and the modelling of them. A generic widget and mapping could be used then which would only work if the user logged in was the same user as the one responsible (e.g. user logged in name matches employee number in a Person CI linked to a business service).
Owner of service A with the current setup could go into service B (accidently or otherwise) via assisted modelling and remove/add CIs breaking an existing model. While auditing will pick up the changes and who made them, the ability to prevent this from happening in the first place is better as the model has to be rebuilt.
Only allowing a small number of people to do modelling but with thousands of services and a high number of CIs this is a large burden for a small team.
With this customer there are over 7000 services and over 1000 service owners meaning that there is a huge administrative overhead to try to limit using groups or other methods that are non-dynamic.
The ability to be able to restrict service model editing based on data and not just groups/roles to enable a more flexible and dynamic approach to some situations such as modelling.
Reference: QCCR1H106866 – ‘Add modelling restrictions, a dynamic security layer based on CI data’
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.