04 — Cloud Security Reviews

Cloud security reviews are now a core responsibility for many Senior Security Consultants.

Modern organisations rarely operate a single isolated cloud environment.

You may encounter:

• AWS
• Microsoft Azure
• Google Cloud
• Kubernetes
• SaaS platforms
• Hybrid cloud
• Multi-cloud environments
• Cloud-native applications
• CI/CD pipelines
• Infrastructure as Code
• Central identity platforms
• Central security operations

A professional cloud security review must therefore go far beyond checking whether a few security services are enabled.

The consultant must understand:

How the cloud environment is governed, how identities operate, how workloads communicate, where sensitive data exists, how security controls are enforced, how threats are detected, and how compromise could spread across the environment.

Module Mission

Your mission is to develop a repeatable cloud security review methodology that moves from:

Business Context
       ↓
Cloud Landscape
       ↓
Governance
       ↓
Identity
       ↓
Network
       ↓
Workloads
       ↓
Data
       ↓
Logging & Detection
       ↓
Resilience
       ↓
Attack Paths
       ↓
Cloud Risk
       ↓
Security Roadmap

By the end of this module, you should be able to review a cloud environment systematically and communicate both technical weaknesses and enterprise-level cloud risk.

1. What Is a Cloud Security Review?

A cloud security review is a structured evaluation of how securely an organisation:

• Designs cloud environments

• Governs cloud usage

• Manages identities

• Controls network access

• Protects workloads

• Secures data

• Monitors activity

• Detects threats

• Responds to incidents

• Maintains resilience

• Enforces compliance

The objective is not:

“Find every misconfiguration.”

The objective is:

Determine whether cloud risk is being appropriately managed.

2. Why Cloud Reviews Are Different

Traditional infrastructure often has relatively clear boundaries.

For example:

Internet
   ↓
Firewall
   ↓
DMZ
   ↓
Internal Network
   ↓
Servers

Cloud environments are more dynamic.

You may have:

Users
  ↓
Identity Provider
  ↓
Cloud Console

Applications
  ↓
Workload Identity
  ↓
Cloud APIs

CI/CD
  ↓
Deployment Role
  ↓
Production

SaaS
  ↓
API Integration
  ↓
Cloud Data

Security therefore depends heavily on:

• Identity

• API permissions

• Automation

• Cloud policy

• Service relationships

• Workload trust

Cloud security is not just network security hosted somewhere else.

3. Understand the Shared Responsibility Model

The first principle of cloud security is shared responsibility.

In general:

Cloud Provider
      ↓
Security OF the Cloud

Customer
      ↓
Security IN the Cloud

The provider typically protects areas such as:

• Physical facilities

• Core infrastructure

• Hardware

• Hypervisor

• Underlying networking

The customer remains responsible for many areas including:

• Identity

• Access

• Configuration

• Applications

• Data

• Logging

• Workload security

• Governance

The exact split varies by service type.

4. Responsibility Changes by Service Model

Consider:

IaaS
↓
Customer responsibility is larger

PaaS
↓
Provider manages more infrastructure

SaaS
↓
Provider manages most technology

But even with SaaS, the customer usually remains responsible for:

• Identity

• Access

• Data handling

• Configuration

• User governance

• Integration security

A consultant must understand where responsibility actually sits.

5. Start With Business Context

Before reviewing cloud controls, understand why the cloud environment exists.

Ask:

• What workloads run here?

• Which workloads are business critical?

• What data is processed?

• Which regions are used?

• What regulatory requirements apply?

• What availability is required?

• Is this production?

• Who owns the platform?

• How quickly is cloud adoption growing?

Cloud risk cannot be assessed without context.

6. Build the Cloud Landscape

Start by mapping the environment.

For example:

Enterprise
│
├── AWS
│   ├── Production
│   ├── Development
│   └── Security
│
├── Azure
│   ├── Corporate Services
│   └── Data Platform
│
├── Google Cloud
│   └── Analytics
│
└── Kubernetes
    └── Application Platform

