GA: Azure Storage updating client-side encryption in SDK to address security vulnerability
Azure Storage is announcing the release of a new version of the client-side encryption feature (referred to as “v2”) in the Azure Storage SDKS to mitigate the CBC mode vulnerability. Given this vulnerability in CBC, v2 will use AES-GCM for client-side encryption instead of CBC.Preview: Azure Storage updating client-side encryption in SDK to address security vulnerability
Azure Storage is announcing the release of a new version of the client-side encryption feature (referred to as “v2”) in the Azure Storage SDKS to mitigate the CBC mode vulnerability. Given this vulnerability in CBC, v2 will not use CBC mode for client-side encryption instead use
Can an azure blob with malware infect other blobs in the storage account?
Hi, I need to know whether it can be infected to other blobs or files if I accidently uploaded a malware into azure storage account or all the blobs are isolated from each other. If it can be infected, does it infect the blob/files only within the container or to the entire storage account?
Query Storage accounts for type of storage and access tier
Hello Community, I have received a task (for Auditing) to find Storage accounts having storage type as "Queue". And also to find blobs with access tier as "Archive" . we have hundreds of storage accounts and each having lots of blobs and contents. Is there any way i can achieve this using resource graph explorer or any something else. On PowerShell i tested using Get-AzStorageAccount | Get-AzStorageContainer | Get-AzStorageBlob | where where{$_.AccessTier -eq "Archive"} this is working for scenarios where storage accounts are less, but it stucks where the number is too big, any help will be appreciated. Thank You PS - i am relatively new to Azure and scripting
Error : Azure Storage - SFTP(preview)
We are using Azure Storage - SFTP(preview) service to upload files to Azure Blob Containers, We are able to upload multiple files simultaneously using the SFTP client. But we are experiencing inconsistency in transferring files to SFTP account as some of these files are failing - we are getting ‘Invalid block size’ error from Azure blob storage. Please let us know what may be causing these issue as we have to manually copy/reinitiate upload to SFTP for the failed files.
User delegation SAS for Azure Tables, Azure Files, and Azure Queues is now Generally Available
We’re excited to announce that user delegation (UD) SAS is now generally available for Azure Tables, Azure Files, and Azure Queues in all regions. User delegation SAS is already available for Azure Blobs, and we are now extending support to Azure Tables, Azure Files, and Azure Queues. This will allow users to create a more secure SAS token than account or service SAS by tying the SAS token to the creator’s identity. UD SAS extends Entra ID and Azure role-based access control (RBAC) for Azure Storage, meaning lower-privileged users and services can now delegate subsets of their access to clients, using a pre-authorized URL. Clients retrieve a user delegation key tied to their Entra ID account and then use it to create SAS tokens granting a subset of their own access rights. This extension of User Delegation Key based SAS enables delegated access at multiple granularities—including table, table entity, queue, queue message, file share, and individual file. Pricing and availability There is no additional cost for user delegation SAS. Pricing is based on the standard read/write transaction costs for your storage account type. To learn more, please see Azure Storage Pricing. UD SAS for Azure Tables, Azure Files, and Azure Queues is generally available in all regions. This capability is available via REST APIs, SDKs, PowerShell, and CLI experiences. Note: this feature is only available in SDKs, PowerShell, and CLI for Azure Files and Azure Queues, but available in all three services for REST APIs. Getting Started Getting started is simple: All general-purpose v2 storage accounts are eligible to use UD SAS. There is no account setting that must be enabled to use this feature. Perform the following steps in the create a user delegation SAS documentation to generate and use a UD SAS token: Ensure you have the correct RBAC roles assigned to create a user delegation key. These roles will include the Storage <Service> Data Contributor and Storage <Service> Delegator (replace Service with the respective service you are using) Get a user delegation key (instructions here) Create the user delegation SAS token (instructions here. Note the steps are similar for each service, but permissions vary slightly from service to service) Share the SAS token to the application/user intended to access storage data Tokens should be passed within applications automatically or shared via key vault for best practice Feedback If you have questions or feedback, please fill out this feedback form. If you need help, create a support request.Introducing Cross Resource Metrics and Alerts Support for Azure Storage
Aggregate and analyze storage metrics from multiple storage accounts in a single chart. We’re thrilled to announce a highly requested feature: Cross Resource Metrics and Alerts support for Azure Storage! With this new capability, you can now monitor and visualize metrics across multiple storage accounts in a single chart and configure alerts across multiple accounts — within the same subscription and region. This makes managing large fleets of storage accounts significantly easier and more powerful. What’s New Cross Resource Metrics Support Visualize aggregated metric data across multiple storage accounts. Break down metrics by individual resources in a sorted and ordered way. Cross Resource Alerting Support Create a single alert rule that monitors a metric across many storage accounts and triggers an action when thresholds are crossed on any resource. Full Metric Namespace Support Works across Blob, File, Table, and Queue metric namespaces. All existing storage metrics are supported for cross resource visualization and alerting. Why This Matters Centralized Monitoring for Large Environments Manage and monitor dozens (or hundreds) of storage accounts at once with a unified view. Fleet-wide Alerting Set up a single alert that covers your whole storage fleet, ensuring you are quickly notified if any account experiences performance degradation or other issues. Operational Efficiency Helps operations teams scale monitoring efforts without needing to configure and manage separate dashboards and alerts for each account individually. How To Get Started Step 1: Create a Cross Resource Metrics Chart Go to Azure Monitor -> Metrics. Scope Selection: Under Select a scope, select the same Metric Namespace (blob/file/queue/table) for multiple Storage Accounts from the same Subscription and Region. Click Apply. In the below example, two storage accounts have been selected for metrics in the blob metric namespace. Configure Metric Chart: Select a Metric (e.g., Blob Capacity, Transactions, Ingress) Aggregation: By default, a Split by clause on ResourceId is applied to view individual account breakdowns. Or view aggregated data across all selected accounts by removing the Split by clause. Example As another example, lets monitor total transactions across storage accounts on the Hot tier to view aggregate or per-account breakdown in a single graph. From the same view, select the Transactions metric instead. Select 5 storage accounts by using the Add Filter clause and filtering by the ResourceId property. Add another filter and select a specific tier, say Hot. This will show aggregated transactions on data in the Hot tier per minute across all selected storage accounts. Select Apply Splitting and select ResourceId to view an ordered breakdown of transactions per minute for all the Storage accounts in scope. In this specific example, only 4 storage accounts are shown since 1 storage account is excluded based on the Tier filter. Step 2: Set Up Cross Resource Alert Rules Click on New alert rule from the chart view shown above in order to create an alert that spans the 5 storage accounts above and get alerted when any account breaches a certain transactions limit over a 5 minute period. Configure required values for the Threshold, Unit and Value is fields. This defines when the alert should fire (e.g., Transactions > 5000) Under the Split by dimensions section, ensure that the Microsoft.ResourceId dimension is not included. Under Actions, attach an Action Group (Email, Webhook, Logic App, etc.). Review and Create. Final Thoughts Cross Resource Metrics and Alerts for Azure Storage makes monitoring and management at scale much more intuitive and efficient. Whether you're overseeing 5 storage accounts or 500, you can now visualize performance and respond to issues faster than ever. And you can do it for metrics across multiple storage services including blobs, queues, files and tables! We can't wait to hear how you use this feature! Let us know your feedback by commenting below or visiting Azure Feedback.Generally Available: Restrict usage of user delegation SAS to an Entra ID identity
Shared access signatures (SAS) grant time-bound, scoped access to Azure Storage resources without sharing account keys. Over time, Azure Storage has continued to strengthen SAS security, moving from account keys to user delegation (UD) SAS secured by Microsoft Entra ID. Today, we’re taking the next step forward by announcing general availability for user-bound user delegation SAS, an extension of UD SAS that ensures a SAS token can only be used by a specific Entra ID identity. This new capability helps customers significantly reduce the risk of unintended access while preserving the flexibility of SAS. UD SAS is an existing feature which utilizes Entra ID and Azure role-based access control (RBAC). Users retrieve a user delegation key tied to their Entra ID account and then use it to create SAS tokens granting a subset of their own access rights. The resulting token can be traced to the delegator and can only be valid for up to 7 days. User-bound UD SAS is an extension of user delegation (UD) SAS which allows users to create a more secure SAS token by restricting the usage of the SAS token to an end user identity. The delegator specifies the Entra identity (security principal) of the end user in the SAS token and the end user needs to authenticate to Entra ID to use the token. The end user can either be in the same tenant or a different tenant as the delegator. Pricing and availability There is no additional cost for user-bound user delegation SAS. Pricing is based on the standard read/write transaction costs for your storage account type. To learn more, please see Azure Storage Pricing. User-bound user delegation SAS is available in all public regions. It is available via REST APIs, SDKs, PowerShell, CLI, and Portal. Getting started Getting started is simple: User-bound user delegation SAS is available on all GPv2 storage accounts in public regions. If the end user of the SAS token is in a different tenant, the allowCrossTenantDelegationSas setting must be enabled on the storage account. If you are not planning on using this feature cross-tenant, the account setting can remain disabled. Perform the following steps in the create a user delegation SAS documentation to generate and use a user-bound UD SAS token: Ensure you have the correct RBAC roles assigned to the delegator to create a user delegation key. These roles will include the Storage <Service> Data Contributor and Storage <Service> Delegator (replace Service with the respective service you are using). Here are all of the applicable roles for each service: Azure Blob Azure Files Azure Tables Azure Queues Storage Blob Data Contributor Storage Files Data Contributor Storage Table Data Contributor Storage Queue Data Contributor Storage Blob Delegator Storage Files Delegator Storage Table Delegator Storage Queue Delegator Get a user delegation key (instructions here) Get the OAuth object ID and tenant ID from your end user. They will have to get these IDs (instructions here) and provide them to you. Create the user-bound user delegation SAS token (instructions here. Note that the steps are the same as for a normal UD SAS token; you will just have to specify the end user and tenant if applicable). Share the SAS token to the application/user intended to access Azure Storage. Tokens should be passed within applications automatically or shared via key vault for best practice. Feedback If you need help, create a support request.
