Consideraciones sobre la seguridad de cargas de trabajo críticas en Azure

La seguridad es uno de los principios fundamentales de diseño y también un área de diseño clave que debe tratarse como una preocupación de primera clase dentro del proceso arquitectónico crítico.

Dado que el enfoque principal de un diseño crítico es maximizar la confiabilidad para que la aplicación siga funcionando y disponible, las consideraciones de seguridad y las recomendaciones aplicadas en este área de diseño se centrarán en mitigar las amenazas con la capacidad de afectar a la disponibilidad y dificultar la confiabilidad general. Por ejemplo, se sabe que los ataques de denegación de servicio (DDoS) correctos tienen un impacto catastrófico en la disponibilidad y el rendimiento. La forma en que una aplicación mitiga esos vectores de ataque, como SlowLoris, afectará a la confiabilidad general. Por lo tanto, la aplicación debe estar totalmente protegida contra amenazas destinadas a poner en peligro directa o indirectamente la confiabilidad de la aplicación para ser verdaderamente crítica en la naturaleza.

También es importante tener en cuenta que a menudo hay importantes ventajas y desventajas asociadas a una posición de seguridad protegida, especialmente con respecto al rendimiento, la agilidad operativa y, en algunos casos, la confiabilidad. Por ejemplo, la inclusión de aplicaciones virtuales de red en línea (NVA) para funcionalidades de firewall de próxima generación (NGFW), como la inspección profunda de paquetes, introducirá una penalización de rendimiento significativa, una complejidad operativa adicional y un riesgo de confiabilidad si las operaciones de escalabilidad y recuperación no están estrechamente alineadas con la de la aplicación. Por lo tanto, es esencial que los componentes y prácticas de seguridad adicionales destinados a mitigar los vectores de amenazas clave también están diseñados para admitir el destino de confiabilidad de una aplicación, que formará un aspecto clave de las recomendaciones y consideraciones presentadas en esta sección.

Importante

Este artículo forma parte de la serie de cargas de trabajo críticas de Azure Well-Architected . Si no está familiarizado con esta serie, se recomienda empezar con lo que es una carga de trabajo crítica.

Mission-Critical código abierto project

Las implementaciones de referencia forman parte de un proyecto de código abierto disponible en GitHub. Los recursos de código adoptan un modelo de Confianza cero para estructurar y guiar el enfoque de implementación y diseño de seguridad.

Alineación con el modelo de Confianza cero

El modelo de Microsoft Confianza cero proporciona un enfoque proactivo e integrado para aplicar la seguridad en todas las capas de una aplicación. Los principios rectores de Confianza cero se esfuerzan por comprobar explícita y continuamente cada transacción, declarar privilegios mínimos, usar inteligencia y detección avanzada para responder a amenazas casi en tiempo real. En última instancia, se centra en eliminar la confianza dentro y fuera de los perímetros de la aplicación, aplicando la verificación para cualquier intento de conectarse al sistema.

Consideraciones de diseño

A medida que evalúe la posición de seguridad de la aplicación, comience con estas preguntas como base para cada consideración.

• Pruebas de seguridad continuas para validar mitigaciones de vulnerabilidades de seguridad clave.

  • ¿Se realizan pruebas de seguridad como parte de los procesos automatizados de CI/CD?
  • Si no es así, ¿con qué frecuencia se realizan pruebas de seguridad específicas?
  • ¿Se miden los resultados de las pruebas con respecto a una posición de seguridad y un modelo de amenazas deseados?

• Nivel de seguridad en todos los entornos inferiores.

  • ¿Todos los entornos del ciclo de vida de desarrollo tienen la misma posición de seguridad que el entorno de producción?

• Continuidad de autenticación y autorización en caso de error.

  • Si los servicios de autenticación o autorización no están disponibles temporalmente, ¿la aplicación podrá seguir funcionando?

• Cumplimiento y corrección de seguridad automatizados.

  • ¿Se pueden detectar cambios en la configuración de seguridad clave?
  • ¿Se automatizan las respuestas para corregir los cambios no compatibles?

