Comprender los efectos de Azure Policy

Cada definición de directiva en Azure Policy tiene un único efecto. Dicho efecto determina lo que ocurre cuando la regla de directivas se evalúa con la coincidencia. Los efectos se comportan de manera diferente si son para un nuevo recurso, un recurso actualizado o un recurso existente.

Actualmente, se admiten estos efectos en una definición de directiva:

Intercambio de efectos

A veces, varios efectos pueden ser válidos para una definición de directiva determinada. A menudo, los parámetros se usan para especificar valores de efecto permitidos para que una única definición pueda ser más versátil. Sin embargo, es importante tener en cuenta que no todos los efectos son intercambiables. Las propiedades de recursos y la lógica de la regla de directiva pueden determinar si un determinado efecto se considera válido para la definición de directiva. Por ejemplo, las definiciones de directiva con efecto AuditIfNotExists requieren otros detalles en la regla de directiva que no son necesarios para las directivas con efecto Audit. Los efectos también se comportan de forma diferente. Las directivas de auditoría evaluan el cumplimiento de un recurso en función de sus propias propiedades, mientras que las directivas AuditIfNotExists evaluan el cumplimiento de un recurso en función de las propiedades de un recurso secundario o de extensión.

La lista siguiente es una guía general sobre los efectos intercambiables:

  • Audit, Deny y Modify o Append suelen ser intercambiables.
  • AuditIfNotExists y DeployIfNotExists suelen ser intercambiables.
  • Manual no es intercambiable.
  • Disabled es intercambiable con cualquier efecto.

Orden de evaluación

En primer lugar Azure Policy evalúa las solicitudes para crear o actualizar un recurso. Azure Policy crea una lista de todas las asignaciones que se aplican al recurso y, a continuación, evalúa el recurso de acuerdo con cada definición. Para un modo de Administrador de recursos Azure Policy procesa algunos de los efectos antes de entregar la solicitud al proveedor de recursos adecuado. Al seguirse este orden se evita que un proveedor de recursos realice un procesamiento innecesario cuando un recurso no cumple con los controles de gobernanza diseñados de Azure Policy. Con un modo de Proveedor de recursos, el proveedor de recursos administra la evaluación y el resultado, e informa a Azure Policy de los resultados.

  • Primero se selecciona Deshabilitado para determinar si se debe evaluar la regla de directivas.
  • Después se evalúan Append y Modify. Dado que cualquiera de ellos podría alterar la solicitud, un cambio realizado podría impedir que se activara un efecto de auditoría o denegación. Estos efectos solo están disponibles con un modo de Administrador de recursos.
  • Luego se evalúa deny. La evaluación de deny antes de audit impide el doble registro de un recurso no deseado.
  • Se evalúa Audit.
  • Manual se evalúa.
  • AuditIfNotExists se evalúa.
  • denyAction se evalúa en último lugar.

Después de que el proveedor de recursos devuelva un código correcto en una solicitud de modo de Resource Manager, AuditIfNotExists y DeployIfNotExists ejecutan una evaluación para determinar si es necesario realizar una acción o un registro de cumplimiento adicionales.

Las solicitudes PATCH que solo modifican los campos relacionados con tags restringen la evaluación de directivas a aquellas que contienen condiciones que inspeccionan campos relacionados con tags.

AddToNetworkGroup

AddToNetworkGroup se usa en Azure Virtual Network Manager para definir la pertenencia a grupos de red dinámicos. Este efecto es específico solo de las definiciones de modo de directivaMicrosoft.Network.Data.

Con los grupos de red, la definición de directiva incluye la expresión condicional para hacer coincidir las redes virtuales con los criterios y especifica el grupo de red de destino donde se colocan los recursos coincidentes. El efecto addToNetworkGroup se usa para colocar recursos en el grupo de red de destino.

Para más información, vaya a Configuración de Azure Policy con grupos de red en Azure Virtual Network Manager.

Append

Append se utiliza para agregar más campos al recurso solicitado durante la creación o actualización. Un ejemplo habitual es la especificación de direcciones IP permitidas para un recurso de almacenamiento.

Importante

Append está pensado para su uso con propiedades que no son de etiqueta. Aunque Append puede agregar etiquetas a un recurso durante una solicitud de creación o actualización, se recomienda usar en su lugar el efecto Modify para las etiquetas.

Evaluación de append

Append realiza la evaluación antes de que un proveedor de recursos procese la solicitud durante la creación o actualización de un recurso. Append agrega campos al recurso cuando se cumple la condición if de la regla de directiva. En caso de que el efecto append reemplace un valor de la solicitud original por otro, actúa como un efecto deny y rechaza la solicitud. Para anexar un nuevo valor a una matriz existente, use la versión [*] del alias.

Cuando una definición de directiva que utiliza el efecto append se ejecuta como parte de un ciclo de evaluación, no realiza cambios en los recursos que ya existen. En su lugar, marca cualquier recurso que cumple la condición if como no conforme.

Propiedades de append

Un efecto append solo tiene una matriz details, que es necesaria. Como details es una matriz, puede tomar un único par campo-valor o varios. Consulte estructura de definición para obtener la lista de campos aceptables.

Ejemplos de append

Ejemplo 1: Un único par campo-valor que usa un alias distinto de [*] con un valor de matriz para establecer reglas de IP en una cuenta de almacenamiento. Cuando el alias distinto de [*] es una matriz, el efecto anexa el valor como toda la matriz. Si la matriz ya existe, el conflicto ocasiona un evento de rechazo.

"then": {
  "effect": "append",
  "details": [
    {
      "field": "Microsoft.Storage/storageAccounts/networkAcls.ipRules",
      "value": [
        {
          "action": "Allow",
          "value": "134.5.0.0/21"
        }
      ]
    }
  ]
}

Ejemplo 2: Un único par campo/valor que usa un alias[*] con un valor de matriz para establecer reglas IP en una cuenta de almacenamiento. Cuando usa el alias [*], el efecto anexa el valor a una matriz que es posible que ya exista. Si la matriz todavía no existe, se crea.

"then": {
  "effect": "append",
  "details": [
    {
      "field": "Microsoft.Storage/storageAccounts/networkAcls.ipRules[*]",
      "value": {
        "value": "40.40.40.40",
        "action": "Allow"
      }
    }
  ]
}

Auditoría

Audit se utiliza para crear un evento de advertencia en el registro de actividad cuando se evalúa un recurso no compatible, pero no se detiene la solicitud.

Evaluación de audit

