Arquitectura de referencia Seguridad

La definición de esta arquitectura persigue garantizar la seguridad en el proceso completo del desarrollo de Software. Se enfoca en la gestión de identidades, control de acceso, monitorización y detección de amenazas, cifrado y la configuración de los propios servicios, aplicaciones, sistemas o plataformas.

Este artículo está dirigido a los equipos de desarrollo de la Junta de Andalucía, Dirección de Proyectos tecnológicos, y las distintas Subdirecciones de la Agencia Digital de Andalucía.

Objetivos, características y beneficios

A medida que el panorama de amenazas actual crece en complejidad, tener una arquitectura de seguridad bien diseñada es algo fundamental para una organización. No solo es una salvaguardia contra los ciberataques modernos, sino un facilitador clave de la transformación digital, la innovación, la confianza de los ciudadanos y el crecimiento empresarial.

La seguridad en la arquitectura desempeña un papel crítico en la protección de sistemas, datos y usuarios en todas las arquitecturas de referencia de la Junta de Andalucía. Su principal objetivo es garantizar los tres grandes pilares fundamentales en los que se basa la seguridad de la información: Confidencialidad, integridad y disponibilidad.

Los principales objetivos que se deben satisfacer a nivel de seguridad en una arquitectura son:

• Asegurar la identificación, autenticación y autorización precisa de usuarios, servicios y sistemas.
• Proteger la integridad y la confidencialidad de los datos.
• Garantizar la disponibilidad de los datos y sistemas.
• Prevenir la entrada de datos no autorizada y la propagación de amenazas.
• Adaptarse y evolucionar continuamente para hacer frente a las amenazas en constante cambio.
• Cumplir las normas de seguridad para garantizar la privacidad de la información y alinearnos con la normativa vigente sobre seguridad.

Para cumplir con los objetivos listados anteriormente y mejorar el nivel de madurez de la seguridad en una arquitectura, se debe prestar especial atención a los siguientes ámbitos:

• Gestión de identidad y acceso (autenticación y autorización):
  • Implementar un sistema de Autenticación avanzada de usuarios con Single Sign On (SSO) y en el futuro con multi factor (MFA).
  • Proveer de políticas de acceso basadas en roles (RBAC) y/o atributos (ABAC) para proteger los datos almacenados y prevenir accesos no autorizados a recursos.
  • Disponer de un mecanismo o proceso de autenticación y autorización para las comunicaciones, no sólo para usuarios, sino también para la comunicación entre componentes de software. Esto se realiza mediante Api Gateway y certificados (MTLS) para microservicios y sistemas de colas. En el caso de entornos de contenedores, el mecanismo mTLS (Mutual TLS) evita que microservicios fraudulentos puedan acceder a los recursos del clúster, minimizando en gran medida la superficie de ataque.
• Monitorización y detección de amenazas: 
  • Incorporar sistemas avanzados de monitoreo, registro, supervisión, análisis de comportamiento y detección temprana de amenazas que permitan identificar actividades sospechosas en tiempo real (EDR). Contar con un plan de recuperación y respuesta para incidentes que se produzcan tanto en máquinas como en contenedores.
  • Monitorizar los logs producidos por los componentes de software para identificar fugas de información, errores de funcionamiento y alertas de seguridad (SIEM).
• Cifrado: 
  • Implementar comunicaciones cifradas que garanticen la privacidad y la integridad de los datos en tránsito, utilizando protocolos seguros como TLS (a partir de la versión 1.2) y mTLS (Mutual TLS).
  • Proteger los datos sensibles o confidenciales tanto en reposo (BBDD) como en tránsito, utilizando algoritmos de cifrado y hashing, con propiedades de seguridad comprobadas. Para garantizar la integridad y confidencialidad, se recomienda usar algoritmos de cifrado simétrico o algoritmos asimétricos. Implementar bibliotecas seguras de hash para contraseñas utilizando siempre las versiones más actualizadas.
  • Almacenar secretos y claves de cifrado en herramientas preparadas para tales fines (Gestores de Secretos).
• Configuración de los sistemas:
  • Bastionar convenientemente los sistemas en cuanto a una línea base de seguridad es imprescindible para evitar la explotación de ataque sobre éstos. El bastionado consiste en configurar correctamente los componentes y políticas del sistema. Estas tareas incluyen la eliminación softwares, aplicaciones, puertos, permisos y accesos que no sean utilizados para la tarea concreta que se desempeñe. También se incluyen los cambios de las configuraciones por defecto y el seguimiento de las prácticas de seguridad de los fabricantes, además de mantener un sistema de actualizaciones y parches para las vulnerabilidades encontradas en ellos. El bastionado siempre debe aplicarse en todos los componentes de la arquitectura.

