Compartir vía


Corrección del acceso de lectura anónimo a datos de blobs (implementaciones de Azure Resource Manager)

Azure Blob Storage admite el acceso de lectura anónimo opcional a contenedores y blobs. Sin embargo, el acceso anónimo puede suponer un riesgo de seguridad. Para mayor seguridad, se recomienda deshabilitar el acceso anónimo. No permitir el acceso anónimo ayuda a evitar las vulneraciones de datos que se producen debido a los accesos anónimos no deseados.

De manera predeterminada, siempre se prohíbe el acceso anónimo a los datos del blob. La configuración predeterminada de una cuenta de almacenamiento de Azure Resource Manager prohíbe a los usuarios configurar el acceso anónimo a contenedores y blobs en una cuenta de almacenamiento. Esta configuración predeterminada impide todo el acceso anónimo a una cuenta de almacenamiento de Azure Resource Manager, independientemente de la configuración de acceso de un contenedor individual.

Cuando no se permite el acceso anónimo para la cuenta de almacenamiento, Azure Storage rechaza todas las solicitudes de lectura anónimas en los datos de blobs. Los usuarios no pueden configurar posteriormente el acceso anónimo para los contenedores de esa cuenta. Los contenedores ya configurados para el acceso anónimo ya no aceptarán solicitudes anónimas.

Advertencia

Cuando se configura un contenedor para el acceso anónimo, cualquier cliente puede leer los datos del mismo. El acceso anónimo supone un posible riesgo de seguridad, por lo que si el escenario no lo requiere, se recomienda no permitirlo para la cuenta de almacenamiento.

Corrección de Azure Resource Manager frente a las cuentas de almacenamiento clásicas

En este artículo se describe cómo usar un marco DRAG (detección, corrección, auditoría y gobernanza) para administrar continuamente el acceso anónimo para las cuentas de almacenamiento que usan el modelo de implementación de Azure Resource Manager. Todas las cuentas de almacenamiento de uso general v2, las cuentas de almacenamiento de blobs en bloques prémium, las cuentas de recursos compartidos de archivos prémium y las cuentas de Blob Storage usan el modelo de implementación de Azure Resource Manager. Algunas cuentas de uso general v1 anteriores y las cuentas de blobs en páginas prémium pueden usar el modelo de implementación clásica.

Si la cuenta de almacenamiento usa el modelo de implementación clásica, se recomienda migrar al modelo de implementación de Azure Resource Manager lo antes posible. Las cuentas de Azure Storage que usan el modelo de implementación clásica se retirarán el 31 de agosto de 2024. Para más información, consulte Las cuentas de almacenamiento clásicas de Azure se retirarán el 31 de agosto de 2024.

Si no puede migrar las cuentas de almacenamiento clásicas en este momento, ahora es cuando debería corregir el acceso anónimo a esas cuentas. Para obtener información sobre cómo corregir el acceso anónimo para las cuentas de almacenamiento clásicas, consulte Corrección del acceso de lectura anónimo a datos de blobs (implementaciones clásicas). Para más información sobre los modelos de implementación de Azure, consulte el artículo acerca de la implementación clásica y con Resource Manager.

Acerca del acceso de lectura anónimo

El acceso anónimo a los datos siempre está prohibido de manera predeterminada. Hay dos configuraciones independientes que afectan al acceso anónimo:

  1. Valor de acceso anónimo para la cuenta de almacenamiento. Una cuenta de almacenamiento de Azure Resource Manager ofrece un valor para permitir o denegar el acceso anónimo a la cuenta. Microsoft recomienda no permitir el acceso anónimo para las cuentas de almacenamiento para lograr una seguridad óptima.

    Cuando se permite el acceso anónimo en el nivel de cuenta, los datos de blobs no están disponibles para el acceso de lectura anónimo a menos que el usuario realice el paso adicional para configurar explícitamente el valor de acceso anónimo del contenedor.

  2. Configure el acceso anónimo del contenedor. De manera predeterminada, el valor de acceso anónimo de un contenedor está deshabilitado, lo que significa que se requiere autorización para cada solicitud al contenedor o sus datos. Un usuario con los permisos adecuados puede modificar el valor de acceso anónimo de un contenedor para habilitar el acceso anónimo solo si se permite el acceso anónimo para la cuenta de almacenamiento.

