Lesson 28: Cloud Security — Securing AWS, Azure, and GCP Environments

What You Will Learn in This Lesson

• How the Shared Responsibility Model works across AWS, Azure, and GCP — and where most organizations get it wrong
• The top cloud misconfigurations that lead to breaches and how to detect them
• Practical IAM hardening techniques for each major cloud provider
• How to align your cloud security posture with SAMA CSCC and NCA ECC requirements

The Shared Responsibility Model — Your Starting Point

Before you touch a single security setting, you need to internalize one concept: the cloud provider secures the infrastructure of the cloud, but you secure everything you put in the cloud. AWS calls it the Shared Responsibility Model. Azure calls it Shared Responsibility. GCP frames it as Shared Fate. The naming differs, but the principle is identical — if you misconfigure an S3 bucket, leave a storage account publicly accessible, or grant overly permissive IAM roles, that breach is on you, not the provider.

Here is how the split works in practice. The provider handles physical data center security, hypervisor patching, and network backbone integrity. You handle operating system patches (for IaaS), application-level configurations, identity and access management, data encryption choices, and network security group rules. The gray area — managed services like RDS, Azure SQL, or Cloud SQL — shifts more responsibility to the provider, but you still own access controls and encryption key management.

The Five Most Dangerous Cloud Misconfigurations

Every major cloud breach in recent years traces back to a handful of recurring mistakes. These are not sophisticated zero-day exploits — they are configuration errors that attackers find using automated scanners in minutes.

1. Publicly Exposed Storage. An S3 bucket with "Block Public Access" disabled, an Azure Blob container set to "Container" access level, or a GCP Cloud Storage bucket with allUsers permission. This is how customer databases, backup files, and internal documents end up on the internet.

2. Overly Permissive IAM Policies. Attaching AdministratorAccess in AWS, granting the Owner role in GCP, or assigning Contributor at the subscription level in Azure to service accounts that only need read access to a single resource. The principle of least privilege is simple in theory, painful in practice, and non-negotiable.

3. Disabled Logging and Monitoring. AWS CloudTrail turned off or logging to a bucket nobody monitors. Azure Activity Logs not routed to a SIEM. GCP Cloud Audit Logs left at the default level without Data Access logs enabled. Without logs, you are blind to both active attacks and compliance audits.

4. Unencrypted Data at Rest. While all three providers offer default encryption, many organizations skip customer-managed keys (CMKs), meaning they cannot enforce key rotation policies, cannot revoke access through key deletion, and cannot meet regulatory requirements that mandate key custody.

5. Exposed Management Ports. Security groups or firewall rules allowing SSH (port 22) or RDP (port 3389) from 0.0.0.0/0. This is the cloud equivalent of leaving your front door wide open with a sign that says "come in."

Real-World Example: A Saudi fintech company migrated its payment processing platform to AWS without adjusting the default security group rules. An external penetration test revealed that their staging database on RDS was accessible from any IP address on port 3306, and CloudTrail had been disabled in two regions to "reduce costs." The remediation required an emergency change window and a full incident report to SAMA — all for configurations that would have taken 30 minutes to set correctly during initial deployment.

Practical IAM Hardening — Provider by Provider

Identity is the new perimeter in cloud environments. If an attacker compromises a highly privileged identity, network-level controls become irrelevant. Here are concrete hardening steps for each provider.

AWS IAM Hardening

# Enforce MFA on all IAM users with console access
aws iam create-policy --policy-name EnforceMFA --policy-document '{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyAllExceptMFA",
      "Effect": "Deny",
      "NotAction": ["iam:CreateVirtualMFADevice","iam:EnableMFADevice","iam:GetUser","iam:ListMFADevices"],
      "Resource": "*",
      "Condition": {"BoolIfExists": {"aws:MultiFactorAuthPresent": "false"}}
    }
  ]
}'

# Find unused IAM access keys older than 90 days
aws iam generate-credential-report
aws iam get-credential-report --query 'Content' --output text | base64 -d | \
  awk -F',' '$5=="true" && $6!="N/A"' | \
  while IFS=',' read -r user arn created pw_enabled pw_last_used key1_active key1_last_rotated rest; do
    echo "Review: $user — Key last rotated: $key1_last_rotated"
  done

# List all policies granting AdministratorAccess
aws iam list-entities-for-policy \
  --policy-arn arn:aws:iam::aws:policy/AdministratorAccess

Azure IAM Hardening

# List all Owner role assignments at subscription level
az role assignment list --role "Owner" --scope "/subscriptions/{sub-id}" \
  --output table

# Enable Conditional Access — require MFA for all admin roles
# (Done via Azure AD Portal > Security > Conditional Access > New Policy)
# Key settings:
#   Users: Directory roles = Global Administrator, Security Administrator
#   Conditions: All cloud apps
#   Grant: Require multi-factor authentication

# Check for service principals with excessive permissions
az ad sp list --all --query "[].{Name:displayName, AppId:appId}" -o table

GCP IAM Hardening

# Audit all IAM bindings at the project level
gcloud projects get-iam-policy PROJECT_ID --format=json | \
  jq '.bindings[] | select(.role=="roles/owner" or .role=="roles/editor")'

