¿Qué es Azure Policy?

Azure Policy ayuda a aplicar los estándares de la organización y a evaluar el cumplimiento a escala. Mediante su panel de cumplimiento, proporciona una vista agregada para evaluar el estado general del entorno, con la posibilidad de explorar en profundidad hasta el nivel de recurso y directiva. También ayuda al cumplimiento de los recursos gracias a la corrección masiva de los recursos existentes y la corrección automática de nuevos recursos.

Nota

Para más información sobre la corrección, consulte Corrección de recursos no compatibles con Azure Policy.

Entre los casos de uso comunes de Azure Policy se incluye la implementación de la gobernanza para la coherencia de los recursos, el cumplimiento normativo, la seguridad, el costo y la administración. Las definiciones de directiva de estos casos de uso comunes ya están disponibles en el entorno de Azure como complementos para ayudarle a comenzar.

En concreto, algunas de las acciones de gobernanza útiles que puede aplicar con Azure Policy incluyen las siguientes:

  • Asegurarse de que el equipo implementa recursos de Azure solo en regiones permitidas
  • Aplicar de forma coherente las etiquetas taxonómicas
  • Requerir recursos para enviar registros de diagnóstico a un área de trabajo de Log Analytics

Es importante reconocer que, con la introducción de Azure Arc, puede ampliar la gobernanza basada en directivas a distintos proveedores de nube e incluso a los centros de datos locales.

Todos los datos y objetos de Azure Policy se cifran en reposo. Para más información, consulte Cifrado en reposo de datos de Azure.

Información general

Para evaluar los recursos y acciones de Azure, Azure Policy compara las propiedades de esos recursos con las reglas de negocio. Estas reglas de negocios, descritas en formato JSON, se conocen como definiciones de directiva. Para simplificar la administración, se pueden agrupar varias reglas de negocio para formar una iniciativa de directiva (a veces conocida como policySet). Una vez formadas las reglas de negocio, se asigna la definición o la iniciativa de directiva a cualquier ámbito de recursos que admita Azure, como grupos de administración, suscripciones, grupos de recursos o recursos individuales. La asignación se aplica a todos los recursos dentro del ámbito de Resource Manager de esa asignación. Si es necesario, se pueden excluir los subámbitos. Para más información, consulte Ámbito de Azure Policy.

Azure Policy usa un formato JSON para formar la lógica que la evaluación emplea para determinar si un recurso es compatible o no. Las definiciones incluyen metadatos y la regla de directiva. La regla definida puede usar funciones, parámetros, operadores lógicos, condiciones y alias de propiedad para coincidir exactamente con el escenario deseado. La regla de directiva determina qué recursos del ámbito de la asignación se evalúan.

Descripción de los resultados de evaluación

Los recursos se evalúan en momentos concretos durante el ciclo de vida de los recursos, el ciclo de vida de la asignación de directivas y la evaluación de cumplimiento periódica continua. Estos son los acontecimientos o eventos que hacen que se evalúe un recurso:

  • Un recurso se crea o actualiza en un ámbito con una asignación de directiva.
  • Una directiva o iniciativa se asigna recientemente a un ámbito.
  • Una directiva o iniciativa que ya está asignada a un ámbito se actualiza.
  • Durante el ciclo de evaluación de cumplimiento estándar, que se produce una vez cada 24 horas.

Para más información sobre cuándo y cómo se realiza la evaluación de directivas, consulte Desencadenadores de evaluación.

Control de la respuesta a una evaluación

Las reglas de negocio para administrar recursos no compatibles varían considerablemente según la organización. Entre los ejemplos de la forma en que una organización desea que la plataforma responda a un recurso no compatible se incluyen:

  • Denegar el cambio de recursos
  • Registrar el cambio en el recurso
  • Modificar el recurso antes del cambio
  • Modificar el recurso después del cambio
  • Implementar recursos compatibles relacionados
  • Bloqueo de acciones en recursos

Azure Policy hace posible cada una de estas respuestas empresariales mediante la aplicación de efectos. Los efectos se establecen en la parte de la definición de directiva de la regla de directiva.

Corrección de recursos no compatibles

Aunque estos efectos influyen principalmente sobre un recurso cuando este se crea o actualiza, Azure Policy también admite el tratamiento de recursos no compatibles existentes sin necesidad de modificar ese recurso. Para más información sobre cómo conseguir que los recursos existentes sean compatibles, consulte cómo corregir los recursos.

Introducción en vídeo

La siguiente introducción de Azure Policy es de la compilación 2018. Para descargar diapositivas o el vídeo, visite Govern your Azure environment through Azure Policy (Gobierno de un entorno de Azure mediante Azure Policy) en Channel 9.

Introducción

Azure Policy y Azure RBAC

Hay algunas diferencias importantes entre Azure Policy y el control de acceso basado en rol de Azure (Azure RBAC). Para evaluar el estado, Azure Policy examina las propiedades de los recursos que se representan en Resource Manager y las propiedades de algunos proveedores de recursos. Azure Policy garantiza que el estado de los recursos sea compatible con las reglas de negocio sin importar quién hizo el cambio o quién tiene permisos para hacerlo. Con el efecto DenyAction, Azure Policy también puede bloquear ciertas acciones en los recursos. Algunos recursos de Azure Policy, como las definiciones de directivas, las definiciones de iniciativas y las asignaciones, son visibles para todos los usuarios. Este diseño permite la transparencia a todos los usuarios y servicios para saber qué reglas de directiva se establecen en su entorno.

Azure RBAC se centra en la administración de acciones del usuario en ámbitos diferentes. Si es necesario controlar alguna acción en función de la información del usuario, Azure RBAC es la herramienta idónea. Incluso si un individuo tiene acceso para realizar una acción, si el resultado es un recurso no compatible, Azure Policy sigue bloqueando la creación o la actualización.

La combinación de Azure RBAC y Azure Policy proporciona un control completo del ámbito en Azure.

Permisos de Azure RBAC en Azure Policy

Azure Policy tiene varios permisos, conocidos como operaciones, en dos proveedores de recursos:

Muchos roles integrados conceden permiso a recursos de Azure Policy. El rol Colaborador de directiva de recursos incluye la mayoría de las operaciones de Azure Policy. El rol Propietario tiene derechos completos. Tanto el rol Colaborador como el rol Lector tienen acceso a todas las operaciones de lectura de Azure Policy.

Colaborador puede desencadenar la corrección de recursos, pero no puede crear ni actualizar definiciones y asignaciones. Administrador de acceso de usuario es necesario para conceder la identidad administrada en los permisos necesarios de las asignaciones deployIfNotExists o modify.

Nota

Todos los objetos de la directiva, como las definiciones, iniciativas y asignaciones, se pueden leer mediante todos los roles de su ámbito. Por ejemplo, una asignación de directiva con alcance a una suscripción de Azure podrá leerse por todos los titulares de roles en el alcance de la suscripción y en niveles inferiores.

Si ninguno de los roles integrados tiene los permisos necesarios, cree un rol personalizado.

Las operaciones de Azure Policy pueden tener un importante impacto en el entorno de Azure. Solo se debe asignar el conjunto mínimo de permisos necesarios para realizar una tarea. Estos permisos no se deben conceder a los usuarios que no los necesiten.

Nota:

La identidad administrada de una asignación de directiva deployIfNotExists or modify necesita permisos suficientes para crear o actualizar los recursos de destino. Para más información, consulte Configurar definiciones de directiva para la corrección.

Requisito de permisos especiales para Azure Policy con Azure Virtual Network Manager

Azure Virtual Network Manager (versión preliminar) le permite aplicar directivas de seguridad y administración coherentes a varias redes virtuales (VNet) de Azure en toda la infraestructura en la nube. Los grupos dinámicos de Azure Virtual Network Manager (AVNM) usan definiciones de Azure Policy para evaluar la pertenencia a la red virtual en esos grupos.

Para crear, editar o eliminar directivas de grupos dinámicos de Azure Virtual Network Manager, necesita lo siguiente:

  • Permisos de lectura y escritura de Azure RBAC en la directiva subyacente
  • Permisos de RBAC de Azure para unirse al grupo de red (no se admite la autorización de administración clásica).

