A Practical Approach to Just-in-Time (JIT) Access for Developers

You're the DBA or maybe the Sysadmin at your company. Whatever your title, you’re the gatekeeper and the key master for your company's database servers.

You stay awake at night wondering if you’ve done everything you can to safeguard your database systems. But all those application developers need, errr want, access to production databases and servers. Whether it's relational databases like Oracle, SQL Server or PostgreSQL, a NoSQL document store, or key-value stores, you likely have sensitive data stored on your database systems.

Should Devs Be Granted Access?

Should application developers have access to production database systems? This is a question as old as Vampires and Werewolves. If you’re an application developer then you can’t work with one hand tied behind your back by having system access restricted. But how will you debug data issues without being able to run ad-hoc queries against your production database? The development environment is great for debugging the web applications and other backend pieces but it's not as helpful when you're trying to debug data issues. On the other hand the DBAs and Sysadmins have a sworn duty to protect the database servers and systems at all costs. They can't just hand out access to whoever wants it.

We won’t debate the philosophical here. For now we’ll assume that the decision has been made that developers should have some type of access to production database systems. You’ll have to decide how much access is the right amount. This will depend on your company’s policy and culture. But what we can do is look at how to give them access in a secure and timely manner without adding extra work in managing their access.

⚠️ Traditional PAM deployments have gaps. Learn how to protect your databases, the cloud, Kubernetes, and more with our legacy PAM augmentation guide.

What Is Appropriate Access?

At some point as a DBA, you will have to come to the realization that developers will need access to their application’s database(s) in order to effectively debug their issues and validate data integrity. Most of us would agree that read-only access would be sufficient for your average dev. But do they need "always on" data access? After the initial application development is done and it has been deployed to production, there is a period of monitoring and adjustment where a developer may need to look at the database in real-time, but that period should be relatively short-lived and direct data access should be fairly limited after that. After this period, the developer should use other development tools like your ELK stack for ongoing application monitoring.

We’re always told to rotate our passwords to be more secure but no one seems to mind if access to database systems goes unused for weeks or months at a time. When you have users that only need infrequent access to a database or server, you end up keeping idle accounts provisioned and potential attack vectors open. Database professionals, this is the stuff that keeps you up at night. Someone could have left their laptop in an Uber with all of your company’s sensitive data there for the taking. You would probably be sleeping a lot better if you knew that users’ accounts had been automatically deprovisioned today and access to your backend database systems had automatically been revoked.

What if there was a way to give developers access exactly when they needed and for exactly how long they need it for? What if they could have this access in a timely manner that was revoked at the end of each day?

Just-In-Time Access

Just-In-Time Access empowers organizations to grant temporary access to systems such as instances and applications for a fixed duration of time on an as-needed basis.

Giving devs a least privileged role is how they are typically given access to the production environment. This is a solid approach but many times developers only need to briefly access a production database system and run a few ad-hoc queries to troubleshoot the current bug. For large organizations, administering access is a full-time job. In an agile world, people move teams and switch to different projects seemingly on an hourly basis. This can lead to a lot of churn in access management to your backend database systems.

A better approach for handling access to database systems would be to allow your application developers to provision their own access and have it revoked with no extra work on your end. Before you start screaming at the monitor, let me explain. Let’s give developers the access they need when they need it for exactly as long as they need it and then automatically deprovision it. With the right data access controls in place (read-only access), a dev could grant themselves temporary access to certain database applications to debug issues and you can sleep easy knowing that the access will be automatically deprovisioned at a preset interval of your choosing.

We can allow developers real-time access provisioning using StrongDM and your favorite chatbot. With StrongDM’s Hubot integration you can let your application developers provision their access when they need it while still maintaining control (and compliance) over what database systems they can access and for how long.

💬 Did you know, StrongDM now has a Slack app? 

Connect the StrongDM Slack app to your Slack workspace through the integrations page in StrongDM. All steps are covered in the documentation here.

Now, your developers are empowered to grant themselves temporary access to the database systems they need. And you can rest assured that at the end of their allotted time, StrongDM will deprovision their access returning the user to their normal state.

Self-service data access does come with risks, such as unauthorized access, and adherence to compliance policies. But these risks can be mitigated by a data governance program and auditing features built into a tool like StrongDM. Setting up real-time access with the right safeguards in place will let application developers have the tools they need to do their job and reduce the overhead on DBAs of constantly provisioning and deprovisioning access. Allowing DBAs to do what they do best - database development.

Learn more about how StrongDM helps organizations with an enterprise-ready just-in-time access solution.