Security Cloud IAP and its role in zero-trust

At Google Cloud, we run a series of Cloud Summits each year. A Cloud Summit is essentially a mini-version of Cloud NEXT – it lasts one day, features multiple tracks of technical sessions, and is usually held in a location where there is plenty of space for booths where customers can ask questions.

One question that we frequently get at the Ask an Architect or Ask the Expert booth is about Cloud Identity-Aware Proxy - what is it for, how does it work, and how to use it?

In this series of blog posts, I am going to address these questions, one at a time:

What’s Cloud IAP?

Cloud IAP evolved out of BeyondCorp, which is Google’s own implementation of a zero-trust security model.

Zero-trust is a bit of an over-hyped term – and fundamentally, it is just a concept, a way to approach and think about network security. There’s no single right way to do zero-trust, and there’s no single product that can implement zero-trust for an enterprise. But there are some important building blocks that you’ll likely need if you begin to implement zero-trust – and Cloud IAP might be one of them.

Zero-trust for corporate applications

Enterprises commonly run a large number of corporate applications – these are third-party or custom-built applications that are only intended to be used by employees. Common examples for such corporate applications include your HR portal, an expense tracking application, or some other internal line-of-business application that an intern or contractor built some years ago.

It is probably safe to assume that each (or at least most) of these applications implement some kind of authentication and authorization – for example, they might integrate with your internal single sign-on system to authenticate users and they might query an internal LDAP server for authorization.

However, chances are that you do not completely trust the security of these applications:

  • Some of the third-party applications might not use the latest version, and the version you run might have known vulnerabilities.
  • Your custom line-of-business applications might still be using an outdated web framework or depend on outdated libraries because it is simply too much work to keep them all up to date.
  • Even for new and up to date applications, you might have some doubts about whether the intern or contractor who built them really followed all the security best practices.

Of course, the classic way to deal with this situation is to expose such corporate apps to the internal network only. The internal network, which presumably only trusted employees have access to, serves as a perimeter and provides a layer of protection that is additional to whatever authentication and authorization mechanisms each of the corporate applications implements.

With zero-trust, we want to move away from perimeter security because it has proven to be too inflexible and to not be good enough to fend off today’s security threats.

But what do we do with these corporate applications if we cannot rely on the network perimeter anymore? Throw out the baby with the bathwater and expose these applications directly to the internet?

The Access Proxy

A key component of the BeyondCorp concept that addresses the challenge of dealing with corporate applications is the Access Proxy. The research paper summarizes the role of the Access Proxy as follows:

The access proxy is configured for each application and provides common features such as global reachability, load balancing, access control checks, application health checks, and denial-of-service protection. This proxy delegates requests as appropriate to the back-end application after the access control checks complete.

In other words, the access proxy serves as a choke point that:

  • is reachable from any network, not just the internal network,
  • enforces protection and access control on top of what the individual (corporate) back-end application implements,
  • performs access control in a context-aware manner – that is, it takes multiple signal into account before delegating a request to the (corporate) back-end application.

And this is exactly what Cloud IAP does – it adds a layer of defense around a corporate application that enables you to expose the corporate applications to untrusted networks without compromising security.

Even when deployed behind Cloud IAP, an application is still supposed to implement proper authentication and authorization – the access control implemented by Cloud IAP is meant to be applied on top of the application’s own access control, not in replacement of the application’s own access control.

Now that we understand the purpose of Cloud IAP, we can take a look at how it works in the next post.

Related posts

Any opinions expressed on this blog are Johannes' own. Refer to the respective vendor’s product documentation for authoritative information.
« Back to home