Database-level Isolation
Database-level isolation is a critical aspect of multi-tenancy, ensuring that tenants cannot access or interfere with each other’s stored data. Most common database engines in AWS offer a variety of features that support fine-grained access control to achieve this level of security in a shared database environment.
DynamoDB tables
In Amazon DynamoDB, fine-grained access control is a powerful feature that allows for row-level security (RLS). By leveraging IAM, you can natively create policies that restrict access to individual items and attributes within a table. This is particularly useful for isolating data based on attributes such as tenant IDs. For example, you could set up a policy that allows a user to only access and modify records related to its associated tenant within a multi-tenant table. This ensures that each tenant’s data remains logically isolated within the same table, even if the table itself is shared among multiple tenants.
The IAM policies can be as specific as needed, allowing for complex scenarios. For instance, you could restrict a user’s access to only certain attributes of an item, such as viewing their account balance but not their transaction history. This level of granularity is invaluable for maintaining strict access controls in a multi-tenant environment.
RDS databases
Implementing fine-grained access control and data isolation in Amazon RDS databases is generally more complex than in DynamoDB. This complexity often arises from the need to leverage the specific capabilities offered by the database engine itself, alongside AWS IAM for identity and permissions. Let’s dive into the specifics of each database engine:
- PostgreSQL: PostgreSQL is notable for its robust support of RLS, a feature that enables the definition of access controls at the individual row level within a database table. In PostgreSQL, RLS policies can be set up to specify which rows can be accessed, modified, or deleted on a per-user basis. IAM roles can be used for authentication, and these IAM identities can then be mapped to PostgreSQL users, allowing for a seamless transition from AWS-level to database-level access control.
- SQL Server: Microsoft SQL Server also supports RLS, which allows you to control access to rows based on group membership or the specific conditions under which a query is executed. IAM roles can be used for authentication to the RDS SQL Server instance. Once authenticated, SQL Server’s internal mechanisms enforce RLS based on the IAM identity.
- MySQL: MySQL does not natively support RLS within tables. However, a workaround is available: you can create views using the MySQL CREATE VIEW statement and define conditions for row visibility. Access can then be granted solely to these views. IAM roles can be used for authentication to the RDS MySQL instance, and once connected, users can be restricted to specific views, thereby achieving a form of row-level isolation.
- Oracle: For Oracle databases on RDS, Oracle Label Security is available in the Enterprise Edition. Unlike traditional database security, which operates at the object level, Oracle Label Security provides fine-grained control down to the level of individual table rows. This makes it a strong choice for Oracle environments that require detailed access controls.
- MariaDB: MariaDB lacks native support for RLS. In such cases, RLS can be emulated at the application layer. This approach, while functional, could introduce additional points of failure or misconfiguration and is heavily reliant on the application’s correct enforcement of these controls, posing a risk if the application has vulnerabilities.
- Aurora: Amazon Aurora does not have native support for RLS but offers alternative mechanisms for data isolation. Specifically, you can grant users the privilege to query specific tables or schemas. While not as granular as true RLS, this method does provide a level of data isolation. IAM roles can be used for authentication to the Aurora instance, and once authenticated, Aurora’s internal access controls, separate from IAM, can be applied to further restrict table or schema access based on the authenticated IAM identity.