Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Restrict Access to your internal websites on AWS with BeyondCorp

transcend.io

Post reply on HN
Print view View original

31–40 of 59 posts

Re: Restrict Access to your internal websites on AWS with BeyondCorp

#31

Post by zerkten »

snazz wrote: post #20
walrus01 wrote: post #16

Earlier quoted context omitted.

Having 100% company owned equipment allows you to do other common sense things like: a) full disk encryption with key escrow for recovery by admin team b) storage of crypto public/private key pair on disk of laptop, for instance an openvpn key file that was created on a company owned PKI server, deployed onto the laptop as part of its provisioning process, and is a unique key for both the human and that particular pi…

What does Google do in this regard? I don't work there, so I'm curious to hear about their solution for endpoint security. From what I've heard, they don't allow sensitive data on laptops in the first place—you mostly SSH into your desktop or a cloud machine. That's probably not enough to solve the issues you described, so I wonder what else they do.

Microsoft documented some of what they do at https://www.microsoft.com/en-us/itshowcase/protecting-high-r....

Re: Restrict Access to your internal websites on AWS with BeyondCorp

#32

Post by peterwwillis »

I haven't implemented this extensively, but there are sometimes problems with setting this up in a corporate environment where there's a need to do things in a uniform way.

- Often if you use a central database such as Active Directory for your internal users, you may need to set up your OAuth endpoint (say, an AWS Cognito User Pool) and then have an AD admin allow that user pool to be a relying party. This means there is some lag time to setting this up, and that it isn't done with automation. So if you have an application you want to spin up a custom domain with a temporary user pool, test something, and then destroy it later, it's probably not going to work without some custom workarounds. No need for this with a traditional VPN.

- If you have 50 different apps, with 50 different URLs, you're going to need to do the above 50 times. Also have 50 staging and dev portals? Same deal. Now try managing changes to all of those at once. The manual steps, plus all the integration with all the product teams, now means this whole thing is becoming burdensome. This is a lot more work than just "use this VPN client and whitelist these CIDRs".

- If you're working for one of those weird companies that loves to do split-horizon DNS with lots of custom internal-only domains, guess what? Probably not gonna work without a VPN.

- Onboarding can be complicated. You now need to help your users manage their accounts, such as password resets, being a part of different domains, using a supported device, MFA registration, troubleshooting internet connections, using a supported CLI tool for non-web-interface APIs, etc. Versus just saying "are you connected to the VPN?".

- A VPN allows a central network team to manage access control across the entire network (or wherever that network team manages networks). BeyondCorp needs to be managed for all of your products by one team, or you may end up with an uneven and difficult process of supporting users across teams. A lot of companies (maybe most) are just not set up to allow independent product teams to manage internal user access. Even then, authorization maybe, not probably not both AuthN + Z.

- If you have a single domain serving multiple apps in multiple URLs requiring different authorization, things can get more complex.

Ultimately I think most of the protocols used for BeyondCorp today have too many drawbacks to say we could all drop our VPNs in support of it. We'll probably need at least another generation of protocols and management workflows in order for it to become the new norm.

Re: Restrict Access to your internal websites on AWS with BeyondCorp

#33

Post by ndomer »

Znafon wrote: post #8

The BeyondCorp paper explicitly mentions that the device state is taken into consideration when giving access to a user, i.e. that the device is identified and controlled, not just the user. It seems to me like it is an important part in the BeyondCorp access model, otherwise wouldn't this just be a SSO portal?

(Author of the blog here)

This is a great question! I hoped this would get brought up, as it is very important. I decided against covering in this blog as I felt it was already fairly long, but the tldr is that I see two incremental ways with this setup to add authorization:

1. Cognito has something called "Adaptive Authentication" that will compute risk scores for each login based on IP, device info, etc. You can customize in the AWS console how risk-tolerant you want to be.

2. You can go the fully-managed approach, which is what we are implementing at Transcend now. The idea is that you'd use an MDM like Fleetsmith to install a TLS cert onto each managed device, and then validate that cert on each request in the auth portal. There are lots of cool ways (we use the Vanta agent) to verify that a users' device is "good" to authenticate with.

I'd like to write more about option 2, but I try to keep this blog posts as technology agnostic as I can, and my experience is fairly limited right now to Vanta + Fleetsmith

Re: Restrict Access to your internal websites on AWS with BeyondCorp

#34

Post by ndomer »

jlgaddis wrote: post #17
ndomer wrote: post #3

Hello everyone! At Transcend, we've used BeyondCorp for all of our internal sites, as well as for our communication between services. Please let us know if you have any questions about getting started :)

