Move sections

Author: pauljewellmsft

articles/storage/common/authorize-data-access.md

@@ -20,30 +20,6 @@ Each time you access data in your storage account, your client application makes
 
 ## Authorization for data operations
 
-The following section briefly describes the authorization options for Azure Storage:
-
-- **Shared Key authorization**: Applies to blobs, files, queues, and tables. A client using Shared Key passes a header with every request that is signed using the storage account access key. For more information, see [Authorize with Shared Key](/rest/api/storageservices/authorize-with-shared-key/).
-
-    Microsoft recommends that you disallow Shared Key authorization for your storage account. When Shared Key authorization is disallowed, clients must use Microsoft Entra ID or a user delegation SAS to authorize requests for data in that storage account. For more information, see [Prevent Shared Key authorization for an Azure Storage account](shared-key-authorization-prevent.md).
-
-- **Shared access signatures** for blobs, files, queues, and tables. Shared access signatures (SAS) provide limited delegated access to resources in a storage account via a signed URL. The signed URL specifies the permissions granted to the resource and the interval over which the signature is valid. A service SAS or account SAS is signed with the account key, while the user delegation SAS is signed with Microsoft Entra credentials and applies to blobs only. For more information, see [Using shared access signatures (SAS)](storage-sas-overview.md).
-
-- **Microsoft Entra integration**: Applies to blob, queue, and table resources. Microsoft recommends using Microsoft Entra credentials with managed identities to authorize requests to data when possible for optimal security and ease of use. For more information about Microsoft Entra integration, see the articles for [blob](../blobs/authorize-access-azure-active-directory.md), [queue](../queues/authorize-access-azure-active-directory.md), or [table](../tables/authorize-access-azure-active-directory.md) resources.
-
-    You can use Azure role-based access control (Azure RBAC) to manage a security principal's permissions to blob, queue, and table resources in a storage account. You can also use Azure attribute-based access control (ABAC) to add conditions to Azure role assignments for blob resources. 
-
-    For more information about RBAC, see [What is Azure role-based access control (Azure RBAC)?](../../role-based-access-control/overview.md).
-
-    For more information about ABAC, see [What is Azure attribute-based access control (Azure ABAC)?](../../role-based-access-control/conditions-overview.md). To learn about the status of ABAC features, see [Status of ABAC condition features in Azure Storage](../blobs/storage-auth-abac.md#status-of-condition-features-in-azure-storage).
-
-- **Microsoft Entra Domain Services authentication**: Applies to Azure Files. Azure Files supports identity-based authorization over Server Message Block (SMB) through Microsoft Entra Domain Services. You can use Azure RBAC for granular control over a client's access to Azure Files resources in a storage account. For more information about Azure Files authentication using domain services, see [Overview of Azure Files identity-based authentication options for SMB access](../files/storage-files-active-directory-overview.md).
-
-- **On-premises Active Directory Domain Services (AD DS, or on-premises AD DS) authentication**: Applies to Azure Files. Azure Files supports identity-based authorization over SMB through AD DS. Your AD DS environment can be hosted in on-premises machines or in Azure VMs. SMB access to Files is supported using AD DS credentials from domain joined machines, either on-premises or in Azure. You can use a combination of Azure RBAC for share level access control and NTFS DACLs for directory/file level permission enforcement. For more information about Azure Files authentication using domain services, see the [overview](../files/storage-files-active-directory-overview.md).
-
-- **Anonymous read access**: Applies to blob resources. This option is not recommended. When anonymous access is configured, clients can read blob data without authorization. We recommend that you disable anonymous access for all of your storage accounts. For more information, see [Overview: Remediating anonymous read access for blob data](../blobs/anonymous-read-access-overview.md).
-
-- **Storage Local Users**: Applies to blobs with SFTP or files with SMB. Storage Local Users support container level permissions for authorization. See [Connect to Azure Blob Storage by using the SSH File Transfer Protocol (SFTP)](../blobs/secure-file-transfer-protocol-support-how-to.md) for more information on how Storage Local Users can be used with SFTP.
-
 The following section describes authorization support and recommendations for each Azure Storage service.
 
 ### [Blobs](#tab/blobs)
@@ -100,6 +76,30 @@ The following table provides information about supported authorization options f
 
 ---
 
+The following section briefly describes the authorization options for Azure Storage:
+
+- **Shared Key authorization**: Applies to blobs, files, queues, and tables. A client using Shared Key passes a header with every request that is signed using the storage account access key. For more information, see [Authorize with Shared Key](/rest/api/storageservices/authorize-with-shared-key/).
+
+    Microsoft recommends that you disallow Shared Key authorization for your storage account. When Shared Key authorization is disallowed, clients must use Microsoft Entra ID or a user delegation SAS to authorize requests for data in that storage account. For more information, see [Prevent Shared Key authorization for an Azure Storage account](shared-key-authorization-prevent.md).
+
+- **Shared access signatures** for blobs, files, queues, and tables. Shared access signatures (SAS) provide limited delegated access to resources in a storage account via a signed URL. The signed URL specifies the permissions granted to the resource and the interval over which the signature is valid. A service SAS or account SAS is signed with the account key, while the user delegation SAS is signed with Microsoft Entra credentials and applies to blobs only. For more information, see [Using shared access signatures (SAS)](storage-sas-overview.md).
+
+- **Microsoft Entra integration**: Applies to blob, queue, and table resources. Microsoft recommends using Microsoft Entra credentials with managed identities to authorize requests to data when possible for optimal security and ease of use. For more information about Microsoft Entra integration, see the articles for [blob](../blobs/authorize-access-azure-active-directory.md), [queue](../queues/authorize-access-azure-active-directory.md), or [table](../tables/authorize-access-azure-active-directory.md) resources.
+
+    You can use Azure role-based access control (Azure RBAC) to manage a security principal's permissions to blob, queue, and table resources in a storage account. You can also use Azure attribute-based access control (ABAC) to add conditions to Azure role assignments for blob resources. 
+
+    For more information about RBAC, see [What is Azure role-based access control (Azure RBAC)?](../../role-based-access-control/overview.md).
+
+    For more information about ABAC, see [What is Azure attribute-based access control (Azure ABAC)?](../../role-based-access-control/conditions-overview.md). To learn about the status of ABAC features, see [Status of ABAC condition features in Azure Storage](../blobs/storage-auth-abac.md#status-of-condition-features-in-azure-storage).
+
+- **Microsoft Entra Domain Services authentication**: Applies to Azure Files. Azure Files supports identity-based authorization over Server Message Block (SMB) through Microsoft Entra Domain Services. You can use Azure RBAC for granular control over a client's access to Azure Files resources in a storage account. For more information about Azure Files authentication using domain services, see [Overview of Azure Files identity-based authentication options for SMB access](../files/storage-files-active-directory-overview.md).
+
+- **On-premises Active Directory Domain Services (AD DS, or on-premises AD DS) authentication**: Applies to Azure Files. Azure Files supports identity-based authorization over SMB through AD DS. Your AD DS environment can be hosted in on-premises machines or in Azure VMs. SMB access to Files is supported using AD DS credentials from domain joined machines, either on-premises or in Azure. You can use a combination of Azure RBAC for share level access control and NTFS DACLs for directory/file level permission enforcement. For more information about Azure Files authentication using domain services, see the [overview](../files/storage-files-active-directory-overview.md).
+
+- **Anonymous read access**: Applies to blob resources. This option is not recommended. When anonymous access is configured, clients can read blob data without authorization. We recommend that you disable anonymous access for all of your storage accounts. For more information, see [Overview: Remediating anonymous read access for blob data](../blobs/anonymous-read-access-overview.md).
+
+- **Storage Local Users**: Applies to blobs with SFTP or files with SMB. Storage Local Users support container level permissions for authorization. See [Connect to Azure Blob Storage by using the SSH File Transfer Protocol (SFTP)](../blobs/secure-file-transfer-protocol-support-how-to.md) for more information on how Storage Local Users can be used with SFTP.
+
 [!INCLUDE [storage-account-key-note-include](../../../includes/storage-account-key-note-include.md)]
 
 ## Next steps