[HN Gopher] Unpacking the Benefits of Zero Trust Architecture as...
___________________________________________________________________
Unpacking the Benefits of Zero Trust Architecture as Defined by
NIST
Author : CKMo
Score : 75 points
Date : 2023-02-17 16:43 UTC (6 hours ago)
(HTM) web link (www.pomerium.com)
(TXT) w3m dump (www.pomerium.com)
| barathr wrote:
| Zero Trust certainly has its benefits over the old perimeter-
| based model, but it also requires new, and massive, trust in
| third-party cloud providers. A bit more on that:
|
| https://invisv.com/articles/zerotrust.html
|
| What we need to move towards is something more like Oblivious
| Trust -- you rely upon third parties but they have nothing
| sensitive in the first place.
| pclmulqdq wrote:
| I actually have been working on a startup that is trying to
| work on reducing your reliance on trust in your infrastructure
| providers: we basically let you put your "perimiter" checks
| inside a piece of hardware that you control completely within a
| cloud service, and that takes the cloud provider out of the
| equation - and it should take us out of the equation too, since
| you host the instances.
| mjg59 wrote:
| Describing "Zero Trust" as a misnomer when it's a reference to
| placing no inherent trust in the client seems misleading. Yes,
| you have to place trust in whatever makes the trust decision,
| whether that's you or a third party. And you also have to place
| trust in whoever is providing device or user identity in the
| first place. There are certainly techniques you can apply that
| mean that accessing a service only provides that service with
| "this user legitimately has access to this resource" rather
| than any information about the specific user, but someone has
| still had to make the determination that that user is
| trustworthy, and they need to have held information about that
| user to make that determination.
| unethical_ban wrote:
| Well that's a lot to read and I should queue it up. But I think
| you're overselling the risk.
|
| Zero-trust means moving the authn and authz from a perimeter
| around the whole ecosystem of tools for your org, down to the
| individual apps. Every app, every tool you were using in an old
| system, could still log your IP/username/login/logout times.
| Now, we're saying "hold up, use 2FA and better RBAC at all
| times" per application, instead of assuming an entity is
| partially trusted because of where they are on the network.
|
| I think ZT can be implemented in or out of the cloud. It just
| happens that people are coupling a move toward ZT with cloud
| identity managers like Okta, and cloud services like AWS.
| waihtis wrote:
| is oblivious trust an existing concept or did you cook it up ad
| hoc for this reply?
| barathr wrote:
| It's something we wrote about in the post I linked.
| mc32 wrote:
| Zero knowledge as a term seems to lend itself to this
| concept.
| gz5 wrote:
| If your needs can be summed as 'only trust entities which you
| explicitly trust, while doing continuous verification and least
| privilege', then use something like OpenZiti or WireGuard.
|
| To be fair, most orgs _don 't_ have those needs. Most zero
| trust implementations were in fact _not_ motivated by zero
| trust. It was more like the VPNs were backhauling user-
| >big_cloud_provider_hosted_app connections through bandwidth-
| constrained private data centers. Acceptable (or not a top
| priority to fix) when remote work was a fraction (for most
| orgs). Not acceptable for all orgs once C-19 hit. "Zero trust"
| from the big vendors took the connections direct (via their
| clouds).
| JamesAdir wrote:
| You will always need to trust someone. How did you trust your
| hardware such as laptops and network equipment so far? So
| either you trust the vendor, or you're trusting a 3rd party
| that checks the hardware for you and give you some form of
| approval.
| michaelt wrote:
| IMHO there's a huge gap between "trust this dell hardware not
| to contain hardware implants" vs "trust cloudflare warp to
| MITM every SSL connection I make"
| mjg59 wrote:
| The conflation between "Zero Trust" and "Zero Trust
| implemented with third-party infrastructure" is unfortunate
| - I think it's reasonable to feel uncomfortable with a
| third party being in a hyper-privileged position to
| effectively assert access to your infrastructure, but
| that's not inherent to Zero Trust and we shouldn't frame
| the conversation in such a way that assumes that it is.
| remram wrote:
| How so? Do you mean because a hardware mod would be
| physically detectable, maybe?
| attentive wrote:
| Ha, MITM SSL... My pet peeve is crowdstrike having
| root/admin RCE backdoor on every server/client OS. Talk
| about trust.
| out-of-ideas wrote:
| ive always correlated zero-trust with that which was recently on
| top of HN: https://dilbert.com/strip/2023-02-11
|
| treat your employees like cattle; see how far that will go
| [deleted]
| EGreg wrote:
| Anyone know Ziti?
| PLG88 wrote:
| I know OpenZiti very well (I work on the project)... whats the
| question?
| colinrand wrote:
| With many new ideas, the early folks love the benefits and aren't
| put off by the challenges. With ZTNA, after doing quite a few
| deployments myself, I can say that the biggest challenges are
| operational. Nothing will piss off developers more than having
| had access to a resource one day, lose it unexpectedly, and then
| not know who to track down to get it back. Or, users hating on
| their VPN, want something else, and then that something else
| (often just another VPN provider) works differently and causes
| them disruptions. ZTNA is a long journey, not a quick fix.
| timcavel wrote:
| [dead]
| [deleted]
| CKMo wrote:
| It is indeed a continuous process, like devops!
| [deleted]
| cscheueuer wrote:
| Has anyone used Pomerium and is it any good compared to Tailscale
| or Twingate?
| CKMo wrote:
| https://www.pomerium.com/comparisons/tailscale-with-pomerium...
|
| The tools do different things. Pomerium plays well with
| Tailscale.
| Aaronstotle wrote:
| I'm testing Twingate out now and I've gotten lot of good back
| from Engineers. Curious to know as well
| badrabbit wrote:
| Zerotrust is cancer.
|
| I dismissed it a few years ago as a harmless hype but I am now
| seeing real harm being caused by this hype.
|
| To avoid writing an essay here let me keep it short and explain
| why: I am seeing orgs spending valuable time, money and resources
| on box checking and implementing false security all over. It is
| being used in place of improving security posture that is aware
| of threat context facing the organization. It has scope-creeped
| beyond the original intended purpose of ensuring all actions are
| explicitly authorized and eliminating implicit trust to mean a
| buch of ridiculous goals and hype words no one can explain
| consistently.
|
| I caution everyone to avoid using the term but to still implement
| the original beyondcorp architecture.
|
| Another cancer that is begining to spread:"passwordless".
| cscheueuer wrote:
| What is the easiest way to implement the original beyondcorp
| architecture without spending multiple months building a
| solution in house?
| eikenberry wrote:
| Isn't this basically true of every tech idea once it hits the
| enterprise? Agile is the usual whipping boy paraded when
| discussions of enterprise ruining something but it seems just
| true in general. As a problem I think this mostly boils down to
| technical decisions being made by non-technical people. Like
| many articles about Zero-Trust (some easy examples here in the
| comments) come out of the gate talking about AuthN, which is
| inherently about trust, they just don't seem to get it.
| [deleted]
| tinglymintyfrsh wrote:
| I don't know what "zerotrust" is supposed to mean. Maybe
| they're stretching the meaning of zero knowledge constructions.
| "Zero knowledge" should mean "the service provider never keeps
| logs, data, metadata, or secrets in the clear that can be
| retrieved without user intervention, preferably not knowing
| anything about any particular user." MEGA is partially this.
|
| "Passwordless" isn't terrible if it means "use a physical
| device or TPM-stored secret instead of a password". It
| shouldn't replace 2FA by having 2 actual factors.
___________________________________________________________________
(page generated 2023-02-17 23:00 UTC)