Procedimientos recomendados de Azure Enclave

En este artículo se describen los conceptos clave y los procedimientos recomendados para Azure Enclave.

Azure Enclave acelera y simplifica la implementación y administración de entornos de nube seguros, aislados y compatibles. Estos entornos están diseñados para administrar las misiones y cargas de trabajo más sensibles en entornos comerciales y aislados (air-gapped).

La creación y ejecución de cargas de trabajo correctamente en Azure Enclave requiere comprender e implementar algunos conceptos clave, entre los que se incluyen:

El grupo de productos Azure Enclave, los equipos de ingeniería y los equipos de campo desarrollaron los siguientes procedimientos recomendados y artículos conceptuales. Los artículos se crearon para ayudar a los propietarios y desarrolladores de comunidades y enclaves a comprender mejor conceptos importantes e implementar las funcionalidades adecuadas.

Configuración de Azure

Lea estos pasos de configuración para determinar si estos pasos de configuración se ajustan a los casos de uso de enclave de Azure.

Configuración de grupos de recursos de Network Watcher

Para evitar posibles problemas con la creación del registro de flujo de red virtual , configure el NetworkWatcherRG grupo de recursos manualmente de antemano y asigne a la Mission Enclave aplicación el Owner rol en ese grupo de recursos, o compruebe que la configuración y la asignación de roles se produjeron automáticamente antes de crear el primer enclave en la suscripción.

Para mitigar este posible problema, para cada suscripción, crea manualmente el grupo de recursos NetworkWatcher denominado NetworkWatcherRG en las nuevas suscripciones y, a continuación, concede la Mission Enclave aplicación Azure Enclave Owner en NetworkWatcherRG:

  1. Seleccione el NetworkWatcherRG grupo de recursos, seleccione Access control (IAM)y Add , y Add role assignment.

Captura de pantalla que muestra la selección para asignar un rol al grupo de recursos en el portal.

  1. Seleccione Privileged administrator roles, seleccione ownery, a continuación, seleccione Next.

Captura de pantalla que muestra la vista de selección para agregar el rol de propietario en el portal.

  1. Seleccione Select members, escriba Mission Enclave en la búsqueda y seleccione la aplicación Mission Enclave, seleccione Select y, a continuación, Next.

Captura de pantalla que muestra cómo seleccionar la aplicación Mission Enclave en el portal.

  1. Si la suscripción requiere una condición, seleccione Allow user to assign all roles except privileged administrator roles Owner, UAA, RBAC (Recommended)y, a continuación, seleccione Review + assign.

Captura de pantalla que muestra la vista para añadir una condición si tu suscripción lo requiere.

  1. Una vez completada la actualización, puede empezar a implementar recursos de Azure Enclave.

Cuando se crea una comunidad o enclave, Azure Enclave intenta los pasos siguientes:

  1. Compruebe si NetworkWatcherRG existe. Si no es así, intente crear ese grupo de recursos.
  2. Compruebe si la Mission Enclave aplicación tiene una asignación Owner permanente en NetworkWatcherRG. De no ser así, intente asignar la Mission Enclave aplicación como una Owner asignación permanente en NetworkWatcherRG. Incluso si existe un permiso heredado Owner , se intenta crear una asignación permanente Owner .
  3. Si se produce un error en cualquier paso, es posible que se produzca un error en las implementaciones de enclave al intentar crear registros de flujo de red virtual.

Patrones de diseño de redes y organización para Azure Enclave

Servicios multiinquilino

Diseño de redes

Azure Enclave reúne las funcionalidades y la flexibilidad de varios productos de red Azure en una interfaz de usuario simplificada, entre las que se incluyen:

  • Azure Virtual WAN
  • Azure Firewall
  • Red virtual de Azure
  • Grupos de seguridad de red