• Examen de secretos para detectar secretos antes de confirmar el código para evitar pérdidas de secretos a través de repositorios de código fuente.

  • ¿Es posible la autenticación en los servicios sin tener credenciales como parte del código?

• Proteja la cadena de suministro de software.

  • ¿Es posible realizar un seguimiento de vulnerabilidades y exposiciones comunes (CVE) dentro de las dependencias de paquetes utilizadas?
  • ¿Hay un proceso automatizado para actualizar las dependencias del paquete?

• Ciclos de vida clave de protección de datos.

  • ¿Se pueden usar claves administradas por el servicio para la protección de la integridad de datos?
  • Si se requieren claves administradas por el cliente, ¿cómo es el ciclo de vida de clave seguro y confiable?

• Las herramientas de CI/CD deben requerir Microsoft Entra entidades de servicio con acceso de nivel de suscripción suficiente para facilitar el acceso del plano de control para las implementaciones de recursos de Azure a todas las suscripciones de entorno consideradas.

  • Cuando los recursos de la aplicación están bloqueados en redes privadas, hay una ruta de acceso de conectividad del plano de datos privado para que las herramientas de CI/CD puedan realizar implementaciones y mantenimiento de nivel de aplicación.
    • Esto presenta complejidad adicional y requiere una secuencia dentro del proceso de implementación a través de los agentes de compilación privados necesarios.

Recomendaciones de diseño

• Use Azure Policy para aplicar configuraciones de seguridad y confiabilidad para todos los servicios, lo que garantiza que cualquier desviación se corrija o esté prohibida por el plano de control en el momento de la configuración, lo que ayuda a mitigar las amenazas asociadas a escenarios de "administrador malintencionado".

• Use Microsoft Entra Privileged Identity Management (PIM) dentro de las suscripciones de producción para revocar el acceso sostenido del plano de control a los entornos de producción. Esto reducirá significativamente el riesgo que suponen los escenarios de "administrador malintencionado" a través de "comprobaciones y saldos" adicionales.

• Use Identidades administradas de Azure para todos los servicios que admiten la funcionalidad, ya que facilita la eliminación de credenciales del código de aplicación y elimina la carga operativa de la administración de identidades para la comunicación entre servicios.

• Use Microsoft Entra control de acceso basado en rol (RBAC) para la autorización del plano de datos con todos los servicios que admiten la funcionalidad.

• Use bibliotecas de autenticación de Plataforma de identidad de Microsoft de primera entidad en el código de aplicación para integrarse con Microsoft Entra ID.

• Considere la posibilidad de almacenar en caché de tokens seguros para permitir una experiencia degradada pero disponible si la plataforma de identidad elegida no está disponible o solo está disponible parcialmente para la autorización de la aplicación.

  • Si el proveedor no puede emitir nuevos tokens de acceso, pero sigue validando los existentes, la aplicación y los servicios dependientes pueden funcionar sin problemas hasta que expiren sus tokens.
  • Normalmente, el almacenamiento en caché de tokens se controla automáticamente mediante bibliotecas de autenticación (como MSAL).

• Use la infraestructura como código (IaC) y las canalizaciones automatizadas de CI/CD para impulsar las actualizaciones de todos los componentes de la aplicación, incluidas en circunstancias de error.

  • Asegúrese de que las conexiones del servicio de herramientas de CI/CD se protegen como información confidencial crítica y no deben estar directamente disponibles para ningún equipo de servicio.
  • Aplique RBAC pormenorizada a las canalizaciones de CD de producción para mitigar los riesgos de "administrador malintencionado".
  • Considere el uso de puertas de aprobación manuales dentro de las canalizaciones de implementación de producción para mitigar aún más los riesgos de "administrador malintencionado" y proporcionar garantía técnica adicional para todos los cambios de producción.
    • Las puertas de seguridad adicionales pueden llegar a un equilibrio en términos de agilidad y deben evaluarse cuidadosamente, teniendo en cuenta cómo se puede mantener la agilidad incluso con puertas manuales.

