Using Temporary Credentials for Production Database Security

Production data can include sensitive data that needs to be carefully protected. The more users have access to your data, the higher the risk of sensitive data exposure and breaches of compliance. This can leave enterprises in a bind: on one hand, you want to keep data access to a minimum. On the other hand, sometimes it’s vital to grant access to engineers and analysts so that they can investigate issues and fix bugs. 

The best approach is to generate temporary credentials, which give access to data on a need-to-know basis. In this article, we will discuss temporary credentials and how they ensure data security and compliance. 

Temporary credentials do what they say on the tin: they work to grant access to data for a limited time. Depending on your security protocols and the engineer or analyst’s needs, you can configure them for a few minutes, hours, or days. With temporary credentials, you can avoid instances of over-privilege, where employees have access to data that they don’t necessarily need and create potential data security risks. 

Security professionals have a lot on their plates, so it’s easy to lose track of who has been granted access because of a temporary need. There’s a high chance that individuals will retain access to sensitive data after their project or need is complete. Employees could change roles, fall victim to social engineering attacks, or leave the organization entirely, all while holding unnecessary permissions. This vastly increases the risk of a data breach. 

For example, a former employee at the mobile payment service Cash App still held the same access permissions after her termination in December 2021. She used her privilege to download and reveal the personal data of over 8 million Cash App customers, resulting in a mass class-action lawsuit that will cost Cash App and its parent company Block millions of dollars. 

Manually provisioning data access is time-consuming and tedious. Not only is this irritating for security teams, but it also means that they might forget to remove access when it’s no longer needed. Using an automated process to provision temporary credentials means that access is revoked automatically, which reduces exposure from excessive permissions. 

Additionally, an automated system for just-in-time (JIT) data access makes it easy to adapt access according to more factors than simply time, like a set number of queries or data views. It dynamically adjusts permissions as user roles and business needs change, always following the principle of least privilege. This helps close potential gaps in operational data security and prevent blind spots. 

When you use a just-in-time data access solution like Satori, engineers and analysts don’t waste time waiting for authorization. It can take days, or sometimes even weeks, for overstretched security teams to approve their request for access, which creates harmful delays in investigations. 

Fast, streamlined temporary credentials facilitate the flow of data around the organization, allowing engineers and analysts to quickly request and receive access. This way, engineers don’t hesitate to ask for access, instead of trying to complete their work with incomplete data or looking for workarounds.

Satori has two processes for generating temporary credentials. Its just-in-time (JIT) access model generates new temp credentials for a single sign-on (SSO) session, and revokes them as soon as the conditions expire. 

The JIT process follows this workflow:

1. The user requests access to specific data for a particular business need. Requests are logged through ticketing systems.
2. The requestor validates the user’s identity, role, and rationale. 
3. The designated approver reviews the request details and decides whether to approve or deny it according to policy rules like user attributes, data classification, and justification.
4. If approved, temporary credentials are generated. 

Recently, Satori released an open-source Rust-based CLI that automatically generates temporary credentials for individual users for certain data stores, such as Snowflake, Postgres, and Redshift. The CLI simplifies and speeds up the process of managing users or configuring SSO. The process is as follows:

1. satori login –display: Asks the engineer to authenticate, and gives them temp credentials.
2. satori run <psql/dbt/mongosh/s3 <Datastore name> [database]: If the user has already performed satori login with psql or the credentials are still valid, this invokes the tool without the need to perform authentication. Otherwise, it requires the user to authenticate and then starts the SSO login flow.
3. satori pgpass: Allows users to use Satori CLI with DataGrip, or any other tool that supports pgpass, to get credentials with login if needed.
4. satori aws: Generates credentials for AWS services.

Satori’s JIT temporary credentials solutions address a number of different potential compliance issues in granting access to production databases. 

• Limited exposure from excessive permissions. Satori automatically revokes access once the conditions are no longer met, whether they are time-bound or usage-bound.
• Improved transparency and accountability around access requests, approvals and denials. The system logs every access request and response.
• Greater visibility into who is using data and how, because all usage sessions are logged and the rationale for every access request is recorded and stored. 
• Compliance with regulations like HIPAA and GDPR, which require that temporary permissions automatically expire at the end of the set time period, or when the user’s status changes. 
• Stronger audit trails which enable improved demonstration of regulatory compliance, thanks to automatic data logging for every access request. 
• Robust enforcement of least privilege because the principle is baked into the system, ensuring that users gain the minimum access level required for their needs.

Using Satori’s automated temp credentials solution removes any bottlenecks from the process. Engineers, analysts, and AI teams don’t have to wait for someone to review their request and manually generate a temp password. Instead, they receive permissions close to instantly, allowing them to ,quickly and easily gain access to the data they need to resolve any issues. 

What’s more, there’s no need for clumsy copying and pasting credentials from one system to another. With Satori’s CLI, data arrives at their digital door swiftly, without friction, and in a pattern that’s already familiar to them from other data tools. 

Consider ACME, a company that has a production database in PostgreSQL. ACME wants to implement a breakglass protocol to give selected engineers full access to their Postgres environment, so they’ll be able to fix production issues under a supervised protocol. For this, they want to grant engineers who are currently on call the ability to get temporary, self-service access to the database for 2 hours at a time.

Satori Authentication allows users to instantly generate temporary credentials to secure databases. In Satori, administrators can customize the expiration time of temporary credentials for different users and groups.

Admins can also set access policies based on roles, geographical location, or any other attributes. For example, at ACME, everyone has self-service, read-only access to this particular data set, for 4 hours at a time. This means every Satori user in the company can request, and instantly receive read-only access to the data set, for 4 hours at a time. Since Mike needs to make changes to the data when he’s on-call, the administrator has set a policy to give all engineers tagged ‘on call’ full access to the data set for 2 hours, as soon as they request it. Admins can also set one or more approvers for access requests if needed. Approving the access request takes seconds, and can be done via the data portal or with our Slack integration.

In order to fix the production issue, Mike doesn’t actually need to see all customer PII in the database. In Satori, it’s easy to set a dynamic masking policy that applies to the on-call group. Admins can set custom masking policies, or use the default policies that come out of the box with Satori: permissive for users who need some PII access, restrictive for users who don’t need to see PII for their functions, and analytics for analytics teams who need to retain statistical data characteristics while protecting PII.

At 3am, Mike, who’s an engineer currently on call, needs to get access to the Postgres environment temporarily to fix the production issue.

First, he goes into his personal data portal, which shows which data stores he has access to and which ones he doesn’t (yet). 

Mike needs access to the Life Insurance Records Postgres database. He presses the Ask for Access to Dataset button, which opens a form for him to include details on the access request.

Depending on Mike’s attributes, he may be able to choose between multiple access request types and purposes. Since he chose a self-service access policy with no required approvers, Mike’s request is automatically approved. He can immediately access the chosen database from the My Data section in the portal, for the next two hours.

Now that he has access to the PostgreSQL environment, he can generate temporary credentials (using the key button in the upper left corner) and use them to log in to the Postgres database.

In a perfect world, databases would never have problems in production and engineers would never need to be on call in the wee hours of the morning. But until we get there, a solid system for administrating temporary credentials can make the process a whole lot smoother. Without it, engineers might have to wait for manual approvals in order to fix potentially critical database issues in production. Moreover, the company risks engineers having elevated access to sensitive PII or PHI, which could lead to security or compliance implications. With Satori’s just-in-time access control, admins can set policies for temporary, self-service access to specific data sets, for specific groups, which update automatically as users and roles change. To learn more about temporary access to data with Satori, schedule a demo with our team.