> For the complete documentation index, see [llms.txt](https://docs.radiusaas.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.radiusaas.com/es/otro/faqs/security-and-privacy.md).

# Seguridad y privacidad

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

## Procesamiento de datos y permisos

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

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

* Australia
* Europa
* Reino Unido
* Estados Unidos de América

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

| Continente   | Región                                                             |
| ------------ | ------------------------------------------------------------------ |
| África       | Johannesburgo                                                      |
| Asia         | <p>Bangalore<br>Singapur<br>Tel Aviv<br>Tokio<br>Seúl<br>Osaka</p> |
| Australia    | <p>Sídney<br>Melbourne</p>                                         |
| Europa       | <p>Fráncfort<br>Londres<br>Madrid<br>Estocolmo</p>                 |
| Norteamérica | <p>Dallas<br>Nueva York<br>Seattle<br>Toronto</p>                  |
| Sudamérica   | <p>Santiago<br>São Paulo</p>                                       |

### 2. ¿Qué datos procesa RADIUSaaS?

#### **Certificados**

RADIUSaaS procesa certificados X.509 de usuario o dispositivo para validar la autenticidad de la solicitud de autenticación. Como parte del certificado, se puede procesar cualquier atributo, que potencialmente contenga información como:

* Nombre de usuario
* Correo electrónico
* UPN

#### **Protocolo RADIUS**

RADIUSaaS se basa en el protocolo RADIUS; por ejemplo, los siguientes datos son visibles para RADIUSaaS:

* Dirección MAC del cliente
* Dirección MAC del NAS (p. ej., punto de acceso, conmutador, ...)
* 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 (solo relevante si RadSec no es compatible de forma nativa)
* Clave privada del certificado del servidor RADIUS

#### **Misceláneo**

RADIUSaaS proporciona opcionalmente la funcionalidad de generar pares nombre de usuario + contraseña para el acceso a la red. Esas credenciales también se almacenan y procesan por el servicio.

### 3. ¿Qué datos se almacenan de forma persistente por/en nombre de RADIUSaaS y cómo?

1. Permisos

   La plataforma RADIUSaaS almacena información de UPN/correo electrónico de los usuarios autorizados para acceder a la plataforma. **RADIUSaaS no almacena ni procesa contraseñas.**
2. Registro

   Para fines de solución de problemas y análisis, la plataforma RADIUSaaS registra todos los datos relevantes que procesa (véase [Pregunta 2](#2.-which-data-is-processed-by-radiusaas) 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 una *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 un funcionamiento adecuado. 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](#2.-which-data-is-processed-by-radiusaas) son **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 integrado de archivo de registros. Sin embargo, la [Exportador de registros](/es/portal-de-administracion/settings/log-exporter.md) función puede utilizarse para ingerir los registros RADIUS en sus propios servicios de registro y archivo.

### 5. ¿A qué permisos de tenant deben consentir los usuarios que acceden al portal web de RADIUSaaS?

1. `Perfil básico de usuario`:

   Con este permiso, RADIUSaaS obtiene 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 concedido acceso`

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

Consulte [aquí](/es/portal-de-administracion/acceso-y-reglas/permissions.md#permissions-consent) para más detalles.

### 6. ¿Qué datos se ponen a disposición al conceder el consentimiento o los consentimientos de 5.?

1. `Perfil básico de usuario`:

   Para obtener detalles sobre qué datos se pueden recuperar, consulte este artículo: <https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-permissions-and-consent#profile>&#x20;
2. `Mantener el acceso a los datos a los que le ha concedido acceso`

   No se pone a disposición ningún dato específico al otorgar el consentimiento para este permiso.

### &#x20;     7. ¿Qué endpoints accesibles externamente expone RADIUSaaS?

1. API del 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
   * Necesaria para operar el servicio.

### 8. ¿Cómo están protegidos los endpoints de la pregunta 7?

1. API del backend del servidor RADIUS
   * Protegidos mediante tokens de acceso JWT que pueden ser administrados (emitidos, eliminados, revocados) por el cliente.
2. Puertos del proxy RADIUS y del servidor RadSec
   * Puertos del servidor RadSec: protegidos 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
   * Protegido mediante autenticación OAuth 2.0 contra uno de nuestros [IDP compatibles](/es/portal-de-administracion/acceso-y-reglas/permissions.md#supported-idps).
4. API de gestión del clúster de Kubernetes
   * Protegido con TLS (>= versión 1.2).

### 9. ¿Qué puertos y protocolos utilizan los endpoints de la pregunta 7?

* API del backend del servidor RADIUS
  * HTTPS (TCP / 443)
* Puertos del proxy RADIUS y del servidor RadSec &#x20;
  * 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 utilizan para obtener acceso a RADIUSaaS?

* El acceso administrativo se realiza mediante autenticación OAuth 2.0 contra un [IDP](/es/portal-de-administracion/acceso-y-reglas/permissions.md#supported-idps) para identidades o cuentas registradas en la plataforma.

### 2. ¿Existen controles de acceso Conditional Access / basados en roles para proteger RADIUSaaS?

* Sí. El portal de administración de RADIUSaaS proporciona funciones para asignar roles a cada usuario (roles disponibles: administrador, visor, invitado).
* Para operar y mantener correctamente el servicio, existen cuentas de superadministrador para un círculo limitado de empleados de glueckkanja AG, que tienen acceso total a todas las instancias de cliente del servicio RADIUSaaS.

### 3. ¿Se pueden recuperar las credenciales de acceso? En caso afirmativo, ¿cómo?

* Credenciales de inicio de sesión: depende de las políticas configuradas de Microsoft Entra ID (Azure AD) en el tenant del cliente.
* Las credenciales de nombre de usuario + contraseña, así como todos los certificados para el 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.

### 4. ¿Qué hay que hacer para recuperar el acceso perdido a la instancia de RADIUSaaS?

* Si su empresa perdió el acceso a la instancia de RADIUSaaS porque el o los administradores anteriores se marcharon o el UPN / dominio ha cambiado, la forma más sencilla de recuperar el acceso es volver a crear una cuenta de usuario que coincida con el UPN existente en RADIUSaaS > Permisos > Administradores. Con diferencia, este es el enfoque más rápido, ya que no requiere ninguna acción por nuestra parte.
* Si lo anterior no es viable, la recuperación del acceso al portal estará sujeta a un riguroso proceso de verificación de identidad que no solo consume tiempo, sino que requerirá un esfuerzo significativo por ambas partes. El coste único de este proceso es de 420,00 EUR (sin IVA). Para iniciar el proceso, abra un ticket de soporte técnico.
* Para evitar la pérdida de acceso a su tenant de RADIUSaaS, siga nuestras mejores prácticas completando cuidadosamente cada paso de nuestras [Guías de inicio](/es/configuracion/get-started.md).

## Protección de datos

### 1. ¿Cómo se *datos en reposo* protegen 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 utilizados para alojar nuestro servicio están [cifrados](https://learn.microsoft.com/en-us/azure/aks/enable-host-encryption).

#### **Registros**

* La base de datos de Elasticsearch se aloja en los discos cifrados del servicio de Kubernetes.
* Los registros se almacenan en una base de datos de Elasticsearch y se segregan mediante espacios dedicados.
* El acceso a esos espacios se concede mediante credenciales de nombre de usuario + contraseña que, a su vez, se almacenan como *Secrets de Kubernetes*.
* La propia base de datos de Elasticsearch no está cifrada.

### 2. ¿Cómo se *datos en tránsito* protegen contra el acceso no autorizado?

* Los flujos de autenticación del dispositivo que intenta acceder a la red se encapsulan en un túnel TLS (>= TLS 1.2).
* La asociación entre NAS y el servidor RADIUS se ofusca mediante el Secreto compartido de RADIUS (algoritmo de hash MD5).

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

#### Backend

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

#### Proxies RADIUS

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

## Seguridad desde el diseño

### 1. ¿RADIUSaaS emplea una estrategia de defensa en profundidad?

RADIUSaaS se basa en protocolos bien establecidos para gestionar 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 utilizar el moderno [RadSec](/es/overview.md#what-is-radsec) protocolo para autenticarse contra RADIUSaaS. Sin embargo, todavía existen muchos componentes de infraestructura de red que no admiten RadSec.

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

![](https://content.gitbook.com/content/SWU1DQ4UGkqER7uGNUOm/blobs/byiGM49uzq0vRK6ny2KM/radius-authentication-sequence.png)

En la primera parte de la secuencia de autenticación, la comunicación se protege mediante 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. A continuación, el tráfico EAP-TLS se transporta mediante UDP al proxy RADIUS. Esta es la fase en la que se intercambian con RADIUSaaS credenciales como el certificado o la contraseña. 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 siempre en el dispositivo cliente.

Se proporciona una comparación exhaustiva entre RADIUS y RadSec en términos de seguridad del transporte [aquí](/es/otro/faqs/security-and-privacy/seguridad-de-transporte-en-radius-frente-a-radsec.md).

{% hint style="success" %}
Conclusión: la autenticación RADIUS basada en UDP con RADIUSaaS es segura, ya que&#x20;

* el tráfico relevante está cifrado\
  y
* además no se transportan secretos si se utiliza autenticación basada en certificados.
  {% endhint %}

### 3. ¿Qué tecnologías, stacks y plataformas se utilizaron para diseñar RADIUSaaS?

* `Kubernetes`
* `Stack EFK (Elasticsearch, Filebeats, Kibana)`
* `Python`
* `Azure (KeyVault)`
* `TerraForm`
* `Git CI`

## Cumplimiento <a href="#compliance" id="compliance"></a>

### 1. ¿glueckkanja cuenta con la certificación ISO 27001?

Sí. El Sistema de Gestión de Seguridad de la Información (ISMS) de glueckkanja AG está certificado según **ISO/IEC 27001:2022**. El alcance de la certificación cubre:

* Desarrollo de productos
* Servicios gestionados

Puede ver el certificado actual [aquí](https://www.glueckkanja.com/documents/general/gk-ISO27001Certificate-en.pdf).

### 2. ¿glueckkanja somete su seguridad a pruebas por expertos externos?

Sí. En 2026, glueckkanja AG encargó a una empresa independiente y especializada en seguridad ofensiva que realizara una evaluación de Red Team que cubriera a toda nuestra empresa.

Elegimos deliberadamente este enfoque holístico en lugar de una prueba de penetración clásica. En vez de comprobar sistemas o endpoints individuales frente a vulnerabilidades conocidas, el Red Team simuló un ciberataque realista y avanzado por parte de un atacante interno contra nuestra infraestructura de TI, encadenando técnicas como lo harían adversarios reales.

La evaluación se centró en:

* identificar vulnerabilidades de alto impacto,
* mapear rutas de ataque completas a través de nuestro entorno,
* evaluar posibles vectores para obtener acceso no autorizado a entornos de clientes,
* evaluar posibles vectores para ejecutar ataques a la cadena de suministro.

Todos los hallazgos se documentaron junto con recomendaciones de mitigación y se abordan como parte de nuestro Sistema de Gestión de Seguridad de la Información certificado ISO 27001.

Repetiremos esta evaluación de Red Team anualmente.

## RGPD y residencia de datos <a href="#user-content-gdpr-and-data-residency" id="user-content-gdpr-and-data-residency"></a>

### 1. ¿Los datos salen de Europa?

* Servicios principales: depende de la configuración
  * Los servicios principales de RADIUSaaS pueden alojarse en los centros de datos descritos en [Pregunta 1](#1.-from-what-data-center-is-radiusaas-operating).
  * Si el servicio se aloja en un centro de datos europeo, entonces ningún dato sale de la Unión Europea.
* Proxy RadSec: depende de la configuración
  * Si necesita 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 ese 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)                                                  | <p>Building 3, Carmanhall Road Sandyford,<br>Industrial Estate 18, Dublín,<br>Irlanda</p> | Servicio de Kubernetes, red, almacenamiento                          |
| Digital Ocean, Inc.                                  | Servicios en la nube                                                          | <p>Y101 6th Ave,<br>Nueva York,<br>NY 10013,<br>Estados Unidos</p>                        | Servicio de Kubernetes, red, almacenamiento, VMs para proxies RADIUS |
| Vultr (marca comercial de The Constant Company, LLC) | Servicios en la nube                                                          | <p>319 Clematis Street - Suite 900<br>West Palm Beach, FL 33401,<br>Estados Unidos</p>    | VMs para proxies RADIUS                                              |
| GitLab, Inc.                                         | repositorio de código git, integración, pruebas y automatización de versiones | <p>268 Bush Street #350, </p><p>San Francisco, </p><p>CA 94104-3503, Estados Unidos </p>  | Repositorio de código, canalización CI/CD.                           |

## Misceláneo <a href="#user-content-miscellaneous" id="user-content-miscellaneous"></a>

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

No

### 2. ¿Qué medidas de QA están implementadas?

* Existen laboratorios dedicados de RADIUSaaS para fines de desarrollo
* El despliegue y la instalación del servicio se realizan mediante TerraForm, garantizando la consistencia y la idempotencia de cada despliegue de instancia
* Kibana APM se utiliza para la medición del estado del servicio y la gestión de alertas
* La monitorización de Digital Ocean supervisa los proxies RadSec
* Cada lanzamiento de producción debe pasar primero por el canal interno, superando los obstáculos de QA relevantes como parte de nuestro proceso de 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 regularmente?

No en forma de una prueba de penetración clásica de SCEPman. En su lugar, glueckkanja AG se somete a una evaluación anual de Red Team realizada por un especialista externo independiente, que va más allá de una prueba de penetración clásica (véase [¿glueckkanja somete su seguridad a pruebas por expertos externos?](#id-2.-does-glueckkanja-have-its-security-tested-by-external-experts)).

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 (incluidas dependencias como bibliotecas de terceros) que podrían afectar a la seguridad de los endpoints que expone RADIUSaaS. Antes de cualquier lanzamiento, cualquier hallazgo relevante se evalúa y corrige para garantizar que RADIUSaaS siga libre de vulnerabilidades conocidas.&#x20;

No realizamos nosotros mismos pruebas de penetración, ni utilizamos herramientas de terceros de "Penetration Test-as-a-Service". En el primer caso, vemos un conflicto de intereses inherente. En el segundo, dado que los servicios típicos de pruebas de penetración a menudo simplemente comprueban los endpoints expuestos frente a CVE y otros exploits conocidos, no vemos ningún valor añadido frente a las comprobaciones que ya realizamos mediante análisis estático de código.&#x20;

En su lugar, confiamos en un enfoque holístico: en 2026, un Red Team independiente simuló un ataque realista y avanzado contra glueckkanja AG, incluyendo explícitamente rutas de ataque hacia entornos de clientes y ataques a la cadena de suministro. En lugar de probar endpoints aislados, esta evaluación examina rutas de ataque completas a través de nuestra organización, lo que consideramos mucho más significativo para la seguridad de nuestros clientes. Repetimos esta evaluación anualmente.

Si desea realizar sus propias pruebas de penetración, por favor [póngase en contacto con nosotros](https://support.radiusaas.com/support/tickets/new?ticket_form=technical_support_request_%28radiusaas%29) y cuéntenos cuáles son sus requisitos.

### 4. ¿Existe un proceso de aplicación de parches?

Sí.&#x20;

Los parches, hot-fixes, correcciones de errores y actualizaciones de funciones se introducen mediante nuestro proceso de CI/CD, que aprovecha diferentes canalizaciones de pruebas para garantizar que solo se publique código que cumpla nuestros criterios de QA. El código recién publicado se pone automáticamente a disposición de todos nuestros clientes. El uso de Infrastructure as Code (Terraform) nos permite ofrecer a nuestros clientes actualizaciones consistentes, reproducibles y de alta calidad.

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.&#x20;

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

* Parches para CVE / vulnerabilidades de seguridad: en cuanto la vulnerabilidad se haga de conocimiento público o en cuanto identifiquemos una vulnerabilidad en nuestro propio código, se proporcionará un hot-fix no más tarde de 24 horas después de que tengamos conocimiento de la vulnerabilidad.&#x20;
* 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 de alta disponibilidad [geo-redundante](https://learn.microsoft.com/en-us/azure/key-vault/general/disaster-recovery-guidance) que replica todo su contenido en un segundo centro de datos, proporcionando así servicios implícitos de copia de seguridad.&#x20;

#### Servidores RADIUS y RadSec

Sin estado. No se requiere copia de seguridad.

#### Registros

Actualmente no se realiza copia de seguridad.

### 7. ¿Hay pruebas de restauración de copias de seguridad?

Sí.&#x20;

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


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.radiusaas.com/es/otro/faqs/security-and-privacy.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
