Automatización de la integración de Sentinel con Azure DevOps

En este artículo, se describe cómo automatizar las operaciones de integración e implementación de Microsoft Sentinel con Azure DevOps. Implemente Azure DevOps mediante las funcionalidades de Microsoft Sentinel para ayudarle a proteger la implementación. A continuación, use un marco de DevSecOps para administrar e implementar artefactos de Microsoft Sentinel a gran escala.

Architecture

En el siguiente diagrama se muestra la configuración de Azure DevOps y de IaC de Microsoft Sentinel.

Descargue un archivo Visio de esta arquitectura.

Flujo de datos

1. El facilitador (Scrum Master) y la administración de productos usan Azure DevOps para definir epopeyas, casos de usuario y elementos de trabajo pendiente como parte del trabajo pendiente del proyecto.
   • El facilitador (Scrum Master) y la administración de productos usan Azure Boards para crear el trabajo pendiente, programar el trabajo en sprints, revisar el panel del proyecto, crear la estructura del repositorio y establecer reglas de seguridad como flujos de trabajo y ramas de aprobación.
   • El repositorio de Git de Azure almacena los scripts y los permisos para administrar artefactos de Microsoft Sentinel en la infraestructura como código.
   • Los artefactos y el control de código fuente mantienen las extensiones y actualizan los paquetes o componentes del flujo de trabajo de DevSecOps que se usan en la solución, como Azure Resource Manager Template Toolkit y PowerShell Pester.
2. Artefactos de Microsoft Sentinel:
   • Directivas. Los ingenieros de SIEM usan directivas de Azure en la arquitectura de referencia para configurar y escalar la configuración de diagnóstico de los servicios de Azure. Las directivas ayudan a automatizar la implementación de los conectores de datos de Microsoft Sentinel, como Azure Key Vault. Las directivas dependen de la API OMSIntegration.
   • Conectores. Microsoft Sentinel usa conectores lógicos, los conectores de datos de Azure, para ingerir datos de seguridad, como en auditorías o métricas, de orígenes de datos compatibles, como Microsoft Entra ID, recursos de Azure, Microsoft Defender o soluciones de terceros. La API de SecurityInsights administra la lista principal de conectores de datos. Otros se basan en la API OMSIntegration y se administran con la configuración de diagnóstico de Azure Policy.
   • Identidad administrada. Microsoft Sentinel usa la identidad administrada para actuar en nombre de la identidad de servicio administrada (MSI) mientras interactúa con cuadernos de estrategias, aplicaciones lógicas o runbooks de automatización y el almacén de claves.
   • Automatización. Los equipos del SOC usan la automatización durante las investigaciones. Los equipos de SOC ejecutan procedimientos de adquisición de datos forenses digitales con Azure Automation, como la cadena de custodia de máquinas virtuales de Azure o eDiscovery (Premium) para Microsoft Defender.
   • Análisis. Los analistas del SOC o los buscadores de amenazas usan reglas de análisis integradas o personalizadas para analizar y correlacionar datos en Microsoft Sentinel o para desencadenar cuadernos de estrategias si se identifican una amenaza y un incidente.
   • Cuadernos de estrategias. Las aplicaciones lógicas ejecutan las acciones repetibles de SecOps, como asignar un incidente, actualizar un incidente o tomar acciones de corrección, como aislar o contener una máquina virtual, revocar un token o restablecer una contraseña de usuario.
   • Búsqueda de amenazas. Los buscadores de amenazas usan funcionalidades proactivas de búsqueda de amenazas que se pueden acoplar con cuadernos de Jupyter para casos de uso avanzados, como el procesamiento de datos, la manipulación de datos, la visualización de datos, el aprendizaje automático o el aprendizaje profundo.
   • Libros. Los ingenieros de SIEM usan paneles de libros para visualizar tendencias y estadísticas, y para ver el estado de una instancia de Microsoft Sentinel y sus subcomponentes.
   • Información sobre amenazas. Un conector de datos específico que fusiona las fuentes de las plataformas de inteligencia sobre amenazas en Microsoft Sentinel. Se admiten dos métodos de conectividad: TAXII y Graph API. Ambos métodos sirven como tiIndicators o indicadores de inteligencia sobre amenazas en las API de seguridad.
3. Microsoft Entra ID. Las funcionalidades de administración de identidad y acceso se entregan a los componentes que se usan en la arquitectura de referencia, como identidades administradas, entidades de servicio, controles de acceso basado en rol (RBAC) de Azure para Microsoft Sentinel, aplicaciones lógicas y runbooks de automatización.
4. Azure Pipelines. Los ingenieros de DevOps usan canalizaciones para crear conexiones de servicio para administrar las distintas suscripciones de Azure, como el espacio aislado y los entornos de producción con canalizaciones de integración continua y entrega continua (CI/CD). Se recomienda usar flujos de trabajo de aprobación para evitar implementaciones inesperadas y entidades de servicio separadas si tiene como destino varias suscripciones por entorno de Azure.
5. Azure Key Vault. Los ingenieros del SOC usan el almacén de claves para almacenar certificados y secretos de entidad de servicio de forma segura. Este componente de la arquitectura ayuda a aplicar el principio de DevSecOps de no tener secretos en el código cuando lo usan las conexiones del servicio Azure Pipeline.
6. Suscripción de Azure. Los equipos del SOC usan dos instancias de Microsoft Sentinel en esta arquitectura de referencia, separadas dentro de dos suscripciones lógicas de Azure para simular entornos de producción y espacio aislado. Puede escalar según sus necesidades con otros entornos, como pruebas, desarrollo, preproducción, entre otros.

Ejemplo de flujo de datos

1. Un administrador agrega, actualiza o elimina una entrada en la bifurcación del administrador 1 del archivo de configuración de Microsoft 365.
2. El administrador confirma y sincroniza los cambios en su repositorio bifurcado.
3. El administrador crea una solicitud de incorporación de cambios (PR) para combinar los cambios en el repositorio principal.
4. La canalización de compilación se ejecuta en la PR.

Componentes

• Microsoft Entra ID es un servicio multiinquilino basado en la nube para administrar los controles de identidad y acceso.
• Azure DevOps es un servicio en la nube para colaborar en código, crear e implementar aplicaciones o planear y supervisar su trabajo.
• Azure Key Vault es un servicio en la nube para el almacenamiento de los secretos y el acceso a estos de forma segura. Un secreto es todo aquello cuyo acceso desea controlar de forma estricta, como las claves API, las contraseñas, los certificados o las claves criptográficas.
• Azure Policy es un servici para crear, asignar y administrar las definiciones de directivas en el entorno de Azure.
• Microsoft Sentinel es una solución escalable, nativa de nube, de SIEM y orquestación de seguridad, automatización y respuesta (SOAR).
• Azure Automation es un servicio para simplificar la administración en la nube mediante la automatización de procesos. Use Azure Automation para automatizar las tareas manuales, propensas a errores, con una ejecución prolongada y repetidas con frecuencia. La automatización ayuda a mejorar la confiabilidad, la eficacia y el tiempo de valor de su empresa.

Detalles del escenario

Los equipos del Centro de operaciones de seguridad (SOC) a veces experimentan desafíos al integrar Microsoft Sentinel con Azure DevOps. El proceso implica muchos pasos y la configuración puede tardar días e implica la repetición. Puede automatizar esta parte del desarrollo.

En la modernización para la nube, los ingenieros deben aprender constantemente nuevas aptitudes y técnicas para proteger y asegurar los recursos empresariales fundamentales. Los ingenieros deben crear soluciones sólidas y escalables que se mantengan al ritmo de los cambiantes escenarios de seguridad y las necesidades empresariales. Una solución de seguridad debe ser flexible, ágil y cuidadosamente planeada desde las primeras fases de desarrollo. Esta metodología de planeamiento temprano se conoce como desplazamiento a la izquierda.

En este artículo, se describe cómo automatizar las operaciones de integración e implementación de Microsoft Sentinel con Azure DevOps. Puede expandir la solución para organizaciones complejas que tienen varias entidades, suscripciones y distintos modelos operativos. Algunos de los modelos operativos compatibles con esta solución incluyen SOC local, SOC global, proveedor de servicios en la nube (CSP) y proveedor de servicios de seguridad administrado (MSSP).

