Cloud Security

In 2019, Capital One suffered one of the largest data breaches in U.S. banking history , over 100 million customer records exposed. The root cause was not a nation-state attack or a zero-day exploit. It was a misconfigured web application firewall in AWS, combined with overly permissive IAM roles that allowed the compromised workload to access far more data than it should have. Nobody handed an attacker the keys. The keys were already sitting in the wrong lock. Cloud misconfiguration is now consistently ranked among the top causes of data breaches globally , and when vendors are operating inside your cloud environment, their misconfigurations become your problem.

What is Cloud Security in the Vendor Context, Really?

Cloud security in the context of third-party risk is not primarily about the cloud provider's infrastructure , that part is largely handled. The real risk lives in how your organization has configured its cloud environment and how vendors are permitted to operate within it. The shared responsibility model is clear: the provider secures the infrastructure, but the customer is responsible for what runs on it, who can access it, and how it is configured. Most cloud breaches do not exploit the provider , they exploit the customer's configuration choices.

Vendor access in cloud environments takes many forms that traditional perimeter security was never designed to govern. A vendor might authenticate using a federated identity, a service principal, a cross-account IAM role, a managed identity, or a long-lived API key. Each mechanism has different risk characteristics, different governance requirements, and different failure modes. The common thread is that they all grant a third party some level of capability inside your cloud tenant , the ability to read data, execute workloads, modify configurations, or trigger automated processes.

Misconfiguration is the dominant risk vector in cloud environments, and it is insidious because it does not look like an attack. An S3 bucket set to public, an IAM role with a wildcard permission policy, a firewall rule left open during testing and never closed , these are configuration states that an attacker discovers and exploits. In the vendor context, misconfigurations can originate from either side: your own team provisioning vendor access carelessly, or a vendor making changes inside your environment that drift from your intended security baseline.

The cloud vendor risk landscape concentrates around five problem areas:

• Overprivileged vendor roles , IAM roles granted far more permission than the integration requires, typically because scoping correctly takes more time than assigning a broad policy
• Standing access vs just-in-time access , vendor credentials that persist indefinitely rather than being provisioned on demand and automatically revoked
• Cross-tenant visibility gaps , vendors operating across multiple cloud tenants with no isolation between customers
• Shadow cloud usage , vendors spinning up resources in your environment outside of approved processes
• Drift from security baseline , vendor-managed configurations that gradually move away from the posture you approved

Why this matters

When a vendor operates inside your cloud environment, the traditional model of third-party risk , assess controls, receive attestation, file the report , breaks down almost completely. A vendor can have an excellent SOC 2 report and simultaneously be operating in your AWS tenant with an IAM role granting read access to every S3 bucket in the account. Those two facts are not in conflict, because the SOC 2 covers the vendor's own environment. Nobody assessed how they were configured inside yours.

The blast radius of a cloud misconfiguration in a vendor context is shaped by what access was granted and how broadly it was scoped. A vendor with a narrowly scoped role represents a contained, manageable risk. A vendor with an administrator role in your cloud account represents an existential exposure , if their credentials are compromised, an attacker inherits the ability to exfiltrate data, modify infrastructure, disable logging, create backdoor accounts, and cover their tracks, all using fully authorized API calls.

The attacker's perspective is straightforward: cloud environments are valuable targets, vendor access is often poorly governed, and the credentials enabling that access are frequently long-lived and broadly scoped. Compromising a vendor with cloud access to multiple customers is a force multiplier , one successful attack delivers a foothold in dozens of environments simultaneously.

Where most teams get this wrong

The most pervasive failure is conflating cloud provider security with cloud security. Organizations sometimes carry an implicit assumption that because the cloud is inherently more secure than on-premises infrastructure, vendor access inside the cloud is less risky than it would be elsewhere. This is exactly backwards. Cloud environments offer exceptional security capabilities, but those capabilities require deliberate configuration. An ungoverned IAM role in AWS is not made safe by the fact that it is in AWS.

The second failure is the absence of cloud-specific controls in vendor assessments. Most TPRM questionnaires ask about encryption, vulnerability management, and incident response. They rarely ask specifically about how a vendor manages their cloud roles, governs the service principals they use in customer environments, or controls configuration drift.

• Vendor IAM roles provisioned with AdministratorAccess or equivalent because scoping least-privilege permissions takes engineering effort
• No periodic review of what vendor roles can actually do versus what they need to do
• Vendor access provisioned for a specific project that persists long after that project concluded
• No monitoring or alerting on vendor API activity within the cloud environment
• Cloud logging not enabled or not reviewed for vendor activity specifically

What good looks like

Mature cloud security governance for vendor access is a continuous control, not a one-time provisioning decision. Access is scoped precisely, reviewed regularly, monitored actively, and revoked automatically when no longer needed.

• Least-privilege IAM roles built specifically for each vendor integration , purpose-built permission sets, not shared broad policies
• Just-in-time access provisioning for vendor activities requiring elevated permissions , granted for a defined window, then automatically revoked
• Cloud activity monitoring with alerts on vendor role usage , unusual API patterns, out-of-scope access, and off-hours activity trigger investigation
• Infrastructure as Code governance , vendor-accessible configurations defined in version-controlled templates so drift is detectable
• Regular access reviews , at minimum quarterly for high-privilege vendor roles, with evidence captured in the TPRM record
• Separation between production and non-production access , no pathway to production unless explicitly approved