Azure Enclave realiza las siguientes recomendaciones generales:

  • Las comunidades deben implementarse cuando tenga requisitos de red para proporcionar una Azure Firewall, que es la plataforma de seguridad inteligente del firewall como servicio de Azure.
  • Las comunidades deben implementarse cuando existan requisitos de confidencialidad organizativa o de datos que exijan separar una Virtual WAN de tipo hub-and-spoke de otra Virtual WAN de tipo hub-and-spoke.
  • Las comunidades deben implementarse cuando tenga requisitos de red para admitir sistemas que abarcan varias regiones de Azure, en las que cada región requiere su propia Azure Firewall. Obtenga más información sobre los casos de uso de Azure Firewall de varios concentradores.
  • Las comunidades deben implementarse cuando existan requisitos de red para dar soporte a un gran número de sistemas en una red de área amplia distribuida de tipo hub-and-spoke. Obtenga más información sobre Azure Virtual WAN.
  • Los enclaves deben implementarse cuando tenga requisitos de red para implementar cargas de trabajo similares como parte de la misma red privada.
  • Los enclaves deben implementarse cuando tenga requisitos de carga de trabajo que necesiten una red virtual y se encuentran dentro de la misma Virtual WAN que una comunidad existente.

Consideraciones de diseño de red de la comunidad

Debe seguir, siempre que sea posible, la documentación de procedimientos recomendados del servicio subyacente Azure al planear las redes de la comunidad. Inclusión de estos procedimientos recomendados:

Consideraciones de diseño de la red de enclave

Debería seguir, siempre que sea posible, la documentación de prácticas recomendadas de los servicios subyacentes de Azure al planificar las redes de enclave. Inclusión de estos procedimientos recomendados:

Obtenga más información sobre los procedimientos recomendados generales de redes de Azure.

Despliegue de cargas de trabajo

  • Las cargas de trabajo están vinculadas a un grupo de recursos administrado en el que los colaboradores del enclave pueden implementar recursos de Azure.
  • De forma predeterminada, todas las cargas de trabajo de enclave de Azure se rigen a través de iniciativas de Azure Policy integradas.
  • Las cargas de trabajo asociadas a una comunidad que tiene una configuración de gobernanza personalizada, usan esta configuración única en lugar de la configuración predeterminada de gobernanza de enclave de Azure.
  • Consideraciones para asignar nombres a recursos de Azure

Patrones de diseño de seguridad para Azure Enclave

Tenga en cuenta estos patrones de diseño de seguridad al diseñar los entornos de Azure Enclave.

Límites de seguridad

Azure Enclave emplea un enfoque de defensa en profundidad cuando se trata de ciberseguridad. Al implementar una comunidad y enclaves, Azure Enclave establece varias capas de aislamiento de red, seguridad, controles de acceso y registro y supervisión.

Responsabilidades de seguridad compartidas

Como servicio en Azure, Azure Enclave también se compromete a mantener el modelo de responsabilidad compartida en la nube. Para Azure Enclave específicamente, las cargas de trabajo son responsabilidad suya. La responsabilidad compartida de Azure se hereda en las cargas de trabajo si ha implementado servicios PaaS en ellas.

Sus comunidades y enclaves representan una responsabilidad compartida. Las comunidades y los enclaves utilizan un modelo de responsabilidad compartida en el que el proveedor de recursos de Azure Enclave crea su entorno de red hub-and-spoke seguro y preconfigurado. Puede administrar este entorno de red mediante la creación de puntos de conexión de enclave, puntos de conexión de comunidad, centros de tránsito o conexiones de enclave. Algunas versiones preliminares de Azure Enclave también permiten realizar cambios manualmente en la red a través de controles subyacentes proporcionados por Azure Virtual WAN, Azure Virtual Network y otros servicios de red Azure subyacentes.

La gobernanza de Azure Enclave también es una responsabilidad compartida. El proveedor de recursos de Azure Enclave crea una lista segura y preconfigurada de iniciativas de Azure Policy para cada implementación de carga de trabajo. Sin embargo, las comunidades ahora pueden personalizar las iniciativas de Azure Policy de la comunidad, lo que invalida la lista preconfigurada para la carga de trabajo. A pesar de los requisitos de la directiva, conservas la posibilidad de establecer excepciones manuales a estas asignaciones de la Iniciativa de Políticas de Azure, en función de sus requisitos de cumplimiento o gobernanza.

