When securing your ArcGIS Enterprise portal, it's important that the environment in which your portal runs be secure as well. There are several best practices that you can follow to ensure the strongest security.
Restrict the portal's proxy capability
The portal is used as a proxy server in several scenarios. As a result, the portal's proxy capability can be misused to launch Denial of Service (DoS) or Server Side Request Forgery (SSRF) attacks against any computer the portal machine can access. To mitigate this potential vulnerability, it's strongly recommended you restrict the portal's proxy capability to approved web addresses. For additional details and full instructions, see Restricting the portal's proxy capability.
Disable anonymous access
To prevent any user from accessing content without first providing credentials to the portal, it is recommended that you configure your portal to disable anonymous access. Disabling anonymous access helps ensure that a public user would not be able to gain access to the resources on your portal.
To learn how to disable anonymous access in your ArcGIS Enterprise portal, see Disabling anonymous access. If you're using web-tier authentication (that is, you're performing authentication through ArcGIS Web Adaptor), you will also need to disable anonymous access on your web server. For instructions, consult your web server's product documentation.
Configure CA-signed server certificates
The ArcGIS Enterprise portal comes preconfigured with a self-signed server certificate, which allows the portal to be initially tested and to help you quickly verify that your installation was successful. However, in almost all cases, an organization should request a certificate from a trusted certificate authority (CA) and configure the portal to use it. The certificate can be signed by a corporate (internal) or commercial CA.
You should configure each applicable ArcGIS component in your organization with a certificate from a corporate or commercial CA. Common examples include ArcGIS Web Adaptor and ArcGIS Server. For example, ArcGIS Server also comes with a preconfigured self-signed certificate. If you'll be federating an ArcGIS Server site with your portal, it's important that you request a CA-signed certificate and configure the server and Web Adaptor to use it.
Configuring a certificate from a trusted authority is a secure practice for web-based systems and will also prevent users from encountering any browser warnings or other unexpected behavior. If you choose to use the self-signed certificate included with ArcGIS Enterprise during testing, you will experience the following:
- Warnings from your web browser, from ArcGIS Desktop, or from ArcGIS Pro about the site being untrusted. When a web browser encounters a self-signed certificate, it will typically display a warning and ask you to confirm that you want to proceed to the site. Many browsers display warning icons or a red color in the address bar for as long as you are using the self-signed certificate.
- The inability to open a federated service in the portal's Map Viewer, add a secured service item to the portal, log in to ArcGIS Server Manager on a federated server, or connect to the portal from ArcGIS Maps for Office.
- Unexpected behavior when configuring utility services, printing hosted services, and accessing the portal from client applications.
The above list of issues you will experience when using a self-signed certificate is not exhaustive. It's imperative that you use a CA-signed certificate to fully test and deploy your portal.
For instructions on how to configure ArcGIS Enterprise with a CA-signed certificate, see the following topics:
When you initially configure your ArcGIS Enterprise deployment, anytime you are challenged for your credentials, the user name and password are sent using HTTPS. This means your credentials sent over an internal network or the Internet are encrypted and cannot be intercepted. By default, all communication within your portal is sent using HTTPS. To prevent the interception of any communication, it is recommended that you configure your web server hosting ArcGIS Web Adaptor to enforce HTTPS as well.
By having HTTPS-only communication enforced, all external communication outside of your Enterprise portal, such as ArcGIS Server services and Open Geospatial Consortium (OGC) services, are secured as your portal will only access to external web content if HTTPS is available. Otherwise, external content is blocked.
However, there may be instances in which you would like to enable both HTTP and HTTPS communication within your portal. To learn how to enforce HTTP and HTTPS for all communication in ArcGIS Enterprise, see Configure HTTPS.
Disable the ArcGIS Portal Directory
You can disable the ArcGIS Portal Directory to reduce the chance that your portal items, services, web maps, groups, and other resources can be browsed, found in a web search, or queried through HTML forms. Disabling the ArcGIS Portal Directory also provides further protection against cross-site-scripting (XSS) attacks.
The decision to disable the ArcGIS Portal Directory depends on the purpose of your portal and the degree to which it needs to be browsed by users and developers. If you disable the ArcGIS Portal Directory, you may need to prepare to create other lists or metadata about the items available on your portal.
For full instructions, see Disable the ArcGIS Portal Directory.
Configure your firewall to work with the portal
Every computer has thousands of ports through which other computers can send information. A firewall is a security mechanism that limits the number of ports on your machine through which other computers can communicate. When you use a firewall to restrict communication to a small number of ports, you can closely monitor those ports to prevent an attack.
The ArcGIS Enterprise portal uses certain ports to communicate, such as 7005, 7080, 7099, 7443, and 7654. As a security best practice, it is recommended that you open your firewall to allow communication on these ports; otherwise, your portal may not function correctly. To learn more, see Ports used by Portal for ArcGIS.
Specify the default token expiration time
If you're using the portal's built-in identity store, a token is used to authenticate members. When a user attempts to access the portal, they provide their user name and password. Portal for ArcGIS verifies the supplied credentials, generates a token, and issues a token to the member.
A token is a string of encrypted information that contains the user's name, the token expiration time, and other proprietary information. When a token is issued to the member, they can access the portal until the token expires. When it expires, the member must provide their user name and password again.
The default expiration time is two weeks (20,160 minutes). Although this may be appropriate for your organization, a token with a longer expiration time is less secure. For example, a token intercepted by a malicious user can be used until the token expires. Conversely, a shorter expiration time is more secure, but members will need to enter their user name and password more frequently.
To change the default token expiration time, follow the steps in Specify the default token expiration time.
Restrict file permissions
It is recommended that file permissions be set so that only necessary access is granted to the Portal for ArcGIS installation directory and content directory. The only account that the Portal for ArcGIS software requires access to is the Portal for ArcGIS account. This is the account that is being used to run the software. Your organization may require that additional accounts also be given access. Keep in mind that the portal account needs full access to the installation and content directories for your site to function properly.
Portal for ArcGIS inherits file permissions from the parent folder where it is installed. Additionally, it grants permission to the portal account so it can access the directory where it is installed. Files created as the portal runs inherit their permissions from the parent folder. If you want to secure the content directory, set restricted permissions on the parent folder.
Any account that has write access to the content directory can change the portal settings that normally can only be modified by an administrator of the system. If a built-in security store is being used to maintain users, the content directory will contain encrypted passwords for those users. In this case, read access to the content directory should also be restricted.