When securing your ArcGIS Enterprise organization, it's important that the environment in which it runs is secure as well. There are several best practices that you can follow to ensure the strongest security.
Set minimum privileges on the container registry account
The container registry account that you specify during deployment should have a minimum level of privileges associated with it, for example, only those to download container images. By default, Kubernetes stores and accesses this account's unencrypted credentials as a secret. It is recommended that you do not specify an account that has privileges to push changes, edit metadata, or administer the container registry.
Configure email settings
You can configure your organization to send email notifications to members and administrators in the event of a forgotten password, updated password policy, and more. Review Email settings for steps and details.
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 Restrict the portal's proxy capability.
Disable anonymous access
The portal's anonymous access option controls access to the portal website. To prevent a user from accessing the portal website without first providing credentials to the portal, it is recommended that you disable anonymous access. While disabling anonymous access does not prevent anonymous users from accessing content shared with everyone, it helps to ensure that a public user cannot use the portal website to search for content or resources shared with everyone. To learn how to disable anonymous access in your ArcGIS Enterprise portal, see Disable anonymous access.
Configure and trust CA-signed TLS certificates
Configuring a certificate from a trusted authority is a secure practice for web-based systems and will prevent users from encountering any browser warnings or other unexpected behaviors. During deployment, your organization must provide or generate a TLS identity certificate for use by the ingress controller. In many deployment configurations, this TLS certificate is the one exposed to all end-users. This means it is highly recommended that the certificate assigned to the ingress controller be signed by a trusted certificate authority (CA). If a self-signed certificate was generated during deployment, it can be replaced by importing a new certificate and assigning it to the ingress controller after the organization has been created.
If the certificate authority that signed the certificate is a corporate or domain CA and not a well-known CA, the public certificate for the CA needs to be imported as a trust certificate as well. This will ensure that ArcGIS Enterprise is able to validate and trust any certificate signed by that CA.
For instructions on how to import an identity or trust certificate, see Import certificates.
When you initially configure your ArcGIS Enterprise deployment, anytime you are challenged for your credentials, the username 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.
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 want 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 non-administrative API directories
From the administrator directory, you can disable HTML access to both the ArcGIS Portal Directory /<context>/sharing/rest and the ArcGIS REST services directory /<context>/rest/services. This can help 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 access to these directories also provides further protection against cross-site scripting (XSS) attacks.
The decision to disable access to these directories will depend on the purpose of your portal and the degree to which it needs to be browsed by users and developers. If you disable access to these directories, you may need to create lists of available operations or metadata about the items and services available on your portal.
For more information, see Disable non-administrative API directories.
Specify token expiration time
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.
Each time you generate a new token while using ArcGIS Enterprise, you should specify an expiration time. If you don't, a default expiration value will be used.
There are three types of tokens used by the portal: ArcGIS tokens, OAuth access tokens, and OAuth refresh tokens. Each type has its own default expiration value.
These maximum and default values cannot be increased and can be decreased by setting the maxTokenExpirationMinutes property in the ArcGIS Portal Directory. The value for the maxTokenExpirationMinutes property applies to each type of token. If that value is less than the maximum value but greater than the default value, only the maximum value will be impacted, and the default value will stay the same. If the value is less than both the maximum and default values, both values will be affected, and the maximum and default values will match what is defined in maxTokenExpirationMinutes.
To change the default token expiration time, follow the steps in Specify the default token expiration time.