SyncHub works by moving data from your cloud service to a database (either your own, or we can provide one for free - see below). All of our connectors work via the cloud service APIs, and all of these APIs are run over HTTPS. The exact version of SSL/TLS is determined by the cloud service.
To optimize performance, SyncHub sometimes caches your data requests on our servers, before moving them to your data warehouse. This caching functionality can be disabled however, and if you do so, it means your data will never be at rest on our servers.
Our master application database uses encryption at rest.
If you are using our free managed data warehouse, this also offers encryption at rest.
Your warehouse is literally a completely separate database. It has its own unique admin login (which we use to populate the data store, create the tables etc), and a unique "reader" login (which we issue to you, to use in your reporting tool). There is zero chance of data-bleed between warehouses.
For avoidance of doubt - while your data warehouse is encrypted-at-rest, within the database the actual data from your cloud service is not encrypted in your warehouse. Doing so would make it impractical to report on from your reporting tools.
If you are instead using your own database, then the security of this is obviously up to you. You simply provide us with login details which let us save your cloud data to the appropriate tables.
Users may restrict access to their hosted database to only specific IP address ranges. Most popular reporting tools will provide a list of their hosted IP addresses, and these are often a good starting point for you to lock down your data.
Broadly speaking, there are two mechanisms to do this - OAuth2 handshakes, and tokens.
The OAuth2 protocol lets a user (you) authorize a third party (SyncHub) to access another application (your cloud service), without ever exposing your username or password. Approximately 80% of our cloud connections offer this, and where available we always take it.
Once authenticated, we store your access token (and your refresh token, if provided) using a two-way salt-encrypted RijnDael algorithm. These need to be two-way because our application must pass them as-is back to your cloud service when authenticating.
The remaining cloud services (usually the older ones) unfortunately do not offer OAuth2 authentication. In these cases, they offer some form of token authentication. The implementations vary between cloud services, but generally consist of you providing us with an encrypted token which you generate yourself within your cloud service. We then use this to identify ourselves as we request data from your cloud service.
Because tokens are controlled by yourself, you can revoke our access at any time simply by deleting the token registration from your cloud service.
As part of our contract with cloud services, we regularly undergo mandated 3rd party security audits, such as penetration tests and architecture reviews. For example, as part of our Xero Practice Manager connection, we conduct an annual audit from the Australian Tax Office (ATO).
SyncHub runs off a single master database, containing app-related data (such as your SyncHub login, the endpoint configuration, segments, logging etc).
Within this database, we demarcate each of our clients using a distinct schema in SQL Server. This schema completely replicates our data structure for each client - for example, every client has their own Person table (first name, last name etc). Separating clients on a per-schema basis massively mitigates the potential for data-bleed between clients.
But it gets even more secure. Each schema has a different database login, making them effectively as isolated as separate databases. Again, this structure mitigates data-bleed between client apps.
Where two-way encryption is required, we’ve already discussed our use of the Rijndael algorithm above. Two-way encryption is required when we need to provide the unencrypted data to a third-party, such as sending tokens to your cloud service during authentication. This algorithm is very secure, and only our app has the keys to decrypt the information.
However, if we never need access to the unencrypted data, then we can take your security a step further with a one-way algorithm. In these cases, we use a salt-encrypted PBKDF2-SHA1 hash to protect your data. This means that nothing can ever view the plain unencrypted version of your data. The classic use case for this is storing the password you use to log in to SyncHub.
Our site offers two-factor authentication to further secure and protect your personal login.
Technically, if you are using our managed warehouse, our support team has access to your data. Though in reality this is very rarely needed, and only ever to help answer questions from customers.
If you are using our BYOD solution, we do not have access to your data.
Our payment system is driven by Stripe. Our system never captures nor stores your credit card information.
We have a lot of ambitious clients who want to get as close as they can to their business data but it’s often siloed in different systems, so while they were able to look at each dataset in isolation, bringing all the right metrics together was challenging.
The SyncHub experience was fantastic. It does what is says on the tin! The connection process is simple, the documentation is good and the communication with the team has been first class.
The SyncHub team got us to where we wanted to be and I think we all wonder how we ever lived without it.
SyncHub has allowed us to see week-to-week exactly how much staff and product we need in our stores.