Restrict Access to your internal websites on AWS with BeyondCorp
41–50 of 59 posts
Re: Restrict Access to your internal websites on AWS with BeyondCorp
#42This naming is needlessly confusing. BeyondCorp is a name invented by Google to describe its internal approach to security, and now it's a Google Cloud product. Why would Transcend reuse this name? It sounds as if Transcend is a middleman reselling a GCP product.
As some examples, https://www.beyondcorp.com/ is run by the IdP Okta, and ScaleFT (a zero trust SaaS company) references the philosophy of BeyondCorp as being used outside of Google: https://www.scaleft.com/blog/beyondcorp-outside-of-google/
Re: Restrict Access to your internal websites on AWS with BeyondCorp
#43Earlier quoted context omitted.
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 inter…
Re: Restrict Access to your internal websites on AWS with BeyondCorp
#44Earlier quoted context omitted.
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
#45I 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.
The poor man's version of this is to put all your services behind an nginx reverse proxy with HTTP Basic auth (and TLS of course). For personal/small scale operations, this is a great way to almost completely eliminate your attack surface, if you have single-digit users and they can be trusted. Everyone running webapps personally should prefer this over, or in addition to, app-specific login systems.
Re: Restrict Access to your internal websites on AWS with BeyondCorp
#46Earlier quoted context omitted.
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 inter…
I wonder if there are any big companies that require HDCP and some sort of "trustworthy USB devices only" system.
Nevermind the fact that HDCP has been broken for ages and any random Chinese capture card will ignore it and Chinese HDMI splitter will strip it, if the purpose is to cheat the system then you can just point a camera at a screen (perfect video quality isn't a requirement here).
Re: Restrict Access to your internal websites on AWS with BeyondCorp
#47Earlier quoted context omitted.
large enterprise deployments of phones or company owned desktops/laptops, etc, very commonly include what would be called "network admission control" software. The device needs to meet a certain defined state of patch level/servicepack/antivirus scan/other things (like GPO registry settings on a windows machine) before allowed to sign on. it's all good to theoretically say that smaller companies should adopt a 'beyon…
Indeed, and the industry term for this is posture assessment. And many companies take this a step further and permit access only with organization-issued equipment, even if you possess authentication credentials.
Re: Restrict Access to your internal websites on AWS with BeyondCorp
#48Re: Restrict Access to your internal websites on AWS with BeyondCorp
#49The 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…
Re: Restrict Access to your internal websites on AWS with BeyondCorp
#50This 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…
What's particularly scary about it?
As for "a typo in terraform would be very hard to detect" - perhaps, yes, assuming it didn't fail outright. To mitigate that I'd expect anyone deploying this for real to protect anything valuable would ensure unit tests were written for the Javascript and to have code reviews of any security-sensitive code like this.