Data transactions between Bot on terminal and Orchestrator

Hi All… I have a question about data security. When the transactions are processed through the queues, we can see the values of transactions in queue from Orchestrator. If I have a bot which reads data from web portal application and records it in excel sheet. While processing this, does the data read from website will be sent to Orchestrator? I mean the data can be accessed from Orchestrator? How secure the data is? Can Orchestrator have the control over data which is read on a terminal machine with Bot? If somebody hacks the machine where orchestrator being run, can data be read or modified?

You define the data you want to share with the Orchestrator queue. So if you don’t include it there, it will stay locally and Orchestrator will not process it.

Some quotes from the security element training:

  1. Communication between robot and Orchestrator is encrypted using the HTTPS protocol (requires
    an SSL certificate employed by the Orchestrator website)
  2. Orchestrator never contacts the robot directly. Orchestrator does not try to create a Remote
    Desktop Session on the robot computer.
  3. Sensitive data should not be stored in the logs. However, access to logged messages stored in
    SQL Server database is controlled by permission (user’s role(s)). For logged messages stored in
    Elasticsearch, the recommended solution is the X-Pack plugin from Elastic Co.
  4. Sensitive data should not be stored in the queue. However, access to the details of a queue item,
    stored in SQL Server database, is controlled by permission (user’s role(s)).

2FA would be welcome for the Orchestrator web interface though…

1 Like

Thank you Bolletje… That is helpful. Actually I want to read an account number from a mainframe screen and need to check its availability in webportal. So here when robot copies the account number, whether orchestrator can access the account number? or account number will be there only at bot level?

Orchestrator does not access our data unless we add to Queues in the Orchestrator

1 Like

Thank you Raj :slight_smile:

You can do both. In a simple implementation you will include the account number in the information that will be shared with Orchestrator. This is explained in the Orchestrator training, but for you to check: insert the Add Queue Item activity in a workflow. You will see that there is input property called “ItemInformation”. This is similar to arguments and information that will be send to Orchestrator, and will be also visible in Orchestrator.

As an example, see the image below used from the Academy level 3 training where you have the WIID (work item ID) visible:

What I understand from your use case is that you don’t want to share the account numbers. Firstly, please be aware that the connection between the agent and Orchestrator is secured. And secondly you can limit the visibility by user role in Orchestrator.

Nevertheless, if you still don’t want to share the data, then you can think of a reference table of account numbers and encrypted or hashed account numbers. Simply said: a dispatcher will retrieve all the account numbers that needs processing, put them in an Excel file in column A for example and paste the hashed value in column B. Then the dispatcher adds the queue items and inserts the hashed values in the ItemInformation for Orchestrator. The performer robot retrieves the queue item information and with it the hashed account number. It then uses this hashed account number to access the Excel file, look in column and matches it with the real account number in column A. You can store the Excel file on a secure shared drive.

This is just a simple way you can implement something like it. But then depends whether it’s worth the efforts.
Another solution is using the Invoke Code activity to insert encrypt and decrypt activities using AES-256.


Thank you Thomas :slight_smile:

1 Like