Cloud Sharing Links, Snapshots, and Cross-Account Transfer

Follow control of the object, not only bytes

A user creates a database snapshot and grants another account permission to restore it. The provider may perform the copy inside its own infrastructure. A perimeter sensor sees no large upload, yet another authority can now obtain the data.

Cloud movement includes object sharing, snapshot permission, image publication, replication, export jobs, cross-account copy, presigned access, and resource-policy changes. The relevant boundary is account, tenant, organization, region, or approved principal.

Define the protected object, source owner, destination authority, operation, permission, lifetime, and provider semantics. A public flag, named external account, and organization-wide share create different exposures.

Derived resources need lineage

A snapshot, backup, machine image, export file, or replica can contain data from another resource while receiving a new identifier. If detection follows only the original object, the derived copy disappears from the story.

Preserve source resource, derived resource, account and region, creation actor, service operation, encryption key relationship, tags, time, and later permission changes. Provider job identifiers can connect request, completion, and output.

Tags and names are helpful but attacker-controlled or mutable. Use provider-assigned identifiers and event-time ownership where available. A snapshot called backup can still be an unauthorized transfer path.

Authority changes can be the transfer event

A resource policy can make an object readable by a new principal without copying it. A presigned URL can delegate temporary access. A role trust change can let another account assume authority over the resource. These are control-plane state changes with data-plane consequence.

Relate actor, session, role or token, policy before and after, target principal, conditions, expiration, resource sensitivity, approval, and later use. A policy document should be interpreted structurally; string matching can miss wildcards, conditions, inherited organization scope, or equivalent principal forms.

The cloud control-plane detection model helps separate who changed authority from who later exercised it. Both identities matter.

Provider success does not always mean movement completed

A successful API request may mean the provider accepted an export job, not that the job finished. A copy can fail after creation. A replication rule can affect only new objects. A share can require acceptance by the destination.

Follow request, policy evaluation, job state, output creation, permission propagation, destination acceptance, and access. Preserve event and ingest times because control-plane and data-plane records can arrive at different rates.

Use precise states: requested, authorized, created, shared, accepted, accessed, and downloaded. Combining them into successful transfer makes the alert more confident than the provider’s evidence.

Respond across every copy and authority path

Removing the original permission may not delete a destination copy. Deleting a snapshot may not revoke an exported object. Rotating a URL may not remove a role trust relationship. Response needs a lineage and authority inventory, not one API reversal.

The alert should identify source and derived resources, source and destination ownership, actor and session, exact operation and state, permissions, key relationships, later access, approval context, and known residual copies. State what the provider confirms and what remains inferred.

Cloud-side movement detection is strongest when it describes control: who could access which derived representation, under whose authority, for how long, and whether that path was exercised. Network evidence can add context, but it is not the defining boundary. That distinction keeps the conclusion useful across provider architectures.