Este artículo está dirigido a los siguientes destinatarios:

• Especialistas del SOC, como analistas y buscadores de amenazas
• Ingenieros de administración de eventos e información de seguridad (SIEM)
• Arquitectos de ciberseguridad
• Desarrolladores

Posibles casos de uso

A continuación se muestran los casos de uso típicos de esta arquitectura:

• Creación rápida de prototipos y pruebas de concepto. Esta solución es ideal para las organizaciones de seguridad y los equipos del SOC que desean mejorar la cobertura de amenazas en la nube o modernizar su infraestructura de SIEM con infraestructura como código (IaC) y Microsoft Sentinel.
• Microsoft Sentinel como servicio. Este marco de desarrollo integra los principios de administración del ciclo de vida de los servicios. Estos principios se adaptan a equipos simples o complejos, como los MSSP, que ejecutan acciones repetibles y estandarizadas en varios inquilinos de clientes, al tiempo que combinan la capacidad de Azure DevOps y Azure Lighthouse. Por ejemplo, un equipo que necesite publicar casos de uso de Microsoft Sentinel para un nuevo actor de amenazas o una campaña en curso podría usar esta solución.
• Creación de casos de uso del SOC para la detección de amenazas. Muchos grupos y plataformas de inteligencia sobre amenazas dependen del contenido y la taxonomía de MITRE Att&ck para analizar su posición de seguridad frente a técnicas y procedimientos de tácticas avanzados. La solución define un enfoque estructurado para desarrollar prácticas de ingeniería de detección de amenazas mediante la incorporación de terminología de MITRE Att&ck en el desarrollo de artefactos de Microsoft Sentinel.

En la siguiente ilustración se muestra un escenario de nube de MITRE Att&ck.

Descargue un archivo Visio de esta arquitectura.

Escenarios de ataque de definición de amenazas basados en MITRE

En esta tabla se muestran los términos, definiciones y detalles de aspectos importantes de los escenarios de ataque.

Elemento de datos	Descripción	Artefactos de Microsoft Sentinel
Título	Nombre descriptivo para el escenario de ataque, en función de las características del vector de ataque o las descripciones de técnicas.	Manifiesto de MITRE
Tácticas de MITRE ATT&CK	Tácticas de MITRE ATT&CK relacionadas con el escenario de ataque	Manifiesto de MITRE
Técnicas de MITRE ATT&CK	Técnicas de MITRE ATT&CK, incluida la técnica o el id. de sub técnica, relacionadas con el escenario de ataque.	Manifiesto de MITRE
Orígenes de conexión de datos	Origen de información recopilada por un sensor o sistema de registro que podría usarse para recopilar información relevante para identificar la acción que se está llevando a cabo, la secuencia de acciones o los resultados de esas acciones por parte de un adversario.	Conector de datos de Microsoft Sentinel u origen de registro personalizado
Descripción	Información sobre la técnica, qué es, para qué se usa normalmente, cómo un adversario puede aprovecharla y variaciones sobre cómo se podría usar. Incluye referencias a artículos autoritativos que describen información técnica relacionada con la técnica, así como en las referencias de uso comodín según corresponda.
Detección	Estrategias de proceso analítico de alto nivel, sensores, datos y detección útiles para identificar una técnica usada por un adversario. En esta sección se informa a los responsables de detectar el comportamiento de los adversarios, como los defensores de red, para que puedan llevar a cabo una acción como escribir un análisis o implementar un sensor. Debe haber suficiente información y referencias para apuntar a metodologías defensivas útiles. Es probable que la detección no siempre sea posible para una técnica determinada y debe documentarse como tal.	Búsqueda de amenazas de Analytics
Mitigación	Configuraciones, herramientas o procesos que impiden que una técnica funcione o que tenga el resultado deseado para un adversario. En esta sección se informa a los responsables de la mitigación contra adversarios, como los defensores de red o los responsables de la formulación de directivas, para que les permita llevar a cabo una acción como cambiar una directiva o implementar una herramienta. Es probable que la mitigación no siempre sea posible para una técnica determinada y debe documentarse como tal.
Mitigación	Configuraciones, herramientas o procesos que impiden que una técnica funcione o que tenga el resultado deseado para un adversario. En esta sección se describe cómo reducir los efectos de los ataques adversarios para los responsables de la defensa de red o los responsables de la formulación de directivas. Se tratan los pasos para cambiar una directiva o implementar una herramienta. Es probable que la mitigación no siempre sea posible para cierta técnica y debe documentarse como tal.	Cuadernos de estrategias, runbooks de automatización

Consideraciones

Estas consideraciones constituyen los pilares del Marco de buena arquitectura de Azure, un conjunto de principios rectores que puede usar para mejorar la calidad de una carga de trabajo. Para más información, consulte Marco de buena arquitectura de Microsoft Azure.

Seguridad

La seguridad proporciona garantías contra ataques deliberados y el abuso de datos y sistemas valiosos. Para más información, consulte Introducción al pilar de seguridad.

Con seguridad, en términos generales, la automatización aumenta la eficacia de las operaciones a la vez que ahorra tiempo para casos de uso más complejos, como la ingeniería de detección de amenazas, la inteligencia sobre amenazas, SOC y casos de uso de SOAR. Los equipos de DevOps deben saber dónde pueden usar IaC de forma segura en el contexto de CI/CD de Microsoft Sentinel. Este proceso introduce el uso de identidades específicas que usan las cuentas que no son humanas en Microsoft Entra ID denominadas entidades de servicio e identidades administradas.

En la siguiente tabla se resumen las consideraciones de seguridad para las entidades de servicio y los principales casos de uso que cubren Microsoft Sentinel y las canalizaciones de versión de Azure DevOps.

Caso de uso	Requisitos (privilegios mínimos)	Duración de la asignación de roles	Ámbito de permiso	Fideicomisario	Consideraciones sobre la seguridad
Habilitación de conectores de Microsoft Sentinel	Administrador de seguridad** Propietario* Colaborador de Microsoft Sentinel Lector	JIT (activación única) A propósito (cada vez que se implementan una suscripción y un conector nuevos)	Inquilino	SPN	Use el almacén de claves para almacenar secretos y certificados de nombre de entidad de seguridad de servicio (SPN). Habilite la auditoría de SPN. Periódicamente, revise la asignación de permisos (Azure AD Privileged Identity Management para SPN) o la actividad sospechosa para SPN. Use autoridades de certificados de Microsoft Entra y la autenticación multifactor (cuando se admita) para las cuentas con privilegios. Use roles personalizados de Microsoft Entra para obtener más granularidad.
Implemente artefactos de Microsoft Sentinel, como libros, análisis, reglas, consultas de búsqueda de amenazas, cuadernos y cuadernos de estrategias	Colaborador de Microsoft Sentinel Colaborador de Logic Apps	Permanente	Área de trabajo o grupo de recursos de Microsoft Sentinel	SPN	Use la aprobación y las comprobaciones del flujo de trabajo de Azure DevOps (ADO) para proteger la implementación de canalizaciones con este SPN.
Asigne una directiva para configurar características de streaming de registro a Microsoft Sentinel	Colaborador de directivas de recursos**	A propósito (cada vez que se implementan una suscripción y un conector nuevos)	Todas las suscripciones que se supervisarán	SPN	Cuando se admita, use Microsoft Entra ID, CA y MFA para las cuentas con privilegios.

* Solo se refiere a la configuración de diagnóstico de Microsoft Entra.
** Los conectores específicos necesitan permisos adicionales, como "administrador de seguridad" o "colaborador de la directiva de recursos" para permitir el streaming de datos al área de trabajo de Microsoft Sentinel, Microsoft Entra ID, Microsoft 365 o Microsoft Defender, y recursos de plataforma como servicio (PaaS), como Azure Key Vault.

Modelo de acceso con privilegios

Recomendamos adoptar una estrategia de acceso con privilegios para reducir rápidamente los riesgos para su empresa de ataques de alto impacto y alta probabilidad en el acceso con privilegios. En el caso de los procesos automáticos en un DevOps, base la identidad en identidades de entidad de servicio.

