NIST SP 800-207A 日本語訳

Ramaswamy Chandramouli

Zack Butcher

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-207A

Ramaswamy Chandramouli Computer Security Division Information Technology Laboratory

Zack Butcher Tetrate, Inc.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-207A

September 2023

U.S. Department of Commerce Gina M. Raimondo, Secretary

National Institute of Standards and Technology

Laurie E. Locascio, NIST Director and Under Secretary of Commerce for Standards and Technology

Certain commercial equipment, instruments, software, or materials, commercial or non-commercial, are identified in this paper in order to specify the experimental procedure adequately. Such identification does not imply recommendation or endorsement of any product or service by NIST, nor does it imply that the materials or equipment identified are necessarily the best available for the purpose.

There may be references in this publication to other publications currently under development by NIST in accordance with its assigned statutory responsibilities. The information in this publication, including concepts and methodologies, may be used by federal agencies even before the completion of such companion publications. Thus, until each publication is completed, current requirements, guidelines, and procedures, where they exist, remain operative. For planning and transition purposes, federal agencies may wish to closely follow the development of these new publications by NIST.

Organizations are encouraged to review all draft publications during public comment periods and provide feedback to NIST. Many NIST cybersecurity publications, other than the ones noted above, are available at https://csrc.nist.gov/publications.

Authority

This publication has been developed by NIST in accordance with its statutory responsibilities under the Federal Information Security Modernization Act (FISMA) of 2014, 44 U.S.C. § 3551 et seq., Public Law (P.L.) 113-283. NIST is responsible for developing information security standards and guidelines, including minimum requirements for federal information systems, but such standards and guidelines shall not apply to national security systems without the express approval of appropriate federal officials exercising policy authority over such systems. This guideline is consistent with the requirements of the Office of Management and Budget (OMB) Circular A-130.

Nothing in this publication should be taken to contradict the standards and guidelines made mandatory and binding on federal agencies by the Secretary of Commerce under statutory authority. Nor should these guidelines be interpreted as altering or superseding the existing authorities of the Secretary of Commerce, Director of the OMB, or any other federal official. This publication may be used by nongovernmental organizations on a voluntary basis and is not subject to copyright in the United States. Attribution would, however, be appreciated by NIST.

NIST Technical Series Policies
Copyright, Use, and Licensing Statements
NIST Technical Series Publication Identifier Syntax

Publication History
Approved by the NIST Editorial Review Board on 2023-09-08

How to Cite this NIST Technical Series Publication:
Chandramouli R, Butcher Z (2023) A Zero-Trust Architecture Model for Access Control in Cloud-Native Applications in Multi-Location Environments. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-207A. https://doi.org/10.6028/NIST.SP.800-207A

Author ORCID iDs
Ramaswamy Chandramouli: 0000-0002-7387-5858

Contact Information
sp800-207A-comments@nist.gov

National Institute of Standards and Technology Attn: Computer Security Division, Information Technology Laboratory 100 Bureau Drive (Mail Stop 8930) Gaithersburg, MD 20899-8930

All comments are subject to release under the Freedom of Information Act (FOIA).

One of the basic tenets of zero trust is to remove the implicit trust in users, services, and devices based only on their network location, affiliation, and ownership. NIST Special Publication 800-207 has laid out a comprehensive set of zero trust principles and referenced zero trust architectures (ZTA) for turning those concepts into reality. A key paradigm shift in ZTAs is the change in focus from security controls based on segmentation and isolation using network parameters (e.g., Internet Protocol (IP) addresses, subnets, perimeter) to identities. From an application security point of view, this requires authentication and authorization policies based on application and service identities in addition to the underlying network parameters and user identities. This in turn requires a platform that consists of Application Programming Interface (API) gateways, sidecar proxies, and application identity infrastructures (e.g., Secure Production Identity Framework for Everyone [SPIFFE]) that can enforce those policies irrespective of the location of the services or applications, whether on-premises or on multiple clouds. The objective of this publication is to provide guidance for realizing an architecture that can enforce granular application-level policies while meeting the runtime requirements of ZTA for multi-cloud and hybrid environments.

egress gateway; identity-tier policies; ingress gateway; microservices; multi-cloud; network-tier policies; service mesh; sidecar proxy; SPIFFE; transit gateway; zero trust; zero trust architecture.