• Defina una posición de seguridad adecuada para todos los entornos inferiores para asegurarse de que se mitigan las vulnerabilidades clave.

  • No aplique la misma posición de seguridad que la producción, especialmente con respecto a la filtración de datos, a menos que los requisitos normativos estipulan la necesidad de hacerlo, ya que esto comprometerá significativamente la agilidad del desarrollador.

• Habilite Microsoft Defender for Cloud (anteriormente conocido como Azure Security Center) para todas las suscripciones que contengan los recursos de una carga de trabajo crítica.

  • Use Azure Policy para aplicar el cumplimiento.
  • Habilite Azure Defender para todos los servicios que admiten la funcionalidad.

• Adopte DevSecOps e implemente pruebas de seguridad en canalizaciones de CI/CD.

  • Los resultados de las pruebas deben medirse con respecto a una posición de seguridad compatible para informar a las aprobaciones de versión, ya sean automatizadas o manuales.
  • Aplique pruebas de seguridad como parte del proceso de producción de CD para cada versión.
    • Si las pruebas de seguridad de cada versión ponen en peligro la agilidad operativa, asegúrese de que se aplique una cadencia de pruebas de seguridad adecuada.

• Habilite el examen de secretos y el análisis de dependencias en el repositorio de código fuente.

Modelado de amenazas

El modelado de amenazas proporciona un enfoque basado en riesgos para el diseño de la seguridad, mediante el uso de posibles amenazas identificadas para desarrollar mitigaciones de seguridad adecuadas. Hay muchas amenazas posibles con distintas probabilidades de aparición y, en muchos casos, las amenazas pueden encadenar de maneras inesperadas, impredecibles e incluso caóticas. Esta complejidad e incertidumbre es la razón por la que los enfoques de seguridad basados en requisitos tecnológicos tradicionales son en gran medida inadecuados para las aplicaciones en la nube críticas. Espere que el proceso de modelado de amenazas para una aplicación crítica sea complejo e inflexible.

Para ayudar a navegar por estos desafíos, se debe aplicar un enfoque de defensa en profundidad por capas para definir e implementar mitigaciones de compensación para amenazas modeladas, teniendo en cuenta las siguientes capas defensivas.

1. La plataforma Azure con funcionalidades y controles de seguridad fundamentales.
2. Arquitectura de la aplicación y diseño de seguridad.
3. Características de seguridad integradas, habilitadas e implementables aplicadas a recursos seguros de Azure.
4. Código de aplicación y lógica de seguridad.
5. Procesos operativos y DevSecOps.

Nota

Al implementar dentro de una zona de aterrizaje de Azure, tenga en cuenta que la implementación de la implementación de la zona de aterrizaje proporciona una capa de mitigación de amenazas adicional mediante el aprovisionamiento de funcionalidades de seguridad centralizadas.

Consideraciones de diseño

STRIDE proporciona un marco de riesgo ligero para evaluar las amenazas de seguridad en vectores de amenazas clave.

• Identidad suplantada: suplantación de personas con autoridad. Por ejemplo, un atacante suplanta a otro usuario mediante su :
  • Identidad
  • Autenticación
• Entrada de manipulación: modificación de la entrada enviada a la aplicación o la vulneración de límites de confianza para modificar el código de aplicación. Por ejemplo, un atacante que usa la inyección de código SQL para eliminar datos de una tabla de base de datos.
  • Integridad de datos
  • Validación
  • Listas de bloqueados o listas de permitidos
• Rechazo de la acción: capacidad de rebatir las acciones ya realizadas y la capacidad de la aplicación para recopilar evidencias e impulsar la responsabilidad. Por ejemplo, la eliminación de datos críticos sin la capacidad de realizar un seguimiento en un administrador malintencionado.
  • Auditoría y registro
  • de firma
• Divulgación de información: obtener acceso a información restringida. Un ejemplo sería un atacante que obtiene acceso a un archivo restringido.
  • Cifrado
  • Filtración de datos
  • Ataques de tipo "Man in the middle"
