What is BeyondCorp? What is Identity-Aware Proxy?
Your company holds very sensitive data: about your clients, your business, your employees. Your employees need to use a variety of applications, internal or external, to access everything from contracts and purchase orders to addresses and phone numbers. It’s vital to your success, and your survival, to properly lock down the applications, the data, and the ways people get access. Yet you also need to make the applications accessible to your people, wherever they are working.
How are you going to protect the lifeblood of your company: the data?
In response, I tend to see more companies adding extra layers of VPNs, firewalls, restrictions and constraints, resulting in a terrible experience and a slight security gain. I think there’s a better way. Inside Google we call it BeyondCorp, and on Google Cloud Platform it’s available to you through a complementary group of security products; today we’ll focus on Identity-Aware Proxy (IAP).
Problems with perimeter security
For most IT professionals, the one-true way to extend security to your infrastructure boils down to adding more, bigger firewalls. Your castle is under attack, what do you do? Taller walls will surely repel the invading barbarians. That might keep out an attacker that only uses one tactic (ladders), but it’s not actually giving you better security against a wide variety of attacks (like wall-crushing dragons).
And attackers are getting very creative. As soon as one spy slips into your castle hiding on the bottom of an ‘innocent’ merchant carriage, you’re sunk. They get past your wall and they get access to everything.
Most corporate networks are structured the same way: highly reinforced perimeter, and highly vulnerable interior.
Once an attacker slips past your perimeter, by compromising an employee device or utilizing a zero-day in one of your servers, then they can move laterally with ease.
These systems rely on location to determine trust: either you’re inside the strong perimeter, by being at the office or on the VPN, and thus you get access, or you’re outside, and you get nothing. The trust comes from where you are, and is given based on the sub-network or IP address you come in from. This is too easy to circumvent: an attacker might ride along by compromising a computer that’s making other, legitimate requests. Or they may get a dangerous device inside the perimeter via an unsuspecting employee. Or just use the internet, since location becomes meaningless as more and more access boils down to IP address.
Turns out you can trust the internet, at least as much as you trust your own network
A strong perimeter also keeps out employees who need to get work done on the road, visiting with a client and only able to use a phone or tablet. The VPN-centric approach focuses on optimizing for laptops and desktops, at the expense of the devices more and more employees actually use to get their work done every day.
Zero Trust IS Context-Aware Access
At Google we’ve shifted to a model that moves Beyond the Corporate network.
This means no more privileged network internally at our offices, and no distinction between connecting to a service from the office or from home.
We don’t rely on VPNs at Google, you shouldn’t either
We’ve stopped using a VPN or special network to gate access to internal tools and services. Instead we look at user identity and the context of each access request, and decide whether or not to grant access for that individual session, based on what we know:
- Is this person authorized for this resource?
- Is this device safe and healthy?
- Does this request meet my access policies?
When I say Zero Trust I mean that we have zero inherent trust in any network or session.
We have to grant trust, otherwise nobody would ever get to our financials, bugs or codebase. But we only grant that trust when we know it’s warranted. That trust is given to a specific session when the criteria above are met.
To make this work we need to know what each person is authorized to access, we need to have confidence in their authentication, and we need to evaluate the health of their device. Every connection to a corporate resource must be encrypted, to prevent any intermediate listener from stealing information.
Set up context-aware access to your app
Let’s take a quick look at how to implement context-aware access to web apps with Identity-Aware Proxy, Google Cloud Platform’s access control tool for controlling access based on who is making the request. In future posts I’ll show you how to apply the same access controls to your GCP infrastructure or 3rd party SaaS applications.
At Slager Bank & Trust they want to replicate this model, but are new to public cloud. So they start with a simple training app they made to enforce regulatory compliance training for all employees. This app walks through the basics of financial regulations, checks that the employees got the answers right, then repings them every 12 months to renew training.
After deploying the app to App Engine, the IT folks at Slager want to make sure only full-time employees can access it, so they don’t get tons of useless traffic from outside the staff, and to avoid any exploits from malicious intruders.
They go to their cloud console, to Security, and head to Identity-Aware Proxy. Since it’s the first time they’ve used IAP, they go through configuring a consent screen, confirming the product name and email address for questions. They decided to use their support team’s email alias so any access issues would go to their IT team first to troubleshoot.
Now they’ve got their App Engine app ready for IAP, and it’s time to decide on access. For this app we want all employees at Slager to be able to see it, and only Max can change permissions or update it. Easy! We choose Add Member to attach an owner, then Add Member again and select the role IAP-Secure Web App User, tossing the group employees in, which contains all full-time Slager employees.
Then we throw the switch (under the heading IAP) and we’re good to go. Now the load balancer in front of this App Engine app will enforce access based on identity, so anyone not inside the employees group (which got IAP-Secure Web App User access) will see this:
Requirements to change the trust model
In a future post I’ll dig into how Google made this change, and plot the course of our eight year journey. But it doesn’t have to be a gigantic effort for you. We can help.
If you’re got an App Engine or Kubernetes app already running on Google Cloud, it’s pretty quick to set up Identity-Aware Proxy (one of our tools to help you create your own BeyondCorp model) and try it out today. You can quickly fire up one of the great how-to’s even if you’ve never used Google Cloud Platform before. And stay tuned for further posts where I’ll walk through how you can get started easily with these features and improve your security and usability at the same time.
