Frequently Asked CMK Questions

Q: What is CMK?

Customer Managed Keys, or CMK, is a cloud architecture pattern that gives customers control and ownership of the encryption keys that protect some or all of their data stored in SaaS applications. It also provides customers with an independent audit of data access.

CMK is a trust-but-verify model. Data is encrypted and decrypted on the service-side. The SaaS provider is able to access data, but the customer has control over encryption keys.

Q: How does CMK differ from Database Encryption?

Database encryption is a single-key approach that transparently protects data stored on disk. It is not per-tenant, a basic SaaS requirement. It does not give customers control over keys and it does not provide independent audit logging.

In a CMK architecture, encryption is performed at the application layer, not the data layer, and data is encrypted using per-tenant keys managed by the customer.

Q: What Key Management System (KMS) or Hardware Security Module (HSM) should I use?

This is a common misconception. You do not host your own KMS or HSM in a CMK architecture. Instead, you call into your customer’s key management infrastructure, giving them independent control.

For mid-market customers who want basic data protection, but do not need control over keys, you may choose to offer hosted KMS as a value-add. However, SaaS vendors should avoid self-hosting Hardware Security Modules. HSMs must be deployed as clusters, are prohibitively expensive and require audit and specialized expertise to manage.

Q: How does CMK work?

CMK gives customers control by integrating their key management infrastructure into a SaaS offering.

Application data is encrypted with a randomly generated data encryption key (DEK). This DEK itself is then encrypted, resulting in an encrypted DEK (EDEK), using a per-tenant master key that is controlled by the customer. The SaaS vendor agrees to discard the DEK from memory and only persist the encrypted data. The EDEK is persisted alongside encrypted application data.

The EDEK cannot be decrypted without interacting with the customer’s key management infrastructure. It is this property that provides the customer with independent control and audit.

Q: How does CMK impact performance or availability?

In a classic CMK architecture, encryption is record level and a decryption call is made on each access. This can introduce excessive latency and negatively impact SLAs. To mitigate these concerns, IronCore optionally supports key leasing. Key leasing caches keys in protected memory on secure machines for short periods so that decryption can be performed on the local network. In this architecture, impact to performance is negligible, and availability depends on the duration of the key lease (e.g., a one hour expiration, with 20 minute renewal would mean that an outage between datacenter and customer key management server would need to last an hour before becoming a service availability issue).

Q: What are Real Time Security Events?

Real time security events generate rich audit trails of data access that include metadata from each request such as the user or service that is making the request and the type of data being acted upon. Any additional metadata your application can provide with each request is used to enrich the security events that make up the event stream. This rich audit trail provides significantly more information than would be available if the tenant was just extracting events from its own KMS logs. SIEMs thus have more information to evaluate when looking for anomalous behavior, and it gives stronger evidence of data access that may be needed for compliance.

SaaS Shield Real Time Security Events allow each tenant’s administrators to configure a logging / SIEM system. The audit trail for each tenant is pushed to the tenant’s logging / SIEM system. As the name implies, this push happens in near-real time, so your tenants can find out about events of interest quickly.

Q: How does application-level encryption impact joins, sorts and filters?

Joins are not impacted as primary and foreign keys are never encrypted.

Sorting and filtering of encrypted fields can be performed client-side with no security implications. If client-side is not possible or practical, a server-side encrypted search or order-revealing encryption scheme may be appropriate. IronCore provides two separate mechanisms to support searching on fields that have been encrypted: deterministic encryption, if you only require exact match searches on the encrypted data, or Cloaked Search if you are using more feature-rich search capabilities provided by Elasticsearch or OpenSearch to index and search data.

Q: What is deterministic encryption?

Deterministic encryption is first and foremost a type of encryption, so it still takes data and a key and produces a scrambled version of the data, such that you can take that scrambled version and the key and recreate the original data. However, deterministic encryption uses an algorithm that will always produce the same encrypted data given a key and plaintext data. (Our regular encryption introduces randomness, so you get a different encrypted result every time you encrypt a given piece of data, even if you use the same key.)

Check here for more technical details.

Q: Is CMK a column-level or row-level approach to encryption?

CMK is orthogonal to the grain at which keys protect data. The defining characteristic of CMK is customer control over keys. Those keys can be used in whatever way makes the most sense for your application.

In practice, CMK is usually a per-tenant master key with per-record data keys (per-row if using a relational database, more generically per-record or per document). In Big Data applications, data keys are usually applied to a data partition. This fits naturally with map-reduce algorithms.

Q: Do I have to encrypt all of my data?

No and usually you do not. Most often data has varying levels of sensitivity. These sensitivity levels result in different data classifications. For example, public, private, restricted, secret, top-secret, etc.

Customers can set policies for different classes of data. In some cases, this means separate encryption and separate access controls on a per-field basis even within a single row.

Q: Does CMK provide end-to-end encryption?

Not generally. However, IronCore’s SaaS Shield CMK Kit can be paired with the IronCore Data Control Platform to add full end-to-end features.

End-to-end encryption is when data is encrypted at its point of origin and is not decrypted until its point of use. Encryption and decryption are most-often performed on the client (but can be performed by cloud services).

We recommend that SaaS vendors begin with server-side encryption and selectively provide client-side protections. These approaches can be mixed. For example, it’s common for SaaS applications to provide CMK protection of records and fields and end-to-end encryption of opaque file attachments. Integrating with IronCore CMK gives you an iterative approach to supporting a full spectrum of data protections.

IronCore’s end-to-end solution also supports cryptographic access control. Access control is the ability to specify who can access what. It is typically implemented using Access Control Lists (ACLs) stored with data. This is prone to the inevitable bugs associated with any large scale software implementation. Cryptographic access control is a way to (conceptually) embed access control directly into the data with cryptographic backing. It has favorable trust-model (minimal/zero-trust) and provability attributes.

Note that end-to-end encryption is required for scenarios where the SaaS application must never be allowed to see or process customer data. End-to-end encryption is zero-trust, whereas CMK is trust-but-verify.

Q: How is key rotation addressed?

Key rotation is completely transparent to your application. IronCore handles all of the details.

Rotating encryption keys is a common practice. Limiting the amount of content encrypted with a single key minimizes the amount of data leaked by a single key compromise.

IronCore rotates DEK keys on every data update.

For master keys, rotation is performed with your customer’s key management infrastructure. IronCore Encryption Service isolates you from any changes.

Q: Can I roll my own CMK solution?

Certainly, but this may not be a good economic, performance or risk decision.

CMK architectures have high integration complexity. There are multiple key management product lines, each with different products and numerous configuration possibilities. Integration with each KMS is not practical. IronCore CMK isolates you from integration complexity by providing a single point of integration and a secure configuration broker for your customers.

Cloud security is evolving rapidly in response to new government regulation and increasing system complexity. Building these features yourself is a lifetime commitment to maintaining and evolving the security and functionality. IronCore will absorb these issues and keep you current and with the latest, strongest, best options for you and your customers.

In a roll-your-own CMK all of the trust must be placed in you as the SaaS vendor. When using a third-party solution made by experts and independently audited, trust is more readily granted. Transparency is also key to trust here, and IronCore offers a high degree of transparency including audited and open sourced code and published papers. Finally, engineering cryptographic solutions are highly error-prone. Legacy open source libraries don’t provide key management solutions or guard rails that prevent developers from accidentally nullifying the security of their schemes. Building these solutions in house creates a higher level of risk for the company and its customers.

Writing security code is a specialized discipline that is not a core competency for traditional SaaS developers. With IronCore, performance is heavily optimized, but the implementation is carefully audited to avoid security holes.