• Denegación de servicio: interrupción malintencionada de la aplicación para degradar la experiencia del usuario. Por ejemplo, un ataque botnet de DDoS, como Slowloris.
  • DDoS
  • Redes de robots (bonets)*
  • Funcionalidades de CDN y WAF
• Elevación de privilegios: obtención de acceso a aplicaciones con privilegios a través de vulnerabilidades de autorización. Por ejemplo, un atacante que manipula una cadena de dirección URL para obtener acceso a información confidencial.
  • Ejecución remota de código
  • Authorization
  • Aislamiento

Recomendaciones de diseño

• Asigne un presupuesto de ingeniería en cada sprint para evaluar posibles amenazas nuevas e implementar mitigaciones.

• Se debe aplicar un esfuerzo consciente para garantizar que las mitigaciones de seguridad se capturen dentro de un criterio de ingeniería común para impulsar la coherencia en todos los equipos de servicio de aplicaciones.

• Comience con un servicio mediante el modelado de amenazas de nivel de servicio y unifique el modelo mediante la consolidación del modelo de subprocesos en el nivel de aplicación.

Protección contra intrusiones de red

Impedir el acceso no autorizado a una aplicación crítica y los datos incluidos es fundamental para mantener la disponibilidad y proteger la integridad de los datos.

Consideraciones de diseño

• Confianza cero supone un estado infringido y comprueba cada solicitud como si se origina en una red no controlada.

  • Una implementación avanzada de red de confianza cero emplea microsegmentación y micro-perímetros de entrada/salida distribuidos.

• Normalmente, se accede a los servicios PaaS de Azure a través de puntos de conexión públicos. Azure ofrece funcionalidades para proteger puntos de conexión públicos o incluso hacerlos totalmente privados.

  • Azure Private Link o los puntos de conexión privados proporcionan acceso dedicado a un recurso PaaS de Azure mediante direcciones IP privadas y conectividad de red privada.
  • Virtual Network los puntos de conexión de servicio proporcionan acceso de nivel de servicio desde subredes seleccionadas a los servicios PaaS seleccionados.
  • Virtual Network inserción proporciona implementaciones privadas dedicadas para los servicios admitidos, como App Service a través de un App Service Environment.
    • El tráfico del plano de administración sigue fluyendo mediante direcciones IP públicas.

• En el caso de los servicios admitidos, Azure Private Link mediante puntos de conexión privados de Azure aborda los riesgos de filtración de datos asociados con los puntos de conexión de servicio, como un administrador malintencionado que escribe datos en un recurso externo.

• Al restringir el acceso de red a los servicios PaaS de Azure mediante puntos de conexión privados o puntos de conexión de servicio, se necesitará un canal de red seguro para que las canalizaciones de implementación accedan tanto al plano de control de Azure como al plano de datos de los recursos de Azure para implementar y administrar la aplicación.

  • Agentes de compilación autohospedados privados implementados en una red privada, ya que el recurso de Azure se puede usar como proxy para ejecutar funciones de CI/CD a través de una conexión privada. Se debe usar una red virtual independiente para los agentes de compilación.
    • Se requiere conectividad con los agentes de compilación privados desde las herramientas de CI/CD.
  • Un enfoque alternativo consiste en modificar las reglas de firewall del recurso sobre la marcha dentro de la canalización para permitir una conexión desde una dirección IP pública del agente de Azure DevOps, con el firewall quitado posteriormente una vez completada la tarea.
    • Sin embargo, este enfoque solo es aplicable a un subconjunto de servicios de Azure. Por ejemplo, esto no es factible para los clústeres de AKS privados.
  • Para realizar tareas administrativas y de desarrollador en los jumpbox del servicio de aplicaciones se puede usar.

• La finalización de las tareas de administración y mantenimiento es un escenario adicional que requiere conectividad con el plano de datos de los recursos de Azure.

• Los Connections de servicio con una entidad de servicio de Microsoft Entra correspondiente se pueden usar en Azure DevOps para aplicar RBAC a través de Microsoft Entra ID.

