Storage Credentials
When you attach your Azure Blob container or S3 bucket, BYOVault needs credentials that can write to it. Here's exactly how those are held.
Where they live
The credentials themselves — an Azure storage connection string, or an AWS access key pair — are stored as a secret in Azure Key Vault, as JSON. BYOVault’s own database only stores the storage type, the container/bucket name, and the name of the Key Vault secret that holds the actual credentials — never the credentials in plaintext in the application database.
What BYOVault does with them
These credentials are used to write encrypted backup data to, and read it back from, the storage account you specified. If you provision a retention vault on the same cloud provider as your primary storage (both AWS S3, or both Azure Blob), BYOVault also uses them to let files move directly between your two accounts without passing through BYOVault’s own servers at all — see below for exactly what that involves on each provider.
Same-provider retention vault moves
When old files move into your locked retention vault, BYOVault can ask your cloud provider to copy them directly, account to account, entirely on the provider’s own infrastructure — a real performance and cost optimization, since the file’s content never has to travel through BYOVault’s own network at all. This only applies when your primary storage and your vault use the same cloud provider; a primary/vault pair split across providers (one on AWS, one on Azure) always moves files the original way, through BYOVault’s own servers.
The two providers need genuinely different setup to make this possible, and each is disclosed here plainly rather than left implicit:
- AWS S3: once, at the moment your vault is locked, BYOVault adds one statement to your primary bucket’s own bucket policy, granting your vault account’s AWS identity read-only access (
s3:GetObject,s3:GetObjectVersion) to that bucket. This statement is scoped exactly to your vault account and is the only change BYOVault ever makes to your bucket policy — any other statements already on your policy are read first and left untouched. You can see this statement yourself at any time in your AWS console, under your primary bucket’s Permissions tab; it carries a Sid beginningbyovault-vault-read-so it’s easy to identify. - Azure Blob: no standing grant is added anywhere. Each individual file copy is authorized by a short-lived (15-minute), read-only SAS token minted fresh for that one file, signed with your primary account’s own credential — nothing persists in your Azure account before, during, or after the copy.