Cloud Security Fundamentals

The Shared Responsibility Model — What the Provider Secures vs. What You Secure

The shared responsibility model is the single most important cloud security concept. Misunderstanding it is the root cause of most cloud data breaches.

Who Secures What

Key insight for analysts: When investigating cloud incidents, look for IAM misconfigurations first. The Cloud Security Alliance reports that IAM misconfigurations are the leading cause of cloud data breaches — not provider vulnerabilities.

Common Shared Responsibility Mistakes

IAM — Users vs. Roles vs. Policies (and Why the Difference Matters)

IAM is the control plane for who can do what in a cloud environment. Misconfigurations here account for the majority of cloud security incidents.

IAM Components

Users

A user is a long-term identity tied to a person. Users have static credentials (password, access keys).

Detection priority: Access keys used outside of automation. Every human user should use single sign-on (SSO) — not static access keys.

Roles

A role is an identity that can be assumed temporarily. Roles have no static credentials — they issue temporary credentials via AWS STS, Azure Managed Identity, or GCP Service Accounts.

Why roles matter for security:

• No static access keys — temporary credentials expire (default 1 hour for AWS STS)
• Least privilege is easier — assign roles to services, not users
• Cross-account access — trust relationships between accounts (AWS, Azure, GCP)

Policies

A policy is a document that defines what an identity can do. Understanding how policies work is essential for investigation.

AWS IAM Policy structure:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::important-bucket/*",
      "Condition": {
        "IpAddress": {"aws:SourceIp": "10.0.0.0/8"}
      }
    }
  ]
}

Azure RBAC Role structure:

{
  "Name": "Custom Storage Blob Data Reader",
  "IsCustom": true,
  "Actions": ["Microsoft.Storage/storageAccounts/blobServices/containers/read"],
  "NotActions": [],
  "AssignableScopes": ["/subscriptions/{sub-id}"]
}

GCP IAM Policy structure:

{
  "bindings": [
    {
      "role": "roles/storage.objectViewer",
      "members": ["user:alice@example.com", "serviceAccount:sa@project.iam.gserviceaccount.com"]
    }
  ]
}

The Common Misconfiguration Pattern

Overly permissive policy: "Action": "*" and "Resource": "*" on a user or role = unfettered access to everything.

SPL query (via CloudTrail) — detect overly permissive policies being attached:

index=cloudtrail eventName="AttachUserPolicy" OR eventName="AttachRolePolicy" OR eventName="PutUserPolicy" OR eventName="PutRolePolicy"
| search requestParameters.policyArn="*:*:*:*:*"
| eval alert = "HIGH — Policy " . requestParameters.policyName . " attached to " . requestParameters.userName . " — verify least privilege"
| table _time, userIdentity.arn, requestParameters.policyArn, sourceIPAddress, alert
| sort - _time

CloudTrail, CloudWatch, and Azure Monitor — The Log Sources

AWS CloudTrail

CloudTrail records every API call made to AWS services — who, what, when, and from where.

Event types:

Key CloudTrail fields for investigation:

Common CloudTrail detection queries:

# Failed API calls — attacker probing permissions
index=cloudtrail errorCode="AccessDenied" OR errorCode="UnauthorizedOperation"
| stats count by userIdentity.arn, sourceIPAddress, eventName, errorCode
| sort - count

# Root account activity — should be rare
index=cloudtrail userIdentity.type="Root"
| stats count by sourceIPAddress, eventName, userAgent
| sort - _time

# Console logins from unusual geolocations
index=cloudtrail eventName="ConsoleLogin"
| iplocation sourceIPAddress
| where Country != "US" AND Country != "CA" (adjust for your org)
| stats count by userIdentity.arn, sourceIPAddress, Country

Azure Activity Log (Azure Monitor)

Azure’s equivalent of CloudTrail — records control-plane operations on Azure resources.

Key event types:

Key fields:

Sample KQL query — detect NSG rule modifications:

AzureActivity
| where OperationNameValue == "MICROSOFT.NETWORK/NETWORKSECURITYGROUPS/SECURITYRULES/WRITE"
| project TimeGenerated, Caller, CallerIpAddress, Resource, OperationName, Status
| order by TimeGenerated desc

GCP Cloud Audit Logs

GCP’s Cloud Audit Logs capture administrative and data-access events.

Log types:

Key fields:

VPC Flow Logs — The Cloud Network Log

VPC Flow Logs capture network traffic metadata in cloud environments. They are the cloud equivalent of firewall logs.

What They Capture

Analyst Use Cases

• Beaconing detection: Consistent outbound connections to a single IP at regular intervals
• Data exfiltration: High outbound bytes to a destination that is not a known cloud service
• Lateral movement: Unexpected internal connections between subnets or accounts
• Scanning / recon: REJECT records from a single source targeting many ports or IPs

VPC Flow Logs are sampled by default (1 in 10,000 packets on AWS). For full visibility, enable 1:1 packet sampling or use a network tap solution.

Cross-Cloud Flow Log Setup

S3 Logging — Server Access Logs vs. CloudTrail

S3 is the most common source of cloud data breaches. Two log sources exist:

S3 Server Access Logs

Granular logs for every request to S3, logged by the S3 data plane.

Enabled: Per-bucket destination in the same account (or another account).

Captures:

• Bucket Owner, Bucket, Time, Remote IP, Requester ARN
• Request ID, Operation (REST.GET.OBJECT, REST.PUT.OBJECT)
• Key (object key), Request-URI, HTTP Status, Error Code
• Bytes Sent, Object Size, Total Time, Turn-Around Time
• Referrer, User-Agent, Version ID

S3 CloudTrail Data Events

Less granular than server access logs but integrated into CloudTrail and easier to search across accounts.

Enabled: Per-bucket in CloudTrail trail.

Captures:

• Standard CloudTrail fields + S3-specific: bucketName, objectKey, eventName
• s3: prefix events: GetObject, PutObject, DeleteObject, ListBucket

When to Use Which

SPL query — detect public S3 object access (Server Access Logs):

index=s3_access
| search requester="Anonymous" (public access)
| stats count by bucket, key, remote_ip, operation
| where count > 1
| eval alert = "MEDIUM — Public S3 access to " . bucket . "/" . key . " — check if public access is intentional"
| table _time, bucket, key, remote_ip, operation, count, alert

The Cloud Incident Investigation Workflow

Phase 1: Identify the Entry Point

Phase 2: Determine the Blast Radius

Phase 3: Containment

Related

• Cloud Threats — Credential Theft, IMDS Abuse, Hijacking, Privilege Escalation — detection and response for T1525, T1552, T1613 techniques
• Cloud Incident Response — detection and response for T1525, T1526, T1078, T1530 techniques
• Container and Kubernetes Threats — detection and response for T1611, T1525, T1574.002 techniques
• Linux Security Fundamentals — detection and response for T1059, T1546, T1548 techniques
• Elastic Security — detection and response for T1654 techniques

Sources

• AWS Shared Responsibility Model
• Azure Shared Responsibility Model
• GCP Shared Responsibility Model
• AWS CloudTrail Documentation
• Azure Monitor Activity Log
• GCP Cloud Audit Logs