Especificación técnica del servicio SaaS de Anjana Data Platform

1 Propósito y alcance

Este documento describe la especificación técnica del servicio Anjana Data Platform SaaS, incluyendo:

• Este documento describe la especificación técnica del servicio Anjana Data Platform SaaS ofrecido por Anjana Data SL, incluyendo:

• Perfiles de infraestructura (PRE, Base, Standard, Balanced) y sus prestaciones.

• Paquetes SaaS ofrecidos y entornos incluidos (PRO/PRE).

• Controles de seguridad incluidos por defecto (baseline) y principios de aislamiento.

• Opciones adicionales de conectividad/seguridad.

• Backups, retención y objetivos de recuperación (RPO/RTO).

• Regiones habituales de operación.

• Responsabilidades del proveedor y del cliente.

Este documento tiene como objetivo dar transparencia y confianza al cliente sobre la arquitectura y seguridad del servicio sin exponer detalles que puedan comprometer la postura de seguridad de Anjana Data SL.

2 Definiciones

• Instancia: despliegue completo e independiente de Anjana Data Platform (componentes, configuración, endpoints y recursos asociados).

• Entorno: clasificación operativa (PRO, PRE, POC, DEV, TEST). En SaaS, normalmente cada entorno se implementa como una instancia independiente.

• PRO: entorno productivo (infraestructura dimensionada para producción).

• PRE: entorno no productivo (validación/preproducción).

3 Arquitectura de referencia del servicio SaaS

3.1 Componentes principales (alto nivel)

Anjana Data Platform SaaS se despliega sobre infraestructura cloud con un modelo de segmentación “por capas”:

• Capa de entrada controlada: el acceso a UI/API se centraliza a través de un punto de entrada gestionado (balanceador cuando aplica) protegido por controles de seguridad (WAF y mitigación DDoS).

• Capa de aplicación en red privada: los componentes de la plataforma operan en subnets privadas, no expuestos directamente a Internet.

• Capa de datos gestionada: almacenamiento de objetos (S3) y base de datos (DB gestionada) dimensionados según el perfil de infraestructura.

• Capa de operación: backups periódicos y mecanismos de recuperación con objetivos RPO/RTO definidos (sección 9).

4 Paquetes SaaS y entornos incluidos

4.1 Paquetes ofrecidos y mapeo a perfiles de infraestructura

Los paquetes SaaS se componen de una o dos instancias (entornos), cada una desplegada con un perfil de infraestructura:

5 Perfiles de infraestructura (PRE / Base / Standard / Balanced)

5.1 Prestaciones por perfil

Los perfiles de infraestructura definen el dimensionamiento técnico y capacidades de alta disponibilidad, así como parámetros de backup/retención.

5.2 Principios de dimensionamiento

• PRE: entorno orientado a validación y preproducción.

• Base: entorno no productivo robusto o entorno productivo de baja carga, según diseño del paquete.

• Standard: entorno productivo con separación de responsabilidades (nodos) y dimensionamiento para cargas superiores.

• Balanced: entorno productivo con capacidad y redundancia incrementadas (replicación/LB según tabla).

6 Seguridad incluida por defecto (baseline)

Todos los despliegues SaaS incorporan un conjunto de controles de seguridad base orientados a proteger disponibilidad, reducir superficie de exposición y fortalecer el control de acceso.

6.1 Protección ante ataques y control del tráfico

• Mitigación DDoS (AWS Shield Standard): protección automática para ataques de capa de red y aplicación, orientada a preservar disponibilidad.

• Filtrado y protección de aplicaciones web (AWS WAF): reglas para mitigar ataques comunes (p.ej., inyección y scripting) y control de bots, aplicadas al tráfico HTTP/HTTPS.

• Gestión de dominios (Route 53): gestión del enrutamiento DNS del servicio.

Objetivo: asegurar que el tráfico entrante pase por una capa de inspección y mitigación antes de llegar a la aplicación.

6.2 Aislamiento de red y mínima exposición

• Subnets privadas: los componentes de la plataforma se despliegan en red privada, sin exposición directa a Internet.

• Security Groups / control de tráfico: control estricto del tráfico entrante/saliente, habilitando únicamente lo necesario para el servicio.

• Entrada centralizada: el acceso externo se concentra en un punto de entrada controlado (balanceador cuando aplica), donde se aplican los controles anteriores.