Audit es el último efecto que Azure Policy comprueba durante la creación o actualización de un recurso. Para un modo de Administrador de recursos, Azure Policy envía el recurso al proveedor de recursos. Al evaluar una solicitud de creación o actualización para un recurso, Azure Policy agrega una operación Microsoft.Authorization/policies/audit/action al registro de actividad y marca el recurso como no compatible. Durante un ciclo de evaluación de cumplimiento estándar, solo se actualiza el estado de cumplimiento en el recurso.

Propiedades de audit

Para un modo de Administrador de recursos, el efecto audit no tiene propiedades adicionales para su uso en la condición then de la definición de directiva.

En el modo de Proveedor de recursos de Microsoft.Kubernetes.Data, el efecto audit tiene las siguientes subpropiedades de details. El uso de templateInfo es necesario para las definiciones de directiva nuevas o actualizadas, ya que constraintTemplate está en desuso.

  • templateInfo (obligatorio)
    • No se puede usar con constraintTemplate.
    • sourceType (obligatorio)
      • Define el tipo de origen de la plantilla de restricciones. Valores permitidos: PublicURL o Base64Encoded.

      • Si es PublicURL, se empareja con la propiedad url para proporcionar la ubicación de la plantilla de restricciones. La ubicación debe ser públicamente accesible.

        Advertencia

        No use identificadores uniformes de recursos de SAS, tokens de dirección URL ni nada que pueda revelar secretos en texto sin formato.

      • Si es Base64Encoded, se empareja con la propiedad content para proporcionar la plantilla de restricciones codificada en Base 64. Consulte Creación de una definición de directiva a partir de una plantilla de restricción para crear una definición de directiva personalizada a partir de una plantilla de restricción Gatekeeper v3 de Open Policy Agent (OPA).

  • restricción (en desuso)
    • No se puede usar con templateInfo.
    • La implementación de CRD de la plantilla de restricción. Usa los parámetros que se han pasado a través de valores como {{ .Values.<valuename> }}. En el ejemplo 2 siguiente, estos valores son {{ .Values.excludedNamespaces }} y {{ .Values.allowedContainerImagesRegex }}.
  • constraintTemplate (en desuso)
    • No se puede usar con templateInfo.
    • Debe reemplazarse por templateInfo al crear o actualizar una definición de directiva.
    • La plantilla de restricción CustomResourceDefinition (CRD) que define nuevas restricciones. La plantilla define la lógica de Rego, el esquema de restricción y los parámetros de restricción que se pasan a través de valores desde Azure Policy. Para más información, vaya a Restricciones de Gatekeeper.
  • constraintInfo (opcional)
    • No puede ser usado con constraint, constraintTemplate, apiGroups, kinds, scope, namespaces, excludedNamespaces, o labelSelector.
    • Si constraintInfo no se proporciona, la restricción se puede generar a partir de templateInfo y la directiva.
    • sourceType (obligatorio)
      • Define el tipo de origen para la restricción. Valores permitidos: PublicURL o Base64Encoded.

      • Si es PublicURL, se empareja con la propiedad url para proporcionar la ubicación de la restricción. La ubicación debe ser públicamente accesible.

        Advertencia

        No use el URI de SAS ni tokens en url ni nada que pueda exponer un secreto.

  • namespaces (opcional)
    • Una matriz de espacios de nombres de Kubernetes a la que limitar la evaluación de directivas.
    • Un valor vacío o que falta hace que la evaluación de la directiva incluya todos los espacios de nombres no definidos en excludedNamespaces.
  • excludedNamespaces (opcional)
  • labelSelector (opcional)
    • Un objeto que incluye las propiedades matchLabels (objeto) y matchExpression (matriz) para permitir especificar qué recursos de Kubernetes se deben incluir para la evaluación de las directivas que coincidieron con las etiquetas y selectores proporcionados.
    • Un valor vacío o que falta provoca que la evaluación de la directiva incluya todas las etiquetas y selectores, excepto los espacios de nombres definidos en excludedNamespaces.
  • ámbito (opcional)
    • Una cadena que incluye la propiedad ámbito para permitir especificar si se buscan recursos de ámbito de clúster o de espacio de nombres.
  • apiGroups (obligatorio cuando se usa templateInfo)
    • Una matriz que incluye los grupos API que deben coincidir. Una matriz vacía ([""]) es el grupo de API principal.
    • No se permite definir ["*"] para apiGroups.
  • kinds (obligatorio cuando se usa templateInfo)
    • Una matriz que incluye el tipo de objeto de Kubernetes al que se debe limitar la evaluación.
    • No se permite definir ["*"] para kinds.
  • values (opcional)
    • Define cualquier parámetro y valor para pasar a la restricción. Cada valor debe existir y coincidir con una propiedad de la sección openAPIV3Schema de validación de la plantilla de restricción CRD.

Ejemplo de audit

Ejemplo 1: Uso del efecto audit para los modos de Administrador de recursos.

"then": {
  "effect": "audit"
}

Ejemplo 2: Uso del efecto audit para un modo de Proveedor de recursos de Microsoft.Kubernetes.Data. La información adicional de details.templateInfo declara el uso de PublicURL y establece url en la ubicación de la plantilla de restricciones que se va a usar en Kubernetes para limitar las imágenes de contenedor permitidas.

"then": {
  "effect": "audit",
  "details": {
    "templateInfo": {
      "sourceType": "PublicURL",
      "url": "https://store.policy.core.windows.net/kubernetes/container-allowed-images/v1/template.yaml",
    },
    "values": {
      "imageRegex": "[parameters('allowedContainerImagesRegex')]"
    },
    "apiGroups": [
      ""
    ],
    "kinds": [
      "Pod"
    ]
  }
}

AuditIfNotExists

AuditIfNotExists habilita la auditoría de recursos relacionados con el recurso que coincide con la condición if, pero no tiene las propiedades especificadas en details de la condición then.

Evaluación de AuditIfNotExists

AuditIfNotExists se ejecuta después de que un proveedor de recursos haya operado con una solicitud de creación o actualización de recursos y haya devuelto un código de estado correcto. La auditoría se produce si no hay recursos relacionados o si los recursos definidos por ExistenceCondition no se evalúan como true. En el caso de los recursos nuevos y actualizados, Azure Policy agrega una operación Microsoft.Authorization/policies/audit/action al registro de actividad y marca el recurso como no compatible. Cuando se desencadena, el recurso que cumple la condición if es el recurso que está marcado como no conforme.

Propiedades de AuditIfNotExists