The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology (NIST) promotes the U.S. economy and public welfare by providing technical leadership for the Nation’s measurement and standards infrastructure. ITL develops tests, test methods, reference data, proof of concept implementations, and technical analyses to advance the development and productive use of information technology. ITL’s responsibilities include the development of management, administrative, technical, and physical standards and guidelines for the cost-effective security and privacy of other than national security-related information in federal information systems. The Special Publication 800-series reports on ITL’s research, guidelines, and outreach efforts in information system security, and its collaborative activities with industry, government, and academic organizations.

NOTICE: ITL has requested that holders of patent claims whose use may be required for compliance with the guidance or requirements of this publication disclose such patent claims to ITL. However, holders of patents are not obligated to respond to ITL calls for patents and ITL has not undertaken a patent search in order to identify which, if any, patents may apply to this publication. As of the date of publication and following call(s) for the identification of patent claims whose use may be required for compliance with the guidance or requirements of this publication, no such patent claims have been identified to ITL. No representation is made or implied by ITL that licenses are not required to avoid patent infringement in the use of this publication.

The authors would like to express their thanks to Isabel Van Wyk of NIST for her detailed editorial review of the public comment version as well as the final publication.

The principles of zero trust, as described in NIST Special Publication (SP) 800-207, have become the guiding markers for developing secure zero trust architecture. A well-established class of applications is the cloud-native application class. The generally accepted characterization of a cloud-native application includes the following:

The realization of a zero trust architecture for the above class of cloud-native applications requires a robust policy framework. In order to follow zero trust principles, the constituent polices in the framework should consider the following scenario:

This document provides guidance for realizing a zero trust architecture that can enforce granular application-level policies for cloud-native applications. The guidance is anchored in the following:

Zero trust (ZT) tenets or principles have been accepted as the guide markers for architecting all applications. There are several reasons why adherence to these tenets is critical for obtaining necessary security assurances, especially for cloud-native applications. The enterprise application environments for this class of applications are highly geographically distributed and span multiple cloud and on-premises environments (e.g., headquarters, enterprise-operated data centers, branch offices). Further, the user base consists of both remote and on-premises employees. These two features call for establishing trust in all of the data sources and computing services of the enterprise — irrespective of their location — through secure communication and the validation of access policies. Apart from geographic distribution, another common feature of cloud-native applications is the presence of many microservices that are loosely coupled and collectively support business processes through extensive inter-service calls. This is augmented by an integrated infrastructure for providing all application services called the service mesh. These features emphasize the concept of identity for the various components of the application in the form of microservices as well as the users who access them through direct calls or clients (other services). This in turn highlights the critical need for authenticating these identities and for providing legitimate access on a per-session basis through a dynamic policy that takes the current status of the user, service, and requested resource into account. The above requirements can only be met through a comprehensive policy framework. This document provides guidance for developing a policy framework that will form the foundation for realizing a zero trust architecture (ZTA) while incorporating zero trust principles into its design for cloud-native applications. The policy framework should also consist of a comprehensive set of policies that span all critical entities and resources in the application stack, including the network, network devices, users, and services.

A summary of the zero trust principles and the definition of a zero trust architecture, as described in SP 800-207, Zero Trust Architecture [1], are:

NIST’s guidance on zero trust also contains an abstract definition of zero trust architecture and gives general deployment models and use cases with which zero trust could improve an enterprise’s overall information technology security posture.

Since the current document provides guidance for the realization of ZTA for cloud-native applications hosted in multiple locations (on-premises and multiple clouds) and the enforcement of ZT principles requires policies that are associated with various security services, it will be useful to refer to the following documents. These documents provide background information for the architecture of a microservices-based application with service mesh as well as guidance for configuring specific security services. The current document expands the reference environment to one in which the Information Technology (IT) application infrastructure of an enterprise spans multiple premises and multiple cloud provider locations as well as addresses the range of policies that is required for comprehensive security assurance.

The scope of this document includes:

The reference application platform consists of microservices-based applications using a service mesh with sidecar proxies as the application services infrastructure. The service mesh technology variation that uses a sidecar-less approach is not considered as the deployment of this technology is still in early stages.

