Domain Management

A domain is a logical division that isolates users and cryptographic keys. Resources like keys are isolated to a single domain and cannot be accessed across domains.

CipherTrust Manager's domains form its multitenancy model. Multitenancy enables the creation of multiple restricted or local domains within a single CipherTrust Manager appliance. Enterprises can use multitenancy to segregate key access (or other resource access) to better control usage of product by line of business or use case.

Every CipherTrust Manager appliance has a root domain by default. Additional child domains can be created, and child domains can have their own children domains. We have validated 100 domains for Virtual CipherTrust Manager k170v, and 1000 domains for every other model. A domain administrator role controls the creation, deletion, and user assignment of domains.

Not all resources are segregated. Certain settings and configurations are only configurable in the root domain. This includes:

• System settings such as syslog servers and ntp servers

• Authentication settings such as LDAP servers.

CipherTrust Manager allows you to partition a single instance into multiple domains, and allows separate administrators with separation of duties to manage encryption keys, security controls, and auditing in each domain.

Domain Planning

As part of configuring CipherTrust Manager, the domain administrator should think about the requirements for the domains to be included within the configuration. Among the requirements to be considered are the following:

• Administration

  • Number and type of administrators required. Administrators can assign user groups to the domain and manage child domains. If administrators have the correct permissions, they can also perform operations on domain resources directly.

  • Number of users requiring access to the domain's resources.

• Administrative operations/practices

  • Backup and Key Rotation Schedule

  • Access to and storage of logs on an external syslog server for auditing purposes

User Management

When a domain is created, one or more initial administrators must be defined. When administrators subsequently log into the domain, they can use assign additional users to the domain and also use groups to assign user permissions.

The defined Admins should, at minimum, have group permissions to create domains, users, and groups. You can assign the admins to the 'Domain Admins' and 'User Admins' system-defined groups to have the correct permissions.

Creating Domains

A new domain is automatically a child domain of the logged-in domain at the time of creation. So, if you are logged into the root domain, and create a new domain, the new domain is a child of root.

By default, a parent domain and its descendants are part of the same certificate chain. You can create domains in a parent-child hierarchy down to ten levels before having to manually replace their associated certificates for client certificate authentication.

To create a domain

1. Log into the CipherTrust Manager Management Console as an Admin with domain creation permissions.

2. Navigate to the domain by clicking Admin Settings and selecting Domains.

3. Select Add Domain.

4. Enter the following information in the Add Domain dialog:

   • Name: Name of the domain

   • Admins: Define the initial set of Admins who can log into the domain, assign users to groups to the domain, and create child domains. These Admins should have the correct permissions.

   The following information is optional:

   • Parent CA: Each domain has a default Certificate Authority (CA) automatically created. This field defines the parent CA which signs the Default CA for the new domain. If no parent CA is provided, the oldest CA in the root domain is used.

   • Meta: Additional reference information regarding the domain. Must be JSON formatted. This can be used to attach information – such as the department or contact details – to the domain. It can then be queried and viewed later. This field is not used internally by CipherTrust Manager.

Domain Authentication

Once the domain(s) have been created, the specified Administrator can log in to the domain. Users that are assigned to the domain can also login to the domain to perform key operations.

GUI

In the GUI, in the upper right hand corner, click on the Root/Admin link and Select Switch Domains. Once the domain has been selected, the Admin is taken to the specified domain. From this point forward, all key management and admin activity is constrained to the selected domain.

CLI

In the CLI, you operate in the root domain by default. There are two ways to perform actions inside a child domain:

• Log into the domain with the ksctl login --user <user_with_domain_permission> [--password <user_password>] --domain <domain_name_or_id> command. If you don't specify the password, you are prompted for it. All subsequent commands in the session are within the domain.

• Use the --domain <domain_name_or_id> option with --user <user_with_domain_permission> for the particular key management or administrative command you wish to perform. You can specify the password with --password or enter it when prompted

REST API

In the REST API, the POST command to authenticate goes to the root domain by default. You can include a child domain name in the schema with domain, as well as the domain administrator username and password. After this initial authentication, subsequent API requests apply to the authenticated domain.

You can also use the GET /v1/auth/self/domains/ endpoint to return a list of domains that the current user is assigned to.

Domain Scoped Backups

You can scope a backup to a single domain.

Work in Progress

The following functionalities are planned for inclusion in future CipherTrust Manager releases.

Service Provider Functionality: Service Providers may wish to have additional configuration in each domain – authentication servers, for example.

Licensing: Currently, licenses applied to the root domain are available to all child domains on the appliance. Work is underway to better track license consumption on a per domain basis. Therefore, we recommend customers allocate licenses as is expected to be enforced.

Logging: Currently, server and client logging are aggregated at the macro level. Activity from individual domains is tagged, but not separately stored in a domain unique log.
To be added:
The ability for system administrators to disallow per domain syslog configuration if they wish to consolidate information into other systems for support and usage tracking purposes.

Managing Syslog Messages Redirection to Parent Domain using ksctl

Syslog messages redirection allows you to send the syslog messages of the current domain to the syslog server configured in its parent domain.
If the current domain is receiving the syslog messages from its child domain, those syslog messages will also be sent to the syslog server configured in the parent domain of the current domain.

It allows you to perform the following operations:

• Enabling/Disabling syslog messages redirection

• Status of the syslog messages redirection

Enabling/Disabling Syslog Messages Redirection

To enable syslog messages redirection to the parent of the current domain, run:

ksctl domains syslog-redirection enable

To disable syslog messages redirection to the parent of the current domain, run:

ksctl domains syslog-redirection disable

Getting Status of Syslog Messages Redirection

It returns the syslog messages redirection status of the current domain. This status shows whether the redirection to parent domain is enabled or disabled. To get the status, run:

ksctl domains syslog-redirection status