This article outlines an approach to model NIST’s Zero Trust Security Architecture while migrating to MS Azure but still working with hybrid cloud deployments, and using tools and services offered by Azure.
What Is a Zero Trust Architecture (ZTA)?
The term ZTA has been in use in the domain of enterprise security models and architectures for organizations since 2010 when Forrester coined the term but became popular after NIST published it as a framework (SP 800-207, final version published in Aug. 2020). ZTA further got a lot of visibility after the US govt recently mandated all Federal agencies to adopt ZTA.
ZTA evolves security much beyond the scope of the conventional perimeter (AKA enterprise firewalls) based approach. Its core principle is that organizations should not automatically trust anything inside or outside their perimeter(s) and, instead, must verify anything and everything trying to connect to their systems before granting access.
So, no access should be granted to any resource unless we know who wants to access it and if the principle of least privilege (POLP) is satisfied.
Tenets of ZTA and how Azure-Based Tooling Can Be Employed
I will try to elaborate on the core tenets of ZTA as per NIST (Italicized) and, then, propose the corresponding mapping in the MS Azure services and tooling.
To begin with, following basic infrastructure/configuration changes or enablement of services is a must.
Micro-segmentation: Broad perimeters need to be broken down into smaller networks, each having its own network access. This micro-segmentation approach reduces the threat surface area significantly. In Azure, it’s easily doable using a variety of virtual networks (VNets), each with its custom configuration of Network Security Group (NSG) to restrict the visibility of the resources within the VNets to only desired networks.
A set of microservices can be easily segmented out this way for limiting access on the network.
Azure AD and IAM: Subscribe to Azure Active Directory (AAD), Azure Active Directory Identity Protection, and Azure AD Privileged Identity Management (PIM). This will require AAD Premium P2 licenses.
These advanced tools help with several aspects of Zero Trust Architecture is covered below. AAD can also manage users and groups for hybrid environments very well. There is also an option to use a federated authentication model.
1. All data sources and computing services are considered resources. A network may be composed of multiple classes of devices. A network may also have small footprint devices that send data to aggregators/storage, software as a service (SaaS), systems sending instructions to actuators, and other functions. Also, an enterprise may decide to classify personally owned devices as resources if they can access enterprise-owned resources.
Azure AD allows for the provisioning of users and configuring identity and access management (IAM) for the users using its portal. In addition, it allows for device registrations. Users can register their work as well as personal devices as “trusted” ones. Users get SSO ability as a benefit.
Azure also allows managed identities which allow for machine/application to machine/application access without requiring specific access granted to individual users. One can also create service principal objects and register applications in Azure AD. Together they satisfy SaaS scenarios.
2. All communication is secured regardless of network location. Network location alone does not imply trust. Access requests from assets located on enterprise-owned network infrastructure (e.g., inside a legacy network perimeter) must meet the same security requirements as access requests and communication from any other non-enterprise-owned network.
For our use cases, this tenet primarily meant API calls from inside the firewall need to be secured as well. Using TLS even for internal API calls/requests, making them offload at API Gateway, which then routes the requests as per rules defined.
#cloud #security #architecture #azure #enterprise security #azure hybrid cloud
