Seguridad y privacidad

Este capítulo proporciona una visión general de las preguntas frecuentes sobre seguridad de la información, privacidad y aseguramiento de la calidad.

Procesamiento de datos y permisos

1. ¿Desde qué centro de datos opera RADIUSaaS?

El servicio principal de RADIUSaaS puede desplegarse actualmente en las siguientes regiones:

• Australia

• Europa

• Reino Unido

• Estados Unidos de América

En caso de que se requieran proxies RADIUS, pueden desplegarse en los siguientes países/regiones:

2. ¿Qué datos procesa RADIUSaaS?

Certificados

RADIUSaaS procesa certificados X.509 de usuarios o dispositivos para validar la autenticidad de la solicitud de autenticación. Como parte del certificado, se puede procesar cada atributo, que potencialmente contiene información como:

• Nombre de usuario

• Correo electrónico

• UPN

Protocolo RADIUS

RADIUSaaS se basa en el protocolo RADIUS, p. ej. los siguientes datos son visibles para RADIUSaaS:

• Dirección MAC del cliente

• Dirección MAC del NAS (p. ej. punto de acceso, switch, ...)

• SSID de WiFi

• Datos específicos del proveedor (p. ej. VLAN, grupo de túnel, ...)

• Dirección IP del NAS

• Dirección IP pública asignada por el ISP

• Secreto compartido de RADIUS (relevante solo si RadSec no es compatible de forma nativa)

• Clave privada del certificado del servidor RADIUS

Varios

RADIUSaaS proporciona (opcionalmente) funcionalidad para generar pares de nombre de usuario + contraseña para el acceso a la red. Esas credenciales también son almacenadas y procesadas por el servicio.

3. ¿Qué datos son almacenados de forma persistente por/en nombre de RADIUSaaS y cómo?

1. Permisos

   La plataforma RADIUSaaS almacena información UPN/correo electrónico de los usuarios que están autorizados a acceder a la plataforma. No se almacenan ni procesan contraseñas por RADIUSaaS.

2. Registro (Logging)

   Para propósitos de solución de problemas y análisis, la plataforma RADIUSaaS registra todos los datos relevantes que procesa (ver Pregunta 2 excepto el Secreto Compartido de RADIUS y la clave privada del certificado del servidor).

   Los registros se almacenan directamente en la plataforma RADIUSaaS dentro de un Elasticsearch base de datos y se segregan para cada cliente mediante un espacio dedicado. Tiempo de retención de registros: 75 días.

3. Certificados

   RADIUSaaS requiere varios certificados de servidor así como certificados raíz para facilitar una operación adecuada. Todos esos certificados se almacenan de forma segura en un Azure KeyVault.

4. Las credenciales opcionales de nombre de usuario + contraseña mencionadas en Pregunta 2 están almacenan de forma segura en un Azure KeyVault.

5. Otros secretos y datos de configuración

   Otros datos secretos, p. ej. el Secreto Compartido de RADIUS así como la configuración del servicio, se almacenan de forma segura en un Azure KeyVault.

4. ¿Existe un mecanismo de archivo para los registros?

No existe un mecanismo incorporado de archivo de registros. Sin embargo, el Exportador de registros puede usarse para ingresar los registros RADIUS en sus propios servicios de registro y archivo.

5. ¿Qué permisos de inquilino (tenant) deben aceptar los usuarios que acceden al portal web de RADIUSaaS?

1. Perfil básico del usuario:

   Con este permiso RADIUSaaS recupera el UPN del usuario que intenta iniciar sesión en el Portal de administración de RADIUSaaS.

2. Mantener el acceso a los datos a los que le ha dado acceso

   Con este permiso RADIUSaaS recibe el derecho de solicitar un token de actualización para que el usuario pueda permanecer conectado.

Por favor vea aquí para más detalles.

6. ¿Qué datos quedan disponibles al otorgar el/los consentimiento(s) de la pregunta 5?

1. Perfil básico del usuario:

   Para detalles sobre qué datos se pueden recuperar, por favor consulte este artículo: https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-permissions-and-consent#profile

