Data Storage and Security
This page describes where the EvTrack cloud service stores personal data and how it is protected. Customers who run EvTrack on their own servers should also read On-premise installations.
Where data is hosted
EvTrack’s cloud service runs in four hosting regions:
| Provider | Region |
|---|---|
| Amazon Web Services | Frankfurt, Germany (eu-central-1) |
| Amazon Web Services | Cape Town, South Africa (af-south-1) |
| Amazon Web Services | London, United Kingdom (eu-west-2) |
| Oracle Cloud | Abu Dhabi, United Arab Emirates |
Each customer’s application and databases are hosted in the region the customer chooses when they sign up. Some files and services are handled by sub-processors whose locations are listed separately.
All traffic to the service passes through the Cloudflare web application firewall, which filters malicious requests before they reach EvTrack’s servers. Photos, ID document images and other files may be stored in Cloudflare R2 object storage. See Sub-processors for every service that handles personal data on EvTrack’s behalf.
The databases run in private networks and cannot be reached from the internet.
Encryption
- In transit: connections to the service use TLS 1.2 or TLS 1.3 with strong ciphers.
- At rest: in the cloud service, stored data is encrypted at rest. Sensitive fields, such as identity and passport numbers, are additionally encrypted inside the database.
- Audit records: the details of each change in the audit log are stored encrypted.
- Backups: encrypted backups are taken daily and kept for 7 days.
Keeping customers’ data separate
The cloud service is multi-tenant: customers share the application and database, and every record belongs to one customer. The application filters every database query by customer, so one customer’s users cannot see another customer’s data.
Access and sign-in
- Passwords are stored as BCrypt hashes, never in readable form.
- Two-step sign-in: users can be required to enter a one-time code sent by email. The code is valid for 10 minutes and allows 5 attempts.
- Single sign-on: customers can sign users in through their own identity provider using SAML, including Microsoft ADFS.
- Roles and permissions control what each user can see and do, including access to visitor details and reports.
- Sessions end after 30 minutes of inactivity, and each user can have one active session at a time.
- Integration APIs are switched off until a customer enables them. Stored secrets, such as API keys and passwords for connected systems, can be replaced but not read back.
- Server logs mask personal data.
Backups
Daily backups are kept for 7 days and then deleted. Data that has been deleted from the service can therefore remain in a backup for up to 7 days. See Retention and Deletion.
Mobile devices
The EvTrack FrontDesk kiosk and EvTrack Guard apps send visitor data to the service as it is captured. When a device is offline, it queues transactions and sends them once it reconnects. Each queued entry is encrypted on the device. The FrontDesk device key is held in the Android Keystore.
When the kiosk camera reads an ID document, the text is read on the tablet and the details are then sent to the service, for example to check the visitor’s identity. Where the customer enables it, ID documents can also be read by Microsoft Azure (see Sub-processors). An image of the document is kept only if the customer switches on saving ID copies; this is off by default.
On-premise installations
Customers can run EvTrack on their own Windows servers with their own MySQL or MariaDB database. In an on-premise installation, personal data stays on the customer’s servers unless the customer connects outside services, such as their email server, an SMS provider, ID document reading or an integration. The customer is responsible for securing and backing up those servers.
An on-premise installation can optionally use Visit Relay, which sends visit passes to an EvTrack cloud cluster so that visitors can receive them.
Configure this in EvTrack
- Security configuration: API access and other security settings
- SAML single sign-on: sign users in through your identity provider
- Roles and permissions: decide who can see personal data
- ID documents: which identity fields are stored and how