While it is of course content marketing, I disagree there is nothing meaningful. Perhaps I’ve been living under a rock but I didn’t know how these organizations handled authentication.
No pricing anywhere on their site either. Huge pet peeve for me. That usually means it is obscene for non trivial usage. Looks very promising but I'm unwilling to carve out the time and mental energy on the remote chance that it'll be something reasonable I can fit into our budget. I'm guessing this is aiming at huge corporations.
>”This requires all systems employed within the BeyondCorp model to be built with the same skill and hardening as required by any public internet solution.”
Is that true of _every_ system? I can imagine they have at least some systems which must be isolated, like BMS or other systems which typically run a decade of more behind in technology, unless they build their own, but then what about sites where they rent from WeWork competitors?
I think the article's description of BeyondCorp is missing a bunch of nuances. AFAIK Google still firewalls their network; the difference is that they put users outside the firewall not inside. And for applications it looks like only a proxy is visible outside the firewall, not the whole app infrastructure.
I'd like to see an MFA-version of Kerberos/kinit, and a PAM module that checks for ticket revocation on login.
That's not so different from BeyondCorp and Uber's model.
Alternatively, some kind of OpenID Connect init (oidcinit) to get a JWT and then a PAM module like the kerberos one (which also checks the JWT's Key Id for revocation on authentication)
From what I've read about BeyondCorp it's far more sophisticated than just Teleport. It's also a service monitoring status of a device including boot security throughout the entire life of the decide, private keys stored in TPM, plus various tiers that depend on multiple factors.
users with totp tokens can kinit using their password+totp in the password field. better still, if you use PAM for all your services, you you can define hbac rules allowing users access to specific services on specific hosts.
the caveat is that the freeipa servers must be available to provide authorization even once the ticket is issued. with x509, the authenticating host doesn't need to rely on a server for anything but CRL checks
I think we have just the (Open Source) solution for you: https://bit.ly/Keymasterhttps://github.com/Symantec/keymaster
This issues MFA-ed ephemeral credentials: SSH certs, Kerberos compatible X509 certs, X509 certs for Kubernetes and well as being an OpenID-Connect/OAuth2 IDentity Manager.
In the fifth paragraph, "No longer does the company rely on a network perimeter, but rather exposes internal systems to the public internet.". This is terribly misleading!
Zero trust model is often explained incorrectly and misunderstood as allowing internal services like OpenSSH directly exposed to public all the time. In actual, it also works similar to VPN having perimeter security but in a dynamic way. There should be a proxy separate from actual service for authentication and only authentication service is exposed to public traffic all time, while internal resource only accepts inbound traffic from IP address of user who has authenticated successfully and this is orchestrated in real-time by the authentication service. The traffic from same user to internal service is also denied the moment they log off, think of it like a dynamic iptables system. Another emphasis of zero trust model is to authenticate requests even when it's coming from the same internal subnet. Too many articles are misleading people that zero trust model is to take away perimeter security entirely.
Note: Exposing any internal services like SSH, message queues or databases directly to public is not the right approach, because they can get compromised when there's any RCE vulnerability.
16 comments
[ 5.6 ms ] story [ 48.3 ms ] threadThe only remotely meaningful part is the plug for their product at the end.
I don't remember the exact number, but their smallest licence was supposedly over 40k€.
Maybe it was a misunderstanding but I didn't pursue it at that point. Even a tenth of that price would've been a hard sale.
Is that true of _every_ system? I can imagine they have at least some systems which must be isolated, like BMS or other systems which typically run a decade of more behind in technology, unless they build their own, but then what about sites where they rent from WeWork competitors?
That's not so different from BeyondCorp and Uber's model.
Alternatively, some kind of OpenID Connect init (oidcinit) to get a JWT and then a PAM module like the kerberos one (which also checks the JWT's Key Id for revocation on authentication)
users with totp tokens can kinit using their password+totp in the password field. better still, if you use PAM for all your services, you you can define hbac rules allowing users access to specific services on specific hosts.
the caveat is that the freeipa servers must be available to provide authorization even once the ticket is issued. with x509, the authenticating host doesn't need to rely on a server for anything but CRL checks
Zero trust model is often explained incorrectly and misunderstood as allowing internal services like OpenSSH directly exposed to public all the time. In actual, it also works similar to VPN having perimeter security but in a dynamic way. There should be a proxy separate from actual service for authentication and only authentication service is exposed to public traffic all time, while internal resource only accepts inbound traffic from IP address of user who has authenticated successfully and this is orchestrated in real-time by the authentication service. The traffic from same user to internal service is also denied the moment they log off, think of it like a dynamic iptables system. Another emphasis of zero trust model is to authenticate requests even when it's coming from the same internal subnet. Too many articles are misleading people that zero trust model is to take away perimeter security entirely.
Note: Exposing any internal services like SSH, message queues or databases directly to public is not the right approach, because they can get compromised when there's any RCE vulnerability.