Modelo de seguridad SaaS

Mapa completo de seguridad SaaS

Modelo de seguridad

Leyenda:

• Tráfico interno: --->

• Tráfico privado: --->

• Tráfico público: --->

• Modalidad Híbrida: - - - -

Detalles del modelo de seguridad

Comenzando por la parte más alta y más alejada de la infraestructura hasta el propio servidor de Anjana se detallan los aspectos de seguridad que componen el modelo:

• AWS Shield Standard: Proporciona protección automática contra ataques DDoS (Denegación de Servicio Distribuido) para todas las aplicaciones alojadas en AWS. Esto incluye mitigación automática de ataques de capa de red y aplicación, reduciendo significativamente el impacto de los ataques DDoS sobre la disponibilidad de las aplicaciones. Protege los servicios de AWS asociados a Anjana:

  • Route 53: encargado de los nombres de dominio asociados al servidor

  • Balanceador de carga: necesario en un entorno en alta disponibilidad
    

• AWS WAF: Proporciona protección contra ataques comunes como:

  • Protección contra ataques de aplicaciones web: Detecta y bloquea ataques comunes como SQL injection, XSS (cross-site scripting), y RFI (remote file inclusion).

  • Filtrado de tráfico: Monitorea y filtra el tráfico HTTP/HTTPS en tiempo real, asegurando que solo el tráfico legítimo alcance nuestras aplicaciones.

  • Control de bots: Cuenta con una serie de reglas para detectar y mitigar las operaciones de bots.

• Subnets privadas: Las instancias de Anjana se encuentran en subnets privadas sin acceso a internet, no exponiendo ningún punto fuera de los puertos exclusivamente necesarios, por lo que únicamente son alcanzables mediante el balanceador de carga posicionado con todas los servicios de seguridad de AWS comentados.
  

• Security Groups: Permiten controlar el tráfico de red entrante y saliente para las instancias de EC2. Filtramos los puertos de acceso aquí. Esto limita el acceso a las instancias de EC2 solo a las conexiones necesarias, reduciendo la superficie de ataque y protegiendo tus aplicaciones de intrusiones no autorizadas.
  

• Apache2 web server con whitelist: El servidor web puede configurarse con listas blancas por Virtual Host (vhost). Esto permite permitir solo el tráfico desde dominios o direcciones IP autorizadas, restringiendo el acceso no deseado al servidor web.
  

• Zeus: El microservicio de autorización y gestión de proveedores provee una capa robusta de autenticación y autorización flexible compatible con múltiples servicios conocidos y bien asentados en la industria como una BBDD, LDAP, AD, AWS Cognito, Azure EntraID, entre otros…

Seguridad complementaria

Como añadidos complementarios al modelo ya establecido de seguridad o alternativa a la whitelist (bajo casos de uso muy concretos y bien revisados) se proponen las siguientes conexiones:

• NO AWS / ON-PREMISE - VPN site to site: Permite interconectar de forma segura la red del cliente con el entorno de Anjana.
  Este modelo habilita comunicación bidireccional entre ambas infraestructuras, permitiendo el acceso privado a la UI/API de Anjana y la integración de plugins desplegados en la infraestructura del cliente, sin necesidad de exponer servicios públicos.

  

  • Detalle y requisitos:

    • Customer Gateway (CGW): Firewall o router compatible con IPsec en el lado del cliente

    • IP pública estática en el extremo del cliente

    • Definición de los rangos de red a interconectar

    • Tipo de cifrado y parámetros de negociación (IKEv1/2, PSK, etc.).

    • Doble túnel IPsec hacia los dos endpoints de AWS para alta disponibilidad (activo/activo o activo/pasivo mediante BGP; recomendado sobre rutas estáticas para failover automático).

  • Ideal para:

    • Clientes on-premise o sin AWS

    • Infraestructuras legacy o multisite

    • Organizaciones con inspecciones de control perimetral y firewalls corporativos
      

• STANDARD - AWS Transit Gateway: Cada cliente dispone de su propio Transit Gateway, exclusivo de su tenant y no compartido con otros clientes, que se interconecta mediante peering con el Transit Gateway de Anjana, actuando este último como router central de la infraestructura SaaS.
  Este modelo habilita una conectividad bidireccional y privada, integrando las redes del cliente como si formaran parte de la propia red del SaaS, y facilitando arquitecturas más escalables y segmentadas cuando existen múltiples entornos o necesidades de red avanzadas.

  

  Detalle y requisitos:

  • Despliegue de un Transit Gateway propio en la cuenta del cliente

  • Peering entre el TGW del cliente y el TGW de Anjana (exclusivo por tenant, sin visibilidad cruzada entre clientes)

  • Peering 1:1 (TGW a TGW): Anjana no contempla la conexión de más de un Transit Gateway de cliente al TGW de Anjana; escenarios que requieran múltiples TGWs del cliente conllevan alcance y costes adicionales.

  • Definición y aceptación de los rangos de red a interconectar

  • Configuración y gestión de tablas de rutas y propagación

  • El tráfico solo fluye entre redes asociadas al TGW (sin tránsito a terceros)

  • Ideal para:

    • Clientes con infraestructuras híbridas (on-prem + cloud)

    • Organizaciones con varias redes internas o VPCs

    • Entornos que requieren segmentación y control centralizado del tráfico

    • Casos con arquitecturas de red complejas o multi-VPC
      

