Rethinking Enterprise Security with BeyondCorp and Identity-Aware Proxy

The traditional castle-and-moat approach to enterprise network security is crumbling in the face of cloud computing, mobile devices, and remote work. Perimeter-based security models that inherently trust internal networks and distrust external ones break down when the boundary between inside and outside blurs. Users need to access applications and data from anywhere, while applications need to securely connect to users and other services across untrusted networks.

Recognizing this paradigm shift, Google developed BeyondCorp, a new zero trust enterprise security framework that eliminates the concept of a trusted network and instead evaluates trust on a per-connection basis. BeyondCorp treats all networks as untrusted and grants access to services based on the authenticated identity of the user and device, regardless of location. It‘s a radically different model that requires rethinking everything from network architecture to application design to device management.

One of the key building blocks of BeyondCorp is Identity-Aware Proxy (IAP), a Google Cloud service that provides granular access control and authentication for cloud-hosted web apps and resources. IAP allows enterprises to enforce zero trust access policies without modifying their applications or networks. As a Linux and proxy server expert, I‘ll dive into the technical details of how IAP works and share insights on how to leverage open-source tools to implement BeyondCorp principles in your own IT environment.

The Limits of Perimeter Security

Traditional enterprise network security relies on a clear demarcation between trusted internal networks and untrusted external ones. The on-premises data center is the castle, and the company-owned laptops and desktops are the royal subjects that enjoy free reign within the castle walls. VPNs act as drawbridges that extend the castle to remote branch offices and traveling employees.

This model falls apart in a world where the moat has dried up and the walls have crumbled. Critical business data no longer resides solely in private data centers – it‘s scattered across multiple public clouds and SaaS apps. Employees access corporate resources not just from managed Windows laptops but from personal smartphones and tablets. Contractors and partners need selective access to certain systems without full network admission.

Compounding the problem is the rise of Linux and open-source software in the enterprise. While Windows desktops could be tightly managed with Active Directory and Group Policy, Linux servers and containers introduce new security challenges. Developers often provision Linux VMs on demand and configure them using infrastructure-as-code tools like Ansible and Terraform. These elastic workloads may exist for days or mere minutes, making traditional perimeter security controls inadequate.

Even for companies that still primarily rely on a private data center, perimeter security has serious weaknesses. Once an attacker penetrates the network through a phishing attack or compromised device, they can move laterally with ease. According to Verizon‘s 2020 Data Breach Investigations Report, over 1/3 of breaches involved internal actors, and 8% of breaches were caused by misconfigurations such as overly broad network access. VPNs that grant full network access are a prime target for attackers.

To quantify the risk of perimeter security, consider these sobering statistics:

• The average cost of a data breach reached $3.86 million in 2020, according to IBM
• It takes organizations an average of 280 days to identify and contain a breach, according to IBM
• Over 80% of organizations have experienced a cloud data breach in the past 18 months, according to an IDC survey
• 30% of organizations have suffered a security incident due to an unsecured Linux server, according to a Ponemon Institute study

The hard truth is that perimeter security is no longer effective or sustainable in a cloud-first, mobile-first, Linux-powered world. It‘s time for a paradigm shift.

The BeyondCorp Revolution

Recognizing the need for a new approach, Google undertook a massive internal initiative to re-envision its enterprise security model for the cloud era. The result was BeyondCorp, a new zero trust framework that Google has been implementing globally since 2011.

The core principle of BeyondCorp is to remove trust from the network and instead establish trust through device and user authentication and authorization. Every request for access to a resource, whether from an internal or external network, is evaluated based on contextual factors like:

• The user‘s identity and role
• The device‘s identity, security posture, and compliance with policies
• The sensitivity of the requested resource
• The risk level of the user and device

Unlike a VPN that grants full network access, BeyondCorp operates on a need-to-know basis where every request is evaluated independently. A finance employee accessing a financial reporting application might require stronger authentication and device security than the same employee accessing a company directory. A salesperson using a personal iPad to read email through a web app would go through different access controls than an IT admin using an SSH client on a managed Linux workstation to access production servers.

This fine-grained access model is enabled by a few key architectural shifts:

1. All access to services is over a standard internet protocol (HTTPS), not a privileged internal network protocol.
2. Access to services is authenticated and authorized at the application layer, not the network layer.
3. All managed devices use certificates to authenticate and establish encrypted tunnels to specific services, not the entire network.
4. A centralized inventory of devices and services acts as a single source of truth for access policy evaluation and monitoring.

Google has published detailed whitepapers on BeyondCorp, but here are some of the key enablers:

• Single sign-on (SSO) for user authentication
• TLS client certificates for device authentication
• Access control lists (ACLs) tying users and devices to services
• Unprivileged internet-facing proxies that enforce global access policies
• Software-defined perimeters that dynamically create encrypted tunnels between users, devices, and services
• Infrastructure-as-code provisioning and management of servers and configs

Implementing BeyondCorp was a multi-year journey for Google that required changes to its internal apps, device management approach, and network architecture. But the results speak for themselves.

In a 2019 presentation, Google reported that BeyondCorp handles over 850,000 requests per second from 156 countries to over 2,100 microservices. Security incidents involving network access dropped significantly, while the time to provision access to new services shrunk from months to minutes. Employee satisfaction with remote access also improved substantially.

Identity-Aware Proxy: BeyondCorp for Everyone

While Google uses many proprietary systems to power BeyondCorp internally, it has released one of the core components as a managed service for all Google Cloud customers: Identity-Aware Proxy (IAP).

