Best practices for Azure Role-Based Access, Azure Functions, and Azure Storage Keys
To accommodate organizational needs, Azure offers a wide range of configurable security options to developers and security operations personnel. Customers must be aware of various security best practices and the shared responsibility model throughout the software development lifecycle.
Customers are in charge of setting up and managing applications, identities, and data, so this is crucial when deploying Azure Functions and providing Azure Role Based Access Control. Customers may give permissions that are too general. When this occurs, there is a chance that the tenant of the customer could misuse these permissions to access more resources.
The Microsoft Security Response Center looked into one such issue that Orca Security recently reported and found it to be unrelated to security. To help customers deploy environments with the least amount of privilege and defense-in-depth to be more resilient against attackers, the situation, however, called for discussion and improvement.
The Azure Functions team intends to update the way functions client tools interact with storage accounts as part of ongoing experience improvements. Changes to better support scenarios involving identity are part of this. Identity will replace shared key authorization as the default mode for AzureWebJobsStorage once identity-based connections are widely available and the new experiences have been verified.  ,
Customers should also read the instructions below to make sure that their environments are as easily set up as possible to meet their organizational needs.
In-depth Azure Functions and Storage Authorization
Storage is used by Azure Functions for a variety of functions. General runtime behaviors like handling trigger checkpointing data and distributed lock management use the AzureWebJobsStorage connection. Depending on the deployment method chosen, Azure Functions code may be stored in the account specified by the AzureWebJobsStorage connection.
Most setups do not default to this, and Functions provides a variety of application code deployment options, including referencing content that is stored elsewhere. Although there is a preview of identity-based connections for AzureWebJobsStorage, the connection by default uses the storage account connection string.  ,
Customers might also want to give users access to their environment in addition to using the default storage account connection string. According to the shared responsibility model, the cloud customer is responsible for access management. When creating role assignments, it’s crucial to choose the right scope while still adhering to security principles like least privilege. Users and apps should n’t have more access than is absolutely necessary. Through privileged identity management, Azure also provides features for granting restricted access.  , ++
By default, only the person who opened the storage account and any inherited owners have access to listKeys. Microsoft advises giving users granular access to read the contents of storage accounts by using built-in functions like Storage Blob Data Reader or Storage File Data SMB Share Reader.
Permission to modify content or list storage account keys is not one of these roles. Like any access credential, storage account keys should be carefully protected because they give you complete access to all of the data and configurations in your account. Microsoft may be granted additional built-in roles. excessive storage, storage accounts, list keys, and action permission for users who only need read access.
Customers could still use Azure Monitor to learn more about the data plane actions taken against that storage account even if excessive privileges were granted and then used. Which users have accessed the shared storage keys can be tracked using the Activity Log, which describes control plane operations. All storage accounts by default have activity logs enabled.
Customers can accomplish this by looking for “listKeys” in the Azure Function storage account. Azure Monitor can also enable and configure resource logs to detect any changes to the storage account’s contents. Customers are strongly advised to set up activity and resource logs on their storage accounts and regularly check them for unusual activity.
Additionally, you can identify clients who are using shared keys or shared access signatures ( SAS ) to authorize storage requests and monitor how clients authorize access to storage accounts.
The Azure Functions team intends to update the way functions client tools interact with storage accounts as part of ongoing experience improvements. Changes to better support scenarios involving identity are part of this. Identity will take over as the default mode for AzureWebJobsStorage once identity-based connections are widely available and the new experiences have been verified.
Additionally, users will be able to enable” StorageWrite” resource logging for storage accounts made during those experiences in the future thanks to Azure Functions clients. To better clarify best practices for setting up storage account access for users with the fewest privileges, we have also updated the documentation for Azure Functions.
Additionally, Azure Storage keeps investing in security, offering full support for identity-based authorization. Role-based access control ( RBAC ), including role-assignment conditions with Azure ABAC, is fully supported by Blob Storage. To easily restrict access with the fewest privileges, we offer a wide range of built-in roles.
Azure Files now supports OAuth over REST and Azure AD Kerberos over SMB. Additionally, this will make it possible to support identity-based authorization for Azure portal file access. In order to promote the use of role-based access, we are also planning guidance and support so that new storage accounts can have shared key and shared access signature ( SAS ) authorization disabled by default . Organizations can use Azure Policy to enforce the use of identity-based authorization for storage in the interim.
Additionally, Microsoft Defender for Cloud ( MDC ) offers improved storage account monitoring, such as the use of compromised authentication tokens, data exfiltration, malware scanning, and automatic discovery of sensitive data to enhance security alerts and nbsp.
Customers ‘ Recommended Actions
We advise customers to use the following methods for user access to storage accounts in order to reduce the overall risk of abuse:
- To guarantee least-privilege access to the storage account, review user permissions. Additionally, you can restrict permissions to the required minimum ( ex. resource group or storage account.
- For access to account keys, keep an eye on Activity Log.
- For storage accounts hosting Azure Functions, enable StorageWrite resource logs and a lifecycle policy to control log retention.
- Consider setting up a storage account specifically for blob storage when storing application code so that you can restrict access.
- MDC for storage accounts should be enabled.
We have updated the existing documentation in addition to the aforementioned suggested actions. Reviewing the updated documents is encouraged for customers:
Storage-related Azure Functions
Conclusion
In conclusion, we are grateful for the chance to look into Orca Security’s findings. To prevent affecting customer data while conducting security research, we strongly advise all researchers to collaborate with vendors in accordance with Coordinated Vulnerability Disclosure ( CVD ) and follow the rules of engagement for penetration testing. The Microsoft Bug Bounty Program is available to researchers who report security concerns to the company’s security response center.
According to Orca’s report, there are still room for us to make improvements to assist customers in setting up their environments correctly and with the least amount of hassle. By using proper RBAC administration and making sure users are given the fewest permissions possible, the risk of these scenarios can be reduced.
Utilizing identity-based connections for AzureWebJobsStorage, which is currently in the preview stage, avoids utilizing over-privileged permissions. Additionally, Azure Storage provides thorough monitoring to spot unauthorized or unusual changes to a storage resource. Additionally, we have updated our existing documentation to reflect our belief that our advice to customers regarding properly defining user privileges for storage account access can be clarified further.
To reduce their exposure to vulnerabilities and other security events, we continue to advise our customers to adhere to security best practices.
Rust is being used to create the Azure IoT Edge Security Daemon.
obtaining an investigative VHD
Part 1 of Azure’s Serial Console Attack and Defense
(Opens in a new browser tab)A new technique to find stolen cookies has been patented by PayPal.
(Opens in a new browser tab)Investigative and incident response scalable infrastructure(Opens in a new browser tab)(Opens in a new browser tab)