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
[email protected]
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