La propiedad details de los efectos de AuditIfNotExists tiene todas las subpropiedades que definen los recursos relacionados para coincidir.

  • Type (obligatorio)
    • Especifica el tipo del recurso relacionado para coincidir.
    • Si el tipo es un tipo de recurso debajo del recurso de condición if, la directiva consultará los recursos de este tipo que estén dentro del ámbito del recurso evaluado. De lo contrario, las consultas de directiva dentro del mismo grupo de recursos o suscripción que el recurso evaluado dependen de existenceScope.
  • Nombre (opcional)
    • Especifica el nombre exacto del recurso para coincidir y hace que la directiva recupere un recurso específico en lugar de todos los recursos del tipo especificado.
    • Cuando los valores de condición para if.field.type y then.details.type coinciden, entonces el valor Name es necesario y debe ser [field('name')], o [field('fullName')] para un recurso secundario. Sin embargo, un efecto Audit debe tenerse en cuenta en su lugar.

Nota:

Los segmentos deTipo y Nombre se pueden combinar para recuperar de forma genérica los recursos anidados.

Para recuperar un recurso específico, puede usar "type": "Microsoft.ExampleProvider/exampleParentType/exampleNestedType" y "name": "parentResourceName/nestedResourceName".

Para recuperar una colección de recursos anidados, se puede proporcionar un ? de carácter comodín en lugar del segmento de apellidos. Por ejemplo, "type": "Microsoft.ExampleProvider/exampleParentType/exampleNestedType" y "name": "parentResourceName/?". Esto se puede combinar con funciones de campo para acceder a los recursos relacionados con el recurso evaluado, como "name": "[concat(field('name'), '/?')]"."

  • ResourceGroupName (opcional)
    • Permite que la coincidencia del recurso relacionado provenga de un grupo de recursos diferente.
    • No se aplica si type es un recurso que estaría debajo del recurso de condición if.
    • El valor predeterminado es el grupo de recursos del recurso de la condición if.
  • ExistenceScope (opcional)
    • Los valores permitidos son Subscription y ResourceGroup.
    • Establece el ámbito de donde obtener el recurso relacionado para que coincida.
    • No se aplica si type es un recurso que estaría debajo del recurso de condición if.
    • Para ResourceGroup, limitaría al grupo de recursos en ResourceGroupName si se especifica. Si no se especifica ResourceGroupName, limitaría al grupo de recursos de la condición if, que es el comportamiento predeterminado.
    • Para Subscription, se consulta toda la suscripción para el recurso relacionado. El ámbito de asignación debe establecerse en la suscripción o superior para una evaluación adecuada.
    • El valor predeterminado es ResourceGroup.
  • EvaluationDelay (opcional)
    • Especifica cuándo se debe evaluar la existencia de los recursos relacionados. El retraso solo se usa para las evaluaciones que son el resultado de una solicitud de creación o de actualización de recursos.
    • Los valores permitidos son AfterProvisioning, AfterProvisioningSuccess, AfterProvisioningFailure, o una duración ISO 8601 entre 0 y 360 minutos.
    • Los valores AfterProvisioning inspeccionan el resultado de aprovisionamiento del recurso que se evaluó en la condición IF de la regla de directiva. AfterProvisioning se ejecuta una vez completado el aprovisionamiento, independientemente del resultado. Si el aprovisionamiento tarda más de seis horas, se trata como un error a la hora de determinar los retrasos de evaluación de AfterProvisioning.
    • El valor predeterminado es PT10M (10 minutos).
    • La especificación de un retraso de evaluación largo puede hacer que el estado de cumplimiento registrado del recurso no se actualice hasta el siguiente desencadenador de evaluación.
  • ExistenceCondition (opcional)
    • Si no se especifica, todo recurso relacionado de type cumple con el efecto y no desencadena la auditoría.
    • Utiliza el mismo lenguaje que la regla de directiva para la condición if, pero se evalúa individualmente en relación con cada recurso relacionado.
    • Si algún recurso relacionado coincidente se evalúa como true, se cumple la condición del efecto y no se desencadena la auditoría.
    • Puede utilizar [field()] para comprobar la equivalencia con los valores en la condición if.
    • Por ejemplo, podría usarse para validar que el recurso primario (en la condición if) está en la misma ubicación de recursos que el recurso relacionado coincidente.

Ejemplo de AuditIfNotExists

Ejemplo: evalúa las máquinas virtuales para determinar si existe la extensión Antimalware y luego audita cuando faltan.

{
  "if": {
    "field": "type",
    "equals": "Microsoft.Compute/virtualMachines"
  },
  "then": {
    "effect": "auditIfNotExists",
    "details": {
      "type": "Microsoft.Compute/virtualMachines/extensions",
      "existenceCondition": {
        "allOf": [
          {
            "field": "Microsoft.Compute/virtualMachines/extensions/publisher",
            "equals": "Microsoft.Azure.Security"
          },
          {
            "field": "Microsoft.Compute/virtualMachines/extensions/type",
            "equals": "IaaSAntimalware"
          }
        ]
      }
    }
  }
}

Denegar

Deny se utiliza para evitar una solicitud de recursos que no coincida con los estándares definidos a través de una definición de directiva, así como para impedir que se produzca un error en la solicitud.

Evaluación de deny

Al crear o actualizar un recurso coincidente en un modo de Administrador de recursos, deny evita la solicitud antes de que se envíe al proveedor de recursos. La solicitud se devuelve como un código 403 (Forbidden). En el portal, este estado de prohibido puede verse como un estado en la implementación que evitó la asignación de directiva. Para el modo de Proveedor de recursos, el proveedor de recursos administra la evaluación del recurso.

Durante la evaluación de los recursos existentes, los recursos que coinciden con una definición de directiva deny se marcan como no compatibles.

Propiedades de deny

Para un modo de Administrador de recursos, el efecto deny no tiene propiedades adicionales para su uso en la condición then de la definición de directiva.

