- PrivaceraCloud Release 4.5
- PrivaceraCloud User Guide
- PrivaceraCloud
- What is PrivaceraCloud?
- Getting Started with Privacera Cloud
- User Interface
- Dashboard
- Access Manager
- Discovery
- Usage statistics
- Encryption and Masking
- Privacera Encryption core ideas and terminology
- Encryption Schemes
- Encryption Schemes
- System Encryption Schemes Enabled by Default
- View Encryption Schemes
- Formats, Algorithms, and Scopes
- Record the Names of Schemes in Use and Do Not Delete Them
- System Encryption Schemes Enabled by Default
- Viewing the Encryption Schemes
- Formats, Algorithms, and Scopes
- Record the Names of Schemes in Use and Do Not Delete Them
- Encryption Schemes
- Presentation Schemes
- Masking schemes
- Create scheme policies on PrivaceraCloud
- Encryption formats, algorithms, and scopes
- Deprecated encryption formats, algorithms, and scopes
- PEG REST API on PrivaceraCloud
- PEG API Endpoint
- Request Summary for PrivaceraCloud
- Prerequisites
- Anatomy of a PEG API endpoint on PrivaceraCloud
- About constructing the datalist for /protect
- About deconstructing the response from /unprotect
- Example of data transformation with /unprotect and presentation scheme
- Example PEG REST API endpoints for PrivaceraCloud
- Audit details for PEG REST API accesses
- Make calls on behalf of another user on PrivaceraCloud
- Privacera Encryption UDF for masking in Databricks
- Privacera Encryption UDFs for Trino
- Syntax of Privacera Encryption UDFs for Trino
- Prerequisites for installing Privacera Crypto plug-in for Trino
- Variable values to obtain from Privacera
- Determine required paths to crypto jar and crypto.properties
- Download Privacera Crypto Jar
- Set variables in Trino etc/crypto.properties
- Restart Trino to register the Privacera Crypto UDFs for Trino
- Example queries to verify Privacera-supplied UDFs
- Azure AD setup
- Launch Pad
- Settings
- General functions in PrivaceraCloud settings
- Applications
- About applications
- Azure Data Lake Storage Gen 2 (ADLS)
- Athena
- Privacera Discovery with Cassandra
- Databricks
- Databricks SQL
- Dremio
- DynamoDB
- Elastic MapReduce from Amazon
- EMRFS S3
- Files
- File Explorer for Google Cloud Storage
- Glue
- Google BigQuery
- Kinesis
- Lambda
- Microsoft SQL Server
- MySQL for Discovery
- Open Source Spark
- Oracle for Discovery
- PostgreSQL
- Power BI
- Presto
- Redshift
- Redshift Spectrum
- Kinesis
- Snowflake
- Starburst Enterprise with PrivaceraCloud
- Starburst Enterprise Presto
- Trino
- Datasource
- User Management
- API Key
- About Account
- Statistics
- Help
- Apache Ranger API
- Reference
- Okta Setup for SAML-SSO
- Azure AD setup
- SCIM Server User-Provisioning
- AWS Access with IAM
- Access AWS S3 buckets from multiple AWS accounts
- Add UserInfo in S3 Requests sent via Dataserver
- EMR Native Ranger Integration with PrivaceraCloud
- Spark Properties
- Operational Status
- How-to
- Create CloudFormation Stack
- Enable Real-time Scanning of S3 Buckets
- Enable Discovery Realtime Scanning Using IAM Role
- How to configure multiple JSON Web Tokens (JWTs) for EMR
- Enable offline scanning on Azure Data Lake Storage Gen 2 (ADLS)
- Enable Real-time Scanning on Azure Data Lake Storage Gen 2 (ADLS)
- How to Get Support
- Coordinated Vulnerability Disclosure (CVD) Program of Privacera
- Shared Security Model
- PrivaceraCloud
- PrivaceraCloud Previews
- Privacera documentation changelog
Privacera Encryption core ideas and terminology
Privacera Encryption enhances the data security provided by Privacera Access Management and Privacera Discovery.
You can encrypt tables, columns, rows, fields, or other data in connected systems. Even if the data are accessible by policies created in Privacera Access Management, the encrypted data cannot be seen.
Encryption can be two-way: you can encrypt the data in place and decrypt it later. Or it can be one-way: with hashing or overwriting with string literals, you can replace the original data to make it invisible and unrecoverable.
You can also completely mask data with a one-way transform.
For a view of the following essential terms in action, see Graphical view of encryption processes
Privacera Encryption relies on schemes:
A scheme is a combination of formats, algorithms, and scopes.
Encryption Schemes encrypt or decrypt the data.
Optional presentation schemes obfuscate decrypted data to a form suitable for displaying to authorized users.
Masking schemes permanently transform the data one-way.
All schemes rely on the same set of Encryption formats, algorithms, and scopes.
An input data format defines the data type and structure to be encrypted, such as alphanumeric, credit card, email address, or social security number.
An encryption algorithm specifies the mathematics used to encrypt, such as AES, FPE, or SHA.
A scope defines the extent of the encryption on the data, such as the first four digits, an IP domain, or all data. Scoping ALL is recommended.
A scheme policy defines access control: users who have permission to access a scheme.
For example, you might rely on a Privacera-supplied encryption scheme to protect a PII field called "EMAIL". The scheme:
Uses
EMAIL
format.Applies the SHA-256 algorithm for a one-way hash.
Is scoped with "masked domain" to hide the portion of the email to the right of the @ sign.
You can also define your own custom encryption, presentation, and masking schemes.
Graphical view of encryption processes
This conceptual graphic with annotation shows the general process of Privacera Encryption. This same process is also illustrated in Encryption architecture and UDF flow.

An endpoint is called to encrypt raw data.
The scheme policy protecting access to encryption functions is checked.
The encryption scheme encrypts the data according to its associated format, algorithm, and scope.
The data is encrypted.
An endpoint is called to decrypt the encrypted data.
The scheme policy protecting access to encryption functions is checked.
The same encryption scheme that encrypted the data is used to decrypt according to the encryption scheme's format, algorithm, and scope.
The presentation scheme obfuscates the decrypted data for presentation to the user.
Encryption architecture and UDF flow
The following diagram shows the PEG architecture for viewing a record. For a description of the keys in this architecture, see Hierarchy and Types of Encryption Keys.

A user queries sensitive data.
Privacera Access Management verifies the user access privileges to the data and the key (encryption scheme) used to decrypt the data.
If the user has access privileges to both the data and key, Privacera encryption requests the Data Encryption Key (DEK) for the encryption scheme.
The Privacera Encryption Gateway (PEG) sends the Encrypted Data Encryption Key (EDEK) from the scheme to Ranger KMS to decrypt the DEK.
Ranger KMS authenticates the caller (the encryption module) and uses the KEK to decrypt EDEK and obtain the DEK.
The PEG obtains the DEK and decrypts the data.
The PEG returns the data to user.
Hierarchy and Types of Encryption Keys
Hierarchy and types of encryption keys
To prevent compromise of encryption keys, key management is critical for encryption of data-at-rest and data-in-transit. The encryption keys must be secured by externalizing them into a separate Key Management System (KMS). Apache Ranger KMS is the key storage system to manage keys across Privacera services. Keys are stored in an encrypted format in the Apache Ranger KMS database.
The key hierarchy includes the following types of keys.

Master Key
The Master Key encrypts the KEKs in Apache Ranger KMS.
The Master Key is stored separately outside of the KMS database or externally on a hardware security module (HSM).
Key Encryption Key (KEK)
A KEK encrypts the Data Encryption Key (DEK).
KEKs are encrypted with the Master Key.
The KEKs are stored and managed in Apache Ranger KMS. Apache Ranger KMS manages the KEK keys to either encrypt DEKs to create Encrypted Data Encryption Keys (EDEKs) or to decrypt EDEKs.
If a KEK is deleted, any associated encrypted data cannot be decrypted.
Data Encryption Key (DEK)
The Data Encryption Key (DEK) is the key that encrypts and decrypts the data.
Each encryption scheme created in the Privacera Portal is mapped to a unique DEK. The user must have key access privileges by way of a scheme policy to encrypt or decrypt data with the DEK.
The DEK is stored in an encrypted format as an Encrypted Data Encryption Key (EDEK). The key used to encrypt the DEK is managed by Apache Ranger KMS.
Encrypted Data Encryption Key (EDEK)
The EDEK is the encrypted DEK and is encrypted with a KEK. A KEK is required to decrypt an EDEK. EDEKs are stored and managed by Privacera.
Key Security
For maximum security, Privacera Encryption relies on different types of encryption keys. For a description of keys, see Hierarchy and Types of Encryption Keys.