Zero Trust Architecture in a Nutshell
At the very essence of ZTA, it is about knowing who is attempting to access what (resource) and whether this (access) is permitted.
So in the context of a client accessing a service/resource provider (e.g. API), a lot of factors can be considered before granting access, for example:
- Where the client is accessing from? Within the enterprise network, outside within the country or somewhere out in the world?
- What device is he using? Corporate or personal?
- Is the device healthy? Has it been patched? Did it posture change since the last time we learnt about it?
- Has the user accessed this service at this timing before in the past with this client?
- What was the previous resource accessed by this client?
- What was the business transactions made prior to this?
- Is the user authorized to access this service?
- Is the user authorized to access this function?
- Should we ask for a stronger proof of identity? Step up to 2FA from 1FA?
As you can see, it is no longer the case of simply granting access once identity and authorisation is verified. There is now a strong need to learn more about the request and evaluating it holistically before permitting or denying access.
With this understanding, I, personally, pretty distilled the ZTA to the following four main components:
- Centralized log management
- Access management Service proxy
- Resource policies
- Trust evaluation engine
Centralized Log Management
Logging and logs have a huge role to play in ZTA.
There is a need for a proper log management solution to capture logs, metrics, web applications, data stores, and various cloud services, all in continuous, streaming fashion. Not only ingesting, it should also transform and prepare data regardless of format or complexity for consumption by the trust evaluation engine.
Access management Service proxy
Service providers or application will now need be Zero-Trust Architecture aware.
These application could be rearchitected to work with the various ZTA components or a ZTA aware proxy can be in place to front requests infront of the application.
This is easier said than done. There is often a need for a mixture of solution to address this need.
For the protected application or resources, basic policy definitions could be in place to determine the minimum trust level required.
If thr request meets the trust level required, it goes to the resources. Otherwise, it will be ignored.
Trust evaluation engine
This is where all the magic and complexity is. The logs and metrics get evaluated and a trust score or level is determined.
If a user typically accesses from a personal device in country but the current request originates from a unknown device from a foreign location, the trust evaluation engine might tag a low trust level to the request. This would in turn result in the request being denied by access management service proxy and resource.
Similarly if the user typically uses a personal device to access resources on the enterprise network decides to access the resources from a cafe with the same device, the trust evaluation engine might prompt for a step up authentication (e.g. 2FA from 1FA) to tag a high trust level or tag a medium trust level with the preexisting authentication.
This evaluation can be based on a weighted metric or complex machine learning model that continuously evolve based on the real-time dataset generated by the entire organization.
There is no single right way to do this and no single approach is better than the other. It all depends on the resources available, schedule and goal.