Tooling

Cloud-Native IAM , AWS IAM, Azure RBAC, GCP IAM

Every major cloud platform supports granular, least-privilege role definitions. The question is not whether the platform supports it , it does , but whether vendor roles have been configured to use it. Asking a vendor to share the permission boundaries of the role they use in your environment is a reasonable and increasingly common request.

Cloud Security Posture Management , Wiz, Prisma Cloud, Orca Security, Lacework

CSPM tools continuously scan cloud environments for misconfigurations, excessive permissions, and drift from security baselines. A vendor using CSPM across the environments they manage is demonstrating an active posture. Organizations should also run CSPM in their own cloud environments to detect misconfigurations introduced through vendor activity.

Cloud Activity Monitoring , AWS CloudTrail, Azure Monitor, GCP Audit Logs, Datadog Cloud SIEM

These tools capture every API call made within a cloud environment. In the vendor context, they are the audit trail for every action a vendor takes inside your tenant. Without them, vendor activity is invisible. Enabling and actively monitoring these logs for vendor-attributed activity is a baseline control, not an advanced one.

Infrastructure as Code Security , Checkov, tfsec, AWS Config, Azure Policy

IaC security tools scan infrastructure templates for misconfigurations before deployment and enforce policy compliance on live infrastructure. Drift detection , alerting when live infrastructure diverges from its approved template , is particularly valuable for detecting unauthorized changes by vendors.

Cloud Entitlement Management , Tenable Cloud Security, Ermetic, Cloudknox

These platforms provide visibility into what every cloud identity can actually do versus what it has actually done, enabling right-sizing of permissions based on observed usage. For vendor roles specifically, they answer the key question: is this vendor using all the permissions they have been granted? In most cases, the answer is no , and unused permissions represent silent risk.

Governance challenges

Cloud governance for vendor access fails most often at the handoff between teams. The business owner approves the vendor relationship. A developer provisions cloud access because they need the integration to work. Security is notified after the fact, if at all. The result is vendor cloud access provisioned outside any formal governance process, with permissions set by whoever was available, and no structured review cycle.

• Require a cloud access justification document for every vendor role , what specific actions does it need, why, and what is the review cadence
• Tag all vendor-created or vendor-accessible resources so they are identifiable in your asset inventory
• Include cloud role permissions in vendor assessment scope , walk through why each permission is necessary
• Set conditional access policies that restrict vendor cloud access to known IP ranges or managed devices where feasible
• Automate deprovisioning , tie vendor cloud access to contract status so access is flagged for review when a contract expires

If you are a small team

Begin with a cloud access inventory , identify every non-human identity in your cloud environment that belongs to or is used by a vendor. For each one, record what permissions it has and when it was last used. This exercise will almost certainly surface roles with excessive permissions and identities that have not been used in months , both are immediate, low-effort remediation opportunities.

• Enable cloud audit logging if it is not already active , this is free or near-free and foundational
• Review every vendor IAM role for least-privilege compliance , AdministratorAccess is a priority remediation
• Identify vendor roles with no activity in 90 days and initiate a review
• Run a free CSPM scan using your cloud provider's native tools to identify misconfigured vendor-accessible resources

What to require

Ask directly:

"What IAM role or service principal do you use to access our cloud environment, and can you walk us through why each permission in that role is necessary?"

"How do you detect and alert on configuration drift in cloud environments you manage or access on behalf of customers?"

"What logging and monitoring do you have in place for your activity within our cloud tenant, and would you share that visibility with us on request?"

Expect as evidence

• A documented and defensible permission set for the vendor's cloud role , not a screenshot of AdministratorAccess
• Evidence of CSPM or equivalent tooling applied to environments they manage
• A defined process for notifying customers of configuration changes made within their environment
• Confirmation that cloud audit logs covering vendor activity are enabled and retained

A vendor who cannot describe the permissions their cloud role carries, or who responds with 'we just use admin to keep things simple,' is telling you everything you need to know about how they approach cloud governance.

How to evidence it

SOC 2 Type II, ISO 27001, PCI-DSS, and HIPAA all address cloud access controls and configuration management. Demonstrating due diligence requires moving beyond policy documentation to evidence of active governance.

• Inventory of all vendor cloud roles and service principals with permissions documented
• Evidence of periodic access reviews with findings and remediation actions recorded
• Cloud audit log retention and evidence that vendor-attributed activity is being monitored
• Deprovisioning records demonstrating vendor cloud access was revoked upon contract termination

Key Takeaway

Cloud environments give vendors extraordinary capability inside your organization. That capability is not inherently dangerous , misconfiguration and ungoverned access are what make it dangerous. Every vendor role that carries more permission than it needs, persists longer than it should, and operates without monitoring is a standing risk that requires no attacker sophistication to exploit. The cloud did not create this problem , but it scaled it dramatically. Governing vendor access in the cloud is not optional infrastructure work. It is third-party risk management.

More on Security

• API Identity Misuse
• Access Certification Effectiveness
• Access Policy Misconfigurations