En concreto, el permiso necesario del proveedor de recursos es Microsoft.Network/networkManagers/networkGroups/join/action.

Importante

Para modificar los grupos dinámicos de AVNM, solo debe tener acceso mediante la asignación de roles de Azure RBAC. No se admite la autorización heredada ni de administración clásica; esto significa que si a la cuenta solo se le asignó el rol de suscripción de coadministrador, no tendría permisos en los grupos dinámicos de AVNM.

Recursos que abarca Azure Policy

Aunque se puede asignar una directiva en el nivel de grupo de administración, solo se evalúan los recursos en el nivel de suscripción o grupo de recursos.

En el caso de algunos proveedores de recursos, como Configuración de la máquina, Azure Kubernetes Service y Azure Key Vault, hay una integración más profunda para administrar valores de configuración y objetos. Para más información, vaya a Modos del proveedor de recursos.

Recomendaciones para la administración de directivas

A continuación, se ofrecen algunos consejos e indicaciones que se deben tener en cuenta:

  • Comience con un efecto audit o auditIfNotExist, en lugar de un efecto de cumplimiento (deny, modify, deployIfNotExist), para realizar un seguimiento del impacto de la definición de directiva en los recursos de su entorno. Si ya tiene scripts implementados para escalar automáticamente las aplicaciones, el hecho de establecer un efecto de cumplimiento puede dificultar las tareas de automatización que ya tiene implementadas.

  • Considere las jerarquías organizativas al crear definiciones y asignaciones. Se recomienda crear definiciones a niveles más altos, como suscripción o grupo de administración. A continuación, cree la asignación en el siguiente nivel secundario. Si crea una definición en un grupo de administración, se puede limitar la asignación a una suscripción o un grupo de recursos dentro de ese grupo de administración.

  • Se recomienda crear y asignar las definiciones de iniciativa incluso para una definición de directiva única. Por ejemplo, tiene la definición de directiva policyDefA y la crea en la definición de iniciativa initiativeDefC. Si crea otra definición de directiva más adelante para policyDefB con objetivos similares a policyDefA, puede agregarla a initiativeDefC y realizar un seguimiento conjunto.

    • Una vez creada una asignación de iniciativa, las definiciones agregadas a la iniciativa también forman parte de las asignaciones de esa iniciativa.

    • Cuando se evalúa una asignación de iniciativa, también se evalúan todas las directivas incluidas en la iniciativa. Si necesita evaluar una directiva de forma individual, es mejor no incluirla en una iniciativa.

  • Administre los recursos de Azure Policy como código con revisiones manuales de los cambios realizados en las definiciones de directivas, iniciativas y asignaciones. Para más información sobre los patrones y las herramientas sugeridos, consulte Diseño Azure Policy flujos de trabajo de código.

Objetos de Azure Policy

Definición de directiva

El proceso de creación e implementación de una directiva en Azure Policy comienza con la creación de una definición de directiva. Cada definición de directiva tiene condiciones que regulan su aplicación. Además, tiene un efecto definido que se produce cuando se cumplen las condiciones.

En Azure Policy, se ofrecen varias directivas integradas que están disponibles de manera predeterminada. Por ejemplo:

  • Allowed Storage Account SKUs (SKU permitidas de cuentas de almacenamiento) (denegar): determina si una cuenta de almacenamiento que se va a implementar se engloba dentro de un conjunto de tamaños de SKU. Su efecto es denegar todas las cuentas de almacenamiento que no cumplen el conjunto de tamaños de SKU definidos.
  • Allowed Resource Type (Tipo de recurso permitido) (denegar): define los tipos de recursos que se pueden implementar. Su efecto es denegar todos los recursos que no forman parte de esta lista definida.
  • Ubicaciones permitidas (denegar): restringe las ubicaciones disponibles para los nuevos recursos. Su efecto se utiliza para exigir los requisitos de cumplimiento de replicación geográfica.
  • Allowed Virtual Machine SKUs (SKU de máquina virtual permitidas) (denegar): especifica un conjunto de SKU de máquina virtual que se pueden implementar.
  • Add a tag to resources (Agregar una etiqueta a los recursos) (modificar): aplica una etiqueta obligatoria y su valor predeterminado si la solicitud de implementación no la especifica.
  • Not allowed resource types (Tipos de recursos no permitidos) (denegar): impide la implementación de una lista de tipos de recursos.

