Protegrity protects specific sensitive data fields such as names, addresses, and dates of birth in deployments of Pivotal Greenplum, as well as other data sources. Leverage Protegrity to encrypt or tokenize (pseudonymize) data fields to reduce the risk of potential breach. Protecting sensitive data fields allows companies to safely and confidently share data and analytics from Pivotal Greenplum more widely across different classes of users while improving an organization’s overall data security posture.
Improve Your Organization's Security Posture
Breach threats are increasing as personal data becomes more valuable. Hackers often compromise access controls. Protecting specific sensitive data reduces the risks from a breach.
Support More Kinds of Users and Usage
Deploy a fine-grained data access policy that allows more of your employees to do their jobs better by accessing your companies data. At the same time, comply with increasing data security and privacy requirements.
Don’t Let Security Stop Business
Protegrity and Pivotal Greenplum are integrated and performant, so securing data to keep out the bad guys doesn’t stop employees from doing their jobs.
Protegrity Overview
Protegrity takes an enterprise approach to securing sensitive data. It leverages scalable, encryption, tokenization, and masking to help businesses secure sensitive information while maintaining data usability. This is a data-centric approach: securing data at rest, in transit and in use. Complementing other security layers (e.g. network security), data-centric security protects underlying data assets so that if perimeter security is breached and data accessed, then it is unreadable and of zero value. It also provides a barrier to internal data theft and is highly effective for creating test/dev data. Built for complex, heterogeneous business environments, the Protegrity Data Security Platform provides unprecedented levels of data security certified across applications, data warehouses, mainframes, hadoop / big data, and cloud environments. Protegrity is designed with a modular deployment architecture and centralized controls. In its latest Market Guide for Data-centric Audit and Protection*, Gartner identified Protegrity as a representative vendor operating across all five data silos and offering solutions in six DCAP capabilities profiled in the report.
Learn More at www.protegrity.com.
* Gartner “Market Guide for Data-Centric Audit and Protection” by Brian Lowans, Marc-Antoine Meunier, Brian Reed, Deborah Kish, Merv Adrian, and David Anthony Mahdi, 3/21/17
Integration features
Provides comprehensive database security with column/field-level data encryption, tokenization, or masking in database tables.
High transparency to applications that use the protected database(s), requiring very few or no modifications.
Utilises Greenplum’s MPP architecture with protectors on each node to minimize performance impact.
Protection at multiple levels of granularity
Segregation of duties by design
Complete range of protection algorithms
Protection can be consistent outside of Greenplum across the entire enterprise data architecture
Centrally managed policies (who can unprotect sensitive data)
Robust key management
Integration with external SIEM tools
“Bad guys are using your employees with privileged administrative access to get into your data warehouse, through phishing and other forms of social engineering. Simply using encryption to provide only coarse-grained protection does not provide enough risk mitigation to respond to today’s internal and external threats.”
Suni Munshani, CEO, Protegrity
How it works
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.
Let's talk about it.
Thank you for your interest!
We will get back to you shortly.