Principios

Partiendo de los objetivos anteriores y del Modelo de la Arquitectura Global, una arquitectura segura debe satisfacer los siguientes principios fundamentales a nivel de protecciones durante el diseño y la implementación:

• Defensa en profundidad (Defense in Depth)
• Confianza cero (Zero Trust)
• Seguridad desde el diseño
• Monitorización constante
• Confidencialidad e integridad de datos
• Cumplimiento normativo

Estos principios ayudan a mejorar la robustez y seguridad de una organización y guían la toma de decisiones a lo largo del desarrollo, despliegue y mantenimiento de las distintas aplicaciones y sistemas:

Defensa en profundidad (Defense in Depth)

El objetivo es emplear múltiples capas de control de seguridad para mitigar riesgos. Ninguna medida de seguridad es infalible por sí sola, por lo que se recomienda una combinación de controles para prevenir, detectar y corregir, proporcionando una defensa más sólida frente a posibles amenazas.

Confianza cero (Zero Trust)

Se busca asumir que no se debe confiar en ninguna entidad, ya sea dentro o fuera de la red, de forma predeterminada. Se requiere implantar mecanismos de autenticación fuertes para verificar las identidades de usuarios y sistemas. Además de aplicar controles de autorización adecuados para garantizar que los usuarios y los sistemas tienen los derechos de acceso apropiados.

• Mínimo privilegio
• Separación de funciones
• Componentes mínimos
• Fallos seguro (Fail-Safe)

Seguridad desde el diseño

Se basa en el principio de que la seguridad debe integrarse desde el inicio del desarrollo, en la fase de diseño de sistemas y aplicaciones. Así se garantiza que las funciones de seguridad no se añadan a posteriori sino que sean fundamentales para la arquitectura del sistema.

Monitorización constante de eventos de seguridad

Este principio establece que debe implementarse mecanismos de supervisión y análisis continuo de los eventos de seguridad, para identificar y responder con prontitud a posibles incidentes de seguridad. Esto implica supervisión en tiempo real, análisis de registros e inteligencia sobre amenazas.

Confidencialidad e integridad de datos

Con este principio se busca proteger la confidencialidad e integridad de los datos mediante mecanismos de cifrado, controles de acceso y comprobaciones de integridad, garantizando que la información sensible no solo esté segura durante su transmisión, sino también cuando se almacena.

Cumplimiento normativo de seguridad

Su objetivo es alinear la arquitectura de seguridad con los requisitos reglamentarios pertinentes y las normas del mercado. Esto garantiza que la organización cumple las obligaciones legales y las mejores prácticas del sector. En este caso, se busca cumplir principalmente con el Esquema Nacional de Seguridad (en adelante ENS) y el Reglamento General de Protección de Datos (RGPD).

Componentes

Para la correcta implantación de una arquitectura de seguridad, la cual cumpla con los objetivos mencionados en el punto anterior, se debe contar con los siguientes componentes:

• Identity and Access Manager (IAM) que provee de mecanismos de autenticación avanzada de usuarios con multi factor (MFA) y Single Sign On (SSO) y de políticas de acceso basadas en roles (RBAC) y atributos (ABAC).
• Sistemas avanzados de observabilidad, monitorización, registro, supervisión, análisis de comportamiento y detección temprana de amenazas (EDR-Endpoint Detection and Response, SIEM- Security Information and Event Management).
• Almacenes de secretos e infraestructura de claves de cifrado (PKI-Public Key Infrastructure).

Identity & Access Manager (IAM)

La gestión de Identidades y accesos a la Junta de Andalucía está enfocada desde un prisma que contempla la escalabilidad y la homogeneización para todas las unidades organizativas (consejerías, organismos, delegaciones, subdirecciones, entidades o empresas adscritas) presentes en la Administración Pública Andaluza.

Es necesario un primer componente que gestionará las identidades, provisionando las cuentas (de usuario y sistema) a partir de datos centralizados del directorio corporativo y de las fuentes autoritativas (formadas inicialmente por el conjunto de los sistemas de recursos humanos) que permita definir identidades, cuentas de aplicación y roles/atributos asociados a la identidad para que puedan ser usados por las aplicaciones.

