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 point and furthest from the infrastructure down to the Anjana server itself, the security aspects that make up the model are detailed:

• 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: Has a set of rules to detect and mitigate bot operations.

• Private subnets: Anjana instances are in private subnets without internet access, not exposing any point outside the exclusively necessary ports, so they are only reachable through the load balancer positioned with all the AWS security services mentioned.
  

• Security Groups: Allow controlling incoming and outgoing network traffic for EC2 instances. Access ports are filtered here. This limits access to EC2 instances only to necessary connections, reducing the attack surface and protecting your applications from unauthorized intrusions.
  

• Apache2 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 authentication layer and flexible authorization compatible with multiple well-known and well-established industry services such as a DB, 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 (in very specific and well-reviewed use cases) the following connections are proposed:

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

  

  • Details and requirements:

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

    • Static public IP on the client side

    • Definition of the network ranges to interconnect

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

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

  • Ideal for:

    • On-premise or non-AWS clients

    • Legacy or multisite infrastructures

    • Organizations with perimeter control inspections and corporate firewalls
      

• STANDARD - AWS Transit Gateway: Each client has its own Transit Gateway, dedicated to their tenant and not shared with other clients, which connects via peering with Anjana's Transit Gateway, with the latter acting as the central router of the SaaS infrastructure.
  This model enables bidirectional and private connectivity, integrating the client's networks as if they were part of the SaaS's own network, and facilitating more scalable and segmented architectures when there are multiple environments or advanced network requirements.

  

  Details and requirements:

  • Deployment of a dedicated Transit Gateway in the client's account

  • Peering between the client's TGW and Anjana's TGW (dedicated per tenant, with no cross-visibility between clients)

  • 1:1 peering (TGW to TGW): Anjana does not support connecting more than one client Transit Gateway to Anjana's TGW; scenarios requiring multiple client 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:

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

    • Organizations with multiple internal networks or VPCs

    • Environments requiring segmentation and centralized control of traffic

    • Cases with complex or multi-VPC network architectures
      

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

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

  

  • Details and requirements:

    • Client with VPC in AWS

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

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

    • Use of Network Load Balancer as the service entry point

    • The client exposes all resources through a single multi-port NLB (one listener per resource), so Anjana only requires a single Interface Endpoint per client to access all of them

    • Does not require routes, shared CIDRs, or network propagation

    • Traffic is not transitable or routable outside the exposed service

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

  • Ideal for:

    • AWS-native clients

    • Integrations where plugins reside in the client's network

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

    • Organizations that prioritize minimum operational maintenance

    • Scenarios with a need for Zero Trust at L4 without network complexity
      

• PREMIUM B - AWS Private Link: The PrivateLink Plugins + SaaS model extends the private connectivity approach to cover both the frontend of Anjana's SaaS (UI/API) and communication with plugins deployed in the client's infrastructure.
  Connectivity is established via two independent PrivateLinks, providing complete isolation, private communication over AWS's internal backbone, and a Zero Trust architecture at L4, covering both the SaaS frontend and the client's plugins, with no internet exposure or network-level connectivity.

  

  • Details and requirements:

    • Client with VPC in AWS

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

    • Configuration of the NLB with the necessary listeners according to the services or technologies to connect on the client's 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 client's VPC pointing to Anjana's Endpoint Service

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

    • Does not require routes, shared CIDRs, or network propagation

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

  • Ideal for:

    • Large enterprise clients

    • Environments with strict confidentiality and isolation requirements

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

    • Scenarios where traffic outside the AWS backbone is not permitted

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 the Technical Specification of the Anjana Data Platform SaaS Service.