En el modo de Proveedor de recursos de Microsoft.Kubernetes.Data, el efecto deny tiene las siguientes subpropiedades adicionales de details. El uso de templateInfo es necesario para las definiciones de directiva nuevas o actualizadas, ya que constraintTemplate está en desuso.

  • templateInfo (obligatorio)
    • No se puede usar con constraintTemplate.
    • sourceType (obligatorio)
      • Define el tipo de origen de la plantilla de restricciones. Valores permitidos: PublicURL o Base64Encoded.

      • Si es PublicURL, se empareja con la propiedad url para proporcionar la ubicación de la plantilla de restricciones. La ubicación debe ser públicamente accesible.

        Advertencia

        No use el URI de SAS ni tokens en url ni nada que pueda exponer un secreto.

      • Si es Base64Encoded, se empareja con la propiedad content para proporcionar la plantilla de restricciones codificada en Base 64. Consulte Creación de una definición de directiva a partir de una plantilla de restricción para crear una definición de directiva personalizada a partir de una plantilla de restricción Gatekeeper v3 de Open Policy Agent (OPA).

  • constraint (opcional)
    • No se puede usar con templateInfo.
    • La implementación de CRD de la plantilla de restricción. Usa los parámetros que se han pasado a través de valores como {{ .Values.<valuename> }}. En el ejemplo 2 siguiente, estos valores son {{ .Values.excludedNamespaces }} y {{ .Values.allowedContainerImagesRegex }}.
  • constraintTemplate (en desuso)
    • No se puede usar con templateInfo.
    • Debe reemplazarse por templateInfo al crear o actualizar una definición de directiva.
    • La plantilla de restricción CustomResourceDefinition (CRD) que define nuevas restricciones. La plantilla define la lógica de Rego, el esquema de restricción y los parámetros de restricción que se pasan a través de valores desde Azure Policy. Para más información, vaya a Restricciones de Gatekeeper.
  • constraintInfo (opcional)
    • No se puede usar con constraint, constraintTemplate, apiGroups o kinds.
    • Si constraintInfo no se proporciona, la restricción se puede generar a partir de templateInfo y la directiva.
    • sourceType (obligatorio)
      • Define el tipo de origen para la restricción. Valores permitidos: PublicURL o Base64Encoded.

      • Si es PublicURL, se empareja con la propiedad url para proporcionar la ubicación de la restricción. La ubicación debe ser públicamente accesible.

        Advertencia

        No use el URI de SAS ni tokens en url ni nada que pueda exponer un secreto.

  • namespaces (opcional)
    • Una matriz de espacios de nombres de Kubernetes a la que limitar la evaluación de directivas.
    • Un valor vacío o que falta hace que la evaluación de la directiva incluya todos los espacios de nombres, excepto los definidos en excludedNamespaces.
  • excludedNamespaces (obligatorio)
  • labelSelector (obligatorio)
    • Un objeto que incluye las propiedades matchLabels (objeto) y matchExpression (matriz) para permitir especificar qué recursos de Kubernetes se deben incluir para la evaluación de las directivas que coincidieron con las etiquetas y selectores proporcionados.
    • Un valor vacío o que falta provoca que la evaluación de la directiva incluya todas las etiquetas y selectores, excepto los espacios de nombres definidos en excludedNamespaces.
  • apiGroups (obligatorio cuando se usa templateInfo)
    • Una matriz que incluye los grupos API que deben coincidir. Una matriz vacía ([""]) es el grupo de API principal.
    • No se permite definir ["*"] para apiGroups.
  • kinds (obligatorio cuando se usa templateInfo)
    • Una matriz que incluye el tipo de objeto de Kubernetes al que se debe limitar la evaluación.
    • No se permite definir ["*"] para kinds.
  • values (opcional)
    • Define cualquier parámetro y valor para pasar a la restricción. Cada valor debe existir en la CRD de la plantilla de restricción.

Ejemplo de deny

Ejemplo 1: Uso del efecto deny para los modos de Administrador de recursos.

"then": {
  "effect": "deny"
}

Ejemplo 2: Uso del efecto deny para un modo de Proveedor de recursos de Microsoft.Kubernetes.Data. La información adicional de details.templateInfo declara el uso de PublicURL y establece url en la ubicación de la plantilla de restricciones que se va a usar en Kubernetes para limitar las imágenes de contenedor permitidas.

"then": {
  "effect": "deny",
  "details": {
    "templateInfo": {
      "sourceType": "PublicURL",
      "url": "https://store.policy.core.windows.net/kubernetes/container-allowed-images/v1/template.yaml",
    },
    "values": {
      "imageRegex": "[parameters('allowedContainerImagesRegex')]"
    },
    "apiGroups": [
      ""
    ],
    "kinds": [
      "Pod"
    ]
  }
}

DenyAction

DenyAction se utiliza para bloquear solicitudes basadas en la acción prevista a los recursos a escala. La única acción admitida hoy en día es DELETE. Este efecto y el nombre de la acción ayudan a prevenir cualquier eliminación accidental de recursos críticos.

Evaluación de DenyAction

Cuando se envía una llamada de solicitud con un nombre de acción aplicable y el ámbito de destino, denyAction impide que la solicitud se realice correctamente. La solicitud se devuelve como un código 403 (Forbidden). En el portal, este estado de prohibido puede verse como un estado en la implementación que evitó la asignación de directiva.

Microsoft.Authorization/policyAssignments, Microsoft.Authorization/denyAssignments, Microsoft.Blueprint/blueprintAssignments, Microsoft.Resources/deploymentStacks, Microsoft.Resources/subscriptions y Microsoft.Authorization/locks están exentos de la aplicación de DenyAction para evitar escenarios de bloqueo.

Eliminación de suscripciones

La directiva no bloquea la eliminación de recursos que se producen durante la eliminación de una suscripción.

Eliminación de grupos de recursos

La directiva evalúa los recursos que admiten la ubicación y las etiquetas con las directivas DenyAction durante la eliminación de un grupo de recursos. Solo las directivas que tengan cascadeBehaviors establecido en deny en la regla de directiva bloquean la eliminación de un grupo de recursos. La directiva no bloquear la eliminación de recursos que no admitan la ubicación y las etiquetas ni ninguna directiva con mode:all.

Eliminación en cascada

La eliminación en cascada se produce cuando la eliminación de un recurso primario elimina implícitamente todos sus recursos secundarios. La directiva no bloquea la eliminación de recursos secundarios cuando una acción de eliminación tenga como destino los recursos primarios. Por ejemplo, Microsoft.Insights/diagnosticSettings es un recurso secundario de Microsoft.Storage/storageaccounts. Si una directiva denyAction tiene como destino Microsoft.Insights/diagnosticSettings, se producirá un error en una llamada de eliminación a la configuración de diagnóstico (recurso secundario), pero una eliminación en la cuenta de almacenamiento (recurso primario) eliminará implícitamente la configuración de diagnóstico (recurso secundario).

En esta tabla se describe si un recurso se protegerá de la eliminación dado el recurso aplicable a la directiva denyAction asignada y el ámbito objetivo de la llamada DELETE. En el contexto de esta tabla, un recurso indexado es aquel que admite etiquetas y ubicaciones, y un recurso no indexado es aquel que no admite etiquetas ni ubicaciones. Para más información sobre los recursos indexados y no indexados, consulte los modos de definición. Los recursos secundarios son recursos que solo existen en el contexto de otro recurso. Por ejemplo, un recurso de extensión de máquinas virtuales es un elemento secundario de la máquina virtual, que es el recurso primario.

