Inevitably all systems have service accounts from Administrator on Windows, to root on Linux, and sa on legacy databases. Service accounts are a necessary part of doing business, but the goal needs to be that no humans (authorized or malicious) have access to any credential which is not their own.
For most systems we’ve solved the “no shared credentials” problem, but many organizations continue to use shared or service accounts for access to databases due to their lack of user federation with a centralized directory service.
Adding further pain, while many databases have tried to solve the user federation issue, support is different across each platform, and still often requires database level grants placing it in the too-hard basket. This often results in data teams running their queries as a generic analyst user, or SRE’s using a generic admin account, anything else creates work for whoever is managing the database for all joiner, mover, leaver (JML) activities. This problem is further compounded by many business intelligence (BI) tools like Looker and Tableau which are often configured to run queries for all users using a single account, and that account having privileges to all possible data within the database which may be needed by any user.
This end result is over permissioned accounts, a reliance on application based controls for who can access which report, exposure of the entire dataset to report developers, and makes it almost impossible to attribute queries run against the database to an end user without trying to correlate log events. As the number of users increases the problem becomes exponentially harder to solve.
The first step to tackling this is either federating user access to the organization’s central directory. Depending on the database engine, there are a number of point solutions: Microsoft Integrated Authentication for MS SQL Server, pam authentication for MariaDB, ldap for PostgreSQL, mongodb, and Oracle. Depending on the integration, they need to be managed separately, and in many cases just offload password verification to the directory service, v’s inferring database privileges from the directory. In the case of MS SQL Server, some workloads still require the user of local (non-AD) database users, which requires their lifecycle, privileges and passwords to be individually managed. For AWS RDS, Amazon have enabled a number of federated options, however these typically rely on the end user mapping to an AWS user or role, and impose their own constraints.
As team members change roles, determining if an individual user’s database login should be changed, and if so, how, becomes another administrative nightmare. Most teams will default to leaving existing access in-place, and just add additional grants at the database object level which can’t be tracked or easily inferred from their account in the centralized directory service. Over time this leads to users having excess privileges, and makes it hard to narrow down where information may have been accessed during a security incident or investigation.
If the organization is subject to audits of their IT process (ITGC), teams are either left manually managing users, passwords, and privileges often with spreadsheets, or building homegrown automation which can be hard to scale or maintain as staffing changes. Some organizations have taken to using Hasicorp Vault or legacy PAM solutions to checkout database credentials, but the user friction is too high for regular users, so is typically reserved for privileged accounts, and invariably leads back to shared user/service accounts being used with limited visibility. Again, organizations need to come up with homegrown solutions to solve the visibility and auditing needs of their auditors or regulations they’re subjected to.
These challenges are what led to the founding of Cyral: remove the pain of database user and rights management, provide full visibility into user activity (DAM), and allow context aware policies to block or mask access to data in real-time.