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:
- Prácticas de seguridad
- Administración de costos
- 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 implicados:
- 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 se ha definido el estado esperado del recurso, no se ha definido aún lo que se quiere hacer con los 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 son compatibles con las reglas de negocio. Para alcanzar este objetivo, se usará el efecto Denegar. También se desea la opción para suspender la directiva en el caso de asignaciones específicas. Por lo tanto, se usará el efecto Deshabilitado 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.
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 propiedades hay un valor llamado supportsHttpsTrafficOnly establecido en false. Esta propiedad se parece a la que se está buscando. Además, el tipo 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 Security transfer required (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 busca. Sin embargo, 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 Resource Manager creadas para distintos recursos. Estas plantillas pueden ser una excelente manera de encontrar la propiedad de recurso que se busca. Puede que algunas propiedades parezcan ser lo que busca, sin embargo, es necesario controlar algo más.
Documentos de referencia de recursos
Para validar que supportsHttpsTrafficOnly es la propiedad correcta, compruebe la referencia de la plantilla de Resource Manager 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 StorageAccountPropertiesCreateParameters-object se muestra una tabla de propiedades aceptables. supportsHttpsTrafficOnly existe y la descripción coincide con lo que se busca para satisfacer 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. Aquí también se puede ver la propiedad supportsHttpsTrafficOnly. 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 tienen 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, se puede ver un alias compatible con 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. Se va a filtrar por el espacio de nombres Microsoft.Storage según los detalles que se tienen 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, la denegación es el efecto que se desea ya que no queremos tener recursos no compatibles creados en el entorno de Azure. Auditar es una buena primera opción de efecto de directiva para determinar de qué modo afecta una directiva antes de establecerla en Denegar. Una manera de facilitar el cambio del efecto por asignación es parametriza el efecto. Consulte a continuación los parámetros para saber cómo hacerlo.
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 propia regla de directiva. Si aún 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 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, no queremos usar un parámetro para permitir cambiar el efecto para la solución de problemas. Se definirá un parámetro effectType y se limitará 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 tipo de cuenta de almacenamiento es Microsoft.Storage/storageAccounts
- La cuenta de almacenamiento Microsoft.Storage/storageAccounts no es true
Como es necesario que ambas instrucciones sean true, se va a usar el operador lógicoallOf. Se 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 creadas anteriormente:
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.
Busque la nueva definición de iniciativa o directiva (o asignación) que quiere quitar.
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: