Compartir a través de


Tutorial: Creación de una definición de directiva personalizada

Una definición de directiva personalizada permite a los clientes definir sus propias reglas para usar Azure. Estas reglas exigen a menudo:

  • Procedimientos de seguridad.
  • Cost Management.
  • Reglas específicas de la organización (como nombres o ubicaciones).

Sea cual sea el factor empresarial para crear una directiva personalizada, los pasos para definir la nueva directiva personalizada son los mismos.

Antes de crear una directiva personalizada, consulte los ejemplos de directivas para ver si ya existe una directiva que se ajuste a sus necesidades.

El enfoque para crear una directiva personalizada sigue estos pasos:

  • Identificar los requisitos empresariales
  • Asignar a cada requisito una propiedad de recurso de Azure
  • Asignar a la propiedad un alias
  • Determinar qué efecto usar
  • Elaborar la definición de directiva

Requisitos previos

Si no tiene una suscripción a Azure, cree una cuenta gratuita antes de empezar.

Identificación de los requisitos

Antes de crear la definición de directiva, es importante entender su intención. En este tutorial, se va a usar un requisito de seguridad empresarial común como objetivo para ilustrar los pasos necesarios:

  • Cada cuenta de almacenamiento debe estar habilitada para HTTPS.
  • Cada cuenta de almacenamiento debe estar deshabilitada para HTTP.

Los requisitos deben identificar claramente los estados de los recursos "será" y "no será".

Aunque definimos el estado esperado del recurso, no hemos definido lo que queremos hacer con recursos no compatibles. Azure Policy admite muchos efectos. En este tutorial, el requisito empresarial se define de este modo: impedir la creación de recursos si no cumplen con las reglas de negocio. Para alcanzar este objetivo, se usará el efecto deny. También se desea la opción para suspender la directiva en el caso de asignaciones específicas. Se usará el efecto disabled y el efecto se convertirá en un parámetro en la definición de directiva.

Determinación de las propiedades de recursos

En función de las necesidades de la organización, el recurso de Azure que se va a auditar con Azure Policy puede ser una cuenta de almacenamiento. Sin embargo, se desconocen las propiedades que se usarán en la definición de directiva. Para realizar la evaluación, Azure Policy utiliza la representación JSON del recurso, por lo que es necesario conocer las propiedades disponibles en dicho recurso.

Hay muchas maneras de determinar las propiedades de un recurso de Azure. Se analizará cada una de ellas en este tutorial:

  • Extensión de Azure Policy para VS Code.
  • Plantillas de Azure Resource Manager (plantillas de ARM)
    • Exportar un recurso existente.
    • Experiencia de creación.
    • Plantillas de inicio rápido (GitHub).
    • Documentos de referencia de plantilla.
  • Azure Resource Explorer.

Visualización de recursos en la extensión de VS Code

La extensión de VS Code se puede usar para examinar los recursos de su entorno y ver las propiedades de Resource Manager en cada recurso.

Plantillas de ARM

Hay varias maneras de examinar una plantilla de ARM que incluya la propiedad que quiere administrar.

Recurso existente en el portal

La manera más sencilla de buscar propiedades es examinar un recurso existente del mismo tipo. Los recursos que ya haya configurado con el valor que quiere aplicar también proporcionan el valor con el que comparar. Examine ese recurso concreto en la página Exportar plantilla en Configuración de Azure Portal.

Advertencia

La plantilla de Resource Manager exportada por Azure Portal no se puede conectar directamente a la propiedad deployment de una plantilla de Resource Manager de una definición de directiva deployIfNotExists.

Captura de pantalla de la página Exportar plantilla de un recurso existente en Azure Portal.

Al hacer esto mismo con una cuenta de almacenamiento se revela una plantilla similar a la de este ejemplo:

