When securing ArcGIS Server, it's important that the environment ArcGIS Server runs in be secure as well. There are several security best practices that you can follow to ensure the greatest security.
Requesting and configuring your own server certificate
ArcGIS Server comes preconfigured with a self-signed certificate, which allows the server 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 server to use it. This could be a domain certificate issued by your organization or a CA-signed certificate.
Like ArcGIS Server, Portal for ArcGIS also comes with a preconfigured self-signed certificate. If you'll be federating your site with Portal for ArcGIS, you should request a certificate from a trusted CA and configure the portal 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 Server and Portal for ArcGIS during testing, you will experience the following:
- Web browser and ArcGIS Desktop warnings 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 as long as you are using the self-signed certificate. You should expect to see these types of warnings if you use a self-signed certificate.
- Inability to open a federated service in the portal map viewer, add a secured service item to the portal, log in to ArcGIS Server Manager on a federated server, and 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.
Caution:
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 Portal for ArcGIS, ArcGIS Server, and ArcGIS Web Adaptor with a CA-signed certificate, see the following topics:
Restricting file permissions
It is recommended that file permissions be set so that only necessary access is granted to the ArcGIS Server installation directory, configuration store, and server directories. The only account that the ArcGIS Server software requires access to is the ArcGIS Server account. This is the account being used to run the software. Your organization may require that additional accounts also be given access. Keep in mind that the ArcGIS Server account needs full access to the installation directory, configuration store, and server directories for your site to function properly.
ArcGIS Server is installed with file permissions that only allow the account running ArcGIS Server access to the files. Files created by ArcGIS Server, such as the configuration store and server directories, are already locked down so that only the account running ArcGIS Server can access them.
Any account that has write access to the configuration store can change ArcGIS Server settings that can normally only be modified by an administrator of the system. If a built-in security store is being used to maintain users, the configuration store will contain encrypted passwords for those users. In this case, read access to the configuration store should also be restricted.
If you have secured map or geoprocessing services, it's important to lock down file permissions on the server directories to ensure that unauthorized accounts don't obtain access to maps and geoprocessing job outputs.
Disabling the primary site administrator account
The primary site administrator account is the account you specify when you first create a site in ArcGIS Server Manager. Its name and password are recognized only by ArcGIS Server; it is not an operating system account, and it is managed separately from the user account in your identity store.
It's recommended that you disable the primary site administrator account. This ensures that there isn't another way to administer ArcGIS Server other than the group or role you've specified in your identity store. See Disabling the primary site administrator account for full instructions.
Defining the shared key used to generate an ArcGIS token
An ArcGIS token is a string of encrypted information. The shared key is the cryptographic key used to generate this encrypted string. The more complex the shared key, the harder it is for a malicious user to break the encryption and decipher the shared key. If a user is able to decipher the shared key, replicate the ArcGIS Server encryption algorithm, and obtain the list of authorized users, the user will be able to generate tokens and consume any secured resource on that particular ArcGIS Server.
Before defining a shared key, consider the following:
- The shared key should be set to 16 characters (any characters beyond 16 are not used). It is recommended that you use a sequence of random characters for the key. Any characters may be used, including nonalphanumeric characters.
- The key should not be set to a dictionary word or a common value that is easily guessed. Since there is no need to remember the key or use it elsewhere, key complexity does not pose the same issues as it does with passwords.
- The token is encrypted with the shared key using the Advanced Encryption Standard (AES), also known as Rijndael. The 16 characters in the key represent the 128 bits used for encryption. For more information on encryption and AES, consult security references or someone in your organization with expertise in security and cryptography.
- In highly secure environments, it is recommended that you change the shared key on a periodic basis. Keep in mind that if you change the shared key, you may need to update your applications to use the new shared key. All existing embedded tokens will become invalid once you change the shared key.
To learn more, see About ArcGIS tokens.
Securely transmitting ArcGIS tokens
To prevent the interception and misuse of tokens, the use of a secure connection using HTTPS is recommended. The use of HTTPS ensures that the user name and password sent from the client and the token returned from ArcGIS Server cannot be intercepted. To learn more, see Configure HTTPS on ArcGIS Server.
When building custom ArcGIS client applications that use GET requests to access web services secured using ArcGIS token-based authentication, it is recommended that the token be sent in the X-Esri-Authorization header instead of a query parameter. This prevents intermediaries on the network, such as proxies, gateways or load-balancers from being able to obtain the token. The example HTTP GET request below sends the token in the X-Esri-Authorization header: GET https://arcgis.mydomain.com/arcgis/rest/services/SampleWorldCities/MapServer?f=pjson HTTP/1.1
Host: arcgis.mydomain.com
X-Esri-Authorization: Bearer xMTuPSYpAbj85TVfbZcVU7td8bMBlDKuSVkM3FAx7zO1MYD0zDam1VR3Cm-ZbFo-
If ArcGIS Server uses ArcGIS Server authentication and not Web-tier authentication (IWA, HTTP BASIC, PKI, etc) the standard HTTP Authorization header may be used instead of the X-Esri-Authorization header: GET https://arcgis.mydomain.com/arcgis/rest/services/SampleWorldCities/MapServer?f=pjson HTTP/1.1
Host: arcgis.mydomain.com
Authorization: Bearer xMTuPSYpAbj85TVfbZcVU7td8bMBlDKuSVkM3FAx7zO1MYD0zDam1VR3Cm-ZbFo-
Using standardized queries
ArcGIS Server includes a security option, known as standardized queries, that provides greater protection against SQL injection attacks. This option is enabled by default.
If you're a server administrator, it is recommended that you leave this security option enabled and instruct your application developers to construct WHERE clause statements that use database-independent syntax. Disabling this option could make your system more vulnerable to SQL injection attacks.
To learn more, see About standardized queries.
Disabling the Services Directory
You can disable the Services Directory to reduce the chance that your services can be browsed, found in a web search, or queried through HTML forms. Disabling the Services Directory also provides further protection against cross-site scripting (XSS) attacks.
The decision to disable the Services Directory will depend on the purpose of your site and the degree to which it needs to be navigated by users and developers. If you disable the Services Directory, you may need to prepare to create other lists or metadata about the services available on your site.
For instructions on disabling the Services Directory, see Disabling the Services Directory.
Restricting cross-domain requests
Cross-domain requests are used in many system attacks. It is a recommended practice to restrict the use of ArcGIS Server services to applications hosted only in domains that you trust. To learn more, see Restricting cross-domain requests to ArcGIS Server.