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, ensuring application availability even during DDoS attacks. 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.).

  • Ideal for:

    • On-premise or non-AWS clients

    • Legacy or multisite infrastructures

    • Organizations with perimeter control inspections and corporate firewalls
      

• STANDARD - AWS Transit Gateway: Acts as a central router that allows interconnecting Anjana's VPC with the client's networks, either via VPN, VPC attachment, or peering between Transit Gateways.
  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:

  • Connection via Transit Gateway, using one of the following options:

    • VPN to the TGW

    • VPC attachment (AWS-to-AWS)

    • Peering between Transit Gateways

  • 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 provides unidirectional communication from Anjana to the client's environment, 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 Interface Endpoint in the client's VPC

    • Exposure of the service via VPC Endpoint Service by Anjana

    • Use of Network Load Balancer as the service entry point

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

    • Traffic is not transitable or routable outside the exposed service

  • 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 real Zero Trust 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 real Zero Trust architecture, 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

    • Scenarios where traffic outside the AWS backbone is not permitted

Comparison table

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