2. Mantener el acceso a los datos a los que le ha dado acceso

   No se hace disponible ningún dato específico al otorgar consentimiento a este permiso.

7. ¿Qué puntos finales accesibles externamente expone RADIUSaaS?

1. API de backend del servidor RADIUS

   • Proporciona información de configuración al proxy RadSec.

2. Puertos del servidor RADIUS y RadSec

   • Para facilitar la autenticación de red desde cualquier lugar de Internet, estas interfaces de autenticación deben exponerse públicamente.

3. Portal de administración de RADIUSaaS

   • Un portal web que facilita la administración del servicio.

4. API de gestión del clúster de Kubernetes

   • Requerida para operar el servicio.

8. ¿Cómo están protegidos los puntos finales de la Pregunta 7?

1. API de backend del servidor RADIUS

   • Asegurados mediante tokens de acceso JWT que pueden ser gestionados (emitidos, eliminados, revocados) por el cliente.

2. Puertos del servidor proxy RADIUS y RadSec

   • Puertos del servidor RadSec: asegurados con TLS (>= versión 1.2).

   • Puertos del servidor proxy RADIUS: protegidos mediante el Secreto Compartido de RADIUS.

3. Portal de administración de RADIUSaaS

   • Asegurado mediante autenticación OAuth 2.0 contra uno de nuestros IDP compatibles.

4. API de gestión del clúster de Kubernetes

   • Asegurado con TLS (>= versión 1.2).

9. ¿Qué puertos y protocolos usan los puntos finales de la Pregunta 7?

• API de backend del servidor RADIUS

  • HTTPS (TCP / 443)

• Puertos del servidor proxy RADIUS y RadSec

  • Puertos del servidor RadSec: RadSec (TCP / 2083)

  • Puertos del servidor proxy RADIUS: RADIUS (UDP / 1812, 1813)

• Portal de administración de RADIUSaaS

  • HTTPS (TCP / 443)

• API de gestión del clúster de Kubernetes

  • HTTPS (TCP / 443)

Identidad

1. ¿Qué esquemas de autorización se usan para obtener acceso a RADIUSaaS?

• El acceso administrativo se realiza mediante autenticación OAuth 2.0 contra un IDP para identidades o cuentas que están registradas en la plataforma.

2. ¿Existen controles de acceso condicional / basados en roles para proteger RADIUSaaS?

• Sí. El portal de administración de RADIUSaaS ofrece funciones para asignar roles a cada usuario (roles disponibles: administrador, visualizador, invitado).

• Para operar y mantener correctamente el servicio, existen cuentas súper-admin para un círculo limitado de empleados de glueckkanja AG, que tienen acceso completo a todas las instancias de cliente del servicio RADIUSaaS.

3. ¿Se pueden recuperar las credenciales de acceso? Si es así, ¿cómo?

• Credenciales de inicio de sesión: Depende de las políticas de Microsoft Entra ID (Azure AD) configuradas en el tenant del cliente.

• Las credenciales de nombre de usuario + contraseña así como todos los certificados para acceso a la red pueden recuperarse desde Azure KeyVault con una política de retención de 90 días después de haber sido eliminados.

Protección de datos

1. ¿Cómo está protegidos los datos en reposo contra el acceso no autorizado?

Datos de configuración y secretos

• Los datos de configuración se almacenan en Azure KeyVault y se protegen mediante credenciales de acceso que a su vez se almacenan como Secrets de Kubernetes.

Servicio de Kubernetes

• Los volúmenes y discos usados para alojar nuestro servicio están cifrados.

Registros

• La base de datos Elasticsearch se aloja en los discos cifrados del Servicio de Kubernetes.

• Los registros se almacenan en una base de datos Elasticsearch y se segregan mediante espacios dedicados.

• El acceso a esos espacios se otorga mediante credenciales de nombre de usuario + contraseña que a su vez se almacenan como Secrets de Kubernetes.

• La propia base de datos Elasticsearch no está cifrada.

2. ¿Cómo están protegidos los datos en tránsito contra el acceso no autorizado?

• Los flujos de autenticación del dispositivo que intenta acceder a la red están encapsulados en un túnel TLS (>= TLS 1.2).

