Skip navigation

Secure (hide) CIs in a single company using configurable security classifications

score 155
You have not voted. Product Team Review

This idea is based on a requirement to secure (restrict read access) to CI instances (across specific or all CI Types) in the CMDB, based on a “security” classification.

 

What makes this idea unique is the requirement to secure (hide) specific CIs at row or record level by ensuring that they are not visible by default to the all support users of the same company.

 

And importantly, without needing to setup “multi-tenant” mode or redesign support org’s and structures in the foundation data.

 

            Primary use case: Secure selected CI Instances using a security classification (driven by a new (custom) attribute in the CDM).

For example, ‘Security Classification’ = “LEVEL 3” will secure any CIs at record level (where this value is set) so it is no longer visible at row level to all support users belonging to the same company. It is only visible to specific groups or users (in the same company).
These users or groups will either be part of security teams (support groups in ITSM) or be allocated to a security application permission group (which can be configured).

 

OOTB how RLS On CI is determined – The 1st level of RLS (row level security) is determined by matching CI Company to user’s company access restriction(s), that is determined on the CI via field id 112 dynamically Furthermore, in multi-tenant platform configurations RLS access can be extended between companies if you have Asset Mgmt. by using People/Group (People tab) i.e. AST:AssetPeople relationships to selected Support Groups / Users.

 

However, as we do not want to separate our support organizations structures across multiple companies, and likewise CMDB CIs must remain under a single company this means we will not be using “multi-tenancy” mode.

 

A solution is required which should enable us to enhance the OOTB features to support what we call “inversed” RLS (as described above). In a nutshell, we want to only give access to select groups, or individuals within a single company.

 

 

See the HL design/flow diagram below. It illustrates how RLS is updated/secured based on this ‘Security Classification’ attribute.

 

** Will need to ensure OOTB workflows work when needed as mentioned above if no mapping exists.

 

^ The CMDB user in this flow has access based on their Asset permissions. Their RLS is determined 1st by their company access restrictions &/or People Org role that allows him/her to view or modify the CI. The UI will need to be enhanced (e.g. need a pop-up warning to confirm changes) if/when the Secure Classification field is updated.

 

 

This design idea consists of the following UI features & capabilities summarized below.

 

  • New ‘Security Classification’ attribute in the CDM which could be generic (like PRIORITY CDM attribute) e.g. LEVEL 1; LEVEL 2; LEVEL3 etc. This can be enumerated attribute in the CDM, or data driven (with a menu attached) & metadata retrieved up from SYS:MenuItems.
  • New AR Computed Groups for each Company / Security Class /Level.  E.g. Calbro_Secure_LEVEL1, Calbro_Secure_LEVEL2, Calbro_Secure_LEVEL3 etc.
  • New GUI or configuration form which allows “user friendly” way mapping of groups / users per company for each security classification above (no mockup over designs is attached but UI can be designed in a number of ways). E.g. One place the UI can be incorporated is into COM:Company or a separate “administrative” UI feature.

 

This GUI will ultimately add/update the AR Computed Group data, see mock up below.

 

 

  • For each CI which has the Security Class field/value populated there will be workflow to perform a lookup into the metadata form, and set the appropriate RLS in CMDBRowLevelSecurity (field 112)
  • If the Security Class field is NULL or there is no matching configuration data for the value then the Company field on a CI will still be set as normal (either by default or as is mapped via integrations), and OOTB workflow will set the CMDBRowLevelSecurity (field 112) as normal.

 

Below is a mockup of a CI, which is with Calbro Services company and where the CMDBRowLevelSecurity is “inversed”. So only the security classification mapped (and the groups defined within) have row level access. In this example Goup ID 1234 (Calbro Security Class 3)

 

 

 

Comments

Vote history