This guidance is intended for security architects and infrastructure designers in organizations with a hybrid IT environment (consisting of both on-premises and multiple cloud-based applications) with a combination of legacy and microservices-based (i.e., cloud-native) applications and a built-in application services infrastructure, such as a service mesh.

The organization of this document is as follows:

An enterprise cloud-native platform is increasingly made up of microservices that are implemented as containers and hosted on a container orchestration platform. In addition, it has a dedicated infrastructure layer called a service mesh, which provides a comprehensive set of application services (e.g., network connectivity, network resilience, observability, and security). These application services are enabled by the following:

In the modern enterprise, the platform described above is present in both on-premises data centers and multiple cloud service locations. Assuming that a service mesh instance is deployed for managing a single cluster that consists of the above platforms, there will be multiple clusters spread over multiple on-premises sites and multiple availability zones in different clouds. Consequently, there will be multiple service mesh instances. Each service mesh instance has two main logical components: 1) a control plane that implements the APIs needed to define various configurations and policies that govern access between various microservices in that cluster and 2) a data plane that enforces those policies at runtime. However, a uniform set of policies is also needed to govern access between any pair of microservices or services in the enterprise irrespective of their location or the service mesh instance of which they are a part. This requires a global control plane that can define a uniform set of policies applicable to the entire set of services that operate in the enterprise and disseminate them to the control planes of the individual service mesh instances. It is technically possible to have a single service mesh control plane instance (i.e., single service mesh instance) that manages multiple clusters spanning multiple environments (i.e., on-premises and on clouds). However, this architecture may make the multiple clusters a single failure domain and potentially defeat the very purpose of designing a multi-cluster configuration (i.e., availability). Thus, running a service mesh control plane instance for each cluster isolates the failure domain and improves availability and scalability. Further, providing the required underlying network connectivity to facilitate every workload (since each workload or application instance has an associated sidecar proxy that forms the data plane) to communicate with a single control plane instance is untenable in most enterprise environments and impossible in many government ones (e.g., air-gapped systems).

The global control plane forms an integral part of the enterprise infrastructure layer. The management plane that contains the various interfaces is hosted within the global control plane. The roles of the global control plane and the management plane are as follows:

In short, the management plane enables the definition and deployment of consistent and uniform policies for all services throughout the enterprise. In addition to the global control plane and management plane, the enterprise infrastructure for a ZTA consists of local control planes (associated with service mesh instances) and a set of various types of proxies that form part of their respective data planes. The proxies act as the policy enforcement points (PEPs) and have three types:

Figure 1 shows a schematic diagram of the entire infrastructure layer for uniform (enterprise-wide) policy deployment for realizing a ZTA.

Fig. 1. Enterprise infrastructure layer for uniform policy deployment

Based on the set of zero trust principles and some strawman ZTAs provided in [1], the following driver assumptions were formulated for realizing a ZTA for an enterprise cloud-native application environment (i.e., a set of microservices in various clusters with each cluster managed by a service mesh and augmented with an enterprise-level infrastructure that consists of a global control plane and management plane). These driver assumptions are:

The above driver assumptions provide the design requirements for a ZTA as follows:

The following policy checks should be implemented at runtime through the deployment of identity-tier policies in order to realize identity-based segmentation:

Note on the above recommendation: In an ideal situation, services would be authenticated for each service request. Since this is highly disruptive from the point of view of application transaction response, this authentication is accomplished at the connection level via mutual Transport Layer Security (mTLS) when a service makes an initial connection establishment as part of its inter-service call. This authentication is not performed again in subsequent calls. However, the security of this operation is ensured by not allowing the connections to be very long (usually as long as the time to live [TTL] of the service’s identity certificate or as short as 15-30 minutes, depending on the configuration).

Note on the above recommendation: Authenticating the user in session at every hop is impractical at scale. Therefore, NIST recommends using short-lived end user credentials (e.g., OAuth 2.0 tokens) for external users and exchanging them for a locally authenticatable token, like a JWT, that is authenticated at each hop.

Context for the application of these policy recommendations and the improved security assurance that emanates from their deployment and enforcement are explained in [2] and [3].

While identity-based segmentation is powerful, purely identity-based policies cannot currently be adopted due to the following scenarios:

Network-tier policies cannot be completely eliminated given current compliance requirements (e.g., PCI/DSS) and regulations. However, relaxing requirements at the network level in exchange for introducing more descriptive policy at the identity level could lead to an improved overall security posture compared to network-tier security alone.

A successful enterprise ZTA requires multi-tier policies that combine network-tier and identity-tier policies:

Multi-tier policies can be implemented realistically and are non-disruptive to current compliance practices. Other tiers of policy also exist. For example, in the context of the service mesh, there are “application-tier” policies, which apply to the application payload itself. These include coarse-grained Web Application Firewall (WAF) rules, fine-grained rules like Spring Cloud Gateway payload validation, and the validation of request semantics via tools like the Open Policy Agent (OPA). Many can even be enforced by a service mesh, but those policies are beyond the scope of this document. The difficulty with having all network-tier policies is that policies expressed through firewall rules have to be continuously changed, depending on the application pair behind those firewalls. The flexibility in having multi-tier policies is that network-tier policies can be relatively static while identity-tier policies higher up in the stack (e.g., service to service) can be dynamic, as illustrated in Fig. 2.

Fig. 2. Flexibility provided by multi-tier policies.

Implementing identity-tier policies is also a more agile process that allows for new policy capabilities, such as writing policy in terms of identity and application-level action and verb. For example, a network-tier policy would describe the subnets that contain application instances of the client being allowed to call the subnet on a specific port. In contrast, an identity-tier policy would allow the client application identity to communicate with the server application identity via Hyper-text Transfer Protocol Secure (HTTPS) on port 443 and execute only the GET method on the public path. The full range of policies that an enterprise ZTA implemented via a service mesh can enable is outlined in [2] and [3]. Implementing multi-tier policies by relaxing network-tier policies (e.g., by allowing communication across a set of gateways) while introducing identity-tier policies with advanced layer seven controls results in a better overall security posture than either a purely identity-tier or purely network-tier approach.

This section will consider the implementation of multi-tier policies for realizing an enterprise ZTA using a reference enterprise scenario in which an enterprise hosts microservices applications in several clusters. Each cluster is serviced with a service mesh instance, and clusters are spread out both on-premises and in multiple clouds. Section 4.1 outlines a simple application infrastructure scenario, and Section 4.2 presents a sample set of associated policies that is relevant for that context. Section 4.3 shows how the same set of policies can be defined and deployed for a realistic application infrastructure scenario in which the incoming traffic comes through a demilitarized zone (DMZ).

Consider an application infrastructure of an enterprise where the application topology spans a cloud and on-premises environment. The applications are implemented as microservices with a service mesh instance for each cluster. Hence, a sidecar proxy is associated with each service. At the entry and exit points of each cluster are ingress and egress gateways, respectively. The same data plane (e.g., open-source Envoy) can be used to implement both the sidecar proxy and the transit gateways. Next, consider establishing policies for a scenario that involves two services — Service 1 and Service 2 — that reside in clusters in a cloud and on-premises, respectively. Service 1 in the cloud cluster can interact with services outside of the cluster through an egress gateway. Similarly, all services that attempt to access Service 2 from outside of the cluster have to go through an ingress gateway. All traffic coming out of the cloud has to go through an outbound firewall, and all traffic coming on-premises has to come through an inbound firewall. The paired egress-ingress proxies and the firewall rules that allow them connectivity are collectively referred to as a “transit gateway”. Each network location for the two services is designated by a subnet address. The application topology and policies described so far are shown in Fig. 3.

Fig. 3. Multi-tier policies for a hybrid application environment

The service mesh has a unique role within the overall policy life cycle activities of policy definition, deployment, enforcement, and update. As already stated, the service mesh is a dedicated infrastructure that provides all application services, including security controls like secure communication and application-level access control. These services are only possible if there are also policies to enforce them during application runtime. Based on the discussion of the control plane in previous sections, it should be clear that this component of the service mesh provides access to the interfaces of various policy definition tools through which policies can be defined and updated. Thus, the control plane of the service mesh acts as the policy administration point, while the underlying policy tools become the policy decision point. In addition, the control plane also enables those policies to be distributed to the various proxies described in the previous section. Once distributed, these proxies intercept all traffic in and out of the applications, where it acts as a universal policy enforcement point. This allows the service mesh — which centrally manages a fleet of the applications’ proxies — to become the modern cloud-native security kernel [3]. The proxies — especially the sidecars — can enforce security and traffic policies and generate telemetry data to allow operators to close the loop on policy changes by authoring a change, observing its effect on the runtime, and making additional changes as needed in a real-time feedback control loop. In other words, the mesh provides the needed capabilities to implement the runtime controls and achieve a zero trust posture.

