Inspiration

Flaneer + AWS, a story of Security

Most of Flaneer services are hosted on AWS. That means that whether it is user data, files, or virtual workstation, it will be hosted on an AWS server. This article will dive into how we do it, how we make sure it is as secure as it can be, and how it will evolve over time.

Saying that everyone is concerned about their data and privacy seems obvious. At Flaneer, we're working with multiple layers of sensitive data:

  • a company's files system, such as Google Drive or One Drive
  • a team's data and connection information
  • a user's virtual workstation, aka its work, streaming over the internet

It is a necessity to build a safe and secure place for users to work.

The goals of this article are multiple. First, what is AWS and why do we consider it as a secure option? Then, how do we make it even safer? Finally, when will we switch to another cloud provider, especially a European one?

How do we work with AWS?

What exactly is AWS doing anyway?

When you want to code something, be it a SaaS or a website, you will need to write code that will interact with a server. This server can store data or run some code. The critical part here is understanding where this particular server is and who is taking care of it. Most of the time, two solutions are possible (and being a startup working in infrastructure, trust me, it is not always an easy choice).

Solution 1: The company (here Flaneer, yours truly) will buy and manage its own hardware. This is a self-hosting solution.

Solution 2: The company (still Flaneer) will rent servers from someone else (a cloud provider). This is a cloud solution. While another company is renting you servers, they cannot access them. Only you are allowed to access and interact with them.

At this point, you probably guessed it: AWS was one of the possible cloud-provider we could go with. Other candidates are often:

  • GCP (Google Cloud Platform)
  • Azure (Microsoft)

and less often:

  • AliCloud (Alibaba)
  • Oracle
  • OVH

and even some very small and local ones. However, the smaller the provider, the less reliable and flexible it will be. It will also be much harder to scale up (or down, that happens sometimes).

This is why we went with AWS. It is the biggest cloud provider in the world and the one we felt the most comfortable to start with. Before diving into how we work with AWS, we think this might be a good time to answer some of the questions we often get asked while onboarding customers.

Why AWS and not another cloud provider?

  • AWS is probably the safest cloud provider out there. Security being our number one priority, it seemed like a no-brainer, and it still seems like it.
  • AWS is the most reliable cloud provider globally, with less than 2 hours of downtime per year. This is huge and can directly remove some cloud providers from the equation (looking at you OVH).
  • The amount of services AWS offers is massive. This allows our engineering team to quickly (that means less time than to make lunch - although that would depend on where you live and what you consider a good lunch (looking at my co-founder and his healthy Burger King habit here)) try and iterate on new solutions.
  • While not European, AWS has a lot of data centers in the world (cf Image 1). This allows us: 1. to easily use the closest servers to our customers; 2. to make sure these closest servers are actually close to the customer. On that note, since:

-> Flaneer uses a French entity in Europe.

-> and that most Flaneer users are European

This forces AWS to respect GDPR.

Why are we not self-hosting?

When you think about it, this makes a lot of sense, especially for a startup building a new infrastructure service from scratch. This would allow us to offer much lower prices and to customize much more the hardware we can offer.

However, this is extremely CapEx intensive and requires many skills that two recently graduated engineers did not have at the beginning. Messing with RaspberryPI, and building small clusters will not allow you to build massive infrastructure, trust me on that one.

However (trust our geeky side on that), we will work on that at some point during Flaneer's life.

Why are my data safe & secure?

You can read extensively about why AWS is secure here: https://aws.amazon.com/security/?nc=sn&loc=0.

As an example:

AWS supports more security standards and compliance certifications than any other offering, including PCI-DSS, HIPAA/HITECH, FedRAMP, GDPR, FIPS 140-2, and NIST 800-171, helping satisfy compliance requirements for virtually every regulatory agency around the globe.

We talked a lot about how AWS is safe. But it is as safe as you make it. If you make a mistake, AWS will not save you: this is why we are extra cautious with every service we use. We'll dive more into this subject in the next part.

What do we do with AWS?

At Flaneer, we use a lot (and by a lot, I mean it) of AWS services. We want to give a brief overview of the main ones and how they are related to our user's data and privacy.

DynamoDB

This is a NoSQL database. This is where we store most of our user's information. DynamoDB will encrypt at rest all of our user's data with KMS encryption keys. We also use a second layer of encryption for extra sensitive data.

Moreover, these databases are not available to anyone except our Lambda backend function.

Lambda

Lambda is the name of the AWS serverless service. This is where most of our logic takes place. They also encrypt at rest most of the data, and more importantly, they use custom roles, allowing them to perform just the actions that they are supposed to do. This allows us to fight role privilege escalation.

S3

This is probably one of our most critical services since this is where we are hosting our user's files, as in a Flaneer version of GoogleDrive. Here, no stones are kept unturned:

  • We block all public access.
  • We make sure no one has access to a particular file except its owner.
  • We ask AWS to encrypt at rest every file entering the bucket.
  • We encrypt every file, in our web app, before sending them to the bucket.

Finally, like with our DynamoDB, no one can access the files except our Lambda backend.

EC2 and their Networks

This is the second most crucial service since this is where our users:

  • work, browse the internet, use their software
  • manage files from their Flaneer Drive, or even from local drive
  • collaborate with teammates

First, using AWS VPC and subnets, we ensure that each EC2 is separated from each others. We consider them in a black hole (except that they can access the internet, hopefully). This allows us to make sure that one EC2 cannot access another one (and thus someone else's work).

We also encrypt the data inside each EC2 by managing their EBS closely. We even (when it is possible) encrypt the memory of our EC2.

Finally, the stream is encrypted at rest, obviously. Thanks to this, no one can see what someone is working on by ear-dropping on the data on transit.

Cloud trail

Each and every operation I talked about above is logged and stored with AWS Cloudtrail. This allows us to periodically check who did what and see if it matches the rules we set up. If someone accessed a file it should not have, we will find him.

I won't talk about the rest of the services we use. First, because this would only interest a handful of people. Second because they are less influential in our product.

Will we switch to another cloud provider?

Is AWS, an American company, as safe as it seems?

Well, first of all, the American government cannot get access to your data. Well, they could, but they would have to:

  • Ask an American Judge
  • The judge would have to agree with the demand: is it justified? proportionate? etc.
  • If the judge agrees, it is now AWS turn
  • AWS would have to agree to the request and make sure the demand can work with European laws.

This is a heavily complex process, and you can read more about that from AWS themself here and here (latest report up to date: June 2021).

Now, we can be as careful as we want and read our AWS contracts every night for a year, this will only let us go that far, and that is as far as AWS wants us to be.

We can't really know who is accessing the servers for maintenance purposes or even where the data are transiting. We are (sadly) bound to trust them. However, this need for trust is (in our opinion) not related to AWS being an American company. Some European cloud providers are even less transparent than AWS, and a French judge could also ask a french cloud provider to access our data.

By encrypting all of our data at rest, we are making the most of what we can do to protect our users, their data, and their work.

Why don't we go with another large Cloud Provider?

While we are using AWS at the moment, nothing stops us from using Azure or GCP. It does, however, mean a technical cost on our side to be cloud-agnostic. We are working on it, and someday, our users will be able to keep their files and workspace in the cloud of their choice.

We know some companies do not want to work with AWS (or any other cloud provider), and that's why we are working on improving our platform with more and more offers.

Get started today