• Las etiquetas de servicio se pueden aplicar a los grupos de seguridad de red para facilitar la conectividad con los servicios PaaS de Azure.

• Los grupos de seguridad de aplicaciones no abarcan varias redes virtuales.

• La captura de paquetes en Azure Network Watcher se limita a un período máximo de cinco horas.

Recomendaciones de diseño

• Limite el acceso a la red pública al mínimo absoluto necesario para que la aplicación cumpla su propósito empresarial con el fin de reducir la superficie expuesta a ataques externos.

  • Use Azure Private Link para establecer puntos de conexión privados para los recursos de Azure que requieren una integración de red segura.
  • Use agentes de compilación privados hospedados para herramientas de CI/CD para implementar y configurar recursos de Azure protegidos por Azure Private Link.
    • Los agentes hospedados por Microsoft no podrán conectarse directamente a los recursos integrados de red.

• Cuando trabaje con agentes de compilación privados, nunca abra un puerto RDP o SSH directamente a Internet.

  • Use Azure Bastion para proporcionar acceso seguro a Azure Virtual Machines y realizar tareas administrativas en PaaS de Azure a través de Internet.

• Use un plan de protección estándar de DDoS para proteger todas las direcciones IP públicas dentro de la aplicación.

• Use Azure Front Door con directivas WAF para entregar y ayudar a proteger aplicaciones HTTP/S globales que abarquen múltiples regiones de Azure.

  • Use la validación del identificador de encabezado para bloquear los puntos de conexión de aplicación públicos para que solo acepten el tráfico que se origina en la instancia de Azure Front Door.

• Si se requieren requisitos adicionales de seguridad de red en línea, como la inspección profunda de paquetes o la inspección de TLS, exija el uso de Azure Firewall premium o la aplicación virtual de red (NVA), asegúrese de que está configurado para lograr una alta disponibilidad y redundancia máximas.

• Si existen requisitos de captura de paquetes, use Network Watcher paquetes para capturar a pesar de la ventana de captura limitada.

• Use grupos de seguridad de red y grupos de seguridad de aplicaciones para el tráfico de aplicaciones de microsegmentar.

  • Evite usar un dispositivo de seguridad para filtrar los flujos de tráfico dentro de la aplicación.
  • Considere el uso de Azure Policy para aplicar reglas de NSG específicas siempre asociadas a subredes de aplicación.

• Habilite los registros de flujo de NSG y envíelos a Análisis de tráfico para obtener conclusiones sobre los flujos de tráfico interno y externo.

• Use Azure Private Link o puntos de conexión privados, siempre que estén disponibles, para proteger el acceso a los servicios PaaS de Azure en el diseño de la aplicación. Para información sobre los servicios de Azure que admiten Private Link, consulte Disponibilidad de Azure Private Link.

• Si el punto de conexión privado no está disponible y los riesgos de filtración de datos son aceptables, use Virtual Network puntos de conexión de servicio para proteger el acceso a los servicios PaaS de Azure desde dentro de una red virtual.

  • No habilite los puntos de conexión de servicio de red virtual de forma predeterminada en todas las subredes, ya que esto introducirá canales de filtración de datos significativos.

• En escenarios de aplicaciones híbridas, acceda a los servicios PaaS de Azure desde el entorno local a través de ExpressRoute con emparejamiento privado.

Nota

Al implementar dentro de una zona de aterrizaje de Azure, tenga en cuenta que la implementación de la implementación de la zona de aterrizaje proporciona conectividad de red a los centros de datos locales. Un enfoque consiste en usar ExpressRoute configurado con emparejamiento privado.

Protección de la integridad de los datos

El cifrado es un paso fundamental para garantizar la integridad de los datos y, en última instancia, es una de las funcionalidades de seguridad más importantes que se pueden aplicar para mitigar una amplia gama de amenazas. Por lo tanto, en esta sección se proporcionarán consideraciones clave y recomendaciones relacionadas con el cifrado y la administración de claves para proteger los datos sin poner en peligro la confiabilidad de la aplicación.