La gestión de accesos debe estar cubierta por un componente que permita realizar esta función, debiendo diferenciar claramente los mecanismos de autenticación y los de autorización, para complementarlos y usarlos debidamente para dar servicio a distintas tipologías de necesidades que sean requeridas por parte de los servicios, aplicaciones o sistemas, cubriendo las siguientes necesidades:

1. Proporcionar funciones de SSO (Single-Sign On) para el acceso de usuarios a múltiples plataformas con un único proceso de Login. El actual estándar de autenticación SAML se caracteriza por ser el más flexible para ser usado en entornos SSO donde, mediante el uso de mensajes XML, se realizan tareas de autenticación y autorización para el acceso a múltiples aplicaciones usando un único proceso de Login.
2. Disponer en el futuro de un mecanismo MFA (Multi-Factor Authentication) para añadir una capa adicional de protección en el proceso de autenticación, evitando ataques como la fuerza bruta o el phishing, para ser utilizados en aplicaciones o sistemas que requieran esta funcionalidad.
3. Ser capaz de gestionar los accesos entre servicios, los cuales son componentes de la arquitectura que realizan acciones de acceso a recursos y no deben intercambiar credenciales entre ellos. Para estos menesteres, el estándar de autorización OAuth es el más recomendado, ya que mediante el uso de Tokens JWT, un servicio puede realizar acciones o acceder a recursos sin tener que compartir credenciales, únicamente delegando la identificación del servicio contra el Identity Provider (IdP) que proporcionan los tokens.
4. Permitir la configuración de políticas de control de acceso basadas en roles (RBAC) y en atributos (ABAC). Esto permitirá cumplir con el principio del mínimo privilegio en los accesos y acciones permitidas a los diferentes componentes de la arquitectura.

Es importante mencionar que a la hora de implementar y configurar los protocolos SAML y OAuth en la herramienta de gestión de accesos, se deberán establecer las versiones SAML2 y OAuth2, respectivamente, pues son las opciones más seguras y actuales para ambos protocolos. De igual forma, todas las conexiones entre estos sistemas deberán realizarse bajo protocolo HTTPS, sobre TLS1.2 (o superior).

Sistemas de monitorización y detección de amenazas

Las labores de inspección, monitorización y alerta ante incidentes, es también otra parte importante de la detección de amenazas en tiempo de ejecución cuando las aplicaciones se encuentran desplegadas en entornos productivos. Es por ello, que la arquitectura de referencia de la ADA deba contener herramientas con este objetivo.

Bajo el escenario planteado por la arquitectura global de referencia de la ADA que se planteaba al principio de este artículo, se dispondrá de una infraestructura basada en contendores sobre Openshift (en adelante OCP), así mismo se dispondrá de los HOSTs que hospedan el sistema OCP y otros servidores de diversa índole. Por lo tanto, se deberá dotar a la arquitectura con herramientas de observabilidad (agentes/sondas) compatibles tanto con entornos de contenedores y como en HOSTs.

Además, se debe contar con un sistema de correlación y centralización (SIEM), el cual deberá ser compatible con las alertas y los logs que se vuelquen desde las sondas o agentes, de forma que pueda centralizarlas y gestionarlas para facilitar la labor de correlación e identificación de amenazas o incidentes.

Será también importante que el sistema de gestión de alertas tenga integración con otros componentes desplegados en la arquitectura de referencia, como pueda ser el gestor de accesos, de tal forma que los logs de auditoría de accesos también se vuelquen al sistema de correlación y centralización (SIEM).

La implementación de mecanismos de observabilidad y correlación, fortalece la capacidad de detección y respuesta ante amenazas de la arquitectura, garantizando la disponibilidad, la integridad y la confidencialidad de los sistemas y datos críticos.

Almacén de secretos e infraestructura de claves de cifrado (PKI)

La arquitectura de seguridad propuesta incluye un sistema seguro y centralizado para el almacenamiento y gestión de secretos y claves de cifrado. El almacén de secretos desempeña un papel crucial al permitir el inventariado de manera centralizada, aislada y cifrada de los secretos, garantizando la confidencialidad de la información sensible y la integridad de los datos almacenados. Además, el gestor de secretos abstrae a los desarrolladores de la tarea de generación y gestión de los secretos, lo que permite que un equipo de operadores administre el almacén de secretos de manera independiente.

El almacén de secretos deberá hacer las veces de infraestructura de clave púbica (PKI) permitiendo almacenar, administrar y gestionar las claves privadas.

Es importante que la herramienta seleccionada realice periódicamente la rotación de los secretos y los certificados de forma autónoma, aportando un mayor grado de robustez a la confidencialidad e integridad de los secretos.

