Follow

SealPath Enterprise On-Premise - Implementation Schemes

Here are shown two basic schemes for deploying SealPath Enterprise On-Premise:

Basic deployment

In the most basic deployment scheme the database is located in the same machine than the front-end servers although it is possible to keep a secondary database in warm-standby with log-shipping to prevent possible outages. The machine is integrated in the domain and connected to Active Directory to manage users, groups, etc.

onpremise_basico.png

 

Deployment with different machines in the front-end and back-end

In the following figure it is shown a deployment where the front-end servers and databases are separated in different machines and different locations and networks. The front-end it is located in the DMZ, in the network’s perimeter. The back-end with the database is located in the internal network with the domain controller.

 onpremise_2.png

Advanced deployment and high-availability deployment

There are other ways to deploy SealPath Enterprise besides the two basic described above. Contact info@sealpath.com to know more details.

 

Communications between servers

Inside the same data center it is possible to have redundancy of the front-end SealPath protection servers (AD-RMS + SealPath’s web services) working in high-availability. These server can work in active/active mode. They are based on stateless services so the load balancing of connections done by a hardware/software load balancer is optimal.

The servers connect with the database (SQL Server) to answer to the different client requests: Document access, protection, audit, etc. The database stores, shares and recovers the following information from a front-end protection cluster:

  • Encryption keys.
  • Cluster configuration data.
  • Certificates and associated identities.
  • Needed data to manage access to protected documents.
  • Audit data about document access, warnings, etc.
  • It caches information about users, identities, Group membership, etc.

To protect the Database against failures there are different alternatives:

  • Include the Database in a high-availability cluster.
  • Use log-shipping to have always a database in “warm-standby”.
  • Have an appropriate and functional back-up policy.

The front-end protection server (AD-RMS + SealPath Web Services) contacts with the Active Directory or LDAP to get information about users and groups (although the database caches this information to minimize the requests to the Active Directory). As the Active Directory is an internal corporate service, usually the organizations already have a high-availability policy for it.

The clients make request to the front-end to:

  • Consume and protect documents.
  • Get audit data.
  • Create protection policies.
  • Authenticate with the system.

These requests can come from outside or inside the corporate network. All the requests are redirected to a URL (i.e.  https://protection.companydomain.com) and use 443 port (HTTPS).

Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request

0 Comments

Please sign in to leave a comment.
Powered by Zendesk