Tenants in MTG Products

If several tenants are used within the same company no additional licenses are required. However, if several tenants are used for multiple companies (e.g., Bitmarck and health insurance companies), an additional license is required for each tenant and is linked to a fixed sum. In this case, usage means creating a certificate or administering a key used in another company.

Tenants in MTG CARA

All CAs of the MTG PKI platform are managed in MTG CARA. HSMs are also connected to MTG CARA. MTG CARA supports the “Virtual CA (VCA)” concept. A VCA is a tenant in MTG CARA with the following properties:

  • Roles and rights for MTG CARA interfaces and APIs can be defined for each VCA. Users without appropriate rights can not see other VCAs.

  • All root and sub CAs created in MTG CARA can be activated/set up for one or more VCAs. Without this step, it is not possible to use a Root or Sub CA for the creation of certificates. This activation allows you to specifically control which VCAs can access specific root and sub CAs.

  • Most HSMs have their own tenant system. The PKCS#11 slots of the Entrust HSMs are an example of this. The private key of each root/sub CA in MTG CARA can be stored in a separate HSM tenant (slot). This means that tenant separation can also be implemented for the CA keys with HSM support.

  • The entire administration of the VCAs, the CAs (root/sub) and the HSM configurations is carried out via the MTG CARA GUI by MTG CARA administrators. In most cases, MTG CARA admins have all rights. VCA-specific management/administration is possible to a very limited extent.

Tenants in MTG CLM

MTG CLM is a software component that uses one or more connected certificate providers to issue, revoke and manage end entity certificates via the GUI and APIs. MTG CARA can be configured as a certificate provider for a MTG CLM instance. This connection is made via an MTG CARA VCA. MTG CLM gets full access to exactly one MTG CARA VCA and may use the CAs that are released specifically for this VCA. In theory, it is possible to set up several MTG CARA certificate providers on the same MTG CLM instance and thus make several VCAs usable, but this is relevant only in cases where several MTG CARA instances are to be used by the same MTG CLM instance.

Management of certificate providers within the MTG CLM GUI is only possible when possessing the MTG CLM Admin role. All MTG CLM admins can manage all certificate providers. In MTG CLM there is also the concept of realms. A realm is a business unit that can be used for different types of administrative separation. Managed certificates are always assigned to exactly one realm and are only visible within this realm. Users can be assigned rights to one or more realms and thus manage certificates in one or more realms. All certificate providers configured by admins can be used in all realms. A user who has all rights within a realm is able to use all CAs that are made available by the existing certificate providers. This requires the creation of a policy within the realm and the corresponding certificate provider and CA to be configured in this policy. It is possible to assign only limited rights within a realm. For example, a user can be allowed to only use existing policies, but not create new ones. This means that only specific CAs can be used for specific users. There are two common scenarios for tenant separation with MTG CLM and MTG CARA:

Option 1

There is one MTG CARA instance and n MTG CLM instances. The tenants are mapped as VCAs and MTG CLM instances. A VCA is created for each tenant in MTG CARA with corresponding root and sub CAs. Each VCA is configured with exactly one MTG CLM instance and each tenant receives its own MTG CLM instance with full admin rights to this MTG CLM instance. The tenant is not granted access in MTG CARA. A global MTG CARA administrator manages all CAs for all tenants.

Option 2

There is one MTG CARA instance and one MTG CLM instance. The tenants are mapped as realms. A single VCA is set up in MTG CARA and all root/sub CAs that are used by all tenants are activated for this VCA. In MTG CLM, the global admin creates n realms and policies are created for each realm, each with the appropriate tenant-specific (sub) CA. Tenants only have limited access within their realm, in which they cannot create policies themselves. They may only use the existing policies for certificate creation and therefore only use their CAs. In this case, all tenant users log in to the same interface. This makes it is easier to unlock false access due to an incorrect rights configuration.

Tenants in MTG KMS

MTG KMS is a software component that securely stores key material and can be used for cryptographic operations. In MTG KMS, HSM configurations are made globally by MTG KMS admins. Several HSM tenants (slots) can be set up. In MTG KMS there is the concept of Tenants (Mandanten). A tenant is a completely separate entity that has its own users. KEKs (Key Encryption Keys) are generated within a tenant, with which all other keys within the tenant are encrypted and stored in the database. KEKs belong exclusively to exactly one tenant. A tenant may use one or more HSM tenants to generate its KEK in the HSM and use it more closely.

MTG KMS has 3 GUI areas:

  • The system admin area, where MTG KMS admin users configure HSMs and create new tenants.

  • The tenant admin area, in which tenant admin users make tenant-specific configurations, e.g. creation of KEKs.

  • The crypto area, in which tenant users can view and manage the keys within their tenant.