Patrones de arquitectura y diseño

A continuación, se mostrará una tabla con el conjunto de patrones aceptados que permiten diseñar una arquitectura estable que cumpla con los requisitos de seguridad. La implantación de estos patrones son la solución para construir una arquitectura que cumpla con los principios ya descritos, y adopten las características de seguridad necesarios, usando para ello los componentes definidos en el apartado anterior.

Pila tecnológica

A continuación, se presentan las soluciones tecnológicas que se han seleccionado y que cumplen con las necesidades expuestas en los puntos anteriores.

A continuación se explica con mayor detalle cada uno de los componentes de la pila tecnológica.

Identity & Access Manager (IAM)

El sistema de Gestión de Identidades y Accesos es el conjunto de procesos, políticas y tecnologías que permiten garantizar que las personas adecuadas tengan acceso al recurso adecuado, en el momento adecuado y por los motivos adecuados.

Identidad

Como se ha indicado anteriormente, desde la Plataforma GUIA de la Junta de Andalucía se realiza actualmente toda la gestión de las identidades, recibiendo peticiones desde fuentes autoritativas relacionadas con la gestión de identidades y cuentas de usuario, que pueden ser dadas de alta, eliminarlas o modificarlas en el inventario de identidades almacenadas en GUIA.

GUIA informa a las aplicaciones que están integradas de las actualizaciones, creaciones o borrados de identidades asociadas a la aplicación y sus atributos.

Autenticación

La autenticación se realiza desde el servicio SSOWeb para la autenticación de empleados y ProxyClave para la autenticación de ciudadanos. Ambos utilizan distintos Identity Providers para realizar la autenticación de los usuarios: LDAP en el caso de empleados, y CL@VE en el caso de los ciudadanos.

Autorización

La solución corporativa para gestión de autorizaciones está pendiente de definición.

Finalmente, el escenario del sistema de gestión de identidades y accesos se materializa de la siguiente forma:

Almacén de secretos e infraestructura de claves de cifrado (PKI)

La solución corporativa para gestión de secretos e infraestructura de claves públicas (PKI) está pendiente de definición.

Esta solución es necesaria para dar cobertura a las necesidades para la gestión de secretos e infraestructura de claves públicas (PKI). En el Escenario "Utilización de una aplicación de gestión de secretos para el consumo de Secretos en Contenedores" se detalla cómo funciona esta aplicación.

Esta herramienta también permite la rotación de secretos y certificados, lo cual aporta aún mayor grado de confidencialidad e integridad a los secretos almacenados, que serán actualizados de forma periódica. Además permite configurar el almacenamiento cifrado, que será una característica obligatoria para todos los secretos administrados bajo el alcance de esta arquitectura.

Requisitos Generales del Gestor de Secretos y PKI

• Almacenamiento Seguro: Los secretos deben almacenarse de forma centralizada y cifrada para evitar su exposición en archivos o código.
• Rotación Automática de Secretos y Certificados: Implementación de mecanismos que permitan la actualización periódica de secretos y certificados para mejorar la seguridad.
• Compatibilidad con Contenedores: El sistema debe ser compatible con plataformas de contenedores como Openshift, asegurando una integración fluida sin comprometer la seguridad.
• Gestión de PKI: Capacidad para administrar la infraestructura de clave pública, incluyendo la emisión, renovación y revocación de certificados.

Con el objetivo de mejorar el bastionado del gestor de secretos, se indican a continuación las políticas de seguridad que se deben habilitar en la solución:

• Despliegue de una aplicación de gestión de secretos en OCP:
  • Desplegar esta aplicación mediante el inyector "Sidecar Agent". Esta modalidad de despliegue es compatible con OCP y permite el consumo y rotación segura de secretos mediante el uso de un agente integrado en el Pod del microservicio.
  • Habilitar la política de Autenticación en la aplicación de gestión de secretos para autenticarse mediante JWT contra RHBK.
  • No ejecutar la aplicación de gestión de secretos como root sino utilizar una cuenta de servicio dedicada para evitar el escalado de privilegios.
  • Habilitar la funcionalidad de logs y auditoría integrándolos con el SIEM corporativo (MÓNICA).
  • Configurar el microservicio de la aplicación de gestión de secretos en OCP como servicio de alta disponibilidad para asegurar el acceso constante a los secretos.