Also identify:

• SaaS services

• External integrations

• CI/CD platforms

• Identity providers

• Security platforms

7. Identify Cloud Ownership

Ask:

• Who owns AWS?

• Who owns Azure?

• Who owns Kubernetes?

• Who defines security standards?

• Who approves new accounts?

• Who monitors cloud security?

• Who responds to incidents?

Cloud security frequently suffers when responsibility is distributed but accountability is unclear.

8. Review Cloud Governance

Governance is the foundation of scalable cloud security.

Review:

• Account creation

• Subscription creation

• Project creation

• Organisational structure

• Naming standards

• Tagging

• Region restrictions

• Service restrictions

• Policy enforcement

• Security ownership

• Exception processes

Without governance, cloud security becomes inconsistent.

9. Review Organisational Structure

Cloud platforms usually support hierarchy.

For example:

Organisation
│
├── Security
├── Logging
├── Shared Services
├── Production
├── Development
└── Sandbox

Evaluate:

• Environment separation

• Business unit separation

• Security boundaries

• Policy inheritance

• Logging separation

A strong hierarchy reduces blast radius.

10. AWS Organisational Review

In AWS, review areas such as:

• AWS Organizations

• Organizational Units

• Service Control Policies

• Central logging

• Security accounts

• Shared services

• Cross-account access

• IAM Identity Center

Ask:

Can one AWS account operate outside required security guardrails?

11. Azure Organisational Review

In Azure, review:

• Management Groups

• Subscriptions

• Resource Groups

• Azure Policy

• Entra ID

• Role assignments

• Central monitoring

• Defender for Cloud

Evaluate whether governance is applied consistently across subscriptions.

12. Google Cloud Organisational Review

Review:

• Organization

• Folders

• Projects

• Organization Policies

• IAM

• Logging

• Security Command Center

Ask whether project-level autonomy bypasses enterprise security requirements.

13. Review Guardrails

A mature cloud platform should not rely only on human behaviour.

Instead of:

“Please do not create public storage.”

Prefer:

Cloud Policy
     ↓
Deployment Request
     ↓
Policy Evaluation
     ↓
Allowed / Blocked

Examples of guardrails include:

• AWS Service Control Policies

• Azure Policy

• Google Organization Policy

• Kubernetes admission policy

Guardrails help make insecure configurations harder to create.

14. Review Identity as the Primary Security Boundary

In cloud environments, identity is often more important than the traditional network perimeter.

Review:

Human Identity
      ↓
Authentication
      ↓
Federation
      ↓
Role
      ↓
Cloud Resource

And:

Workload
    ↓
Workload Identity
    ↓
Cloud API
    ↓
Resource

Compromise of identity can bypass many network controls.

15. Review Human Identity

Evaluate:

• Central federation

• SSO

• MFA

• Administrative roles

• Account lifecycle

• Dormant users

• External users

• Break-glass accounts

• Access reviews

Avoid cloud environments with unmanaged local user accounts wherever practical.

16. Review Root and Emergency Accounts

For high-privilege emergency identities:

• Are they protected with MFA?

• Are credentials securely stored?

• Is access monitored?

• Are they used only when necessary?

• Are procedures documented?

Emergency access should be controlled but still available when required.

17. Review Privileged Access

Look for:

• Permanent administrators

• Global administrators

• Owner roles

• Overly broad IAM policies

• Standing access

• Shared privileged accounts

Prefer:

Normal User
    ↓
Approved Elevation
    ↓
Temporary Privilege
    ↓
Administrative Task
    ↓
Privilege Removed

Just-in-Time access reduces risk.

18. Review Least Privilege

Cloud permissions can become extremely complex.

Ask:

• Which roles have wildcard permissions?

• Which users have administrator access?

• Which service accounts have broad permissions?

• Which permissions are unused?

