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

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.

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

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.
Privilege Elevation and Delegation Management (PEDM) Explained
Privilege Elevation and Delegation Management (PEDM) Explained
In this article, we’ll explore Privileged Elevation and Delegation Management (PEDM). You’ll learn how PEDM works and how it mitigates the risks associated with poorly managed privileged accounts. By the end of this article, you’ll understand why PEDM is an important security strategy and how businesses can use PEDM to manage privileged access and prevent cyberattacks.
Zero Standing Privileges (ZSP): Everything You Need to Know
What Are Zero Standing Privileges (ZSP)? (And How They Work)
Securing sensitive company data starts with limiting who can access that data, and adopting a zero standing privileges security approach is a great way to control access. In this article, we’ll discuss what zero standing privileges (ZSP) are, how standing privileges are created, and how just-in-time access makes a ZSP model feasible. We’ll explore the risks that accompany standing privileges, the benefits of a zero standing privilege philosophy, and best practices to follow when adopting a ZSP model. By the end of this article, you’ll be ready to incorporate a zero standing privilege philosophy into your security strategy.
Cloud Data Protection: Challenges, Best Practices and More
Cloud Data Protection: Challenges, Best Practices and More
Cloud data protection is an increasingly popular element in an organization’s security strategy. In this article, we’ll explore what cloud data protection is, why it’s important, and the best practices to follow when migrating to the cloud. By the end of this article, you’ll understand the benefits and challenges of adopting a data security strategy for cloud environments.
StrongDM + Cloud Secrets Management = Your New PAM
StrongDM + Cloud Secrets Management = Your New PAM
StrongDM integrates with your favorite cloud secrets manager to provide an end-to-end version of remote access for more than just privileged accounts.