• Seguridad de una aplicación de gestión de secretos:
  • Por defecto, las políticas de seguridad de los gestores de secretos se encuentran configuradas como “deny”. Esta política no concede ningún permiso sobre el sistema.

  • Implementar políticas de control de acceso en la capa de administración de la herramienta para limitar las acciones (capabilities) y visibilidad de secretos a aquellos que operen y administren un gestor de secretos. Por ejemplo:

    # This section grants all access on "secret/*". further restrictions can
                    # be applied to this broad policy, as shown below.
                    path "secret/*" {
                      capabilities = ["create", "read", "update", "patch", "delete", "list"]
                    }

  • Habilitar cifrado TLS1.3 (o al menos TLS1.2) para todas las comunicaciones entre clientes y el gestor de secretos.
• Gestión de Secretos:
  • Implementar espacios de nombres (namespaces) para aislar secretos por aplicación o usuario.
  • Configurar políticas de expiración y rotación automática de secretos para mejorar la confidencialidad.
  • Limitar el acceso a los secretos mediante el principio del mínimo privilegio, con roles y permisos lo más restrictivos posible.
• Uso de PKI con un gestor de secretos:
  • Crear una autoridad de certificación (CA) para emitir y gestionar certificados digitales.
  • Establecer políticas de emisión para controlar el acceso y el uso de certificados.
  • Utilizar un gestor de secretos para generar certificados TLS para servicios y aplicaciones en Kubernetes.
• Rotación de Certificados y Claves
  • Configurar políticas de renovación automática para prevenir el vencimiento de certificados.
  • Implementar alertas y procesos automatizados para la rotación de claves y certificados.
  • Asegurar el control de acceso a las funciones de administración de PKI.
• Convivencia en un ecosistema de microservicios sobre OCP
  • Utilizar el agente sidecar para acceder a secretos almacenados en un gestor de secretos seguro.
  • Configurar las diferentes aplicaciones para utilizar certificados emitidos por un gestor de secretos para comunicaciones seguras.
  • Aplicar las mejores prácticas de seguridad como el principio del mínimo privilegio para evitar la exposición no autorizada de secretos y claves.

De esta forma se conseguirá una protección básica de integración de un gestor de secretos en un entorno de microservicios sobre OCP y soportando funciones de PKI, garantizándose la confidencialidad, integridad y disponibilidad de los secretos.

Sistemas de monitorización y detección de amenazas

Como se ha comentado anteriormente, la arquitectura de referencia de seguridad debe contener herramientas de observabilidad que actúen como agentes para detectar las amenazas, y sistemas de monitorización y correlación para los eventos detectados. Con este fin se propone desplegar el siguiente escenario, donde los microservicios y los HOST dispondrán de agentes de detección de amenazas en tiempo de ejecución que enviarán sus logs de auditoría a un sistema de correlación y centralización (SIEM) basado en la herramienta MÓNICA.

• Sensor para contenedores de CrowdStrike Falcon:

  El sensor para contenedores de CrowdStrike Falcon actúa como un Sistema de Detección y Respuesta en EndPoints (EDR) en entornos de contendores y pods, proporcionando capacidades avanzadas de detección de seguridad en llamadas de sistema, actividades del kernel y tráfico de red. Su implementación en la arquitectura permite una vigilancia proactiva de amenazas y actividades maliciosas en los pods de Openshift.

• Sensor para HOSTs de CrowdStrike Falcon:

  Además, CrowdStrike Falcon también cubre la protección de HOSTs, tanto físicos como virtuales. Especializada en la detección de intrusiones de seguridad y actividades maliciosas, CrowdStrike completa la estrategia de seguridad al proporcionar una visibilidad pegada al servidor que virtualiza el entorno de contenedores. Sus capacidades de detección avanzada ayudan a identificar y responder rápidamente ante posibles amenazas en tiempo real.

• Integración con SIEM:

  Las alertas de seguridad generadas por CrowdStrike Falcon se centralizan y correlan en un Sistema de Gestión de Eventos e Información de Seguridad (SIEM) soportado por la plataforma MÓNICA. Esta integración permite un análisis exhaustivo de las alertas y eventos de seguridad, facilitando la identificación de patrones de comportamiento anómalos y la respuesta rápida ante posibles incidentes. Al ser el SIEM corporativo de la ADA, su integración con el resto de herramientas de seguridad corporativas se encuentra en un estado de madurez muy alto, permitiendo monitorizar todas las alertas de seguridad generadas por herramientas de seguridad horizontales desplegadas en la actualidad y que se pretenden desplegar con la presente arquitectura de referencia. Gracias a estas integraciones se conseguirá una visión a nivel de auditoría mucho más amplia acerca de las alertas de seguridad de toda la arquitectura dispuesta.

