Legacy Haven University

Cloud storage leaks when identity and object permissions do not match. CompTIA Security+ (SY0-701) tests that control pattern: who may touch stored data, under which rule, and who still owns the configuration after the provider hosts the disks.

Amazon Simple Storage Service (S3) is one vendor’s object store. An object store keeps files as objects inside a named container, often called a bucket. A bucket policy is a rule set on that container. Identity and Access Management (IAM) is the control plane that names people, services, and roles, then assigns permissions. Official SY0-701 does not list S3 or AWS. It does list cloud architecture, the responsibility matrix, cloud-specific vulnerabilities, misconfiguration, least privilege, permission restrictions, and hardening of cloud infrastructure. Use the vendor names as a working example. Map every choice back to those bullets.

Study the same pattern in the Security+ SY0-701 hub.

What object storage actually is

A file server presents folders and an operating system. An object store does not. The provider exposes an API. The customer creates a container, puts objects in it, and attaches access rules.

Three pieces decide a request:

1. Identity. Who or what is calling. A human user, a workload role, or another cloud service.
2. Permission. What that identity may do. Read, write, list, delete, or change policy.
3. Resource rule. What the container itself allows. A bucket policy is this layer.

Authorization (the “may I?” decision) fails closed when any required layer denies the request. Authentication (proving the identity) is separate. Security+ groups both under identity and access management in objective 4.6.

The responsibility matrix still applies

Objective 3.1 names the responsibility matrix. That is CompTIA’s term for shared responsibility. The cloud service provider (CSP) runs the physical facility, the storage fabric, and the control-plane API. The customer still owns:

• data classification
• who receives an account
• which permissions those accounts get
• encryption choices the customer can enable
• review of public or cross-account access

A third-party vendor (also 3.1) does not inherit your identity design. Hybrid designs add a second copy of the same problem: on-premises directories and cloud identities must not grant more access than either side intended.

IAM is permission assignment, not a logo

Objective 4.6 asks you to implement and maintain identity and access management. The official list includes:

• provisioning and de-provisioning user accounts
• permission assignments and implications
• access controls: mandatory, discretionary, role-based, rule-based, attribute-based, time-of-day restrictions
• least privilege
• privileged access management tools, including just-in-time permissions and ephemeral credentials

Least privilege means an identity receives only the access required for its task, and nothing extra. A backup role that can read objects does not need permission to rewrite the bucket policy. A human admin who can change policy does not need standing access all day if a just-in-time grant will do.

Role-based access control (RBAC) groups permissions by job. Rule-based access control matches a statement such as “this principal, this action, this resource.” Attribute-based access control (ABAC) adds tags or context, such as environment or data class. A bucket policy is closest to a rule on the resource. An IAM policy attached to a user or role is closest to a permission assignment on the identity. Both must stay consistent.

Why bucket policies exist

A container policy answers questions the identity policy cannot answer alone:

• May any principal outside this account read these objects?
• May a specific role in another account write logs here?
• Does this container refuse anonymous access even if someone later attaches a wide identity policy?

That last question is configuration enforcement (objective 2.5). Access control lists (ACLs) appear on the same official line as permissions. Some object stores still expose object-level ACLs. Treat an ACL as a second, coarser rule. Prefer one explicit model and document it. Two overlapping models create gaps.

Objective 3.3 lists permission restrictions next to encryption as a method to secure data. Encryption at rest protects a stolen disk image. It does not stop an authorized API call. Permission restrictions stop the call.

Data at rest still needs a key plan

Objective 3.3 names data states: at rest, in transit, and in use. Cloud object storage is data at rest until a client pulls it. Then the same bytes become data in transit.

If the customer manages the key, key loss equals data loss. If the provider manages the key, review who inside the customer account may call decrypt. That is still a permission assignment.

Cloud-specific failure mode: misconfiguration

Objective 2.3 lists cloud-specific vulnerabilities and, separately, misconfiguration. Official text does not define a public bucket. The operational meaning is still simple: a container that accepts requests the owner did not intend.

Hardening (objective 4.1, target: cloud infrastructure) is the fix pattern:

• start from a secure baseline
• deny public access unless a written business rule requires it
• grant identities the narrowest role that completes the job
• remove unused accounts
• enforce the same rules on every new container
• log access and policy changes

Objective 2.5 names the same cluster: access control, ACLs, permissions, least privilege, configuration enforcement.

Do not publish steps that open a container to the internet. The exam item is the control, not the break.

How a request should fail

Walk the decision in this order when you study a scenario:

1. Is the caller an authentic identity? If not, stop.
2. Does the identity policy allow the action on this resource?
3. Does the container policy allow that same identity and action?
4. Does any extra restriction (ACL, block-public setting, time-of-day rule) deny it?
5. Is the data class allowed in this region (data sovereignty and geolocation sit in 3.3)?

A “yes” at step 2 and a “no” at step 3 is a deny. That is the point of a resource policy. Students miss this on scenario items because they stop at the role.

What to memorize for SY0-701

Memorize the official nouns, then attach the vendor example:

If a practice question names a bucket, translate it to “cloud storage container + resource policy.” If it names IAM, translate it to “identity, provisioning, and permission assignment.”

Operator checklist

Use this as a review list, not as a vendor runbook:

• Classify the data before you create the container.
• Create the identity first, then the permission, then the resource rule.
• Apply least privilege. Expand only with a ticket and an expiry.
• Confirm anonymous access is off unless a documented exception exists.
• Confirm encryption at rest is on.
• De-provision accounts that no longer need the store.
• Re-read the policy after every change.

Study the domain map and the rest of this series from the Security+ guide.