As a backup solution provider, we recognise the importance of excellent security practices. We are a small team and we strive for excellence.
# General Practices
- Access to all servers, source code and all 3rd party applications are secured with two-factor authentication where possible
- We use strong, randomly generated passwords that are never reused and cycled.
- Developers and contractors are only given the lowest level of access that allows them to work. No one is granted access to production system or databases unless explicitly requested (these operations happen under the supervision of a director).
- We NEVER copy production database data to external devices (like developers' laptops)
- We NEVER access customers backed up data unless explicitly requested to by a customer.
- We employ the use of automatic security vulnerability detection tools to alert us to security issues, so we can apply patches quickly.
# Access Control
Every developer and contractor is required to sign an NDA before gaining access to any sensitive information about SnapShooter Limited, which also covers our customers' data. Contractors are given the lowest access that will allow them to complete their tasks, which rarely extends from a local version of the SnapShooter code base.
At sign up, a user's password is hashed using bcrypt before being stored.
Customers are free to enable 2FA on their accounts using the Google Authenticator application method.
Passwords can be recovered using a password reset token. This does not reset 2FA which can be reset via support. The method to restore 2FA will depend on the organisation and may require billing and cloud provider information.
# Data Flow
Depending on the backup method, the flow of data is handled differently.
# Data Flow / Native Backups
When performing native backups, the data from your servers/volumes/instances/disks flows from your server to your cloud provider's account. At no stage does the data from the resource flow through SnapShooter's infrastructure. In the case of AWS/DigitalOcean and Hetzner, there is no way for backups to be downloaded.
# Data Flow / Object Storage Backups
When we perform an object storage backup, that is a backup of files and folders or a database to object storage. The data from your resource is streamed directly from your server (or proxy server) directly to the object storage of choice.
We login to your server to request the backup to happen and we monitor the progress, but at no point does the content of the data flow through a SnapShooter server.
# Software Development Practices
The code that runs SnapShooter is version controlled and all employees and contractor's code is subject to review by at least one other person before it can be 'merged and deployed into the production.
Code is tested in a staging environment before being deployed to production.
Our backend servers are currently hosted on AWS. Our current region for servers and databases is located in Ireland. We are a multi AZ setup with a fault torrance of N+2.
Our hosting for servers for management of backups only holds data for the management of backups as well as billing. The data from backups are located with your own cloud providers of choice.
You can view AWS Certifications here.
# Recovering a dismissed staff member's account
It's common to see the developer who setup the account no longer be a part of the business.
We strongly recommend you setup with a plan that supports teams and invite other members of your business to have management access to the account.
In the rare case that a single developer setup the account and is no longer available, contact firstname.lastname@example.org to arrange the recovery process.
# SSH Keys
When performing backups that require us to access a customer's server, we generate 4096-bit RSA keys. When you register for SnapShooter, we generate a new key. You can use this key for each backup, or generate new key pairs on demand. The private key is stored in our database using AES-256 encryption. When connecting to your server to perform a backup, the server establishing the outbound SSH connection is protected behind a NAT gateway and has no direct access to the internet (including inbound SSH)