Connectivity (between network elements) and access policies (between service instances) are network-tier policies and identity-tier policies, respectively. Consider the following example set of policies that contain a combination of network-tier and identity-tier policies. Network-tier policies can be further categorized into coarse-grained and fine-grained policies.

Firewall: allow 10.100.2.3/30 15443 to 10.1.2.3/30:15443

Fig. 4. An example authorization policy in a Service mesh that allows Service 1 to Service 2 on port 443 but only allows it to execute the GET HTTP verb on the “/public” path

This simple example shows some of the advanced capabilities that identity-tier policies can achieve by limiting access based on the application request context. Specifically, this policy limits the application actions to a single HTTP verb on a specific path, but a much more sophisticated policy can be implemented as well. See [2] and [3] for detailed overviews.

Consider another common application scenario in which there is an internal (i.e., within a cluster in the enterprise data center) three-tier application. This application is accessed from outside (through a mobile app or website) through a DMZ. This scenario consists of edge gateways present in the DMZ — an ingress gateway and an egress gateway at the entrance and exit points to and from the data center with firewalls at either side of the gateways. Each of the services that represent the front end and back end (application logic) of the three-tier application have to have a sidecar proxy to enforce policies that pertain to inter-service call requests. This scenario requires the definition and deployment of a combination of network-tier and identity-tier policies that span the various types of gateways and sidecar proxies. Deploying policies at these multiple locations requires an enterprise-level infrastructure that plays the role of a global control plane, as described in Section 2.1. This is designated as a central coordination infrastructure, as shown in Fig. 5.

Fig. 5. Policy deployment for a three-tier application

This section discusses the functionality of each of the application infrastructure elements involved in the policies (e.g., firewalls, gateways, sidecar, transit, and edge proxies). Since the functionality of firewalls that take part in this context for coarse network-tier policies is well known, this section focuses on the functionality of gateways that take part in fine-grained network and identity-tier policies:

Network-tier policies are necessary for geographically distributed application infrastructures and for meeting the compliance requirements of regulators. However, having a combination of network-tier and identity-tier policies allows for some relaxation of the network-tier policies as any unauthorized traffic flow due to an overlooked network element in the path can be addressed through flexible service identity-tier policies. In order to appreciate the need for the coexistence of both policy tiers, it is necessary to know the characteristics of both tiers of policies. This layering of policies, whose strictness can be tuned per organizational needs at each tier, provides agility and operational ease over status quo perimeter-based models while enhancing the overall security posture of the organization.

In this approach, applications and service resources with similar security requirements are grouped into a unique segment, and firewall rules are created to block or allow communication with each group or segment [5]. The segments are created using network layer abstractions (e.g., Virtual Local Area Network (VLAN) IDs or some other tagging approaches), while policies are defined using network address constructs (e.g., IP addresses and ports). Policies apply to subnets (e.g., VLANs) rather than to individual hosts. The assignment of applications to a particular segment can be based on different criteria, such as “all applications with similar security requirements” or “all tiers (e.g., web front end, application logic servers, and database servers) associated with a particular application should run in a single segment”. Each segment is protected by gateway devices, such as intelligent switches and routers or next-generation firewalls, that should have the capacity to react and adapt in response to the threats and changes in the application workflows. Segmentation gateways monitor traffic, stop threats, and enforce granular access across east-west traffic (rarely for north-south traffic) within on-premises data centers or cloud regions. The main difficulty with this approach is in mapping the applications’ security requirements-based segments to corresponding network segments. Another difficulty is change management. The mapping between applications and network identities that are being statically maintained has to be kept in sync with the operational scenario in which the application’s network locations are continuously changing due to performance and security. More modern cloud-native deployments that leverage techniques like container network interface-driven network policy are good improvements because they provide identity-tier style policies (i.e., policy in terms of identities and non-network-oriented nouns) while implementing that policy at the network layer (e.g., via Extended Berkeley Packet Filter (eBPF) policy or Border Gateway Protocol (BGP) propagation rules). These are a strong upgrade from traditional microsegmentation because they tend to result in finer-grained policies that are easier for the organization to manage over time. However, they typically lack the ability to apply per-request policies in the context of the application, which is needed to achieve identity-based segmentation.