El acceso con privilegios debe ser la prioridad de seguridad principal en todas las empresas. Cualquier riesgo de estas identidades crea efectos muy negativos. Las identidades con privilegios tienen acceso a los recursos críticos para la empresa, lo que casi siempre provoca importantes impactos cuando los atacantes pone en peligro estas cuentas.

La seguridad de acceso privilegiado tiene importancia crítica porque es fundamental para el resto de las garantías de seguridad. Un atacante que controla las cuentas con privilegios puede dañar todas las demás garantías de seguridad.

Por ese motivo, se recomienda distribuir lógicamente las entidades de servicio en niveles o categorías diferentes mediante un principio de privilegio mínimo. En la siguiente ilustración se muestra cómo clasificar las entidades de servicio, en función del tipo de acceso y de dónde se requiera el acceso.

Entidades de servicio de nivel 0

Las entidades de servicio de nivel 0 tienen el nivel más alto de permisos. Estas entidades de servicio permiten a alguien llevar a cabo tareas de administración de grupos de administración raíz o de inquilinos como administrador global.

Por motivos de seguridad y capacidad de administración, se recomienda tener solo una entidad de servicio para este nivel. Los permisos para esta entidad de servicio se conservan, por lo que se recomienda conceder solo los permisos mínimos necesarios y mantener la cuenta supervisada y protegida.

Almacene el secreto o el certificado de esta cuenta de forma segura en Azure Key Vault. Se recomienda encarecidamente que busque el almacén de claves en una suscripción administrativa dedicada si es posible.

Entidades de servicio de nivel 1

Las entidades de servicio de nivel 1 son permisos elevados que están limitados al ámbito de los grupos de administración en el nivel de organización empresarial. Estas entidades de servicio permiten a alguien crear suscripciones en el grupo de administración que está en el ámbito.

Por motivos de seguridad y capacidad de administración, se recomienda tener solo una entidad de servicio para este nivel. Los permisos para esta entidad de servicio se conservan, por lo que se recomienda ampliamente conceder solo los permisos mínimos necesarios y mantener la cuenta supervisada y protegida.

Almacene el secreto o el certificado de esta cuenta de forma segura en Azure Key Vault. Se recomienda encarecidamente que busque el almacén de claves en una suscripción administrativa dedicada si es posible.

Entidades de servicio de nivel 2

Las entidades de servicio de nivel 2 están limitadas al nivel de suscripción. Estas entidades de servicio permiten a alguien llevar a cabo tareas administrativas en una suscripción y actuar como propietario de la suscripción.

Por motivos de seguridad y capacidad de administración, se recomienda tener solo una entidad de servicio para este nivel. Los permisos para esta entidad de servicio se conservan, por lo que recomendamos ampliamente conceder solo los permisos mínimos necesarios y mantener la cuenta supervisada y protegida.

Almacene el secreto o el certificado de esta cuenta de forma segura en Azure Key Vault. Se recomienda ampliamente que busque el almacén de claves en un grupo de recursos administrativo dedicado.

Entidades de servicio de nivel 3

Las entidades de servicio de nivel 3 están limitadas al administrador de cargas de trabajo. En un escenario típico, cada carga de trabajo se encuentra dentro del mismo grupo de recursos. Esta estructura limita los permisos de la entidad de servicio solo a este grupo de recursos.

Por motivos de seguridad y capacidad de administración, se recomienda tener solo una entidad de servicio por carga de trabajo. Los permisos para esta entidad de servicio se conservan, por lo que recomendamos ampliamente conceder solo los permisos mínimos necesarios y mantener la cuenta supervisada y protegida.

Almacene el secreto o el certificado de esta cuenta de forma segura en Azure Key Vault. Se recomienda ampliamente que busque el almacén de claves en un grupo de recursos administrativo dedicado.

Entidades de servicio de nivel 4

Las entidades de servicio de nivel 4 tienen los permisos más limitados. Estas entidades de servicio permiten a alguien llevar a cabo tareas administrativas que están limitadas a un recurso.

Se recomienda usar identidades administradas siempre que sea posible. En el caso de las identidades no administradas, almacene el secreto o el certificado de forma segura en Azure Key Vault donde se almacenan los secretos de nivel 3.

Excelencia operativa

La excelencia operativa abarca los procesos de las operaciones que implementan una aplicación y la mantienen en ejecución en producción. Para más información, consulte Introducción al pilar de excelencia operativa.

Las soluciones de Microsoft Sentinel se componen de tres bloques que garantizan operaciones completas y correctas.

El primer bloque es la definición del entorno, que forma los elementos de arquitectura esenciales. Su principal preocupación con este bloque es tener en cuenta el número de entornos de producción y de no producción que se implementarán y, a continuación, asegurarse de que la configuración sea homogénea en todos los casos.

El segundo bloque es la implementación del conector de Microsoft Sentinel, donde se tiene en cuenta el tipo de conectores que requiere el equipo y los requisitos de seguridad para habilitarlos.

El tercer bloque es la administración del ciclo de vida de los artefactos de Microsoft Sentinel, que abarca la codificación, implementación y uso o destrucción de los componentes. Por ejemplo, este bloque contiene las reglas analíticas, los cuadernos de estrategias, los libros, la búsqueda de amenazas y más.

Tenga en cuenta estas dependencias entre artefactos:

• Reglas de automatización definidas en una regla de análisis
• Libros o análisis que requieren un nuevo origen de datos o conector
• Administración de las actualizaciones de los componentes existentes
  • Cómo hacer versiones de los artefactos
  • Cómo identificar, probar e implementar una regla de análisis actualizada o completamente nueva

Compilar, probar e implementar la infraestructura

En la administración de soluciones de Microsoft Sentinel y DevOps, es importante tener en cuenta los aspectos de conectividad y seguridad de la arquitectura empresarial.

Azure DevOps puede usar agentes hospedados por Microsoft o agentes autohospedados para las actividades de compilación, prueba e implementación. En función de los requisitos de la empresa, puede usar un modelo hospedado en Microsoft, uno autohospedado o una combinación de ambos modelos.

• Agentes hospedados por Microsoft. Esta opción es la manera más rápida de trabajar con agentes de Azure DevOps, ya que es una infraestructura compartida para toda la organización. Para obtener más información sobre el uso de agentes hospedados por Microsoft en la canalización, consulte Agentes hospedados por Microsoft. Los agentes hospedados por Microsoft pueden funcionar en entornos de red híbrida y conceder acceso a los intervalos IP. Para descargar los intervalos IP a los que estos agentes conceden acceso, consulte Intervalos IP de Azure y etiquetas de servicio: nube pública.
• Agentes autohospedados. Esta opción proporciona recursos dedicados y más control al instalar el software dependiente para las compilaciones e implementaciones. Los agentes auto-hospedados pueden funcionar en máquinas virtuales, conjuntos de escalado y contenedores en Azure. Para obtener más información sobre los agentes auto-hospedados, consulte agentes de Azure Pipelines.

Ejecutores GitHub

GitHub puede usar ejecutores hospedados en GitHub o auto-hospedados para actividades relacionadas con la creación, las pruebas y la implementación. En función de las necesidades de la empresa, puede usar un modelo hospedado en GitHub, uno autohospedado o una combinación de ambos modelos.

Ejecutores hospedados en GitHub

Esta opción es la forma más rápida de trabajar con flujos de trabajo de GitHub, ya que es una infraestructura compartida para toda una organización. Para más información, consulte Acerca de ejecutores hospedados en GitHub. Los agente hospedados en GitHub trabajan en entornos de redes híbridas, según determinados requisitos de red. Para más información sobre los requisitos de red, consulte Ejecutores y recursos de hardware admitidos.

Ejecutores autohospedados

Esta opción proporciona a su empresa una infraestructura de recursos dedicada. Los ejecutores auto-hospedados trabajan en máquinas virtuales y contenedores en Azure y admiten el escalado automático.

Consideraciones a la hora de elegir ejecutores

Al elegir opciones para los agentes y ejecutores de la solución de Microsoft Sentinel, tenga en cuenta las siguientes necesidades:

• ¿Su empresa necesita recursos dedicados para ejecutar procesos en los entornos de Microsoft Sentinel?
• ¿Desea aislar los recursos para el entorno de producción de actividades de DevOps del resto de los entornos?
• ¿Necesita probar determinados casos que requieren acceso a recursos o recursos críticos que solo están disponibles en una red interna?

Orquestación y automatización de procesos de versión

Puede configurar el proceso de implementación con Azure DevOps o GitHub. Azure DevOps admite el uso de una canalización YAML o una canalización de versión. Para obtener más información sobre el uso de una canalización de YAML en Azure DevOps, consulte Uso de Azure Pipelines. Para obtener más información sobre el uso de una canalización de versión en Azure DevOps, consulte Canalizaciones de versión. Para más información sobre el uso de GitHub con Acciones de GitHub, consulte Reconocimiento de Acciones de GitHub.

Azure DevOps

Puede llevar a cabo las siguientes actividades de implementación en una implementación de Azure DevOps.

• Use una canalización de YAML para desencadenar automáticamente las aprobaciones de solicitud de incorporación de cambios o ejecutarse a petición.
• Administre las conexiones de servicio para distintos entornos mediante grupos de Azure DevOps.
• En los entornos críticos, configure las aprobaciones de implementación mediante la característica de conexión de servicio y grupos de Azure DevOps para asignar permisos de usuario específicos en su equipo.

GitHub

Puede llevar a cabo las siguientes actividades de implementación en una implementación de GitHub.

• Use GitHub para crear solicitudes de incorporación de cambios o actividades de implementación.
• Administre las credenciales de la entidad de servicio mediante secretos de GitHub.
• Integre la aprobación de implementación a través del flujo de trabajo asociado a GitHub.

Implementación automática con la infraestructura de Microsoft Sentinel

Puede implementar uno o más entornos de Microsoft Sentinel, en función de la arquitectura empresarial:

• Las organizaciones que necesitan varias instancias en su entorno de producción pueden configurar suscripciones diferentes en el mismo inquilino para cada ubicación geográfica.
• Una instancia centralizada en el entorno de producción proporciona acceso a una o más organizaciones en el mismo inquilino.
• Los grupos que necesitan varios entornos como producción, preproducción, integración, entre otros, pueden crearlos y destruirlos según sea necesario.

Definiciones de entorno físico frente a lógico

Tiene dos opciones para configurar las definiciones de entorno, físicas o lógicas. Ambas tienen diferentes opciones y ventajas:

• Definición física: los elementos de la arquitectura de Microsoft Sentinel se definen con las siguientes opciones para Infraestructura como código (IaC):
  • Plantillas de Bicep
  • Plantillas de Azure Resource Manager (plantillas de ARM)
  • Terraform
• Definición lógica: actúa como una capa de abstracción para configurar distintos equipos en el grupo y definir sus entornos. La definición se establece en la canalización de implementación y los flujos de trabajo como entrada para el entorno de compilación mediante el uso del nivel de infraestructura física.

Tenga en cuenta estos puntos al definir los entornos lógicos:

• Convenciones de nomenclatura
• Identificaciones de entorno
• Conectores y configuraciones

Repositorio de código

Dados los enfoques de entorno que se muestran en la sección anterior, tenga en cuenta la siguiente organización de repositorio de código de GitHub.

Definición física: en función de las opciones de IaC, piense en un enfoque que use definiciones de módulo individuales que estén vinculadas en la definición de implementación principal.

En el siguiente ejemplo se muestra cómo se puede organizar el código.

Restrinja el acceso a este repositorio al equipo que define la arquitectura en el nivel físico, lo que garantiza una definición homogénea en la arquitectura empresarial.

Puede adaptar la estrategia de bifurcación y combinación a la estrategia de implementación de cada organización. Si su equipo necesita empezar con la definición, consulte Adopción de una estrategia de bifurcación de Git.

Para más información sobre plantillas de ARM, consulte Uso de plantillas vinculadas y anidadas al implementar recursos de Azure.

Para más información sobre cómo configurar entornos de Bicep, consulte Instalación de herramientas de Bicep. Para obtener más información sobre GitHub, consulte Flujo de GitHub.

Las definiciones lógicas definen los entornos de una empresa. El repositorio de Git recopila las distintas definiciones de una empresa.

En el siguiente ejemplo se muestra cómo se puede organizar el código.

El repositorio refleja las acciones de solicitud de incorporación de cambios que llevan a cabo distintos equipos. Distintos equipos definen varios entornos y los aprueban los propietarios o aprobadores de la empresa.

El nivel de privilegios para ejecutar una implementación de entorno es el nivel 2. Este nivel garantiza que el grupo de recursos y los recursos se crean para el entorno con la seguridad y privacidad necesarias. Este nivel también establece los permisos de usuario en las acciones permitidas en los entornos de producción, producción y preproducción.

Las organizaciones que desean entornos a petición para pruebas y desarrollo y la capacidad de destruir los entornos después de finalizar las pruebas, pueden implementar una canalización de Azure DevOps o acciones de GitHub. Pueden establecer desencadenadores programados para destruir los entornos según sea necesario mediante eventos de Azure DevOps o acciones de GitHub.

Configuración automática de conectores de Microsoft Sentinel

Los conectores de Microsoft Sentinel son una parte esencial de la solución que admite la conexión con diferentes elementos del panorama de la arquitectura empresarial, como Microsoft Entra ID, Microsoft 365, Microsoft Defender o las soluciones de plataforma de inteligencia sobre amenazas, entre otros.

Al definir un entorno, puede usar la configuración de los conectores para configurar entornos con configuraciones homogéneas.

El modelo de nivel de entidad de servicio tiene que admitir la habilitación de conectores como parte del modelo DevOps. Este enfoque garantiza el nivel correcto de permisos, como se muestra en la siguiente tabla.

Escenario del conector	Nivel del modelo de acceso con privilegios mínimos.	Privilegios mínimos de Azure	Requiere aprobación del flujo de trabajo
Microsoft Entra ID	Nivel 0	administrador global o administrador de seguridad	Recomendado
Protección de Microsoft Entra ID	Nivel 0	administrador global o administrador de seguridad	Recomendado
Microsoft Defender for Identity	Nivel 0	administrador global o administrador de seguridad	Recomendado
Microsoft Office 365	Nivel 0	administrador global o administrador de seguridad	Recomendado
Microsoft Cloud App Security	Nivel 0	administrador global o administrador de seguridad	Recomendado
Microsoft Defender XDR	Nivel 0	administrador global o administrador de seguridad	Recomendado
Microsoft Defender for IoT	Nivel 2	Colaborador	Recomendado
Microsoft Defender for Cloud	Nivel 2	Lector de seguridad	Opcionales
Actividad de Azure	Nivel 2	Lector de la suscripción	Opcionales
Plataformas de inteligencia sobre amenazas	Nivel 0	administrador global o administrador de seguridad	Recomendado
Eventos de seguridad	Nivel 4	Ninguno	Opcionales
syslog	Nivel 4	Ninguno	Opcionales
DNS (versión preliminar)	Nivel 4	Ninguno	Opcionales
Firewall de Windows	Nivel 4	Ninguno	Opcionales
Eventos de seguridad de Windows a través de AMA	Nivel 4	Ninguno	Opcionales

Implementación de artefactos de Microsoft Sentinel

En la implementación de artefactos de Microsoft Sentinel, DevOps adquiere más importancia, ya que cada empresa crea varios artefactos para evitar y corregir los ataques.

La implementación de los artefactos puede ser responsabilidad de uno o varios equipos. La compilación automática y la implementación de artefactos suele ser el requisito de proceso más común y determina el enfoque y las condiciones de los agentes y ejecutores.

La implementación y administración de artefactos de Microsoft Sentinel requiere el uso de la API de REST de Microsoft Sentinel. Para más información, consulte API de REST de Microsoft Sentinel. En el siguiente diagrama se muestra una canalización de Azure DevOps en una pila de API de REST de Azure.

También puede implementar el repositorio mediante PowerShell.

Si el equipo usa MITRE, considere la posibilidad de clasificar los distintos artefactos y especificar las tácticas y técnicas de cada uno. Asegúrese de incluir un archivo de metadatos correspondiente para cada tipo de artefacto.

Por ejemplo, si va a crear un cuaderno de estrategias mediante una plantilla de Azure ARM y el nombre de archivo es Playbook.arm.json, agregue un archivo JSON denominado Playbook.arm.mitre.json. A continuación, los metadatos de este archivo incluyen los formatos CSV, JSON o YAML que corresponden a las tácticas o técnicas de MITRE que se usan.

Al seguir esta práctica, el equipo puede evaluar la cobertura de MITRE en función de los trabajos que se llevan a cabo durante la instalación para los diferentes tipos de artefactos que se usan.

Artefactos de compilación

El objetivo del proceso de compilación es asegurarse de que genera artefactos de la máxima calidad. En el siguiente diagrama se muestran algunas de las acciones del proceso de compilación que puede llevar a cabo.

Descargue un archivo Visio de esta arquitectura.

• Puede basar la definición del artefacto en un esquema descriptivo en formato JSON o YAML y, a continuación, validar el esquema para evitar errores de sintaxis.
  • Valide sus plantillas de ARM mediante el Kit de herramientas de prueba de plantillas de ARM.
  • Valide los archivos YAML y JSON para modelos personalizados mediante PowerShell.
• Valide la configuración de la lista de reproducción y asegúrese de que los registros de enrutamiento entre dominios (CIDR) sin clases que defina sigan el esquema correcto, por ejemplo, 10.1.0.0/16.
• Use consultas del lenguaje de consulta de palabras clave (KQL), que puede validar en el nivel de la sintaxis, para reglas de análisis, reglas de búsqueda y reglas de streaming en vivo.
• Haga que la validación local de KQL sea una opción.
• Integre la herramienta de validación insertada de KQL en la canalización de DevOps.
• Si va a implementar lógica basada en PowerShell para Azure Automation, puede incluir la validación de sintaxis y las pruebas unitarias mediante los siguientes elementos:
  • Pester
  • PSScriptAnalyzer
• Genere el informe de metadatos del manifiesto MITRE en función de los archivos de metadatos que se incluyen con los artefactos.

Exportación de artefactos

Normalmente, varios equipos trabajan en varias instancias de Microsoft Sentinel para generar los artefactos necesarios y validarlos. Con el objetivo de volver a usar los artefactos existentes, su empresa puede configurar procesos automáticos para obtener las definiciones de artefactos de los entornos existentes. Automation también puede proporcionar información sobre los artefactos creados por distintos equipos de desarrollo durante la instalación.

En el siguiente diagrama se muestra un proceso de extracción de artefactos de ejemplo.

Descargue un archivo Visio de esta arquitectura.

Implementación de artefactos

Los objetivos del proceso de implementación son:

• Reducir el tiempo de comercialización.
• Aumentar el rendimiento en los distintos equipos implicados en la configuración y administración de la solución.
• Configurar las pruebas de integración para evaluar el estado del entorno.

Los equipos de desarrollo usan el proceso para asegurarse de que pueden implementar, probar y validar los casos de uso de artefactos que están en desarrollo. La arquitectura y los equipos de SOC validan la calidad de la canalización en entornos de control de calidad y trabajan con las pruebas de integración para escenarios de ataque. En los casos de prueba, un equipo suele combinar diferentes artefactos como reglas de análisis, cuadernos de procedimientos de corrección, listas de reproducción, entre otros. Una parte de cada caso de uso incluye la simulación de ataques en los que toda la cadena se evalúa a partir de la ingesta, la detección y la corrección.

En el diagrama siguiente se muestra la secuencia del proceso de implementación que garantiza que los artefactos se implementan en el orden correcto.

Descargue un archivo Visio de esta arquitectura.

La administración de artefactos de Sentinel como código ofrece maneras flexibles de mantener las operaciones y automatizar la implementación en una canalización CI/CD de DevOps.

Las soluciones de Microsoft ofrecen flujos de trabajo de automatización para los siguientes artefactos.

Artefacto	Flujos de trabajo de automatización
Listas de reproducción	Revisión de código Validación de esquema Implementación Creación, actualización y eliminación de listas de seguimiento y elementos
Fusión de reglas de análisis Seguridad de Microsoft Análisis del comportamiento de ML Anomalía Programado	Revisión de código Validación de la sintaxis de KQL Validación de esquema Pester Implementación Crear, habilitar, actualizar, eliminar, exportar Compatibilidad con plantillas de alerta
Regalas de automatización	Revisión de código Validación de esquema Implementación Crear, habilitar, actualizar, eliminar, exportar
Conectores	Revisión de código Validación de esquema Implementación Acciones: habilitar, eliminar (deshabilitar), actualizar
Reglas de búsqueda	Revisión de código Validación de la sintaxis de KQL Validación de esquema Pester Implementación Acciones: crear, habilitar, actualizar, eliminar, exportar
Playbooks	Revisión de código TTK Implementación Acciones: crear, habilitar, actualizar, eliminar, exportar
Workbooks	Implementación Acciones: crear, actualizar, eliminar
Runbooks	Revisión de código Validación de la sintaxis de PowerShell Pester Implementación Acciones: crear, habilitar, actualizar, eliminar, exportar

En función del lenguaje de automatización que elija, es posible que algunas funcionalidades de automatización no sean compatibles. En el siguiente diagrama se muestran qué funcionalidades de automatización son compatibles con el lenguaje.

* Características en desarrollo que aún no están documentadas
** Métodos de automatización admitidos por Microsoft Operational Insights o las API de proveedor de recursos de Microsoft Insights

Azure Automation

En el diagrama siguiente se muestran los componentes de la simplificación del acceso de Microsoft Sentinel con la identidad de servicio administrado.

Descargue un archivo Visio de esta arquitectura.

Si necesita conceder acceso a otros recursos, use la identidad administrada, que garantiza una identidad única para todas las operaciones críticas.

Use Azure Automation para configurar cuadernos de estrategias. Use scripts de PowerShell para las siguientes tareas complejas y características de automatización:

• Integración con soluciones de terceros, donde se requieren distintos niveles de credenciales y se basan en credenciales personalizadas o de Microsoft Entra ID:
  • Credenciales de usuario de Microsoft Entra
  • Credenciales de entidad de servicio de Microsoft Entra
  • Autenticación de certificado
  • Credenciales personalizadas
  • Identidad administrada
• Implementación de una solución que reutiliza scripts organizativos o soluciones que requieren el uso de comandos de PowerShell para evitar la traducción compleja a cuadernos de estrategias:
  • Soluciones basadas en PowerShell
  • Soluciones basadas en Python
• Implementación de soluciones en escenarios híbridos, donde las acciones de corrección pueden afectar a los recursos locales y en la nube.

Repositorios de Microsoft Sentinel

Los equipos de DevOps experimentados podrían considerar la posibilidad de administrar Microsoft Sentinel en Infraestructura como código (IaC) con canalizaciones de CI/CD integradas en Azure DevOps. Los grupos de productos comprenden los desafíos a los que se enfrentan los clientes y asociados al crear arquitectura de seguridad de Azure DevOps, por lo que las dos iniciativas siguientes pueden ayudar:

• Documentación de la arquitectura de referencia
• Desarrollo de una nueva solución, anunciada en Ignite 2021, que se denomina "Repositorios de Microsoft Sentinel"

Para admitir la elección de la solución que se adapte a las necesidades de su equipo, en la tabla siguiente se comparan los criterios funcionales y técnicos.

