How Rewind Keeps Your Data Secure

This article is written by Dave North, Rewind’s Cloud Architect. Dave has been a versatile member of the Ottawa technology sector for more than 20 years. Prior to Rewind, he was a long time member of Signiant, holding many roles in the organization including sales engineer, pro services, technical support manager, product owner devops director.

—

As a backup provider, you are trusting us with your data and that we are merely caretakers of this data. We’ve invested a lot of time and effort in making sure that we’re storing your data in as secure a manner as possible so we wanted to cover the steps and practices we follow.

Physical Security

We host our service using Amazon Web Services so the security of our data centers is taken care of by Amazon as part of our hosting costs.  Amazon has a very comprehensive set of credentials and certifications around security of the data center itself.  While this is a very important consideration, it’s only part of the equation and AWS themselves talk about security as a shared responsibility.  This means everything else is our responsibility.  So what does that entail?

For this article, I’ve broken things down into four main areas of concern:

• What are humans (operations) permitted to do?
• What are applications permitted to do?
• How is data secured at rest and in transit?
• How do we monitor for security events?

What are operations permitted to do?

All security controls at Rewind fall under the least privilege model.  Meaning we assign access to users based on the absolute least access someone needs to be able to perform their duties.  We do things like:

• Require two-factor authentication for all users for all systems.
• Assign users to groups with policies to these groups rather than individual users (much easier to track exactly who has what access).
• Only grant access to systems and data where users need that access to perform their duties.

What are applications permitted to do?

We apply a similar logic to applications that we apply to users.  Running in AWS, we can use IAM roles to define very specific access policies for what resources an application is allowed to access. These policies can be incredibly granular and can be used to enforce separation of concerns (ie. systems supporting Shopify backups cannot access data related to BigCommerce).

The access policies themselves are defined as part of an “infrastructure as code” model and held under version control which requires several levels of review for any changes made.

Where applications need to communicate with external services using credentials, the credentials are stored encrypted in a vault out-of-band from the service itself and any build or deploy systems we use.

We use the latest version of Ruby on Rails for most of our application development which provides many “out of the box” security benefits (encrypted cookies, sanitized DB queries via ActiveRecord, strong parameters).

Finally, our applications undergo an external audit by a 3rd party looking for common security concerns like SQL injection, brute force attacks, etc.

How is data secured at rest and in transit?

All data at rest in databases, cache services or other data stores is encrypted using standard AWS encryption mechanisms – typically AES 256.  In addition, for sensitive data like platform access tokens, we encrypt these with a second key within the database. This means that even applications and humans that can query the database must be able to decrypt the access keys in order to communicate with a platform.  The key itself is stored encrypted and only accessible by applications that require it.

For data in transit across the network (either our own services or out to a platform provider or the internet), all communication takes place using HTTPS (encrypted) connections.  We use a certificate with a 2048 bit key size on all of our Rewind endpoints and certificates are rotated yearly.

Related blog post: Adding an HTTP Audit Log to a Ruby Application

At the network layer, we use AWS security groups with rules allowing least privilege access to required services.  For example, only services that need access to a database can access that database.

Data is stored in one of 3 regional centres for compliance with requirements like GDPR.  If your platform data is in the US, we use a US AWS region; if your platform data is in Europe, we use a European AWS region and finally if your platform data is in Canada, we use a Canadian AWS region. If you have a requirement to have backup data stored in a different geographic location, you can contact our team and we can work with you to store data where needed.*

*Enterprise plans only

How do we monitor for security events?

AWS has a fantastic range of tools and services focused on security and we’re using most of them! Guard Duty gives us insight into things like network port probes or suspicious activity. Cloudtrail gives a full audit of all activity across all of our AWS resources.  VPC flow logs show a record of all network activity into or out of our cloud networks (and tools like Guard Duty can use these for real time analysis).

Security Hub rolls up results from many AWS services and gives us a quick dashboard into how things are looking across our AWS services.  In addition, it shows how well we are complying with the CIS Foundations Benchmark (a well-accepted list of security best practices for services running in AWS).

Security is like an onion – both have many layers

Hopefully, this short article on data security gives some insight into the many layers of security that are at work protecting your data at Rewind.

Have further questions about security? Check out our data security and engineering blog. Or contact us at team@rewind.com