Smartcrypt Enterprise Manager Appliance Setup

Table of Contents

  1. General Appliance Overview
  2. Definitions
  3. Setup and Configuration
  4. Upgrades
  5. Backups and Restores

General Appliance Overview

Note: For customers wishing to install the Smartcrypt Enterprise Manager onto their own application and database infrastructure, a software only (non-Appliance) version is available.

Definitions

Data Centers

Data Centers are used to determine which user agents connect to which Smartcrypt Enterprise Managers. A Data Center requires a defined Active Directory Organizational Unit and when a user agent from that OU authenticates it will be directed to communicate with the Smartcrypt Enterprise Manager or Cluster responsible for serving that OU.

Clusters

Clustering two or more Smartcrypt Enterprise Manager (SEM) Appliances can assist in centralized management and fault tolerance. Clustered systems can be geographically dispersed and do not need to be located on the same network. Note: Clustering systems do not provide network load-balancing functionality. If you want to load balance traffic among appliances, you can use a 3rd party load balancer that supports sticky sessions or use DNS round-robin. That said, systems can be added to data centers to ensure that Users in a specific Active Directory OU are always redirected to the same appliance or group of appliances.

Smartcrypt Enterprise Manager Setup and Configuration Quick Start

  1. Login and Accept EULA
  2. Create SMDS Account
  3. Acquire evaluation license
  4. Configure Network / Hostname
  5. Join Active Directory Domain (System | Domain Tab)
  6. Configure AD Account (requires netbios prefix)
  7. Configure LDAP User (+LDAPS)
  8. Exporting LDAPS public key for import
  9. Configure AD Connection for User Lookups (Basics | Server General Tab)
  10. Set Master Database Password (System | Database)
  11. Configure TLS/SSL (System | SSL Tab)
  12. SSL (Upload Trusted Roots (NewQ))
  13. Does not get passed to clients
  14. Advanced | Clusters
  15. Join Slave
  16. Verify connectivity
  17. Advanced | Data Centers
  18. Setup first data center
  19. Verify

Configurations

The Smartcrypt Enterprise Manager Appliance comes in four configurations

  • 200v :: A virtual appliance suitable for utilizing within your own virtual infrastructure.
  • 300h :: A hardware appliance that contains a hardware security module (HSM) for FIPS 140-2 Level 3 key storage.
  • 300r :: A hardware appliance that contains a quantum powered true random number generator provided by Quintessence Labs.
  • 350 :: A hardware appliance that contains both an HSM and a quantum random number generator. Note: A Smartcrypt Enterprise Manager can be configured to use a pre-existing, external Quintessence Labs Trusted Security Foundation for HSM backed secure key storage or quantum random number generation. The following documentation applies to all of the above configurations.

Hypervisor Support (200v only)

The Smartcrypt Enterprise Manager Appliance is officially supported on VMware vSphere v5.5+ but should run in any hypervisor including Microsoft Hyper-V, Citrix Xen Server and Linux KVM. It will also run in many Type-2 hypervisors including VMware Fusion, Workstation, VirtualBox and Hyper-V on Windows.

For proof-of-concept and lab environments, a single appliance is supported. For production use, a minimum of two appliances is required. PKWARE recommends two [TODO]**appropriately sized ** appliances per physical data center. For example:

  • A 10,000-user enterprise with east and west coast data centers could deploy a 4-appliance cluster. Virtual Data Centers would be defined to partition west coast and east coast users to the two appliances closest to them, with appropriate considerations made for an organization's Active Directory Organization Unit configuration strategy.
  • A 50,000-user enterprise with a large US production data center, US disaster recovery (DR) site and branch offices in Germany and and the UK could deploy six units. Two in the production data center, two at the DR site and one in each of the branch offices. The master database would reside in the production data center and during DR testing / recovery one of the slave units in the DR site would be promoted to master.

Masters and Slaves

Each appliance has three local databases:

  • An (encrypted) key store containing identity and encryption key information. The master appliance has a read + write version of this database and each slave has a read-only copy.
  • A security information event database that contains events generated by the Agents attached to it.
  • A temporary database used for publishing security events to the master. The Appliance uses a single master / multiple slave database model where the majority of the time agents are only reading updates to the state of the world they live in. These updates include agent configuration updates, new policy distributions, changes to existing policies, new encryption-key distributions and changes to the access control lists on existing encryption keys. An example of a write operation would be an endpoint client creating an encryption key. Once the client creates a key and its corresponding access control list (ACL), the client must send that information to the master database. Once the master is aware of the new key and ACL, it updates its own keystore and synchronizes the change with the slave instances. Once each slave has learned about the new key the agents connected to that slave will learn about it.

Non-Clustered Data

Each Appliance has its own configuration information that is not replicated to other members of the cluster. This information includes things like hostname, IP Address, DNS information, etc.

