Skip to Content
chalvien 1.0 is released
DocumentationGuidesDmzTechnical Specification

DMZ On-Premises Architecture – Technical Specification (v0.1)

  • Audience: Developers, IT, sysadmins, security team
  • Goal: Define concrete architecture, components, security model, and deployment strategy.

1. Purpose

  • Define the proposed system architecture
  • Describe infrastructure layout (physical + logical)
  • Define security boundaries
  • Define deployment and maintenance strategy
  • Provide a base for implementation planning

2. High-Level Architecture Overview

Short explanation:

The system will be hosted on-premises using physical servers separated by network zones. Public access will be restricted to a DMZ network segment. Application and database layers will be isolated in internal networks.

Internet
   │
Firewall
   │
[ DMZ ]
   │
Reverse Proxy / Web Server
   │
Firewall (internal)
   │
[ Internal Network ]
   ├── Application Server
   └── Database Server

3. Network Segmentation

3.1 Zones

  • External Network (Internet)
  • DMZ
  • Internal Application Network
  • Database Network (optional dedicated VLAN)

3.2 Firewall Rules (Principle of Least Privilege)

Examples:

  • Internet → DMZ: HTTPS (443) only
  • DMZ → App Server: internal API port only
  • App Server → Database: DB port only
  • No direct Internet → Internal Network access

4. Infrastructure Components

4.1 Physical Servers

Define number and roles:

  • Server 1: Reverse Proxy / Web Gateway (DMZ)
  • Server 2: Application Server
  • Server 3: Database Server
  • Optional: Backup Server

Specify:

  • OS (Linux recommended)
  • Virtualization (optional: Proxmox/VMware)
  • RAID configuration
  • Backup strategy

5. Application Layer

Describe:

  • Backend stack (e.g., Django / Node / etc.)
  • API exposure (REST)
  • Authentication strategy (JWT / session)
  • Logging strategy
  • Error monitoring
  1. Database Layer
  • RDBMS (e.g., PostgreSQL / MySQL)
  • Internal-only access
  • Backup strategy:
  • Daily incremental
  • Weekly full
  • Retention policy
  • Encryption at rest (if required)

7. Security Model

  • TLS termination in DMZ
  • Internal communication encrypted (optional but recommended)
  • Role-based access control (RBAC)
  • Audit logging
  • OS hardening
  • Patch management strategy

8. Deployment Strategy

  • Manual deployment vs CI/CD
  • Update procedure
  • Rollback procedure
  • Staging environment (recommended even on-prem)

9. Backup & Disaster Recovery

  • Backup location (separate machine or NAS)
  • Restore test schedule
  • RTO (Recovery Time Objective)
  • RPO (Recovery Point Objective)

10. Scalability Strategy (Future)

  • Horizontal scaling option
  • Load balancer introduction
  • Virtualization readiness
  • Migration to hybrid/cloud if needed

For organizarion’s specific scenario—a physical server in the DMZ pulling data from an internal LAN database—the architecture should follow a tiered segmentation model using a managed switch.

1. Network Segmentation (VLANs)

  • DMZ VLAN (e.g., VLAN 10): This isolated segment holds the physical server. It has a direct path to the internet for public services but is strictly barred from general internal network traffic.
  • LAN VLAN (e.g., VLAN 20): This is where the database server and other sensitive internal assets reside.

2. Managed Switch “Gatekeeper”

Since there is no hardware firewall, a Layer 3 Managed Switch acts as the core traffic controller. It uses Access Control Lists (ACLs) to enforce security rules at the hardware level:

  • Rule A: Allow the DMZ Server IP to communicate with the Internal DB IP on the specific database port only (e.g., TCP 1433 or 3306).
  • Rule B: Block all other traffic between the DMZ and LAN VLANs.

3. Secure Data Access (The “Pull” Strategy)

  • Read-Only Database Account: The application on the physical server should use a database user with SELECT permissions only. This ensures that even if an attacker gains control of the DMZ server, they cannot delete or alter data in the internal LAN.
  • Host-Based Firewalls: Every server runs its own internal firewall (Windows Firewall or iptables) as a secondary defense layer, allowing only trusted source IPs.

Visualizing the Architecture

The following diagrams illustrate how these zones are typically structured to protect the internal core from external threats.

Strategic Benefits for the Client

  • Regulatory Compliance: This design satisfies common requirements for network segmentation and data isolation.
  • Performance: Using physical hardware for the DMZ server ensures maximum throughput for high-demand applications.
  • Resilience: By isolating the database on the internal LAN, you protect the business’s most valuable asset even if the public-facing server is under attack.

Architecture Diagram

DMZ OverviewDMZ Setup