Protección de los parámetros
A veces es necesario pasar valores confidenciales a las implementaciones, como contraseñas y claves de API. Pero debe asegurarse de que estos valores están protegidos. En algunas situaciones, no quiere que la persona que crea la implementación conozca los valores de secreto. Otras veces, alguien escribirá el valor del parámetro al crear la implementación, pero debe asegurarse de que los valores de secreto no se registran. En esta unidad, aprenderá cómo proteger los parámetros.
Sugerencia
El mejor enfoque es evitar totalmente el uso de credenciales. Las identidades administradas para recursos de Azure pueden permitir que los componentes de la solución se comuniquen entre sí de forma segura y sin credenciales. Las identidades administradas no están disponibles para todos los recursos, pero es conveniente usarlas siempre que sea posible. Cuando no se pueda, tiene la opción de usar los enfoques descritos aquí.
Nota:
Los comandos de esta unidad se muestran para ilustrar conceptos. No los ejecute todavía. Pronto va a practicar lo que aprenderá aquí.
Definición de parámetros seguros
El decorador @secure se puede aplicar a los parámetros de cadena y objeto que pueden contener valores secretos. Al definir un parámetro como @secure, Azure no habilitará los valores de parámetros en los registros de implementación. Además, si crea la implementación de forma interactiva mediante la CLI de Azure o Azure PowerShell y necesita especificar los valores durante la implementación, el terminal no mostrará el texto en la pantalla.
Como parte de la migración de la aplicación de RR. HH., debe implementar una base de datos y un servidor lógico de Azure SQL. Aprovisionará el servidor lógico con un inicio de sesión y una contraseña de administrador. Dado que estos valores son confidenciales, deben estar protegidos. Esta es una declaración de ejemplo para crear dos parámetros de cadena para los detalles del administrador de SQL Server:
@secure()
param sqlServerAdministratorLogin string
@secure()
param sqlServerAdministratorPassword string
Observe que ninguno de los parámetros tiene especificado un valor predeterminado. Es conveniente evitar especificar valores predeterminados para nombres de usuario, contraseñas y otros secretos. De lo contrario, si alguien implementa la plantilla y no se da cuenta de que debe invalidar el valor, debilitará su seguridad porque obtendrá el valor predeterminado en lugar de algo que haya elegido.
Sugerencia
Asegúrese de que no crea salidas para datos confidenciales. Cualquier persona que tenga acceso al historial de implementación puede acceder a los valores de salida. Estas personas no son aptas para la administración de los secretos.
Evitar el uso de archivos de parámetros para los secretos
Como ha aprendido en la unidad anterior, los archivos de parámetros son una excelente manera de especificar un conjunto de valores de parámetros. A menudo, creará archivos de parámetros para cada entorno en el que va a realizar la implementación. En general, debe evitar el uso de archivos de parámetros para especificar valores de secretos. Los archivos de parámetros suelen guardarse en un sistema de control de versiones centralizado, como Git. Muchas personas podrían tener acceso a él en el futuro. No guarde datos confidenciales en los sistemas de control de versiones porque no están diseñados para almacenar este tipo de información.
Integración con Azure Key Vault
Azure Key Vault es un servicio diseñado para almacenar secretos y proporcionar acceso a ellos. Puede integrar las plantillas de Bicep con Key Vault mediante un archivo de parámetros con una referencia a un secreto de Key Vault.
Puede usar esta característica haciendo referencia al almacén de claves y al secreto en el archivo de parámetros. El valor nunca se expone porque solo se hace referencia a su identificador, que por sí solo no es ningún secreto. Al implementar la plantilla, Azure Resource Manager contactará con el almacén de claves y recuperará los datos.
Sugerencia
Puede hacer referencia a los secretos de los almacenes de claves que se encuentran en un grupo de recursos o una suscripción diferentes de aquellos en los que va a realizar la implementación.
Este es un archivo de parámetros que usa referencias de Key Vault para buscar el inicio de sesión y la contraseña de administrador del servidor lógico de SQL que se van a usar:
{
"$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentParameters.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"sqlServerAdministratorLogin": {
"reference": {
"keyVault": {
"id": "/subscriptions/f0750bbe-ea75-4ae5-b24d-a92ca601da2c/resourceGroups/PlatformResources/providers/Microsoft.KeyVault/vaults/toysecrets"
},
"secretName": "sqlAdminLogin"
}
},
"sqlServerAdministratorPassword": {
"reference": {
"keyVault": {
"id": "/subscriptions/f0750bbe-ea75-4ae5-b24d-a92ca601da2c/resourceGroups/PlatformResources/providers/Microsoft.KeyVault/vaults/toysecrets"
},
"secretName": "sqlAdminLoginPassword"
}
}
}
}
Observe que, en lugar de especificar un elemento value para cada uno de los parámetros, este archivo tiene un objeto reference, que contiene detalles del almacén de claves y el secreto.
Importante
El almacén de claves debe configurarse para permitir que Resource Manager acceso a los datos del almacén de claves durante las implementaciones de las plantillas. Además, el usuario que implementa la plantilla debe tener permiso para acceder al almacén de claves. Aprenderá a hacer estas tareas en la siguiente unidad.
Uso de Key Vault con los módulos
Los módulos permiten crear archivos de Bicep reutilizables que contienen un conjunto de recursos. Es habitual usar módulos para implementar partes de la solución. Los módulos pueden tener parámetros que aceptan valores de secretos, y puede usar la integración de Key Vault en Bicep para proporcionar estos valores de forma segura. Este es un archivo de Bicep de ejemplo que implementa un módulo y proporciona el valor del parámetro de secreto ApiKey obteniéndolo directamente de Key Vault:
resource keyVault 'Microsoft.KeyVault/vaults@2023-07-01' existing = {
name: keyVaultName
}
module applicationModule 'application.bicep' = {
name: 'application-module'
params: {
apiKey: keyVault.getSecret('ApiKey')
}
}
Observe que, en este archivo de Bicep, se hace referencia al recurso de Key Vault mediante la palabra clave existing. La palabra clave indica a Bicep que Key Vault ya existe, y este código es una referencia a ese almacén. Bicep no lo implementará de nuevo. Además, observe que el código usa el método getSecret() en el valor del parámetro apiKey del módulo. Se trata de una función especial de Bicep que solo se puede usar con parámetros de módulo seguros. Internamente, Bicep traduce esta expresión al mismo tipo de referencia de Key Vault que aprendió anteriormente.