There are many different definitions, implementation patterns, and implications of a zero trust architecture (ZTA) in the IT industry today. While Esri is not in a position to define or implement a ZTA strategy for a given organization, ArcGIS is a suite of software and tools that operates within an IT environment and is increasingly subject to the constraints, rules, and policies that a ZTA may implement. Some of the considerations for using ArcGIS with ZTA are described below.
The ArcGIS system is designed from a software architecture perspective to rely on certain assumptions for network access, openness, and compatibility, an approach that is also referred to as implicit trust. With this design approach, deploying ArcGIS into a ZTA environment may present challenges or functional limitations without a careful understanding of an organization’s ZTA strategy, and a clear planning and implementation approach.
Esri has, and continues to work to meet the demand for ZTA-ready deployment patterns in each software release. In many ways, ArcGIS supports ZTA-like security postures today, as the software can be configured to require authentication from all users, carefully manage permissions, and authenticate all users of remote applications or clients before viewing or accessing data. Whether this existing security posture sufficiently meets the security requirements for a specific organization is a decision that must be made by an organization after careful review and consideration.
In practice, most organizations implement ZTA using a combination of new policies, new technologies, and new network architectures. Generally, this involves moving away from the wide area network (WAN) style of network deployment, where communication between systems on the same network have been largely open and unrestricted, and authentication is managed with application-specific protocols and tools. This traditional networking approach relies on securing the perimeter of the network, which is effective against certain threats, but may leave the rest of the network vulnerable to an outside actor who was able to breach the secure perimeter.
ZTA operates on the assumption that this previous pattern of largely open network access is fundamentally insecure. It suggests that users, devices, applications, and services should be authenticated more frequently, more carefully, and in more places than ever before. A common ZTA goal is to achieve a least privileges session, for a limited duration, for any network activity that occurs between two components or users of a system. A spectrum of policies and technical approaches can be used to pursue this goal, and ultimately, each organization is responsible to define its own design for ZTA, re-architect to comply with this design, and monitor compliance over time.
ArcGIS Online, as a software-as-a-service offering, is generally positioned outside the bounds of a ZTA definition. This is because the security and controls of that system are the responsibility of Esri as a vendor, and the users of this system rely on their trust and agreement with Esri to meet these goals.
In a SaaS system, all users exclusively access ArcGIS Online using HTTPS requests to known and secured REST endpoints, with no access to the backend systems, the network hosting them, or any other secured resources. Esri provides a security baseline for ArcGIS Online along with a variety of security or privilege settings that can be configured to match each organization’s need for security in a SaaS system, from restricting default user access to controlling privileges and sharing of content.
ArcGIS Pro is a Windows desktop application that is used for a wide variety of data analysis, editing, and visualization workflows. Throughout these workflows, ArcGIS Pro generally connects to datasets that can be organized in three categories:
Whenever these connections require authentication, ArcGIS Pro must be aware of the authentication standard and specifically support it so that users may connect to that data location. The software currently supports a wide variety of authentication patterns, from database users to enterprise identities or operating system authentication, access keys and secrets, service account credentials, and others. ZTA often implements new and more complex authentication requirements for storage systems, such as multi-factor user authentication or removing the support for headless service accounts or dedicated data access accounts. Any implementation of ZTA security controls on databases, file systems, web services or other data storage systems must be carefully considered to account for the potential impact to ArcGIS users.
ArcGIS Pro also makes HTTPS requests when communicating with ArcGIS Enterprise, ArcGIS Online, or other external web services. When these requests are secured in unexpected ways or using browser-like ZTA enforcement patterns such as cookie-based session management, ArcGIS Pro may be unable to connect to these endpoints, as it currently only supports a set of known and carefully tested security access patterns for HTTPS requests.
Other ArcGIS desktop applications such as ArcGIS Drone2Map, ArcGIS Earth, ArcGIS AllSource, Survey123, or Insights Desktop also may be impacted by ZTA architecture decisions. Each of these applications uses HTTPS-based connections to query and visualize data, so the same caveats or concerns are relevant.
Mobile device and application security is a rich, complex, and challenging area of cybersecurity. Its importance has increased with the mainstream adoption of mobile app workflows, coupled with the increase in personal use by employees and members of an enterprise environment. Common mobile security topics include enterprise mobility management (EMM), device registration, endpoint management, traffic management, mobile device management (MDM), mobile application management (MAM), and others. A variety of vendor solutions also contribute to or aim to support increasing the security of mobile workflows, as well as user-based and behavior-based controls that can help to prevent these issues.
While mobile devices can support device-level and app-level VPNs, or similar, the concept of VPNs as a solution to cybersecurity is questioned in a ZTA, and many mobile apps expect internet-facing services to exist, so they can be accessed from public wireless signals and varied locations.
ZTA is often implemented for mobile device workflows by requiring some combination of device-based authentication, device registration, and continuous access monitoring. These controls are often implemented at the mobile operating system level, which may or may not be accessible to ArcGIS mobile applications. As an example, a device can be registered with Azure Entra ID, which can then be used as a conditional check before authentication through Azure AD is allowed, but if the ArcGIS mobile application is not aware of the requirement, or how to access the device registration information, it will not be sent to the Entra ID endpoint and authentication may fail.
ArcGIS Enterprise is a server-based set of web applications and web services that users access through HTTPS requests from a client, whether that client is a browser, mobile app, or desktop application. While impacts to those clients are discussed in previous sections, ArcGIS Enterprise itself can also be impacted by a ZTA configuration. For example, if all internal network requests are required by a system policy to be authenticated, that policy could include all ArcGIS Enterprise component-to-component requests, which are either secured by ArcGIS-managed tokens and keys or a user and password authentication. If a network is designed to filter every internal network request, to require a certain certificate, key or header, these internal component requests will likely be blocked and fail.
The impacts mentioned above underscore the importance of understanding the specifics of any zero trust implementation to prepare for its potential impact with ArcGIS components. One approach to achieving zero trust requirements with ArcGIS is to consider the existing security posture of the system, that all user requests are individually authenticated by ArcGIS tokens, which is a strong mechanism, and sufficiently validate user activity to achieve this standard.
A common technology used as part of a zero trust architecture controls is an Identity-aware proxies. While this pattern may achieve some goals for browser-based traffic, it will likely interfere with access from ArcGIS Pro or mobile applications to ArcGIS Enterprise.