As a backup solutions provider, we recognise the importance to excellent security practices. We are a small team and we strive to real 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 required 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 dictions tools to alert us to security issues, so we can apply patches quickly.
# Access Control
Every developer and contractor is required to sign a 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, this rarely extends from a local version of the SnapShooter code base.
At sign up a users 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 information 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 providers account. At no stage does the data from the resource flow through SnapShooters 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 contracts code is subject to review by at least one other person before it can be 'merged and deployed into the production.
Code is tarted in a staging environment before being deployed to production
Our backend servers are currently hosted in 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 cloud providers of choice.
You can View AWS Certifications
SnapShooter uses Cronitor for continuous uptime monitoring and cron monitoring to ensure that your backups always run on schedule.
# Recovering Dismissed Staff members account
It's common to see the developer who setup the account to 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 a single developer setup the account and is no longer available contact email@example.com 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)