Add modelling restrictions, a dynamic security layer based on CI data

Add modelling restrictions, a dynamic security layer based on CI data

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’

1 Comment
Micro Focus Expert
Micro Focus Expert
Status changed to: Waiting for Votes

Thank you for sharing your idea! It’s open for comments and kudos, and we’re looking forward to input from the community. Once there is enough community traction, it will be further reviewed by the product team

About the Author
Bill has over 26 years of experience in the IT industry focusing on providing business solutions utilizing HPE Software’s tools at enterprise scale. He comes from the HPE-IT organization where he managed the first deployment of HPSC (now HPSM) and then later UCMDB with its discovery partner UD. Bill also managed a team of IT Developers, who created customized configuration management solutions for HPE-IT and HPE’s ES clients.
Most "Liked" Contributors
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.