Entidad que se va a eliminar Entidad aplicable a condiciones de directiva Acción realizada
Resource Resource Protegido
Suscripción Resource Deleted
Resource group Recurso indexado Depende de cascadeBehaviors
Resource group Recurso no indexado Deleted
Recurso secundario Recurso principal El elemento primario está protegido; se elimina el elemento secundario
Recurso principal Recurso secundario Deleted

Propiedades de DenyAction

La propiedad details del efecto DenyAction tiene todas las subpropiedades que definen la acción y los comportamientos.

  • actionNames (obligatorio)
    • Matriz que especifica qué acciones se va a impedir que se ejecuten.
    • Los nombres de acción admitidos son: delete.
  • cascadeBehaviors (opcional)
    • Objeto que define qué comportamiento se seguirá cuando el recurso se elimine implícitamente mediante la eliminación de un grupo de recursos.
    • Solo se admite en las definiciones de directiva con el modo establecido en indexed.
    • Los valores permitidos son: allow o deny.
    • El valor predeterminado es deny.

Ejemplo DenyAction

Ejemplo: Denegar cualquier llamada de eliminación dirigida a cuentas de base de datos que tengan un entorno de etiqueta que sea igual a producción. Dado que el comportamiento en cascada se establece en deny, bloquee cualquier llamada DELETE destinada a un grupo de recursos con una cuenta de base de datos aplicable.

{
  "if": {
    "allOf": [
      {
        "field": "type",
        "equals": "Microsoft.DocumentDb/accounts"
      },
      {
        "field": "tags.environment",
        "equals": "prod"
      }
    ]
  },
  "then": {
    "effect": "denyAction",
    "details": {
      "actionNames": [
        "delete"
      ],
      "cascadeBehaviors": {
        "resourceGroup": "deny"
      }
    }
  }
}

DeployIfNotExists

Similar a AuditIfNotExists, una definición de directiva DeployIfNotExists ejecuta una implementación de plantilla cuando se cumple la condición. Las asignaciones de directivas con efecto establecido como DeployIfNotExists requieren una identidad administrada para realizar la corrección.

Nota

Las plantillas anidadas son compatibles con deployIfNotExists, pero las plantillas vinculadas no son compatibles actualmente.

Evaluación de DeployIfNotExists

DeployIfNotExists se ejecuta después de un retraso configurable cuando un proveedor de recursos controla una solicitud de creación o actualización de suscripciones o recursos y devuelve un código de estado correcto. La implementación de una plantilla se produce si no hay recursos relacionados o si los recursos definidos por ExistenceCondition no se evalúan como true. La duración de la implementación depende de la complejidad de los recursos incluidos en la plantilla.

Durante un ciclo de evaluación, las definiciones de directiva con un efecto DeployIfNotExists que coinciden con los recursos se marcan como no compatibles, pero no se realiza ninguna acción en dicho recurso. Los recursos no conformes existentes se pueden solucionar con una tarea de corrección.

Propiedades de DeployIfNotExists

La propiedad details del efecto DeployIfNotExists tiene todas las subpropiedades que definen los recursos relacionados con los que se establece la coincidencia y la implementación de plantilla que se ejecuta.

  • Type (obligatorio)
    • Especifica el tipo del recurso relacionado para coincidir.
    • Si el tipo es un tipo de recurso debajo del recurso de condición if, la directiva consultará los recursos de este tipo que estén dentro del ámbito del recurso evaluado. De lo contrario, las consultas de directiva dentro del mismo grupo de recursos o suscripción que el recurso evaluado dependen de existenceScope.
  • Nombre (opcional)
    • Especifica el nombre exacto del recurso para coincidir y hace que la directiva recupere un recurso específico en lugar de todos los recursos del tipo especificado.
    • Cuando los valores de condición para if.field.type y then.details.type coinciden, entonces el valor Name es necesario y debe ser [field('name')], o [field('fullName')] para un recurso secundario.

Nota:

Los segmentos deTipo y Nombre se pueden combinar para recuperar de forma genérica los recursos anidados.

Para recuperar un recurso específico, puede usar "type": "Microsoft.ExampleProvider/exampleParentType/exampleNestedType" y "name": "parentResourceName/nestedResourceName".

