No longer straightforward
Today, the traditional borderline between inside and outside is blurring, and moreover, port-based filtering has become less valuable, since so much traffic is now tunneled over SSL. Think only of the ballooning of APIs. Web application firewalls seek to patch this, but have proven cumbersome, error-prone and difficult to maintain. Rethinking traditional perimeter-based network security into a holistic security approach – often called ‘deperimeterization’ – has now got its own strategy: “A Zero Trust Architecture (ZTA) strategy is one where there is no implicit trust granted to systems based on their physical or network location (i.e., local area networks vs. the Internet). Access to data resources is granted when the resource is required, and authentication (both user and device) is performed before the connection is established.” (NIST SP 800-207).
It seems nobody likes the label Zero Trust Architecture, but the strategy is gaining traction fast. After all, nobody is happy when finding out that, after investing millions in a web conferencing system, only people from inside the organization can connect, ending up in the peculiar situation that people from outside the organization – contractors, business partners, suppliers, clients – all are required to travel to your conference room while at the same time your own employees simply join from anywhere. And that is just one simple example. We now have the technologies in place to do a better job on security, with smarter means to control access to digital resources. Specifically, we have cloud native computing and API Management. Together, they can deliver on the promisee of zero trust architecture: a smarter and more effective information security. And this is how you make it work.
Making zero trust architecture work in your core
In a zero trust world, it’s still a good idea to start with asking yourself what kind of assurance you need in which case. Let’s suppose you practice domain drive design. Each domain is a coherent composition of microservices, preferably developed and operated by a single team, or a single release train, owned by a single product owner. Inside the domain, there is a common understanding on messages exchanged and data being shared. After all, the team shares a common language. You want to be able to freely use GRPC calls with protobuf messages, for instance. Or query quite freely on a GraphQL engine. Or share events in streams. Sure, a basic level of authentication will be needed. On Kubernetes, the regular control plane services provide pretty much all the security you need. You share a namespace, every microservice is identified by a unique name inside this namespace, and you’re fully in control of all the changes that happen inside your namespace. What more could you wish for? You don’t expose anything to the outside world but through your anti-corruption layer. In short, your trust is in the control plane to fence your domain off from outside. And if you cannot trust your control plane doing just that, then you should probably fix that at the root.
Making zero trust architecture work in your periphery
Across domains, things are a bit different. You still can rely on Kubernetes to identify sources and destinations, and to enforce your virtual network policies. But now, as part of your ‘anti-corruption layer’, you will probably do some additional validation and transformation. Here, binary messages are not appropriate. For validation and transformation purposes, you need clearly defined schemas, typically as part of a contract. If user authorization is part of your anti-corruption policy, a valid user token is the best way of identification. Yes, you have to trust a common identity provider, which is again a fundamental necessity you’d better get right in the first place.
Obviously, a microgateway is uniquely positioned to host your anti-corruption layer. Since a microgateway is closely tied to a single domain, and typically managed by people with intimate domain knowledge, a microgateway can do much more than just control access to your domain – as is the core business of an API Gateway. In that respect, the WSO2 API Microgateway is a bit of a misnomer. In fact, your microgateway might just as well act as an adapter for incoming messages. It might also act as an API Firewall and block any invalid message from entering. And, yes, you can now enforce fine-grained authorization policies too, just as your Zero Trust Architecture requires. This way, leaving all integration and access control logic to your gateway, you can prevent your code from being polluted by glueware. Clean code complemented by a smart integration hub to build a new level of trust. Sounds clever to me.
Smart APIs
Once you start communicating outside of your Kubernetes cluster, you enter a different world. This is a world pretty much without any authority to control access. So, an additional set of controls is needed. At this scale, you probably don’t want to do any deep message processing. Yet, as a firsts line of defense, you do want to keep close to all potential intrusions at bay. This is what API Management can do for you. And here’s how.
First, you probably want to be selective with the APIs you expose to the outside world. It is quite common, for instance, that resources are read-only in the outside. You can decide to limit access through scopes, and in some cases that would be fine. But in many cases, when you think about it deeply, your outside resource model is simply different from your inside model. It has a different justification, to start with. Also a different legal context. Hence you govern it differently. Also, it probably shouldn’t change that often. Actually, it’s more a product than just a resource.
Some of the differences are more subtle than you can define on the method level. You can, for instance, have full access to your own health insurance claims, limited access to that of your family members, and zero access to others. Your outside resource may be something like /myHealthInsurance, with /familly as subresource. Whereas, in the inside, you have /claims/{id}, /plan/{id} and /payments/{id}. With the id in the user token, these APIs can be mapped easily and securely, but at the same time, the more powerful lower-level APIs are simply not accessible directly. This eliminates an attack vector in a way you could never do if you would directly expose your internal APIs.
Identity as the new perimeter
Once you have your APIs defined, the next topic to consider is whom to grant access to use it. API Management gives you two options. One, through authorization, you can limit accessibility of APIs in the developer portal to specific groups of users. Often, however, there is more to granting access than a simple role assignment. You might want to verify a person’s identity, their bank account, or their affiliations. Basically, anything you need to trust his good intentions. That’s where you can use a custom workflow to decide on a subscription request.
Next, you can think of operational policies – a valid subscription, a valid token, user quota, monetization – that you want your API Gateway to enforce. Don’t forget the power a reliable token can bring. All the information you put in an identity token is from a trusted source. Often, identifiers in an API template introduce a vulnerability. If you can circumvent this by putting them in an identity token instead, you’ll be much safer off. In other words, Identity can be a smarter perimeter than simple authorization can do.
Finally, you want to monitor your API usage to evaluate the effectiveness of your policies. Based on usage, you may very well decide to revoke an API subscription you’ve first granted. Or to fine-tune your quota policies. Anything that can further increase the value of your API portfolio. In the end, that’s what counts.
API Management covers all your needs starting with API Definition up to API Analytics, and with the smart addition of WSO2 API Microgateways, you can start building trustworthy systems on an untrusted network. And you can trust Yenlo if you need a helping hand. Just ask.
