Does a cloud provider handle every security task?

No. The division varies, and customers retain important responsibilities.

Is a managed service free of configuration risk?

No. Customer-controlled identities, access rules and application behavior can still create exposure.

Does cloud security mean only blocking attackers?

No. It also includes preventing mistakes, detecting misuse and maintaining recoverable, available services.

AI Glossary / Data engineering and architecture / Beginner

Cloud computing security

Definition

Cloud computing security is the protection of cloud-hosted systems, data and services against unauthorized access, misuse, disruption and unintended exposure. It combines technical controls, operational practices and clearly assigned responsibilities. Protection is shared between the cloud provider and the customer, with the division depending on the service and deployment model.

What it means

A provider may secure facilities and underlying infrastructure while a customer remains responsible for identities, data access and application configuration. A managed database shifts some operating tasks to the provider, but it does not decide which employee should see a record or whether a query result may be shared. Security therefore requires understanding what each service manages and what the organization must manage itself. The cloud label is neither a guarantee of safety nor evidence of inherent insecurity.

How it works

The organization identifies important assets and access paths, assigns permissions, protects credentials and configures network and data controls. Logs and monitoring help detect unusual behavior; backups and tested recovery support resilience. Configuration and software changes need review because they can alter exposure. Encryption protects data under particular conditions, but authorized access still needs control. A practical design maps responsibilities to named teams and checks that required controls operate across application, identity, storage and management interfaces.

Three practical examples

A company limits a cloud application's service identity to the storage objects it needs instead of granting broad administrative access.
A data team reviews who can query a managed warehouse and separates ordinary analysis from permission management.
An AI application ensures that document retrieval respects user access rights, so model-generated answers do not expose content merely because it exists in a shared index.

Think of it this way

Think of renting secure office space. The landlord may maintain the building's structure and entry systems, while the tenant controls staff access, document handling and internal procedures. The analogy is limited because cloud responsibilities change by service and are governed by specific technical arrangements; one provider's division should not be assumed for every product.

Worked example

Consider a hypothetical reporting service with three identities: an ingestion worker, an analyst and an administrator. The worker needs to add new records but not change access policies. The analyst needs to read approved tables but not delete backups. The administrator manages permissions but does not require routine use of every dataset. A permission matrix can make those distinctions explicit. If all three instead receive one shared administrator credential, the system loses both separation and clear attribution. This worked example is a design exercise, not a complete security architecture or a claim that three roles are sufficient for every organization.

Illustrative case study

Fictional case: Pine Insights uses a managed analytics platform and initially assumes that all security work belongs to the provider. During a configuration review, the team finds an overly broad sharing setting on a dataset. It narrows access, assigns an owner for permission reviews and tests whether audit logs show the relevant changes. It also checks the provider's service-specific responsibility guidance. This case illustrates a preventable governance gap without claiming a real breach or quantified risk reduction.

Common misconceptions and mistakes

Do not assume encryption compensates for excessive permissions: an authorized but inappropriate request may still receive decrypted data. Do not treat a private network as a substitute for identity controls. Provider certifications do not automatically certify every customer configuration or business process. A backup is useful only if it can be recovered when needed, and monitoring is useful only if someone can respond. Avoid copying one responsibility chart across services that expose different levels of customer control.

Business use

Businesses should translate security requirements into specific access, configuration, monitoring and recovery responsibilities. Keep an inventory of cloud services and data, identify owners and review changes as the system evolves. For AI, include prompts, retrieved documents, outputs, model artifacts and logs in that inventory. Evaluate controls through representative tests and evidence, rather than relying on reassuring labels. Legal or regulatory obligations require context-specific review beyond this technical glossary definition.

Check your understanding

A provider patches the operating system of a managed database. Does that establish that the customer's analyst permissions are correct?

Answer: No. Platform maintenance and data authorization are separate responsibilities that must both be addressed.

Related terms

Identity and access management
Least privilege
Backup
Incident response
shared responsibility model
encryption
audit logging

Learn next

Choose one cloud service and list which party manages infrastructure, software updates, identities, data permissions and recovery. Confirm that list against the service documentation. Then test one realistic access and recovery scenario to identify gaps between the documented design and actual behavior.

Sources

Primary provider references: AWS shared responsibility model, https://aws.amazon.com/compliance/shared-responsibility-model/ ; Amazon VPC security responsibilities, https://docs.aws.amazon.com/vpc/latest/userguide/security.html . Official provider search excerpts consulted; full service-specific and editorial review remain pending. Provider examples illustrate responsibility boundaries rather than a universal allocation for all clouds.

Previous: Cloud computing architecture Next: Cloud database