• La asociación entre el NAS y el servidor RADIUS se ofusca mediante el Secreto Compartido de RADIUS (algoritmo de hash MD5).

3. ¿Cómo se separan los tenants de los clientes entre sí?

Backend

Los servicios backend de RADIUSaaS se ejecutan en múltiples clústeres de Kubernetes distribuidos a nivel mundial. La instancia RADIUSaaS de cada cliente tiene su propio espacio de nombres (namespace) de K8s, espacio de registro y IP pública dedicada. Hay una instancia de Elasticsearch con cuentas de cliente dedicadas para registro y lectura por clúster.

Proxies RADIUS

Cada proxy RADIUSaaS se ejecuta en su propia VM con IP pública dedicada.

Seguridad por diseño

1. ¿Emplea RADIUSaaS una estrategia de defensa en profundidad?

RADIUSaaS se basa en protocolos bien establecidos para manejar los flujos de autenticación de red (RADIUS, RadSec, EAP-TLS, EAP-TTLS-X). Debido al fuerte enfoque en la autenticación basada en certificados, capturar el tráfico carece de sentido mientras el espía no tenga acceso a un certificado de confianza.

2. ¿Es seguro el protocolo RADIUS basado en UDP?

Recomendamos usar el moderno RadSec protocolo para autenticarse contra RADIUSaaS. Sin embargo, todavía existen muchos componentes de infraestructura de red que no soportan RadSec.

El siguiente diagrama muestra el flujo de autenticación RADIUS:

En la primera parte de la secuencia de autenticación, la comunicación está asegurada por un algoritmo de hash basado en MD5 (parcialmente cifrado con el secreto compartido). No se transportan secretos en esta fase.

En la segunda parte de la secuencia de autenticación, un EAP basado en TLS (p. ej. EAP-TLS) cifra el tráfico. El tráfico EAP-TLS se transporta luego vía UDP hasta el proxy RADIUS. Esta es la fase en la que se intercambian credenciales como el certificado o la contraseña con RADIUSaaS. Si utiliza autenticación basada en certificados, no se transportan secretos en esta fase ya que solo se intercambia la clave pública. La clave privada permanece en el dispositivo cliente en todo momento.

Se proporciona una comparación exhaustiva entre RADIUS y RadSec en términos de seguridad de transporte aquí.

Conclusión: La autenticación RADIUS basada en UDP con RADIUSaaS es segura, ya que

• el tráfico relevante está cifrado y

• adicionalmente no se transportan secretos si se utiliza autenticación basada en certificados.

3. ¿Qué tecnologías, pilas, plataformas se usaron para diseñar RADIUSaaS?

• Kubernetes

• Stack EFK (Elasticsearch, Filebeats, Kibana)

• Python

• Azure (KeyVault)

• TerraForm

• Git CI

RGPD y residencia de datos

1. ¿Los datos salen de Europa?

• Servicios centrales: Depende de la configuración

  • Los servicios centrales de RADIUSaaS pueden alojarse en los centros de datos descritos en Pregunta 1.

  • Si el servicio está alojado en un centro de datos europeo, entonces ningún dato sale de la Unión Europea.

• Proxy RadSec: Depende de la configuración

  • Si requiere un proxy RadSec debido a limitaciones del equipo de red respecto al soporte nativo de RadSec, puede seleccionar un proxy de varias regiones, entre ellas Europa. En tal caso, sus datos permanecen dentro de las fronteras de la Unión Europea.

2. ¿De qué proveedores de nube de terceros depende RADIUSaaS y por qué?

Empresa	Servicios	Contacto	Propósito
Microsoft Corporation	Servicios en la nube (Azure)	Edificio 3, Carmanhall Road Sandyford, Industrial Estate 18, Dublín, Irlanda	Servicio de Kubernetes, redes, almacenamiento
Digital Ocean, Inc.	Servicios en la nube	Y101 6th Ave, Nueva York, NY 10013, Estados Unidos	Servicio de Kubernetes, redes, almacenamiento, VMs para proxies RADIUS
Vultr (marca registrada de The Constant Company, LLC)	Servicios en la nube	319 Clematis Street - Suite 900 West Palm Beach, FL 33401, Estados Unidos	VMs para proxies RADIUS
GitLab, Inc.	repositorio de código git, integración, pruebas y automatización de lanzamientos	268 Bush Street #350, San Francisco, CA 94104-3503, Estados Unidos	Repositorio de código, canalización CI/CD.

