Seguridad y confianza

Security is not a feature.
It is the foundation.

Tuurio ID se basa en autenticacion conforme a estandares, cifrado, aislamiento por tenant y operaciones listas para auditoria para equipos europeos.

PKCE

Flujo de autorizacion

AES-256

Encryption

ISO 27001

Datacenter Alemania

SLA 99,5%

Business/Enterprise

Arquitectura de seguridad

Cada capa esta protegida, desde infraestructura hasta autenticacion.

Infraestructura

STACKIT en Alemania con infraestructura de centro de datos certificada ISO 27001.

  • STACKIT, Alemania
  • Cloud SQL PostgreSQL, AES-256 at rest
  • TLS 1.3, WAF, proteccion DDoS
  • Spring Security 7 (Kotlin)
  • Copias de seguridad automatizadas, recuperacion point-in-time

Autenticacion y autorizacion

OAuth 2.0 Authorization Code + PKCE con opciones modernas de MFA.

  • OAuth 2.0 Authorization Code + PKCE (S256)
  • MFA: TOTP + WebAuthn/Passkeys (FIDO2)
  • Social Login: Google, Microsoft, Apple, GitHub
  • Enterprise SSO: SAML 2.0
  • Permisos y roles personalizados (JWT claims)
  • Restricciones de dominio de correo

Medidas de proteccion

Rate limiting basado en Redis y bloqueo progresivo en todos los endpoints de autenticacion.

  • Rate limiting basado en Redis (por endpoint)
  • Proteccion contra fuerza bruta con bloqueo progresivo
  • CAPTCHA activado ante actividad sospechosa
  • Proteccion CSRF/XSS (Spring Security)

Auditoria y forense

Cadenas de auditoria con deteccion de manipulaciones para operaciones de cumplimiento y respuesta a incidentes. El almacenamiento inmutable independiente sigue siendo un control operativo.

  • Cadenas de auditoria con deteccion de manipulaciones
  • 20+ tipos de eventos (login, MFA, admin, token)
  • Trazabilidad X-Correlation-ID
  • Notificaciones webhook
  • Exportacion de registros de auditoria (CSV/JSON)
Guia de trazabilidad

Disponibilidad

Operacion con SLA para aplicaciones criticas de negocio.

  • Monitorizacion continua de disponibilidad
  • SLA 99,5% (Business/Enterprise)
  • Copias de seguridad automaticas
  • Despliegues sin tiempo de inactividad

Cifrado y firma

AES-256 at rest, TLS 1.3 en transito, hashing Argon2id, firma RS256.

  • Cifrado AES-256 at rest
  • TLS 1.3 en transito
  • Hashing de contrasenas Argon2id (64 MB, OWASP)
  • Firma JWT RS256, rotacion de JWK por inquilino

Seguridad MCP

Los asistentes de IA se conectan mediante OAuth y reciben solo acceso vinculado al tenant y al recurso.

  • Clientes públicos con Authorization Code + PKCE
  • Scopes separados mcp:connect y mcp:write
  • Los permisos efectivos del usuario siguen siendo determinantes
  • Control de producción independiente para herramientas de escritura
Modelo de seguridad MCP

Passkey-only: finalidad, conservación y retorno a la contraseña

Complemento preparado de la política operativa, 8 de octubre de 2026. Describe el contrato previsto para el despliegue aprobado; no afirma que las funciones restantes estén disponibles ni concede una aprobación jurídica, de publicación o de activación.

Con Passkey-only, los verificadores de contraseña nativos e importados existentes se bloquean y conservan exclusivamente para un posible retorno a la contraseña. Permanecen en el almacenamiento original; no se crea un archivo adicional. La conservación no es otro método de recuperación ni permite un acceso alternativo solo con contraseña.

La activación original registrada inicia un periodo de 30 días, exactamente 720 horas. Un proceso automático limitado elimina los antiguos verificadores del almacenamiento activo desde el vencimiento solo mientras la misma activación siga habilitada. Guardar o reintentar una política habilitada no prolonga el periodo. Sin una prueba del inicio de una activación anterior, su antigüedad sigue siendo desconocida; la fecha del despliegue no crea un vencimiento inventado.

Desactivar Passkey-only antes de la eliminación permite volver a utilizar los verificadores originales conservados con las comprobaciones normales de la cuenta y la autenticación. Una activación real posterior inicia otro periodo. La desactivación nunca restaura contraseñas eliminadas, sesiones ni tokens revocados. La eliminación cierra el retorno a la contraseña antigua; las passkeys y la recuperación configurada permanecen.

Con un passkey actualmente utilizable y una recuperación configurada, la persona afectada puede solicitar en cualquier momento la eliminación de su propia contraseña antigua dentro de este régimen de conservación. Tras desactivar la política debe demostrarse que las pruebas sin cambios eran anteriores a la activación original; se rechazan las nuevas contraseñas creadas después de la desactivación y los historiales no demostrados. Un administrador autorizado del tenant puede eliminar deliberadamente las pruebas conservadas antes de tiempo mientras passkey-only está activo, con auditoría. El efecto irreversible sobre la vuelta al acceso con contraseña se explica de antemano y requiere confirmación explícita. Este proceso no elimina silenciosamente el único factor de acceso actual fuera de este régimen.