Caso de uso y características	Enfoque personalizado de Azure DevOps y GitHub	Repositorios de Microsoft Sentinel
Queremos empezar a implementar rápidamente artefactos de Microsoft Sentinel sin dedicar tiempo a definir componentes de arquitectura de Azure DevOps, como agentes, canalizaciones, Git, paneles, una wiki, entidades de servicio, RBAC, auditorías, entre otros.	No recomendado	Recomendado
Tenemos equipos pequeños y conjuntos de aptitudes bajos para administrar las canalizaciones de CI/CD.	No recomendado	Recomendado
Queremos controlar y administrar todos los aspectos de seguridad de las canalizaciones de CI/CD.	Compatible	No compatible
Es necesario integrar puertas y ramas para supervisar la integración, antes de permitir que los desarrolladores desencadenen canalizaciones de implementación, como el control de código fuente, la revisión de codificación, la reversión, la aprobación del flujo de trabajo, entre otros.	Compatible	Compatibilidad parcial
Tenemos una estructura personalizada de Git o repositorio.	Compatible	Compatible
No usamos los lenguajes Resource Manager o Bicep IaC para compilar artefactos.	Compatible	No compatible
Queremos administrar de forma centralizada la implementación de artefactos en varias áreas de trabajo de Microsoft Sentinel en un único inquilino de Microsoft Entra.	Compatible	Compatible.
Queremos integrar o ampliar canalizaciones de CI/CD entre varios inquilinos de Microsoft Entra.	Compatible	Compatible
Tenemos cuadernos de estrategias con parametrizaciones diferentes en función de la suscripción, la ubicación, el entorno, etc.	Compatible	Por determinar, directrices que se tienen que documentar
Queremos integrar diferentes artefactos en el mismo repositorio para crear casos de uso.	Compatible	Compatible
Queremos la capacidad de quitar artefactos de forma masiva.	Compatible	No compatible

Disponibilidad, rendimiento y escalabilidad

Al elegir la arquitectura para los agentes de Azure DevOps en su empresa para escenarios de Microsoft Sentinel, tenga en cuenta las siguientes necesidades:

• El entorno de producción puede requerir un grupo de agentes dedicado para las operaciones en el entorno de Microsoft Sentinel.
• Los entornos que no son de producción pueden compartir el grupo de agentes con un gran número de instancias para controlar las distintas demandas de los equipos, en particular, para las prácticas de CI/CD.
  • Los escenarios de simulación de ataques son un caso especial en el que se pueden necesitar agentes dedicados. Considere si es necesario un grupo dedicado para sus necesidades de prueba.
• Las organizaciones que trabajan en escenarios de redes híbridas pueden considerar la posibilidad de integrar a los agentes dentro de la red.

Las organizaciones pueden crear sus propias imágenes para agentes basadas en contenedores. Para obtener más información, consulte Ejecutar un agente autohospedado en Docker.

Administración entre inquilinos de Microsoft Sentinel con Azure DevOps

Como SOC global o MSSP, es posible que tenga que administrar varios inquilinos. Azure Lighthouse admite operaciones de escalado entre varios inquilinos de Microsoft Entra al mismo tiempo, lo que hace que las tareas de administración sean más eficaces. Para más información, consulte Información general sobre Azure Lighthouse.

La administración entre inquilinos es especialmente eficaz en los siguientes escenarios:

• Administración de recursos de Microsoft Sentinel en inquilinos del cliente.
• Seguimiento de ataques y visualización de alertas de seguridad en varios inquilinos.
• Visualización de incidentes en varias áreas de trabajo de Microsoft Sentinel distribuidas entre inquilinos.

Métodos de incorporación de clientes

Tiene dos opciones para incorporar clientes, una oferta de servicio administrado y una plantilla de ARM.

Incorporación manual mediante una plantilla de ARM

Si no quiere publicar una oferta en Azure Marketplace como proveedor de servicios o no cumple todos los requisitos, puede incorporar clientes manualmente mediante plantillas de ARM. Esta es la opción más probable en un escenario empresarial, donde la misma empresa tiene varios inquilinos.

En la tabla siguiente se comparan los métodos de incorporación.

Consideración	Oferta de servicio administrado	Plantillas de ARM
Se necesita una cuenta del Centro de partners	Sí	No
Requiere el nivel de competencia de la plataforma en la nube Silver o Gold o un estado de Proveedor de servicios administrados experto de Azure (MSP)	Sí	No
Disponible para nuevos clientes mediante Azure Marketplace	Sí	No
Se puede limitar la oferta a clientes específicos	Sí (solo con ofertas privadas, que no son compatibles con las suscripciones que se establecen a través de un revendedor del programa CSP)	Sí
Se requiere la aceptación del cliente en Azure Portal	Sí	No
Se puede usar automatización para incorporar varias suscripciones, grupos de recursos o clientes	No	Sí
Acceso inmediato a nuevos roles integrados y características de Azure Lighthouse	No siempre (disponible generalmente después de un pequeño retraso)	Sí

Para más información sobre la publicación de ofertas de servicios administrados, consulte Publicación de una oferta de servicio administrado para Azure Marketplace.

Para más información sobre cómo crear una plantilla de ARM, consulte Creación e implementación de plantillas de ARM.

En el siguiente diagrama se muestra la integración de arquitectura de alto nivel entre un inquilino de MSSP y los inquilinos del proveedor de recursos de un cliente con Azure Lighthouse y Microsoft Sentinel.

Descargue un archivo Visio de esta arquitectura.

1. Una oferta de MSP se integra a través de una plantilla de ARM o una oferta de servicio de Azure Marketplace.
2. La administración de recursos delegados de Azure comprueba que la solicitud es de un inquilino de asociado y llama a un proveedor de recursos de servicio administrado.
3. El proveedor de recursos de servicio administrado usa RBAC para controlar el acceso del MSP.
4. El MSP completa las acciones de SecOps en un recurso de cliente.
5. El proceso de facturación trata los gastos como cargos del cliente. La facturación dividida es posible si las entidades de cliente tienen áreas de trabajo independientes en el mismo inquilino de Microsoft Entra.
6. La seguridad y soberanía de los datos depende del límite del inquilino del cliente.

Identidad entre distintos inquilinos

Para administrar Microsoft Sentinel con Azure DevOps, evalúe las siguientes decisiones de diseño para los componentes.

Caso de uso	Ventajas
Identidad global para administrar acciones DevOps, entidad de servicio única	Este caso se aplica a los procesos de implementación globales, que implican a todos los inquilinos. El uso de identidad unificada facilita el acceso a los distintos inquilinos, pero podría hacer que el proceso de administración de acciones de aprobación para inquilinos específicos sea complejo. El mecanismo de protección y el modelo de autorización para este tipo de identidad también son muy importantes, con el fin de evitar el uso no autorizado debido al impacto global relacionado.
Identidad dedicada para administrar acciones de DevOps, varias entidades de servicio	Este caso se aplica cuando los procesos de implementación se dedican a cada inquilino o si las acciones del inquilino requieren aprobación. En este caso, la recomendación para proteger y autorizar este uso de identidad es la misma que en el caso global, incluso cuando se reduce el impacto.

Organización del repositorio de códigos

Caso de uso	Ventajas
Repositorio unificado con una sola versión del código para todos los inquilinos	Este caso facilita tener versiones unificadas del código en el repositorio. En este caso, una versión unificada del código que administra una versión específica para los inquilinos podría requerir que se admita en ramas para cada caso.
Repositorio unificado con carpetas de código específicas por inquilino	Este caso complementa el caso de un solo repositorio. Aquí, una estructura de carpetas puede dividir artefactos dedicados por inquilino.
Repositorio dedicado por inquilino	Este enfoque proporciona aislamiento al administrar artefactos de código. Facilita la evolución entre inquilinos con distintos equipos o requisitos. La consolidación de los cambios requiere establecer un proceso entre repositorios, lo que puede requerir esfuerzo de mantenimiento.

Procesos de compilación e implementación

Caso de uso	Ventajas
Proceso de compilación único para todos los inquilinos	Cuando todos los inquilinos funcionan con la misma versión de los artefactos, esta es la opción más sencilla para implementar la generación y el paquete.
Proceso de compilación por inquilino	Se implementa una versión diferente del código en cada inquilino.
Proceso de implementación global para todos los inquilinos	Las nuevas implementaciones y actualizaciones de las implementaciones se aplican a todos los inquilinos. Los pasos de los procesos de implementación y actualización se usan para todos los inquilinos.
Proceso de implementación global inquilino por inquilino	Las nuevas implementaciones y actualizaciones de las implementaciones se aplican a uno o más inquilinos.
Proceso de implementación dedicado por inquilino	El proceso de implementación se adapta para cada inquilino.

