Книга: Getting to Know ArcGIS Enterprise
Назад: Part 1: Implementing ArcGIS Enterprise
Дальше: Chapter 5: Going beyond the ArcGIS Enterprise base deployment

Chapter 4Introduction to ArcGIS Enterprise security best practices

Objectives

Introduction

As enterprise-grade software, ArcGIS Enterprise is designed to ensure a secure user experience. ArcGIS Enterprise provides a built-in content management system that enables users to safely collaborate with each other in the context of the ArcGIS Enterprise portal. Although not a comprehensive guide to implementing security, this chapter is a primer to security concepts that apply to ArcGIS Enterprise.

The goal in any security strategy is to find a balance between the functionality needed to support the organization mission and security policies that limit unnecessary functions. Finding this balance will require negotiations between security stakeholders at your organization and GIS teams, so it is best to come prepared to this discussion with a clear set of workflows that need to be implemented.

In the scope of ArcGIS Enterprise, there are three primary areas where IT and ArcGIS Enterprise administrators should work together to establish common ground in their security practices:

This chapter does not include an exhaustive list of security considerations that must be implemented to secure a system. The next few pages instead will present basic information and describe a security structure whereby an ArcGIS Enterprise administrator can facilitate discussions with their IT staff to make security decisions. For more technical information, review the content in the ArcGIS Trust Center, a resource maintained by Esri’s dedicated product security and privacy team. This chapter will conclude with a tutorial on how you can validate your system security with built-in tooling, using the ArcGIS Security and Privacy Advisor linked from the ArcGIS Trust Center.

ArcGIS Enterprise ownership-based security

This section covers these facets of security:

Users, groups, roles

ArcGIS Enterprise uses an ownership-based security model. All content within your organization is managed and secured through users and groups. Unless content is shared publicly, authentication is required to access and interact with most of the apps, features, services, and maps within ArcGIS Enterprise. Each user may be granted specific licenses, roles, and privileges to customize their ability to manage their own content within ArcGIS Enterprise. Even administrator-level privileges, such as creating groups and managing group content export, can be delegated to nonadministrators for delegation of responsibilities. We will explore content and user management in chapters 7 and 8, but let’s talk about how ArcGIS Enterprise can use different authentication methods.

Authentication options

ArcGIS Enterprise supports creating and managing users using built-in authentication as well as an organization’s identity stores, such as Active Directory, Lightweight Directory Access Protocol (LDAP), Security Access Markup Language (SAML) compliant, or OpenID Connect (OIDC) identity providers. This capability allows administrators a certain level of control over how their users will authenticate against ArcGIS Enterprise. Note that no matter what level of authentication you choose, core functions, such as group creation and licensing, will be unaffected. If you are an application developer, ArcGIS Enterprise also supports noninteractive means of authentication using API keys and exchanging ClientIDs and Client Secret values. Let’s examine the primary difference between built-in authentication and centralized authentication.

Built-in: This is the default identity store for your ArcGIS Enterprise portal. Upon creation, ArcGIS Enterprise prompts you to provide a built-in site administrator account. This account is used for the initial creation of the ArcGIS Enterprise portal. Although this is an acceptable way to start creating your ArcGIS Enterprise deployment, it is industry best practice to centralize account management through an organization-wide identity provider.

Centralized identity management (CIM): As a best practice, having a user base that is using CIM in an organization is critical toward establishing zero trust architecture (ZTA). The ArcGIS Enterprise Hardening Guide, which you can access at , defines ZTA as the principle that “no actor, system, network, or service operating outside or within the security perimeter is trusted.” CIM through an SAML-compliant internal developer platform (IDP) or other option aligns with ZTA foundational tenants.

Once ArcGIS Enterprise administrators choose and implement an authentication method, they must choose the roles and user types needed for each user to complete their work. Follow this primary security principle: Only grant users the exact privileges they need to complete their work. As simple as this sounds, defining specific rights and privileges to your default users as well as your power users is one of the most important ways to avoid accidents and spills in the future of your environment.

Next, consider the administrator user: A built-in administrator user is created at the beginning of the ArcGIS Enterprise portal installation. It is vital for the initial system configuration of ArcGIS Enterprise; however, it is also viewed as a potential security vulnerability because of its unassigned status as well as its elevated privileges. The ArcGIS Enterprise Hardening Guide recommends that this user is deactivated as soon as possible to avoid unnecessary exposure. Using custom roles, nonadministrator users may be delegated certain administrative rights and privileges. Custom roles allow organizations to better segregate administrative responsibilities across the ArcGIS Enterprise organization.

A good example of this is the Group Manager role. In the older releases of ArcGIS Enterprise, it was necessary to be an administrator or a group owner user to add, remove, and promote different users within a group. This task proved to be cumbersome to larger organizations that had many groups, so the Group Manager role was introduced. As a delegated role, nonadministrators and group owners had the ability to accept membership requests and manage the group. Delegating administrative responsibilities is a smart way to limit the number of administrator users in ArcGIS Enterprise for better security and accountability.

