Security FAQ
Most of the Q&A's are related to the SaaS deployment type of getint.io (e.g. default one for Jira Cloud customers).
We do our best to meet Security standards expectations of our customers.
Although, if for some reasons what you find here would not meet your requirements, you can always use a On-Premise (Self-Hosted) version of getint.io. This should let you to to run getint.io platform fully behind firewall, within your company infrastructure.
We are transmitting, processing and storing only the essential data that is required to perform integration and synchronization according to customers setup configurations. We also collect logs of each synchronization which are used by customers and support to identify and resolve encountered problems.
Type of data depends on what exactly was configured by customer for each integration, but it may include
- items (issues, tasks, bugs, incidents) data, like fields values
- comments data
- users identifiers (like accountId, full name)
- encrypted connection details stored in a database
- url to apps instances that are under integration, eg. Jira url
Should not. Unless that data is stored in the items that are synchronized between apps and it was explicitly picked up by customer for a sync.
E.g. for each employee, customer creates a Task in Jira Project, and in that task custom fields there are stored employee gender, monthly salary etc. And customer wants those tasks including those custom fields to be synced to the other Jira instance. Then getint.io would keep those custom fields values in logs as a trace after performed synchronization
In SaaS deployment each customer data is stored on a one machine. And on that machine integration / synchronization logic is performed. Therefore there is no transmission of the data to any external services.
We use SSL for a HTTP protocol. Also REST communication is authenticated with JWT.
Keys are stored in encrypted form on hosts owned by getint.io. We can not provide much more information due to security reasons.
Not applicable. If yes, only Getint.io company owners.
Not applicable. If yes, only Getint.io company owners.
Yes, source code is under a GIT source control, provided by Azure DevOps platform.
There is no cleartext password stored in a code. All password, needed for running application are provided at runtime.
Daily backups, kept for 30 days.
Under SaaS deployment, our infrastructure is deployed on Linode - comapny that has 1 milion of customers world wide. All backups and hard drives, VMs utilization is handled by Linode and done according to their SLA terms.
For each patch we are running threw the process of unit testing, automatic testing, uat testing and deployment to production.
Each patch is encapsulated as a new getint.io version, stored within internal artifactory.
We use a blue / green deployment technique to make sure patch deployment to production is backward compatible.
Data is provided by the customer who obtains an account within the application. Each customer has a separate database schema in which his data is stored. All the configurations, setups, connection details are provided by the customer and saved within his 'database' part. External users outside of his organization will not have access to load / read the data. Also, except backups, his data is not synchronized, transmited or shared to any other external services, machines.
Only getint.io support stuff has access to integration / synchronization logs in order to help customers solving the issues.
We use standard techniques provided by Spring framework.
Not yet. We are planning to be on this program by the end of 2021.
Users are authenticated using JWT tokens. Data is transmitted via HTTPS so data is encrypted via this protocol. Authentication is handled by standard Spring mechanisms.
Yes. With frequent rotation.
Only for internal systems used by getint.io company members.
Customers are authenticated with JWT tokens for both cloud and on-premise solutions. There is a flat roles structure so authenticated user gains access to the most parts of the product.
There is plan for introducing roles hierarchy but no delivery date is defined at moment.
As above.
Yes we follow best practices, including code reviews, staged deployments, UAT and Smoke testing and many others.
No
Yes, before the release, on staging environments.
Getint.io company members.
No