Skip to main content
Iru Identity es un servicio en la nube creado para ser el centro fiable de tu acceso. A continuación se explica cómo está construido el servicio y qué implica eso para la fiabilidad y el aislamiento.

​
Dos planos, separados por función

La plataforma se divide en dos servicios que se implementan de forma independiente y comparten un núcleo común organizado en capas. Mantener el aprovisionamiento privilegiado separado del tráfico de solicitudes de cada tenant reduce el alcance del impacto de cada uno.

​
Un núcleo organizado en capas y disciplinado

Ambos servicios están desarrollados en Go sobre una arquitectura en capas con una regla de dependencia unidireccional. Un nivel de plataforma aplicado por separado se sitúa por debajo de las capas de producto y se encarga del aislamiento de tenants y de las primitivas de identidad. Foundation se mantiene sin dependencias para las utilidades de infraestructura compartidas que no llevan contexto de tenant.
1

Plataforma

Aislamiento de tenants y columna vertebral de la identidad: acceso a la base de datos, sesiones, resolución de tenant y región, actor, registro y gestión de URL públicas. Este nivel se revisa y aplica por separado para que el aislamiento quede fuera del código de producto habitual.
2

Base

Utilidades de infraestructura compartidas que no dependen de nada por encima de ellas (por ejemplo, criptografía y rastreo). Los aspectos limitados al tenant residen en platform, no aquí.
3

Dominio

Lógica de negocio por entidad (usuarios, aplicaciones, políticas…). Depende de platform y foundation, no de usecase ni de REST.
4

Caso de uso

Coordina varios servicios de dominio para flujos complejos.
5

REST

Controladores HTTP y middleware, la única capa que se comunica a través de la red.
La organización en capas es una convención documentada y aplicada mediante revisión (respaldada por linting y la estructura de directorios), no un invariante garantizado por el compilador. Lo indicamos con honestidad en lugar de exagerar.
Las pruebas siguen la misma disciplina: la lógica de negocio pura se prueba con pruebas unitarias sin mocks, y el comportamiento se valida con pruebas de integración que se ejecutan contra una base de datos PostgreSQL real, de modo que las pruebas ejercitan la misma seguridad a nivel de fila y el mismo comportamiento de auditoría que se ejecutan en producción, no una aproximación simulada.

​
Alojamiento y refuerzo de la seguridad

Iru Identity se ejecuta en AWS, con una implementación con seguridad reforzada:

Contenedores reforzados

Los servicios se ejecutan en AWS Fargate sin privilegios de root, con un sistema de archivos raíz de solo lectura, no-new-privileges y todas las capacidades de Linux eliminadas.

Sin contraseñas de base de datos permanentes

La aplicación se conecta a PostgreSQL gestionado (Amazon RDS) mediante tokens de autenticación de IAM de corta duración. No hay ninguna contraseña de base de datos estática que pueda filtrarse.

Los secretos se mantienen fuera del código

Las credenciales y las claves de firma se inyectan desde un almacén de secretos gestionado en tiempo de ejecución, nunca se confirman en el repositorio ni se almacenan en la base de datos en texto sin cifrar.

Cadena de suministro analizada

Las imágenes de contenedor se analizan en busca de vulnerabilidades en el pipeline de CI antes de que puedan publicarse.
Los recursos estáticos se sirven a través de una CDN (Fastly), y los entornos de vista previa de corta duración para pruebas se ejecutan en Google Cloud Run.

​
Dos regiones, residencia de datos real

Iru Identity opera en dos regiones aisladas (Estados Unidos us-east-2 y Unión Europea eu-central-1), y la residencia se aplica en el código, no por convención.
  • Cada tenant está fijado a una región, que se almacena en el registro del tenant.
  • La capa de base de datos mantiene pools de conexiones independientes por región y enruta cada transacción según la región del tenant. Una solicitud cuya región no se puede resolver se rechaza. Nunca recurre silenciosamente a otra región.
  • Las operaciones de datos específicas de una región (como los datos iniciales) están controladas para que no puedan ejecutarse en la región equivocada.
El resultado: los datos de un tenant de la UE solo se leen y escriben en infraestructura de la UE. Consulta Aislamiento multitenant para ver cómo continúa el aislamiento dentro de cada base de datos regional.

​
Diseñado para mantenerse disponible y ser observable

Un endpoint de actividad sin dependencias permite al orquestador realizar sondeos sin tocar la base de datos ni la autenticación. Al apagarse, los servicios dejan de aceptar tráfico y vacían en orden el rastreo, los informes de errores y las conexiones de base de datos.
Los pools de conexiones están ajustados y limitados, hacen ping a su base de datos al iniciarse y fallan rápidamente si no está accesible, en lugar de atender solicitudes defectuosas.
El aprovisionamiento de cuentas en tus aplicaciones se ejecuta mediante un bucle de outbox y conciliación en procesos en segundo plano que tienen en cuenta las cancelaciones, de modo que los cambios dependientes se reintentan hasta que se completan correctamente en lugar de perderse.
Las solicitudes se rastrean con OpenTelemetry desde HTTP, pasando por el código de la aplicación, hasta la consulta SQL, y los registros estructurados se correlacionan por tenant e ID de rastreo. Los errores se capturan de forma centralizada con muestreo para equilibrar la fidelidad y el coste.
Los cambios de esquema están integrados, ordenados por versión y verificados mediante sumas de comprobación (una migración ya aplicada que se modifica es un fallo grave). Un comprobador permanente verifica que el diario de auditoría de cada tabla se mantiene sincronizado con su esquema activo.

​
Próximos pasos

Aislamiento multitenant

Cómo la seguridad a nivel de fila y la auditoría de solo anexión mantienen los datos de cada tenant separados y con constancia de cualquier manipulación.

Arquitectura de autenticación

Inicio de sesión resistente al phishing, solicitudes firmadas y cómo se establece la confianza de SSO.

Seguridad y privacidad

Las garantías que suman estos mecanismos.

Arquitectura del sistema

La visión orientada al cliente de cómo fluyen las identidades y el inicio de sesión.