¿Cómo puedes hacer que las organizaciones sean más compatibles con Microsoft Azure?

Las organizaciones que utilizan Microsoft Azure cumplen con las normativas (HIPAA, GDPR, PCI DSS, CCPA, NYDFS y estándares similares) mediante una combinación de Azure Policy, Microsoft Defender for Cloud, Microsoft Purview Compliance Manager y las opciones de control de claves de Azure Key Vault. Esto es importante porque Azure Blueprints, una de las herramientas en las que este sector ha confiado durante años, se está retirando gradualmente hasta el 31 de enero de 2027. Acción recomendada: migre cualquier sistema de gobernanza basado en Blueprints a Azure Deployment Stacks y Template Specs ahora, antes de que finalice el plazo de migración.

Publicado: febrero de 2022. Actualizado: agosto de 2026. Revisado por el equipo de asesoría en cumplimiento normativo de Encryption Consulting.

Para obtener información básica sobre Azure Key Vault, consulte Servicios de Microsoft Azure: Azure Key Vault . Para comparar la administración de claves de Azure con la de AWS y GCP, consulte AWS KMS frente a Azure Key Vault frente a GCP KMS . Para obtener información sobre identidad basada en certificados en la nube, consulte PKI basada en la nube: GCP, AWS y Azure.

¿Qué implica el cumplimiento normativo para las organizaciones que operan en Azure?

El cumplimiento normativo implica cumplir con los estándares específicos de seguridad y privacidad que se aplican al sector y la base de clientes de una organización, como HIPAA y HITECH para datos sanitarios, GDPR para datos personales europeos, PCI DSS para datos de tarjetas de pago y normativas estatales como CCPA y NYDFS. Cada estándar establece sus propios controles mínimos, por lo que una organización debe adaptar sus cargas de trabajo de Azure a los estándares que le correspondan, en lugar de asumir que una postura de seguridad genérica los abarca todos. Azure no garantiza el cumplimiento por sí solo; proporciona los controles subyacentes (cifrado, gestión de acceso, supervisión y herramientas de auditoría) que la organización configura y opera para cumplir con dichos estándares.

¿Azure Blueprints sigue siendo una herramienta de cumplimiento normativo en la que debería confiar?

No. Azure Blueprints, que antes era una forma común de empaquetar artefactos de gobernanza (directivas, asignaciones de roles y plantillas de recursos) en un marco reutilizable y aprobado por la organización, se está retirando gradualmente. Cualquier arquitectura de cumplimiento que aún dependa de Blueprints necesita un plan de migración ahora, no un plan para elaborarlo más adelante.

Fecha	Que cambios
31 de julio de 2026	Ya no es posible crear nuevas definiciones de planos ni nuevas versiones de las definiciones existentes.
31 de octubre de 2026	Las definiciones existentes ya no se pueden modificar; tampoco se pueden crear nuevas asignaciones.
31 de diciembre de 2026	Las asignaciones existentes ya no se pueden modificar.
Enero 31, 2027	Retirada definitiva: la API de planos deja de responder, se elimina el acceso al portal y se borran todos los artefactos de planos que no se hayan exportado previamente.

La solución recomendada por Microsoft combina dos servicios: Azure Deployment Stacks gestiona la asignación, la implementación y la administración del ciclo de vida (incluida la aplicación de restricciones de asignación, reemplazando los bloqueos de Blueprint), mientras que Template Specs o un repositorio Git gestionan el almacenamiento y el control de versiones de las definiciones. Exporte todas las definiciones, versiones y asignaciones de planos existentes mucho antes del 31 de enero de 2027, ya que cualquier dato que no se haya exportado para esa fecha no podrá recuperarse.

Azure Policy no se ve afectado por esta retirada y sigue siendo la herramienta actual para definir y aplicar reglas de negocio a los recursos de Azure; siempre fue el motor de gobernanza subyacente a Blueprints, y continuará funcionando por sí solo después de que Blueprints desaparezca.

