I could not find any code sample for revoking the created Shared Access Signature access on blob, can anyone provide me link or reference for removing the Shared Access Signature access created earlier.
Even if shared access signature (SAS) is based on a stored access policy (SAP), you can only revoke SAP, not individual SAS.
Azure Storage security guide has good details:
https://learn.microsoft.com/en-us/azure/storage/common/storage-security-guide#revocation
SAS not based on SAP - can't be revoked:
If you are using ad hoc URIs, you have three options. You can issue SAS tokens with short expiration policies and wait for the SAS to expire. You can rename or delete the resource (assuming the token was scoped to a single object). You can change the storage account keys. This last option can have a significant impact, depending on how many services are using that storage account, and probably isn't something you want to do without some planning.
SAS based on SAP - can be revoked by revoking SAP:
If you are using a SAS derived from a Stored Access Policy, you can remove access by revoking the Stored Access Policy – you can just change it so it has already expired, or you can remove it altogether. This takes effect immediately, and invalidates every SAS created using that Stored Access Policy. Updating or removing the Stored Access Policy may impact people accessing that specific container, file share, table, or queue via SAS, but if the clients are written so they request a new SAS when the old one becomes invalid, this will work fine.
Best practice:
Because using a SAS derived from a Stored Access Policy gives you the ability to revoke that SAS immediately, it is the recommended best practice to always use Stored Access Policies when possible.
Context
MSFT Azure storage account (live version as of 2019-11-26)
MSFT Azure storage permissions as managed by Shared Access Signature (SAS)
Problem
User user145610 wants to immediately revoke a deployed SAS
(e.g., because SAS allows authentication into Blob Storage, and the SAS has been compromised, requiring immediate remediation to prevent unauthorized data breach)
Workarounds already mentioned
Other answers already appear in this thread discussing the use of Shared Access Policy (aka Stored Access Policy) (SAP)
SAS generated based on SAP has limitations, only five SAPs can be attached to a a blob container within a storage account.
Workaround: Regenerating Account Keys
One workaround that does not appear in this thread (at the time of this posting) is the ability to regenerate the account key used to originally create the SAS, as documented in one of the links in the see also section of this answer.
Regenerating an account key will cause all application components using that key to fail to authorize until they're updated to use either the other valid account key or the newly regenerated account key. Regenerating the account key is the only way to immediately revoke an ad hoc SAS.
Consequently, one potential workaround is to generate and deploy SASs based on the secondary account key, and have the expectation that you will routinely regenerate the secondary account key whenever immediate revocation of one or more SASs becomes necessary.
(Obviously, this is not a desirable circumstance where many SAS tokens are deployed and dependent on the secondary account key, because they will all be rendered invalid upon regeneration of the key)
Solution
The inability to deploy a large number of SAPs, combined with the potentially unfavorable side-effects of having to regenerate account keys suggests that a potential solution is to re-engineer the architecture of your project to use ActiveDirectory for controlling authorization and access control, and the generation of SAS tokens.
SASs based on SAPs may be better suited for cases where there are only few clients requiring access, and the probability of the SASs getting compromised is extremely low.
As of this writing, MSFT Azure storage supports the generation and use of SAS tokens based on ActiveDirectory accounts.
See also
How many access policies can I create and add on the same one Azure container?
https://learn.microsoft.com/en-us/azure/storage/common/storage-auth
https://learn.microsoft.com/en-us/rest/api/storageservices/create-service-sas#revocation-of-a-sas
https://learn.microsoft.com/en-us/azure/storage/common/storage-sas-overview#types-of-shared-access-signatures
https://learn.microsoft.com/en-us/rest/api/storageservices/create-user-delegation-sas
https://learn.microsoft.com/en-us/azure/storage/common/storage-sas-overview#best-practices-for-using-sas
You can't revoke a shared access signature unless it is based on a stored access policy. See https://learn.microsoft.com/en-us/rest/api/storageservices/define-stored-access-policy#modifying-or-revoking-a-stored-access-policy for more information:
To revoke a stored access policy, you can either delete it, or rename
it by changing the signed identifier. Changing the signed identifier
breaks the associations between any existing signatures and the stored
access policy. Deleting or renaming the stored access policy
immediately effects all of the shared access signatures associated
with it.
Came across this topic too. As per highlighted by #IlyaBerdichevsky on the top, Best practice is to use a SAS derived from a Stored Access Policy.
TLDR;
Watch this youtube tutorial
(Step by step) How to create a SAS Derived from Store Access Policy?
First, setup Stored Access Policy
Go to your Azure Storage Resource
Click on containers (left panel under Data Storage), choose your container (because different container may setup different policy).
Click on Access Policy (left panel under Settings)
Click on Add policy
Here you may specify the desired policy you want (Sample in screenshot)
Click on OK
Tap on Save button on top (it reflects quickly actually, although it claimed to take about 30 seconds)
Second, generate SAS based on the SAP (Stored Access Policy) created
Back to Azure Storage Resource
Click on Storage Explorer (preview)
In my case I'm using Blob container, so I'll expand my blob container and click on the container I want. You shall see your file inside the container, once you've selected.
Right click on the file, click on Get Shared Access Signature.
Select the policy you have just created under the dropdown.
Tap on create
DONE! You've gotten your token now :)
How to revoke/extend the SAS token created for client?
Back to the policy you have setup
Update the expiry time
Save
TAAA-DAHH! Same link with the SAS token should expired/work now.
I had the same problem and this is how I solved it:
The communication between the redacted service and Azure Blob Storage is done through the SDK v8.0.
Related
In order to connect to Azure Shared Storage(in particularly File Share) to perform tasks like copying/removing/modifying files from remote to azure storage, we need either SAS(Shared Access Signature) or Active Directory Settings Enabled (and then assign roles based on requirement).
I wanted to implement the access using SAS approach, I tried generating SAS from UI, tried generating SAS by making use of Access Keys(Present Inside Storage Account - Confidential and most important key for storage account) both worked. But UI approach isn't conducive in my case, and Access token can't be given to anyone apart from the administrator.
So is there a way to generate SAS using Azure AD credentials or some service where we can create an account and password/key and that account can be used to create SAS token via curl(REST call) and not generating SAS via access keys(admin key).
The tricky part is to let your users create a sas token for the file share without granting them permissions on the whole storage account.
You can use a middle tier application that creates the SAS token and allow the users to use that app. An azure function with an HTTP trigger can be used for example. You grant the azure function access to the storage account using a Managed Service Identity and secure the access to the Azure function either with Active Directory or a function key, that you distribute to your users.
You can try with this approach:
A SAS token for access to a container, directory, or blob may be secured by using either Azure AD credentials or an account key.
Microsoft recommends that you use Azure AD credentials when possible as a security best practice, rather than using the account key, which can be more easily compromised. When your application design requires shared access signatures, use Azure AD credentials to create a user delegation SAS for superior security.
Create a User delegation SAS
Generate a User Delegation Key:
POST https://myaccount.blob.core.windows.net/?restype=service&comp=userdelegationkey
Is there a way to get Azure to reject SAS (Shared Access Signatures) tokens that are NOT issued from a Stored Access Policy? In other words, I'd like to prevent Application Services from using ad-hoc access policies. That way, we not only manage the policies centrally, but we can quickly and with little impact revoke them.
I wish I could do all the reviews myself to ensure nobody does anything like that in the code, but I don't and not everyone does thorough code reviews. So I want to save us from ourselves.
The only way is change the account key.
As per this doc:
A shared access signature URI is associated with the account key used to create the
signature, and the associated stored access policy (if any). If no stored access policy is
specified, the only way to revoke a shared access signature is to change the account key.
For Azure there is an API Endpoint that allows to regenerate key.
The endpoint looks like
POST https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Storage/storageAccounts/{accountName}/regenerateKey?api-version=2017-06-01
Documentation states
When you have code that needs to access or modify resources, you must set up an Azure Active Directory (AD) application.
However, when I use it (i.e. create POST request) I'm getting error Authentication failed. The 'Authorization' header is missing. I tried to follow this tutorial and I did all the steps except Assign application to role What role should I select to be able to regenerate password? How do I do that? Am I getting this correct?
I think you could use Storage Account Key Operator Service Role.
The Storage Account Key Operators are allowed to list and regenerate keys on Storage Account.
Storage Account Contributor: Lets you manage storage accounts, but not access to them.
Contributor:Lets you manage everything except access to resources.
If you have some more action to operate, you could use more powerful roles, but if you only want to regenerate key, I suggest that you could use Storage Account Key Operator Service Role.
I'm developing a web application which users can upload their files and each user can set permissions for the uploaded file to access to other users.
I want to use Azure Blob Storage of Azure File Storage for the uploaded files to be saved.
I need to check and validate the uploaded files before saving them, though users should upload their files on web server and then the web server will validate the files and save them to Azure Storage using Access Key.
To get accessed the files using explained method in SAS - Shared Access Signatures, Part 1: Understanding the SAS model, I want to create account SAS and generate URL on the web server and then user can download their accessible files directly from the Azure Storage.
Here is the access model (just to read data):
And here is the sample SAS url:
https://myaccount.blob.core.windows.net/sascontainer/sasblob.txt?sv=2015-04-05&st=2015-04-29T22%3A18%3A26Z&se=2015-04-30T02%3A23%3A26Z&sr=b&sp=rw&sip=168.1.5.60-168.1.5.70&spr=https&sig=Z%2FRHIX5Xcg0Mq2rqI3OlWTjEg2tYkboXr1P9ZUXDtkk%3D
But, what if user share the URL with anonymous users directly: they can access the file before expiration date, or maybe they can use the URL to access other files (or not?).
Can account SAS limit access to specific files or folders?
Can I expire the SAS server side?
What would be the best solution on this scenario?
Account SAS is for account level, Azure File Storage supports file share level SAS or file level SAS as well, please use them instead.
To revoke SAS in server side, you'll need to set up Shared Access Policy for them. By removing the corresponding Shared Access Policy, the related SAS can be revoked. However, server can only store 5 Shared Access Policies at most, which may not satisfy your requirement. What's more, Shared Access Policy doesn't support Account SAS currently. Anyway, technically there is still one way to revoke ad hoc SAS, but I don't think it's a valid option: to regenerate the corresponding storage account key on SAS Provider Service which was used to generate the ad hoc SAS.
In my opinion, SAS is not the good solution for your scenario, since SAS is designed for sharing links in plain text among anonymous users. In order to achieve your requirement, you need to set up your own authentication and authorization on your website. All the users must upload/download the files via your website, and Azure Storage is just the storage back end of your website, which shouldn't be exposed to users directly.
We can use SAS to set the file permission, use SAS policy to set the start data and expire date. However if you have very complex logic about the file. I would suggest you use role permission to do this.
We are using MS Azure and developing SAAS based Multi-Tenant Application.
For each Tenant we have BLOB Container Private and assigned to each Tenant.
Also there is a requirement that Client can share files with other client users.
Eg.
Client C1 has Container "C1" and it has files "C1f1", "C1f2" and "C1f3".
User U1 and U2. U1 has access permission for C1f1 and U2 has C1f2 access only.
How can we do this in MS Azure Permission or Security? This needs to be done RUNTtime?
Please suggest How can this be done - What is BEST way to do
I believe you have two options.
Either generate and use SAS tokens per client/user with the right permissions. With a SAS token you can provide access to a specific resource up to a specific point in time. The disadvantage is that SAS tokens cannot be revoked on a per token basis. You can only revoke all tokens by rolling the storage access key that was used to generate the SAS token. Another disadvantage is that you have to provide a SAS token per item you want to grant access to. (For more info see also https://azure.microsoft.com/nl-nl/documentation/articles/storage-dotnet-shared-access-signature-part-1/)
Create a Web Service that encapsulates the Azure storage and serves files to your customers. In this service implement authorization management yourself.