Access control to data with multitenancy

BMC Helix CMDB offers a flexible permissions model that lets you grant role-based permission to areas of BMC Helix CMDB functionality and grant row-level read and write permission to instance data.

This row-level security enables BMC Helix CMDB to support multitenancy. Multitenancy means that one CMDB holds data about multiple parties' IT environments, usually in the case of an IT service provider, and each party can access only their own data. Each party whose data is represented in the CMDB is considered an account.

Overview of multitenancy in BMC Helix CMDB

Multitenancy has long been a feature in the BMC Helix ITSM (BMC Helix ITSM) that enables you to control which records and configuration data are exposed to a user, based on the user's membership in a company, business unit, or other group.

Although multitenancy is primarily used by consuming applications such as BMC Helix ITSM and Service Impact Manager, BMC Helix CMDB provides the mechanisms for a multitenancy permission model. BMC Helix CMDB also defines a base implementation for a multitenancy permission model. You can extend this base implementation or develop a new implementation that is consistent with the base implementation. The Product Catalog component also leverages multitenancy. If you have not installed BMC Helix ITSM, you can set up multitenancy by using the Product Catalog and the AccountID default instance permissions in BMC Helix CMDB. If you do this, make sure that the AccountID values match the company values in the Company form. AccountID is used to control BMC Helix CMDB multitenancy, while the company field is used to control multitenancy in the Product Catalog and BMC Helix ITSM applications.

You can use multitenancy to control access in a hosted environment. For example, in a service provider environment, a single BMC Helix CMDB application might be used by multiple companies, with the data for each company hidden from the other companies using the application. You can also use multitenancy to control access in a single company, with the data for each business unit hidden from other business units.

Multitenancy is used to segregate data and restrict access by the Company field, in BMC Helix ITSM, or the Company form in Action Request System. Access restrictions can be created so that a user with access to only one company cannot see data for another company. To segregate data by business unit, you must record each business unit as a separate company. In this scenario, a user with access to only one business unit cannot see incidents for another business unit.

BMC Helix CMDB multitenancy permission model

The DefaultAccountPermissions class enables you to define default permissions based on AccountID. From the account ID, you can assign default permissions when you create configuration items (CIs). Default instance permissions enable you to specify CMDBRowLevelSecurity and CMDBWriteSecurity values for an entire class instead of specifying them every time you create an instance of the class. You can give these permissions to a different group for each account ID, which supports multitenancy by enabling you to grant users access to only the instances for their account. For more information about default instance permissions, as well as roles and other permissions, see Providing-users-with-permissions-to-access-the-CMDB-Portal-by-using-groups-and-roles.

The Product Catalog supports defining approved products for different organizations. Multitenancy enables you to have a single Product Catalog shared among multiple organizations and track the approved products for each organization.

You can define the approved items for the version and patch levels, not just the product name. All the other options in the Product Catalog are separated for each products by organization as well. For more information, see Product-Catalog-and-multitenancy.

Calbro Services' access implementation

Calbro Services has several different business units. Although each business unit is part of the overall company, the various business units need access to different applications and data. For example, all employees of Calbro Services can install Microsoft Word, but only certain members of Finance should install and work with the payroll application. HR has a similar restriction on the job posting and recruitment application used by that business unit. Members of IT should have access to all applications.

Calbro Services must set up product access and restrictions in the Product Catalog for Finance and HR. IT will have access to all possible products. The following figure illustrates the access in this scenario, in which some people have access to Finance products, some people have access to HR products, and others have unrestricted access to all products.

 Access to applications in business units

This scenario includes the following groups:

• Finance — People in this group can access products used only by Finance.
• HR — People in this group can access products used only by HR.
• IT — People in this group can access all products, including those used by HR and Finance.

Allen Allbrook, the Calbro Services administrator, creates Operating Company entries for Finance, HR, and IT in the Product Catalog. This automatically creates Action Request System (AR System) regular groups for these Operating Companies.

Next, Allen assigns individual employees to these AR System groups. For example, Allen adds Patrick Paycheck to the Finance group, Betty Benefits to the HR group, and himself to the IT group.

Allen can then configure the Product Catalog entries for application access according to the Operating Company. Allen allows the Global company (everyone at Calbro Services) access to Microsoft Word, the Finance company access to the payroll application, the HR company access to the job posting and recruitment application, and the IT company access to all applications.

Product Catalog entries do not restrict employee access to applications, but Allen can run discovery reports about the applications installed on employee computers, and then uninstall applications that are not approved for use according to the Product Catalog.

Additionally, people in Finance need to see employee information stored in the BMC_Person form, while people in HR need access to change information on that form. To accomplish this, Allen establishes instance permissions to data on the BMC_Person form. He first makes sure that the Finance and HR groups have access to the CMDB Data View role. Next, Allen adds the Finance and HR groups to the CMDBRowLevelSecurity attribute value for BMC_Person entries those employees should see. Allen then adds the HR group to the CMDBWriteSecurity attribute value for entries that HR employees should have access to modify.

For more information about how permissions and multitenancy are related to products used by a company, see Product-Catalog-and-multitenancy. For information about setting permissions, see Providing-users-with-permissions-to-access-the-CMDB-Portal-by-using-groups-and-roles.