Para implementar estas definiciones de directiva (tanto las definiciones integradas como las personalizadas), primero debe asignarlas. Puede asignar cualquiera de estas directivas a través de Azure Portal, PowerShell o la CLI de Azure.

La evaluación de la directiva se realiza con distintas acciones, como la asignación de directivas o las actualizaciones de directiva. Para obtener una lista completa, vea desencadenadores de evaluación de directivas.

Para obtener más información sobre las estructuras de las definiciones de directiva, consulte Estructura de definición de directiva.

Los parámetros de directiva permiten simplificar la administración de directivas reduciendo el número de definiciones de directiva que debe crear. Cuando crea una definición de directiva, puede definir parámetros para que sea más genérica. Después, puede volver a usar esa definición de directiva para diferentes escenarios. Para ello, transmita distintos valores al asignar la definición de directiva. Por ejemplo, especifique un conjunto de ubicaciones para una suscripción.

Los parámetros se definen cuando se crea una definición de directiva. Cuando se define un parámetro, se le asigna un nombre y, de manera opcional, un valor. Por ejemplo, podría definir un parámetro para una directiva denominada location. Después, puede asignarle valores diferentes, como EastUS o WestUS, al asignar una directiva.

Para más información sobre los parámetros de directiva, vea Estructura de definición: Parámetros.

Definición de iniciativa

Una definición de iniciativa es una colección de definiciones de directiva personalizadas para alcanzar un único objetivo general. Las definiciones de iniciativa simplifican la administración y asignación de las definiciones de directiva. Tal simplificación se realiza mediante la agrupación de un conjunto de directivas como un solo elemento. Por ejemplo, podría crear una iniciativa titulada Habilitación de la supervisión en Microsoft Defender for Cloud, con el objetivo de supervisar todas las recomendaciones de seguridad disponibles en la instancia de Microsoft Defender for Cloud.

Nota:

El SDK, como CLI de Azure y Azure PowerShell, usa propiedades y parámetros denominados PolicySet para hacer referencia a las iniciativas.

En esta iniciativa, tendría definiciones de directiva como las siguientes:

  • Supervisar SQL Database sin cifrar en Microsoft Defender for Cloud, para supervisar servidores y bases de datos SQL sin cifrar.
  • Supervisar las vulnerabilidades del SO en Microsoft Defender for Cloud, para supervisar los servidores que no cumplen con la base de referencia configurada.
  • Supervisar Endpoint Protection omitido en Microsoft Defender for Cloud, para supervisar los servidores que no tienen instalado un agente de protección de los puntos de conexión.

Al igual que los parámetros de directiva, los parámetros de iniciativa permiten simplificar la administración de iniciativas mediante la reducción de la redundancia. Los parámetros de iniciativa son aquellos que las definiciones de directiva usan dentro de la iniciativa.

Por ejemplo, imagine un escenario en el que tiene la definición de una iniciativa (initiativeC), con las definiciones de directiva policyA y policyB, y que cada una de ellas espera un tipo diferente de parámetro:

Directiva Nombre del parámetro tipo del parámetro Nota:
policyA allowedLocations array Este parámetro espera una lista de cadenas para un valor, porque el tipo de parámetro está definido como una matriz
policyB allowedSingleLocation string Este parámetro espera una palabra para un valor, porque el tipo de parámetro se definió como una cadena