En la tabla siguiente se resume cómo las dos opciones de configuración afectan al acceso anónimo para un contenedor.

El nivel de acceso anónimo del contenedor se establece en Privado (configuración predeterminada) El nivel de acceso anónimo del contenedor se establece en Contenedor El nivel de acceso anónimo del contenedor se establece en Blob
El acceso público no está permitido para la cuenta de almacenamiento No hay acceso anónimo a ningún contenedor en la cuenta de almacenamiento. No hay acceso anónimo a ningún contenedor en la cuenta de almacenamiento. La configuración de la cuenta de almacenamiento invalida la configuración del contenedor. No hay acceso anónimo a ningún contenedor en la cuenta de almacenamiento. La configuración de la cuenta de almacenamiento invalida la configuración del contenedor.
Se permite el acceso anónimo para la cuenta de almacenamiento No hay acceso anónimo a este contenedor (configuración predeterminada). Se permite el acceso anónimo a este contenedor y sus blobs. Se permite el acceso anónimo a los blobs de este contenedor, pero no al propio contenedor.

Cuando se permite el acceso anónimo para una cuenta de almacenamiento y se configura para un contenedor específico, el servicio acepta una solicitud para leer un blob en ese contenedor que se pasa sin el servicio acepta un encabezado Authorization y los datos del blob se devuelven en la respuesta. Sin embargo, si la solicitud se pasa con un encabezado Authorization, se omite el acceso anónimo en la cuenta de almacenamiento y la solicitud se autoriza en función de las credenciales proporcionadas.

Detección de solicitudes anónimas desde aplicaciones cliente

Al no permitir el acceso de lectura anónimo a una cuenta de almacenamiento, se arriesga a rechazar las solicitudes a contenedores y blobs que están configurados actualmente para el acceso anónimo. Cuando no se permite el acceso anónimo a una cuenta de almacenamiento, se invalida la configuración de acceso de cada contenedor individual de esta. Cuando no se permite el acceso anónimo para la cuenta de almacenamiento, se producirá un error en las futuras solicitudes anónimas a esa cuenta.

Para comprender de qué forma el impedimento del acceso anónimo puede afectar a las aplicaciones cliente, se recomienda habilitar el registro y las métricas de esa cuenta y analizar los patrones de las solicitudes anónimas durante un intervalo de tiempo. Use métricas para determinar el número de solicitudes anónimas a la cuenta de almacenamiento y utilice registros para determinar a qué contenedores se tiene acceso anónimo.

Supervisión de las solicitudes anónimas con el Explorador de métricas

Para realizar el seguimiento de las solicitudes anónimas a una cuenta de almacenamiento, use el Explorador de métricas de Azure situado en Azure Portal. Para más información sobre el Explorador de métricas, consulte Análisis de métricas con el Explorador de métricas de Azure Monitor.

Siga estos pasos para crear una métrica que realice el seguimiento de las solicitudes anónimas:

  1. Vaya a la cuenta de almacenamiento en Azure Portal. En la sección Supervisión, seleccione Métricas.

  2. Seleccione Agregar métrica. En el cuadro de diálogo Métrica, especifique los valores siguientes:

    1. Deje el campo Ámbito establecido en el nombre de la cuenta de almacenamiento.
    2. Establezca Espacio de nombres de métricas en Blob. Esta métrica informa de las solicitudes realizadas solo al almacenamiento de blobs.
    3. Establezca el campo Métrica en Transacciones.
    4. Establezca el campo Agregación en Suma.

    La nueva métrica muestra la suma del número de transacciones en el almacenamiento de blobs a lo largo de un intervalo de tiempo determinado. La métrica resultante aparece como se muestra en la siguiente imagen:

    Captura de pantalla que muestra cómo configurar la métrica para sumar transacciones de blobs

  3. A continuación, seleccione el botón Agregar filtro para filtrar la métrica de las solicitudes anónimas.

  4. En el cuadro de diálogo Filtro, especifique los valores siguientes:

    1. Establezca el valor Propiedad en Autenticación.
    2. Establezca el campo Operador en el signo igual (=).
    3. Establezca el campo Valores en Anónimo seleccionándolo en la lista desplegable o escribiéndolo.
  5. En la esquina superior derecha, seleccione el intervalo de tiempo del que desea ver la métrica. También puede indicar lo pormenorizada que debe ser la agregación de las solicitudes, especificando intervalos en cualquier punto entre 1 minuto y 1 mes.

