On the first of January 2020, the California Consumer Privacy Act (CCPA) went into effect, placing new burdens on organizations that do business in or with residents of California. Which means a whole lot of organizations are under pressure to meet new regulations.
But, didn't we just go through this with General Data Protection Regulation (GDPR)?
While some of the requirements brought to us by the European Union's GDPR do overlap with CCPA, GDPR compliance isn't enough to protect your organization in regard to CCPA.
Let’s review the basics of what CCPA allows consumers:
Many of the provisions of the CCPA can simply be adhered to through changes to organizational policies or disclaimers issued on an organization’s website. That said, a handful of provisions are best addressed using technology.
To ensure that data is stored securely, encryption, both in transit and at rest, can be utilized—however, building an encryption scheme yourself can be a challenge.
Additionally, how can you ensure that the data hasn't been accessed inappropriately or disclosed to outside parties? By logging each access attempt and analyzing those logs, you’ll make certain that only approved processes or people can see or use the data.
Deleting data upon request might sound straight forward but what about all the backups? Will you have to scour every S3 bucket or backup tape to safeguard that the data has been completely removed? If you encrypt each record with a unique key, you can functionally delete all copies of a record by deleting that key. Much simpler, right?
HashiCorp's Vault is a drop-in solution to these challenges and more. Let's drive into three specific parts of CCPA and how Vault can be utilized to address these challenges.
Vault Security Barrier
The storage backends used by Vault are untrusted by design. Vault uses a security barrier for all requests made to the backend. Vault’s cryptographic barrier encrypts all information in transit and at rest via the cryptographically secure aes-256 algorithm. Depending on the backend used, Vault may communicate with the backend over TLS to provide an added layer of security. In some cases, such as a file backend, this is not applicable. Because storage backends are untrusted, an eavesdropper would only gain access to encrypted data (even if communication with the backend was intercepted).
The transit secrets engine handles cryptographic functions on data in-transit. Vault doesn't store the data sent to the secrets engine. It can also be viewed as "Cryptography as a Service" or "Encryption as a Service". Furthermore, Vault’s Transit secrets engine allows for encryption/decryption/hmac workflows, as well as signing and verification, abstracting the complexity around maintaining encryption keys, and allowing users and organizations to retain control over them inside Vault’s cryptographic barrier. The primary use case for transit is to encrypt data from applications while still storing that encrypted data in some primary data store. This relieves the burden of proper encryption/decryption from application developers and pushes the burden onto the operators of Vault.
SEC. 5. Section 1798.105 of the Civil Code is amended to read:
1798.105. Right to Delete Personal Information
1798.105. (a) A consumer shall have the right to request that a business delete any personal information about the consumer which the business has collected from the consumer.
Vault’s Transit backend supports deriving a unique encryption key for each citizen. Using derived convergent is extremely powerful as it offers several benefits to your organization. Key derivation is supported, which allows the same key to be used for multiple purposes by deriving a new key based on a user-supplied context value.
In this mode, Vault encrypts each row in each table of the database with a unique encryption key. Even if an attacker were able to access the raw data, each row of the database is encrypted with a unique, high-entropy key. Also, the database never sees a plaintext value. Why do we need derived encryption? When 1798.105. (a) is invoked, the derived key is then removed and data is effectively cryptoshreded. If any ciphertext was lost or stolen they would essentially become useless to a would be attacker as they now have no means of finding the encryption key. Enable the transit secrets engine by executing the following command:
$ vault secrets enable transit
By default, the secrets engine will mount at the name of the engine. Now, create an encryption key ring named "ccpa" by executing the following command:
$ vault write -f transit/keys/ccpa
Create encryption key with convergent encryption option in Vault's UI derived key.
SEC. 13. Section 1798.140 of the Civil Code is amended to read:
1798.140. Definitions
(1) Auditing related to a current interaction with the consumer and concurrent transactions, including, but not limited to, counting ad impressions to unique visitors, verifying positioning and quality of ad impressions, auditing compliance with this specification and other standards, providing analytic services, or providing similar services on behalf of the business, service provider, or contractor.
Vault’s audit log maps actions to entities to track data breach taxonomy, patterns of access, and who is accessing what.
Audit devices are the components in Vault that responsible for managing audit logs. Every request to Vault and response from Vault goes through the configured audit devices. This provides a simple way to integrate Vault with multiple audit logging destinations of different types.
The generated audit log contains every authenticated interaction with Vault including errors. There is an audit log entry for each request and its response, a compressed JSON object that looks like this:
{
"time": "2019-11-05T00:40:27.638711Z",
"type": "request",
"auth": {
"client_token": "hmacsha256:6291b17ab99eb5bf3fd44a41d3a0bf0213976f26c72d12676b33408459a89885",
"accessor": "hmacsha256:2630a7b8e996b0c451db4924f32cec8793d0eb69609f777d89a5c8188a742f52",
"display_name": "root",
"policies": [
"root"
],
"token_policies": [
"root"
],
"token_type": "service"
},
"request": {
"id": "9adb5544-637f-3d42-9459-3684f5d21996",
"operation": "update",
"client_token": "hmacsha256:6291b17ab99eb5bf3fd44a41d3a0bf0213976f26c72d12676b33408459a89885",
"client_token_accessor": "hmacsha256:2630a7b8e996b0c451db4924f32cec8793d0eb69609f777d89a5c8188a742f52",
"namespace": {
"id": "root"
},
ccpa.md 11/29/2019
4 / 5
"path": "sys/policies/acl/admin",
"data": {
"policy": "hmacsha256:212744709e5a643a5ff4125160c26983f8dab537f60d166c2fac5b95547abc33"
},
"remote_address": "127.0.0.1"
}
}
{
"time": "2019-11-05T00:40:27.641524Z",
"type": "response",
"auth": {
"client_token": "hmacsha256:6291b17ab99eb5bf3fd44a41d3a0bf0213976f26c72d12676b33408459a89885",
"accessor": "hmacsha256:2630a7b8e996b0c451db4924f32cec8793d0eb69609f777d89a5c8188a742f52",
"display_name": "root",
"policies": [
"root"
],
"token_policies": [
"root"
],
"token_type": "service"
},
"request": {
"id": "9adb5544-637f-3d42-9459-3684f5d21996",
"operation": "update",
"client_token": "hmacsha256:6291b17ab99eb5bf3fd44a41d3a0bf0213976f26c72d12676b33408459a89885",
"client_token_accessor": "hmacsha256:2630a7b8e996b0c451db4924f32cec8793d0eb69609f777d89a5c8188a742f52",
"namespace": {
"id": "root"
},
"path": "sys/policies/acl/admin",
"data": {
"policy": "hmacsha256:212744709e5a643a5ff4125160c26983f8dab537f60d166c2fac5b95547abc33"
},
"remote_address": "127.0.0.1"
},
"response": {}
}
The following command enables the audit device, file at the file/path. The output logs are stored in the /vault/vault-audit.log file.
$ vault audit enable file file_path=/vault/vault-audit.log
Success! Enabled the file audit device at: file/.