¿Cómo funciona el control de claves nativas frente al control de claves externas en Azure Key Vault?

Azure Key Vault y sus servicios relacionados ofrecen varios niveles de custodia de claves, cada uno con sus respectivas ventajas y desventajas en cuanto a coste, aislamiento y quién controla en última instancia el material de clave:

Nivel de control de claves	Cómo funciona	Mejor ajuste
Key Vault Standard (nativo, software)	Las claves están protegidas por software en un entorno multiusuario.	Opción predeterminada para la mayoría de las cargas de trabajo; menor coste.
Key Vault Premium (nativo, con respaldo HSM)	Las claves están protegidas dentro de un grupo compartido de módulos de seguridad de hardware para múltiples usuarios.	Cargas de trabajo que requieren claves respaldadas por hardware sin el costo de un HSM dedicado.
HSM administrado de Azure Key Vault (nativo, dedicado)	Las claves residen en un grupo HSM dedicado, de inquilino único y validado según la norma FIPS 140-3 de nivel 3, que Microsoft gestiona en nombre del cliente.	Cargas de trabajo reguladas que requieren custodia de hardware dedicada y control administrativo total sobre el HSM.
Módulo de seguridad de hardware (HSM) dedicado de Azure (hardware controlado por el cliente)	Un dispositivo HSM físico de inquilino único en Azure que el cliente, y no Microsoft, administra directamente.	Organizaciones con un mandato de cumplimiento que exige que el proveedor de la nube nunca administre el HSM por sí mismo.
BYOK (material clave importado)	El material clave generado fuera de Azure (a menudo en un HSM local) se importa a Key Vault o a un HSM administrado, que luego gestiona su ciclo de vida en adelante.	Organizaciones que necesitan demostrar la procedencia de las claves o que ya generan claves a través de un HSM local existente.

Se recomienda utilizar Key Vault Standard o Premium por defecto, a menos que un requisito específico exija el uso del pool dedicado de Managed HSM o del hardware administrado por el cliente de Dedicated HSM. Ambas opciones implican un aumento significativo en los costos y la carga operativa, y solo resultan rentables cuando un mandato de cumplimiento específico exige ese nivel de aislamiento.

¿Cómo debería estructurarse la gestión de identidades y accesos (IAM) para Azure Key Vault y las herramientas de cumplimiento normativo?

El control de acceso basado en roles (RBAC) de Azure es el modelo de permisos recomendado por Microsoft para Key Vault, que reemplaza el antiguo sistema de directivas de acceso a nivel de bóveda con las mismas asignaciones de roles granulares y auditables que se utilizan en el resto de Azure.

1. Migre los almacenes que aún utilizan el modelo de permisos de directiva de acceso heredado a Azure RBAC, ya que RBAC se integra con el Acceso condicional de Azure AD y genera un registro de auditoría coherente en todos los servicios.
2. Separar el Oficial de Criptografía de Key Vault rol (gestión del ciclo de vida clave: crear, rotar, eliminar) de Usuario de criptografía de Key Vault (operaciones de cifrado/descifrado/firma únicamente), otorgando cada una a identidades diferentes.
3. Defina el alcance de las asignaciones de roles a nivel de bóveda o clave individual, en lugar de a nivel de suscripción, de modo que una única concesión demasiado amplia no exponga todas las claves de la suscripción.
4. Revise las asignaciones de roles en las bóvedas con la misma frecuencia que otras revisiones de acceso a producción, ya que una concesión de usuario criptográfico obsoleta equivale a un acceso de descifrado permanente.

¿Cómo se debe gestionar la rotación de claves en Azure?

