RDS is clearly a very popular AWS offering, and there has been a 40% year-over-year growth in Stack Overflow traffic for RDS-related topics. At its core It is a managed database service that simplifies setup, operation, and scaling of relational databases. Because it houses some of the most sensitive data for the organization, securing access to it becomes an important topic.
In an attempt to modernize authentication for RDS, AWS created the ability to authenticate to RDS databases by federating authentication with AWS IAM. It utilizes an AuthenticationPlugin to associate a user on the database to an AWS IAM role.This reduces the risks of setting and managing database passwords which creates numerous security challenges:
- Passwords have long been acknowledged as an ineffective security control due to password reuse and guessability of typical user passwords.
- It is generally easy for an RDS instance to be accessible from the internet, both inadvertently and intentionally, which makes it easy for attackers to leverage compromised passwords.
- Even with the most securely provisioned databases, once attackers have established a beachhead they can conduct a rapid brute force attack on database passwords, giving security teams essentially no time to catch the incident. This is possible because databases lack native throttling controls.
AWS IAM RDS authentication addresses the challenges above by replacing passwords with a short lived (15 minute) token that is used when connecting to a database, generated using the AWS CLI. By leveraging existing IAM users and policies, managing database access becomes easier and more scalable, reducing administrative overhead and simplifying user onboarding and offboarding.
While IAM authentication is a big improvement on using database passwords, it still falls short.
Most security frameworks that are based on the principle of least privilege and/or Zero Trust, require authentication to be augmented with other controls which act to further verify and repudiate the identity of any user that needs to access a service. For instance, the AAA security model, a widely utilized framework for network access control, acts as a three-stage gatekeeper, first verifying user identities, then determining the permitted actions based on that identity, and finally logging their activity for auditing, again ensuring that only authorized individuals can access and interact with secure resources. IAM authentication falls short of these requirements. The reason is:
- Authorization for exercising various privileges within the database itself is still tied to database roles, and doesn’t inherit from IAM. This makes managing entitlements highly convoluted and exposes databases to basic threats. E.g., it is very difficult to ensure that privileged users cannot drop tables or update protected data.
- Activity logs, which by themselves are extremely resource intensive to generate, lack the necessary information for meeting common compliance requirements and enabling easy forensics because identity is not federated together across the actions that are performed inside the database. E.g., any action is performed by an IAM role assumed by a user, which is given an ephemeral database account which then exercises privileges based on local database roles to issue a command – stitching all these disparate identities is cumbersome.
Additionally, there are several practical challenges and limitations with IAM authentication that do make it difficult for it to scale for large organizations:
- Most organizations use aliases for their RDS databases to make them easier for users to connect to, however AWS RDS IAM does not support requesting tokens in this manner.
- The RDS IAM token is valid only for 15 minutes. This also presents a usability issue for users that may want to use database tools which dynamically establish multiple connections for queries, such as Datagrip.
- Using IAM authentication requires users to be familiar with the AWS command line and proves unwieldy for users without development experience.
- RDS IAM authentication has to be selectively enabled, which is generally an inconvenience for both engineers and users when deploying new databases.
- Currently, as of Feb 2024, AWS recommends you only use “IAM database authentication when your application requires fewer than 200 new IAM database authentication connections per second”, which is seen as a significantly limiting factor for enterprises. ( https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAMDBAuth.html)
- Certain highly regulated organizations prevent the use of copy-paste in their environments to prevent data breach. This makes it effectively impossible to use the RDS IAM tokens which are generally about 1KB and comprise thousands of characters.
- This above point not only is an inconvenience for users, but also sometimes shows up as a show stopper for certain old database drivers which assume limits on the length of credentials that can be supplied during authentication.
Given the increasing arms race between defenders and bad actors, most organizations understand the need to continue investing in their least privilege model., Now, especially with the recent SEC rule (S-K 106) requiring companies to publicly disclose cybersecurity events, implementing tooling which provides detailed logging of sensitive data accessed is becoming critical. As such, any database security investment needs to properly couple authentication with authorization and logging.
All the reasons above make IAM authentication for RDS practically a poor choice for companies dealing with sensitive data. While it is a good short-term solution for smaller teams, the overhead and risk imposed by its limitations grow very quickly as the teams and their workloads scale.
Cyral brings identity federation, observability, and granular access controls to databases.
Cyral uses a token based approach which preserves existing database access workflows for both technical and non-technical users, while providing a seamless and scalable identity federation solution. . Cyral provides configurable token lifetime, approval workflow management and eliminates the need to have user principals defined in the database. Additionally, all authorization policies can now be tied to user identity regardless of the database role or account, and detailed activity logs can be obtained that are enriched with user information and session context.
