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.
Restrict Access to your internal websites on AWS with BeyondCorp
11–20 of 59 posts
Re: Restrict Access to your internal websites on AWS with BeyondCorp
#12How’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 whitepaper)
Some of this is discussed in the "Non-HTTP Protocols" section of this paper: https://www.usenix.org/system/files/login/articles/login_win...
Re: Restrict Access to your internal websites on AWS with BeyondCorp
#13The 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?
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 'beyondcorp' type approach. but at a certain point of threat model on the client device (keystroke loggers + tools that send screenshots somewhere else, as is found on black hat remote access tools/botnet tools), you need to have specialists in endpoint/workstation device security keeping on top of threats, and defining the security policy.
what sketches me out about this particular article is that they're essentially trusting any client endpoint device that has the 2FA hardware token, and has a working browser. you could have a totally screwed up windows 10 laptop riddled with some very nasty RATs that would work fine to use the 2FA authentication tool, and sign in to their service with chrome in a browser. there's nothing about verifying the state of the software and trustworthiness of the operating system of the client device which might be potentially accessing very sensitive internal information.
i see literally nothing in that article about inspecting or trusting the state of the operating system or software on the client device. does it have a bunch of malicious browser plugins? who knows. is it running a remote desktop tool that's linked to somewhere else? who knows. is it infected with an advanced remote access tool? who knows. is it six months out of date on windows updates? who knows...
the article's assertion that a vpn based approach is like an eggshell is false in my opinion. you should not have an environment where simple vpn auth allows you in to the squishy inner center of private data. a belt and suspenders approach is needed.
Re: Restrict Access to your internal websites on AWS with BeyondCorp
#14The 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?
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
#15Close but not close enough. Take an ALB, pair it with your SSO solution (AWS SSO, OneLogin, Okta, etc). Add DUO and make sure to validate the devices as well. You need half if not less of the infrastructure outlined in this article.
Re: Restrict Access to your internal websites on AWS with BeyondCorp
#16Earlier 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.
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 piece of hardware
c) you can use the same crypto key pair on client device local storage, if not for something like openvpn, for other authentication purposes identifying that particular user and hardware
d) obviously, have the device trust your own internal PKI's root CA for access to purely-intranet resources. getting a company root CA trusted by the browsers in a BYOD device environment is a pain in the ass.
Re: Restrict Access to your internal websites on AWS with BeyondCorp
#17Hello 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.
Re: Restrict Access to your internal websites on AWS with BeyondCorp
#18A 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.
SSH through a Teleport/Boundary-style bastion can be viewed as BeyondCorp for developers.
Re: Restrict Access to your internal websites on AWS with BeyondCorp
#19Close but not close enough. Take an ALB, pair it with your SSO solution (AWS SSO, OneLogin, Okta, etc). Add DUO and make sure to validate the devices as well. You need half if not less of the infrastructure outlined in this article.
URL for your article?
Re: Restrict Access to your internal websites on AWS with BeyondCorp
#20Earlier quoted context omitted.
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.
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.