Objetivo: reducir superficie de ataque y evitar exposición innecesaria de componentes internos.

6.3 Control de acceso e integraciones de identidad

• Zeus (autenticación y autorización): capa de autenticación/autorización compatible con múltiples proveedores de identidad (p.ej., LDAP, AD, proveedores cloud y otros).

Objetivo: proporcionar control de acceso robusto y flexible, alineado con integraciones corporativas del cliente (según paquete contratado en el Modelo de Licenciamiento).

6.4 Whitelisting a nivel de servidor web (cuando aplica)

• Servidor web con whitelist: posibilidad de restringir acceso por dominios/IP autorizados (configurable según necesidades del cliente y su paquete de conectividad).

Objetivo: reforzar el principio de “permitir solo lo necesario”.

7 Conectividad y seguridad adicional (paquetes opcionales)

7.1 NO AWS / ON-PREMISE — VPN Site-to-Site

• Orientado a clientes sin AWS o con arquitectura on-premise/multicloud.

• Conectividad segura tipo VPN entre redes.

7.2 STANDARD — AWS Transit Gateway

• Orientado a arquitecturas híbridas o multi-red con integración centralizada.

• Facilita conectividad privada bidireccional en entornos AWS/híbridos.

7.3 PREMIUM A — AWS PrivateLink (enfoque Zero Trust para conectividad con plugins)

• Opción orientada a escenarios mixtos, donde la conectividad mediante PrivateLink se utiliza para necesidades específicas (por ejemplo, conectividad con plugins o integraciones), manteniendo cuando aplique el acceso UI/API conforme al baseline del servicio (WAF/Shield/whitelist y controles asociados).

• Facilita un modelo “Zero Trust” a nivel de servicio para componentes concretos sin exigir aislamiento total del frontal.

7.4 PREMIUM B — AWS PrivateLink (UI/API + plugins, sin salida a Internet)

• En PREMIUM B, el acceso a la UI/API del servicio se realiza exclusivamente mediante AWS PrivateLink, y la arquitectura se diseña para que la instancia SaaS quede sin salida a Internet (no se expone UI/API a Internet público). Esta opción proporciona el máximo nivel de aislamiento de acceso, al concentrar la comunicación en conectividad privada a nivel de servicio.

Comparativa resumen de los distintos paquetes de seguridad adicional

8 Regiones habituales de operación

El servicio SaaS se ofrece de forma estándar en las siguientes regiones habituales de operación:

• Europe (Frankfurt) — eu-central-1

• Europe (Spain) — eu-south-2

• US East (N. Virginia) — us-east-1

• US West (N. California) — us-west-1

• Europe (Ireland) — eu-west-1 (only WP)

Cuando el cliente solicite una región distinta, podrá aplicarse un add-on de “región fuera de estándar” conforme al Modelo de Licenciamiento. En caso de que la región pase a considerarse habitual por adopción adicional, aplicará la política de cese de cómputo del coste definida en dicho modelo.

9 Backups, retención y recuperación (RPO/RTO)

9.1 Backups y retención

Los backups del servicio se realizan con la frecuencia y retención definidas por el perfil de infraestructura (ver tabla 5.1-A).

9.2 Objetivos de recuperación

• RPO (Recovery Point Objective): 24 horas.

• RTO (Recovery Time Objective): 24 horas.

Los objetivos anteriores aplican al servicio estándar. Requisitos superiores (RPO/RTO menor, retención extendida u obligaciones específicas) se tratan como condición particular y/o add-on, sujeto a evaluación técnica.

10 Operación del servicio (alto nivel)

Anjana Data SL presta operación del servicio SaaS conforme al alcance definido en el Modelo de Licenciamiento (Servicio gestionado), incluyendo:

• Operación y mantenimiento del servicio.

• Actualizaciones planificadas.

• Monitorización operativa.

11 Responsabilidades del cliente (SaaS)

El cliente es responsable de:

• Gestionar el uso del servicio conforme a su licenciamiento (objetos gobernados, integraciones, plugins, etc.).

• Mantener contacto administrativo para notificaciones operativas.

• En caso de contratar conectividad/seguridad adicional: cumplir prerequisitos técnicos bajo su control (p.ej. configuración en su red/VPC o componentes equivalentes).

• Proporcionar la información necesaria para configuración (dominios, certificados si aplica, sistemas de identidad) según el alcance contratado.