"resources": [
  {
    "comments": "Generalized from resource: '/subscriptions/{subscriptionId}/resourceGroups/myResourceGroup/providers/Microsoft.Storage/storageAccounts/mystorageaccount'.",
    "type": "Microsoft.Storage/storageAccounts",
    "sku": {
      "name": "Standard_LRS",
      "tier": "Standard"
    },
    "kind": "Storage",
    "name": "[parameters('storageAccounts_mystorageaccount_name')]",
    "apiVersion": "2018-07-01",
    "location": "westus",
    "tags": {
      "ms-resource-usage": "azure-cloud-shell"
    },
    "scale": null,
    "properties": {
      "networkAcls": {
        "bypass": "AzureServices",
        "virtualNetworkRules": [],
        "ipRules": [],
        "defaultAction": "Allow"
      },
      "supportsHttpsTrafficOnly": false,
      "encryption": {
        "services": {
          "file": {
            "enabled": true
          },
          "blob": {
            "enabled": true
          }
        },
        "keySource": "Microsoft.Storage"
      }
    },
    "dependsOn": []
  }
]

En properties es un valor denominado supportsHttpsTrafficOnly establecido en false. Esta propiedad se parece a la que se está buscando. Además, el type del recurso es Microsoft.Storage/storageAccounts. El tipo nos permite limitar la directiva a solo los recursos de este tipo.

Creación de un recurso en el portal

Otra manera mediante el portal es la experiencia de creación de recursos. Al crear una cuenta de almacenamiento mediante el portal, una opción en la pestaña Avanzadas es Transferencia de seguridad necesaria. Esta propiedad tiene las opciones Disabled (Deshabilitado) y Enabled (Habilitado). El icono de información tiene texto adicional que confirma que esta opción es probablemente la propiedad que buscamos. Pero el portal no dice el nombre de la propiedad en esta pantalla.

En la pestaña Revisar y crear, hay un vínculo en la parte inferior de la página a Descargar una plantilla para la automatización. Al seleccionar el vínculo se abre la plantilla que crea el recurso que se ha configurado. En este caso, se pueden ver dos trozos principales de información:

...
"supportsHttpsTrafficOnly": {
  "type": "bool"
}
...
"properties": {
  "accessTier": "[parameters('accessTier')]",
  "supportsHttpsTrafficOnly": "[parameters('supportsHttpsTrafficOnly')]"
}
...

Esta información indica el tipo de propiedad y también confirma que supportsHttpsTrafficOnly es la propiedad que se busca.

Plantillas de inicio rápido de GitHub

Las plantillas de inicio rápido de Azure en GitHub contienen cientos de plantillas de ARM creadas para distintos recursos. Estas plantillas pueden ser una excelente manera de encontrar la propiedad de recurso que se busca. Algunas propiedades pueden parecer lo que busca, pero controlan algo distinto.

Documentos de referencia de recursos

Para validar que supportsHttpsTrafficOnly es la propiedad correcta, compruebe la referencia de la plantilla de ARM correspondiente al recurso de cuenta de almacenamiento en el proveedor de almacenamiento. El objeto de propiedades tiene una lista de parámetros válidos. Al seleccionar el vínculo del objeto StorageAccountPropertiesCreateParameters se muestra una tabla con las propiedades aceptables. supportsHttpsTrafficOnly está presente y la descripción coincide con lo que estamos buscando en relación con los requisitos empresariales.

Azure Resource Explorer

Otra forma de explorar los recursos de Azure es mediante Azure Resource Explorer (versión preliminar). Esta herramienta usa el contexto de su suscripción, así que debe autenticarse en el sitio web con sus credenciales de Azure. Una vez autenticado, puede examinar por proveedores, suscripciones, grupos de recursos y recursos.

Busque un recurso de cuenta de almacenamiento y examine las propiedades. También vemos la propiedad supportsHttpsTrafficOnly aquí. Al seleccionar la pestaña Documentación, se puede ver que la descripción de la propiedad coincide con lo que se ha encontrado en los documentos de referencia anteriormente.

Búsqueda del alias de propiedad

