he outbreak of the coronavirus pandemic caused a tectonic shift in the way businesses operate. Employees had to work from home, e-commerce saw rapid growth, and digital currency took the place of physical money. Businesses rapidly moved from physical to digital platforms. Due to the closure of offices, only IT engineers were allowed to enter data centers that hosted bare-metal servers. The digital transition was challenging for most organizations, but those who had migrated to cloud systems were better equipped.
The deployment of products on the cloud is not an unknown phenomenon. Companies use the cloud at every stage, from startups to Fortune 500. However, with the increasing use of digital technology after the pandemic and a relatively low awareness of cloud security, several large companies have fallen prey to cyberattacks. IT infrastructure security has always been critical for big firms, and even a small compromise can cost companies a fortune.
In the last three years, the cloud has attained great maturity in providing easy functionality to secure the systems, and the cyber attacks have increased significantly. Wait, hold on - did I just contradict myself? Confused?? Let me clear this very scenario. Let’s get some more real-time (and non-technological) examples to clarify what I want to convey. In recent years, roadways and automobiles have improved, but accidents have also increased. Got it? Alright, one more. But this one is the last. Due to COVID-19, people are more health-conscious, but junk food still causes serious health issues. By now, you must have got my inferences. If yes, please pat your back. We might have good roadways and automobiles, but if people don’t drive properly, there’s gonna be accidents. We might be aware of the benefits of healthy eating and regular exercise, but if we keep feeding our bellies with bad fat and wrong carbs, the body is going to suffer. Similarly, even if the cloud service providers offer us secure options, it's useless if we don't take proactive steps.
In this blog post, we will take a look at the most important configurations that we need to do in the cloud no matter what the scale of infrastructure is. We will be taking Amazon Web Services (AWS) cloud as our cloud service provider of interest. Keep reading.
- Kill IAM Access and Secret keys and Use IAM Roles: The easier we get, the harder we suffer. Let me give an analogy. You are a part of the engineering team for an E-Commerce giant and you are supposed to write the email API. For sending the mail, you need credentials, right? Would you hard-code the username and password for your SMTP server? A big fat NO. Well, these are the IAM Access and Secret keys. The most insecure way of developing systems is to use IAM access and secret keys in the product code to access different AWS resources. The best way to use AWS resources is to use IAM roles with restricted permissions to access AWS resources and get rid of IAM access and secret keys altogether.
- Must enable MFA on IAM users: You love me and are giving me $1 million and asking for my bank account number. I told you verbally just once and only once. Would you not ask me again to confirm the account number just to ensure that the amount is transferred to the right person? Well, that’s multi-factor authentication (MFA) for you in the AWS cloud. With MFA enabled, solely entering the username and password for login to the AWS account won’t let you into the kingdom. You need to provide the six-digit unique code, also known as time-based one-time passwords (TOTP) with a lifespan of 30 seconds only. Unless you enter this TOTP, you won’t be able to log in. MFA could be virtual or physical based on your requirements.
- Principle of least privilege: I am a guest at your home but I ain’t your family member. I am very hopeful and happy that you are going to give me keys to your locker that has $10 million inside it, right? What, no? You won’t give me? Well, then why give the wide range of permissions in IAM/bucket policies that have a bigger blast radius, eventually proving fatal to your infrastructure? We should give only those permissions that serve the purpose of our product applications - neither more nor less. This is the principle of the least privileges. For example, if your application needs to write the assets to S3 buckets, please don’t give S3:* or don’t attach AWS managed AmazonS3FullAccess. Nada. Just give the required permission of PutObject in the allow block and EXPLICITLY DENY s3:DeleteBucket in the deny block of IAM policy.
- Hardening S3 Bucket Policy: Bucket policies determine access levels for principals within and across accounts. Often, engineers tend to focus on adding policies to IAM roles and overlook securing the buckets. However, it is crucial to secure the buckets as they hold important assets, data, and files related to your product. IAM roles provide resource-level permissions, while bucket policies handle bucket-level permissions. By default, Amazon S3 blocks public access to your account and buckets.
- Make WAF your best gatekeeper: If you've ever watched Suits, you'll understand this example. Imagine you're Harvey Specter, you have a beautiful office, and you collect celebrity-signed basketballs. But then, jealous Travis Tanner comes by, and he convinces Donna, your secretary, that you're expecting him. Donna lets Travis into your office, even though you didn't want him there. This situation is similar to what can happen if you don't set up your AWS Web Application Firewall (WAF) rules correctly. It's easy for unwanted traffic to enter your infrastructure and cause trouble. To prevent this, it's essential for an infrastructure engineer to ensure that they set proper rules on WAF, allowing or rejecting certain IPs, ports, ranges, etc. It's also important to prioritize these rules to keep your infrastructure secure.
- Configure Security Group Rules wisely: When configuring Security group rules, infrastructure engineers should not focus on immediate resolutions or activities. They must instead prioritize long-term goals and understand that allowing an entire IP address for a particular port, whether for ingress or egress, can make the security group layer of the infrastructure vulnerable to attack. It is not advisable to allow outbound access for all ports to a particular IP address. Hence, infrastructure engineers should conduct a comprehensive analysis and possess a futuristic vision while writing rules for egress or ingress to ensure better security for the infrastructure.
The aforementioned considerations are just the tip of the iceberg and there are many more such aspects to securing the infrastructure over the AWS cloud like implementing SOC compliance on AWS, configuring FEDRAMP compatible settings, leveraging AWS Inspector and AWS GuardDuty, and much more to improve the security posture of your cloud infrastructure.