IAP is a building block for BeyondCorp that provides granular identity-based access control for cloud-hosted HTTP services without requiring any application code changes. It acts as a lightweight, internet-facing reverse proxy that intercepts all traffic to a service and enforces centralized access policies before routing authorized requests to the backend.

Here‘s how it works:

1. An administrator configures an IAP access policy in the Google Cloud Console or via an API, specifying which users and groups can access which resources under what conditions.
2. A user tries to access an IAP-secured resource like a web app, API, or SSH endpoint.
3. IAP redirects the user to authenticate with their Google (or other OAuth) identity.
4. If authentication succeeds, IAP looks up the user‘s identity and group memberships and evaluates them against the access policy.
5. If authorization succeeds, IAP establishes a secure tunnel to the backend resource and forwards the user‘s request with identity headers.
6. The backend resource can further evaluate the identity headers for fine-grained access control.

IAP supports a variety of authentication methods, including:

• Google Accounts (OAuth)
• SAML and OIDC identity providers
• Client certificates (mTLS)
• Service accounts and short-lived access tokens

It also integrates with Google Cloud‘s context-aware access policies, allowing administrators to define access rules based on attributes like:

• Device security posture (e.g. screen lock, disk encryption, OS version)
• IP address or geolocation
• Time of day and date range

Some common IAP use cases include:

• Enabling SSO and granular access for cloud-hosted web apps
• Enforcing least privilege access to cloud APIs and services
• Securing remote access to VM instances via SSH and RDP
• Replacing VPN for access to internal resources from untrusted networks
• Implementing software-defined perimeters and zero trust network access

To demonstrate the power and simplicity of IAP, let‘s walk through an example deployment.

Acme Inc. has a containerized expense reporting web app running on Google Kubernetes Engine (GKE). The app frontend and backend services are exposed via an HTTP load balancer. Acme wants to restrict access to the app to only its employees and enforce stricter policies for off-network access.

To enable IAP, an Acme admin logs into the Google Cloud Console, navigates to the IAP config page, and selects the GKE backend service. They click "Enable API" to turn on IAP for the service.

Next, the admin configures an access policy. They specify a Gmail account domain (e.g. acme.com) to allow any user with a matching email to access the app. They also configure a context-aware policy that requires company-owned devices and a specific corporate IP range for access outside the office network.

With that, the expense app is now secured with identity-based access control. When an employee visits the app URL, they are redirected to Google to authenticate. Upon successful login, IAP checks their identity and device context against the policy. If everything checks out, the request is securely routed to the app backend. The app can further inspect identity headers to enforce granular permissions.

IAP even secures access for developers and admins. Instead of SSH keys or bastion hosts, they can use the Google Cloud Console or gcloud CLI to establish one-click SSH tunnels to Kubernetes nodes or VM instances. IAP authenticates the user and sets up a local proxy automatically.

Embracing Zero Trust and Open Source

IAP is a powerful tool in the zero trust toolbox, but it‘s far from the only one. Enterprises running on Linux have a variety of open-source options for building BeyondCorp-style architectures.

One key pattern is using forward proxies and service meshes to enforce authentication and authorization at the edge. Open-source proxies like Envoy, NGINX, and HAProxy can be deployed as sidecars to application containers or VMs. The proxies terminate inbound connections, inspect headers, and perform access control before forwarding requests upstream.

OAuth2 Proxy is a popular open-source project that provides IAP-like identity-based access for any HTTP service behind a proxy. It integrates with a variety of OAuth providers and can enforce access policies based on email domain, group membership, and other attributes.

Another emerging trend is software-defined perimeter (SDP) solutions that dynamically create encrypted tunnels between users and services in real-time. Open-source projects like Wireguard and OpenZiti provide simple, secure connectivity without the complexity and overhead of VPNs.

On the device management front, tools like osquery and Fleet allow enterprises to maintain a real-time inventory of Linux and macOS device state. This data can inform access policies and help identify non-compliant or high-risk devices.

Finally, infrastructure-as-code is critical for managing ephemeral Linux workloads at scale. Provisioning tools like Terraform and Ansible make it easy to codify and automate access policies across cloud environments. Secrets management tools like Vault enable dynamic secret injection and rotation.

Zero Trust Roadmap

Migrating to a zero trust model like BeyondCorp doesn‘t happen overnight. It requires buy-in from leadership, cross-functional collaboration, and a phased implementation approach. While every organization‘s journey will be different, here is a high-level roadmap:

1. Define business drivers and goals. Articulate the security, productivity, and agility benefits of zero trust and align with stakeholders.
2. Take inventory. Map and classify all users, devices, networks, applications, and data. Prioritize based on risk and readiness.
3. Strengthen identity. Implement SSO, MFA, and user lifecycle management across all services. Use OAuth and SAML standards.
4. Harden devices. Deploy MDM and endpoint protection across managed devices. Establish device trust through certificates and security posture checks.
5. Implement access proxies. Front cloud-based and internet-facing services with IAP or proxy servers. Enforce global access policies at the edge.
6. Isolate workloads. Segment networks and deploy micro-perimeters around high-risk services. Use SDPs and service meshes for granular access.
7. Monitor and adapt. Collect security telemetry across proxies, services, and policy engines. Monitor for anomalies and continuously update policies based on risk.

The journey to zero trust is ongoing. But with the right mindset, architecture, and tools, enterprises can realize significant benefits in security, productivity, and agility. By adopting BeyondCorp principles and leveraging open-source software, companies of all sizes can leave the castle-and-moat behind and thrive in the cloud era.