En este escenario, tiene tres opciones en el momento de definir los parámetros de iniciativa para initiativeC:

  • Use los parámetros de las definiciones de directiva dentro de esta iniciativa: en este ejemplo, allowedLocations y allowedSingleLocation se convierten en parámetros de iniciativa para initiativeC.
  • Proporcione valores a los parámetros de las definiciones de directiva dentro de esta definición de iniciativa. En este ejemplo, puede proporcionar una lista de ubicaciones al parámetro de policyA, allowedLocations, y al parámetro de policyB, allowedSingleLocation. También puede proporcionar valores cuando asigne esta iniciativa.
  • Proporcione una lista de las opciones de value que se puede usar cuando se asigna esta iniciativa. Cuando asigna esta iniciativa, los parámetros inherentes de las definiciones de directiva dentro de la iniciativa solo pueden tener valores provenientes de esta lista.

Al crear las opciones de valor en una definición de iniciativa, no se puede proporcionar un valor diferente durante la asignación de la iniciativa, porque no forma parte de la lista.

Para más información sobre las estructuras de las definiciones de iniciativa, consulte Estructura de definición de iniciativa.

Assignments

Una asignación es una definición o una iniciativa de directiva que se ha asignado a un ámbito concreto. Este ámbito puede ir desde un grupo de administración a un recurso individual. El término ámbito hace referencia a todos los recursos, grupos de recursos, suscripciones o grupos de administración a los que se asigna la definición. Todos los recursos secundarios heredan las asignaciones. Este diseño conlleva que una definición aplicada a un grupo de recursos también se aplique a los recursos de dicho grupo. Sin embargo, puede excluir un subámbito de la asignación.

Por ejemplo, en el ámbito de la suscripción, puede asignar una definición que impida la creación de recursos de red. También podría excluir un grupo de recursos en la suscripción que está diseñado para la infraestructura de red. De esta forma, concede acceso a este grupo de recursos de red a los usuarios de confianza con la creación de recursos de red.

En otro ejemplo, podría asignar una definición de lista de tipos de recursos permitidos en el nivel de grupo de administración. Luego, puede asignar una directiva más permisiva (que permita más tipos de recursos) en un grupo de administración secundario o incluso directamente en las suscripciones. Sin embargo, este ejemplo podría no funcionar porque Azure Policy es un sistema de denegación explícito. En su lugar, debe excluir el grupo de administración secundario o la suscripción de la asignación de nivel de grupo de administración. Después, puede asignar la definición más permisiva en el grupo de administración secundario o en el nivel de suscripción. Si alguna asignación tiene como resultado la denegación de un recurso, la única manera de permitir el recurso es modificar la directiva de denegación.

Las asignaciones de directivas siempre usan el estado más reciente de su definición o iniciativa asignadas al evaluar los recursos. Si se cambia una definición de directiva que ya está asignada, todas las asignaciones existentes de esa definición usarán la lógica actualizada al realizar la evaluación.

Para más información sobre la configuración de asignaciones mediante el portal, consulte Creación de una asignación de directiva para identificar recursos no compatibles en el entorno de Azure. También hay pasos disponibles para PowerShell y la CLI de Azure. Para más información sobre la estructura de asignación, consulte la estructura de asignaciones.

Número máximo de objetos de Azure Policy

Hay un número máximo de cada tipo de objeto de Azure Policy. Para las definiciones, una entrada de Scope significa el grupo de administración o la suscripción. En el caso de las asignaciones y exenciones, una entrada de Scope significa el grupo de administración, la suscripción, el grupo de recursos o el recurso individual.

Where Qué Número máximo
Ámbito Definiciones de directiva 500
Ámbito Definiciones de iniciativa 200
Inquilino Definiciones de iniciativa 2,500
Ámbito Asignaciones de iniciativas o directivas 200
Ámbito Exenciones 1000
Definición de directiva Parámetros 20
Definición de iniciativa Directivas 1000
Definición de iniciativa Parámetros 400
Asignaciones de iniciativas o directivas Exclusiones (notScopes) 400
Regla de directiva Condicionales anidados 512
Tarea de corrección Recursos 50.000
Definición de la política, iniciativa o solicitud de asignación Bytes 1 048 576

Las reglas de directiva tienen límites adicionales respecto al número de condiciones y su complejidad. Consulte Límites de reglas de directiva para obtener más detalles.

Pasos siguientes

Ahora que tiene información general acerca de Azure Policy y algunos de los conceptos clave, se recomienda seguir estos pasos: