---
{
  "title": "Cloud storage security",
  "summary": "Verify storage access through identities, resource policies, delegated links, encryption keys, logging, and recovery rather than equating encryption with privacy.",
  "topic": "networking",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "units": [
    6
  ],
  "aliases": [],
  "sources": [
    {
      "title": "AWS: Shared Responsibility Model",
      "url": "https://aws.amazon.com/compliance/shared-responsibility-model/"
    },
    {
      "title": "AWS: Amazon S3 security best practices",
      "url": "https://docs.aws.amazon.com/AmazonS3/latest/userguide/security-best-practices.html"
    }
  ],
  "published": "2026-10-02",
  "editorialVersion": 2
}
---
## The idea

Cloud storage security requires explicit permission design, appropriate encryption, logging, retention, and recovery. Public access can be intentional for some resources, but sensitive records need verified restrictions. Object policies, identity permissions, temporary links, and inherited settings may interact. Encryption at rest does not prevent an identity with legitimate decryption and read permission from accessing the content. Assess the full access path and business purpose.

## In practice

A public website asset and a private payroll export use different storage policies. Tests verify that anonymous access succeeds only for the intended public asset.

## A common misunderstanding

“Encrypted” does not mean “not exposed.” Authorized access through the service can return decrypted content.

## Check your understanding

What should a sharing review include?

**Think it through:** Who can read, write, list, change permissions, and create delegated access, plus how those actions are logged.

## Classify objects before sharing them

Imagine a fictional academy stores public course images and private learner submissions. The objects may use the same underlying service but need different sharing and retention decisions. Separate their policy requirements explicitly instead of assuming one default fits every dataset.

Public access can be appropriate for the images. The submissions need a verified authorization path for the relevant learner and instructor. Test both the intended public read and the intended private denial using non-sensitive sample data.

## Delegation is another access path

Temporary links and service identities can grant access without an ordinary interactive login. Their scope, lifetime, handling, and revocation behavior matter. A private-looking interface does not prove that no delegated route exists.

Suppose an export link is copied into an inappropriate channel. Determine what the link permits and how long it remains usable according to the service's model. Avoid putting live credentials or private links in public troubleshooting examples.

## Encryption protects a different boundary

At-rest encryption does not prevent a service from returning plaintext to an identity with the required read and key permissions. Review who can read, write, delete, alter policies, or control the relevant keys.

Recovery also needs lifecycle planning. Retention, versioning, deletion controls, and backups solve different problems and have service-specific behavior. Verify the required restore result rather than assuming several enabled features are interchangeable.

For an authorized exercise, create an invented public image and private submission in a lab design. List every access route, including an application identity and a delegated link. Then add a mistaken deletion and describe how the owner restores the required version. The useful review connects data classification, effective permissions, cryptographic boundaries, and recovery evidence into one complete account.

## Keep exploring

- [[cloud-identity]]
- [[key-management]]
- [[exfiltration]]
- [[backups]]