Azure Key Vault admite directivas de rotación automática integradas, lo que permite a las organizaciones definir un período de rotación y una ventana de notificación opcional antes de la expiración. Al igual que con cualquier servicio de administración de claves en la nube, la rotación solo crea una nueva versión de la clave para operaciones futuras; no vuelve a cifrar los datos ya protegidos por una versión anterior ni elimina automáticamente la versión anterior. Un plan de rotación completo requiere un paso de recifrado independiente y una programación explícita para la eliminación de las versiones antiguas de la clave una vez que ya no dependan de ellas.

¿Qué información debe registrar para cumplir con la normativa y la administración de claves de Azure?

• Registros de diagnóstico de Key Vault, Se envían a Azure Monitor o Log Analytics, cubriendo cada operación clave, la identidad del emisor y la versión específica de la clave utilizada.
• Alertas de Microsoft Defender para la nube por patrones de acceso anómalos contra Key Vault y otros recursos supervisados.
• Cambios en el estado de cumplimiento de Azure Policy, Seguimiento de cuándo un recurso entra o deja de cumplir con una política asignada.
• Historial de evaluación de Microsoft Purview Compliance Manager, que registra el estado de las acciones de mejora a lo largo del tiempo para estándares como HIPAA y GDPR.

¿Cuánto cuestan las herramientas de cumplimiento y administración de claves de Azure?

Key Vault Standard y Premium se facturan por operación de clave y por versión de clave protegida por HSM; Managed HSM y Dedicated HSM tienen una tarifa plana considerablemente más alta para cubrir la capacidad de hardware dedicada. Microsoft Defender for Cloud se factura por recurso protegido una vez que se habilitan sus planes mejorados. Las funciones de evaluación principales de Microsoft Purview Compliance Manager se incluyen con ciertas suscripciones de Microsoft 365 y centradas en el cumplimiento, en lugar de facturarse por separado. Azure Deployment Stacks y Template Specs, como funciones nativas de Azure Resource Manager, no tienen ningún cargo de servicio adicional más allá de los recursos que implementan. Confirme las tarifas unitarias actuales con las páginas de precios de Microsoft antes de presupuestar una migración desde Blueprints, ya que estas herramientas se facturan y licencian con modelos completamente diferentes.

¿Cómo es la arquitectura de cumplimiento multi-nube en Azure, AWS y GCP?

Cada nube principal implementa las mismas capas conceptuales, un motor de gobernanza de políticas como código, un servicio de monitoreo continuo de la postura de seguridad y un servicio de administración de claves por niveles, bajo diferentes nombres: Azure Policy y Defender for Cloud en Azure, AWS Config y Security Hub en AWS, y Organization Policy y Security Command Center en GCP. Una arquitectura de cumplimiento multi-nube coherente asigna los mismos objetivos de control (cifrado en reposo, acceso a claves con privilegios mínimos, monitoreo continuo) a las herramientas nativas de cada nube, en lugar de intentar ejecutar un único motor de gobernanza en las tres, ya que ninguna de ellas administra de forma nativa los recursos de las demás.

Consulte nuestra comparación de AWS KMS, Azure Key Vault y GCP KMS para obtener un análisis completo de las diferencias específicas en la gestión de claves entre las tres plataformas, y la información de infraestructura de clave pública (PKI) basada en la nube (GCP, AWS y Azure) para ver cómo se compara la identidad basada en certificados.

¿Cuáles son las limitaciones de las herramientas de cumplimiento normativo de Azure?

• La retirada gradual de Azure Blueprints obliga a cualquier organización que haya basado su gobernanza en él a emprender un verdadero proyecto de migración; las pilas de implementación y las especificaciones de plantilla no son un reemplazo directo, sino que requieren la reescritura de los artefactos de gobernanza.
• Tanto el HSM gestionado como el HSM dedicado conllevan un coste sustancialmente mayor que el Key Vault estándar o premium, que debe justificarse en función de un requisito de cumplimiento real en lugar de adoptarse por defecto.
• La migración de bóvedas del modelo de política de acceso anterior al control de acceso basado en roles (RBAC) requiere una planificación cuidadosa, ya que los dos modelos no siempre se corresponden uno a uno y una migración apresurada puede otorgar permisos excesivos o bloquear el acceso legítimo.
• Tanto Microsoft Defender for Cloud como Purview Compliance Manager requieren una configuración inicial; los umbrales de alerta y evaluación predeterminados generan información irrelevante que debe ajustarse al perfil de riesgo real de la organización.

