CloudSec-Pro key terms

A division of security duties between a cloud provider and its customer. The provider secures the physical infrastructure and managed service internals; the customer secures their data, identities, configurations, and anything they build on top.

The IaaS, PaaS, or SaaS categorization that determines how much of the stack the provider operates. Higher abstraction shifts more operational duties to the provider but leaves identity, data, and configuration duties with the customer.

The exact line in a given service where provider responsibility ends and customer responsibility begins. It varies by service, so it must be determined per workload rather than assumed from the general shared responsibility model.

The policies, decision rights, and oversight mechanisms an organization uses to direct cloud adoption. It defines who may approve accounts, services, and exceptions, and how compliance is evidenced to auditors and leadership.

The documented linkage between a regulatory or framework requirement and the specific technical or procedural safeguard that satisfies it. Good mapping shows evidence sources and lets one control satisfy multiple overlapping requirements.

Collecting and storing proof that controls operate, such as configuration snapshots, logs, and approval records, on a scheduled basis. It replaces manual screenshot gathering and reduces audit effort and staleness.

A living record of identified cloud risks with owners, likelihood, impact, and treatment decisions. It links technical findings to business consequences so leadership can prioritize remediation and accept residual risk explicitly.

A formal decision by an accountable owner to tolerate a known risk without further mitigation, usually time-bound and documented. It differs from ignoring a finding because it records rationale, approver, and expiry.

The process for granting, tracking, and expiring deviations from security policy. Each exception should name the scope, business justification, compensating controls, approver, and review date so drift does not become permanent.

Trusting an external identity provider to authenticate users and pass assertions about them to a cloud platform. It avoids separate credentials per cloud and centralizes authentication, session policy, and deprovisioning.

A signed XML statement from an identity provider describing a subject and authentication context. Cloud platforms validate the signature, audience, and timing conditions before issuing a session.

Configuration on the cloud side that defines which external identity provider is trusted, which audiences and conditions are accepted, and how claims map to roles. Weak conditions can allow assertion replay or cross-tenant impersonation.

A flaw where a trusted service is tricked into using its own authority on behalf of an unintended party. In cloud it often appears as overly broad role assumption or missing external ID checks in trust policies.

A principal in one account or tenant temporarily obtaining credentials for a role in another. Trust policies and conditions should restrict exactly who may assume it and under what external identifiers.

A maximum-permissions guardrail attached to an identity that caps what its other policies can grant. It prevents privilege escalation when delegated administrators create or modify roles.

Granting only the permissions needed for a task, for only as long as needed. In cloud it requires continuous review because permissions accumulate through policy changes and unused grants.

Elevating privileges temporarily after an approval or policy check, then automatically revoking them. It shrinks the window in which standing administrative credentials can be stolen or misused.

A chain of allowed actions that lets a lower-privileged principal gain higher rights, such as creating a role, passing it to a compute resource, then assuming it. These paths must be modeled, not just individual grants.

A logically isolated network in a cloud region where you define subnets, routing, and gateways. It is the foundation for segmentation, and its default route and peering choices determine exposure.

A stateful, instance-level firewall that permits traffic by protocol, port, and source. Because it is allow-list based and stateful, return traffic is automatic, but overly broad source ranges remain a common exposure.

A stateless, subnet-level filter evaluated in ordered rules for both inbound and outbound traffic. It provides a coarse second layer of defense and requires explicit rules for return traffic.

A regional hub that connects many VPCs and on-premises networks through a single attachment point. It simplifies routing but concentrates trust, so route tables and attachment policies need careful segmentation.

A private IP address inside your network that connects to a managed service without traversing the public internet. It reduces data exposure and lets service access be governed by network policy.

Controlling outbound traffic from workloads to prevent data exfiltration and command-and-control callbacks. Effective designs combine network allow-lists with DNS controls and proxy inspection rather than relying on inbound rules alone.

A managed service that creates, stores, and controls cryptographic keys and performs encrypt and decrypt operations without exposing key material. Its key policies and audit logs are central to data protection.

Encrypting data with a data key, then encrypting that data key with a longer-lived master key. It limits how much data a single key protects and allows fast re-wrapping when master keys change.

A key the customer creates and controls in a key service, including its policy, rotation, and disabling. It gives the customer the ability to revoke access to encrypted data independently of the provider.

Periodically replacing a cryptographic key with a new version while retaining old versions to decrypt existing data. It bounds the impact of an undetected key compromise and supports compliance requirements.

Any route by which data can leave its intended boundary, including public storage links, over-permissive APIs, logging pipelines, and outbound network flows. Enumerating these paths is a core design review activity.

Labeling data by sensitivity so handling, encryption, retention, and access rules can be applied consistently. Classification drives which controls are mandatory and is a prerequisite for automated protection.

An object store container whose policy or ACL allows anonymous access. It is a frequent cause of breaches, so continuous detection of public exposure and blocking of public policies are standard controls.

Defining cloud resources in versioned templates that are applied by automation rather than by hand. It enables review, repeatability, and drift detection, but misconfigured templates propagate errors at scale.

Expressing security and compliance rules in machine-evaluable form so they can be tested in pipelines and enforced at deploy time or continuously at runtime. It makes policy consistent and auditable.

Moving security checks earlier in the development lifecycle, such as scanning code and templates before deployment. Finding issues before release is cheaper and prevents flawed patterns from spreading.

Replacing servers or containers with new builds instead of patching them in place. It removes configuration drift, makes rollback predictable, and ensures every running instance matches a known artifact.

Inspecting image layers and installed packages for known vulnerabilities and embedded secrets before and after deployment. Continuous rescanning matters because new vulnerabilities are disclosed after images are built.

Protecting the code, dependencies, build systems, and artifacts that produce a workload. Practices include signed artifacts, provenance attestations, pinned dependencies, and verified build environments.

Divergence between the intended, codified state of a resource and its actual state after manual changes or out-of-band edits. Drift reintroduces known risks and undermines compliance evidence.

Continuous assessment of cloud configurations against benchmarks and policy, surfacing misconfigurations with context and remediation guidance. It complements runtime detection by addressing the conditions that enable attacks.

Modeling how an attacker could chain misconfigurations, identities, and network reachability to reach a high-value asset. It prioritizes fixes by real exploitability rather than by raw finding count.

Incident handling that uses cloud control-plane and data-plane logs, automated enrichment, and API-driven containment. It differs from host-centric response because identities and APIs are primary evidence and action surfaces.

A record of management API calls showing who changed what, when, and from where. It is the primary evidence source for investigating privilege changes, resource deletion, and policy tampering.

Using predefined automation to isolate a workload, revoke sessions, or disable credentials during an incident. It reduces attacker dwell time but must be tested to avoid disrupting critical services.