Local host mapping

Agent Communication

We only use online/offline status and home data center to determine which server we prefer. If that server is unavailable, we try every other server until we find one that works. We will also periodically check if we're able to return to the preferred server if we're not already talking to it. Expected behavior is that the agent talks to one of the servers in the other data center.

Clusters

Clusters are required for failover, high availability and performance. Smartcrypt data (identities, encryption keys, policies and configuration data) are replicated between nodes to ensure information cannot be lost.

Creating a new Cluster

To create a cluster, navigate to the Advanced tab and choose Cluster. If the Appliance is not a current Cluster member, you will see a message indicating that the server is currently in standalone mode. Click Start a Cluster to put the Appliance in cluster mode. You should see a single member in the cluster list with the "State" set to "Up" and the "Database Source" set to Master. To add systems to this cluster, see "Adding a new system to an existing Cluster" TODO: Link.

Adding a new system to an existing Cluster

To add a new Appliance to the Cluster:

  1. Navigate to the Advanced tab and choose Cluster. If the Appliance is not a current Cluster member, you will see a message indicating that the server is currently in standalone mode.
  2. Click Start Pairing Mode to put the node in pairing mode allow the node to accept a new Appliance.
  3. Navigate to the current Master node in the cluster and choose the "Pair with Another" option.
  4. Type the URL of the new node you put into pairing mode in the previous step and click Pair. Once the pairing process has finished you will see a "Complete" message. On the clustering page you will see all nodes and their current states. New nodes will show up in a "Down" state until they have finished their initial data replication from the Master. For large databases over slower network links this could take several minutes.

Removing a system from a cluster

To remove an Appliance from a Cluster:

  1. Navigate to the Advanced tab and choose Cluster.
  2. Select the node you wish to remove and choose the "Remove" option on the right hand side. This will set the removed node back to its original factory state. ...If you do not plan on re-adding the removed node back into the cluster, choose to "Delete" it from the link on the right. Note: If the node you wish to remove is currently the master, you must choose a new master first. See "Promoting a slave to a master" below. TODO: Link.

Limiting user access to the cluster

Changing the mode of a cluster

Promoting a slave to master

  1. Login to the node you wish to promote.
  2. Navigate to the Advanced tab and choose Cluster.
  3. Click Make Database Master. This will cause a re-assignment of the master role that,upon completion. will allow you to cleanly remove the old master from the Cluster.

Data Centers

Data centers are used to map Active Directory (AD) users by Organizational Unit (OU) to an Smartcrypt Enterprise Manager Cluster. When a user logs in, they are directed to a Smartcrypt Enterprise Manager or Cluster of Managers responsible for servicing their OU.

Creating a new Data Center

Click Advanced, choose Data Centers and click Add. Choose a descriptive name and type out the Active Directory Organizational Unit paths you wish to assign to this Data Center. For example:

...Data Center Name: PKWARE UK
...Data Center OUs: ou=users,ou=lhr,dc=pkware,dc=com
...Data Center Name: PKWARE US
...Data Center OUs: ou=users,ou=mke,dc=pkware,dc=com | ou=users,ou=mke,dc=pkware,dc=com | ou-users,ou=lga,dc=pkware,dc=com

Assigning a Data Center to a node

Once you have created a new Data Center, it must be assigned to a node in the Cluster. Return to the Cluster tab and click Edit Data Centers. From here, you may assign specific Smartcrypt Enterprise Manager nodes to the data centers you wish them to service.

Upgrading the Smartcrypt Enterprise Manager Appliance

To upgrade to the latest version:

  1. Download the latest update (delivered as a .zip file).
  2. Navigate to the System tab of the Smartcrypt Enterprise Manager.
  3. Click Choose File from the System Updates section and select the .zip file you downloaded in Step 1.
  4. Click Update. The update will be applied and the system will automatically restart. Some updates will take longer than others and you may need to wait up to 15 minutes for an update to be fully applied.

Updating software on a cluster

Note: Upgrading the master causes a publication of the compatibility matrix between all slaves. All nodes will evaluate themselves and decide if they are compatible or not. If they are not, they disable their service API (clients cannot connect to them) and they send a message stating that they are not compatible with the cluster. Each slave must be upgraded; after which they will rejoin replication. Slaves may be updated ahead of the master. For example: If the master is on v17.0 and a slave is on v17.1, the slave will operate at the v17.0 feature-set until the master has been upgraded to v17.1.

Backup and Restores

A daily database backup is taken at 12:00am each day. All database restores must be performed on the Master node. To restore a database, login to the Master node and click on the System tab. Choose the database you wish to restore and click Restore. WARNING: Encryption keys created AFTER the point in time you are restoring to will be lost. Data encrypted with these keys will remain inaccessible unless you have previously configured a Contingency Key or Contingency Group.