Para recuperar una colección de recursos anidados, se puede proporcionar un ? de carácter comodín en lugar del segmento de apellidos. Por ejemplo, "type": "Microsoft.ExampleProvider/exampleParentType/exampleNestedType" y "name": "parentResourceName/?". Esto se puede combinar con funciones de campo para acceder a los recursos relacionados con el recurso evaluado, como "name": "[concat(field('name'), '/?')]"."

  • ResourceGroupName (opcional)

    • Permite que la coincidencia del recurso relacionado provenga de un grupo de recursos diferente.
    • No se aplica si type es un recurso que estaría debajo del recurso de condición if.
    • El valor predeterminado es el grupo de recursos del recurso de la condición if.
    • Si se ejecuta una implementación de plantilla, se implementa en el grupo de recursos de este valor.
  • ExistenceScope (opcional)

    • Los valores permitidos son Subscription y ResourceGroup.
    • Establece el ámbito de donde obtener el recurso relacionado para que coincida.
    • No se aplica si type es un recurso que estaría debajo del recurso de condición if.
    • Para ResourceGroup, limitaría al grupo de recursos en ResourceGroupName si se especifica. Si no se especifica ResourceGroupName, limitaría al grupo de recursos de la condición if, que es el comportamiento predeterminado.
    • Para Subscription, se consulta toda la suscripción para el recurso relacionado. El ámbito de asignación debe establecerse en la suscripción o superior para una evaluación adecuada.
    • El valor predeterminado es ResourceGroup.
  • EvaluationDelay (opcional)

    • Especifica cuándo se debe evaluar la existencia de los recursos relacionados. El retraso solo se usa para las evaluaciones que son el resultado de una solicitud de creación o de actualización de recursos.
    • Los valores permitidos son AfterProvisioning, AfterProvisioningSuccess, AfterProvisioningFailure, o una duración ISO 8601 entre 0 y 360 minutos.
    • Los valores AfterProvisioning inspeccionan el resultado de aprovisionamiento del recurso que se evaluó en la condición IF de la regla de directiva. AfterProvisioning se ejecuta una vez completado el aprovisionamiento, independientemente del resultado. Si el aprovisionamiento tarda más de seis horas, se trata como un error a la hora de determinar los retrasos de evaluación de AfterProvisioning.
    • El valor predeterminado es PT10M (10 minutos).
    • La especificación de un retraso de evaluación largo puede hacer que el estado de cumplimiento registrado del recurso no se actualice hasta el siguiente desencadenador de evaluación.
  • ExistenceCondition (opcional)

    • Si no se especifica, todo recurso relacionado de type cumple con el efecto y no desencadena la implementación.
    • Utiliza el mismo lenguaje que la regla de directiva para la condición if, pero se evalúa individualmente en relación con cada recurso relacionado.
    • Si algún recurso relacionado coincidente se evalúa como true, se cumple la condición del efecto y no se desencadena la implementación.
    • Puede utilizar [field()] para comprobar la equivalencia con los valores en la condición if.
    • Por ejemplo, podría usarse para validar que el recurso primario (en la condición if) está en la misma ubicación de recursos que el recurso relacionado coincidente.
  • roleDefinitionIds (obligatorio)

  • DeploymentScope (opcional)

    • Los valores permitidos son Subscription y ResourceGroup.
    • Establece el tipo de implementación que se desencadena. La Suscripción indica una implementación a nivel de suscripción, ResourceGroup indica una implementación en un grupo de recursos.
    • En la Implementación debe especificarse una propiedad location al usar las implementaciones de nivel de suscripción.
    • El valor predeterminado es ResourceGroup.
  • Deployment (obligatorio)

    • Esta propiedad debe incluir la implementación de plantilla completa, ya que luego se pasaría a la API PUT Microsoft.Resources/deployments. Para más información, consulte Deployments REST API (API REST de implementaciones).
    • Las implementaciones de Microsoft.Resources/deployments anidadas en la plantilla deben usar nombres únicos para evitar la contención entre varias evaluaciones de directivas. El nombre de la implementación primaria se puede usar como parte del nombre de las implementaciones anidadas mediante [concat('NestedDeploymentName-', uniqueString(deployment().name))].

    Nota

    Todas las funciones dentro de la propiedad Deployment se evalúan como componentes de la plantilla, no la directiva. La excepción es la propiedad parameters que pasa los valores de la directiva a la plantilla. El valor en esta sección bajo el nombre de un parámetro de plantilla se usa para realizar este paso de valor (vea fullDbName en el ejemplo DeployIfNotExists).

Ejemplo de DeployIfNotExists

Ejemplo: evalúa las bases de datos de SQL Server para determinar si transparentDataEncryption está habilitado. De lo contrario, se ejecuta una implementación para habilitarlo.

"if": {
  "field": "type",
  "equals": "Microsoft.Sql/servers/databases"
},
"then": {
  "effect": "deployIfNotExists",
  "details": {
    "type": "Microsoft.Sql/servers/databases/transparentDataEncryption",
    "name": "current",
    "evaluationDelay": "AfterProvisioning",
    "roleDefinitionIds": [
      "/subscriptions/{subscriptionId}/providers/Microsoft.Authorization/roleDefinitions/{roleGUID}",
      "/providers/Microsoft.Authorization/roleDefinitions/{builtinroleGUID}"
    ],
    "existenceCondition": {
      "field": "Microsoft.Sql/transparentDataEncryption.status",
      "equals": "Enabled"
    },
    "deployment": {
      "properties": {
        "mode": "incremental",
        "template": {
          "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
          "contentVersion": "1.0.0.0",
          "parameters": {
            "fullDbName": {
              "type": "string"
            }
          },
          "resources": [
            {
              "name": "[concat(parameters('fullDbName'), '/current')]",
              "type": "Microsoft.Sql/servers/databases/transparentDataEncryption",
              "apiVersion": "2014-04-01",
              "properties": {
                "status": "Enabled"
              }
            }
          ]
        },
        "parameters": {
          "fullDbName": {
            "value": "[field('fullName')]"
          }
        }
      }
    }
  }
}

Disabled

Este efecto es útil para probar situaciones o cuando la definición de directiva ha parametrizado el efecto. Esta flexibilidad permite deshabilitar una única asignación en lugar de deshabilitar todas las asignaciones de la directiva.

Nota

Las definiciones de directiva que usan el efecto Disabled tienen el estado de cumplimiento predeterminado Compatible después de la asignación.

Una alternativa al efecto Disabled es enforcementMode, que se establece en la asignación de directiva. Cuando enforcementMode es Disabled, los recursos se siguen evaluando. El registro, como los registros de actividad, y el efecto de la directiva no se producen. Para más información, consulte Asignación de directivas: modo de cumplimiento.

Manual

El nuevo efecto manual permite certificar automáticamente el cumplimiento normativo de los recursos o ámbitos. A diferencia de otras definiciones de directiva que examinan activamente la evaluación, el efecto Manual permite cambios manuales en el estado de cumplimiento normativo. Para cambiar el cumplimiento normativo de un recurso o ámbito de destino de una directiva manual, debe crear una atestación. El procedimiento recomendado es diseñar directivas manuales destinadas al ámbito que define el límite de los recursos cuyo cumplimiento normativo necesita atestación.

Nota:

La compatibilidad con la directiva manual está disponible a través de varias iniciativas de cumplimiento normativo de Microsoft Defender for Cloud. Si es un cliente de Microsoft Defender for Cloud para el nivel Premium, consulte su introducción a la experiencia.

Actualmente, las siguientes iniciativas de directiva normativa incluyen definiciones de directivas que contienen el efecto manual:

  • FedRAMP High
  • FedRAMP Medium
  • HIPAA
  • HITRUST
  • ISO 27001
  • Microsoft CIS 1.3.0
  • Microsoft CIS 1.4.0
  • NIST SP 800-171 Rev. 2
  • NIST SP 800-53 Rev. 4
  • NIST SP 800-53 Rev. 5
  • PCI DSS 3.2.1
  • PCI DSS 4.0
  • SOC TSP
  • SWIFT CSP CSCF v2022

El ejemplo siguiente tiene como destino las suscripciones de Azure y establece el estado de cumplimiento normativo inicial en Unknown.

{
  "if": {
    "field": "type",
    "equals": "Microsoft.Resources/subscriptions"
  },
  "then": {
    "effect": "manual",
    "details": {
      "defaultState": "Unknown"
    }
  }
}

