Zero Trust Webhook Security - AWS Lambda example
Zero trust webhook security provides strong identity, authentication, authorization, least privileged access and micro-segmentation. By locking down layer 3, you eliminate the grind of IP address, ACL and firewall management. In this example, with a couple of lines of code, a AWS Lambda webhook is consumed by an app server, without the app server being reachable from the networks:
The Challenge of Securing API Networking
APIs historically lived in private data centers, and were relatively limited in volume and scale. Now, two waves have converged to reshape this topology:
- Microservices. The transition from monolithic apps to microservice architectures multiplied API networking. APIs are now about 80% of Internet traffic, with 200% type annual growth rates.
- Hybrid and multi-cloud. Over 80% of enterprises are hybrid cloud, and almost 90% expect to be using at least two clouds by 2023. One key result is distributed APIs.
This has been great for business velocity. However, we now have an unprecedented amount of API networking across distributed sites, making secure networking very difficult. For example, Gartner stated that API attacks will become the most frequent attack vector for enterprise web apps in 2022. The key challenge is to better secure this new topology of massively distributed APIs, while still retaining the business velocity we need.
Read the API security whitepaper to learn how to mitigate against these challenges.
NetFoundry Zero Trust API Security Helps Respond To This New Challenge
Historically, API security focused on user identification, authentication and authorization techniques, e.g. claims-based authentication and authorization. That happens at layer 7 - *after* packets arrive at your public API perimeter element.
NetFoundry uniquely helps you applies the claims-based approach to layer 3 to block unauthorized sessions *before* they can get to your network. Your public API endpoints are transformed into private API endpoints, yet your API clients still reach them from the Internet!
API clients identify, authenticate and authorize before they are given network access to your (now private) API endpoint. You move the policy enforcement point to the origination of the session so only authorized traffic can access your API endpoint.
This new approach helps with all 10 of the OWASP top 10 API security risks, because it makes it much more difficult for attackers to get to your API endpoint in the first place (even if there are vulnerabilities further downstream that the attackers could exploit if they had layer 3 access). Read the API security whitepaper to learn more.