Varios

1. ¿RADIUSaaS forma parte de un programa de bug-bounty?

No

2. ¿Qué medidas de aseguramiento de calidad (QA) están en vigor?

• Existen laboratorios dedicados de RADIUSaaS para propósitos de desarrollo

• El despliegue e instalación del servicio se realiza mediante TerraForm, garantizando consistencia e idempotencia de cada despliegue de instancia

• Kibana APM se usa para la medición de la salud del servicio y la gestión de alertas

• Monitoreo de Digital Ocean supervisando los proxies RadSec

• Cada lanzamiento a producción debe pasar primero por el canal interno, superando los obstáculos de QA relevantes como parte de nuestro proceso CI

  • Pruebas unitarias

  • Revisión por pares (principio de seis ojos)

  • Pruebas de integración

  • Pruebas de estrés

  • Pruebas basadas en la experiencia

3. ¿Realizan pruebas de penetración periódicamente?

No.

Como parte de nuestras Prácticas de Desarrollo Seguro, empleamos herramientas (p. ej. análisis estático de código) que escanean la base de código en busca de CVE y otros exploits comunes (incluyendo dependencias como bibliotecas de terceros) que podrían afectar la seguridad de los puntos finales que RADIUSaaS expone. Antes de cualquier lanzamiento, se evalúan y remedian los hallazgos relevantes, para asegurar que RADIUSaaS permanezca libre de vulnerabilidades conocidas. No realizamos pruebas de penetración nosotros mismos, ni usamos herramientas de terceros de “Penetration Test-as-a-Service”. Para lo primero, vemos un conflicto de interés inherente. Para lo segundo, dado que los servicios típicos de pruebas de penetración a menudo simplemente verifican los puntos finales expuestos contra CVE y otros exploits conocidos, no vemos un valor añadido frente a las comprobaciones que ya realizamos usando análisis estático de código. Si desea realizar sus propias pruebas de penetración, por favor contáctenos y cuéntenos sus requisitos.

4. ¿Existe un proceso de parcheo?

Sí.

Los parches, correcciones rápidas, correcciones de errores y actualizaciones de funciones se introducen mediante nuestro proceso CI/CD que aprovecha diferentes canales de pruebas para asegurar que solo el código que satisface nuestros requisitos de QA sea liberado. El código recién publicado se pone automáticamente a disposición de todos nuestros clientes. El uso de Infraestructura como Código (Terraform) nos permite entregar actualizaciones consistentes, reproducibles y de alta calidad a nuestros clientes.

La arquitectura basada en Kubernetes de nuestro servicio garantiza que las actualizaciones de código sean transparentes para nuestros clientes y no provoquen interrupciones del servicio.

5. ¿Cuáles son los SLA para parches?

• Parches para CVE / vulnerabilidades de seguridad: Una vez que la vulnerabilidad se haga pública o en cuanto identifiquemos una vulnerabilidad dentro de nuestro propio código, se proporcionará una corrección urgente en un plazo no mayor a 24 horas después de que hayamos tenido conocimiento de la vulnerabilidad.

• Otros parches: Sin SLA.

6. ¿RADIUSaaS realiza copias de seguridad?

Secretos y datos de configuración

Aprovechamos Azure KeyVault para almacenar de forma segura secretos (p. ej. certificados) y todos los demás datos de configuración del servicio. Azure KeyVault es un servicio georedundante de alta disponibilidad que replica todo su contenido en un segundo centro de datos, proporcionando así servicios de copia de seguridad implícitos.

Servidores RADIUS y RadSec

Sin estado. No requieren copia de seguridad.

Registros

Actualmente no están respaldados.

7. ¿Se realizan pruebas de restauración de copias de seguridad?

Sí.

La restauración desde copias de seguridad se prueba con cada actualización/lanzamiento del servicio. Hay aproximadamente 4 - 8 lanzamientos por año.