Cloud Infra Security: Configs That Don't Break

The most surprising truth about cloud infrastructure security is that the shared responsibility model often leads to a false sense of security, making organizations believe their cloud provider handles more than they actually do.

Let’s look at how this plays out in practice. Imagine a typical web application deployed on AWS.

{
  "Resources": [
    {
      "Type": "AWS::EC2::Instance",
      "Properties": {
        "ImageId": "ami-0abcdef1234567890",
        "InstanceType": "t3.micro",
        "NetworkInterfaces": [
          {
            "DeviceIndex": 0,
            "SubnetId": "subnet-0123456789abcdef0",
            "Groups": [
              "sg-0abcdef1234567890"
            ]
          }
        ]
      }
    },
    {
      "Type": "AWS::IAM::Role",
      "Properties": {
        "AssumeRolePolicyDocument": {
          "Version": "2012-10-17",
          "Statement": [
            {
              "Effect": "Allow",
              "Principal": {
                "Service": "ec2.amazonaws.com"
              },
              "Action": "sts:AssumeRole"
            }
          ]
        },
        "Policies": [
          {
            "PolicyName": "S3ReadOnlyAccess",
            "PolicyDocument": {
              "Version": "2012-10-17",
              "Statement": [
                {
                  "Effect": "Allow",
                  "Action": "s3:GetObject",
                  "Resource": "arn:aws:s3:::my-private-bucket/*"
                }
              ]
            }
          }
        ]
      }
    },
    {
      "Type": "AWS::S3::Bucket",
      "Properties": {
        "BucketName": "my-private-bucket",
        "PublicAccessBlockConfiguration": {
          "BlockPublicAcls": true,
          "BlockPublicPolicy": true,
          "IgnorePublicAcls": true,
          "RestrictPublicBuckets": true
        }
      }
    }
  ]
}

This snippet shows an EC2 instance with a specific security group (sg-0abcdef1234567890) and an IAM role that grants read-only access to an S3 bucket named my-private-bucket. The bucket itself has public access blocked.

The problem this solves is the fundamental need to secure digital assets and operations in a distributed, scalable environment. Cloud providers offer a massive, complex infrastructure, and security is a joint effort. AWS, GCP, and Azure all provide a suite of security tools and services, but how you configure and use them is entirely up to you.

Internally, these controls operate at different layers. AWS Security Groups and Network ACLs are stateful and stateless firewalls for your VPC, controlling traffic at the instance and subnet level, respectively. IAM (Identity and Access Management) governs who (users, services) can do what (actions) to which resources. S3 bucket policies and IAM policies interact to define access to object storage. Azure’s Network Security Groups (NSGs) and Azure Policy serve similar functions. GCP’s Firewall Rules and IAM are its counterparts.

The key levers you control are:

• Network Access: Who can reach your instances and services. This involves configuring Security Groups, NSGs, and firewall rules to allow only necessary inbound and outbound traffic. For example, allowing SSH (port 22) and HTTPS (port 443) from specific IP ranges, but denying all other inbound traffic.
• Identity and Permissions: What actions authenticated users and services can perform. This is managed through IAM roles, users, and policies. The principle of least privilege is paramount: grant only the minimum permissions required for a task. A common mistake is giving overly broad permissions like s3:* instead of s3:GetObject and s3:PutObject to specific buckets.
• Data Protection: How your data is secured at rest and in transit. This includes enabling encryption for storage services (like S3, EBS, Azure Blob Storage, GCP Cloud Storage) and using TLS/SSL for data in transit.
• Configuration Management: Ensuring your cloud resources are configured securely and remain so. Services like AWS Config, Azure Policy, and GCP Security Command Center help detect misconfigurations.

Here’s a crucial detail that trips many people up: the default for many cloud services is not the most secure. For instance, if you create an S3 bucket and don’t explicitly enable encryption or block public access, it might be accessible to the internet by default, or at least accessible to any authenticated AWS user. This means a simple aws s3 ls from an attacker’s compromised AWS credentials could list your bucket contents if permissions are too loose. The PublicAccessBlockConfiguration in the example above is a critical, explicit step to prevent this. Likewise, leaving default security group rules open to 0.0.0.0/0 for sensitive ports is a direct invitation to trouble.

The next concept you’ll encounter is automated compliance and drift detection.