La defaultState propiedad tiene tres valores posibles:

  • Desconocido: el estado inicial y predeterminado de los recursos de destino.
  • Compatible: el recurso es conforme a sus estándares de directivas manuales
  • No compatible: el recurso no es conforme a sus estándares de directivas manuales

El motor de cumplimiento normativo de Azure Policy evalúa todos los recursos aplicables al estado predeterminado especificado en la definición (Unknown si no se especifica). Un Unknown estado de cumplimiento normativo indica que debe certificar manualmente el estado de cumplimiento normativo de los recursos. Si el estado del efecto no está especificado, el valor predeterminado es Unknown. El Unknown estado de cumplimiento normativo indica que usted mismo debe certificar el estado de cumplimiento normativo.

En la captura de pantalla siguiente se muestra cómo aparece una asignación de directiva manual con el Unknown estado en Azure Portal:

Resource compliance table in the Azure portal showing an assigned manual policy with a compliance reason of 'unknown.'

Cuando se asigna una definición de directiva con manual efecto, puede establecer los estados de cumplimiento normativo de los recursos o ámbitos de destino a través de atestaciones personalizadas. Las atestaciones también permiten proporcionar información complementaria opcional en forma de metadatos y vínculos a evidencias que acompañan al estado de cumplimiento normativo elegido. La persona que asigna la directiva manual puede recomendar una ubicación de almacenamiento predeterminada para la evidencia especificando la evidenceStorages propiedad de los metadatos de la asignación de directiva.

Modificar

Modify se usa para agregar, actualizar o quitar propiedades o etiquetas de una suscripción o un recurso durante la creación o la actualización. Un ejemplo habitual es la actualización de etiquetas en recursos como costCenter. Los recursos no conformes existentes se pueden solucionar con una tarea de corrección. Una sola regla de Modify puede tener cualquier número de operaciones. Las asignaciones de directivas con efecto establecido como Modify requieren una identidad administrada para realizar la corrección.

Modify admite las operaciones siguientes:

  • Agregar, reemplazar o quitar etiquetas de recursos. En el caso de las etiquetas, una directiva Modify siempre debe tener el elemento mode establecido en indexed a menos que el recurso de destino sea un grupo de recursos.
  • Agregar o reemplazar el valor del tipo de identidad administrada (identity.type) de máquinas virtuales y Virtual Machine Scale Sets. Solo puede modificar para identity.type máquinas virtuales o conjuntos de escalado de máquinas virtuales.
  • Agregar o reemplazar los valores de determinados alias.
    • Use Get-AzPolicyAlias | Select-Object -ExpandProperty 'Aliases' | Where-Object { $_.DefaultMetadata.Attributes -eq 'Modifiable' } en Azure PowerShell 4.6.0 o superior para obtener una lista de los alias que se pueden usar con Modify.

Importante

Si está administrando etiquetas, se recomienda usar Modify en lugar de Append, ya que Modify proporciona más tipos de operaciones y la posibilidad de corregir los recursos existentes. Sin embargo, se recomienda Append si no puede crear una identidad administrada o Modify no es compatible todavía con el alias de la propiedad del recurso.

Evaluación de Modify

Modify se evalúa antes de que un proveedor de recursos procese la solicitud durante la creación o actualización de un recurso. Las operaciones Modify se aplican al contenido de la solicitud cuando se cumple la condición if de la regla de la directiva. Cada operación Modify puede especificar una condición que determina cuándo se aplica. Las operaciones con evaluaciones de condiciónfalsa se omiten.

Cuando se especifica un alias, se realizan las siguientes comprobaciones adicionales para asegurarse de que la operación Modify no cambia el contenido de la solicitud de tal forma que el proveedor de recursos lo rechace:

  • La propiedad a la que se asigna el alias se marca como "modificable" en la versión de API de la solicitud.
  • El tipo de token de la operación Modify coincide con el tipo de token esperado para la propiedad en la versión de API de la solicitud.

Si se produce un error en cualquiera de estas comprobaciones, la evaluación de la directiva recurre al valor de conflictEffect especificado.

Importante

Se recomienda que las definiciones de Modify que incluyen alias usen el efecto de conflicto de auditoría para evitar errores en las solicitudes con versiones de API en las que la propiedad asignada no es "modificable". Si el mismo alias se comporta de manera diferente con cada versión de API, se pueden usar operaciones Modify condicionales para determinar la operación Modify usada para cada una.

Cuando una definición de directiva que utiliza el efecto Modify se ejecuta como parte de un ciclo de evaluación, no realiza cambios en los recursos que ya existen. En su lugar, marca cualquier recurso que cumple la condición if como no conforme.

Propiedades de Modify

La propiedad details del efecto Modify tiene todas las subpropiedades que definen los permisos necesarios para la corrección y las propiedades operations que se usan para agregar, actualizar o quitar valores de etiqueta.

  • roleDefinitionIds (obligatorio)
  • conflictEffect (opcional)
    • Determina qué definición de directiva "gana" si más de una modifica la misma propiedad o cuando la operación Modify no funciona en el alias especificado.
      • En el caso de los recursos nuevos o actualizados, la definición de la directiva con deny tiene prioridad. Las definiciones de directivas con Audit omiten todas las operaciones. Si más de una definición de directiva tiene el efecto deny, la solicitud se deniega como conflicto. Si todas las definiciones de directiva tienen audit, no se procesa ninguna de las operaciones de las definiciones de directiva en conflicto.
      • En el caso de los recursos existentes, si hay más de una definición de directiva que tenga el efecto deny, el estado de cumplimiento es Conflict. Si una o varias definiciones de directivas tienen el efecto deny, cada asignación devuelve un estado de cumplimiento de Non-compliant.
    • Valores disponibles: audit, deny, disabled.
    • El valor predeterminado es deny.
  • operations (obligatorio)
    • Una matriz de todas las operaciones de etiqueta que se van a llevar a cabo en los recursos coincidentes.
    • Propiedades:
      • operation (obligatorio)
        • Define qué acción se va a realizar en un recurso coincidente. Las opciones son: addOrReplace, Add, Remove. Add se comporta de forma similar al efecto Append.
      • field (obligatorio)
        • La etiqueta que se va a agregar, reemplazar o quitar. Los nombres de etiqueta deben seguir la misma convención de nomenclatura que otros campos.
      • value (opcional)
        • Valor en el que se va a establecer la etiqueta.
        • Esta propiedad es necesaria si operation es addOrReplace o Add.
      • condition (opcional)
        • Una cadena que contiene una expresión de lenguaje de Azure Policy con funciones de directiva que se evalúa como true o false.
        • No admite las siguientes funciones de directiva: field(), resourceGroup(), subscription().