Una vez configurada la métrica, las solicitudes anónimas comenzarán a aparecer en el gráfico. En la imagen siguiente, se muestran las solicitudes anónimas agregadas en los últimos 30 minutos.

Captura de pantalla que muestra las solicitudes anónimas agregadas al almacenamiento de blobs

También puede configurar una regla de alerta para recibir una notificación cuando se realice un determinado número de solicitudes anónimas a su cuenta de almacenamiento. Para más información, vea Creación, visualización y administración de alertas de métricas mediante Azure Monitor.

Análisis de los registros para identificar los contenedores que reciben solicitudes anónimas

Los registros de Azure Storage capturan detalles sobre las solicitudes realizadas a la cuenta de almacenamiento, como el modo en que se autorizó una solicitud. Puede analizar los registros para determinar qué contenedores reciben solicitudes anónimas.

Para registrar las solicitudes a su cuenta de Azure Storage con el fin de evaluar las solicitudes anónimas, puede usar el registro de Azure Storage en Azure Monitor. Para más información, consulte Supervisión de Azure Storage.

El registro de Azure Storage en Azure Monitor admite el uso de consultas de registro para analizar los datos de registro. Para consultar los registros, puede usar un área de trabajo de Azure Log Analytics. Para más información sobre las consultas de registro, consulte el Tutorial: Introducción a las consultas de Log Analytics.

Creación de una configuración de diagnóstico en Azure Portal

Para registrar datos de Azure Storage con Azure Monitor y analizarlos con Azure Log Analytics, primero debe crear una configuración de diagnóstico que indique qué tipos de solicitudes y para qué servicios de almacenamiento quiere registrar los datos. Después de configurar el registro de la cuenta de almacenamiento, los registros están disponibles en el área de trabajo de Log Analytics. Para crear un área de trabajo, consulte Creación de un área de trabajo de Log Analytics en Azure Portal.

Para obtener información sobre cómo crear una configuración de diagnóstico en Azure Portal, consulte Creación de una configuración de diagnóstico en Azure Monitor.

En el artículo Registros de recursos encontrará una referencia sobre los campos disponibles en los registros de Azure Storage en Azure Monitor.

Consulta de registros de solicitudes anónimas

Los registros de Azure Storage en Azure Monitor incluyen el tipo de autorización que se usó para hacer una solicitud a una cuenta de almacenamiento. En la consulta de registro, filtre por la propiedad AuthenticationType para ver las solicitudes anónimas.

Para recuperar los registros de los últimos siete días de solicitudes anónimas al almacenamiento de blobs, abra el área de trabajo de Log Analytics. Luego, pegue la siguiente consulta en una nueva consulta de registro y ejecútela:

StorageBlobLogs
| where TimeGenerated > ago(7d) and AuthenticationType == "Anonymous"
| project TimeGenerated, AccountName, AuthenticationType, Uri

También puede configurar una regla de alerta basada en esta consulta para que le informe sobre las solicitudes anónimas. Para más información, consulte Creación, visualización y administración de alertas de registro mediante Azure Monitor.

Respuestas a solicitudes anónimas

Cuando Blob Storage recibe una solicitud anónima, esa solicitud se realizará correctamente si se cumplen todas las condiciones siguientes:

  • Se permite el acceso anónimo para la cuenta de almacenamiento.
  • El contenedor de destino está configurado para permitir el acceso anónimo.
  • La solicitud es para el acceso de lectura.

Si alguna de esas condiciones no es verdadera, se produce un error en la solicitud. En caso de error, el código de respuesta depende de si la solicitud anónima fue realizada con una versión del servicio que admite el desafío del portador. El desafío del portador es compatible con las versiones de servicio 2019-12-12 y posteriores:

  • Si la solicitud anónima se ha realizado con una versión de servicio que admite el desafío del portador, el servicio devuelve el código de error 401 (no autorizado).
  • Si la solicitud anónima se ha realizado con una versión de servicio que no admite el desafío de portador y el acceso anónimo no se permite para la cuenta de almacenamiento, el servicio devuelve el código de error 409 (conflicto).
  • Si la solicitud anónima se ha realizado con una versión de servicio que no admite el desafío del portador y se permite el acceso anónimo para la cuenta de almacenamiento, el servicio devuelve el código de error 404 (no encontrado).

