The Protegrity Data Security Platform is comprised of the Enterprise Security Administrator (ESA) – the central hub for enterprise-wide management of policy, key material, auditing, and reporting. The foundation for protecting sensitive data in the enterprise is the data security policy that the organization creates within the ESA, based on relevant regulations and its particular needs and circumstances. The purpose of the policy is to enable the Security Officer to determine, specify, and enforce the following data security rules:
- What type(s) of sensitive data shall be protected?
- Which method(s) will be used to protect the sensitive data?
- Who shall have access to the sensitive data?
- Where in the enterprise shall the policy be enforced?
- Audit of access and process attempts by whom, to what data, where and when.
The policy is enforced by the Data Protectors, and audit logs of all activity on sensitive data are recorded and sent back to ESA for reporting. Data Protectors have two primary components: the Communications Agent and the Policy Enforcement Agent.
- The Communications Agent is the switchboard between ESA and the Data Protector. It manages all policy and audit log communications between ESA and the Data Protector, caches, and secures policy from ESA with encryption keys (located remotely from the appliance) and prepares the policy for use by the Policy Enforcement Agent.
- The Policy Enforcement Agent executes the policy determined in ESA on the installed system, protecting or unprotecting data, and delivering it to the various enterprise roles according to the policy.
The Protegrity Data Security Platform provides a range of safeguards to protect the diversity of enterprise data environments. This includes the Pivotal Greenplum MPP Database Protector. This delivers protection on every node of a Greenplum database cluster. The Pivotal Greenplum MPP database protector makes full use of the parallel processing capability, the ability for nodes to pull policy updates (instead of pushing from ESA), and collecting and aggregating a massive number of audit logs from every node.
The following diagram illustrates the operations that the Policy Enforcement Agent performs as it protects sensitive data from unauthorized intruders and delivers data in the clear to authorized users.
1. A requestor (a person or a process) makes a request to view sensitive data (e.g. through an application or query console).
2. For example, the user requests to view Name and Address – both of which have been secured at rest inside the data storage of Pivotal Greenplum.
3. The Policy Enforcement Agent and the Communications Agent work together as the core components of the Data Protectors. All requests to view sensitive data trigger the Enforcement Agent to generate audit logs of all activity, and the Communications Agent relays them back to ESA.
4. In response to the request, the Enforcement Agent checks who the requestor is and checks the policy (in memory locally) to determine if the requestor has authority to the protected fields.
5. If the policy states that the requestor’s role is authorized to see, then the Enforcement Agent will take the data in storage and unprotect it. The policy may specify that only parts of the sensitive protected data may be exposed for a particular role. If the requestor is not authorized to access the protected sensitive data, then the Enforcement Agent will not deliver the data in the clear. The policy can be configured to return a variety of responses to unauthorized attempts, including delivering protected data, a “no access” string, NULL, an exception, etc.
6. Assuming the policy allows access, the unprotected Name and Address are returned to the user as part of the result set and an audit log of this activity is generated and sent to ESA.