Any plans for articles covering the "device identity" and "device inventory database" components of BeyondCorp? Slapping an proxy server to handle SSO/SAML in front of your web sites is the easy part. I'm curious to hear how you're handling the devices -- especially if you're employees are remote.

This is a great question! I hoped this would get brought up, as it is very important. I decided against covering in this blog as I felt it was already fairly long, but the tldr is that I see two incremental ways with this setup to add authorization:

1. Cognito has something called "Adaptive Authentication" that will compute risk scores for each login based on IP, device info, etc. You can customize in the AWS console how risk-tolerant you want to be.

2. You can go the fully-managed approach, which is what we are implementing at Transcend now. The idea is that you'd use an MDM like Fleetsmith to install a TLS cert onto each managed device, and then validate that cert on each request in the auth portal. There are lots of cool ways (we use the Vanta agent) to verify that a users' device is "good" to authenticate with.

I'd like to write more about option 2, but I try to keep this blog posts as technology agnostic as I can, and my experience is fairly limited right now to Vanta + Fleetsmith

Re: Restrict Access to your internal websites on AWS with BeyondCorp

#35

Post by closeparen »

xienze wrote: post #7

How’s this work with things that aren’t websites? Do you have to throw a proxy in front of e.g., your database server that keeps track of which IPs have already authenticated over the web?

You run a service behind the HTTP proxy, or another proxy with a more suitable protocol like SSH, which can speak the required protocols (or just blindly forward TCP) across production. You run a CLI tool that binds a local port and forwards to this service.

In some ways this is a poor man's VPN server, but it can be smarter: with protocol support, you can combine the identity of the connected developer with application-level data (e.g. this is an INSERT statement) to make AuthZ decisions.

Re: Restrict Access to your internal websites on AWS with BeyondCorp

#36

Post by ndomer »

gizmodo59 wrote: post #11

A genuine question on this topic, does that mean we should have SSH ports open to the world too? If we have some form of 2FA? Or I’m misreading the point of beyond Corp.

(Author here)

I think the second most secure way to handle service authentication is to protect your ports with strong auth, like this article talks about.

But the most secure way to handle this is to just eliminate the open port entirely.

Here's another post of mine where I talk about making a bastion host with no open ports and no ingress on its security group: https://codelabs.transcend.io/codelabs/aws-ssh-ssm-rds/index...

Re: Restrict Access to your internal websites on AWS with BeyondCorp

#37

Post by ndomer »

xienze wrote: post #7

How’s this work with things that aren’t websites? Do you have to throw a proxy in front of e.g., your database server that keeps track of which IPs have already authenticated over the web?

(Author here)

At Transcend, we use a bastion host (like others have mentioned). The key difference that we do that I don't think has been covered is that our bastion only makes outgoing connections, and has no open ports to the world.

Using the AWS SSM managed service, we can create bastions that have no ingress at all.

I talk through some different approaches in a codelab over here: https://codelabs.transcend.io/codelabs/aws-ssh-ssm-rds/index...

Re: Restrict Access to your internal websites on AWS with BeyondCorp

#39

Post by closeparen »

xcskier56 wrote: post #38

Do companies really setup their networks and applications such that if you’re on the VPN you have access to almost everything? Man that sounds insane.

Household name companies routinely get owned because a pen tester finds a network drop in a conference room, or a smart thermostat that merely needs internet access becomes a beachhead. There's apparently a whole generation of IT that believes security is about what is and isn't allowed on "the corporate network."

In my tech career the office WiFi has never been more privileged than the coffee shop across the street, just faster.

Re: Restrict Access to your internal websites on AWS with BeyondCorp

#40

Post by sshahone »

Znafon wrote: post #8

The BeyondCorp paper explicitly mentions that the device state is taken into consideration when giving access to a user, i.e. that the device is identified and controlled, not just the user. It seems to me like it is an important part in the BeyondCorp access model, otherwise wouldn't this just be a SSO portal?

You are correct. The solution presented is not a BeyondCorp but rather an SSO implementation that adds authentication to the internal application.

For BeyondCorp, it essentially:

* Must be Layer 7 protocol, access privilege aware (achieved by an identity-aware access proxy).

* Promotes authorization as opposed to authentication only.

* Should be able to enforce security policies (time, location, context, 2fa).

* Must be aware of the security state of the user device.

Shameless plug: Check out our zero trust service access project TRASA (https://github.com/seknox/trasa). It's free and opensource and addresses many of the requirements outlined by BeyondCorp.

Post reply on HN