Para más información sobre el desafío del portador, consulte Desafío del portador.

Corrección del acceso anónimo para la cuenta de almacenamiento

Después de evaluar las solicitudes anónimas a contenedores y blobs de la cuenta de almacenamiento, puede tomar medidas para corregir el acceso anónimo de toda la cuenta estableciendo la propiedad AllowBlobPublicAccess para False.

El valor de acceso anónimo de una cuenta de almacenamiento invalida la configuración individual de los contenedores de esa cuenta. Al no permitir el acceso anónimo a una cuenta de almacenamiento, los contenedores que estén configurados para permitirlo ya no estarán accesibles de forma anónima. Si no permite el acceso anónimo para la cuenta, no es necesario deshabilitar el acceso anónimo para contenedores individuales.

Si en su escenario es preciso que determinados contenedores estén disponibles para el acceso anónimo, debería mover esos contenedores y sus blobs a cuentas de almacenamiento independientes reservadas para el acceso anónimo. Luego, puede impedir el acceso anónimo a cualquier otra cuenta de almacenamiento.

La corrección del acceso anónimo requiere la versión 2019-04-01 o posterior del proveedor de recursos de Azure Storage. Para más información, consulte la API REST del proveedor de recursos de Azure Storage.

Permisos para no permitir el acceso anónimo

Para establecer la propiedad AllowBlobPublicAccess para la cuenta de almacenamiento, un usuario debe tener permisos para crear y administrar cuentas de almacenamiento. Los roles de control de acceso basado en rol de Azure (Azure RBAC) que proporcionan estos permisos incluyen la acción Microsoft.Storage/storageAccounts/write. Los roles integrados con esta acción incluyen:

Las asignaciones de roles deben tener el ámbito del nivel de la cuenta de almacenamiento o superior para permitir que un usuario deniegue el acceso anónimo para la cuenta de almacenamiento. Para obtener más información sobre el ámbito de los roles, vea Comprensión del ámbito para RBAC de Azure.

Preste atención para restringir la asignación de estos roles solo a aquellos usuarios administrativos que requieran la capacidad de crear una cuenta de almacenamiento o actualizar sus propiedades. Use el principio de privilegios mínimos para asegurarse de que los usuarios tienen los permisos mínimos que necesitan para realizar sus tareas. Para más información sobre la administración del acceso con RBAC de Azure, consulte Procedimientos recomendados para RBAC de Azure.

Estos roles no proporcionan acceso a los datos de una cuenta de almacenamiento a través de Microsoft Entra ID. Sin embargo, incluyen Microsoft.Storage/storageAccounts/listkeys/action, que concede acceso a las claves de acceso de la cuenta. Con este permiso, un usuario puede usar las claves de acceso de la cuenta para acceder a todos los datos de una cuenta de almacenamiento.

La acción Microsoft.Storage/storageAccounts/listkeys/action en sí concede acceso a los datos a través de las claves de cuenta, pero no concede a un usuario la capacidad de cambiar la propiedad AllowBlobPublicAccess para una cuenta de almacenamiento. Para los usuarios que necesiten acceder a los datos de la cuenta de almacenamiento, pero no deban tener la capacidad de cambiar la configuración de esta, considere la posibilidad de asignar roles tipo Colaborador de datos de Storage Blob, Lector de datos de Storage Blob o Lector y acceso a los datos.

Nota

Los roles clásicos de administrador de suscripciones Administrador del servicio y Coadministrador equivalen al rol Propietario de Azure Resource Manager. El rol Propietario incluye todas las acciones, por lo que un usuario con uno de estos roles administrativos también puede crear cuentas de almacenamiento y administrar la su configuración. Para obtener más información, consulte Roles de Azure, roles de Microsoft Entra y roles de administrador de suscripción clásicos .

Establezca la propiedad AllowBlobPublicAccess de la cuenta de almacenamiento en False.

Para denegar el acceso anónimo a una cuenta de almacenamiento, establezca la propiedad AllowBlobPublicAccess de la cuenta en False.

Importante

Cuando no se permite el acceso anónimo a una cuenta de almacenamiento, se invalida la configuración de acceso para todos los contenedores de esta. Cuando no se permite el acceso anónimo para la cuenta de almacenamiento, se producirá un error en las futuras solicitudes anónimas a esa cuenta. Antes de cambiar esta configuración, asegúrese de comprender su efecto sobre las aplicaciones cliente que puedan acceder a los datos de la cuenta de almacenamiento de forma anónima siguiendo los pasos descritos en Detección de solicitudes anónimas desde aplicaciones cliente.

Para no permitir el acceso anónimo de una cuenta de almacenamiento en Azure Portal, siga estos pasos:

  1. Vaya a la cuenta de almacenamiento en Azure Portal.

  2. Busque la opción Configuración en Configuración.

  3. Establezca Permitir el acceso anónimo de blobs en Deshabilitado.

    Captura de pantalla que muestra cómo denegar el acceso anónimo para la cuenta

Nota:

No permitir el acceso anónimo en una cuenta de almacenamiento no afecta a los sitios web estáticos hospedados en dicha cuenta. Al contenedor $web siempre se puede acceder de forma pública.

Después de actualizar la configuración de acceso anónimo de la cuenta de almacenamiento, el cambio puede tardar hasta 30 segundos en propagarse por completo.

Script de ejemplo para la corrección masiva

El siguiente script de PowerShell de ejemplo se ejecuta en todas las cuentas de almacenamiento de Azure Resource Manager de una suscripción y establece la configuración de AllowBlobPublicAccess para esas cuentas en False.

<#
.SYNOPSIS
Finds storage accounts in a subscription where AllowBlobPublicAccess is True or null.

.DESCRIPTION
This script runs against all Azure Resource Manager storage accounts in a subscription
and sets the "AllowBlobPublicAccess" property to False.

Standard operation will enumerate all accounts where the setting is enabled and allow the 
user to decide whether or not to disable the setting.  

Classic storage accounts will require individual adjustment of containers to remove public
access, and will not be affected by this script.

Run with BypassConfirmation=$true if you wish to disallow public access on all Azure Resource Manager 
storage accounts without individual confirmation.

You will need access to the subscription to run the script.

.PARAMETER BypassConformation
Set this to $true to skip confirmation of changes. Not recommended.

.PARAMETER SubscriptionId
The subscription ID of the subscription to check.

.PARAMETER ReadOnly
Set this parameter so that the script makes no changes to any subscriptions and only reports affect accounts.

.PARAMETER NoSignin
Set this parameter so that no sign-in occurs -- you must sign in first. Use this if you're invoking this script repeatedly for multiple subscriptions and want to avoid being prompted to sign-in for each subscription.

.OUTPUTS
This command produces only STDOUT output (not standard PowerShell) with information about affect accounts.
#>
param(
    [boolean]$BypassConfirmation = $false,
    [Parameter(Mandatory = $true, ValueFromPipelineByPropertyName = 'SubscriptionId')]
    [String] $SubscriptionId,
    [switch] $ReadOnly, # Use this if you don't want to make changes, but want to get information about affected accounts
    [switch] $NoSignin # Use this if you are already signed in and don't want to be prompted again
)

begin {
    if ( ! $NoSignin.IsPresent ) {
        Login-AzAccount | Out-Null
    }
}

process {
    try {
        Select-AzSubscription -SubscriptionId $SubscriptionId -ErrorAction Stop | Out-Null
    }
    catch {
        Write-Error "Unable to access select subscription '$SubscriptionId' as the signed in user -- ensure that you have access to this subscription." -ErrorAction Stop
    }

    foreach ($account in Get-AzStorageAccount) {
        if ($null -eq $account.AllowBlobPublicAccess -or $account.AllowBlobPublicAccess -eq $true) {
            Write-host "Account:" $account.StorageAccountName " isn't disallowing public access."

            if ( ! $ReadOnly.IsPresent ) {
                if (!$BypassConfirmation) {
                    $confirmation = Read-Host "Do you wish to disallow public access? [y/n]"
                }
                if ($BypassConfirmation -or $confirmation -eq 'y') {
                    try {
                        Set-AzStorageAccount -Name $account.StorageAccountName -ResourceGroupName $account.ResourceGroupName -AllowBlobPublicAccess $false
                        Write-Host "Success!"
                    }
                    catch {
                        Write-Output $_
                    }
                }
            }
        }
        elseif ($account.AllowBlobPublicAccess -eq $false) {
            Write-Host "Account:" $account.StorageAccountName "has public access disabled, no action required."
        }
        else {
            Write-Host "Account:" $account.StorageAccountName ". Error, please manually investigate."
        }
    }
}

end {
    Write-Host "Script complete"
}

Comprobar el valor de acceso anónimo para varias cuentas

Para comprobar el valor de acceso anónimo en un conjunto de cuentas de almacenamiento con un rendimiento óptimo, puede usar Azure Resource Graph Explorer en Azure Portal. Para más información sobre el uso de Resource Graph Explorer, consulte Inicio rápido: Ejecución de la primera consulta de Resource Graph mediante Azure Resource Graph Explorer.

Si la siguiente consulta se ejecuta en Resource Graph Explorer, este devuelve una lista de cuentas de almacenamiento y muestra el valor de acceso anónimo para cada cuenta:

resources
| where type =~ 'Microsoft.Storage/storageAccounts'
| extend allowBlobPublicAccess = parse_json(properties).allowBlobPublicAccess
| project subscriptionId, resourceGroup, name, allowBlobPublicAccess

En la imagen siguiente se muestran los resultados de una consulta en una suscripción. En el caso de las cuentas de almacenamiento en las que la propiedad AllowBlobPublicAccess se establece explícitamente, aparece en los resultados como true o false. Si la propiedad AllowBlobPublicAccess no está establecida para una cuenta de almacenamiento, aparece en blanco (o null) en los resultados de la consulta.

Captura de pantalla que muestra los resultados de la consulta para la configuración de acceso anónimo entre cuentas de almacenamiento

Uso de Azure Policy para auditar el cumplimiento

Si tiene un gran número de cuentas de almacenamiento, es posible que desee realizar una auditoría para asegurarse de que esas cuentas están configuradas para evitar el acceso anónimo. Para auditar un conjunto de cuentas de almacenamiento para su cumplimiento, use Azure Policy. Azure Policy es un servicio que puede usar para crear, asignar y administrar directivas que aplican reglas a los recursos de Azure. Azure Policy le permite mantener esos recursos conforme a lo establecido en los estándares corporativos y los contratos de nivel de servicio. Para más información, consulte la Introducción a Azure Policy.

Creación de una directiva con un efecto de auditoría

Azure Policy admite efectos que determinan lo que sucede cuando una regla de directiva se evalúa con respecto a un recurso. El efecto de auditoría crea una advertencia cuando un recurso no cumple los requisitos, pero no detiene la solicitud. Para obtener más información, consulte Comprender los efectos de Azure Policy.

Para crear una directiva con un efecto de auditoría para el valor de acceso anónimo de una cuenta de almacenamiento con Azure Portal, siga estos pasos:

  1. En Azure Portal, vaya al servicio Azure Policy.

  2. Seleccione Definiciones en la sección Creación.

  3. Seleccione Agregar definición de directiva para crear una nueva definición de directiva.

  4. En el campo donde se indica la ubicación de la definición, seleccione el botón Más para especificar dónde se encuentra el recurso de directiva de auditoría.

  5. Escriba un nombre para la directiva. Si lo desea, puede escribir también una descripción y la categoría.

  6. En Regla de directivas, agregue la siguiente definición de directiva a la sección policyRule.

    {
      "if": {
        "allOf": [
          {
            "field": "type",
            "equals": "Microsoft.Storage/storageAccounts"
          },
          {
            "not": {
              "field":"Microsoft.Storage/storageAccounts/allowBlobPublicAccess",
              "equals": "false"
            }
          }
        ]
      },
      "then": {
        "effect": "audit"
      }
    }
    
  7. Guarde la directiva.

Asignación de la directiva

A continuación, asigne la directiva a un recurso. El ámbito de la directiva corresponde a ese recurso y a todos los recursos que hay debajo del mismo. Para más información sobre la asignación de directivas, consulte Estructura de asignaciones de Azure Policy.

Para asignar la directiva con Azure Portal, haga lo siguiente:

  1. En Azure Portal, vaya al servicio Azure Policy.
  2. Seleccione Asignaciones en la sección Creación.
  3. Seleccione Asignar directiva para crear una nueva asignación de directiva.
  4. En el campo Ámbito, seleccione el ámbito de la asignación de directiva.
  5. En el campo Definición de directiva, seleccione el botón Más y, a continuación, seleccione la directiva que definió en la sección anterior de la lista.
  6. Escriba un nombre para la asignación de directiva. La descripción es opcional.
  7. Deje la opción Cumplimiento de directivas como Habilitada. Esta configuración no tiene ningún efecto en la directiva de auditoría.
  8. Seleccione Revisar y crear para crear la asignación.

Ver el informe de cumplimiento

Una vez asignada la directiva, puede ver el informe de cumplimiento. El informe de cumplimiento de una directiva de auditoría proporciona información sobre las cuentas de almacenamiento que no cumplen con esa directiva. Para más información, consulte Obtención de datos de cumplimiento de directiva.

El informe de cumplimiento puede tardar varios minutos en estar disponible después de que se cree la asignación de directiva.

Para ver el informe de cumplimiento en Azure Portal, siga estos pasos:

  1. En Azure Portal, vaya al servicio Azure Policy.

  2. Seleccione Cumplimiento.

  3. Filtre los resultados por el nombre de la asignación de directiva que creó en el paso anterior. El informe muestra el número de recursos que no cumplen con la directiva.

  4. Puede explorar en profundidad el informe para obtener más detalles, incluida una lista de cuentas de almacenamiento que no cumplen los requisitos.

    Captura de pantalla que muestra el informe de cumplimiento de la directiva de auditoría para el acceso anónimo

Uso de Azure Policy para aplicar el acceso autorizado

Azure Policy admite la gobernanza en la nube, asegurándose así de que los recursos de Azure cumplen los requisitos y los estándares establecidos. Para asegurarse de que las cuentas de almacenamiento de su organización permiten solo solicitudes autorizadas, puede crear una directiva que impida la creación de una nueva cuenta de almacenamiento con u valor de acceso anónimo que permita las solicitudes anónimas. Esta directiva también impedirá todos los cambios de configuración en una cuenta existente si el valor de acceso anónimo de esa cuenta no es compatible con la directiva.

La directiva de cumplimiento usa el efecto de denegación para evitar una solicitud que podría crear o modificar una cuenta de almacenamiento para permitir el acceso anónimo. Para obtener más información, consulte Comprender los efectos de Azure Policy.

Para crear una directiva con un efecto de denegación para un valor de acceso anónimo que permita solicitudes anónimas, siga los mismos pasos descritos en Uso de Azure Policy para la auditoría de cumplimiento, pero proporcione el siguiente código JSON en la sección policyRule de la definición de directivas:

{
  "if": {
    "allOf": [
      {
        "field": "type",
        "equals": "Microsoft.Storage/storageAccounts"
      },
      {
        "not": {
          "field":"Microsoft.Storage/storageAccounts/allowBlobPublicAccess",
          "equals": "false"
        }
      }
    ]
  },
  "then": {
    "effect": "deny"
  }
}

Después de crear la directiva con el efecto de denegación y asignarla a un ámbito, un usuario no puede crear una cuenta de almacenamiento que permita el acceso anónimo. Asimismo, los usuarios tampoco pueden realizar cambios de configuración en una cuenta de almacenamiento existente que actualmente permita el acceso anónimo. Si intentan hacerlo, se producirá un error. El valor de acceso anónimo de la cuenta de almacenamiento debe establecerse en false para continuar con la creación o la configuración de la cuenta.

En la siguiente imagen se muestra el error que se produce si se intenta crear una cuenta de almacenamiento que permita el acceso anónimo cuando una directiva con un efecto de denegación requiere que no se permita el acceso anónimo.

Captura de pantalla que muestra el error que se produce al crear una cuenta de almacenamiento que infringe la directiva

Pasos siguientes