# List service account keys older than 90 days
gcloud iam service-accounts keys list \
  --iam-account=SA_EMAIL \
  --format="table(name, validAfterTime, validBeforeTime)"

# Enable Organization Policy to restrict service account key creation
gcloud resource-manager org-policies enable-enforce \
  iam.disableServiceAccountKeyCreation \
  --organization=ORG_ID

Cloud Security Posture Management (CSPM)

Manual checks do not scale. Once you operate across multiple accounts, subscriptions, or projects, you need automated posture management. Each provider offers a native tool, and there are strong third-party options as well.

AWS Security Hub aggregates findings from GuardDuty, Inspector, Macie, and Firewall Manager into a single dashboard. Enable the CIS AWS Foundations Benchmark standard — it maps directly to many SAMA CSCC controls. Azure Defender for Cloud (formerly Azure Security Center) provides a Secure Score and regulatory compliance dashboard that includes CIS, ISO 27001, and PCI-DSS mappings out of the box. GCP Security Command Center (SCC) Premium tier offers vulnerability scanning, threat detection, and compliance monitoring with built-in CIS benchmarks.

For multi-cloud environments — which are increasingly common in Saudi financial institutions running core banking on one provider and analytics on another — tools like Prisma Cloud, Wiz, or Orca Security provide a unified view. The key is not which tool you choose, but that you have continuous, automated scanning rather than quarterly manual reviews.

Network Security in the Cloud

Cloud networking is not traditional networking with different names. Concepts like VPCs, subnets, security groups, NACLs, and route tables exist across all three providers, but the default behaviors differ significantly.

In AWS, security groups are stateful (return traffic is automatically allowed) while NACLs are stateless. In Azure, Network Security Groups (NSGs) are stateful and can be applied at both the subnet and NIC level. In GCP, firewall rules are applied at the VPC level and are stateful by default. A critical best practice across all three: segment your workloads into separate VPCs/VNets, use private subnets for databases and internal services, and route egress traffic through a centralized inspection point — whether that is AWS Network Firewall, Azure Firewall, or GCP Cloud NGFW.

# AWS: Check for security groups allowing ingress from 0.0.0.0/0
aws ec2 describe-security-groups \
  --filters "Name=ip-permission.cidr,Values=0.0.0.0/0" \
  --query "SecurityGroups[*].{ID:GroupId,Name:GroupName,Ports:IpPermissions[?contains(IpRanges[].CidrIp,'0.0.0.0/0')].{From:FromPort,To:ToPort}}" \
  --output table

Alignment with Saudi Regulations

SAMA's Cyber Security Framework (CSCC) does not prohibit cloud adoption, but it demands that financial institutions maintain full visibility, control, and auditability of their cloud environments. Specifically, Domain 3 (Cyber Security Operations and Technology) requires continuous monitoring capabilities — which maps directly to enabling CloudTrail, Azure Monitor, and GCP Cloud Logging with centralized SIEM integration. NCA's Essential Cybersecurity Controls (ECC 2-2024) reinforce this with explicit requirements around data residency — critical because Saudi regulators expect customer data for financial institutions to reside within the Kingdom or in approved jurisdictions. AWS has a region in the Middle East (Bahrain), Azure has UAE and Qatar regions, and GCP operates in Doha. Verify that your workloads are pinned to compliant regions and that cross-region replication does not accidentally route data to unapproved locations. The PDPL adds another layer: cloud service agreements must clearly define data processing roles, breach notification responsibilities, and data subject rights handling.

Common Mistakes to Avoid

• Treating cloud security as an afterthought. Security configurations must be part of Infrastructure-as-Code (Terraform, CloudFormation, Bicep) from day one. Retrofitting security onto a running environment is exponentially harder and riskier than building it in from the start.
• Using root or owner accounts for daily operations. The root account in AWS, Global Administrator in Azure, and Organization Admin in GCP should be locked behind MFA hardware tokens and used only for break-glass scenarios. Create dedicated admin accounts with time-limited elevated access instead.
• Ignoring cloud-specific attack vectors. Server-Side Request Forgery (SSRF) against the instance metadata service (IMDS) is a cloud-native attack that does not exist in on-premises environments. Enforce IMDSv2 on all EC2 instances, restrict metadata access in GCP, and use managed identities instead of embedding credentials in Azure VMs.

Lesson Summary

• The Shared Responsibility Model means cloud providers secure the infrastructure, but you own the security of your configurations, identities, data, and applications — misunderstanding this boundary is the root cause of most cloud breaches.
• The top cloud security risks are not sophisticated attacks but basic misconfigurations: public storage, overprivileged IAM, disabled logging, unmanaged encryption keys, and open management ports. Automated CSPM tools catch these continuously.
• Saudi regulations (SAMA CSCC, NCA ECC, PDPL) do not block cloud adoption but require data residency compliance, continuous monitoring, and clear contractual responsibilities with cloud providers — plan for these from the architecture phase, not after deployment.

Next Lesson

In the next lesson, we will cover: API Security — Vulnerabilities and Protection — you will learn how to identify and mitigate the most common API security flaws, implement authentication and rate limiting, and test your APIs against the OWASP API Security Top 10.

Ready to apply these concepts in your organization? Contact Fyntralink for a complimentary SAMA Cyber Maturity Assessment.