Today’s combination of database authentication and network-based access control mechanisms are inadequate for implementing complex security models required by modern multi-tenant data services. It’s difficult, if not impossible, to configure many databases to authenticate users and applications based on not just the account credentials but also other attributes, such as their client IP addresses or subnet CIDRs.
The security model that databases need
Imagine a multi-tenant data service hosted on the cloud. The service stores data belonging to various tenants, and allows them to consume it using their own tools and applications. Figure 1 illustrates architectural details of such a service, the data paths tenants use for consumption, and the management paths the service owners use for its administration.
Figure 1: Multi-tenant Data Service Architecture
It’s important to note the following properties of this architecture:
- Database instances (servers) may host data belonging to multiple tenants (illustrated using Ts in the figure). If so, the multi-tenancy model leverages database schemas to isolate tenant data. Thus, each tenant gets a unique schema that is tied to a unique database account. Tenants access data by connecting to the associated database account using credentials only known to them.
- Within each tenant, users may connect to the database using native database tools, BI tools, or custom applications running in the tenant’s own environment (a data center or a cloud VPC).
- Lastly, the group of administrators managing the data service have access to both the infrastructure as well as the hosted data for ongoing maintenance.
What would the security model for a service like this look like?
- The most obvious requirement is that a tenant’s users and applications must never be able to access other tenants’ data.
- A further requirement would be that each tenant’s data access requests must originate from known network locations, specified using allowed / disallowed lists of CIDR ranges or IP addresses. This makes sense because tenants are operating within their own corporate environments, whose network locations are fixed, be it a data center or a cloud VPC. Hence, data access requests for the tenant can be expected to originate only from those fixed locations, and nowhere else.
- Lastly, administrators (i.e., data service owners) who need access to the database instances for maintenance purposes must be on the corporate network in order to do so. In some cases, subgroups of administrators may be responsible for certain tenants, and the security model must be able to accommodate for that.
In other words, what’s required is the ability to examine a data access request’s network location while making authentication and access control decisions in the database.
This, however, is a fundamental access control limitation in databases. A few modern databases like Snowflake support this capability in the form of Network Policies but most operational databases like MySQL, PostgreSQL, and SQL*Server do not.
Consequently, it’s either kludgy or impossible to implement even moderately complex security models like the one described!
The security model that databases get
So, how do architects and developers work around this problem today?
Typically, they compensate for these inadequacies by resorting to using VPN devices, network firewall rules, and cloud network security groups, in order to enforce checks on network locations of the users and applications making data access requests. While these workarounds function at a somewhat coarse-grained manner, they come with a number of implementation challenges of their own!
VPN devices are old technology, and are expensive, hard to deploy, and manage. They become an even poorer fit in complex multi-tenant scenarios.
Cloud security group rules, similar to firewall rules, must be configured outside the database, thus decentralizing access control from an administrative perspective. This makes maintenance difficult, since access control policies must be defined in multiple places now i.e., both inside the database and in the cloud provider.
Most importantly, both VPNs and security group rules are just network-layer controls and cannot be extended to the database layer. For example, it’s not possible to write a policy that enforces that tenant acme can only access data within a database instance’s acme schema, and that too, when the requests originate from the 10.28.xxx.xxx CIDR range. This is because database authentication mechanisms can only examine and verify the database account credentials presented by a client but not the CIDR range / IP address where it’s running.
For these reasons, currently there aren’t any easy-to-use tools for administrators to faithfully replicate their desired security models in their implementations, and govern access centrally across all of their tenants, users and applications!
The security model that databases deserve
At Cyral, we have been working on simplifying these problems, and today we are very excited to announce the general availability of Network Shield!
Network Shield allows administrators to specify granular authentication and access control policies to govern which network locations data requests can originate from, and which database instances or schemas they can access.
Check out our product announcement for details on how to enable this capability, and for examples of the kind of policies you can start writing for your own services and applications!
