> ## Documentation Index
> Fetch the complete documentation index at: https://docs.arc.cdata.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Security Best Practices

> Security-related features and recommended best practices for CData Arc installations.

This page provides information on security-related features available in CData Arc and describes the best practices we recommend you follow.

### Hardening Server Security Settings

Arc Cloud uses the `ScriptingEngineHardeningLevel` setting to control which script operations are disabled. Arc Cloud instances use level `1` by default. CData manages this setting in the hosting platform, so you cannot change it in the application. To request a different level, contact **[arcsupport@cdata.com](mailto:arcsupport@cdata.com)**.

The following table shows which operations are disabled at each hardening level:

| Level | Disabled Operations |
| - | - |
| 0 | All operations are allowed. |
| 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 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 disables operations for obtaining sensitive information from the server or performing arbitrary http requests. |

## Securing Data in CData Arc

The following sections relate to the security of data in Arc, including the messages and data that flow through the application and the [flow](../../flows) configurations themselves.

### Enabling TLS/SSL for Outbound Traffic

Arc automatically parses whether to negotiate TLS/SSL based on the target URL of outbound connections. For example, if an outbound [AS2](https://docs.arc.cdata.com/26.4/cloud/en/connectors/as2.md) connection is targeting an `https` URL, Arc negotiates TLS.

TLS/SSL is strongly recommended for transferring data over protocols that do not include built-in encryption mechanisms. This means that 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 TLS/SSL encryption.

### Validating TLS/SSL Server Certificates and SSH Keys

When making an outbound connection to a TLS/SSL or SSH server, the connector establishing the connection (for example, [REST](https://docs.arc.cdata.com/26.4/cloud/en/connectors/rest.md), [AS2](https://docs.arc.cdata.com/26.4/cloud/en/connectors/as2.md), or [SFTP](https://docs.arc.cdata.com/26.4/cloud/en/connectors/sftp.md)) attempts to validate the certificate or key provided by the server. If a server certificate/key is not configured in the connector settings, Arc uses the validation process present in the underlying system to determine if the server's certificate is trusted.

You can configure connectors with a specific TLS/SSL certificate or SSH key thumbprint to override the 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 implicitly trust the server's identity when you set the **TLS Server Certificate** field to *Any Certificate*. You should only do this when there is no concern about server impersonation attacks.

### Managing Users and Admins and Accessing the API

Arc maintains a set of username and password credentials for users who are authorized to log in to the Arc web interface and use the application. For more information on users and roles, including the Admin role, see [Users](https://docs.arc.cdata.com/26.4/cloud/en/getting-started/administration/settings/users.md) and [User Roles](https://docs.arc.cdata.com/26.4/cloud/en/getting-started/administration/settings/user-roles.md).

Users with the Admin role are allowed to access and change passwords of other users. The credentials for the Admin user created with your instance 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, you can generate an auth token that allows this user access to the API (with restrictions according to that user's role in the application). For more information on using an auth token to access the Admin API, see [API Authentication](https://docs.arc.cdata.com/26.4/cloud/en/admin-api/admin-api-authentication.md).

> [!NOTE]
>
> A user's auth token is not displayed after it is created, so it should be stored securely in an external location.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.