The State of Security at Delphix

Security is consistently ranked as one of the top concerns of our customers. Sometimes, it’s even the gatekeeper for teams to adopt Delphix, the warden to keep your data safe, and the bridge builder to your existing enterprise systems. Security is paramount to us, and we incorporate the industry standard practices of identification, authentication, authorization, and auditing for each control we build into our platform. In this post, I discuss strategy, existing features for you to adopt now, and what’s on the horizon.

Identity: How Delphix Identifies You

Identity is the foundation on which we build security at Delphix. Previously, Delphix has built user-based security controls around engine-specific user names, which, for small deployments can be fine. But for a larger, enterprise-wide application, this approach leaves many pitfalls, such as high administrative overhead, localized control, lack of additional security controls.

In 5.3.3, we added SAML 2.0 support, enabling Delphix to connect to enterprise identity providers (IdP)—an industry standard for driving user-based identity and authentication. By integrating with IdPs, Delphix adopts common standards like multi-factor authentication that can be established by InfoSec teams.

Within the Delphix product, this creates a shift from using user names, as the mode of establishing who you are, to your email address, which is how identity is established within most IdPs. This practice is foundational as we authenticate human connections via Single Sign On (SSO), generate API keys tied to a user email (to establish accountability) for machine authentication, and tie all actions across all Delphix engines to the associated email. This standard propagates uniformly across all of your engines—reducing administrative overhead—and provides the foundation we need to build best-in-class security.

Authentication: How You Prove Your Identity to Delphix

Now with identity squared away, let’s dive into the security controls we’ve built for authentication. At Delphix, we think about authentication in three buckets: human (users), machine (APIs and automation), and infrastructure (databases and operating systems). We look at each experience by examining industry trends (e.g. what does it take to offer a “passwordless” Delphix experience?), prevalence of the specific controls we introduce (e.g. password vaults are growing in popularity and more often being mandated by InfoSec policies), and the flexibility in the experience we can deliver.

Below is an overview of recent functionality that we’ve delivered to enhance how Delphix authenticates connections and get out of the business of manual and less secure passwords.

1. Human (User) Authentication via SSO Support

In 5.3.3, we introduced SAML 2.0 support, which enables SSO access via your identity provider (IdP) of choice. Single sign-on via SAML2 has quickly become the de facto authentication strategy, supplanting things like username/password and LDAP or AD. In addition to per-engine SSO support, it is also a prerequisite for Data Control Tower (formerly known as Central Management).

This enhancement not only ties human identity to an identity provider (IdP), but allows enterprise security teams to build in additional controls for user authentication, like two-factor authentication.

2. Machine Authentication via API Keys

Delphix is API-first and we want to provide an optimal security experience for our API-centric customers—whether it’s integrating our platform into a CI/CD pipeline or simply using an orchestration point of choice. That’s why we introduced API keys via Data Control Tower. DCT users can generate API keys to integrate into their virtualization and masking scripts. We also provide key rotation to assist with InfoSec policies.

API keys build in a new level of security for scripting and automation workflows by shifting to a token-based authentication system from the less secure username and password. All keys are tied to the user email that generated them, and each key can be rotated to maintain token lifecycle standards.

3. Infrastructure Authentication (OS/DB connections)

We recently introduced password vault support to remove the need for operating system and DB username/password-based credentials for adding environments and linking dSources. As of 6.0.4, we support both CyberArk and HashiCorp Vaults for all supported Unix/Linux/Windows operating systems, plus Oracle, SQL Server, and SAP ASE for database authentication. We will be extending coverage to the rest of the Delphix-supported DB portfolio (Db2, HANA, Postgres, and EBS) in subsequent releases. Masking support for DB-based authentication will soon be added as well.

Note: A common use case for this is to rotate your credentials inside of the password vault on a regular basis. Delphix won’t see the credentials. Every new operation requiring the authentication step requires Delphix to establish a new session to the password vault and to retrieve the credential at that time for use. We do not store any infrastructure passwords on the Delphix Engine.

