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 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 clientes 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 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 evitar sanciones legales, proteger la reputación de la organización y garantizar la privacidad de la información.

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 de usuarios con multi factor (MFA) y Single Sign On (SSO).
  • Proveer de políticas de acceso basadas en roles (RBAC) 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 o 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. Este mecanismo podría ser gestionado por una solución de service mesh.
• 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 como el AES256 (Estándar de cifrado avanzado) o algoritmos asimétricos como el RSA2048 y el ECC (Criptografía de curva elíptica). Implementar bibliotecas seguras de hash para contraseñas, como bcrypt o Argon2 que utilizan el algoritmo Blowfish tilizando 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 vuelve robustas y seguras las organizaciones y guían la toma de decisiones a lo largo del desarrollo, despliegue y mantenimiento de una arquitectura: 

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 1, se debe contar con los siguientes componentes:

• Identity and Access Manager (IAM) que provee de mecanismos de autenticación de usuarios con multi factor (MFA) y Single Sign On (SSO) y de políticas de acceso basadas en roles (RBAC).
• 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, se debe enfocar desde un prisma que contemple 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.

Por este motivo se ha tenido presente, para el diseño de esta arquitectura de seguridad, la importancia de la Plataforma GUIA, sus servicios horizontales y más concretamente, su implicación en la provisión de las cuentas (de usuario y servicio) sobre el Directorio Activo único (Directorio Activo Corporativo, en adelante DAC) al cual pretende aspirar Junta de Andalucía.

Bajo estas premisas, es necesario diferenciar entre el componente que gestionará las Identidades y el componente que gestionará los Accesos.

La Plataforma GUIA realiza actualmente toda la gestión de las identidades mediante el uso del componente Oracle Identity Governance (OIG), el cual recibe las peticiones de gestión de cuentas por parte de SIRHUS para darlas de alta, eliminarlas o modificarlas en el DAC.

La gestión de los accesos en estos momentos no se realiza desde GUIA, siendo necesaria la incorporación de un nuevo componente que realice esta función, el cual cubra de forma obligatoria 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 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 de 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.
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)

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 mediante el uso del componente Oracle Identity Governance (OIG), el cual recibe las peticiones de gestión de cuentas por parte de SIRHUS para darlas de alta, eliminarlas o modificarlas en el DAC.

La gestión de los accesos no se realiza desde GUIA, por lo que se ha seleccionado como gestor de accesos la solución Red Hat Build of Keycloak (en adelante, RHBK), la cual es compatible con diferentes estándares de gestión de accesos como: SAML, OAuth y OpenID Connect (OIDC). Además permite el control de accesos RBAC, así como la federación de identidades contra OIG.

Finalmente, el escenario del sistema de gestión de identidades y accesos propuesto quedaría de la siguiente forma:

Como puede verse en la Ilustración anterior, las peticiones de los usuarios para acceder a aplicaciones corporativas, servicios o desde los propios servicios entre sí, se realizarán a través de RHBK, quién validará la existencia de una cuenta (de usuario o servicio) contra el OIG y comprobará los permisos que tiene dicha cuenta para acceder al recurso solicitado (URL del recurso).

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

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

Para dar cobertura a las necesidades para la gestión de secretos e infraestructura de claves públicas (PKI), es necesario utilizar una aplicación de gestión de secretos. 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 del grupo ICA.

• 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

IAM y Mecanismo de autenticación y autorización para Usuarios

Escenario

Un servicio se autentica contra el gestor de accesos RHBK. Además, un usuario que desea acceder a un servicio, se autentica en el SSO (RHBK), el cual, administra sus permisos de acceso y valida la identidad contra el OIG.

Descripción

Como puede verse en la Ilustración anterior, las peticiones de los Usuarios para acceder a aplicaciones o servicios se realizarán a través de RHBK. RHBK validará la existencia de una cuenta (de usuario o servicio) contra el OIG y comprobará los permisos que tiene dicha cuenta para acceder al recurso solicitado. 

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

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