• Are roles reusable beyond their intended purpose?

Examples of high-risk permissions include broad capabilities to:

• Create identities

• Modify IAM

• Assume roles

• Create keys

• Disable logging

• Modify networks

• Access secrets

19. Review Workload Identity

Applications should not depend on long-lived credentials where better options exist.

High-risk pattern:

Application
   ↓
Hardcoded Access Key
   ↓
Cloud API

Preferred pattern:

Application
   ↓
Managed Workload Identity
   ↓
Temporary Credentials
   ↓
Cloud API

Examples include:

• AWS IAM Roles

• Azure Managed Identities

• Google Service Accounts

• Kubernetes workload identities

20. Review Credential Exposure

Search for risks such as:

• Static access keys

• Long-lived API keys

• Secrets in code

• Credentials in CI/CD

• Credentials in configuration files

• Shared credentials

Understand both storage and rotation.

21. Review Network Architecture

Cloud networking still matters.

Map:

Internet
   ↓
Edge
   ↓
Public Tier
   ↓
Private Application Tier
   ↓
Data Tier

Review:

• Public exposure

• Segmentation

• Routing

• Firewalls

• Security groups

• Network ACLs

• Private endpoints

• Peering

• VPN

• Dedicated connectivity

22. Identify Publicly Exposed Resources

Create an inventory of public resources.

Examples:

• Load balancers

• Virtual machines

• Storage

• Databases

• APIs

• Kubernetes endpoints

• Management interfaces

For each resource ask:

Does this actually need to be public?

23. Review Firewall and Security Group Rules

Look for:

• 0.0.0.0/0

• ::/0

• Broad administrative access

• Unrestricted internal communication

• Unused rules

• Legacy rules

Do not assume every broad rule is critical.

Understand:

• Port

• Protocol

• Exposure

• Asset criticality

• Compensating controls

24. Review Segmentation

Assess separation between:

• Production and development

• Application and data

• Management and workloads

• Business units

• Sensitive and non-sensitive systems

Ask:

If one workload is compromised, what can it reach?

25. Review Private Connectivity

Where appropriate, sensitive services can use private connectivity rather than public endpoints.

Examples:

• Private service endpoints

• Private database access

• Private storage access

• Private management paths

This can reduce unnecessary exposure.

26. Review Egress Security

Inbound controls receive most attention.

Also review outbound access.

Ask:

• Can workloads access any internet destination?

• Are egress paths logged?

• Can malware communicate externally?

• Can data be exfiltrated directly?

Egress controls can reduce attack impact.

27. Review DNS Security

Cloud DNS is frequently overlooked.

Review:

• DNS ownership

• Hosted zones

• Logging

• Resolver configuration

• Private DNS

• Domain protection

DNS compromise can redirect legitimate traffic.

28. Review Compute Security

For virtual machines, assess:

• Image security

• Hardening

• Patching

• Administrative access

• EDR

• Logging

• Disk encryption

• Metadata service protection

• Instance identity

Cloud does not eliminate operating system security.

29. Review Metadata Service Security

Cloud metadata services can expose temporary credentials to workloads.

Attack scenario:

Application Vulnerability
       ↓
SSRF
       ↓
Metadata Service
       ↓
Workload Credentials
       ↓
Cloud API Access

Review protections against credential retrieval and excessive workload permissions.

30. Review Serverless Security

Serverless functions introduce different risks.

Review:

• Function permissions

• Event sources

• Secrets

• Environment variables

• Dependencies

• Logging

• Network access

• Trigger security

A small serverless function can still have highly privileged cloud access.

31. Review Container Security

Review:

• Image provenance

• Vulnerability scanning

• Registry security

• Runtime security

• Secrets

• Privileges

• Host access

• Logging

Container security should cover both build time and runtime.

32. Review Kubernetes Security

For Kubernetes environments, assess:

Cluster Governance
      ↓
API Access
      ↓
RBAC
      ↓
