*Republished with permission from VMblog.com.
Traditionally, Zero Trust has been focused on moving beyond the network perimeter. But with the growing use of APIs, Zero Trust is increasingly about API security. VPN-based solutions to Zero Trust security challenges are shifting the perimeter, but not going beyond it. Proper authorization at the API layer allows you to go beyond perimeter security and make a leap forward in achieving Zero Trust security.
What is Zero Trust?
At its core, Zero Trust is about no longer establishing trust based on where you’re coming from in a network. Your location on the network is not sufficient anymore, and you need to present something to compensate for that, which often takes the form of tokens. Applications function with APIs nowadays, so you’re sending a token to consume an API, and Zero Trust security is achieved by shifting trust from a network perimeter assurance to authentication and authorization of the identities associated with the API requests.
Public vs private APIs
For an organization exposing APIs, it is common to classify APIs with two categories: “private APIs” and “public APIs.” Public vs. private APIs can mean multiple things, but often it refers to whether or not they are available on a public network. In this case, applying Zero Trust principles to API security should dictate that every API be classified as public since the perimeter can no longer constitute the basis of security. API reclassification requires an organization to consider adding token-based authorization to existing APIs.
Another way to look at public vs. private APIs is to consider whether they are only meant to be consumed by the organization they belong to or are open for other teams or even third parties to adopt as part of their services or applications. By shifting how we classify APIs as public, an organization not only improves its security but opens up new innovation and collaboration opportunities. Perhaps your developers aren’t looking for new ways to create new experiences, but somebody else might be. And opening up your APIs allows you to participate in somebody else’s innovation and benefit from it.
Zero Trust, an integration challenge
Prior to Zero Trust, when security was based on the perimeter, the user experience tended to be simple: it worked if you were inside the perimeter and did not otherwise. When this is no longer the case, some form of authentication or entitlement check needs to happen.
The burden associated with this cannot rest on the end-user. User experience expectations raise the bar on how much integration needs to happen behind the scenes. To deliver a frictionless experience, the application might need to orchestrate a handshake with a trusted identity provider. It might need to fetch information about users, their privacy preferences, their entitlements, and the risk associated with a transaction. This integration is addressed by APIs and API gateways, configured to work with centralized authorization services and integrating with data services, identity directories, event-based APIs, microservices, etc.
API discovery and observability
APIs multiply fast. It’s hard to keep up with the IT sprawl they create. We recently learned that the average enterprise has two to three API management gateways from different vendors, and plans to adopt more soon. If your APIs are spread out across multiple platforms with disconnected governance, Zero Trust security is harder to standardize on.
Research also shows that organizations aren’t confident that they have a full inventory of all the APIs they expose in these various API silos. You can’t secure what you’re not aware of, and a centralized API management plane that discovers all APIs as they are added in their respective silo and provides centralized API observability is an essential ingredient for moving forward with Zero Trust.
Monitoring APIs is not just looking at performance metrics: API analytics show trends in how your APIs are used — or abused. Reports on the policies enforced in your various API silos allow you to validate your implementation against security objectives.
Addressing security at the API layer
Addressing security at the API layer produces a more agile application where rules are decoupled from business logic and policies can be added or modified on the fly without affecting back-end implementation. By treating your private APIs as public APIs and applying adequate token-based security, you improve your security posture and no longer depend exclusively on perimeter security.
Read the original article from VMblog.com.