Version 22.0.8473

• Securing the CData Arc Infrastructure
  • Enabling SSL/TLS for Inbound Traffic
    • SSL/TLS for the Web Server
    • SSL/TLS for Other Servers
  • Managing Users and Admins and Accessing the API
    • Admin API
  • Configuring Firewalls and Using a DMZ
    • DMZ
  • Separating Public Endpoints from the Web Interface
  • Hardening Server Security Settings
    • Windows
    • Java
• Securing Data Within CData Arc
  • Enabling SSL/TLS for Outbound Traffic
  • Validating SSL/TLS Server Certificates and SSH Keys

This page provides information on security-related features available in CData Arc and describes our recommended practices to follow. Security concerns have been divided broadly into two categories:

• Securing the infrastructure upon which Arc operates
• Securing data within Arc

Both of these sections describe relevant security concepts and contain subsections with our recommendations for engaging with the concept.

Securing the CData Arc Infrastructure

Many security settings are managed by the server configuration files. When using the embedded web server included with Arc, the server configuration files are found in the following locations:

• Windows Edition—the Web.Config file in the www folder of the Arc installation directory (by default, C:\Program Files\CData\CData Arc)

• Java Edition—the arc.properties file in the Arc installation directory

When deploying Arc to an external server, the configuration file for that external server should be used instead.

Enabling SSL/TLS for Inbound Traffic

It is strongly recommended that you enable SSL/TLS on your server. SSL/TLS uses public-key/private-key cryptography to encrypt communication channels between a client and server. This encryption protects the confidentiality, authenticity, and integrity of data in Arc. In addition, through the use of digital certificates, TLS offers facilities for client/server identity confirmation.

Enabling inbound SSL/TLS can be divided into two categories:

• TLS for the host web server, which relates to HTTP traffic, including protocols that use HTTP underneath like AS2 and AS4. Since the same web server that hosts Arc is used to handle these requests, TLS must be enabled at the web server level.
• TLS for all other servers, which relates to non-HTTP traffic, such as FTP and OFTP. Since the servers handling these inbound connections are not the same as the web server hosting Arc, these options must be enabled within the Arc interface in the Profiles page under the tab for the appropriate protocol.

SSL/TLS for the Web Server

For the Windows edition of Arc, if you are using the embedded server, see Embedded Server. If you are using IIS, see Configuration in IIS.

For the Java edition, see the Enabling SSL/TLS section of the Java Edition documentation.

SSL/TLS for Other Servers

Use the Profiles page to enable SSL/TLS for the following servers:

• FTP Server
• OFTP Server
• HL7 MLLP Server

Each of these servers has a tab in the Profiles page where SSL/TLS can be enabled or disabled.

Managing Users and Admins and Accessing the API

Arc maintains a set of user credentials (username and password) for users that are authorized to log in to the Arc web interface and use the application. User management and user roles, including the Admin role, are described in the User Roles section of the documentation.

Users with the Admin role are allowed to access and change passwords of other users. The credentials for the original Admin user that is created when Arc is first run should be securely stored in an external location to ensure that this account is both secure and recoverable.

Admin API

Users can perform all application management tasks via calls to the Admin API, so securing access to this API is just as important as securing access to the web interface. When an Arc user is created, an auth token can be generated that allows this user access to the API (with restrictions according to that user’s role in the application). Details on using an auth token to access the Admin API can be found in API Authentication.

A user’s auth token is not displayed after it is created, and thus should be stored securely in an external location.

Configuring Firewalls and Using a DMZ

In order for Arc to send and receive messages, it will need to be free from firewall interference on the relevant sending and receiving ports. If possible, it is best to whitelist specific IPs within the firewall to ensure that traffic only comes from expected sources. In cases where this is not possible, the firewall must be opened on critical ports where Arc listens for inbound messages. Arc protects configuration resources behind a login portal.

By default, the Arc web server listens on port 8001. Ports for non-web protocols can be configured directly in the application. For example, the OFTP Server listening port can be configured in the OFTP Server tab of the Profiles page.

DMZ

The Windows edition of Arc includes support for establishing a reverse SSH tunnel to host Arc in a demilitarized zone (DMZ) to avoid opening the firewall on a private network directly. More information on cloud hosting can be found in the DMZ Gateway section.

Separating Public Endpoints from the Web Interface

By default, Arc uses the same web server port to host both the admin console (where Arc can be configured and managed) and the public receiving endpoints that remote partners can use to send data to the application. The Admin Console is protected by credentials to ensure that remote partners do not gain access. However, hosting the public receiving endpoints on a separate port ensures that network/firewall rules can be used to add a layer of redundancy and enhance security.

The public receiving endpoints can be hosted on a separate network port as described in Separate API Endpoints.

Hardening Server Security Settings

You can increase the security of your Arc server by setting the configuration parameter ScriptingEngineHardeningLevel in the Arc configuration files. By default, this parameter is set to 0, which does not block any operations. You can set it to a value between 0 and 3, where each higher value increases security by disabling certain operations. The list below shows which operations are disabled at each hardening level:

• 0: All operations are allowed. This is the default setting.
• 1: The most vulnerable operations are disabled. This includes any operations that allow the user to interact with the host system in an arbitrary way.
• 2: In addition to the operations disallowed in level 1, this level also disables operations for creating new users, accessing files on disk in a non-arbitrary way, and introducing recurring tasks.
• 3: In addition to the operations disallowed in levels 1 and 2, this level also disables operations for obtaining sensitive information from the server or performing arbitrary http requests.

Use the sections below to set the hardening level for your installation.

Windows

Use a text editor to open the Web.Config file in the www folder of the installation directory. At the bottom, inside the <appSettings> tags, add the line shown below and set value to your desired level:

<appSettings>
     <add key="ScriptingEngineHardeningLevel" value="0"/>
</appSettings>

Java

Use a text editor to open the arc.properties file in the installation directory. Add a line for the following property, and set the number to your desired level:

cdata.initParameters=ScriptingEngineHardeningLevel:0

Securing Data Within CData Arc

The following sections relate to the security of data within Arc, including the messages/data that flow through the application and the Flow configurations themselves:

• Encrypting outbound data in transit
• Validating SSL certificates and SSH keys

Enabling SSL/TLS for Outbound Traffic

Arc automatically parses whether or not to negotiate SSL/TLS based on the target URL of outbound connections. For example, if an outbound AS2 Connection is targeting an https URL, Arc negotiates TLS.

SSL/TLS is strongly recommended for transferring data over protocols that do not include built-in encryption mechanisms. As such, web traffic should be sent to HTTPS endpoints, FTP traffic should be directed to FTPS endpoints, and so on. Other than correctly configuring the target URL, no additional steps are necessary to ensure Arc negotiates SSL/TLS encryption.

Validating SSL/TLS Server Certificates and SSH Keys

When making an outbound connection to an SSL/TLS or SSH server, the connector establishing the connection (e.g. a REST Connector, AS2 Connector, SFTP Connector, etc) attempts to validate the certificate or key provided by the server. If no server certificate/key is configured in the connector settings, Arc uses the validation process present in the underlying system (e.g. the OS or JRE) to determine if the server’s certificate is trusted.

Connectors can be configured with a specific SSL/TLS certificate or SSH key thumbprint to override this underlying system behavior. When making an outbound connection, if the server’s certificate matches the certificate configured in the connector, the connector trusts the server. This option provides the highest level of security.

Connectors can also implicitly trust the server’s identity by setting the TLS Server Certificate field to Any Certificate. This should be done only when there is no concern for server impersonation attacks.