Identity-tier policies use contextual, application-driven identifiers (e.g., “order processing front-end service can communicate with inventory back-end service”) instead of network parameters (e.g., “permit calls from 192.168.10.0/24 subnet to 10.0.0.31”). The identifiers assigned to services at runtime are cryptographic identities, which are used for mutual authentication and authorization during each service request and response. Deploying identity-tier policies requires a standardized infrastructure for creating, issuing, and maintaining tamper-proof service identities. Some of the components of this infrastructure are outlined below and also discussed in [5]:

These allowable flows can be based on either (a) the structure of the application (i.e., “the front end of application 1 can call the back end of application 1”) or (b) a legitimate business transaction (e.g., “order processing application can call the shipping application”). Often, organizations do not know all of the allowable service requests in their infrastructure. However, the observability capabilities of the infrastructure (e.g., the metrics provided by the service mesh) can be leveraged to build a view of “requests made today”. From that view, the organization can create fine-grained policies for allowable service requests. Utilizing this observe-and-lock-down methodology builds the organizational processes required to maintain the life cycle of these policies over time.

Policies based on service and application identities do not use any infrastructure-related variables (e.g., IP addresses, subnets), so they are environment-agnostic and provide the freedom for the services and applications to be migrated to different environments and still maintain the same policies. In other words, there can be a consistent set of policies across cloud providers and on-premises because the policy follows the application rather than the network.

Additional advantages include:

Identity-tier policies enable only valid network traffic between the various component services of the application due to the mutual authentication and authorization of the service identities, thus enabling the goals of zero trust network access (ZTNA) to be met.

To realize the goals of all types of policies (e.g., coarse- and fine-grained network policies, identity-tier policies), it is necessary to have a monitoring framework as part of a ZTA. The salient features of the two tenets called out in SP 800-207 (Section 2.1) for ZTA are:

The requirements for the monitoring framework in the context of cloud-native applications are:

The monitoring data, derived analytics, and telemetry data should be used in the following ways to realize zero trust principles for cloud-native applications:

This document provides guidance for realizing a ZTA for cloud-native application platforms (microservices with a service mesh infrastructure) in the context of an enterprise environment in which applications are hosted in multi-cluster and multi-cloud deployments. A ZTA consists of deployment artifacts that enforce zero trust principles, which is only possible with robust, flexible, scalable, and granular policies that cover all enterprise resources. A policy framework that consists of network-tier and identity-tier policies to meet these goals has been proposed in this document. The artifacts needed for the definition, deployment, and enforcement of these policies have been discussed along with examples of network-tier policies and identity-tier policies. The applicability of these policies in modern enterprise application infrastructures is also illustrated. Finally, the policies that belong to the two tiers are compared in terms of their advantages and limitations, and the critical role of identity-tier policies for realizing a ZTA in the context of modern cloud-native application infrastructures is emphasized.

[1] Rose S, Borchert O, Mitchell S, Connelly S (2020) Zero Trust Architecture. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-207. https://doi.org/10.6028/NIST.SP.800-207 [2] Chandramouli R, Butcher Z (2020) Building Secure Microservices-based Applications Using Service-Mesh Architecture. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-204A. https://doi.org/10.6028/NIST.SP.800-204A [3] Chandramouli R, Butcher Z, Aradhna C (2021) Attribute-based Access Control for Microservices-based Applications using a Service Mesh. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-204B. https://doi.org/10.6028/NIST.SP.800-204B [4] SPIFFE (2022) SPIFFE Concepts. Available at https://spiffe.io/docs/latest/spiffe-about/spiffe-concepts/ [5] Chandramouli R (2022) Guide to a Secure Enterprise Network Landscape. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-215. https://doi.org/10.6028/NIST.SP.800-215 [6] Chickowski E (2022) Implementing Zero Trust in your Enterprise: 8 Ways to get Started. Available at https://www.informationweek.com/whitepaper/network-and-perimeter-security/endpoint-security/implementing-zero-trust-in-your-enterprise-how-to-get-started/441133