Keyfactor Command Security Design Considerations
Keyfactor Command Security Design Considerations
-
Determine the list of users or groups who will have access to Keyfactor Command. Access in Keyfactor Command is based on Active Directory users and groups. These will be used to create Security Identities in Keyfactor Command (using the "DOMAIN\group name" format) to which Security Roles will be assigned.
Note: If you require only one layer of security (all users will have full access) you can simply use the Administrator Role that was created during installation (see Administration Section in the Keyfactor Command Server Installation Guide).Note: When defining the AD groups/users you will use to form Identities, consider whether you will have a one-to-one or one-to many relationship between Identities and Roles. -
Define the naming convention for Security Roles. Menu access and certificate security will be assigned to Roles which in turn will be applied to Security Identities.
-
Determine the Keyfactor Command menu access and level of functionality you want to apply to each Role using the permissions information found Security Role Permissions.
-
Determine certificate security based on collections and certificate store permissions based on containers, if any. See below for more information.
When designing a container permission scheme, you need to think first about whether you want your users to have access to all the certificate stores in your Keyfactor Command database or whether you need to limit your users to having access to only a subset of your stores. If you're comfortable granting access to all the stores, you can use the global Read permission. If you're not comfortable with this, you need to use container-level permissions and grant Read permissions on a container-by-container basis. These can be granted separately on a group-by-group (or user-by-user) basis, so group A can be granted global Read while group B is only granted Read to a certain container.
Next, you need to think about what you want your users to be able to do with the stores they have access to. By granting Read access to the stores, you're allowing your users to browse to the certificate stores page and see all the stores and containers that they've been granted access to, but they can perform no operations related to the stores. These are controlled with additional permissions (see below) that can also be set either globally or on a container-by-container basis. You can combine global and container-level security.
In addition to the permissions that must be considered when designing a permission scheme for certificate stores, you must also give consideration to permissions for certificates. Users must have permissions to certificates in order to use the certificate store operations. See Certificate Permissions and Container Permissions.
Any containers that do not have container-by-container permissions applied fall back to the global permissions, if any global permissions have been set.
When designing a certificate permission scheme, you need to think first about whether you want your users to have access to all the certificates in your Keyfactor Command database or whether you need to limit your users to having access to only a subset of your certificates. If you're comfortable granting access to all the certificates, you can use the global Read permission. If you're not comfortable with this, you need to use collection The certificate search function allows you to query the Keyfactor Command database for certificates from any available source based on any criteria of the certificates and save the results as a collection that will be availble in other places in the Management Portal (e.g. expiration alerts and certain reports).-level permissions and grant Read permissions on a collection-by-collection basis. These can be granted separately on a group-by-group (or user-by-user) basis, so group A can be granted global Read while group B is only granted Read to a certain collection.
Next, you need to think about what you want your users to be able to do with the certificates they can view. There are certificate operation permissions (see Certificate Permissions) that you can set that control what your users can do with the certificates. These can be set either globally or on a collection-by-collection basis. You can combine global and collection-level security.
At the global level, the Certificates Read role permission grants access to both the certificate search page and all certificate collections. Users who have been granted only collection-level Read permissions and not global Read permissions have access only to the collections to which they have been granted access and not to the certificate search page. See Security Role Permissions and Certificate Permissions.
In addition to the Certificates role permissions that must be considered when designing a permission scheme for certificates, you must also give consideration to the Certificate Collections and Certificate Store Management global role permissions.
-
Enabling the Certificate Collections Modify global role permission allows users to use the Save, Save As and Delete buttons for a collection. This allows users to create new certificate collections based on existing collections (Save As), delete existing collections (Delete), or modify select settings about an existing collection (Save). Typically, Certificate Collections permissions would only be granted to users who also had at least global Read permissions to allow them to do certificate searches from which to create new collections.
-
You will need to consider the Certificate Store Management role permissions if you use certificate stores and want any of your limited access users to make use of the Add to Certificate Store, Remove from Certificate Store, or Renew/Reissue operations on certificates. These certificate operations are only available to users who have also been granted the Read and Schedule role permissions for Certificate Store Management. Permissions to certificate stores can be granted either globally or via container security (see Certificate Permissions and Container Permissions).