• PREMIUM A - AWS Private Link: Permite comunicarse de forma privada con plugins o tecnologías desplegadas en la infraestructura del cliente, sin exponer endpoints públicos ni establecer conectividad a nivel de red.

  Este modelo protege exclusivamente el sentido Anjana → cliente. El frontal SaaS de Anjana (UI/API) no forma parte de este mecanismo y permanece expuesto a Internet, protegido mediante los controles estándar (Shield, WAF, balanceador). La comunicación hacia el cliente es unidireccional, completamente aislada y basada en el backbone interno de AWS, aplicando un enfoque Zero Trust a nivel L4.

  

  • Detalle y requisitos:

    • Cliente con VPC en AWS

    • Creación de un Endpoint Service en la VPC del cliente, exponiendo los plugins o recursos

    • Creación de un Interface Endpoint en la VPC de Anjana apuntando al Endpoint Service del cliente

    • Uso de Network Load Balancer como punto de entrada del servicio

    • Todos los recursos de cliente mediante un único NLB con un listener por recurso, de forma que Anjana solo requiere un único Interface Endpoint por cliente para acceder a todos ellos

    • No requiere rutas, CIDR compartidos ni propagación de red

    • El tráfico no es transitable ni enrutable fuera del servicio expuesto

    • El cifrado en tránsito de la comunicación con los plugins/fuentes del cliente depende de que el servicio expuesto lo implemente de forma nativa (p. ej. TLS aplicativo, Oracle Native Network Encryption/TCPS); PrivateLink aísla el tráfico a nivel de red pero no lo cifra por sí mismo.

  • Ideal para:

    • Clientes AWS-native

    • Integraciones donde los plugins residen en la red del cliente

    • Entornos con requisitos estrictos de aislamiento y seguridad (ENS / ISO27001 / SOC2)

    • Organizaciones que priorizan mínimo mantenimiento operativo

    • Escenarios con necesidad de Zero Trust a nivel L4 sin complejidad de red
      

• PREMIUM B - AWS Private Link: El modelo PrivateLink Plugins + SaaS extiende el enfoque de conectividad privada para cubrir tanto el frontal del SaaS de Anjana (UI/API) como la comunicación con plugins desplegados en la infraestructura del cliente.
  La conectividad se establece mediante dos PrivateLinks independientes, proporcionando aislamiento completo, comunicación privada sobre el backbone interno de AWS y una arquitectura Zero Trust a nivel L4, tanto para el frontal SaaS como para los plugins del cliente, sin exposición a Internet ni conectividad a nivel de red.

  

  • Detalle y requisitos:

    • Cliente con VPC en AWS

    • Exposición de la UI/API de Anjana mediante VPC Endpoint Service, soportado sobre Network Load Balancer (NLB)

    • Configuración del NLB con los listeners necesarios según los servicios o tecnologías a conectar en la parte del cliente

    • Los servicios expuestos deben escuchar en los puertos definidos en los listeners del NLB

    • La comunicación debe cumplir los requisitos de seguridad TLS/SSL, utilizando certificados compatibles con https://wiki.anjanadata.com/es/seguridad/25.2/mecanica-de-certificados

    • El Endpoint Service define y controla las cuentas AWS autorizadas, requiriendo aceptación explícita de la conexión si aplica

    • Creación de Interface VPC Endpoints en la VPC del cliente apuntando al Endpoint Service de Anjana

    • Configuración de Security Groups asociados a los Interface Endpoints según los puertos y servicios requeridos

    • No requiere rutas, CIDR compartidos ni propagación de red

    • Cada PrivateLink es independiente, no transitable y no enrutable

  • Ideal para:

    • Grandes clientes enterprise

    • Entornos con requisitos estrictos de confidencialidad y aislamiento

    • Arquitecturas que exigen Zero Trust a nivel L4 de extremo a extremo

    • Escenarios donde no se permite tráfico fuera del backbone AWS

Tabla comparativa

Responsabilidades por modelo de conexión

Recomendaciones de AWS:

• Architecting Successful SaaS: Interacting with Your SaaS Customer's Cloud Accounts | AWS Partner Network (APN) Blog.

• Amazon VPC-to-Amazon VPC connectivity options - Amazon Virtual Private Cloud Connectivity Options

Documentación relacionada

Para paquetes SaaS, perfiles de infraestructura, regiones de operación, objetivos de recuperación (RPO/RTO) y responsabilidades generales del servicio, ver la Especificación técnica del servicio SaaS de Anjana Data Platform.