Audit logging and SIEM

Audit logging was introduced in ArcGIS Enterprise 11.4. Audit logging is the ability to track and report information related to

Audit logging is particularly useful to organizations that have legal requirements to track each change made to their data.

For example, let’s say that you are an insurance provider. Since details surrounding users’ claims can be considered privileged information, your organization may require a chain of custody to certain pieces of content within ArcGIS Enterprise. With audit logging, you can honor this requirement by tracking user sign-in information, item access and modification history, and group management information.

Audit logs captured in ArcGIS Enterprise are designed to be used in a Security Information and Event Management (SIEM) system. If a security event occurs, the SIEM allows organizations to access logs and events that occurred in the system at a specific time to correlate and analyze responses. Additionally, logs at various components of ArcGIS Enterprise may be directed into the SIEM to understand the software-level events that may have contributed to an event.

This chapter covers two major topics when you consider application-level security: user authentication and auditing. Regardless of your implementation plan, these factors are important to consider early on. For details that are more nuanced toward a specific architecture or deployment style, consult the ArcGIS Enterprise Hardening Guide, found at the ArcGIS Trust Center. This guide covers the information we’ve presented here with added depth and context.

Software-level considerations

So far, we’ve talked about some features and functions that exist within ArcGIS Enterprise as an application. Because the software can be deployed on multiple machines and used as essential infrastructure, administrators must ensure that ArcGIS Enterprise is running in the most secure state possible. At a minimum, ArcGIS Enterprise administrators should be aware of these aspects:

Versioning implications

Esri typically releases two versions of ArcGIS Enterprise each year—a long-term supported (LTS) release and a short-term supported (STS) release. Deciding on which release to install depends on how often you want to upgrade. We will explore more of this nuance in chapter 20, but briefly, if having the latest available features is important to your workflows, you will want to upgrade to the STS and LTS releases as soon as possible.

From a security posture, upgrading to the latest release ensures that the underlying components of ArcGIS Enterprise are their most recent versions. Due to different dependencies, Esri does not recommend upgrading these components independently. Doing so will lead to unexpected consequences and may cause the system to become unsupportable. Next, we’ll review the necessary steps to secure communication between these components using certificates.

.

Certificates

What are certificates? In the context of enterprise networking, an enterprise network certificate, also known as an Enterprise SSL Certificate/Enterprise PKI Certificate, is a way to establish trust within a network. Depending on how certificates are created, they can be countersigned by a Certificate Authority (CA). A CA is responsible for creating a trusted list of root certificates that support the basic foundation of Hypertext Transfer Protocol Secure (HTTPS) encrypted communication.

You can import different kinds of certificates into ArcGIS Enterprise to establish trusted communication between

In the scope of a base ArcGIS Enterprise deployment, certificates become relevant in three places:

Certificates are typically applied to Web Adaptor during installation; however, administrators usually overlook importing certificates at the internal end points of Portal for ArcGIS, ArcGIS Server, and ArcGIS Data Store. Although this will not influence your federation, it may have negative side effects when you work with advanced features, such as distributed collaboration, or use stream services from ArcGIS GeoEvent™ Server.

Portal for ArcGIS and ArcGIS Server components rely on communication over ports 6443 and 7443. Communication over these ports is vital for the internal functions of ArcGIS Server and the ArcGIS Enterprise portal, so you should never expect to see these ports in regular workflows. However, if certificates are not imported at these end points, you run the risk of unexpected failures in certain tasks occurring. Since the ArcGIS Data Store is tied to the hosting server, an administrator may choose to update the certificate using command line tools. This will secure communication between the hosting server and the ArcGIS Data Store over the specific ports. We will explore how to update all these certificates in the tutorial at the end of this chapter.

Security validation tooling in ArcGIS Enterprise

Administrators can use several tools to start the process of verifying the security of their ArcGIS Enterprise deployment. You will have the opportunity to work with these tools in the tutorial at the end of this chapter.

Each of these tools provides a good starting point for an ArcGIS Enterprise administrator to understand any possible security gaps. However, the authors encourage all administrators to work with their IT and security teams on taking additional steps to ensure security. These steps can include creating governance policies for sensitive data and educating the user base on common security pitfalls.

Network considerations

Network-level security is dependent on the architecture adopted by your organization’s IT department. There are innumerable variances in the way organizations configure their networking, ranging from the cloud provider they choose to the accessibility of the deployment outside the internal network. This chapter does not cover every possible nuance but rather serves as a guide to have conversations with your IT team to reach shared understandings and create a secure and accessible ArcGIS Enterprise deployment.

For a successful ArcGIS Enterprise deployment, it is vital that the IT and GIS departments align to create a conceptual plan. Too often, only one of the departments takes on the responsibility, which can lead to limited functionality, unexpected issues due to access problems, and potential data spills or leaks.

. This resource defines the ArcGIS Well-Architected Framework, which demonstrates architecture best practices, provides an overview of ArcGIS as a platform as well as its deployment options, and brings additional training resources to the system that powers ArcGIS.

