Setting Up Secure Cloud Storage: Restricted Access, Partner Sharing, Website Backup, and Lifecycle Management

Create a storage account and configure high availability.

In Azure Portal, search for "storage account"

Select "Storage account"

Select "Create"

*Insert Resource Group previously created name
*

*Insert Storage account name
*

Select "Redundancy" to be Geo-redundant storage (GRS)

Select "Review + Create"

Check Validation and select "Create"

Create a storage container, upload a file, and restrict access to the file.

In the storage account, select "Data storage" and select "containers"

Select "+ Container"

Name the container

Ensure access level is private

Select "Create"

Upload File to Container
Select Container

Select "Upload"

Select File and upload

Select the file and copy file URL to check if file will be accessed

Paste URL to a new tab, verify file doesn't display

An external partner requires read and write access to the file for at least the next 24 hours. Configure and test a shared access signature (SAS)

Select the uploaded blob file and click the "Generate SAS tab"

Ensure the partner has only read permission

Set start/expiry time for the next 24 hours

Select "Generate SAS token and URL"

Copy the Blob SAS URL to a new browser tab to verify accessibility, file should be accessible.

Configure storage access tiers and content replication.
Return to storage account

Notice the default access tier is set to hot

In the Data Management section

Select "Lifecycle management"

Select "Add a rule"

Add Rule name

Select Rule scope to apply rule to all blobs in your storage account

Select "Next"

Select "Last modified"

Set days

Select "Move to cool storage"

Add rule

The public website files need to be backed up to another storage account

Create a new container

Select "Create"

Navigate to another storage account, click on "Data management"

Select "Object replication"

Select "Create replication rules"

Set Destination storage account to the Private storage previously created

Set Source Container as mainpublic and Destination Container as backup

Select "Create"

Comments

[疏影]

Lifecycle-aware secure storage is the right framing. Two Windows-side patterns we use that complement this:

• Once the storage backend is picked (Nextcloud / OwnCloud / SMB NAS / S3-compatible bucket), mount it as a drive letter on Windows so the team sees files in Explorer. ScsDriver handles SMB / S3 / SFTP / WebDAV so the same mount table also carries any other backend the company standardized on. Auto-reconnect across sleep / VPN / 网卡切换 is what makes the per-user drive letter stick across a normal workday.
• For the lifecycle piece specifically, having the storage tier visible as a drive lets the admin run cleanup scripts (Get-ChildItem -Recurse on old files) without a custom CLI. Same data, same mount, different admin workflow.

Operational notes for secure cloud storage at small-team scale:

• Restricted access works at the share / container / bucket boundary; pick a model that matches the access pattern (per-user vs per-team).
• For SMB targets, mind the 'multiple connections to server' default on Windows; using distinct service accounts per destination side-steps it.
• If you're also piping this into a NAS, audit the actual mount table quarterly — orphaned drive letters from old employees are a quiet leak path. Thanks for the writeup.