SaaS Security Model

Complete SaaS Security Map

Security Model

Legend:

• Internal traffic: --->

• Private traffic: --->

• Public traffic: --->

• Hybrid mode: - - - -

Security Model Details

Starting from the highest and most distant part of the infrastructure down to the Anjana server itself, the security aspects that make up the model are detailed below:

• AWS Shield Standard: Provides automatic protection against DDoS (Distributed Denial of Service) attacks for all applications hosted on AWS. This includes automatic mitigation of network- and application-layer attacks, significantly reducing the impact of DDoS attacks on application availability. It protects the AWS services associated with Anjana:

  • Route 53: responsible for the domain names associated with the server

  • Load balancer: necessary in a high-availability environment
    

• AWS WAF: Provides protection against common attacks such as:

  • Web application attack protection: Detects and blocks common attacks such as SQL injection, XSS (cross-site scripting), and RFI (remote file inclusion).

  • Traffic filtering: Monitors and filters HTTP/HTTPS traffic in real time, ensuring that only legitimate traffic reaches our applications.

  • Bot control: Includes a set of rules to detect and mitigate bot operations.

• Private subnets: Anjana's instances are located in private subnets with no internet access, exposing no point beyond the strictly necessary ports, so they can only be reached through the load balancer positioned with all the AWS security services described above.
  

• Security Groups: Allow controlling inbound and outbound network traffic for EC2 instances. We filter access ports here. This limits access to EC2 instances to only the necessary connections, reducing the attack surface and protecting your applications from unauthorized intrusions.
  

• Web server with whitelist: The web server can be configured with whitelists per Virtual Host (vhost). This allows only traffic from authorized domains or IP addresses, restricting unwanted access to the web server.
  

• Zeus: The authorization and provider management microservice provides a robust, flexible authentication and authorization layer compatible with multiple well-known, industry-standard services such as a database, LDAP, AD, AWS Cognito, Azure EntraID, among others…

Complementary Security

As complementary additions to the already established security model, or as an alternative to the whitelist (for very specific, well-reviewed use cases), the following connections are proposed:

• NO AWS / ON-PREMISE - VPN site to site: Allows securely interconnecting the customer's network with the Anjana environment.
  This model enables bidirectional communication between both infrastructures, allowing private access to the Anjana UI/API and the integration of plugins deployed in the customer's infrastructure, without needing to expose public services.
  

  • Detail and requirements:

    • Customer Gateway (CGW): IPsec-compatible firewall or router on the customer side

    • Static public IP on the customer end

    • Definition of the network ranges to interconnect

    • Encryption type and negotiation parameters (IKEv1/2, PSK, etc.).

    • Dual IPsec tunnel to the two AWS endpoints for high availability (active/active or active/passive via BGP; recommended over static routes for automatic failover).

  • Ideal for:

    • On-premise customers or those without AWS

    • Legacy or multisite infrastructures

    • Organizations with perimeter control inspections and corporate firewalls
      

• STANDARD - AWS Transit Gateway: Each customer has their own Transit Gateway, exclusive to their tenant and not shared with other customers, which interconnects via peering with Anjana's Transit Gateway, the latter acting as the central router of the SaaS infrastructure.
  This model enables bidirectional and private connectivity, integrating the customer's networks as if they were part of the SaaS network itself, and facilitating more scalable and segmented architectures when multiple environments or advanced network needs exist.
  

  Detail and requirements:

  • Deployment of the customer's own Transit Gateway in their account

  • Peering between the customer's TGW and Anjana's TGW (exclusive per tenant, with no cross-visibility between customers)

  • 1:1 Peering (TGW to TGW): Anjana does not support connecting more than one customer Transit Gateway to Anjana's TGW; scenarios requiring multiple customer TGWs involve additional scope and costs.

  • Definition and acceptance of the network ranges to interconnect

  • Configuration and management of route tables and propagation

  • Traffic only flows between networks associated with the TGW (no transit to third parties)

  • Ideal for:

    • Customers with hybrid infrastructures (on-prem + cloud)

    • Organizations with several networks internal or VPCs

    • Environments that require segmentation and centralized traffic control

    • Cases with complex or multi-VPC network architectures
      

