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

21–30 of 59 posts

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

#21

Post by walrus01 »

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.

I would be shocked if they don't have a whole team of people keeping up on the threat models for client workstation windows, macos and linux endpoint devices, and creating the equivalent of windows active directory registry pushes+other software loads to guarantee the condition of an endpoint device.

Otherwise how do you know an endpoint device (assuming it's on a network segment with a default route out to the internet, or is somebody in a work-from-home mode) isn't running a persistent video recording session feeding something like a realtime mirror of the screen, VNC-over-SSH tunnel to some third party.

At smaller size companies I have even seen stories of a person who was hired as a fully remote developer by $software_corp, and proceeded to set up a remote desktop tool and subcontract their entire job to a person in $developing_country, at a significant profit margin.

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

#22

Post by Spivak »

brandon wrote: post #12
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?

Historically at Google the exceptions fell into one of a few buckets: * You used a modified client or client proxy (this was done for e.g. SSH) * You used a remote-desktop protocol to remote into a machine with direct network access to the service * The service got a wholesale exemption and was allowed through the firewall with ordinary IP ACLs (descending order of impressiveness wrt the BeyondCorp philosophy and whi…

Why would you ever need option 2/3 when the IAP exists? Is there stuff that doesn’t work over a tunneled connection?

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

#23

Post by ec109685 »

This code scares me: https://github.com/transcend-io/beyondcorp-cloudfront/blob/m...

This encourages a behavior of copy and pasted authentication javascript from service to service.

The ALB approach from the article at least centralizes the SSO dance in one place, but still a typo in terraform would be very hard to detect.

The BeyondCorp approach Google uses, as far as I know, relies on sophisticated proxy servers in front of ALL protected services to ensure the very tricky aspects like posture assessments, zero day patching, logging, rate limiting and other security best practices are handled in one place.

With a scattershot approach, companies may not be open to a VPN exploit anymore, but may have opened themselves up to many more individual exploits and much slower reaction times when an exploit is found.

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

#24

Post by __float »

Spivak wrote: post #22
brandon wrote: post #12

Earlier quoted context omitted.

Historically at Google the exceptions fell into one of a few buckets: * You used a modified client or client proxy (this was done for e.g. SSH) * You used a remote-desktop protocol to remote into a machine with direct network access to the service * The service got a wholesale exemption and was allowed through the firewall with ordinary IP ACLs (descending order of impressiveness wrt the BeyondCorp philosophy and whi…

Why would you ever need option 2/3 when the IAP exists? Is there stuff that doesn’t work over a tunneled connection?

the iap is an http proxy, so you need a way to send non-http traffic. this might require client modifications (not everything is proxy-aware), and you can't always modify the source.

some protocols are udp and latency sensitive, which doesn't work well enough tunneled

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

#25

Post by dangero »

I read a part of the article, but I'm confused. How is this different than making all our internal servers public and using okta or auth0 for sign in?

I wouldn't do that because any of those servers could have a security vulnerability that we're not aware of, so I feel like this must protect against that somehow, but I'm just not fully understanding what it does.

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

#27

Post by m1keil »

dangero wrote: post #25

I read a part of the article, but I'm confused. How is this different than making all our internal servers public and using okta or auth0 for sign in? I wouldn't do that because any of those servers could have a security vulnerability that we're not aware of, so I feel like this must protect against that somehow, but I'm just not fully understanding what it does.

Main difference is that all of these websites are public behind one big proxy (ALB) and not public on their own. The security concerns are centralised in one place, not 10.

That's not to say that the ALB can't have a bug or a misconfiguration that will render it wide open. But that's probably true for VPN as well.

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

#28

Post by m1keil »

We have a very similar setup with Cognito, GSuite and ALBs. For CLI/API access we also have API Gateway which allows to authenticate with JWT tokens that we can issue via Cognito.

It's not perfect:

* This setup only deals with Authentication. There is no authorization at all. I.e ANYONE with org gmail account can get in.

* There is no real SSO. Say you have an application you need to login to behind this proxy. The proxy will pass you through to the login page, where you need to login (again) via whatever it is configured. It's not to say that it's impossible to solve as you have enough info in the headers/cookies that are passed from ALB to sort something out with custom solution, but it takes time.

* You need to be very careful with your OAuth config. With GSuite, as example, you can very easily configure the OAuth client to authenticate ANY @gmail user instead of your @company...

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

#30

Post by closeparen »

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?

My company has configuration management for company laptops install a client certificate. The "internal frontend" proxy checks for this client certificate in addition to AD credentials + Duo.
Post reply on HN