Data Encryption

• All the sensitive data is encrypted and stored in the Qntrl database.

• Sensitive data:

• Task payload, response

• Credentials

• Tokens used to connect with the Bridge

• AES algorithm is used to encrypt the data at rest.

• Encryption keys are different for each org and kept confidential. To know more about our encryption policy refer to this link.

• All the sensitive data is encrypted and stored, as required, in either the file system or the bridge database.

• Sensitive data:

1. Bridge credentials - to login bridge in UI

2. OAuth credentials - to connect with the Qntrl

3. Registration Token

4. All the Credentials are created in the Bridge.

• AES algorithm is used to encrypt the data.

• A unique encryption key is generated while installing the bridge. So, even if the encrypted data is exposed, it will be difficult to view the original data.

• Task payload may contain sensitive information. So, in addition to protocol encryption, the payload will be encrypted to avoid exposure of original data. 

• AES/SHA256 algorithm is used to encrypt the payload.

• Sensitive data in logs are masked on both the Qntrl and Bridge sides.

Credentials 

• Users can create credentials either in Qntrl or in Bridge. In both cases, data will be encrypted and stored in respective databases.

• Credentials created in the Qntrl are encrypted as per our EAR policy. Profile-level permissions can be configured for credentials. Also, it can be viewed only by the created user.

• The credentials created in the Bridge will be encrypted using the AES algorithm with AES/CBC/PKCS5P mode.

Permissions 

1. Only users with settings permission can download and install Bridge.
   
2. Also, users with proper permission can execute tasks, and commands for a Bridge.

Authentication 

• Bridge uses HTTPS and WSS protocols to communicate with the Qntrl.
• HTTPS calls are used for initial registration and in server startups once. This call will be authenticated by a registration token which is bundled in the Bridge.
• This registration token gives a response on successful authentication and contains keys to create WebSockets. Using that response, WebSockets will be created and a connection will be made between the Bridge and the Qntrl.
• Further communications will be made through WSS protocol and all the requests through WebSockets will be validated on the Qntrl side.

Network Security 

• Inbound Requests: Users do not need to configure their firewall for inbound requests. All inbound requests are handled via WebSocket communication.
• Outbound Requests: Users should whitelist the following domains in their firewall for outbound requests. Please note that the specific domain may vary depending on the data center location, but for the US data center, the following domains should be allowed:  
• core.qntrl.com
• accounts.zoho.com
• bridgews.qntrl.com

Resource Limit 

1. You can increase or reduce the Java process memory configured for the bridge. If you are going to execute heavy or long-running tasks frequently, then you can increase the limit by changing the  wrapper.java.maxmemory property in wrapper-bridge.conf inside the conf folder.
   
2. The value should be in MB. For example, If you need to configure 1GB as process memory then the value should be 1024.
3. A Bridge restart is required if you are changing the property.
   

1. Users can configure thread counts for execution as per their requirements. Refer to this link.
2. Users can configure different values for different thread pools.
1. Request pool - Receives a task from the Qntrl and forwards it to the task pool.
2. Response pool - Receives a response after task execution and forwards the response back to the Qntrl.
3. Asynchronous pool - Executes asynchronous tasks from the Qntrl.
4. Synchronous pool - Executes synchronous tasks from the Qntrl.
5. SFTP pool - File management tasks will be executed by this pool.
   

1. Cluster option enables the users to group similar kinds of bridges for Load Balancing and Failover mechanism. Refer to this link to learn more about Cluster.

Proxy

• Users can configure proxy, for outbound requests. To configure a proxy, execute set_proxy.sh for Unix-based systems and execute set_proxy.bat for Windows systems.
• A Bridge restart is required after setting the proxy.
• Once the proxy is set, all the requests including WebSockets will be communicated through a proxy server.

Other security measures 

• The registration token will be bundled in the downloaded zip/installer and expires once it is used. The token will also lose validity if it is not used within 14 days from the downloaded time. Additionally, each user within the organization will have a unique token assigned to them.
• The Register API will provide connection details and an update token as a response. If the bridge is restarted, the update token is used to retrieve the connection details and these connection details will be used to create WebSockets.
• The update token will be encrypted and stored within the installation folder of bridge. The connection details used for establishing WebSocket connections will not be stored anywhere and these details can only be retrieved by using either the registration token or update token.
• The registration token is used only for the initial registration. Subsequent communications will take place through WebSockets. For communication, Secure WebSocket (WSS) protocol is employed to ensure security.
• A profile-level permission has been granted to users, enabling them to utilize other user's credentials during the task execution. The credential data will remain confidential and inaccessible to anyone except the user who created it. Moreover, only the user who initially created the credential will have the authority to modify or delete it. While the super admin holds the capability to delete the Credentials, they are unable to view or modify the associated data.
• Furthermore, a threshold limit per user for triggering messages within an org and an org-level API limit is available on the Qntrl side.