Cross-account bucket delivery (S3, GCS, Azure): a security checklist

Start with a dedicated delivery bucket#

A dedicated delivery bucket is the foundation of cross-account sharing, because every other control is simpler when the bucket holds only the licensed package. Copy the prepared data into a new bucket, ideally in a separate account, project or subscription used only for deliveries, and never grant a buyer access to a production or backup bucket.

Block public access on the bucket and the account before anything is uploaded. Name the bucket for the delivery rather than the buyer, since bucket names surface in logs, URLs and shared documents. Include a manifest of file names and checksums so the buyer can confirm the package is complete.

Before granting access, run a final scan of the delivery prefix. Google's Sensitive Data Protection can inspect Cloud Storage repositories, and secret scanners such as TruffleHog, which scans object stores among other sources, can catch keys left in configuration exports. TruffleHog's verification feature logs in with the secrets it finds, so use it with care on data that may contain third-party credentials.

The cross-account delivery checklist#

The cross-account delivery checklist covers nine controls, from a dedicated bucket to planned revocation, and works as a sign-off document. The person who configures the bucket and a second reviewer both confirm each line before the buyer receives access details.

• 1Dedicated bucket in a delivery-only account, project or subscription.
• 2Public access blocked at both bucket and account level.
• 3One principal in the buyer's account, named in the license or delivery plan.
• 4Read-only actions only, scoped to the delivery prefix.
• 5Encryption with a customer-managed key whose policy grants decrypt to that principal only.
• 6Object-level access logging switched on and retained.
• 7Versioning or object lock if the package must be provably unchanged.
• 8An expiry date agreed in writing, with a named owner for revocation.
• 9Revocation steps: remove the grant, remove key permissions, then delete or archive the bucket.

How the controls map across S3, GCS and Azure#

The controls map closely across the three major clouds, though the names differ. Feature details and limits change, so confirm current behavior in each provider's documentation before relying on any of them.

When presigned and signed URLs are enough#

Presigned and signed URLs are enough for small, one-off pulls where the buyer has no matching cloud identity. A presigned or signed URL typically grants access to one object for a limited time (an Azure shared access signature can also cover a whole container, so scope it carefully), and anyone holding the URL can use it, which is both the convenience and the risk.

Keep expiries short, generate URLs per file batch rather than for the whole package at once, and send the list through a channel separate from the delivery notice. The maximum lifetime of a URL depends on the provider and on the credentials that signed it, so check the documentation rather than assuming a link will outlive the session that created it.

For large or repeated deliveries, role-based access is easier to audit and revoke. Reads by a named principal appear in logs under that identity, while a URL forwarded around the buyer's organization tells you only that someone used it.

Encryption keys and key policies#

A customer-managed key gives the supplier a second off switch. Even if a bucket policy is misconfigured, a principal without decrypt permission on the key cannot read the encrypted objects, and removing that permission stops further reads of objects encrypted with that key.

Scope the key policy to the buyer's principal and to decrypt only. Do not grant key administration, and do not reuse a key that protects production data. Remember the limit of any technical control: once the buyer copies objects into its own account, the license terms govern that copy, not your key.

Logging, expiry and revocation#

Logging, expiry and revocation close the delivery: logs prove who read what, and revocation should be a scheduled event with an owner, not something that happens when someone remembers. A grant left open after acceptance serves no purpose and widens the window for mistakes.

Illustrative: a software company delivers to a buyer on another cloud#

Illustrative: a fictional vertical software company serving property managers licenses a prepared set of support tickets linked to Jira issues and release notes. Its data lives in AWS, while the buyer's team works mainly in Google Cloud and has no AWS identity ready.

The CTO creates a delivery-only AWS account and bucket, blocks public access, encrypts with a dedicated KMS key and turns on CloudTrail data events. The buyer creates a minimal AWS role for the transfer, and the bucket and key policies grant that role read and decrypt on one prefix. Logs show the reads, the buyer confirms checksums, and the CTO removes both grants on the agreed date and archives the bucket under the license's retention terms.

How SourceX approaches bucket deliveries#

SourceX handles bucket delivery within the Delivery step of the SourceX five-step transaction. Large datasets stay in the supplier's own storage or ship on encrypted drives, and SourceX never hosts multi-terabyte datasets; the handover is recorded instead.

The delivery method, the principal granted access, the dates and the release authorization become part of the SourceX Evidence Packet, so supplier and buyer share one record of what was delivered, to whom and under which approval.