Namespaces
      ↓
NetworkPolicy
      ↓
Workload Security
      ↓
Secrets
      ↓
Logging

Also review cloud integration.

A Kubernetes service account may provide access to cloud APIs.

33. Review Kubernetes RBAC

Look for:

• cluster-admin

• Broad role bindings

• Wildcards

• Excessive service account privileges

• Shared service accounts

Ask:

If this pod is compromised, what Kubernetes permissions are available?

34. Review Kubernetes Network Segmentation

Without appropriate network controls, pods may communicate broadly.

Assess:

• Namespace boundaries

• NetworkPolicies

• East-west communication

• Control-plane access

• External access

Do not assume namespaces provide strong network isolation by themselves.

35. Review Kubernetes Secrets

Evaluate:

• Secret storage

• Encryption

• Access control

• External secret managers

• Rotation

• Logging

Avoid treating Kubernetes Secrets as automatically secure.

36. Review Storage Security

Cloud storage is a common data exposure area.

Review:

• Public access

• Access policies

• Encryption

• Versioning

• Logging

• Replication

• Retention

• Lifecycle policies

Examples include:

• Amazon S3

• Azure Blob Storage

• Google Cloud Storage

37. Review Database Security

Assess:

• Public exposure

• Authentication

• Encryption

• Network access

• Administrative access

• Backups

• Logging

• Database audit capability

Managed database does not mean the database configuration is automatically secure.

38. Review Data Classification

Understand:

• What data exists?

• Where is it stored?

• How sensitive is it?

• Who can access it?

• Which regulations apply?

A cloud security review without data context can misprioritise findings.

39. Review Encryption at Rest

Check whether sensitive services support and use encryption.

Also review:

• Provider-managed keys

• Customer-managed keys

• Key ownership

• Key rotation

• Access permissions

Do not simply mark:

Encryption = enabled.

Understand who controls the keys.

40. Review Encryption in Transit

Review:

• TLS

• Internal service communication

• APIs

• Database connections

• Administrative connections

• Hybrid links

Sensitive internal traffic may also require protection.

41. Review Key Management

Key management is a critical architectural dependency.

Assess:

Key Creation
    ↓
Storage
    ↓
Usage
    ↓
Access
    ↓
Rotation
    ↓
Revocation
    ↓
Deletion

Review separation of duties between:

• Key administrators

• Data administrators

• Application owners

42. Review Secrets Management

Cloud environments should use centralised secrets management where practical.

Review:

• Secret creation

• Access

• Rotation

• Audit logging

• Application integration

• CI/CD usage

Avoid:

• Credentials in repositories

• Secrets in plain-text configuration

• Shared passwords

43. Review Logging Architecture

Cloud logs should usually be centralised.

Examples:

AWS

• CloudTrail

• VPC Flow Logs

• GuardDuty findings

Azure

• Activity Logs

• Entra logs

• Defender logs

Google Cloud

• Cloud Audit Logs

• VPC Flow Logs

Map:

Cloud Environment
      ↓
Audit Logs
      ↓
Central Security Location
      ↓
SIEM
      ↓
Detection

44. Protect the Logs

Ask:

• Can administrators delete audit logs?

• Are logs stored outside production?

• Is retention appropriate?

• Are logs immutable?

• Is access restricted?

An attacker with administrative access may try to remove evidence.

45. Review Logging Coverage

Logging enabled in 90% of accounts may still be insufficient if the missing 10% contain critical systems.

Validate:

• All accounts

• All subscriptions

• All projects

• All required regions

• Critical services

Coverage matters.

46. Review Threat Detection

Cloud providers offer native security services.

Examples include:

• AWS GuardDuty

• Microsoft Defender for Cloud

• Google Security Command Center

Assess:

• Coverage

• Configuration

• Ownership

• Alert routing

• Investigation process

Enabling a service does not guarantee operational value.

47. Review SIEM Integration

Ask:

• Which cloud logs reach the SIEM?

• Are security alerts ingested?

• Are detections implemented?

• Who monitors them?

• Are alerts tested?

The flow should be:

Cloud Event
    ↓
Telemetry
    ↓
SIEM
    ↓
Detection
    ↓
Analyst
    ↓
Response

48. Map Cloud Attack Scenarios

Review realistic attack scenarios.

Example:

Credential Phishing
      ↓
Cloud User Compromise
      ↓
Privilege Escalation
      ↓
IAM Modification
      ↓
Persistence
      ↓
Data Access

Ask which controls prevent, detect, or limit each step.

49. Review Cloud Privilege Escalation Paths

Cloud IAM relationships can create indirect privilege escalation.

For example:

User
  ↓
Can Pass Role
  ↓
Compute Service
  ↓
Privileged Role
  ↓
Administrator Access

An apparently limited user may gain higher privileges indirectly.

Senior consultants should look beyond directly assigned permissions.

50. Review Cross-Account Trust

Cross-account or cross-subscription access can create complex attack paths.

Map:

Account A
   ↓
Trusted Role
   ↓
Account B
   ↓
Sensitive Resource

Review:

• Trust policies

• External IDs

• Third parties

• Federation

• Privileged relationships

51. Review SaaS Integration

Cloud environments frequently integrate with external services.

Examples:

• CI/CD

• Monitoring

• Backup

• Security tools

• Identity systems

• Data analytics

Ask:

• What permissions are granted?

• What data is shared?

• How is access revoked?

• What happens if the provider is compromised?

52. Review Infrastructure as Code

Modern cloud environments are increasingly deployed through:

• Terraform

• CloudFormation

• Bicep

• ARM templates

• Kubernetes manifests

Review:

• Code repositories

• Security scanning

• Secrets

• Policy validation

• Approval

• Drift

Infrastructure security should begin before deployment.

53. Review CI/CD Security

CI/CD platforms often have significant cloud privileges.

Map:

Developer
   ↓
Source Control
   ↓
CI/CD
   ↓
Deployment Identity
   ↓
Cloud Environment

Review:

• Pipeline permissions

• Secrets

• Branch protection

• Approval controls

• Deployment roles

• Artifact security

54. Identify CI/CD Attack Paths

Example:

Developer Compromise
       ↓
Pipeline Modification
       ↓
Deployment Role
       ↓
Production

Ask:

Can a developer indirectly gain production control by modifying the pipeline?

This is a critical architecture question.

55. Review Backup and Recovery

Review:

• Backup coverage

• Backup location

• Encryption

• Retention

• Immutability

• Cross-account protection

• Recovery testing

Ask:

Could the same compromised administrator delete both production and backups?

If yes, resilience may be weak.

56. Review Disaster Recovery

Assess:

• Recovery regions

• Recovery accounts

• Recovery credentials

• Dependencies

• DNS

• Data replication

• Recovery testing

Security incidents can become availability incidents quickly.

57. Review Multi-Cloud Architecture

Multi-cloud environments introduce additional complexity.

You may encounter:

Entra ID
   ↓
AWS
Azure
Google Cloud
Kubernetes
SaaS

Review consistency across:

• Identity

• Logging

• Policy

• Key management

• Incident response

• Governance

Different clouds should not mean completely different security standards.

58. Identify Security Control Gaps Between Clouds

Example:

AWS
Mature Guardrails
Mature Logging
Strong IAM

Azure
Partial Policies
Partial Logging
Broad Admin Access

The enterprise risk may be:

Cloud security maturity is inconsistent across platforms.

That is more meaningful than reporting isolated configuration findings.

59. Review Cloud Compliance

Determine applicable requirements.

Examples:

• ISO/IEC 27001

• ISO 27017

• ISO 27018

• SOC 2

• PCI DSS

• CIS Benchmarks

• NIST

• Privacy requirements

Map controls carefully to the services actually being used.

