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, garantizando la disponibilidad de las aplicaciones incluso durante ataques DDoS. 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.).

  • 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: Actúa como un router central que permite interconectar la VPC de Anjana con redes del cliente, ya sea mediante VPN, VPC attachment o peering entre Transit Gateways.
  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:

  • Conexión mediante Transit Gateway, usando una de las siguientes opciones:

    • VPN hacia el TGW

    • VPC attachment (AWS-to-AWS)

    • Peering entre Transit Gateways

  • 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 proporciona una comunicación unidireccional desde Anjana hacia el entorno del cliente, 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 Interface Endpoint en la VPC del cliente

    • Exposición del servicio mediante VPC Endpoint Service por parte de Anjana

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

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

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

  • 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 real 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 real, 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 end-to-end

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

Tabla comparativa

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