Originally published at: Understanding Best Practices When Building in the Cloud - Skycrafters
Building confidently in the cloud can be challenging. Often, we use a technology and find out later that we could have been using it better. Becoming an expert at something can take years. In becoming an expert, you learn how not to do things, how to do them better, and how to do them the best way. What if there is a shortcut or guide to the best way? Well, there are: best practices. Subject matter experts create their best practices to give a guide for how to achieve that goal of best. Here is a simplified example for getting to the best practice in note-taking.
You go to a meeting, listen to everything that is going on, and you think you understand it. You are all set, and you think “I got this!” Later you find out that you missed some key things, and you don’t remember what was said in the meeting because you did not take notes.
For the next meeting, you learn from your earlier mistake and take notes so that you will remember the important things. However, you find out when referencing back to them, you paraphrased too much, and you don’t understand the notes.
You have practiced how to take notes properly so that when you go back to look over them you remember everything from the meeting. In this scenario of note-taking, you finally figured out the best practices for retaining information at your meetings with your notes.
So why best practices?
When you don’t use best practices, you are not accessing the most effective use of tools or services. These best practices are defined by industry experts who know the tool best, and how to get the most success with the tool. Examples of not using this methodology lead to headlines such as 540M Facebook member records exposed by an unsecure AWS S3 bucket and Misconfigured servers contributed to more than 200 cloud breaches. You also might land yourself on this top 10 list: The biggest cloud breaches of 2019 and how to avoid them for 2020.
You are probably thinking, no way people stop using Facebook because of these breaches, and you are right! But do most organizations have that luxury? For example, if that were your bank, would you still use them? Probably not (Wells Fargo 2017, need we say more 😅).
Using best practices with the tools you are using, as well as building in the cloud on AWS, Azure, GCP, Kubernetes, containers, and applications will set you up to be the most successful with your tools of choice. So, what outcomes can you expect from using best practices? More security as you are building, more proficiency with the tools and services you are using, better structure, faster environment, a reliable system that will withstand outages, and a more cost-effective solution.
Examples of Best Practices
Every product or service being used has a bad, ok, good, and best way to be used. There is always more than one answer and many different use cases or scenarios. There may not be a specific right answer but there is a worst and best.
Commenting in Code
For instance, when learning how to write code, no matter which language, the first thing you learn is how to comment in code; not commenting can be looked at as bad. Or you can do comments and then find out later that you really don’t understand what you wrote and probably nobody else does either. At least you are writing comments though. Then the best would be folding your comments or writing comments so that you and anyone else can understand what the comments are and what the code is meant to accomplish.
Not using tags or labels with your resources in the cloud is not the best way of building. When using tags, it can let you know who owns the resources and what project it is a part of, enabling you to know the purpose of each resource. Also, tags help you to find resources and they are often used by third-party tools for organization purposes and exceptions. So having a set tagging process such as a resource owner and project association, will be the best way to leverage tags.
Allowing everyone access to your environment or resources is a bad practice. You can add an access control list, which is defiantly better. To achieve a best practice, you should use multiple layers, such as an access control list, security groups, and access control policies to add access control layers of protection.
Encryption is a security best practice. This will protect your data from being publicly readable at rest or in transit.
Take this example as a way to think about encryption. You are delivering an important message from Barbados to Texas. So that only you and your recipient know what is in the message, you write it in a special code that only the two of you understand. To further protect your special message, you put it in a coded container and only your friend has the key to get in. This way both your message and the container are protected. This is like using encryption at rest and in transit. Doing nothing is bad. Doing one or the other is better. Two levels of protection are the best practice.
As mentioned earlier there are many different use cases or scenarios. Designing can take a bit of strategic planning and you have to do a bit of a balancing act to find the perfect fit for your goals. At times, for greater performance, you have to use a less restrictive security posture, or you have to spend a little more money to achieve the desired goal. These three different use case diagrams will show some common uses, structures and highlight the best practices in these scenarios.
Use Case 1: Basic Web App
For example, AWS has what they call the AWS Well-Architected Framework which is broken up into 5 pillars: Reliability, Cost Optimization, Performance Efficiency, Operational Excellence, and Security.
In this diagram, you have a basic web application. The diagram is broken down based on the 5 pillars. The diagram is AWS, but it translates to any cloud platform.
Here you can see there are 2 availability zones with a database in each zone as well as EC2s (or virtual machines) in each zone. This creates reliability by having a backup of computing power as well as a secondary database. Should one zone fail, then the other can take over.
You have auto-scaling, which means it will spin up and down EC2 compute power as needed. So, in this diagram, you have 2 EC2s all the time but if you meet capacity and need back up, then that is when the auto-scaling will kick in and provide more EC2s as you need them. This helps to stop downtime, lagging, and not enough power needed to perform the tasks.
In this diagram, the auto-scaling that I mentioned will not only scale up but will scale down as needed. This can be used to save money as well as making sure there aren’t any EC2s that are not being utilized and still costing money. So, if you aren’t using the EC2 the auto-scaling will get rid of it and then bring it back when needed.
The Elastic Load Balancers are distributing an even amount of capacity across the EC2 instances. To decrease the retrieval time in getting content from the S3 bucket (storage) you would use CloudFront.
Security is obviously a really big part of using best practices. In most architectures, you have storage like the S3 Bucket in this diagram. One of the most common configurations found in storage is that it is publicly open to everyone. This is the worst practice but often needed. So, what can you do to safeguard your storage?
There are a few things that you can do to get that from bad to better. One thing you could do in this diagram is to allow CloudFront to pull and write the data instead of the file storage, so the file storage can still be private. Another option, a third-party tool scanning the files that are being uploaded. This helps you to find a way to have something better than bad when you can’t accomplish your best. Doing one or the other is a good practice. If it’s possible to do both, that would be a best practice.
Are you preventing unwanted access in your network security? This is when the layers of access control come into play. Are you controlling the ports where traffic is allowed to flow in and out? Another layer of protection would be using third-party intrusion prevention or detection system blocking malicious traffic.
Do you have the protection need for the EC2s in the diagram? Is access to the EC2 being restricted to those who need it? This can be accomplished by limiting your team with access to the security groups. Are you using a third-party tool to provide anti-malware, ids/ips, firewall, log inspection, and an application control?
Use Case 2: Serverless Application
This use case is here to show the serverless part that is not in that other diagram. This continues the conversation of the security best practices.
In this diagram, you have a serverless application for a purpose of voting. For example, like voting on Dancing with the Stars you message in your vote, and they save the tallies.
With applications built using services such as Lambda, there is an OAWAP top 10 for serverless. This would include things like injection, broken authentication, sensitive data exposure, and so on. What best practices are you going to use when it comes to vulnerable serverless applications?
There are third-party tools that provide application security giving some sort of blocking for the OWASP 10. You can also ensure that as you are building, you use something like least privilege. This grants access and permissions only for what is needed and nothing more.
Use Case 3: Container Security
In this use case, you will learn about containers that were not pictured in the first two diagrams. Common problems found with container usage: images created inaccurately, Docker files reviling important data, unreliable resource usage, and outdated images.
This diagram shows a basic container build using open-source code from GitHub. Using best practices with containers would be to avoid the list of those common problems as well as other things such as use CI/CD testing and deployment and keeping your images small.
It isn’t always easy to avoid some of those problems. For example, unknowingly using someone’s carelessly built container image you found on GitHub or other open-source code. To avoid this happening, you can use a third-party tool to help with evaluations of these problems. There are third-party tools that can do pre-runtime scans, integrate into your pipeline, and provide container security during runtime. This will assist in covering you in those top listed problems.
Shifting Best Practices Left
Being able to shift best practices left before deploying anything will allow you to catch a lot of the problems we have discussed while it is still code. So, scan your code yourself or have a third-party tool that does this automatically for you.
If the code is infrastructure-as-code using the CloudFormation template, scan to see that it is following best practices from the AWS Well-Architected Framework with multi-availability zones, backup EC2s and databases, closed buckets, layered access control, and encryption of data.
You now have a lot of information about best practices. What should you do next? Start searching for best practices of the tools that you use. I have shared a few links throughout this article to give you an idea of what you should be looking for from those companies.
We covered a lot here mostly around building in the cloud, but what about with other tools or products? Keep an eye out for a follow-up article from me that will address that topic.
I’d love to hear your reactions to this article in the comments. What do you think about best practices? What experiences do you have with them? What else would you like to see covered on this topic? Let’s discuss this in the forum.