<img src="https://ws.zoominfo.com/pixel/6169bf9791429100154fc0a2" width="1" height="1" style="display: none;">

Struggling to implement least privilege in your organization? Join StrongDM featuring Forrester for this upcoming webinar. Register now!

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 called AccessBot

First, we need to install the StrongDM binary into the Hubot directory. Then create an admin token and give it grant permissions.

There are two environment variables that need to be set in Hubot like so set SDM_HOME=/app and set SDM_ADMIN_TOKEN=[admin token here].

Finally, add your just-in-time StrongDM script to scripts/ and Hubot is ready to give provision your developer's access.

module.exports = (robot) ->
robot.hear /access to (.*)/i, (res) ->
target = res.match[1]
email = res.envelope.user.email_address
res.reply "Granting #{email} access to '#{target}' for 1 hour"
spawn('SDM', ['admin','users','grant-temporary','-d','1h',target,email])

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.

StrongDM logo
💙 this post?
Then get all that StrongDM goodness, right in your inbox.

You May Also Like

Vault Sprawl: How To Manage Multiple Secret Vaults
Addressing Vault Sprawl: How To Manage Multiple Secret Vaults
Secret vaults ensure that sensitive and privileged credentials are well protected, rotated, and only used–or checked out–when necessary. This makes them a critical and foundational tool for credential protection in modern infrastructures.
Top 3 Least Privilege Risks (And How to Address Them)
3 Reasons Why Least Privilege Has Failed
The inability to audit, track, and understand how permissions are being used (or if they’re used at all) has been non-existent. Until now. The findings are clear: organizations need visibility into privileged access and its usage to fully understand and address their total attack surface.
Augmenting Legacy PAM with StrongDM: Getting to Dynamic Access
We constantly hear about the gender gap in technology. Whether it’s the shortage of female founders and CEOs, claims of discrimination, or the comparatively small number of women in computer science majors, it seems that the issue has become a regular feature story in the news cycle. Disagreement over how to respond abounds on social media, in editorials, and not infrequently within tech companies themselves.
Service Accounts: Definition, Best Practices, Security, and More
Service Accounts: Definition, Best Practices, Security, and More
Is your organization overwhelmed by rampant service account sprawl? Rest assured, you can regain control. Modern Privileged Account Management (PAM) tools and practices empower you to overcome the challenges of unchecked service accounts. The information in this article will help you understand the meaning of service accounts, so you can manage your organization’s service accounts more effectively and mitigate their risks. Robust security is attainable for all your privileged accounts.
PAM Pricing Simplified: Your Cost and ROI Explained
PAM Pricing Simplified: Your Cost and ROI Explained
The cost of a privileged access management (PAM) solution goes beyond the licensing fees. While it’s tempting to look only at the initial costs, evaluating privileged access management pricing includes examining other factors to determine whether the solution will provide a real Return on Investment (ROI) or cause more problems than it solves.