Procedimientos recomendados de seguridad de Azure

Azure Enclave recomienda seguir los procedimientos recomendados y patrones de seguridad de Microsoft Azure para implementar recursos Azure e implementar cargas de trabajo.

Debe seguir los procedimientos recomendados de seguridad de Azure - Cloud Adoption Framework para organizar los sistemas, la infraestructura en la nube, el personal de TI, las estructuras de los equipos y la formación corporativa de concienciación sobre ciberseguridad.

Filtración de datos a través del sistema de nombres de dominio

La filtración de datos a través del sistema de nombres de dominio (DNS) representa un problema de seguridad importante para las organizaciones, ya que usa un protocolo que normalmente se permite a través de firewalls y rara vez se supervisa para actividades malintencionadas. Los atacantes pueden aprovechar las consultas DNS para extraer datos confidenciales de los sistemas en peligro mediante la codificación de información dentro de nombres de dominio o mediante técnicas de tunelización de DNS. Este método es insidioso porque el tráfico DNS parece legítimo y a menudo elude las herramientas tradicionales de supervisión de seguridad.

En los ataques de filtración de datos basados en DNS, los actores malintencionados codifican datos robados en consultas DNS, a menudo mediante técnicas como el etiquetado de subdominios o las consultas de registro TXT. Por ejemplo, un atacante podría dividir datos confidenciales en fragmentos e insertar cada fragmento como subdominio en consultas DNS en dominios controlados por atacantes. Los datos se pueden extraer de los registros DNS en el servidor DNS del atacante. Este enfoque permite la filtración gradual de grandes conjuntos de datos mientras mantiene un perfil bajo, ya que las consultas DNS aparecen como solicitudes normales de resolución de nombres.

Abordar la exfiltración de datos con la Directiva de seguridad de Azure DNS

Azure DNS Directiva de seguridad proporciona protección completa contra ataques de filtración de datos basados en DNS al ofrecer un control pormenorizado sobre el tráfico DNS dentro de Azure Redes virtuales. Este servicio permite a las organizaciones implementar medidas de seguridad proactivas que puedan detectar, alertar y bloquear actividades DNS sospechosas antes de que los datos se puedan filtrar correctamente.

La directiva de seguridad de Azure DNS aborda la filtración de datos DNS a través de varios mecanismos clave. En primer lugar, proporciona la capacidad de crear reglas de tráfico DNS que pueden bloquear consultas a dominios malintencionados conocidos o patrones de dominio sospechosos que se usan habitualmente en intentos de filtración. Las organizaciones pueden mantener listas de bloques de dominios asociados con los servicios de infraestructura de comandos y control o de filtración de datos. En segundo lugar, el servicio ofrece funcionalidades completas de registro dns que capturan todas las consultas y respuestas DNS dentro de redes virtuales protegidas. Este registro permite a los equipos de seguridad analizar patrones de tráfico DNS e identificar posibles intentos de filtración. En tercer lugar, el motor de directivas admite el filtrado de dominios comodín, lo que permite a las organizaciones bloquear categorías completas de dominios sospechosos o implementar listas de permitidos para destinos DNS aprobados.

La implementación de la Directiva de seguridad de Azure DNS crea varias capas de defensa contra la exfiltración de datos DNS. Las reglas de tráfico se pueden configurar con distintos niveles de prioridad, lo que permite directivas de seguridad complejas que equilibran la seguridad con los requisitos operativos. El servicio admite el bloqueo en tiempo real de consultas malintencionadas al tiempo que proporciona registros detallados para el análisis forense y la búsqueda de amenazas. Además, los vínculos de red virtual garantizan que las directivas de seguridad de DNS se apliquen de forma coherente en todos los recursos de los segmentos de red protegidos, lo que crea un perímetro de seguridad completo que resulta difícil para los atacantes omitir.