Lista de verificación para la toma de decisiones: Modernización del cumplimiento normativo en Azure

1. Inventarie todas las definiciones y asignaciones de Azure Blueprints que se estén utilizando actualmente y programe su migración antes del 31 de julio de 2026, fecha límite para las nuevas definiciones.
2. Reconstruya los artefactos de gobernanza utilizando Azure Deployment Stacks para la asignación y el ciclo de vida, y Template Specs o Git para el almacenamiento de definiciones.
3. Seleccione un nivel de Key Vault (Estándar, Premium, HSM administrado o HSM dedicado) en función de un requisito documentado real, no por defecto.
4. Migre cualquier almacén que aún utilice el modelo de directiva de acceso heredado a Azure RBAC, separando la administración de claves del uso de claves.
5. Habilite la rotación automática de Key Vault y documente el proceso de recifrado independiente para los datos existentes.

¿Qué recomendaría Encryption Consulting?

La mayoría de los clientes de Azure con los que trabajamos siguen utilizando la gobernanza basada en Blueprints sin un plan de migración, lo que convierte una retirada programada en una situación caótica e imprevista. Los servicios de asesoramiento en cumplimiento normativo de Encryption Consulting adaptan sus obligaciones regulatorias reales (HIPAA, GDPR, PCI DSS y otras) a los controles de Azure adecuados, planifican su migración de Blueprints a Deployment Stacks y nuestra oferta de HSM como servicio le proporciona custodia de claves respaldada por hardware sin necesidad de gestionar directamente la infraestructura HSM.

Preguntas frecuentes

¿Cuándo desaparecerá definitivamente Azure Blueprints?

La jubilación total está prevista para el 31 de enero de 2027, pero la eliminación gradual comienza antes: las nuevas definiciones de planos dejarán de ser posibles el 31 de julio de 2026, y se aplicarán restricciones adicionales el 31 de octubre y el 31 de diciembre de 2026.

¿Qué debería reemplazar a Azure Blueprints?

Microsoft recomienda Azure Deployment Stacks para la asignación, la implementación y la gestión del ciclo de vida, combinado con Template Specs o un repositorio Git para almacenar y versionar las plantillas subyacentes.

¿Sigue siendo Azure Security Center la herramienta adecuada?

Azure Security Center pasó a llamarse Microsoft Defender for Cloud; la capacidad subyacente de supervisión continua del estado de seguridad sigue vigente bajo ese nombre.

¿Cuál es la diferencia entre Azure Key Vault Premium y Managed HSM?

La versión Premium protege las claves en un grupo de módulos de seguridad de hardware (HSM) compartido y multiusuario; la versión Managed HSM protege las claves en un grupo de HSM dedicado, de un solo usuario y validado según la norma FIPS 140-3 de nivel 3, con control administrativo completo, a un coste correspondientemente mayor.

¿El cambio de una clave de Key Vault vuelve a cifrar automáticamente los datos existentes?

No. La rotación solo crea una nueva versión de clave activa para operaciones futuras; los datos ya cifrados con la versión anterior siguen dependiendo de ella hasta que se ejecute un proceso de recifrado explícito.

¿Necesita ayuda para planificar la migración de Azure Blueprints o para alinear sus requisitos de cumplimiento con los controles de Azure adecuados? Póngase en contacto con el equipo de Asesoramiento en Cumplimiento de Encryption Consulting.

Referencias

Retirada de Azure Blueprints – learn.microsoft.com

Cómo elegir la solución de administración de claves de Azure adecuada – learn.microsoft.com