Operaciones de Modify

La matriz de propiedades operations permite modificar varias etiquetas de maneras diferentes a partir de una única definición de directiva. Cada operación se compone de las propiedades operation, field y value. Operation determina qué hace la tarea de corrección en las etiquetas, field determina qué etiqueta se modifica y value define el nuevo valor de la etiqueta. En el ejemplo siguiente se realizan los siguientes cambios en las etiquetas:

  • Se establece la etiqueta environment en "Test", incluso si ya existe con otro valor.
  • Se quita la etiqueta TempResource.
  • Se establece la etiqueta Dept en el parámetro de directiva DeptName configurado en la asignación de directiva.
"details": {
  ...
  "operations": [
    {
      "operation": "addOrReplace",
      "field": "tags['environment']",
      "value": "Test"
    },
    {
      "operation": "Remove",
      "field": "tags['TempResource']",
    },
    {
      "operation": "addOrReplace",
      "field": "tags['Dept']",
      "value": "[parameters('DeptName')]"
    }
  ]
}

La propiedad operation tiene las siguientes opciones:

Operación Descripción
addOrReplace Agrega la propiedad o la etiqueta definidas y el valor al recurso, incluso si estas ya existen con un valor diferente.
Sumar Agrega la propiedad o la etiqueta definidas y el valor al recurso.
Remove Quita la propiedad o la etiqueta definidas del recurso.

Ejemplos de Modify

Ejemplo 1: se agrega la etiqueta environment y se reemplazan las etiquetas environment existentes por "Test":

"then": {
  "effect": "modify",
  "details": {
    "roleDefinitionIds": [
      "/providers/Microsoft.Authorization/roleDefinitions/b24988ac-6180-42a0-ab88-20f7382dd24c"
    ],
    "operations": [
      {
        "operation": "addOrReplace",
        "field": "tags['environment']",
        "value": "Test"
      }
    ]
  }
}

Ejemplo 2: se quita la etiqueta env y se agrega la etiqueta environment o se reemplazan las etiquetas environment existentes por un valor parametrizado:

"then": {
  "effect": "modify",
  "details": {
    "roleDefinitionIds": [
      "/providers/Microsoft.Authorization/roleDefinitions/b24988ac-6180-42a0-ab88-20f7382dd24c"
    ],
    "conflictEffect": "deny",
    "operations": [
      {
        "operation": "Remove",
        "field": "tags['env']"
      },
      {
        "operation": "addOrReplace",
        "field": "tags['environment']",
        "value": "[parameters('tagValue')]"
      }
    ]
  }
}

Ejemplo 3: Asegúrese de que una cuenta de almacenamiento no permita el acceso público a los blobs; la operación Modify solo se aplica cuando se evalúan solicitudes con una versión de API mayor o igual que 2019-04-01:

"then": {
  "effect": "modify",
  "details": {
    "roleDefinitionIds": [
      "/providers/microsoft.authorization/roleDefinitions/17d1049b-9a84-46fb-8f53-869881c3d3ab"
    ],
    "conflictEffect": "audit",
    "operations": [
      {
        "condition": "[greaterOrEquals(requestContext().apiVersion, '2019-04-01')]",
        "operation": "addOrReplace",
        "field": "Microsoft.Storage/storageAccounts/allowBlobPublicAccess",
        "value": false
      }
    ]
  }
}

Mutate (versión preliminar)

La mutación se usa en Azure Policy para Kubernetes para corregir los componentes del clúster de AKS, como los pods. Este efecto es específico solo de las definiciones de modo de directivaMicrosoft.Kubernetes.Data.

Para más información, vaya a Descripción de los clústeres de Azure Policy para Kubernetes.

Propiedades de mutate

  • mutationInfo (opcional)
    • No se puede usar con constraint, constraintTemplate, apiGroups o kinds.
    • No se puede parametrizar.
    • sourceType (obligatorio)
      • Define el tipo de origen para la restricción. Valores permitidos: PublicURL o Base64Encoded.
      • Si es PublicURL, se empareja con la propiedad url para proporcionar la ubicación de la plantilla de mutación. La ubicación debe ser públicamente accesible.

        Advertencia

        No use el URI de SAS ni tokens en url ni nada que pueda exponer un secreto.

Definiciones de directivas en capas

Un recurso puede verse afectado por varias asignaciones. Estas asignaciones pueden ser del mismo ámbito o de ámbitos diferentes. Cada una de estas asignaciones también es probable que tenga un efecto diferente al definido. La condición y el efecto de cada directiva se evalúan por separado. Por ejemplo:

  • Directiva 1
    • Restringe la ubicación de recursos a westus
    • Se asigna a la suscripción A.
    • Efecto deny.
  • Directiva 2
    • Restringe la ubicación de recursos a eastus
    • Se asigna al grupo de recursos B de la suscripción A.
    • Efecto audit.

Esta configuración produciría el resultado siguiente:

  • Cualquier recurso que ya esté en el grupo de recursos B en eastus es compatible con la directiva 2 y no compatible con la directiva 1
  • Cualquier recurso que ya esté en el grupo de recursos B y que no esté en eastus no es compatible con la directiva 2 ni con la directiva 1 si no está en westus
  • La directiva 1 deniega cualquier recurso nuevo en la suscripción A que no esté en westus
  • Cualquier recurso nuevo en la suscripción A y en el grupo de recursos B en westus se crea y no es compatible con la directiva 2

Si tanto la directiva 1 como la directiva 2 tienen efecto deny, la situación cambia a:

  • Cualquier recurso que ya esté en el grupo de recursos B y no en eastus no es compatible con la directiva 2
  • Cualquier recurso que ya esté en el grupo de recursos B y no en westus no es compatible con la directiva 1
  • La directiva 1 deniega cualquier recurso nuevo en la suscripción A que no esté en westus
  • Cualquier recurso nuevo que esté en el grupo de recursos B de la suscripción A se deniega.

Cada asignación se evalúa individualmente. Por lo tanto, no hay ninguna oportunidad de que un recurso se escape por diferencias en el ámbito. El resultado neto de las definiciones de directivas en capas se considera acumulativo en su mayoría restrictivo. Por ejemplo, si tanto la directiva 1 como la 2 tuviesen un efecto Deny, las definiciones de directivas en conflicto y superpuestas bloquearían un recurso. Si aún necesita que el recurso se cree en el ámbito de destino, revise las exclusiones en cada asignación para validar si las asignaciones de directivas adecuadas están incidiendo en los ámbitos adecuados.

Pasos siguientes