Secure Access Trade-offs for DevSecOps Teams

Engineering teams building software are always under pressure to deliver new features, fix bugs, and improve performance. To move quickly, engineers need access to computing resources: servers, Kubernetes clusters, databases, logs, etc.

Granting access to these resources creates a big attack surface area. Consider all attack vectors that exist for a database: An attacker can get SSH access to a database machine, or via a Kubernetes API, or via a compromised Web user interface, or even via the database's own socket.

What Is Access?
Granting access to modern computing environments is a multistep process:

Security Overhead
What types of computing resources typically need to be accessed? The usual suspects may include SSH boxes, databases, internal dashboards, Kubernetes APIs, various middleware, etc. Each of these layers uses its own configuration syntax, listens on a socket, speaks its own protocol, and has its own take on concepts such as authentication or role-based access control (RBAC).

Configuring access for every single socket of every single instance of every single environment for the best possible security is a laborious task. It requires significant expertise because every resource type comes with its own unique security considerations. In addition to the constantly growing set of these endpoints, there is also a growing number of engineers who need access.

Implementing best practices for connectivity, authentication, authorization, and audit for every socket of every resource type is extremely hard. A compromise often must be made.

Common Trade-offs
To reduce the security overhead, most organizations rely on the combination of these trade-offs:

● Shared secrets. A security team carefully configures every resource type for remote access, but only for a handful of predefined users, like "admin" and "app." The credentials for these are often shared.

● Access restrictions. Engineers are never given access to some resources. This slows down the pace of development.

● Relying on the perimeter. Taking advantage of the fact that the private network itself can authenticate clients via solutions such as VPNs. Individual resources are not protected.

These approaches present numerous problems. Let's highlight just a few:

● Shared secrets can be stolen because laptops can be stolen. They do not create a useful audit log that ties actions to a person.

● Relying on perimeter security creates a single point of failure. When attackers get access to a private network, nothing stops them from getting access to everything.

● Access restrictions severely limit engineering productivity and creativity and create incentives for engineering teams to be building backdoors for themselves.

Emerging Solutions
The buzzwords to pay attention to are: identity, zero trust, and access plane.

Identity
Identity-based access means moving away from shared accounts. Each user must log in with their own account identity. It would be impractical to configure every resource with identities of all employees. Instead, identity-based protocols like SAML rely on some sort of a temporary token, for authentication. However, the existing standards are not compatible with resources that do not speak HTTP, such as SSH servers or databases.

Zero Trust
Zero trust-based access means moving away from perimeter security. Zero-trust principles mean that every resource acts as if it was running on a public Internet, uses encryption, performs authorization, and maintains its own audit log.

Access Plane
An access plane builds on top of identity and zero trust and allows organizations to let go of access restrictions. An access plane consolidates access and:

● Creates a single access point for all engineers and resource types across all environments.

● Enforces identity-based access for all resources and people. It uses certificate-based authentication and authorization, thereby acting as a certificate authority of an organization.

● Automatically creates certificate-based connections to all resource types, even if they don't natively support it. This removes the overhead of having to configure every resource type separately.

● Maintains the centralized audit log, creating real-time and historical view of all events.

● Implements authorization for every supported protocol.

Advanced Techniques
There are additional improvements to security that can be made. One recommendation is to implement the principle of least privilege, which basically means eliminating permanent "root" type accounts and replacing them with access on-demand.

What if an engineer could create a "git pull request" requesting temporary access to critical production infrastructure? Then the engineer's peers would review and approve such requests, granting temporary access with solid security and compliance guarantees.

Some security-minded organizations implement a more advanced version of access requests called a "four-eye policy," when access is granted only when the live session is streamed and viewed by another person, making sure that not less than two sets of human eyes are watching what Alice is doing.

Conclusion
Implementing connectivity, authentication, authorization, and audit logging for every socket in every cloud environment used to be an insurmountable task. The best tech companies in Silicon Valley employ the best talent to build and maintain in-house solutions dedicated to this task.

But thanks to recent advancements in access technologies, everyone can now apply identity-based authentication and authorization and zero-trust principles for their computing resources using the concept of an access plane.

More advanced organizations can implement concepts such as the principle of least privilege and temporary privilege elevations with techniques such as access requests or "four-eye" policies.

The end result is simple remote access, which makes engineers more productive, doesn't compromise security, enforces compliance, and allows visibility into everyone's behavior. A win-win.