.png)
Organizations frequently struggle to find the best way to provide their engineers with access their backend infrastructure. How do you balance security with engineering productivity and platform resilience?
We’ve put together a list of the most common reasons why organizations look to BastionZero to simplify and secure the methods they use to grant their engineers with privileged access to their infrastructure.
You lack auditability
You have no idea who has access to what systems. Does Bob have access to your database passwords? Has he logged into the database recently, and if so what kind of changes did he make? Who is that person logged in as “root” on us-west-server-22 and why kind of commands did he run? Who was that “cluster-admin” user that deleted a pod last night at 10:49pm? Who has the SSH keys to your Jenkins server? The lack of visibility makes it difficult to tell what’s going on in your infrastructure, and is at odds with your compliance and security goals. It leaves you open to insider attacks and makes it difficult to respond to incidents.
.png)
You have “privilege creep”
You had an employee who needed admin access to a cluster to fix a bug. They eventually got their needed access, but you never took this access away. There was another incident and this employee shared the cluster admin credential with someone else. There was yet another incident and your employee was given credentials to your database in order to fix the problem. Rinse and repeat. If this is the method for granting access to your backend, your security team very quickly loses track of who has access to what.
Having privileged credentials spread out across many individuals makes your infrastructure vulnerable. If just one of them gets hacked, it’ll cause a significant impact on your systems. It also creates a big headache from a compliance perspective, which can impact revenue and business relationships.
You have a growing number of targets
You team needs access to lots of different targets - some EC2 instances, some on-prem VMs, a kubernetes cluster in EKS and another one in GKE, a Mongo Atlas database and postgres RDS databases. So you have many different types of targets, and now you need to build individual systems to support access to each one. Different types of targets need different system—you can’t use the same system for server, DBs, and k8s access. But maintaining and building separate systems can be painful.
BastionZero is an all-in-one platform that supports access to all of your different types of targets.
You have a growing number of accounts
Having different access systems for different targets is a lot to manage, and multiplying that in a matrix by your cloud accounts makes it even harder. You can build a different infrastructure access system in every different account you have with with each cloud provider, but this can quickly get out of control, especially if since you need to build and maintain the four As yourself:
- Access (how users connect to your targets)
- Authentication (how they log in)
- Authorization (how you determine which targets, roles and accounts a given user can have access to)
- Auditing (how you track where they logged in and what commands they ran)
BastionZero is an all-in-one SaaS that solves this problem in a completely cloud-agnostic manner. We don’t rely on any of your cloud providers internal tools, IAM roles, or access systems.
You rely too much on perimeter-based defenses
The industry is finally moving away from an over reliance on VPNs. VPNs make it too easy for adversaries to move laterally through your systems, and don’t provide you with audit logs of who access what specific target or what they did to that target. Also, with a VPN you still need to manage the access system that gets you over that “last mile” to your target (eg bastions, jumpboxes, SSH keys, k8s credentials, database proxies, database passwords, etc.) Moving to a zero trust posture makes you more secure. And BastionZero saves your the effort of having to build out these “last mile” access systems.
You are managing long-lived credentials
You may be providing long-lived keys that users store on their laptops. However, having long-lived credentials to manage is a security and productivity issue. You need a system to manage which servers can be accessed with which keys. You may have shared credentials that you don’t want to provide to new hires or on-call people, which also impacts productivity.
Long-lived credentials can also become a security issue. If a laptop gets compromised, the adversary can use the key to attack your system later. Even back in 2001, FluffiBunni installed malicious SSH clients on its victims in order to exfiltrate and steal SSH keys. Colonial Pipeline was hacked in 2021 due to an old VPN key that was leaked. Using these keys, they could log into systems—sometimes even six months later—because the stolen keys were still usable.
A zero-trust security posture, which eliminates long-lived credentials, can spare your infrastructure from these sorts of attacks.
You have many disparate systems for access
When there's been an organic development of remote access systems, each systems develops differently. But disparate systems aren’t maintainable. You have to worry if one system has a bug and needs patching. You don’t know who actually has access to the other system. You database passwords are shared across the devops organization. This lack of visibility is a major security risk.
Your engineering team is growing
Your engineering team has grown. However, ten engineers sharing one key has evolved to a hundred engineers sharing it. You can’t trust all these people with access: it’s become a risk issue. Manually inputting IAM roles for each member of the team just isn’t scalable.
From an efficiency standpoint, offboarding has also been affected. You may have an engineer who left the company with several SSH keys. If you don't have auditability or a system that tracks their SSH keys, it can make the offboarding process extremely painful.