Optimización de costos

La optimización de costos trata de reducir los gastos innecesarios y mejorar las eficiencias operativas. Para más información, vea Información general del pilar de optimización de costos.

El costo de la solución depende de los siguientes factores:

• El volumen de datos que la empresa alimenta mensualmente en el área de trabajo de Log Analytics de Microsoft Sentinel
• El nivel de compromiso o el método de facturación que elija, como pago por uso (PAYG).
• La tasa de retención de las directivas de datos en una tabla o nivel global

Para más información, consulte Retención por tipo de datos de Azure.

Para calcular los precios, consulte la calculadora de precios de Microsoft Sentinel. Para obtener más información sobre las consideraciones y ejemplos de precios avanzados, consulte Planeación de los costos de Microsoft Sentinel.

Puede incurrir en costos adicionales si extiende la solución con los siguientes componentes:

• Cuadernos de juegos: runtimes para Azure Logic Apps y Azure Functions. Para más información, consulte la información de precios.
• Exportación a almacenamiento externo como Azure Data Explorer, Event Hubs o una cuenta Azure Storage.
• Un área de trabajo de aprendizaje automático y el proceso que usa un componente de Jupyter Notebook.

Implementación de este escenario

En la siguiente sección se describen los pasos para implementar este escenario en forma de un caso de uso de ejemplo que abarca los distintos procesos de DevOps.

Compilación y publicación del marco de Microsoft Sentinel

En primer lugar, configure los componentes NuGet necesarios en un repositorio dedicado donde distintos procesos puedan consumir las versiones que genere.

Si está trabajando con Azure DevOps, puede crear una fuente de componentes para hospedar los distintos paquetes de NuGet desde el marco de Microsoft Sentinel para PowerShell. Para obtener información, consulte Introducción a paquetes de NuGet.

Si el equipo elige un registro de GitHub, puede conectarlo como un repositorio de NuGet, ya que es compatible con el protocolo de fuente. Para más información, consulte Introducción a paquetes de GitHub.

Cuando tiene un repositorio disponible de NuGet, la canalización contiene una conexión de servicio para NuGet. Estas capturas de pantalla muestran la configuración de la nueva conexión de servicio denominada Microsoft Sentinel NuGet Framework Connection.

Después de configurar la fuente, puede importar la canalización para compilar el marco de PowerShell directamente desde GitHub en una bifurcación específica. Para más información, consulte Compilar repositorios de GitHub. En este caso, creará una nueva canalización y elegirá GitHub como el código fuente.

Otra opción es importar el repositorio de Git como un repositorio de Azure DevOps basado en Git. En ambos casos, para importar la canalización, especifique la ruta de acceso siguiente:

src/Build/Framework/ADO/Microsoft.Sentinel.Framework.Build.yml

Ahora puede ejecutar la canalización por primera vez. A continuación, el marco se compila y se libera en la fuente de NuGet.

Definir el entorno de Microsoft Sentinel

Al empezar con Microsoft Sentinel y usar estos ejemplos, defina el entorno de su empresa, por ejemplo, Entorno como código o EaC. En cada caso, especifique los distintos elementos que crean el entorno.

La arquitectura de Microsoft Sentinel incluye los siguientes elementos en Azure:

• Área de trabajo de Log Analytics: esta área de trabajo constituye la base de la solución. La información relacionada con la seguridad se almacena aquí y el área de trabajo es el motor del lenguaje de consulta Kusto (KQL).
• Solución de Microsoft Sentinel sobre el área de trabajo de Log Analytics: esta solución amplía la funcionalidad del área de trabajo de Log Analytics para incluir las funcionalidades SIEM y SOAR.
• Key Vault: el almacén de claves conserva los secretos y las claves que se usan durante los procesos de corrección.
• Cuenta de Automation: esta cuenta es opcional y se usa para los procesos de corrección. El proceso de corrección que se usa se basa en los runbooks de PowerShell y Python. El proceso incluye una identidad administrada por el sistema que funciona con recursos diferentes según los procedimientos recomendados.
• Identidad administrada por el usuario: esta característica actúa como una capa de identidad unificada de Microsoft Sentinel que administra las interacciones entre cuadernos de estrategias y runbooks de Microsoft Sentinel.
• Conexiones de aplicación lógica: son conexiones para Microsoft Sentinel, el almacén de claves y la automatización que usan la identidad administrada por el usuario.
• Conexiones de aplicación lógica externa: son conexiones para recursos externos que participan en los procesos de corrección y que se basan en los cuadernos de estrategias.
• Azure Event Hubs: esta característica es opcional y controla la integración entre Microsoft Sentinel y otras soluciones, como Splunk, Azure Databricks y aprendizaje automático, y Resilient.
• Cuenta de almacenamiento: esta característica es opcional y controla la integración entre Microsoft Sentinel y otras soluciones, como Splunk, Azure Databricks y aprendizaje automático, y Resilient.

Mediante el uso de ejemplos del repositorio, puede definir el entorno con archivos JSON para especificar los distintos conceptos lógicos. Las opciones disponibles para definir el entorno pueden ser literales o automáticas.

En una definición literal, especifique el nombre y los elementos de cada recurso del entorno, como se muestra en este ejemplo.

{
    {
        "SubscriptionId": "<subscription-identifier-associated-with-service-connection>",
        "Name": "<environment-name>",
        "NamingConvention": "<naming-convention-template-for-automatic-cases>",
        "Location": "<environment-location>",
        "ResourceGroup": {
            "Type": "Literal",
            "ResourceGroupName": "<resource-group-name>"
         }
    },
    "Resources":
    {
        "Sentinel":
        {
            "Type": "Literal",
            "LogAnalyticsWorkspaceName": "<Log-Analytics-workspace-name>",
            "ManagedIdentityName": "<user-managed-identity-name>",
            "SentinelConnectionName": "<Sentinel-API-connection-name>",
            "KeyVaultName": "<Key-Vault-name>",
            "KeyVaultConnectionName": "<Key-Vault-API-connection-name>"
        },
        "Automation":
        {
            "Type": "Literal",
            "AutomationAccountName": "<automation-account-name>",
            "AutomationAccountConnectionName": "<automation-account-API-connection-name>"
        },
        "Integration":
        {
            "Type": "Literal",
            "EventHubNamespaces": [
                "<Event-Hubs-namespace-1-name>",
                "<Event-Hubs-namespace-2-name>",
                "<Event-Hubs-namespace-3-name>",
                "<Event-Hubs-namespace-4-name>",
                "<Event-Hubs-namespace-5-name>",
                "<Event-Hubs-namespace-6-name>",
                "<Event-Hubs-namespace-7-name>",
                "<Event-Hubs-namespace-8-name>",
                "<Event-Hubs-namespace-9-name>",
                "<Event-Hubs-namespace-10-name>",
            ],
            "StorageAccountName": "<storage-account-name>"
        }
    }
}

En una definición automática, los nombres de elemento se generan automáticamente en función de las convenciones de nomenclatura, como se muestra en este ejemplo.

{
    {
        "SubscriptionId": "<subscription-identifier-associated-with-service-connection>",
        "Name": "<environment-name>",
        "NamingConvention": "<naming-convention-template-for-automatic-cases>",
        "Location": "<environment-location>",
        "ResourceGroup": {
            "Type": "Automatic"
        }
    },
    "Resources":
    {
        "Sentinel":
        {
            "Type": "Automatic"
        },
        "Automation":
        {
            "Type": "Automatic"
        },
        "Integration":
        {
            "Type": "Automatic",
            "MaxEventHubNamespaces": 5
        }
    }
}

Puede encontrar ejemplos en el repositorio GitHub en la ruta de acceso a entornos de Microsoft Sentinel y usar los ejemplos como referencia para preparar los casos de uso.

Definir el entorno de Microsoft Sentinel

Cuando tenga al menos un entorno definido, puede crear la conexión de servicio de Azure para integrarse con Azure DevOps. Después de crear la conexión de servicio, establezca la entidad de servicio vinculada en el rol propietario o en un nivel de permisos similar en la suscripción de destino.

