Preparación ante incidentes de Microsoft Azure: unificado
Cuando se declara un incidente de Azure, comunicamos las actualizaciones a las suscripciones o los inquilinos afectados a través de la hoja Problemas de servicio de Azure Service Health (dentro de Azure Portal).
Antes de un incidente
Se recomienda seguir estos pasos para estar preparados y ayudar a proteger su organización:
Recibir notificaciones y mantenerse al día en caso de incidentes que afecten a los servicios de Azure
Familiarícese con Azure Service Health en Azure Portal: el lugar donde acceder en caso de problemas.
Configure alertas de Service Health para notificarle cualquier problema: por correo electrónico, SMS, webhook, etc. en el nivel de suscripción, por servicios o por regiones.
El tipo de notificación de problemas de servicio alertará a la organización de que los servicios se ven afectados por incidentes de servicio.
El tipo de notificación de aviso de seguridad alertará a su organización de que los servicios se ven afectados por un incidente de seguridad o de privacidad.
Estas son recomendaciones básicas de configuración de alertas:
Para los tipos de problemas de servicio, mantenimiento planeado y aviso de estado:
- Sus cargas de trabajo críticas: configure alertas para su(s) suscripción(es) y servicio(s) que alimentan su(s) carga(s) de trabajo crítica(s).
- Configure alertas para servicios básicos en Azure Stack:
- "Infraestructura de red": capa fundamental en la pila de Azure en la que se basan todos los tipos de cargas de trabajo y aplicaciones, desde IaaS a SaaS.
- Servicio "Microsoft Azure Portal": servicio básico que se usa para administrar recursos de Azure. Su versatilidad lo posiciona como un servicio "comodín", que abarca una variedad de escenarios y experiencias de resumen de impacto que se comunicarán bajo este servicio.
Para los avisos de seguridad, escriba lo siguiente:
- Todas las suscripciones y servicios de Azure; por lo general, los agentes maliciosos atacan los recursos menos utilizados, por lo que es importante que este tipo de alerta cubra todos los recursos de Azure.
Además, la solución Alertas de línea base de Azure Monitor proporciona instrucciones y código completos para implementar una línea base de alertas de plataforma, así como alertas de mantenimiento del servicio a través de directivas e iniciativas en entornos de Azure, con opciones para la implementación automatizada o manual.
Asegúrese de que los siguientes roles tienen la información de contacto adecuada y que se revisan periódicamente para mantenerse al día. Para obtener más información, consulte Mantenerse informado sobre los problemas de seguridad de Azure: Azure Service Health | Microsoft Learn)
Administrador de suscripciones y propietario de la suscripción: contactos que se usarán para recibir notificaciones (a través de Azure Portal o correo electrónico, en función de los requisitos de comunicación) para problemas de seguridad que afectan al nivel de suscripción.
Administrador global de inquilinos y Contacto técnico: contactos que se usarán para recibir notificaciones (a través de Azure Portal o correo electrónico, en función de los requisitos de comunicación) para los problemas de seguridad que afectan a nivel de inquilino.
Administrador de seguridad: puede revisar y hacer cambios en la directiva de seguridad, aplicar recomendaciones y ver y descartar alertas.
Considere la posibilidad de usar alertas de estado o eventos programados para mantenerse al tanto de problemas -específicos para que sus usuarios y sistemas conozcan los problemas -específicos y los próximos eventos de mantenimiento.
Para comprender los principios de comunicación de Azure, revise la experiencia Avance de la interrupción: automatización, comunicación y transparencia | Blog y Novedades de Azure | Microsoft Azure.
Aumentar la seguridad y la posición de resistencia para evitar o minimizar el impacto de los incidentes de manera potencial
Revise e implemente los procedimientos recomendados de seguridad operativa para proteger los datos, las aplicaciones y otros recursos, especialmente los siguientes:
Aplique la autenticación multifactor para mitigar las preocupaciones sobre la exposición.
Implemente alertas para usuarios de riesgo alto. Configure el acceso condicional para asegurarse de que se le notifica cuando hay un “usuario de riesgo” en su entorno.
Controlar el movimiento de suscripciones desde y hacia directorios. Con fines de gobernanza, los administradores globales pueden permitir o impedir que los usuarios de directorio cambien los directorios desconocidos dentro de su organización. Esto garantiza que la organización tenga visibilidad completa de las suscripciones que se usan en los directorios de la organización e impida el movimiento de suscripciones que podrían ir a un directorio desconocido.
Optimice la confiabilidad, seguridad y mucho más de las cargas de trabajo críticas con Azure Well-Architected Framework (WAF) y Revisión. Tenga en cuenta también estas acciones para complementar el trabajo en WAF.
Aproveche el libro Confiabilidad, integrado en Azure Portal en la hoja Azure Advisor, para revisar la posición de confiabilidad de las aplicaciones, evaluar los riesgos y planear mejoras.
Expandir la carga de trabajo/las implantaciones entre regiones para garantizar la continuidad empresarial y la recuperación en caso de catástrofe (BCDR). Use la lista completa publicada de pares de regiones de Azure.
Ampliar la carga de trabajo/las implementaciones dentro de una región en zonas de disponibilidad.
Consideración del aislamiento de máquinas virtuales en Azure: Azure Virtual Machines | Microsoft Learn para cargas de trabajo críticas para la empresa.
Considere las configuraciones de mantenimiento para la capacidad de controlar y administrar las actualizaciones de muchas máquinas virtuales de Azure.
Use Azure Chaos Studio para evaluar la resistencia de las aplicaciones de Azure. Someta las aplicaciones de Azure a errores controlados, reales o simulados, para observar la resistencia de las aplicaciones y la respuesta a interrupciones como la latencia de red, la interrupción del almacenamiento, los secretos con fecha de expiración y la interrupción del centro de datos.
Use el Libro de retirada de servicios, que se integra en Azure Portal en la hoja de Azure Advisor, como vista única de nivel de recurso centralizado de las retiradas de servicios. Le ayuda a evaluar el impacto, evaluar las opciones y planear la migración de la retirada de servicios y características.
Siga el blog de confiabilidad avanzada de Azure para mantenerse al día de los esfuerzos de Azure en lo que respecta a los esfuerzos de resistencia continua.
Durante un incidente
Cuando las suscripciones clave se ven afectados por un incidente, es importante que sepa dónde y cómo encontrar las comunicaciones pertinentes relativas a este incidente:
Revise las alertas de Azure Service Health en Azure Portal para ver las actualizaciones más recientes de nuestros ingenieros.
- Es importante tener en cuenta que los contactos de rol específicos mencionados en la sección "antes de un incidente" (es decir, administrador de suscripciones/propietario, contacto técnico/de privacidad, administrador de inquilinos) también pueden recibir notificaciones por correo electrónico para incidentes de seguridad o privacidad.
Si hay problemas al acceder al portal, compruebe la página pública de estado de Azure azure.status.microsoft como copia de seguridad.
Si alguna vez hay problemas con la página Estado, busque actualizaciones a través de @AzureSupport en "X" (antes Twitter).
¿Por qué usar Service Health en lugar de la página Estado pública?
Muchos clientes comprueban nuestras páginas de estado accesibles públicamente (como azure.status.microsoft) en los primeros signos de posibles problemas para ver si hay problemas conocidos con nuestros servicios en la nube. Estas páginas solo muestran problemas generalizados que cumplen ciertos criterios, no incidentes más pequeños que afectan a menos clientes.
Azure Service Health (dentro de Azure Portal) sabe qué suscripciones e inquilinos administra, por lo que muestra una vista mucho más precisa de los problemas conocidos que afectan a la interrupción. También le permite configurar alertas para que se le pueda notificar de manera automática.
¿Cuándo resulta útil abrir un caso de soporte técnico?
Si el incidente de servicio ya se ha comunicado a través de Estado del servicio, esto incluirá toda la información más reciente y no será necesario abrir una solicitud de soporte técnico. Si se ve afectado por un incidente de servicio pero no ve el problema representado en la página Estado del servicio, abra una solicitud de soporte técnico.
Si los materiales de seguridad recibidos no cubren alguna pregunta, abra una solicitud de soporte técnico haciendo referencia al Id. de seguimiento.
Después de un incidente
Lea la revisión posterior a incidentes (PIR) en el panel Historial de mantenimiento de Azure Service Health (o a través de alertas de Service Health configuradas por el cliente) para comprender lo que hemos aprendido.
En caso de incidentes importantes que cumplan los criterios de nuestra página de estado público, únase a un streaming en vivo de Azure Incident Retrospective para obtener respuestas a las preguntas o vea la grabación.
Si cree que puede ser elegible para un crédito de Acuerdo de Nivel de Servicio, cree una nueva solicitud de soporte técnico con un tipo de problema de "Solicitud de reembolso" e incluya el Id. de seguimiento de incidentes.