We often get questions from folks about other companies claiming to compete with Veza. We wanted to take these questions as an opportunity to share some of our guiding principles on the Identity-First Security market and Veza’s unique approach to building our authorization platform. There is a lot of noise out there, and we're bullish about how quickly this market is expanding. We believe the noise is only going to get louder!
There is a group of vendors who are approaching the access control problem with an in-line architecture. This involves some component, like a proxy, sidecar, or agent, that sits between the data and the user/requester. In other words, exactly the same architecture that “man-in-the-middle” attacks leverage. Along with this comes a “new” policy framework (usually claiming to be simpler than what you’re using today) that the in-line component evaluates when it sees a flow of traffic. Often, these solutions include a way to request new access (a portal, workflow, etc.), and time-bound access policies.
At Veza, we believe the in-line approach suffers from four fatal flaws, impacting deployment, security, and availability:
Slow to deploy: the added risk and complexity of an in-line architecture necessitates lengthy security and infrastructure reviews before deployment can be deemed safe.
Downtime risk: because the solution is in-line, uptime becomes limited to the uptime of the solution (i.e., the weakest link in the chain). Downtime for the security solution impacts your data availability, potentially a large issue when dealing with production and revenue-impacting business processes.
New points of failure: because the in-line approach intercepts the data, security breaches or bugs in the solution itself can result in data loss or gaps in data integrity.
Policy complexity: these solutions have a new policy layer. Unless all other security policies are going to be removed on Day 1, the added complexity of understanding the overlap and interactions between all the existing policies and the new policies must be understood, monitored, and continuously evaluated.
The real-world results speak for themselves. Deployments of in-line solutions are relegated to narrow use cases, and tend to become features in other solutions rather than new platforms themselves. This type of solution isn’t suited to be widely used in the enterprise, given the multitude of SaaS applications, custom applications, data systems, cloud services and infrastructure services that the vast majority of companies use. Forcing users through a proxy for a service on the internet is an architectural and user-experience nightmare.
The Veza approach is different. Instead of an in-line agent or proxy, Veza pulls metadata from APIs to operate out-of-band. We leverage the native authorization policies and systems you already have and already use. Instead of adding a new layer, we make the existing layer do what it was supposed to do in the first place. The advantages of this approach are:
Fast to deploy: all that is required is a read-only role to integrate with the target systems.
No downtime risk: Veza doesn’t sit between users and the data they need.
No new points of failure: Veza never intercepts your critical data, only the authorization metadata.
Reduced policy complexity: Veza helps you understand and manage the authorization policies that you already use today, and improve them over time by actually operationalizing the principle of Least Privilege
In short, Veza was built for the real-world—see our Manifesto here. In-line solutions look good on paper; out-of-band ones are the practical solution. As more people realize this, it will become clearer that out-of-band architecture is the future of the identity-first security market. Help us spread the word about this important distinction and share my blog post on your favorite social channel. If you’d like to see more, come request a demo.
5 Actionable Strategies to Improve Security Posture
We did a deep dive into cyber security, identity security, and evolving digital threats. Implement…
A field guide to bad permissions part 2: expired permissions
Why expired permissions go unnoticed The main reason expired permissions go unnoticed is that it’s…