1. Zero Trust Architecture: Isolation as the Foundation

The production infrastructure is designed according to the zero trust model: no component is considered “trusted” by default. All servers reside in an isolated network segment using private IPv4 addresses (e.g., 10.x.x.x or 192.168.x.x). Direct internet access to databases, microservices, or internal APIs is physically impossible.

This is not merely a “restriction”—it’s an architectural requirement that enables:

  • Reducing the attack surface to a single entry point.
  • Eliminating the risk of direct scanning or exploitation of service vulnerabilities.
  • Simplifying audits and ensuring compliance with regulatory standards (PCI DSS, GDPR).

2. Defense in Depth: Two Frontline Layers

All incoming traffic passes through a two-layer defense system built on the principle of defense in depth:

  1. FortiGate WAF (Web Application Firewall)
    A hardware gateway at the network edge provides L3–L7 filtering:

    • Blocks DDoS attacks and vulnerability scanners.
    • Signature- and behavior-based protection against SQLi, XSS, and RCE.
    • Integration with threat intelligence for up-to-date signatures.

  2. Nginx as a policy enforcement point
    Behind the WAF sits Nginx, configured as a strict reverse proxy:

    • Whitelists allowed HTTP methods, paths, and headers.
    • Validates User-Agent and Origin headers.
    • Rate-limits requests and blocks fuzzing attempts.
    • Maintains detailed logs of all traffic (for SIEM and forensic analysis).

This architecture ensures that even if an attacker bypasses the WAF (e.g., via a zero-day vulnerability), they immediately encounter strict application-layer policies and cannot directly access business logic.

3. Microservices and Network Discipline

The application architecture follows the 12-Factor App methodology, especially regarding isolation and configuration. Critically:

  • Internal microservices do not expose public ports. Communication occurs exclusively within a trusted network:
    • In Kubernetes — via Pod-to-Pod communication with NetworkPolicy.
    • In Docker Swarm or Compose — through overlay networks with strict egress/ingress rules.
  • Public-facing services never process sensitive data over open channels. Even when accessed over TLS, raw sensitive data is never transmitted in plaintext.

This approach eliminates the risk of an internal service accidentally becoming publicly exposed due to a load balancer or DNS misconfiguration.

4. Data Protection “In Transit” and “At Rest”

Data is the core asset. Therefore:

  • All PII, tokens, and financial identifiers in PostgreSQL are encrypted at the application layer.
  • Administration tools (pgAdmin, DBeaver) cannot retrieve decrypted values—even with valid database credentials.
  • Decryption occurs only within the context of an authorized request inside a trusted service.

This is not an “extra measure”—it’s the foundation of compliance. Even in the event of compromised database credentials or a data dump, the information remains useless to attackers.

5. CI/CD as a Quality and Security Gate

Every change flows through a three-stage pipeline that serves as both a quality and audit mechanism:

Stage Purpose Automation
Dev Stage Initial feature testing by developers Unit tests, linting, image builds
QA Stage Smoke tests, regression, UX validation Integration tests, UI tests, security scans (Trivy/Snyk)
Pre-Prod / Prod Final acceptance or progressive rollout Blue/Green (bare metal) or Canary (K8s + Istio)
  • Pre-Prod is used in traditional infrastructure setups. Final manual acceptance occurs here, and traffic can be manually routed (e.g., to the product team).
  • Canary deployment in Kubernetes is used in cloud-native environments: 5% of traffic goes to the new version, 95% to stable. Automated monitoring of errors, latency, and resource consumption triggers rollbacks.

Important: No stage is skipped. A production release is impossible without passing all tests and having CI-signed, verified build artifacts.

Conclusion: Control Is a Design Choice—Not a Reaction

The described model demonstrates that “full production control” is neither a myth nor an ops-team requirement—it’s the result of:

  • Architectural discipline (isolation, 12-Factor principles, zero trust),
  • Engineering automation (CI/CD as a delivery and verification mechanism),
  • A security-first culture (data encryption, boundary and internal protection).

This approach ensures not only compliance but also predictability, reproducibility, and resilience—the hallmarks of a mature production environment.

“Reliability isn’t something you add at the end. It’s something you design from the very beginning.”
— adapted from the Google SRE Workbook

Architecture Diagram

Below is a schematic illustrating the described structure:

+---------------------+
|     Internet        |
+----------+----------+
           |
           v
+----------+----------+
|   FortiGate WAF     | ← L3–L7 protection (DDoS, SQLi, XSS)
+----------+----------+
           |
           v
+----------+----------+
|      Nginx Proxy    | ← Path whitelisting, header filtering
+----------+----------+
           |
           v
+----------+----------+
|   Public-Facing     |
|   Microservices     | ← External APIs only, no sensitive data
+----------+----------+
           |
   +-------+-------+
   |               |
   v               v
+--+--+        +---+---+
| K8s |        | Docker| ← Internal-only services
| Net |        | Net   |    (Pod-to-Pod / Overlay)
+--+--+        +---+---+
   |               |
   v               v
+--+--------------+--+
| PostgreSQL (application-layer encryption) |
| Redis, Consul, etcd                      |
+--------------------+
      (isolated network, no external access)
← Back to Portfolio