Para las implementaciones de Azure Enclave, la Directiva de seguridad de Azure DNS debe integrarse como parte de la arquitectura general de seguridad. Las organizaciones deben configurar directivas de seguridad de DNS para supervisar y controlar el tráfico DNS de las cargas de trabajo del enclave, lo que garantiza que los datos confidenciales permanecen protegidos incluso si las cargas de trabajo individuales se ponen en peligro. La revisión y actualización periódicas de las listas de dominios DNS, combinadas con la supervisión continua de registros DNS, proporciona protección continua frente a amenazas basadas en DNS en constante evolución y ayuda a mantener la integridad de seguridad del entorno de Azure Enclave.

Puede encontrar más información en la documentación de la directiva de seguridad de DNS.

Implementación de directivas de seguridad de DNS para denegar por defecto

Para obtener la máxima seguridad en entornos de enclave de Azure, las organizaciones deben implementar un enfoque de "denegación de forma predeterminada, permitir por excepción" para el filtrado de DNS. Este modelo de seguridad garantiza que todas las consultas DNS estén bloqueadas a menos que se permita explícitamente, lo que proporciona la protección más segura frente a las comunicaciones de filtración de datos basadas en DNS y comandos y controles.

El enfoque de denegación por defecto se implementa mediante una estructura de reglas DNS de dos niveles dentro de la Directiva de seguridad de Azure DNS:

Paso 1: Crear la regla de denegación predeterminada Cree una lista de dominios DNS que contenga solo el dominio . raíz (punto). Este dominio comodín responde a todas las consultas DNS posibles. Asocie esta lista de dominios a una regla de tráfico DNS configurada con:

  • Prioridad: 65000 (prioridad más baja)
  • Acción: Bloquear
  • Lista de dominios: dominio raíz (.)

Esta regla actúa como catch-all que bloquea cualquier consulta DNS no permitida explícitamente por reglas de mayor prioridad.

Paso 2: Crear reglas de lista de permitidos Cree listas de dominios DNS independientes que contengan dominios específicos necesarios para las operaciones empresariales legítimas. Estos pueden incluir:

  • Servicios Azure esenciales (por ejemplo, *.azure.com, *.microsoft.com)
  • Dominios corporativos y servicios que no son de Microsoft de confianza
  • Servicios de actualización del sistema operativo
  • Dominios de autoridad de certificación

Asocie las listas de elementos permitidos a las reglas de tráfico DNS configuradas con:

  • Prioridad: 500-1000 (mayor prioridad que la denegación predeterminada)
  • Acción: Permitir
  • Listas de dominios: dominios aprobados específicos

Procesamiento de reglas basado en prioridades La directiva de seguridad de Azure DNS procesa las reglas en orden de prioridad (los números más bajos indican una prioridad más alta). Cuando se realiza una consulta DNS:

  1. El sistema evalúa primero las reglas de permiso de alta prioridad (prioridad 500-1000)
  2. Si el dominio coincide con una lista de permitidos, se permite la consulta.
  3. Si no hay ninguna allow coincidencia de reglas, la consulta pasa a la regla de denegación predeterminada (prioridad 65000) y se bloquea el tráfico.

Este enfoque proporciona varias ventajas de seguridad:

  • Modelo de confianza cero: no se permiten consultas DNS a menos que se autorice explícitamente.
  • Control pormenorizado: las organizaciones pueden controlar con precisión qué dominios son accesibles
  • Registro de auditoría: todas las consultas bloqueadas se registran, lo que proporciona visibilidad sobre posibles amenazas.
  • Actualizaciones incrementales: se pueden agregar nuevos dominios aprobados para permitir listas sin modificar la regla de denegación predeterminada

Implementación de ejemplo:

Priority 500: Allow rule for Azure services
- Domain List: azure-services (contains azure.com., microsoft.com.)
- Action: Allow

Priority 600: Allow rule for business applications
- Domain List: business-domains (contains company.com., partner1.com., partner2.com.)
- Action: Allow