Se ha identificado la propiedad de recurso, pero es necesario asignarle un alias.

Hay varias maneras de determinar los alias de un recurso de Azure. Se analizará cada una de ellas en este tutorial:

  • Extensión de Azure Policy para VS Code.
  • Azure CLI.
  • Azure PowerShell.

Obtención de alias en la extensión de VS Code

La extensión de Azure Policy para la extensión de VS Code facilita el examen de los recursos y la detección de alias.

Nota

La extensión de VS Code solo expone las propiedades del modo Administrador de recursos y no muestra ninguna propiedad del modo Proveedor de recursos.

Azure CLI

En la CLI de Azure, el grupo de comandos az provider se usa para buscar alias de recursos. Se va a filtrar por el espacio de nombres Microsoft.Storage según los detalles que se obtuvieron anteriormente sobre el recurso de Azure.

# Login first with az login if not using Cloud Shell

# Get Azure Policy aliases for type Microsoft.Storage
az provider show --namespace Microsoft.Storage --expand "resourceTypes/aliases" --query "resourceTypes[].aliases[].name"

En los resultados, vemos un alias admitido por las cuentas de almacenamiento llamado supportsHttpsTrafficOnly. La existencia de este alias significa que se puede escribir la directiva para aplicar los requisitos empresariales.

Azure PowerShell

En Azure PowerShell, el cmdlet Get-AzPolicyAlias se usa para buscar los alias de recurso. Filtre por el espacio de nombres Microsoft.Storage en función de los detalles que obtuvimos anteriormente sobre el recurso de Azure.

# Login first with Connect-AzAccount if not using Cloud Shell

# Use Get-AzPolicyAlias to list aliases for Microsoft.Storage
(Get-AzPolicyAlias -NamespaceMatch 'Microsoft.Storage').Aliases

Al igual que con la CLI de Azure, los resultados muestran un alias compatible con las cuentas de almacenamiento llamado supportsHttpsTrafficOnly.

Determinación del efecto para usar

Decidir qué hacer con los recursos no compatibles es casi tan importante como decidir qué se debe evaluar en primer lugar. Cada posible respuesta a un recurso no compatible se conoce como efecto. Los efectos controlan si se registra o bloquea el recurso no compatible, si tiene datos anexados o si tiene una implementación asociada para devolver el recurso a un estado de compatibilidad.

En nuestro ejemplo, deny es el efecto que se desea ya que no queremos tener recursos no conformes creados en el entorno de Azure. Auditar es una buena primera opción de efecto de directiva para determinar cuál es el efecto de una directiva antes de establecerla en deny. Una manera de facilitar el cambio del efecto por asignación es parametriza el efecto. Consulte los parámetros para obtener los detalles.

Elaboración de la definición

Ya se tienen los detalles de la propiedad y el alias de lo que se planea administrar. El siguiente paso es elaborar la regla de directiva propiamente dicha. Si no está familiarizado con el lenguaje de directiva, consulte la estructura de definición de directivas para saber cómo estructurar la definición de directiva. Esta es una plantilla vacía del aspecto de una definición de directiva:

{
  "properties": {
    "displayName": "<displayName>",
    "description": "<description>",
    "mode": "<mode>",
    "parameters": {
              <parameters>
    },
    "policyRule": {
      "if": {
              <rule>
      },
      "then": {
        "effect": "<effect>"
      }
    }
  }
}

Metadatos

Los tres primeros componentes son metadatos de la directiva. Es fácil proporcionar valores para estos componentes dado que ya se sabe para lo que se está creando la regla. El modo consiste principalmente en las etiquetas y la ubicación del recurso. Puesto que no es necesario limitar la evaluación a los recursos que admiten etiquetas, se debe usar el valor all para mode.

"displayName": "Deny storage accounts not using only HTTPS",
"description": "Deny storage accounts not using only HTTPS. Checks the supportsHttpsTrafficOnly property on StorageAccounts.",
"mode": "all",

Parámetros