60. Avoid Compliance-Only Cloud Reviews

A cloud environment can be compliant and still contain meaningful attack paths.

For example:

MFA
✓

Logging
✓

Encryption
✓

but:

CI/CD
   ↓
Over-Privileged Production Role
   ↓
Full Cloud Administration

A threat-based review may identify risk missed by checklist assessment.

61. Build Cloud Attack Paths

Consider:

Internet
   ↓
Application
   ↓
Workload Identity
   ↓
Cloud Storage
   ↓
Sensitive Data

Or:

Developer
   ↓
CI/CD
   ↓
Deployment Identity
   ↓
Production

Or:

Cloud User
   ↓
Role Assumption
   ↓
Security Account
   ↓
Logging Configuration

Attack-path analysis helps prioritise cloud findings.

62. Review Blast Radius

For every privileged identity ask:

If compromised, what can it control?

Evaluate:

• Accounts

• Subscriptions

• Projects

• Applications

• Data

• Security controls

• Logs

• Backups

Large blast radius should receive special attention.

63. Review Security Control Independence

Security controls should ideally not be fully controlled by the systems they protect.

Weak design:

Production Account
│
├── Application
├── Logs
├── Security Tools
└── Backup

Compromise of one administrator may expose everything.

Stronger design:

Cloud Organisation
│
├── Production
├── Security
├── Logging
└── Backup

Separation can improve resilience.

64. Assess Cloud Security Maturity

A simple model might include:

Level 1 — Ad Hoc

Cloud usage is decentralised with limited governance.

Level 2 — Developing

Basic standards and controls exist.

Level 3 — Defined

Governance and baseline security are consistently implemented.

Level 4 — Managed

Security is centrally monitored and measured.

Level 5 — Optimised

Controls are automated and continuously improved.

Always support maturity ratings with evidence.

65. Identify Systemic Cloud Findings

Examples:

Weak Cloud Governance

Multiple accounts operate without central policy.

Excessive Privilege

Broad IAM permissions are widespread.

Inconsistent Logging

Audit visibility varies by environment.

Decentralised Secrets Management

Teams use different approaches.

Weak Environment Separation

Production and non-production share trust relationships.

Systemic findings usually deserve strategic remediation.

66. Develop Cloud Findings

A cloud finding should include:

Finding Title
      ↓
Observation
      ↓
Affected Scope
      ↓
Evidence
      ↓
Attack Scenario
      ↓
Risk
      ↓
Recommendation

67. Example Finding

Excessive Privileged Access Across Cloud Environments

Observation

Multiple human identities retain permanent administrative permissions across production cloud environments.

Risk

Compromise of a privileged identity could provide broad control over cloud resources, security configuration, and sensitive data.

Attack Scenario

Credential Theft
      ↓
Cloud Authentication
      ↓
Administrator Role
      ↓
Production Access
      ↓
Security Control Modification
      ↓
Data Access / Service Disruption

Recommendation

Introduce centralised privileged-access governance, require phishing-resistant MFA, reduce standing administrative permissions, implement temporary elevation, and regularly review privileged roles.

Priority

High

68. Example Architecture Finding

Cloud Audit Logs Are Stored Within the Production Security Boundary

Observation

Critical audit logs are retained within the same cloud accounts as production workloads.

Risk

A sufficiently privileged attacker compromising production may also be able to modify or delete evidence required for detection and investigation.

Recommendation

Centralise security logs within a dedicated security-controlled account or subscription with restricted administrative access and appropriate retention protections.

69. Prioritise Cloud Findings

Consider:

• Internet exposure

• Privilege

• Criticality

• Attack path

• Blast radius

• Sensitive data

• Detection capability

• Existing controls

• Compliance impact

An issue affecting a single development system should generally be treated differently from one affecting the organisation’s identity platform.

70. Build the Cloud Remediation Roadmap

Example:

0–30 Days
│
├── Remove unnecessary public exposure
├── Secure privileged accounts
├── Remove exposed credentials
└── Enable critical audit logging

30–90 Days
│
├── Centralise identity
├── Implement logging standards
├── Improve IAM governance
└── Standardise cloud security baselines

3–6 Months
│
├── Implement policy guardrails
├── Introduce PAM/JIT
├── Improve network segmentation
└── Centralise secrets management

6–12 Months
│
├── Multi-cloud security governance
├── Security automation
├── Policy-as-Code
└── Continuous control validation

71. Executive Cloud Security Reporting

Executives usually do not need a list of 150 misconfigurations.

Instead present themes such as:

Cloud Governance

Security controls are inconsistently enforced.

Privileged Access

Excessive standing administrative permissions increase account-compromise impact.

Monitoring

Cloud logging coverage is incomplete.

Environment Separation

Production security boundaries require improvement.

Security Automation

Manual processes limit scalability.

Then provide a prioritised roadmap.

72. Cloud Review Deliverables

A professional engagement may produce:

• Cloud security assessment report

• Cloud architecture review

• Risk register

• Cloud control matrix

• IAM review

• Network review

• Attack-path analysis

• Annotated architecture diagrams

• Remediation roadmap

• Executive presentation

73. Build Your Cloud Review Checklist

Use:

[ ] Business context understood
[ ] Cloud inventory established
[ ] Ownership identified
[ ] Organisation hierarchy reviewed
[ ] Governance reviewed
[ ] Guardrails reviewed
[ ] Human IAM reviewed
[ ] Privileged IAM reviewed
[ ] Workload identity reviewed
[ ] Long-lived credentials reviewed
[ ] Network architecture reviewed
[ ] Public exposure reviewed
[ ] Segmentation reviewed
[ ] Egress reviewed
[ ] Compute reviewed
[ ] Containers reviewed
[ ] Kubernetes reviewed
[ ] Storage reviewed
[ ] Database security reviewed
[ ] Data protection reviewed
[ ] Encryption reviewed
[ ] Key management reviewed
[ ] Secrets reviewed
[ ] Logging reviewed
[ ] Threat detection reviewed
[ ] SIEM integration reviewed
[ ] CI/CD reviewed
[ ] Infrastructure as Code reviewed
[ ] Cross-account trust reviewed
[ ] Third-party integrations reviewed
[ ] Backup reviewed
[ ] Disaster recovery reviewed
[ ] Attack paths mapped
[ ] Blast radius evaluated
[ ] Findings prioritised
[ ] Roadmap developed

74. Practical Scenario — Enterprise Multi-Cloud Review

You are asked to assess an organisation operating:

• AWS production workloads

• Azure corporate services

• Kubernetes applications

• Microsoft Entra ID

• GitHub-based CI/CD

• Central SIEM

Initial discovery identifies:

• Developers have broad AWS access

• Azure subscriptions lack consistent policy enforcement

• Several Kubernetes workloads use static cloud credentials

• AWS production logs remain inside production accounts

• CI/CD has permanent administrative access

• Multi-cloud privileged access reviews are manual

Your task is not to report six unrelated issues.

Look for the larger pattern.

75. Step 1 — Identify Systemic Themes

Possible themes:

Cloud Governance Inconsistency
        +
Excessive Privilege
        +
Weak Workload Identity
        +
Insufficient Security Separation
        +
Manual Access Governance

These indicate broader cloud maturity weaknesses.

76. Step 2 — Build Attack Paths

Example:

Developer Compromise
       ↓
Source Repository
       ↓
CI/CD Pipeline
       ↓
Permanent Cloud Admin Role
       ↓
Production

Another:

Application Compromise
       ↓
Static Cloud Credential
       ↓
Cloud API
       ↓
Sensitive Resources

Another:

Production Administrator
       ↓
Production Account
       ↓
Audit Logs
       ↓
Evidence Deletion

77. Step 3 — Evaluate Blast Radius