Consideraciones de diseño

• Azure Key Vault tiene límites de transacciones para claves y secretos, con limitación aplicada por almacén en un período determinado.

• Key Vault proporciona un límite de seguridad, ya que los permisos para acceder a las claves, los secretos y los certificados se aplican en el nivel del almacén.

  • Las asignaciones de las directivas de acceso de Key Vault conceden permisos independientes a las claves, los secretos o los certificados.
    • Los permisos de nivel de objeto granulares para una clave, un secreto o un certificado específicos ahora son posibles.

• Después de cambiar una asignación de roles, hay una latencia de hasta 10 minutos (600 segundos) para que se aplique el rol.

  • Hay un límite de 2000 asignaciones de roles de Azure por suscripción.

• Azure Key Vault módulos de seguridad de hardware subyacentes (HSM) tienen validación FIPS 140.

  • Hay disponible un HSM administrado de Azure Key Vault dedicado para escenarios que requieren el cumplimiento de FIPS 140-2 nivel 3.

• Azure Key Vault proporciona alta disponibilidad y redundancia para ayudar a mantener la disponibilidad y evitar la pérdida de datos.

• Durante una conmutación por error de región, el servicio de Key Vault puede tardar unos minutos en conmutar por error.

  • Durante una conmutación por error Key Vault estará en modo de solo lectura, por lo que no será posible cambiar las propiedades del almacén de claves, como las configuraciones de firewall y las opciones.

• Si se usa private link para conectarse a Azure Key Vault, la conexión puede tardar hasta 20 minutos en restablecerse durante una conmutación por error regional.

• Una copia de seguridad crea una instantánea a un momento dado de un secreto, una clave o un certificado, como un blob cifrado que no se puede descifrar fuera de Azure. Para obtener datos utilizables del blob, se debe restaurar en un Key Vault dentro de la misma suscripción de Azure y la misma geografía de Azure.

  • Los secretos pueden renovarse durante una copia de seguridad, lo que provoca una discrepancia.

• Con las claves administradas por el servicio, Azure realizará funciones de administración de claves, como la rotación, lo que reduce el ámbito de las operaciones de la aplicación.

• Los controles normativos pueden estipular el uso de claves administradas por el cliente para la funcionalidad de cifrado del servicio.

• Cuando el tráfico se mueve entre los centros de datos de Azure, el cifrado de capa de vínculo de datos de MACsec se usa en el hardware de red subyacente para proteger los datos en tránsito fuera de los límites físicos no controlados por Microsoft o en nombre de Microsoft.

Recomendaciones de diseño

• Use claves administradas por el servicio para la protección de datos siempre que sea posible, lo que elimina la necesidad de administrar las claves de cifrado y controlar las tareas operativas, como la rotación de claves.

  • Use solo las claves administradas por el cliente cuando haya un requisito normativo claro para hacerlo.

• Use Azure Key Vault como repositorio seguro para todos los secretos, certificados y claves si es necesario tener en cuenta mecanismos de cifrado adicionales o claves administradas por el cliente.

  • Aprovisione Azure Key Vault con las directivas de eliminación temporal y purga habilitadas para permitir la protección de retención de los objetos eliminados.
  • Use la SKU de Azure Key Vault respaldada por HSM para entornos de producción de aplicaciones.

• Implemente una instancia de Azure Key Vault independiente dentro de cada marca de implementación regional, lo que proporciona ventajas de aislamiento y rendimiento de errores a través de la localización, así como navegar por los límites de escala impuestos por una única instancia de Key Vault.

  • Use una instancia de Azure Key Vault dedicada para los recursos globales de la aplicación.

• Siga un modelo de privilegios mínimos limitando la autorización para eliminar permanentemente secretos, claves y certificados a roles de Microsoft Entra personalizados especializados.

• Asegúrese de que se realiza una copia de seguridad de las claves de cifrado y los certificados almacenados en Key Vault, lo que proporciona una copia sin conexión en el evento improbable Key Vault deja de estar disponible.

