Best practices for limiting the cmdb_ot_editor role

[MasterBlockWarr]

An OT Editor role introduced by Operational Technology Manager essentially gives users access to all tables stemming from cmdb_ci_*. This is to address the use-cases when there is an IT CI on OT Network or to model OT networking devices (since there is no dedicated OT Netgear in cmdb_ci_ot). On the other hand this causes significant problem for customers during implantations, because OT Teams with editor rights can essentially edit ALL IT CIs in the CMDB.

I'm aware of the "Enhanced RBAC (Role Based Access Control) for OT Configuration Guide for CMDB" documentation that recommends setting up Data Filtration rules. What could be other ways to address this issue? How do you handle the interconnection of OT and IT classes in Purdue L3?

[alexendr2]

<p><strong>Comment 3:</strong> I'd recommend reviewing the <a href="https://docs.servicenow.com/">ServiceNow ACL inheritance behavior</a>. It's easy to underestimate how permissions cascade when using cmdb_ci_* tables. For OT/IT overlap at Purdue Level 3, we use tagging + dynamic group assignments to trigger access rules contextually.</p>

[Mark Manders]

Use Data Filtration (as suggested by ServiceNow itself) or add extra ACLs to the system. With the 'deny unless' ACL you will be able to just limit editing to certain groups (if you are not part of the 'non ot cmdb group', you aren't allowed to edit a table).