Scenarios & Selection

This scenario addresses the most common enterprise exposure: public-facing APIs consumed by web browsers, mobile apps, and third-party integrations. The architecture places an active-active API gateway cluster in the DMZ, fronted by a WAF for application-layer filtering. All inbound connections terminate TLS at the gateway boundary; re-encryption with mTLS is applied for backend service calls. NetFlow data is exported from the edge firewall to a central collector, and all authentication events and API call logs are ingested by the SIEM for real-time correlation.

Figure 3.1: Scenario A — Internet-Facing API Security. Active-active API gateway cluster in DMZ with WAF, zone segmentation (DMZ → App Zone → Data Zone), and SIEM telemetry.

As organizations adopt microservices architectures on Kubernetes, east-west traffic between services becomes a significant attack surface. This scenario deploys a service mesh with mTLS sidecars on every pod, managed by a central control plane that issues short-lived certificates from the PKI/KMS. Namespace-level network policies restrict which services can communicate, and all sidecar telemetry is exported to the SIEM. The control plane enforces certificate rotation automatically, eliminating the risk of long-lived credentials in service-to-service communication.

Figure 3.2: Scenario B — Microservices mTLS East-West Traffic. Kubernetes namespaces (payments, profile, orders) with mTLS sidecars, service mesh control plane issuing certificates, and policy-restricted namespace-to-namespace communication.

Critical data replication between primary and secondary data centers requires a robust site-to-site encryption mechanism that can sustain high throughput with low latency overhead. This scenario deploys IPsec gateway pairs in HA configuration at each site, connected via two diverse WAN paths to eliminate single points of failure. Route-based IPsec is preferred over policy-based to simplify management and support dynamic routing. NetFlow is exported from both edge routers to a shared collector, and the SIEM monitors tunnel health, rekey events, and traffic anomalies.

Figure 3.3: Scenario C — Data Center IPsec Replication. Primary and secondary data centers connected via dual diverse WAN paths with HA IPsec gateway pairs, NetFlow collectors, and SIEM monitoring at both sites.

Partner integrations introduce external identities and networks that must be strictly isolated from internal zones. This scenario creates a dedicated Partner Access Zone containing an API gateway for structured data exchange and an SFTP server for file transfers, both accessible only through a reverse proxy. A firewall enforces strict separation between the partner zone and internal networks. mTLS certificates are issued per-partner for API connections, while SSH key pairs are used for SFTP. An optional DLP inspection module can be inserted for regulated data flows. Partner-specific log indexes in the SIEM enable targeted investigation without exposing internal telemetry.

Figure 3.4: Scenario D — Partner B2B Data Exchange. Dedicated Partner Access Zone with API gateway, SFTP server, reverse proxy, and optional DLP inspection. Firewall separation from internal enterprise network with partner-specific log indexing.

Hybrid cloud deployments require consistent security controls across both cloud and on-premises environments, with a unified PKI/KMS managing certificates for workloads on both sides. This scenario uses cloud-native private endpoints to eliminate public internet exposure for cloud-to-on-premises API calls, combined with an IPsec/VPN gateway for bulk data flows. The on-premises PKI issues certificates that are trusted by cloud workloads, ensuring mTLS is maintained end-to-end. NetFlow from the on-premises edge and cloud VPC flow logs are both ingested by the SIEM for a unified view of hybrid traffic.

Figure 3.5: Scenario E — Cloud-to-On-Premises Hybrid Connectivity. Cloud VPC with private endpoints and IPsec gateway connecting to on-premises data center, unified PKI/KMS managing certificates for both environments, and SIEM aggregating cloud VPC flow logs and on-premises NetFlow.

Direct SSH access to production servers is one of the most common sources of credential theft and lateral movement. This scenario eliminates direct admin access by routing all privileged sessions through a hardened SSH bastion host with MFA enforcement. The bastion records all session activity to a tamper-evident storage system and exports session metadata to the SIEM. Firewall rules block all direct SSH connections to target servers, ensuring the bastion is the sole ingress path. SSH key pairs are rotated regularly, and access rights are reviewed quarterly to remove stale accounts.

Figure 3.6: Scenario F — Privileged Admin Access via SSH Bastion. All admin sessions routed through hardened bastion host with MFA, session recording, and SIEM integration. Firewall blocks all direct SSH to target servers.

Operational technology (OT) and industrial IoT environments present unique challenges: legacy protocols, air-gap requirements, and the need to collect telemetry data without exposing control systems to IT networks. This scenario uses a data diode or unidirectional security gateway at the OT/IT demarcation zone to enforce one-way data flow from the factory floor to IT analytics systems. A protocol converter bridges industrial protocols (Modbus, OPC-UA) to standard IT formats. TLS encryption is applied on the IT side for historian and analytics connections, while the OT side remains isolated. NetFlow monitoring and SIEM alerts cover the IT segment.

Figure 3.7: Scenario G — OT/IoT Secure Data Collection. Industrial PLCs and sensors connected via IoT gateway to OT/IT demarcation zone with data diode and protocol converter. One-way data flow to IT historian and analytics platform with TLS encryption on IT side.

Traditional VPN-based remote access grants broad network access after a single authentication event, creating significant lateral movement risk. ZTNA replaces this with a continuous verification model where every access request is evaluated against identity, device posture, and context. This scenario deploys a cloud-hosted ZTNA broker that integrates with the enterprise identity provider (IdP) for MFA-backed authentication. Each application is individually protected, and access is granted per-session based on real-time posture signals. SIEM monitoring covers all access decisions, and micro-segmentation prevents lateral movement even if a session is compromised.

Figure 3.8: Scenario H — Zero Trust Network Access (ZTNA) for Remote Workers. Cloud ZTNA broker with IdP integration, continuous verification, device posture checks, and per-application access grants. SIEM monitoring all access decisions with micro-segmentation preventing lateral movement.