Las cuentas nuevas creadas mediante un flujo Passkey-only no reciben contraseña. Los tenants nuevos siguen comenzando con Passkey-only desactivado; su activación es una decisión expresa tras comprobar la preparación de las cuentas.

Los registros de eliminación separados y de acceso restringido contienen identificadores de cuenta y tenant, identificadores de comparación de las pruebas retiradas y los metadatos originales de activación y eliminación, no pruebas de contraseña reutilizables. Impiden volver a aceptar material retirado incluso después de eliminar la cuenta. Son datos personales de seguridad, no datos anónimos. La implementación técnica preparada no incluye caducidad automática ni proceso de eliminación para estos registros. El periodo de 720 horas de las antiguas pruebas de contraseña no promete que estos registros se eliminen al mismo tiempo; su finalidad y conservación deben evaluarse por separado antes del lanzamiento.

Eliminar filas activas no borra de inmediato las copias de las copias de seguridad cifradas existentes; estas siguen la política real de conservación de copias. Una restauración permanece aislada de la autenticación y las escrituras hasta reconciliar los registros de eliminación, la activación y las revocaciones. El proceso de limpieza por sí solo no hace segura una copia antigua completa que descarta el historial de eliminaciones. No debe reactivar silenciosamente verificadores, sesiones ni tokens de renovación eliminados o revocados.

Las reglas previstas terminan todas las demás sesiones y todos los demás tokens de renovación del usuario tras configurar la recuperación y todas las sesiones y los tokens no passkey del tenant al activar la política. La desactivación no los restablece. Solo Tuurio realiza un rollback de la aplicación: confirmar la desactivación, detener las escrituras afectadas, terminar las sesiones seleccionadas y después restaurar la imagen anterior registrada. Restaurar una copia de seguridad y revertir una imagen de aplicación son operaciones diferentes.

Arquitectura multi-tenant

Aislamiento por tenant en acceso a datos, configuracion y manejo del issuer.

Aislamiento de inquilinos

Cada consulta SQL esta limitada al inquilino. El acceso entre inquilinos esta arquitectonicamente excluido.

  • Aislamiento a nivel de BD via Hibernate Filters
  • Cada consulta limitada a tenant_id
  • Acceso entre inquilinos arquitectonicamente prevenido
  • Todos los datos de inquilinos en la UE (Alemania)

Configuracion especifica por inquilino

Cada inquilino tiene su propio subdominio, marca y claves criptograficas.

  • Subdominio dedicado por inquilino
  • Fuente JWK especifica por inquilino y rotacion de claves
  • Marca y configuracion individual
  • Modelo de permisos y roles aislado

Seguridad para desarrolladores

Integracion segura por defecto para tu aplicacion.

Validacion de tokens

JWTs firmados con RS256 con endpoint JWKS publico para validacion offline.

  • Endpoint JWKS para validacion criptografica
  • Algoritmo de firma RS256
  • Tiempo de vida y refresh de tokens configurable
  • PKCE obligatorio (sin flujo implicito)

Seguridad de integracion

Validacion estricta para flujos OAuth seguros de fabrica.

  • Coincidencia estricta de redirect URI
  • Validacion de parametro state
  • OIDC Discovery estandar
  • Sin vendor lock-in (protocolos estandar)

Respuesta a incidentes

Procesos transparentes para incidentes de seguridad y reportes de vulnerabilidades.

Contacto de seguridad y divulgacion

Nos tomamos las vulnerabilidades en serio. Reporte problemas de forma responsable.

  • Contacto de seguridad: security@tuurio.com
  • Politica de divulgacion responsable
  • Respuesta a incidentes en 24 horas
  • Comunicacion de estado transparente

Compliance y estandares

Cumplimiento que realmente importa para equipos europeos.

DSGVO

Operacion orientada a GDPR

Hosting UE, terminos de tratamiento configurables y audit trails apoyan modelos operativos orientados a GDPR.

NIS2

Orientado a NIS2 (Art. 21)

MFA, registros de auditoria y trazabilidad forense apoyan las obligaciones de evidencia NIS2.

ISO

Centro de datos ISO 27001

Operacion en Alemania con infraestructura de centro de datos certificada.

MoR

Modelo Merchant-of-Record

Facturacion estructurada con configuracion fiscal limpia para uso internacional.

Estandares tecnologicos

OAuth 2.0 OpenID Connect WebAuthn / FIDO2 SAML 2.0 Spring Security 7 Kotlin PostgreSQL Redis PKCE (S256) RS256 / JWKS Argon2id AES-256 TLS 1.3 REST API Webhooks

5 idiomas con deteccion automatica

Deutsch (DE) English (EN) Francais (FR) Italiano (IT) Espanol (ES)

Seguridad en la que puedes confiar.

PKCE, passkeys, tracing listo para auditoria y hosting UE. Empieza con controles que puedes verificar.