• Use Key Vault certificados para administrar la adquisición y firma de certificados.

• Establezca un proceso automatizado para la rotación de claves y certificados.

  • Automatice el proceso de renovación y administración de certificados con entidades de certificación públicas para facilitar la administración.
    • Establezca alertas y notificaciones para complementar las renovaciones automatizadas de certificados.

• La clave de supervisión, el certificado y el uso de secretos.

  • Defina alertas para un uso inesperado en Azure Monitor.

Gobernanza controlada mediante directivas

En última instancia, las convenciones de seguridad solo son eficaces si se aplican de forma coherente y holística en todos los servicios y equipos de aplicaciones. Azure Policy proporciona un marco para aplicar líneas base de seguridad y confiabilidad, lo que garantiza el cumplimiento continuo de un criterio de ingeniería común para una aplicación crítica. Más concretamente, Azure Policy forma una parte clave del plano de control de Azure Resource Manager (ARM), complementando RBAC mediante la restricción de las acciones que pueden realizar los usuarios autorizados y se puede usar para aplicar convenciones de seguridad y confiabilidad vitales en los servicios de plataforma utilizados.

Por lo tanto, en esta sección se explorarán las consideraciones y recomendaciones clave que rodean el uso de Azure Policy gobernanza controlada para una aplicación crítica, lo que garantiza que las convenciones de seguridad y confiabilidad se aplican continuamente.

Consideraciones de diseño

• Azure Policy proporciona un mecanismo para impulsar el cumplimiento aplicando convenciones de seguridad y confiabilidad, como el uso de puntos de conexión privados o el uso de Availability Zones.

Nota

Al implementar dentro de una zona de aterrizaje de Azure, tenga en cuenta que es probable que se aplique la aplicación de asignaciones de directivas de línea de base centralizadas en la implementación de grupos y suscripciones de administración de zonas de aterrizaje.

• Azure Policy se puede usar para impulsar actividades de administración automatizadas, como el aprovisionamiento y la configuración.

  • Registro del proveedor de recursos.
  • Validación y aprobación de configuraciones de recursos de Azure individuales.

• Azure Policy ámbito de asignación determina la cobertura y la ubicación de las definiciones de Azure Policy informa de la reutilización de las directivas personalizadas.

• Azure Policy tiene varios límites, como el número de definiciones en cualquier ámbito determinado.

• La ejecución de las directivas Deploy If Not Exist (DINE) puede tardar varios minutos en ejecutarse.

• Azure Policy proporciona una entrada crítica para los informes de cumplimiento y la auditoría de seguridad.

Recomendaciones de diseño

• Asigne requisitos legislativos y de cumplimiento normativo a las definiciones de Azure Policy.

  • Por ejemplo, si hay requisitos de residencia de datos, se debe aplicar una directiva para restringir las regiones de implementación disponibles.

• Defina un criterio de ingeniería común para capturar definiciones de configuración seguras y confiables para todos los servicios de Azure utilizados, lo que garantiza que estos criterios se asignan a Azure Policy asignaciones para aplicar el cumplimiento.

  • Por ejemplo, aplique un Azure Policy para aplicar el uso de Availability Zones para todos los servicios pertinentes, lo que garantiza configuraciones confiables de implementación dentro de la región.

La implementación de referencia de Mission Critical contiene una amplia gama de directivas centradas en la seguridad y confiabilidad para definir y aplicar un ejemplo de criterios de ingeniería comunes.

• Supervise el desfase de configuración del servicio, en relación con los criterios de ingeniería comunes, mediante Azure Policy.

Para escenarios críticos con varias suscripciones de producción en un grupo de administración dedicado, priorice las asignaciones en el ámbito del grupo de administración.

• Use directivas integradas siempre que sea posible para minimizar la sobrecarga operativa del mantenimiento de definiciones de directivas personalizadas.