This is the quickest time-to-value for most teams looking to shift away from manual usernames and passwords. Many of our customers already have a password vault team within their enterprise that sets policies and provides vaults as a service. The good news is that the Delphix implementation readily fits most enterprise vault requirements. Switching to this standard is a matter of configuring a Delphix vault or directory, placing your infrastructure credentials inside, and registering the vault and credential string inside the platform.

We recognize that for many organizations, there’s a strong push to go completely passwordless, which generally means there’s a mandate to go to a token-based system. One standard that we have adopted for all of our OS-level support and are building out for all database authentication is Kerberos.

While this requires additional infrastructure to implement a Kerberos system, this standard does away with passwords, which represents an additional level of security.

Authorization: What Users are Allowed to Access in Delphix

1. User-based Authorization

With the GA of Data Control Tower, Delphix introduced a central point of control that can be extended to numerous areas of the Delphix experience by way of setting global policies. User-based access administration—now available—is the first step in a long line of enhancements.

This August, we released our complete overhaul of user-based data control via data access groups available with Data Control Tower. In essence, it’s a shift from engine-based user registration, data access management, and user access permissions setting to a global, enterprise-wide approach. Data Control Tower provides specified groups over a set of data that can span multiple engines and assigns granular permissions for each data object (dSource, VDB). From an administrative standpoint, this completely streamlines day-to-day user access.

Customers often have user management systems within the enterprise in the form of an Active Directory or LDAP directory service. The request to be able to tie into those systems as a means of defining access within Delphix has been one of the most frequently requested enhancements. The good news is that this is LIVE and is available via DCT by way of IdP attribute mapping.

What this means is that if you have your AD or LDAP service connected to your IdP, we can import AD groups as IdP attributes and use those for determining access group membership. This drives value for you in that any changes made to relevant users in your AD/LDAP directory will automatically be reflected in Delphix (with Data Control Tower).

In the case below, we examine how this would work for two application teams. In the below figure, the AD attribute is mapped to the customer IdP that is then pushed to Data Control Tower Access Groups.

Note: Active Directory and Okta are just examples of systems that Delphix interfaces with—any system that supports SAML 2.0 is supported for this workflow.

It’s not uncommon for developers to move teams, which necessitates granting and revoking access to relevant data in Delphix. Normally, this would be a manual step. However, in Data Control Tower, this is automatic as long as the change is reflected in AD/LDAP.

Note: Masking support for data access groups is planned for 2021. It will have a similar experience but will focus on masking objects like environments.

2. Write-to-Environment Authorization

A common worry with application teams that bring their own target infrastructure (servers, storage, and associated OS licenses) to a shared engine is the potential for a different team provisioning VDBs onto their target hosts. As of 6.0.5, we have introduced functionality on the virtualization engine to enable an engine-wide lockdown of target environments, coupled with the ability to attribute VDB provision permissions on specific environments to user groups. This prevents one team from accidentally provisioning VDBs to another team’s infrastructure. The UI will be introduced in the Data Control Tower at a later date.

3. Admin Privileges Authorization

We are also building a subsetted admin control group into Data Control Tower that will allow for a more granular selection of admin-like privileges (e.g. add environment, view performance metrics, set policies). We recognize that not every organization has the same admin-to-application team relationships for which we built our engine-based administrative model. Instead, this enhancement is aimed at providing flexibility around the application team experience and to empower them to perform admin-tasks (if it makes sense for your organization).

Audit: Driving Accountability Throughout Delphix

The final element of security we are heavily investing in is the audit capability of Delphix usage among customers. Yet again, since Data Control Tower spans a Delphix deployment, it is the logical point of introducing this set of security audit enhancements.

Universal User Actions Audit Log

Data Control Tower audit log is a live feature that tracks and exports all of the actions that are being done within Data Control Tower. The future vision for this feature is to extend it to cover all actions taking place across all connected Delphix engines.

Conclusion

Security around connections to Delphix is just the tip of the iceberg. And this is only a snapshot of the work focusing on securing connections to and from Delphix, ultimately leading to a secure, scalable, and rich experience. There is no solution for security that is a one-size fits all. If your InfoSec policy requires something special—reach out, let’s have a conversation, and we can work together to make sure that you are covered. In future posts, we’ll cover security measures such as extending our reporting capabilities via DCT APIs to datasource-specific security enhancements to name a few—stay tuned!