Architecture

PoC to Production Grade

Security is of utmost importance when hosting your production workloads into public cloud. It is one thing to host a non-critical web resource publicly, but it is altogether a different game when considering to host a production grade application on the internet. After all, what do we mean by production grade? And why is it so hyped?

In this blog post, we shall see if this is just a hype or a serious business. Security of applications hosted on AWS is a shared model between AWS and customers. Where, AWS takes care of the security of the cloud, and customers are responsible for the security within the cloud. 

To keep this post simple, let us consider a simple static website hosted using S3 bucket and Route53 for DNS management. Static websites can be created in S3 buckets, and this is available as a feature – which means we can actually host our website within minutes with a few simple clicks.

By default, all the content stored in our bucket has to be public for our website to work. By enabling S3 static website hosting feature, we also get a URL using which anyone can access the website. However, if we own a domain name and we would like to use it rather than a URL generated by S3, then we need to use Route53 – DNS management service by AWS.

Using Route53 we can manage DNS entries to make the domain name point to our S3 bucket and serve the incoming requests with the content in the bucket. We can also create a similar setup for subdomains.

All this sounds simple and can be easily done. Take a look at the Terraform code in this repository. The basic code is included in the ‘insec’ folder which does the same. Here we have declared following resources:

  1. S3 bucket, to store index and error documents. Note that the name of our bucket should be the same as that of the domain or subdomain we own.
  2. S3 bucket objects, to upload index and error files as an object to this bucket.
  3. Route53 Hosted zone.
  4. Route53 record, to create a DNS record in the hosted zone and point it to S3 bucket endpoint.

This works! But is it enough from the security perspective? By virtue, if there is a room for improvement, the system is just not secure. Organizations today seem to be working on this principle. There are dedicated security councils driving security standards across organizations to protect their systems from any possible cyber attacks, keeping a constant eye on newly discovered vulnerabilities.

If we were learning AWS or Terraform or just how DNS works by implementing it for ourselves – the above setup is just fine. It teaches all of that. But the same setup will never be approved for production. Architecting a production system broadly involves 3 things – scalability, reliability and security

If we want to think about building a production environment for our website, let us take a look at a few things which can be done to improve it’s security. This by no means is the complete list of security measures to be taken for projects like these. The intention here is to realise the difference between production and sub production systems with respect to security.

  1. Encryption at rest: Encryption plays a major role in securing data at rest and in transit. Security systems rely heavily on encryption and cryptography technologies. We can enable encryption on the S3 bucket and objects stored within.
  2. Encryption in transit: By default, S3 buckets create an endpoint which uses HTTP protocol for communication. To secure data in transit, it is important to use HTTPS. This can be achieved using CloudFront distribution for our website.
  3. Monitoring: Monitoring enables transparency of systems. It helps us listen to critical system events and take actions. Events like modifications (CRUD) to the objects stored in buckets, incoming requests, system health in general can be monitored and alarms can be created. We can enable logging on our S3 bucket and CloudFront distribution.
  4. Versioning: Versioning helps track changes to objects and maintain previous versions. This is useful from a restoration and traceability perspective. We can enable versioning on our S3 bucket.
  5. Policies: We can enforce strict policies on the objects. AWS encourages the principle of least privilege to be implemented using policies and roles. In essence, this means giving only the required access to the entities interacting with the system. We can implement policies on our S3 bucket to implement this principle and avoid unnecessary risks.
  6. Caching: We can configure caching behavior to manage which methods are allowed and cached. This goes back to the principle of least privilege, so we can specify only those methods which we would respond to. We don’t need any query parameters currently, so we can disable the same.

As mentioned earlier, the list can go on. But this should be enough to make us understand how important security is and how different are production systems. AWS Well-Archicted Framework relies on Security as one of it’s pillars.

In this age of DevOps, people coming from Dev backgrounds have very less knowledge about infrastructure security and operations in general. The spirit of DevOps will be realized when we have a kind of synergy which would enable Devs to leverage Ops perspectives and vice versa.

Hey, if you like what I write do consider subscribing and sharing it with your friends. I am currently working on things like newsletter and courses on Let’sDoTech. I would be sharing some exclusive content in my newsletter starting June 2021. Come, be an early bird!

Twitter, Instagram, Facebook, LinkedIn

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s