When it comes to protecting data and workloads in Google Cloud, you’re likely torn between competing needs:
- a true separation of powers without a loss in performance;
- simpler security and dynamic access policy capabilities even as contexts and edge cases multiply; and
- a single plane of control and visibility across a diverse portfolio of applications and environments.
Luckily, integrated security and access policy control is finally catching up to technology with the integration of Ionic MachinaTM and Google Cloud External Key Manager (EKM). In this post, I’ll give a technical overview of the solution and an explanation of policy-driven access controls, including comparisons to other methods to explore how Machina for EKM resolves the tension between competing needs.
For organizations who want to maintain encryption keys completely outside of their cloud infrastructure, Machina for EKM offers a true separation of powers with key provenance, centralized key management, and granular policy-based access controls. In fact, Machina delivers customer-managed trust: a consistent, unified approach to policy management across your portfolio of applications, regardless of whether they’re on-prem or in the cloud.
Technical Overview of Machina for EKM: Separation of Powers with High Performance
It all starts with a Google Cloud key ring — which is a logical grouping of keys for organizational purposes — and a key, which inherits certain permissions from the key ring. A key is a named grouping of versioned key material that has defined protection, purpose, and algorithm characteristics. All keys represent groupings of key versions, where each key version is simply key material associated with a key at any given moment. Used to encrypt some corpus of data, this is a key encryption key (KEK).
EKM relies on external KEKs, which are defined as symmetric keys with an “external protection level” provided by a third party, Ionic. External key versions have a globally unique URI (uniform resource indicator) that maps to a specific piece of external key material. The URI identifies the region-specific Machina EKM service and key to use as a key encryption key (KEK). The KEK functions as a wrapper, encrypting the DPK (data protection key). Machina is a highly scalable and available service that receives requests to wrap and unwrap DPKs with a key version KEK.
In practice, you can follow these easy steps (and get more support here):
- Create a key or use an existing one in your Machina with any attributes that describe the data. This is your KEK.
- Grant your Google Cloud project access to this key using Machina policy
- Associate the Google KEK version in your Google Cloud project to your KEK
- Set Ionic policy as desired using Machina attributes
- Start securely accessing data and resources
When an access request is made in your Google Cloud environment to anything protected with an external key, the Google native service calls out via the EKM API as the project service user to Machina. Google provides authentication of the service user making the request through signed claims; Machina verifies your white listed instance and the validity of the Google service user claims for full integrity. At this point, Machina policy reviews additional contextual details to determine whether or not to unwrap the DPK.
Because the Google DPK has been fully wrapped by the KEK, at no time does Google have the ability to decrypt without explicit permission granted by Machina policy. Likewise, Machina does not have access to the data that was encrypted with the DPK. Both vendors are blind to the fully decrypted request; only the customer has complete control. Customer-managed trust is achieved by this complete separation of powers.
Let me drive this point home with a brief comparison that will also address the tension with performance that my technical description might have raised. You may be familiar with customer-initiated, push-based methods like customer-managed encryption keys (CMEK) or bring your own key (BYOK). In these scenarios, you grant the CSP access to your key, generating the key through your CSP (CMEK), or pre-pushing it into the cloud until you take it away (BYOK). Your key material is distributed to a cloud service, which uses the key in any requests until you take that key away, probably to replace it with a new one. The point to remember is that once you’ve told the service it can use this key, it’s off and running.
Machina for EKM is an inline API pull, versus a pre-push, that takes place in under 150 milliseconds for high-performance responses. Google never sees the KEK, which functions like a master key to wrap/unwrap the DPK, rendering a just-in-time decision based on policy to grant or deny access. In this model, the cloud service asks your Machina instance “Can I have access to this data — or this table, image, or snapshot — within this project, under this context?” You have control over what the service can and can’t do, in real-time.
Machina Policy: Simpler Security for Complex Contexts
In this section, I’ll call out a few more integration-specific policy details before zooming out to look at the positive impact attribute-based access controls (ABAC) can have on your enterprise. Machina policy leverages ABAC to render policy decisions, which means you can evaluate the context of the user or service requesting access, the context of the data or resource in question, and the context of the request itself.
When configuring integration policy, the Machina EKM integration service user and the Google service user must both be allowed access to the KEK. Attributes about these service users are used in making policy decisions. If either are denied, then policy will ultimately deny access.
Besides the users and services, Machina policy considers the context of the data or resource in question. Each of the KEKs addressed by a unique URI in your Machina instance can be assigned multi-valued attributes. These attributes are generally used to describe what is protected by the combination of the DPK and KEK. Describing data will greatly increase your control and visibility into access transactions, as I’ll discuss in the next section.
Other contextual attributes are also used by Machina when rendering a policy decision. Environmental attributes can be used to allow or deny access based on current information about the request, such as time of day, version of the integration service, or whether the requesting IP falls within an approved range or within services allowed for that region.
These flexible controls uniquely position Machina to take action against Key Access Justifications; the more attributes you can provide, the more flexible your policy can be. Key Access Justifications represent the true context of the request, passed by Google to Machina as an Environmental Attribute. To Machina, this value is simply another attribute, natively supported by its attribute-based policy builder.
Key Access Justifications also simplify the process of gaining visibility into cloud services; you don’t have to tie cloud or event logs into each application or other systems handling access. Machina captures every access request, whether allowed or denied, in a central and easily-auditable location. You can access that information within Machina Console or export it to a SIEM or other system for additional correlation and alerting.
Let me next address the tension between simplifying security in the face of business environments that just keep growing in complexity. Most organizations rely on role-based access controls (RBAC) that only consider whether a user or service belongs to a particular role before granting access. This may suffice for 50-80% of your everyday operations — depending on industry and complexity — and Machina easily accommodates roles as just another set of attributes about a user or service. But RBAC does not handle edge cases or contextual scenarios well if at all, which represents substantial risk. You may have found yourself in the unenviable position of having more roles than actual users, or you may have decided to accept the risks of not being able to operationally maintain a role for every foreseeable scenario.
I’m here to tell you that it doesn’t have to be that way. Simple use of contextual policy reduces significant amounts of risk. I’ve seen this repeatedly with our customers, who tell me that with ABAC capabilities, they manage fewer policies in fewer places. By integrating Machina across complex landscapes, they exert consistent positive control over their data wherever it lives or travels.
Machina: A Single Plane of Control and Visibility Across Diverse Environments
Machina includes a number of components by default that enterprises often attempt to cobble together on their own, but they can only integrate a subset of these capabilities, usually confined to a few isolated silos. No other solution on the market today delivers a massively scalable key management system with a data attribute store, a highly flexible attribute-based policy engine capable of making just-in-time decisions, and an extensive set of SDKs and APIs to simplify consistent data handling in an integrated manner across a complex hybrid landscape.
I started this post with a technical overview of the encryption methodology and a comparison to BYOK models. Let me now spend a moment on what differentiates Machina from traditional key management services (KMS) and hardware security modules (HSMs).
While these options may offer on-prem and cloud coverage, they don’t scale well. An HSM, or HSM-backed cloud service, is designed to only work with one or two applications at a time. They don’t have the flexibility to tie in easily to other systems or applications, and they don’t offer a data attribute store or granular policy. What access controls they do offer are tied to the keys themselves, not the data that those keys protect. This is a subtle statement, but it has profound implications.
Without a data identity store, KMS and HSMs don’t know the individual identity of the data they are trying to protect. They may support key versioning, but they don’t understand and can’t adapt to policy changes or the latest regulation to come down the pike. To cope with a new privacy regulation that affects your data handling rules, you’d need to pull an existing key, issue new ones, add people into new groups or roles, and hook all of this up to token management. This is a stopgap. It doesn’t scale.
Instead of defining policies based on access to a key, with Machina I can describe my data using attributes and then use those attributes when writing policy. This policy is not just based on a single key-bound instance of the data, but it covers how that data should be handled across the board for every service and application that touches it. This is why attributes matter. Controlling access via key attributes and not the keys themselves is subtle, but it’s really important for people who care about regulatory compliance.
If you hard-code privacy, compliance, or other access control policy logic into your applications, you are signing up to continually modify that logic to address the next new applicable law or regulation. This will prevent you from building all the other innovations your business needs to thrive. If you haven’t heard, I’m pretty passionate about the way Machina contributes to a more sustainable enterprise architecture.
But getting back to the value of attribute-based policy, the more you describe your data, the more control you have and the more detailed your visibility and reporting. This is true if you are using Machina for EKM, and it’s true for data outside these services. Describe the data using attributes — whether it’s PII, Swiss financial, HR records, or pertaining to a special project — and use one policy to govern how that data should be handled, regardless of whether it’s being accessed inside or outside a Google service or on prem. You don’t have to use different systems for all of those contexts: The policy is independent of the key.
With attribute-based policy that can be enforced in real time against a data identity store, backed by an enterprise-grade key management system, and easily extendable by SDKs and APIs, Machina brings a single plane of control and visibility to even the most complicated and siloed environments.
Through a technical overview of Machina for EKM that highlights the benefits of attribute-based policy, along with comparisons to other methods, I’ve illustrated how Machina resolves tensions between competing needs: a separation of powers with high performance, simpler security for complex contexts, and a single plane of control and visibility across diverse environments.
The true separation of powers inherent in Machina for EKM helps you achieve this customer-managed trust in the cloud. Machina for EKM is available for Google services like BigQuery, Compute Engine, Kubernetes Engine, and Cloud SQL. You can learn more or purchase directly from the Google Marketplace. And because Machina easily extends these capabilities to all your applications, whether they’re in the cloud or not, you’ll be taking a large step toward simplifying your enterprise architecture with consistent control and visibility. Contact Ionic for more information.