Aunque no se ha usado un parámetro para cambiar la evaluación, sí queremos usar un parámetro para permitir el cambio del effect para la solución de problemas. Debe definir un parámetro effectType y limitarlo a solo deny y disabled. Estas dos opciones coinciden con nuestros requisitos empresariales. El bloque de parámetros finalizado es similar a este ejemplo:

"parameters": {
  "effectType": {
    "type": "string",
    "defaultValue": "Deny",
    "allowedValues": [
      "Deny",
      "Disabled"
    ],
    "metadata": {
      "displayName": "Effect",
      "description": "Enable or disable the execution of the policy"
    }
  }
},

Regla de directiva

Elaborar la regla de directiva es el paso final en la creación de la definición de directiva personalizada. Se han identificado dos instrucciones con las que realizar la prueba:

  • El type de la cuenta de almacenamiento es Microsoft.Storage/storageAccounts.
  • El valor de supportsHttpsTrafficOnly de la cuenta de almacenamiento no es true.

Como es necesario que ambas instrucciones sean true, se debe usar el operador lógico allOf. Se debe pasar el parámetro effectType al efecto en lugar de realizar una declaración estática. La regla finalizada se parece a la de este ejemplo:

"if": {
  "allOf": [
    {
      "field": "type",
      "equals": "Microsoft.Storage/storageAccounts"
    },
    {
      "field": "Microsoft.Storage/storageAccounts/supportsHttpsTrafficOnly",
      "notEquals": "true"
    }
  ]
},
"then": {
  "effect": "[parameters('effectType')]"
}

Definición completada

Con las tres partes de la directiva definidas, esta es la definición completada:

{
  "properties": {
    "displayName": "Deny storage accounts not using only HTTPS",
    "description": "Deny storage accounts not using only HTTPS. Checks the supportsHttpsTrafficOnly property on StorageAccounts.",
    "mode": "all",
    "parameters": {
      "effectType": {
        "type": "string",
        "defaultValue": "Deny",
        "allowedValues": [
          "Deny",
          "Disabled"
        ],
        "metadata": {
          "displayName": "Effect",
          "description": "Enable or disable the execution of the policy"
        }
      }
    },
    "policyRule": {
      "if": {
        "allOf": [
          {
            "field": "type",
            "equals": "Microsoft.Storage/storageAccounts"
          },
          {
            "field": "Microsoft.Storage/storageAccounts/supportsHttpsTrafficOnly",
            "notEquals": "true"
          }
        ]
      },
      "then": {
        "effect": "[parameters('effectType')]"
      }
    }
  }
}

La definición completada se puede usar para crear otra directiva. El portal y cada SDK (la CLI de Azure, Azure PowerShell y API REST) aceptan la definición de diferentes formas, así que revise los comandos de cada una para validar el uso correcto. A continuación, asígnela, con el efecto parametrizado, a los recursos adecuados para administrar la seguridad de sus cuentas de almacenamiento.

Limpieza de recursos

Si terminó de trabajar con los recursos de este tutorial, use los pasos siguientes para eliminar todas las asignaciones y definiciones que ha creado:

  1. Seleccione Definiciones (o Asignaciones si trata de eliminar una asignación) en Creación en el lado izquierdo de la página de Azure Policy.

  2. Busque la nueva definición de iniciativa o directiva (o asignación) que quiere quitar.

  3. Haga clic con el botón derecho en la fila o seleccione los puntos suspensivos al final de la definición (o asignación) y elija Eliminar definición (o Eliminar asignación ).

Revisar

En este tutorial, ha realizado correctamente las tareas siguientes:

  • Ha identificado los requisitos empresariales
  • Ha asignado a cada requisito una propiedad de recurso de Azure
  • Ha asignado a la propiedad un alias
  • Ha determinado el efecto que se usará
  • Ha elaborado la definición de directiva

Pasos siguientes

A continuación, usará su definición de directiva personalizada para crear y asignar una directiva: