CMDB Edit Access

[Bhaskar Palle1]

Hi Team,

I am trying to identify the users who all are having edit access to CMDB tables and wanted to restrict their access to read only. What are the roles i need to consider to find the users list and limit their access to read only for CMDB in Service Now.

Thanks 

Bhaskar

[CMDB Whisperer · Accepted solution]

Are you really looking to remove CMDB access from all users?  Why are you looking to do this?  How are CIs going to get updated if you remove all users' access?  In any case, it's likely going to involve more than just removing roles from users, but removing roles from other roles, and indeed likely modifying the ACLs associated with various roles, i.e. redoing the security model itself.  So this will be a major effort that you will need to test thoroughly from multiple scenarios and perspectives before committing to.  The reason is that CMDB access is spread across multiple CI classes and attributes, assigned to a variety of different roles, and those roles are inherited by other roles.  For example, itil role allows CI updates but is also required for most fulfillment activity in the platform.  So removing that role from users is not feasible.  And there are other roles that have access to specific CI classes like Business Applications and Services.  Answering the question definitively would involve looking at the roles themselves and what other roles they inherit, and what ACLs they use.  There are ways to enumerate what users have a specific type of access on a given table, but they are a bit complex.  So I think the first question to answer here is what are you looking to accomplish and why?  There are likely other approaches that make more sense than redoing the entire security model.

[CMDB Whisperer · Accepted solution]

The question is which users, which CIs, and which attributes?  While some users may be causing inaccuracies, users are also responsible for ensuring accurate data.  

There are two kinds of data on CIs: business data and technical data.  Technical data is discoverable and it makes more sense to limit users' ability to overwrite this data -- as long as the data is actually discovered, which may not be consistently reliable.  Business data (ownership, assignment, criticality, etc.) can only be provided by users.  So if your goal is to get the most accurate business data, then you either need to allow direct editing of the CI or provide controlled processes such as through the service catalog which would result in updates to the data.  Simply making a blanket assumption that cutting off all users' access to modify CIs isn't going to result in greater accuracy.  It will result in making your CMDB irrelevant. 

What you should consider focusing on instead are:

• What data do I care most about collecting?
• What data can I ignore for now and not collect it at all?  Inconsistently collected data and unreliable data is worse than no data at all!
• If there is technical data on a CI, how reliably is it discovered?  If it is reliably discovered, it may be worth limiting users' direct access to modify the data.  You can do this using UI policies without having to worry about roles, ACLs, etc.  Just make the field read-only on the form and this will prevent users from editing the data on the form.  No modification to roles or ACLs needed.  However, if it is not reliably discovered, then you should probably leave it open.
• What are the real causes and reasons for the inaccuracies?  Is there anything you can do to educate users?
• Are you using CMDB Health and do you have it configured optimally so that you are measuring the Completeness, Correctness, and Compliance of the CMDB data for the CI classes, attributes, and relationships you care about the most?
• Have you thought about using Data Certification to periodically certify the accuracy of data in critical CIs and attributes?
• Is the problem with accuracy that users who have no authority over a CI are making modifications and you want only users with authority or data ownership to edit the CI?  If so, there is the possibility of tying access to the appropriate users (i.e. Managed by Group, Support Group, Change Group, etc.) so that only users with a direct stake in the specific CI can edit the data.  However, this is still a significant undertaking which requires that you define and assign the stakeholder roles to all CIs, and that you redesign the security model and test it thoroughly.  So, while this may be worth doing, you should be aware of the associated effort and risk.