1. Importe la canalización para crear el nuevo entorno tal como se define en este archivo.

   src/Release/Sentinel Deployment/ADO/Microsoft.Sentinel.Environment.Deployment.yml

2. A continuación, escriba el nombre de la conexión de servicio que representa el entorno.

   

3. Elija la rama de la definición del entorno en el repositorio. 

4. Escriba el nombre de la conexión de servicio de Azure DevOps de la suscripción en el cuadro Conexión de entorno de Azure.

5. Escriba el nombre del entorno que puede usar una conexión de servicio para resolver varios entornos en la misma suscripción.

6. Elija la acción que se aplicará a los conectores.

7. Seleccione Usar versión preliminar de Artifacts de PowerShell si desea usar las versiones preliminares de los componentes del marco de PowerShell.

La canalización incluye los pasos siguientes como parte del flujo de implementación:

• Implemente componentes NuGet.
• Conecte mediante herramientas de NuGet con el repositorio de artefactos.
• Resuelva la fuente.
• Instale los módulos necesarios
• Defina el entorno.
• Valide qué recursos existen en el destino.
• Agregue Log Analytics y Microsoft Sentinel si no están en el área de trabajo.
• Si ya tiene Log Analytics, agregue Microsoft Sentinel a través de la instancia de Log Analytics.
• Cree una identidad administrada para representar la interacción entre Microsoft Sentinel y Logic Apps.
• Cree Azure Key Vault y establezca la asignación de roles para administrar secretos y claves en la identidad administrada.
• Si procede, cree una cuenta de Azure Automation y active la identidad administrada asignada por el sistema.
• Establezca la asignación de roles en el almacén de claves para la identidad administrada asignada por el sistema.
• Cree las definiciones de Event Hubs si no existen y establezca si la definición incluye los elementos de integración.
• Establezca la asignación de roles en el almacén de claves para la identidad administrada asignada por el sistema.
• Cree las definiciones de la cuenta de almacenamiento si no existen y establezca si la definición incluye los elementos de integración.
• Establezca la asignación de roles en el almacén de claves para la identidad administrada asignada por el sistema.
• Implementar acciones del conector
• Implemente el runbook de integración en la cuenta de Automation.
• Implemente conexiones de Logic Apps si se definen como parte del entorno.

Destruir un entorno de Microsoft Sentinel

Cuando el entorno ya no es necesario, como en el caso de un entorno de desarrollo o pruebas, puede destruirlo tal como se define en este archivo.

src/Release/Sentinel Deployment/ADO/Microsoft.Sentinel.Environment.Destroy.yml

Al igual que al implementar la canalización del entorno, especifique el nombre de la conexión de servicio que representa el entorno.

Trabajar con el entorno de Microsoft Sentinel

Una vez que el entorno esté listo, puede empezar a crear los artefactos para configurar los distintos casos de uso.

1. Exporte los artefactos del entorno en el que está trabajando tal y como se define en este archivo.

   src/Release/Artifacts Deployment/ADO/Microsoft.Sentinel.Artifacts.Export.yml

2. Elija la rama de la definición del entorno en el repositorio.

   

3. Escriba el nombre de la conexión de servicio de Azure DevOps del entorno que se va a exportar en el cuadro Conexión de entorno de Azure.

4. Seleccione Usar versión preliminar de Artifacts de PowerShell si desea usar las versiones preliminares de los componentes del marco de PowerShell.

5. Elija el formato de las reglas de búsqueda y análisis.

   El archivo de salida de artefactos está disponible en los resultados. Una vez que tenga los artefactos, puede incluir el archivo de salida en el repositorio de Git.

Compilación de artefactos en el entorno de Microsoft Sentinel

Coloque los artefactos en la ruta de acceso de los casos de uso de MITRE de Microsoft Sentinel. Configure la estructura de carpetas según los distintos tipos de artefactos.

1. Inicie el proceso de compilación tal como se define en este archivo.

   src/Build/Artifacts/ADO/Microsoft.Sentinel.Artifacts.Build.yaml

2. Elija la rama de la definición del entorno en el repositorio.

   Diagrama de cómo elegir la rama para compilar los artefactos.] (./media/build-artifacts-pipeline.png)

3. Seleccione Usar versión preliminar de Artifacts de PowerShell si desea usar las versiones preliminares de los componentes del marco de PowerShell.

La canalización consiste en estos pasos:

• Implemente componentes de NuGet.
• Conecte las herramientas NuGet en el repositorio de artefactos.
• Resuelva la fuente.
• Instale los módulos necesarios
• Obtega el marco del kit de herramientas de pruebas para validar las plantillas de ARM.
• Valide las plantillas de ARM.
• Valide el código de runbooks de PowerShell y hacer la validación de la sintaxis.
• Ejecute las pruebas unitarias de Pester si procede.
• Valide la sintaxis de KQL en las reglas de búsqueda y análisis.

Implemente los artefactos en el entorno de Microsoft Sentinel

Al implementar los artefactos, puede usar los repositorios de Microsoft Sentinel o los ejemplos de canalización de implementación en este repositorio. Para más información, consulte Implementación de contenido personalizado desde el repositorio.

Repositorios de Microsoft Sentinel

Si usa repositorios de Microsoft Sentinel, puede configurar un proceso de versión para incluir los artefactos en el repositorio que está conectado a cada instancia de Microsoft Sentinel. Una vez confirmados los artefactos en el repositorio, algunos de los pasos se ejecutan automáticamente como parte de la creación de la canalización y la habilitación de los repositorios de Microsoft Sentinel.

Además, puede personalizar los procesos de implementación que los repositorios de Microsoft Sentinel hacen en función de las prácticas que se describen en este documento. Un aspecto importante a tener en cuenta es la aprobación de la versión, que puede configurar con estos enfoques:

• Aprobación de PR al confirmar los artefactos. Para más información, consulte Creación de solicitudes de incorporación de cambios.
• Liberación de la aprobación de la canalización al ejecutar la implementación. Para más información, consulte Definición de aprobaciones y comprobaciones.

Ejemplos de canalización de implementación de Microsoft Sentinel

Mediante el uso de los ejemplos de canalización de implementación de Microsoft Sentinel, puede configurar un proceso de versión.

1. Configure el proceso de versión tal como se define en este archivo.

   src/Release/Artifacts Deployment/ADO/Microsoft.Sentinel.Artifacts.Deployment.yml

2. Elija la rama de la definición del entorno en el repositorio.

   

3. Escriba el nombre de la conexión de servicio de Azure DevOps del entorno que se va a exportar en el cuadro Conexión de entorno de Azure.

4. Seleccione Usar versión preliminar de Artifacts de PowerShell si desea usar las versiones preliminares de los componentes del marco de PowerShell.

Colaboradores

Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.

Autor principal:

• Kevin Kisoka | Arquitecto asociado

Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.

Pasos siguientes

• Para obtener información sobre Microsoft Sentinel con arquitectura de DevOps de un solo inquilino, consulte Implementación y administración de Microsoft Sentinel como código.
• Para obtener información sobre la arquitectura multiinquilino de MSSP, consulte Combinación de Azure Lighthouse con las funcionalidades de DevOps de Microsoft Sentinel.
• Para obtener información sobre la identidad administrada con Microsoft Sentinel, consulte Novedades: Identidad administrada para conector de Microsoft Sentinel Logic Apps.
• Para obtener información sobre cómo implementar contenido desde un repositorio de Microsoft Sentinel, consulte Implementación de contenido personalizado desde el repositorio.
• Para más información sobre las consideraciones de seguridad de Azure DevOps, consulte Referencia rápida de permisos predeterminados para Azure DevOps.
• Para obtener información sobre cómo proteger un repositorio de Azure DevOps, consulte Agregar protección a un recurso de repositorio.
• Para obtener información sobre cómo administrar la seguridad de conexión de servicio de Azure DevOps, consulte Conexiones de servicio en Azure Pipelines.

Recursos relacionados

• Supervisión de la seguridad híbrida mediante Microsoft Defender for Cloud y Microsoft Sentinel
• Diseño de una canalización de CI/CD con Azure DevOps
• Funcionalidad avanzada de plantilla de ARM