The elements that define your network security will vary based on the type of infrastructure on which you choose to deploy ArcGIS Enterprise. One common theme binds network security together, regardless of your infrastructure options: the level of availability of your content and ArcGIS Enterprise to the internet.

ArcGIS Enterprise is designed to run independently without any access to the internet. However, running a completely air-gapped deployment will also restrict your access to Esri’s basemaps, ArcGIS Living Atlas of the World content, and other useful services. Earlier in the chapter, we said that the goal in any security strategy is to find a balance between the functionality that is needed to support the mission and a security policy that limits unnecessary functions. Although an air-gapped system may be the most protected from a security perspective, it comes at the cost of functionality. This is why understanding the type of data being hosted on your ArcGIS Enterprise deployment and the security requirements of the base data become so important.

To strike this middle ground, administrators often enable access to arcgis.com from their organizations to access ArcGIS Living Atlas content and basemaps. One of the most fundamental ways to secure this type of content access is using a web app firewall (WAF). A properly configured WAF will monitor and filter all HTTP traffic to and from a web app. In the case of an ArcGIS Enterprise deployment, WAF rules will allow for the use of ArcGIS Living Atlas content and basemaps within the organization. The ArcGIS Trust Center’s ArcGIS Enterprise Web Application Filter Rules documentation contains specific rules needed for the software to function properly.

. .

Verify your system security configuration

The Esri Software and Security Team has created a set of tools and applications that can be configured to run on your ArcGIS Enterprise deployment. The content of these tools is based on the ArcGIS Enterprise Hardening Guide.

  1. Navigate to the ArcGIS Trust Center at .
  2. At the top right of the screen, click Launch Security Adviser.

    The ArcGIS Security and Privacy Adviser page opens.

  3. Enter the Portal URL for your ArcGIS Enterprise organization. Ensure that it has a portal end point.
  4. On a separate tab, navigate to your ArcGIS Enterprise organization site and sign in as an administrator.
  5. On the Content tab, click New item.
  6. In the New item window, select Application. Then apply the following settings:
    • Application type: Web mapping
    • URL: https://desb9z4fk5fbl.cloudfront.net
  7. Click Next and save the application with your own details.
  8. On the app’s item page, click the Settings tab. Scroll down to the Credentials section and click Register application.
  9. For Redirect URLs, type the same URL you used to create the app.
    The Register window with the Redirect URLs field.
  10. Click Register.

    Your application is now registered. A Client ID, Client Secret, and Temporary Token are generated to access the application.

  11. Copy the Client ID. Return to the ArcGIS Security and Privacy Adviser tab. Paste the Client ID in the App ID field.
  12. Click Go To Enterprise Login.

    Running this tool will display any security issues that need to be addressed or considered, as defined by the ArcGIS Enterprise Hardening Guide.

    A list of issues identified by the ArcGIS Security and Privacy Adviser tool.

Scanning ArcGIS Server

ArcGIS Server includes a Python script tool, serverScan.py. This tool identifies security configuration options and adds a severity figure. You will run the tool to scan the ArcGIS Server machine.

  1. Access the ArcGIS Server machine.
  2. Navigate to the location of the ArcGIS Server installation. Open tools and then open admin.
  3. Run the serverScan.py tool.

    This tool will require the PSA credentials used to configure the ArcGIS Server site at installation.

    This tool will also require a directory to deposit the security scan.

    An example input (for Windows deployments) may look like the following:

    python serverScan.py -n gisserver.domain.com -u admin -p my.password -o C:\Temp

  4. Observe the outputs of the tool.
    • What possible changes may you need to make to improve security?

Scanning the ArcGIS Enterprise portal

Similar to ArcGIS Server, Portal for ArcGIS includes a Python script tool: portalScan.py.

  1. Access the machine that is running Portal for ArcGIS.
  2. Navigate to the location of the Portal for ArcGIS installation. Open tools and then open security.
  3. Run the portalScan.py tool.

    This tool will require administrator-level credentials. This tool will also require a directory to deposit the security scan output.

    An example input (for Windows deployments) may look like the following:

    portalScan -n portal.domain.com -u admin -p my.password -o C:\Temp

  4. Observe the outputs of the tool.
    • What possible changes may you need to make to improve security?

Take the next step

If you have questions about whether a particular security configuration setting is appropriate, bring the scan results to the people responsible for information security in your organization and further discuss any additional steps you should take to harden your ArcGIS Enterprise deployment.

Summary

In this chapter, we introduced the three levels of security that are relevant to ArcGIS Enterprise: ArcGIS Enterprise identity-based security, software-level security, and network-level security. The goal of a good security strategy is to find an intersection between function and access. To reach this goal, ArcGIS Enterprise administrators must work closely with their IT counterparts to identify the access requirements of features that are hosted on the internet and the privacy requirements of the data in ArcGIS Enterprise.

Назад: Part 1: Implementing ArcGIS Enterprise
Дальше: Chapter 5: Going beyond the ArcGIS Enterprise base deployment