Priority 65000: Default deny rule
- Domain List: deny-all (contains .)
- Action: Block

Las organizaciones que implementan este enfoque deben comenzar con un inventario completo de los dominios necesarios y refinar gradualmente la lista de dominios permitidos en función de las necesidades operativas y los registros de seguridad. La revisión periódica de las consultas bloqueadas ayuda a identificar dominios legítimos que podrían necesitar agregarse a las listas de permitidos al tiempo que mantiene una posición de seguridad sólida.

Implementación de directivas de DNS predenegadas por defecto con el Servidor DNS de Windows

En entornos que no pueden utilizar la directiva de seguridad de Azure DNS o que requieren control local de DNS, se puede implementar una seguridad similar de denegación por defecto mediante el Servidor DNS de Windows con las funciones de directiva de DNS. Este enfoque proporciona protección comparable frente a la filtración de datos basada en DNS, a la vez que mantiene la compatibilidad con la infraestructura de Windows existente.

Windows servidor DNS (Windows Server 2016 y versiones posteriores) admite la funcionalidad de directiva DNS que permite a las organizaciones implementar reglas sofisticadas de filtrado de DNS. El modelo de denegación de forma predeterminada se puede lograr mediante una combinación de reglas de directiva DNS y configuraciones de zona.

Grupos de recursos administrados en Azure Enclave

Los grupos de recursos que contienen recursos administrados por Azure Enclave.

Grupo de recursos administrados por la comunidad

El grupo de recursos administrados por la comunidad contiene los recursos de infraestructura descritos en ¿Qué es una comunidad?.

El nombre del grupo de recursos administrados por la comunidad sigue esta convención de nomenclatura: myCommunityName-HostedResources-<GUID>. Cada implementación de la comunidad crea este grupo de recursos y coloca la infraestructura de la comunidad en su interior. Al eliminar la comunidad, el proveedor de recursos de Azure Enclave elimina automáticamente el grupo de recursos administrado por la comunidad.

Captura de pantalla que muestra un ejemplo de los recursos de la comunidad administrados por Azure Enclave.

El grupo de recursos administrados por la comunidad tiene las siguientes limitaciones:

  • No se puede especificar un grupo de recursos existente para el grupo de recursos administrado por la comunidad.
  • No se puede especificar una suscripción diferente para el grupo de recursos administrado por la comunidad.
  • No se puede cambiar el nombre del grupo de recursos administrados por la comunidad después de crear la comunidad.
  • No se pueden especificar nombres para los recursos administrados dentro del grupo de recursos administrados de la comunidad.
  • No se pueden modificar ni eliminar las etiquetas creadas por Azure de los recursos administrados dentro del grupo de recursos administrados de la comunidad.

Si modifica o elimina etiquetas, recursos y otras propiedades de recursos creadas Azure en el grupo de recursos administrados por la comunidad, podría ver resultados inesperados. Dado que Azure Enclave administra el ciclo de vida de la infraestructura en el grupo de recursos administrado por la comunidad, cualquier cambio podría hacer que su enclave pasara a un estado no admitido.

Un escenario común en el que desea modificar los recursos es a través de etiquetas. Azure Enclave permite crear y modificar etiquetas que se propagan a recursos del grupo de recursos administrados por la comunidad. Es posible que quiera crear o modificar etiquetas personalizadas, por ejemplo, para asignar un centro de costos o una unidad de negocio. Esto también se puede lograr creando políticas de Azure con ámbito en el grupo de recursos administrado por la comunidad.

Nota:

Si no tiene habilitado el bloqueo del grupo de recursos administrado por la comunidad, puede modificar directamente cualquier recurso del grupo de recursos administrado por la comunidad. La modificación directa de los recursos del grupo de recursos administrados por la comunidad puede hacer que el enclave se vuelva inestable o no responda.

Grupo de recursos administrado por el enclave

El grupo de recursos administrados por enclave contiene los recursos de infraestructura descritos en ¿Qué es un enclave?.

