Overview

The Model Architecture for Protegrity Appliance consists of various components aimed at ensuring data security, high availability, fault tolerance, and effective disaster recovery. It includes an Enterprise Security Administrator (ESA), Data Security Gateway (DSG), standard protectors, and cloud protectors.

Purpose

Protegrity’s Model Architecture must support business continuity, agility, and scalability in production. It should be prescriptive but adaptable to user specific requirements for additional capacity, geo-proximity, and domain isolation by simply extending the deployment architecture in a cookie cutter manner. Adhering to the principles of such an architecture would increase the reliability of solutions while reducing QA and support costs.

Goals

• Provide a proven, standardized blueprint for building a Protegrity Appliance.

• Help to reduce risk and uncertainty in design and implementation.

• Allow for better consistency and collaboration among stakeholders and team members.

• Improve the overall efficiency and effectiveness of development and deployment.

• Enable users to leverage best practices and industry standards to achieve their goals.

• Serve as a baseline for future improvements and enhancements.

What is NOT the goal

• It is NOT a complete universal architecture for all user deployments.

  • Example: A user does not currently have the resources or infrastructure available to achieve the model architecture.

  • Example: A user cannot implement the changes needed in time for the next change window.

• It is NOT a mandated solution for the user to have support from Protegrity experts, not necessarily meaning just Protegrity Support.

When an architecture does not meet a modeled architecture, what to do?

• Ensure the user understands the limitations of not following a model architecture.

• This is not supposed to be a push for increased licensing but to get the user to a better architectural stance.

Audience

This document is intended for:

• Solution Architects, Solution Engineers, Technical Account Managers, Customer Success Managers, Support Engineers, and Product Managers.

• Partners (with corresponding technical roles above).

Scope

The scope of this document includes:

• System Requirements: References to respective sections in documentation containing the detailed specifications of hardware and software prerequisites for deployment.

• Installation and Upgrade Procedures: References to respective sections in documentation containing the step-by-step instructions for installing the system and performing upgrades.

• Configuration Guidelines: Best practices and recommendations for configuring the system to meet operational needs.

• Best Practices for Maintaining and Operating the System: Guidelines on routine maintenance tasks and optimal operation strategies.

• Disaster Recovery Planning: Strategies and plans to recover and restore functionality in the event of a disaster. This includes failover and failback from Primary site to DR site and vice-versa.

• Fault Tolerance Strategies: Methods and techniques to ensure continuous operation and mitigate system failure risks.

• Security Measures: Security protocols and measures to protect the system from threats and vulnerabilities.

Key Concepts

The following key concepts are important to understand when reading the Model Architecture documentation.

GTM: Global Traffic Manager (GTM) is made available, configured, and controlled by the user. GTM is at a minimum required to achieve High Availability (HA) and Disaster Recovery (DR).

LTM: Local Traffic Manager (LTM) is made available, configured, and controlled by the user. LTM is required to achieve redundancy of ESAs in case of failover of primary ESA.

Replication Job: A manual replication job is required between the Primary ESA and all the Secondary ESAs.

Recovery Plan: A recovery plan is created and owned by the user.

For example, in an event of a failover (where Primary ESA is down, and Secondary ESA is up) and the load balancer now points to Secondary ESA. It is the best practice to freeze policy changes during this period to avoid having to consider the role of Secondary ESA being altered. A recovery from this scenario would be to resolve the reason Primary ESA is down and let the load balance simply switch back to the primary ESA.

Keystore: It is made available, configured and controlled by the user. The Keystore is required when regulations standards such as PCI DSS, HIPAA or FIPS are required to be enforced.

Port and Connection: All ports and connection requirements must be met to ensure seamless operation and communication across system components.