Secure file sharing for business: what to check before you send the link

The four properties that make a share safe to send

A share is safe to send outside your company when it ends on its own, can be pulled back before then, is tied to a person rather than to possession of a URL, and leaves a record of every open. Miss one and you have a specific, nameable exposure rather than a vague unease.

• Expiry: access ends on a date you chose, not when someone remembers to clean up.
• Revocation: you can cut access early, from one place, without rotating anything else.
• Identity: the recipient proves who they are, so the record names a person rather than a request.
• Record: every open is logged with who, what and when, in a form you can export.

What is not on that list

Encryption in transit is not a differentiator. Every option below is HTTPS, and transport encryption protects the link while it travels, not after it arrives. The risk being managed here is a valid link in the wrong hands, which encryption does nothing about.

A password sent in a second email is not one either. It adds friction, it usually travels the same channel as the link, and it answers none of the four properties: it does not expire, it cannot be revoked centrally, it does not identify anyone, and it produces no record. If a password is the only control, the share is unprotected with extra steps.

Public objects: not a sharing model at all

Making an object publicly readable and passing the URL around fails all four properties at once. There is no expiry, revocation means editing the object or its policy, there is no identity, and while server access logs and CloudTrail record requests, they record requesters and not people. An unlisted URL is not a secret: it travels in referrer headers, chat history, browser sync and forwarded mail.

S3 Block Public Access exists precisely to stop this pattern from arriving by accident. Leave it enabled at the account level, and treat any request to disable it for a specific bucket as a decision that needs a written reason, not a configuration detail.

Presigned URLs: right for one file, wrong as a habit

A presigned URL signs a specific object and operation with the credentials of the identity that created it, and works until its configured expiration or until those credentials expire, whichever comes first. It scores well on expiry and badly everywhere else. Treat it as a bearer token: anyone who obtains the URL can use it for as long as it is valid.

Revocation is the weak point. There is no list of outstanding links to click cancel on. Cutting a presigned URL short means invalidating the credentials that signed it or removing the object, which affects far more than the one share. Identity is absent by design, and your logs will show the signing identity rather than the recipient.

That makes presigned URLs an excellent mechanism and a poor process. Use them system to system, for a one-off download, or to accept an upload from a form. Do not build a client-facing sharing workflow on them and call it secure.

Four ways to reach S3 files without the AWS console

Attachments and sync folders: the copy problem

Emailing the document or dropping it into a consumer sync folder solves the delivery problem by creating a second copy outside the store you govern. From that moment the two drift: your version gets revised, theirs does not, and there is no mechanism to reconcile them beyond somebody noticing.

The governance consequence is worse than the version confusion. Retention rules, encryption settings, access policy and audit logging apply to the object in your bucket. They do not follow the copy into a mailbox, a laptop or a third party filing system. If the document was worth protecting where it lived, the copy is the whole exposure.

A workspace share: all four properties in one place

The alternative is to keep the object where it is and share a controlled view of it. That is what BucketDesk shares do. Expiry is required rather than optional, links are revocable from the workspace, recipients sign in with an emailed link so the record names a person, and every open is logged. Sharing is available on Pro and Business.

There is one decision worth making deliberately: a live link follows the object, so the recipient always sees the current version, while a snapshot freezes the file as it was at the moment you shared it. A live link is right for a working document your side is still revising. A snapshot is right for anything you have effectively committed to, such as a quote, a statement or a signed agreement, where "what did we actually send them" needs a permanent answer.

What makes an S3 workspace secure enough for a teamReview features and plan limits

Sharing with clients and with people who work remotely

A client is not an employee. They will not install a client, they will not be provisioned an identity in your directory, and they should certainly never receive an AWS credential. What they need is one link that opens, proves who they are with minimal ceremony, and stops working when the engagement ends. That is the whole requirement, and it is why sign-in by emailed link exists: it establishes identity without creating an account you then have to deprovision.

Remote teams are the same problem seen from inside. The useful shift is that the control sits on the object rather than on the network. Nobody has to be on a VPN for an expiring, revocable, logged share to behave correctly, which also means nobody gets broad network access as a side effect of needing to read one document.

Before you send the link

• Does this share expire on a date, and is that date short enough to be meaningful?
• If the recipient forwards it, does the next person get in without proving who they are?
• Can you revoke it in under a minute, from one screen, without touching credentials?
• Will the log tell you who opened it, or only that a request was made?
• Should the recipient see later revisions? If not, send a snapshot rather than a live link.
• Is this a copy leaving the governed store, or a view of the object staying in it?