El nombre del grupo de recursos administrado por el enclave sigue esta convención de nomenclatura: myEnclaveName-HostedResources-<GUID>. Cada implementación de enclave crea este grupo de recursos y coloca la infraestructura de enclave dentro de él. Al eliminar el enclave, el proveedor de recursos de Azure enclave elimina automáticamente el grupo de recursos administrado por enclave.

Captura de pantalla que muestra un ejemplo de los recursos de enclave administrados por Azure Enclave.

El grupo de recursos administrados por enclave tiene las siguientes limitaciones:

  • No se puede especificar un grupo de recursos existente para el grupo de recursos administrado por el enclave.
  • No se puede especificar una suscripción diferente para el grupo de recursos administrado por el enclave.
  • No se puede cambiar el nombre del grupo de recursos administrados del enclave después de crear el enclave.
  • No se pueden especificar nombres para los recursos administrados en el grupo de recursos administrados del enclave.
  • No se pueden modificar ni eliminar las etiquetas creadas por Azure de los recursos administrados en el grupo de recursos administrados del enclave.

Si modifica o elimina etiquetas, recursos y otras propiedades de recursos creadas Azure en el grupo de recursos administrados por el enclave, podría obtener resultados inesperados, como errores de red, acceso y supervisión. Dado que Azure Enclave administra el ciclo de vida de la infraestructura en el grupo de recursos administrado del enclave, cualquier cambio podría hacer que el enclave pase a un estado no compatible.

Un escenario común en el que desea modificar los recursos es a través de etiquetas. Azure enclave permite crear y modificar etiquetas que se propagan a los recursos del grupo de recursos administrados por el enclave. Es posible que quiera crear o modificar etiquetas personalizadas, por ejemplo, para asignar un centro de costos o una unidad de negocio. El etiquetado de recursos también se puede lograr mediante la creación de directivas de Azure con un ámbito en el grupo de recursos administrado por el enclave.

Advertencia

La modificación de los recursos en el grupo de recursos administrados del enclave puede hacer que el enclave se vuelva inestable o no responda.

Grupo de recursos de carga de trabajo

La carga de trabajo está vinculada a uno o varios grupos de recursos donde puede crear y organizar los recursos de Azure.

Adición de un grupo de recursos a una carga de trabajo

La adición de un nuevo grupo de recursos normalmente requiere que el usuario tenga permisos para crear un nuevo grupo de recursos. Los roles de suscripción Owner o Contributor tienen este permiso, pero es posible que la persona que crea el grupo de recursos de la carga de trabajo no tenga o no necesite este permiso privilegiado. Azure Enclave intenta crear tres maneras de crear el nuevo grupo de recursos que va desde los requisitos de permisos de usuario más altos hasta los más bajos, lo que ofrece flexibilidad para el usuario:

  • Opción 1: requiere los permisos con más privilegios para la persona que crea o actualiza la carga de trabajo, lo que proporciona control total, pero necesita acceso elevado.
  • Opción 2: Implica la configuración manual por parte del usuario para conceder la propiedad de la Mission Enclave aplicación en el nivel de suscripción, lo que podría no alinearse con sus preferencias.
  • Opción 3: no requiere permisos para el usuario o la aplicación, lo que lo convierte en el método más sencillo, pero impone una relación estricta de 1:1 entre el grupo de recursos y la Mission Enclave carga de trabajo.

Cada opción tiene ventajas y limitaciones, control de equilibrio, comodidad y flexibilidad para adaptarse a distintas necesidades. Estas opciones se evalúan una por una, empezando por la opción 1, y la primera opción que funcione se utiliza para crear el nuevo grupo de recursos.

Después de crear un grupo de recursos de carga de trabajo mediante la opción 3, verá una advertencia de que la opción 3 no se puede usar para los siguientes grupos de recursos de carga de trabajo de esa carga de trabajo. También puede crear una nueva carga de trabajo y, a continuación, crear un nuevo grupo de recursos de carga de trabajo mediante la opción 3 de nuevo.