• PREMIUM A - AWS Private Link: Allows communicating privately with plugins or technologies deployed in the customer's infrastructure, without exposing public endpoints or establishing network-level connectivity.

  This model protects exclusively the Anjana → customer direction. Anjana's SaaS front end (UI/API) is not part of this mechanism and remains exposed to the Internet, protected by the standard controls (Shield, WAF, load balancer). Communication toward the customer is unidirectional, fully isolated, and based on AWS's internal backbone, applying a Zero Trust approach at L4.

  • Detail and requirements:

    • Customer with a VPC in AWS

    • Creation of an Endpoint Service in the customer's VPC, exposing the plugins or resources

    • Creation of an Interface Endpoint in Anjana's VPC pointing to the customer's Endpoint Service

    • Use of a Network Load Balancer as the service's entry point

    • The customer exposes all their resources through a single NLB with one listener per resource, so Anjana only requires a single Interface Endpoint per customer to access all of them

    • Requires no routes, shared CIDRs, or network propagation

    • Traffic is neither transitable nor routable outside the exposed service

    • Encryption in transit for communication with the customer's plugins/sources depends on the exposed service implementing it natively (e.g. application-layer TLS, Oracle Native Network Encryption/TCPS); PrivateLink isolates traffic at the network level but does not encrypt it by itself.

  • Ideal for:

    • AWS-native customers

    • Integrations where the plugins reside in the customer's network

    • Environments with strict isolation and security requirements (ENS / ISO27001 / SOC2)

    • Organizations that prioritize minimal operational maintenance

    • Scenarios requiring L4-level Zero Trust without network complexity
      

• PREMIUM B - AWS Private Link: The PrivateLink Plugins + SaaS model extends the private connectivity approach to cover both Anjana's SaaS front end (UI/API) and communication with plugins deployed in the customer's infrastructure.
  Connectivity is established through two independent PrivateLinks, providing full isolation, private communication over AWS's internal backbone, and an L4-level Zero Trust architecture, for both the SaaS front end and the customer's plugins, with no exposure to the Internet or network-level connectivity.
  

  • Detail and requirements:

    • Customer with a VPC in AWS

    • Exposure of Anjana's UI/API via a VPC Endpoint Service, backed by a Network Load Balancer (NLB)

    • NLB configuration with the necessary listeners according to the services or technologies to connect on the customer side

    • Exposed services must listen on the ports defined in the NLB listeners

    • Communication must meet TLS/SSL security requirements, using certificates compatible with https://wiki.anjanadata.com/es/seguridad/25.2/mecanica-de-certificados

    • The Endpoint Service defines and controls the authorized AWS accounts, requiring explicit acceptance of the connection if applicable

    • Creation of Interface VPC Endpoints in the customer's VPC pointing to Anjana's Endpoint Service

    • Configuration of Security Groups associated with the Interface Endpoints according to the required ports and services

    • Requires no routes, shared CIDRs, or network propagation

    • Each PrivateLink is independent, non-transitable, and non-routable

  • Ideal for:

    • Large enterprise customers

    • Environments with strict confidentiality and isolation requirements

    • Architectures requiring end-to-end L4-level Zero Trust

    • Scenarios where traffic outside the AWS backbone is not allowed

Comparison table

Responsibilities by connection model

AWS recommendations:

• 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

Related documentation

For SaaS packages, infrastructure profiles, operating regions, recovery objectives (RPO/RTO), and general service responsibilities, see https://wiki.anjanadata.com/es/solucion-tecnica/26.1/especificacion-tecnica-del-servicio-saas-de-anjana-data-platform.