• Análisis y Respuesta:

  La implementación de CrowdStrike Falcon en contendores y HOSTs y su integración con MONICA, permitirá que los equipos de seguridad puedan interpretar y analizar las alertas generadas para identificar amenazas potenciales y tomar medidas correctivas ágiles, mitigando el impacto ante posibles ataques y protegiendo la infraestructura y los datos de la organización. Por tanto, se fortalecerá la capacidad de detección y la respuesta ante amenazas de la arquitectura, garantizando la disponibilidad, la integridad y la confidencialidad de los sistemas y datos críticos.

Escenarios de aplicación

Utilización de una aplicación de gestión de secretos para el consumo de Secretos en Contenedores

Escenario

Se va a definir la integración de un sistema para la generación y utilización segura de secretos en un entorno donde los activos a proteger sean instancias de contenedores en pods de Kubernetes. La generación de los secretos será una tarea transparente a los desarrolladores, y será gestionada por el equipo de operaciones, que será el encargado de facilitar las parejas clave-valor para los secretos.

Descripción

• Aplicación de gestión de secretos: se implementará una aplicación de gestión de secretos para gestionar de forma segura y centralizada los secretos utilizados por las aplicaciones en contenedores. Esta proporcionará un almacenamiento cifrado y controlado de los secretos, evitando su exposición en archivos o en el código de las aplicaciones. Además, permitirá la gestión dinámica y la rotación automática de los secretos para mantener la seguridad de la infraestructura.
• Despliegue en OCP: la aplicación de gestión de secretos será desplegada como un servicio en el OCP, garantizando su disponibilidad y escalabilidad. Se configurará la política de autenticación mediante JWT integrando la herramienta con RHBK, el cual estará asociado a la cuenta de servicio correspondiente. Se establecerá un servicio de alta disponibilidad para asegurar el acceso constante.
• Integración con microservicios: los microservicios en otros contenedores accederán a los secretos almacenados en la aplicación de gestión de secretos utilizando un agente especial. Se configurarán políticas de acceso para limitar la visibilidad y manipulación de los secretos, garantizando el principio del mínimo privilegio.
• Funcionalidades de la aplicación de gestión de secretos: proporcionarán funcionalidades avanzadas, como la generación dinámica de secretos, la rotación automática de claves y certificados y la auditoría detallada de las acciones realizadas en los secretos. Además, se habilitará el cifrado TLS para las comunicaciones entre clientes y la propia aplicación, garantizando la seguridad en la transferencia de datos sensibles.

Monitorización Avanzada de Seguridad en Contenedores

Escenario

Un microservicio está monitorizado por el sensor de CrowdStrike Falcon a nivel de Pod. Además, el HOST físico que alberga la plataforma de virtualización, tiene desplegado otro sensor de Falcon, para realizar lo propio a nivel anfitrión. Culmina este escenario con la integración con la plataforma MÓNICA donde tanto el microservicio como el HOST envían las alertas de seguridad para ser correladas y tratadas.

Descripción

• CrowdStrike Falcon: para un despliegue robusto de Falcon, se desplegarán los sensores de Falcon tanto en el host que soporta la infraestructura de Openshift, como en los pods de los microservicios.
• Sensor para contenedores de CrowdStrike Falcon: una vez los sensores de Falcon estén integrados en los pods, se realizará la configuración correspondiente para conectar con la consola de Falcon donde se centralizarán los eventos de EDR. Será esta consola la que se integre con MÓNICA.
• Sensor para HOSTs de CrowdStrike Falcon: Falcon también dispone de sensores para los diferentes endpoints físicos que se quieran monitorizar, desde máquinas con SO huésped de entornos virtualizados (OCP), hasta workstations de usuarios finales. Todas las alertas de los sensores serán enviadas a la consola central de Falcon, donde se centralizan todos los servicios prestados por la herramienta. Este servidor central es quien se integrará con MÓNICA para realizar el correlado de alertas.
• MÓNICA: actuará como colector de observabilidad donde centralizar y correlar todas las alertas de seguridad generadas por los sensores de CrowdStrike Falcon.

Referencias

Referencias técnicas:

• Patrones de microservicios
• Kubernetes
• Openshift
• AES256
• JWT auth method: JWT/OIDC - Auth Methods Developer
• CrowdStrike Falcon sidecar sensor in Kubernetes