Ask:

• Can one identity access multiple clouds?

• Can CI/CD modify security controls?

• Can workloads access unrelated resources?

• Can administrators modify logs?

• Can production compromise affect backup?

Now you are evaluating architecture rather than isolated settings.

78. Step 4 — Develop the Target State

Example:

Central Identity
      ↓
Strong MFA
      ↓
Temporary Privilege
      ↓
Cloud Roles

With:

Enterprise Cloud Governance
      ↓
Policy Guardrails
      ↓
AWS / Azure / GCP

And:

Cloud Workloads
      ↓
Managed Workload Identity
      ↓
Least Privilege

And:

All Clouds
    ↓
Central Logging
    ↓
Security Account
    ↓
SIEM

79. Senior Consultant Cloud Review Questions

Build the habit of asking:

Governance

What prevents a team from deploying insecure cloud infrastructure?

Identity

Which identity represents the largest blast radius?

Workloads

How do applications authenticate to cloud services?

Network

What is publicly reachable and why?

Data

Where does the most sensitive cloud data exist?

CI/CD

Who can indirectly control production through deployment systems?

Logging

Could a production administrator destroy audit evidence?

Detection

How would the SOC detect cloud privilege escalation?

Recovery

Could an attacker destroy both workloads and backups?

These questions reveal meaningful cloud risk.

80. Build Your Cloud Security Review Toolkit

Add:

Cloud Security Review Toolkit
│
├── Cloud Discovery Questionnaire
├── Cloud Inventory Template
├── Governance Review Checklist
├── IAM Review Checklist
├── Network Review Checklist
├── Workload Review Checklist
├── Kubernetes Review Checklist
├── Data Security Checklist
├── Logging Review Checklist
├── Cloud Attack Path Template
├── Cloud Risk Register
├── Cloud Finding Template
├── Multi-Cloud Assessment Matrix
└── Cloud Security Roadmap

Key Takeaways

A Senior Security Consultant conducting cloud security reviews should:

• Understand the cloud business context

• Map the complete cloud landscape

• Understand shared responsibility

• Review governance before configurations

• Evaluate organisational structure

• Assess cloud guardrails

• Treat identity as a primary security boundary

• Review privileged and workload identities

• Identify long-lived credentials

• Assess public exposure

• Evaluate segmentation and egress

• Review compute, containers, and Kubernetes

• Protect storage and databases

• Understand sensitive data

• Review key and secrets management

• Centralise and protect security logs

• Evaluate cloud threat detection

• Review CI/CD and Infrastructure as Code

• Identify privilege escalation paths

• Evaluate cross-account trust

• Measure blast radius

• Identify systemic weaknesses

• Develop practical remediation roadmaps

• Communicate cloud risk at both technical and executive levels

The cloud security review workflow is:

Discover
   ↓
Govern
   ↓
Map Identity
   ↓
Map Connectivity
   ↓
Review Workloads
   ↓
Follow Data
   ↓
Review Visibility
   ↓
Build Attack Paths
   ↓
Evaluate Blast Radius
   ↓
Prioritise Risk
   ↓
Build Roadmap

A mature cloud security review does not ask only:

“Is this cloud resource configured securely?”

It asks:

“How could compromise of this resource propagate through the cloud environment, and what prevents that from becoming a business-impacting incident?”

What’s Next?

➡️ 05 — Risk & Compliance

Now that you can review cloud environments from governance, architecture, identity, workload, data, and attack-path perspectives, the next module connects technical security findings with enterprise risk and compliance obligations.

You will learn how Senior Security Consultants translate technical observations into risk statements, evaluate likelihood and impact, assess controls, understand residual risk, map findings to frameworks and regulatory requirements, work with risk registers, handle exceptions, and support management risk decisions.

The goal is to move from:

“This security control is weak.”

to:

“This weakness creates a defined business risk, affects specific compliance obligations, and requires a clearly prioritised treatment decision.”