Background information Glossary
Introduction 1.
“ ”
Next to the fact that we want to be in control of our Jira environment, which is hosted in one of our data centers, We want to be in control of what data will be synced and exposed to our customers.
CHRISTOF CUYPERS - GANTER
4BOOK A DEMO
1. Information is exchanged between all known parties.
a. The sender wants to be sure that the information is sent
to the right destination.
b. The recipient wants to be sure that the information is
received from the right source.
2. The shared information has not been tampered with by
third parties.
3. The information is restricted to what the sender wants to send,
and what the receiver wants to receive.
4. Every data exchange is logged for audit purposes.
5. Any security breach is escalated to all stakeholders.
In any type of information exchange, it is best to ensure that it is done in
a secure way, such that:
This white paper provides an overview of how Exalate handles the information that is exchanged between 2 issue trackers
Exalate is an advanced synchronization engine with various deployment
models and information exchange paths that allows users to synchro-
nize information between multiple trackers in a secure and controllable
way. To understand the security aspects of the solution, it is important
to grasp how information is processed by what components, and how
information flows through these components.
2.
6BOOK A DEMO
2.1.2. Built-in Autonomy
The Exalate Node is the application which acts as a gateway between
an issue tracker and the network connecting different environments
directly. It has the following functions:
• Detecting the fact that the data “under sync” has been changed
or new data needs to be brought under sync
• Extracting the relevant data from the tracker and formatting it
as a structured message
• Exchanging the data with other nodes connected to the network
• Applying incoming messages locally
Whenever 2 companies decide to integrate their systems to exchange
information, it must be done in such a way that neither of the parties
loses control of what information is sent out and how incoming informa-
tion is processed. Keeping the systems loosely coupled is essential
to ensure scalability and maintainability.
This requirement leads to the fact that every side has its own Exalate
Node which will translate any information between the local context
and the exalate network.
7BOOK A DEMO
In the synchronization process, 4 main components are involved - 2 trackers that host the issues, and 2 Exalate Nodes. The trackers can be any of the supported trackers (Jira, Salesforce, HP ALM/ QC, ServiceNow, GitHub, Zendesk, Azure DevOps, ...).
• A - Exalate (Blue) interfaces with Tracker (Blue) for retrieving
issue information.
• Either polls Tracker (Blue) for any changes since the last full
synchronization, or gets triggered by Tracker (Blue) that a
change has occurred.
• Collects all relevant issue information and composes a message.
• B - Exalate (Blue) sends the message to Exalate (Red) for further
processing.
• C - Exalate (Red) decomposes the message and applies the mes-
sage to the Tracker (Red), such as updating an issue summary.
• D - Exalate (Red) interfaces with Tracker (Red) to retrieve the
changes which have been triggered by the synchronization
and composes an acknowledgment message.
• E - Exalate (Red) sends the acknowledgment message back
to Exalate (Blue).
and applies it to Tracker (Blue).
Information flows as follows:
There are many potential reasons why a synchronization might fail.
This section details how the transactional synchronization engine works.
Whenever a change happens to a set of information that requires syn-
chronization, Exalate will pick up this change immediately and start to
synchronize the information.
It tracks the synchronization events, ensuring that every event proces-
ses in the same order as the original issue event. This means that if a
problem occurs in a change process, it will be queued and applied in the
same order as it was made in the original issue. Exalate ensures that all
changes are applied as soon as the problem is fixed.
Additionally, Exalate uses an integrated retry mechanism for resolving
errors. It helps recover any failure and resume synchronization from
the point of interruption.
2.1.3. The Synchronization Process Uses Queues which are Persisted in a Relational Database
1. The synchronization process starts with one of the available trig-
gers: operation, trigger, API, post function, or through polling for
change.
2. Exalate runs the outgoing sync processor and extracts a replica
from the issue. With the outgoing sync processor, you can spec-
ify what information can be sent to the destination instance.
3. The outgoing sync event is registered in the Sync Queue.
4. The outgoing sync event is then sent to the destination instance.
5. The incoming sync request is registered in the sync request
queue on the destination side.
6. Exalate runs the incoming sync processor with the received mes-
sage, , and applies the change to the local issue.
7. Exalate runs the destination instance outgoing sync processor
to create an acknowledgment message.
8. The act of synchronization is completed and all sync operation
data is cleaned - the Exalate sync panel status is changed to
Synchronized.
The numbers in the list below correspond to the numbers in the above diagram:
11BOOK A DEMO
2.2. Deployment models
Exalate’s design goal is to provide a common issue integration platform,
independent of the particularities of the underlying tracker.
This section of the document outlines all the different deployment
models supported by Exalate.
The diagram below provides a full overview of how Exalate integrates
with each of the different underlying trackers. Every deployment model
has different information exchange paths.
2.2.1. Deployment Type 1 - Exalate as a Separate Application on-Premise
The ‘On-premise server’ deployment is used whenever you want to keep
the integration processing within your security parameter. A separate
(virtual) application server hosts the Exalate application, the database,
and the file storage. The application acts as the intermediate gateway
between the tracker and the Exalate network.
2.2.1.1. Connections
by the tracker (Label 1B in Graph
above)
late nodes (normally HTTP/S), (Label
A in Graph above)
(Postgres on port 5432), (Label 1A in
Graph above)
which is used to access the Exalate console
and the Exalate transport layer.
13BOOK A DEMO
2.2.2. Deployment Type 2 - Exalate as an add-on of Jira Server or Jira Data Center
The embedded add-on approach is used for
Jira Server and Jira Data Center. Atlassian Jira
provides an extension SDK, allowing you to
run additional functionality in the same process
space as the application itself. This allows for
unrestricted access to any information
maintained by Jira.
Access to Exalate functionality, such as transport and console, is
controlled by the Exalate REST API (Label A in the graph above).
The outgoing connections are between the Exalate add-on and the
other Exalate nodes (normally HTTP/S). Access to the database is
controlled by the ‘Active Objects’ database layer provided by the Jira
environment (Label 2A).
Cloud Servers
Exalate Running on Cloud
G I T H U B / S E R V I C E N O W / S A L E S F O R C E / Z E N D E S K
B M C R E M E DY H P A L M / Q C
S E R V I C E N O W
DEPLOYMENT TYPE 1
Firewall
2.2.3. Deployment Type 3 - Exalate as an Atlassian Connect add-on
This deployment model is exclusively used for Jira Cloud, which requires
Atlassian Connect add-ons.
These add-ons are web applications running on separate hosts. They
are integrated with Atlassian Jira Cloud using various techniques such
as REST API requests, webhooks, iframes, etc. The Exalate nodes are
deployed in a single tenant setup on Exalate cloud.
is restricted by what the Jira Cloud API
allows to access.
res between Jira Cloud and the app can be
found here.
Atlassian Cloud add-ons are, in most cases, multi-tenant. This means
that a single Atlassian Connect app will support multiple subscribing
Atlassian applications. This is not an option for Exalate, as it provides
a scripting interface that can execute database queries and REST calls.
It is essential that the environment provided for one customer is com-
pletely separated from the environment of another customer. The
following components are essential to implement this single-tenant
architecture:
For each Jira Cloud instance, a separate environment is brought
up, using advanced docker related technologies.
The process space, file system, and database are completely con-
tained in a separate ‘node-environment’.
Exalate Hosts are hosting multiple node-environments.
• The mapper (Label 3C)
Since Atlassian cloud is interfacing with the application using
a static URL (connect.exalate.net), there is a need to redirect to
the correct node.
The mapper is a reverse proxy that will redirect calls from Jira
cloud to the right node application using the id provided by
2.2.3.3 Mapper connections
The mapper is a reverse proxy which accepts connections for:
• Incoming connections
• Exalate node connections for synchronization message
exchange (Label A)
exchange (Label A)
• Database access (Label 3A)
All nodes are fronted with a reverse proxy for SSL termination.
Connection to the database is on a docker specific local network
• Infrastructure management
such as Github, Zendesk, ServiceNow, and
Salesforce. The main difference between this
deployment model and the deployment model
type 3 is that any connection with the tracker
is direct, without a mapper in between.
The application itself is a docker environ-
ment operating in the same way as Jira Cloud
nodes, where process space, file system, and
database are completely separate from other
environments.
2.2.4. Deployment Type 4 - Exalate as a Separate Application in the Cloud
There are 2 types of interactions with the tracker depending on the
services provided by that tracker:
2.2.4.1. Connections to the tracker (4A)
• Push
Exalate will register with the tracker to receive webhooks when-
ever the tracker provides this capability - the tracker will open a
connection to the Exalate node to post the hook.
• Poll
The poll model is used to identify changes occurring on issues -
in this case, all connections are built from Exalate to the tracker.
All traffic is encrypted - this is enforced by the trackers.
For interactions with the tracker, the Exalate node will communicate
as follows:
(Label A)
• Outgoing connections to the database server (Label 4B)
All nodes are fronted with a reverse proxy for SSL termination.
Connection to the database is on a docker specific local network
2.3.1. Public to public
There are currently 3 types of connections for Exalate. This section
outlines how they work. A connection type determines how connections
between Exalate Nodes are built.
In a public to public connection type, TCP/IP connections are initiated
from both sides.
It assumes there is an unobstructed network path between the two
nodes. Synchronization events are transmitted to the other side from the
moment these events occur.
2.3.2. Private to public
This connection type is used whenever there is a need to connect a
public instance, such as Jira Cloud/ Zendesk, with an internal server. A
firewall obstructs any connections from the public / Internet to the pri-
vate server. In this case, all connections are built from the private ser-
ver to the public server, collecting all changes that need to be applied
Local connections are used to sync between local project configura-
tions, such as between a Jira Service Desk project and one or more Jira
Software projects.
2.4. Source and Destination Authentication
One of the biggest risks in the exchange of information between a
source Exalate Node and a destination Exalate Node is that the source
sends data to the wrong destination, or the data is received from the
wrong source.
To mitigate this risk, a JWT based approach has been implemented.
JWT ensures that the client making the request is a trusted source,
which is something that HTTPs is missing. For JWT to work, the client
sending the HTTP(s) request needs to have a secret that the server also
has. This acts as a private key to sign tokens with. Every request from
the client must pass the token somewhere in the request - we pass it in
the “X-Exalate-JWT” header - so that the server can find the secret and
validate the signature. If the signature proves that the client formed it
using the same secret, the client has proven its identity.
This secret is exchanged at the moment that the connection is
established and is contained in the invitation code.
TRY IT FOR FREEBOOK A DEMO
Complete autonomous control over both outgoing and incoming information
A frictionless collaboration across internal teams and outside company borders.
Maximum security due to complete control over the data being shared with the other systems.
Limitless customizability to fit your unique and complex integration needs.
Set up a synchronization between multiple Jira instances, Salesforce, Azure DevOps, ServiceNow, Zendesk, Github, HP ALM & more.
3.
This section expands on the security risks which exist in the product and the techniques used to mitigate this risk.
23BOOK A DEMO
3.1. Data handling
Exalate is a middleware that transports data between 2 issue trackers.
This section focuses on how this data is protected by looking at confi-
dentiality, integrity, and availability - also known as the CIA triad.
In section 2.1.3, we explained how the data flows through the system.
The data security aspects are relevant in the following steps:
THIS PROCESS IS INDEPENDENT OF THE DEPLOYMENT MODEL, OR THE CONNECTION TYPE.
When the data is retrieved from the tracker
When the data is stored as a sync event in the database
a - When the data is sent to the other side
b - Where it gets queued into the sync requests queue
When the data is processed and applied to the local issues
Step 2
Step 3
Step 4
Step 5
Step 2 - Data retrieval
Migration
Risk
Mitigation
¹ Note that client-side certificates are not supported as this is not currently supported by different trackers.
• Man in the middle attack when the data is retrieved
• Data is retrieved from the wrong instance
• For Deployment Type 1 and 3
Use encrypted (https) traffic between the Exalate Node and the
tracker with properly defined certificates¹
• For Deployment model 3
The communication between the tracker and node is protected by
an Atlassian specific JWT mechanism - More information here
• Data is stored in the database and file system, also known as blobs
- this can be read when accessing the host.
• Protect access to the hosts and the databases
• Encrypt the payload in the database
26BOOK A DEMO
Step 4a - When the node sends the data to the other side
Step 4b - Where it gets queued into the sync requests queue
Step 5 - When the data is processed and applied to the local issues
Risk
• Information is sent to the wrong exalate node
• Information is received from the wrong Exalate Node
• Configuration change in the database
• As explained in section 2.4, a JWT token mechanism is used to
sign every message between the nodes such that the client is
recognized as a trusted source.
• The destination risk is mitigated by ensuring that the connection
is built using the invitation code.
3.3. Access control
All data is backed-up on a daily basis, retained for 2 days, and offline
stored on rsync.net.
As explained in the previous section, a risk exists that people with
appropriate access to the database/ file systems can breach data con-
fidentiality. This is only relevant for deployment models 3 and 4, where
the Exalate functionality is hosted by us. In deployment models 1 and 2,
Exalate functionality is hosted by you, which means the access control
aspect is handled by your own security roles.
Exalate uses 2 hosting providers:
Security white paper Online backup | FAQ
3.3.1. Physical Access Control
All Exalate servers are Linux-based and are protected:
• Access to the environment is through a single jump box. Access
to the jump box is PPK based per NOC engineer, and access is
revoked at end of contract.
• Every Exalate node is running in its own virtual environment (com-
pute, file and database storage).
• Access to the environment is only possible on ports 22 (ssh) and
443 (https). Port 80 is allowed but will always be redirected to
443.
• Offboarding
One of the mandatory tasks during offboarding staff is to remove all
public keys of this specific person from all the Exalate servers
A monthly penetration test is performed on all Exalate hosts to identify
potential and/or unattended breaches.
Access to any Exalate application functions as follows:
• Every environment is a fully single-tenant setup with its own
database scheme and process space.
• The internal network (between the load balancer and the nodes)
is a hub based network where nodes are forbidden to access each
other’s network.
• Access to the database scheme is protected by user id and
password.
• The Exalate application access is enforced by authenticating
the user by the underlying issue tracker - Exalate administration
user id and passwords are not stored in the database.
• The authorization model is plain and simple: all entities
(connections., triggers, ...) can be modified, once you have access
to the application.
3.4 Application security
The processors (incoming and outgoing sync processors) are executable
code that can manipulate any of the information which is reachable by
Exalate.
Therefore, it is vital that a governance model is put in place to ensure
that the right people have access to the configuration interface - the
Exalate Console.
Bugs happen frequently, and the risk that a developer introduces a secu-
rity breach is high. We are currently in the process of introducing appli-
cation security processes in preparation for an ISO27001 certification.
• The scripts can be monitored for any change.
• The core mapping functionality can be externalized to the file
system and versioned through git or other VCS systems.
• Access to the data is always performed as the proxy user -
therefore, the authorization of this proxy user needs to be
governed in the underlying tracker.
The processors are a significant risk in the security model provided by Exalate.
4.
Throughout the document, we use various terms which are explained in more detail here
32BOOK A DEMO
gement system requiring integration.
The Exalate console allows
configuration of the synchronization.
exchanges structured messages
between multiple trackers.
issue ‘under sync’ - this typically results
in creating an issue on the other side.
To trigger an Exalate means to start
the Exalate operation.
To trigger an Exalate
WHEN IN DOUBT, OR IF YOU HAVE QUESTIONS/FEEDBACK ABOUT EXALATE OR THIS DOCUMENT, PLEASE SEND US AN EMAIL AT SECURITY@IDALKO.COM
Experience a seamless collaboration between teams across Jira instances, ServiceNow, Zendesk, Salesforce, Github & other trackers.
BOOK A DEMOTRY FOR FREE
“With the amazing support team and the flexible capability of Exalate, we were able to see it work nicely and become an important part of our work life cycle.
HUNG NGUYEN - DELL
“Exalate is marketed as the most flexible synchronization tool for issue trackers
and that short definitions is pretty accurate from what we have observed.
PIOTR RADTKE - NETGURU
“The first thing that hits you when using this app is how easy it is to get a synchroniza- tion up and running. By default, everything works so well.
DANIEL MIKS - RIADA
2.1 The synchronization process