This is our fourth post in the series that documents Maplewave’s journey to transition our IT infrastructure to the public cloud. Follow the links for Part 1, Part 2, and Part 3.
It has been a while and a lot has happened since my last update, but as promised, here is Maplewave’s take on implementing a secure public cloud environment.
In this blog, I will explore security responsibilities, products that enhance security, and secure designs.
Like everyone who has ever seriously considered moving applications into the public cloud, we had questions about security. Data breaches seem to happen every other day and they are often linked to the public cloud in one way or another. Our stated goal from the beginning of our process was, “To make our cloud environments even more secure than our own data center.” And like everything else on this journey, we are still evolving our security practices to be the best they can be, but I think we are in a pretty great place!
Shared Responsibility
One thing to remember about public cloud security is it’s a shared responsibility between the provider and the customer.
The provider is responsible for the physical and logical security of the underlying hardware, software, networking, and facilities that provide the services. The customer is responsible for implementing security controls and measures to the services as they are configured and consumed, for example, services like EC2 or S3.
If a customer defines an EC2 compute instance and then leaves that instance wide open on the internet and a threat actor does something nefarious, it is not the responsibility of the provider. This would be like storing private information in an S3 storage bucket and then making it available to the public!
In order for it to work, everyone has a part to play when it comes to keeping your public cloud secure.
Keeping Secure With The Right Tools
Consuming public cloud services requires a significant focus on security and an understanding of the various tools and methods available – and trust me when I say there are a lot of tools out there!
To secure our applications and data in the public cloud, Maplewave uses a combination of AWS services and third-party products. Here are some of the AWS services we use:
- Identity Access Management (IAM): A web service that helps securely control access to AWS resources. Use IAM to control who is authenticated (signed in) and authorized (has permissions) to use resources.
- Security Groups: A virtual firewall to control inbound and outbound traffic from EC2 compute instances.
- Access Lists (ACL): Controls traffic, but at the Virtual Private Cloud (VPC) networking layer rather than at the EC2 instance.
We also take advantage of other third-party products, such as next-generation and web application firewalls to protect our infrastructure. These products can be easily purchased on-demand through the AWS Marketplace or using a ‘bring your own license’ model. Maplewave was very fortunate in this instance because we were able to continue using the same security vendor that we used in our physical data centers. These virtual products maintained the same user interface as their physical cousins, making our transition extremely painless.
Cloud Design
Beyond just products and services, you should also consider the overall design of the cloud environment to protect your applications and data.
For several years, threat actors have used the technique of compromising a single system and then moving horizontally to gain access to other interesting systems. Historically, companies have protected systems by placing barriers at the edges or interconnects with other networks, like the internet. But if a threat actor can compromise a system on the inside of these barriers, they can then mingle with other systems without worrying about other walls. This led to a trend in the security industry called “micro-segmentation”, which allows companies to isolate workloads from one another and secure them individually.
Implementing micro-segmentation in the cloud environment can be done in various ways and brings great benefits, including smaller attack surfaces and focus on securing applications, and not just the hosts that run them. One way that we have implemented this is by using a multi-VPC approach and placing our customers’ applications in separate VPCs. Not only does this essentially solve the “Coke vs. Pepsi” age-old debate around multi-tenancy, but it also now makes moving horizontally between systems that much more difficult.
Security is not something that you run as a single project when deploying the public cloud environment; it is an ongoing evolving process that I am not sure has an end. It involves a great deal of continuing education and monitoring because those of us on this side of the fence are constantly playing catch-up.
Our work is never done, and every new day is an adventure.
If you’re embarking on a new cloud project and looking for advice, check out Maplewave’s Cloud Consulting services and reach out to our team.
Until next time, stay safe and stay connected!