Agregue un grupo de recursos al enclave:

  1. Abra la página del portal de Azure para la carga de trabajo.
  2. Seleccione Manage y, a continuación, Resource Groups.
  3. Seleccione Add a resource group.
  4. En la ventana lateral que se abre, seleccione Create new para proporcionar el nombre del nuevo grupo de recursos vacío o seleccione la Resource Group lista desplegable para elegir un grupo de recursos existente.
  5. Seleccione OK y, a continuación, Save.

¿Cómo es un grupo de recursos de carga de trabajo diferente de otros grupos de recursos de Azure?

Un grupo de recursos de carga de trabajo es un componente crítico de la seguridad y el cumplimiento de Azure enclave, ya que es donde se crean los recursos importantes. Dado que estos grupos de recursos de carga de trabajo están vinculados a una carga de trabajo y la carga de trabajo está vinculada a un enclave, Azure Enclave administra la eliminación de grupos de recursos administrados por cargas de trabajo.

Además, la directiva se aplica a los grupos de recursos de carga de trabajo. Al igual que las directivas de la comunidad se aplican al enclave, las directivas del enclave se aplican a los recursos de carga de trabajo y a los grupos de recursos de la carga de trabajo. Al crear un nuevo grupo de recursos de carga de trabajo, las funciones se establecen a nivel del enclave y se heredan de la suscripción. Algunas de estas directivas se heredan de la comunidad y también puede crear directivas en el enclave que se apliquen a las cargas de trabajo y a los grupos de recursos de carga de trabajo.

Organización de recursos en grupos de recursos de carga de trabajo

Si desea dividir los recursos en dos grupos de recursos, puede elegir cualquiera de estas opciones:

  • dividir esos recursos entre dos grupos de recursos vinculados a una carga de trabajo
  • dividir esos recursos entre dos cargas de trabajo cada una con uno o varios grupos de recursos

Eliminación de cargas de trabajo

Cuando se solicita una eliminación de la carga de trabajo, se comprueban los grupos de recursos de carga de trabajo para asegurarse de que están vacíos. Si los grupos de recursos de carga de trabajo contienen recursos, se produce un error en la eliminación de la carga de trabajo solicitada y se muestra un error. Para eliminar la carga de trabajo y los grupos de recursos de carga de trabajo, primero vacíe los grupos de recursos de carga de trabajo. Los grupos de recursos de carga de trabajo vacíos ayudan a evitar la eliminación accidental de recursos importantes.

La eliminación de un recurso vinculado a la carga de trabajo sigue el mismo comportamiento. Por ejemplo, si se solicita una eliminación de la comunidad, pero todos los grupos de recursos de carga de trabajo no están vacíos, la operación muestra un error. Vacíe los grupos de recursos de la carga de trabajo e inténtelo de nuevo.

El grupo de recursos administrados de carga de trabajo tiene las siguientes limitaciones:

  • No se puede especificar un grupo de recursos existente para el grupo de recursos administrado por la carga de trabajo.
  • No puede especificar una suscripción diferente para el grupo de recursos administrado por la carga de trabajo.
  • No se puede cambiar el nombre del grupo de recursos administrados de la carga de trabajo después de crear la carga de trabajo.
  • No se pueden modificar ni eliminar las etiquetas creadas por Azure de los recursos administrados dentro del grupo de recursos administrados de la carga de trabajo.

Un escenario común en el que desea modificar los recursos es a través de etiquetas. Azure Enclave permite crear y modificar etiquetas que se propagan a los recursos del grupo de recursos administrados por la carga de trabajo. Es posible que quiera crear o modificar etiquetas personalizadas, por ejemplo, para asignar un centro de costos o una unidad de negocio. El etiquetado también se puede lograr creando Azure Policies con un ámbito en el grupo de recursos administrado de la carga de trabajo.

Otros procedimientos recomendados de Azure

A medida que cree sus comunidades, enclaves y cargas de trabajo en Azure, es importante tener en cuenta los siguientes principios de diseño universal:

  • Last updated on