• Cuando se requieran definiciones de directiva personalizadas, asegúrese de que las definiciones se implementan en el ámbito adecuado del grupo de administración para permitir la reutilización en suscripciones de entorno abarcadas para permitir la reutilización de directivas en entornos de producción e inferior.

  • Al alinear la hoja de ruta de la aplicación con las hojas de ruta de Azure, use los recursos de Microsoft disponibles para explorar si se podrían incorporar definiciones personalizadas críticas como definiciones integradas.

Nota

Al implementar dentro de una zona de aterrizaje de Azure, considere la posibilidad de implementar definiciones de Azure Policy personalizadas dentro del ámbito del grupo de administración raíz de la empresa intermedia para habilitar la reutilización en todas las aplicaciones dentro del patrimonio de Azure más amplio. En un entorno de zona de aterrizaje, determinadas directivas de seguridad centralizadas se aplicarán de forma predeterminada en ámbitos de grupo de administración superiores para aplicar el cumplimiento de seguridad en todo el patrimonio de Azure. Por ejemplo, las directivas de Azure se deben aplicar para implementar automáticamente configuraciones de software a través de extensiones de máquina virtual y aplicar una configuración de máquina virtual de línea base compatible.

• Use Azure Policy para aplicar un esquema de etiquetado coherente en toda la aplicación.
  • Identifique las etiquetas de Azure necesarias y use el modo de directiva de anexión para aplicar el uso.

Si la aplicación está suscrita al soporte técnico de Microsoft Mission-Critical, asegúrese de que el esquema de etiquetado aplicado proporciona un contexto significativo para enriquecer la experiencia de soporte técnico con un conocimiento profundo de la aplicación.

• Exporte Microsoft Entra registros de actividad al área de trabajo global de Log Analytics que usa la aplicación.
  • Asegúrese de que los registros de actividad de Azure se archivan en la cuenta de almacenamiento global junto con los datos operativos para la retención a largo plazo.

En una zona de aterrizaje de Azure, los registros de actividad de Microsoft Entra también se ingerirán en el área de trabajo de Log Analytics de la plataforma centralizada. Debe evaluarse en este caso si Microsoft Entra ID siguen siendo necesarios en el área de trabajo global de Log Analytics.

• Integre la información de seguridad y la administración de eventos con Microsoft Defender for Cloud (anteriormente conocido como Azure Security Center).

Consideraciones específicas de IaaS al usar Virtual Machines

En escenarios en los que se requiere el uso de iaaS Virtual Machines, es necesario tener en cuenta algunos aspectos específicos.

Consideraciones de diseño

• Las imágenes no se actualizan automáticamente una vez implementadas.
• Novedades no se instalan automáticamente en máquinas virtuales en ejecución.
• Normalmente, las imágenes y las máquinas virtuales individuales no están protegidas de fábrica.

Recomendaciones de diseño

• No permita el acceso directo a través de la red pública de Internet para Virtual Machines proporcionando acceso a SSH, RDP u otros protocolos. Use siempre Azure Bastion y jumpboxes con acceso limitado a un pequeño grupo de usuarios.
• Restrinja la conectividad directa a Internet mediante grupos de seguridad de red, Firewall (Azure) o Application Gateways (nivel 7) para filtrar y restringir el tráfico de salida.
• En el caso de las aplicaciones de varios niveles, considere la posibilidad de usar subredes diferentes y usar grupos de seguridad de red para restringir el acceso entre ellas.
• Priorice el uso de la autenticación de clave pública, siempre que sea posible. Almacene secretos en un lugar seguro, como Azure Key Vault.
• Proteja las máquinas virtuales mediante la autenticación y el control de acceso.
• Aplique los mismos procedimientos de seguridad que se describen para escenarios de aplicaciones críticas.

Siga y aplique prácticas de seguridad para escenarios de aplicaciones críticas como se describió anteriormente, cuando corresponda, así como los procedimientos recomendados de seguridad para cargas de trabajo de IaaS en Azure.

Paso siguiente

Revise los procedimientos recomendados para los procedimientos operativos para escenarios de aplicaciones críticas.

Procedimientos operativos