Skip to main content

Architecture Views

Purpose​

This section provides multiple views of the Scheol Security Lab architecture.

Each view highlights a specific aspect of the environment:

  • structural organization
  • trust boundaries
  • critical flows and interactions

The goal is not to document every component in detail, but to support:

  • risk understanding
  • security reasoning
  • architectural decision-making

1. High-Level Architecture Overview​

Description​

The lab is structured around two main environments:

  • Heaven - externally exposed infrastructure (public VPS)
  • Hell - internal infrastructure (on-premise virtualized environment)

This separation reflects a typical hybrid architecture combining:

  • public-facing services
  • internal control and monitoring systems

Key Characteristics​

  • Public services are hosted in Heaven
  • Sensitive systems and control functions are hosted in Hell
  • Administrative and security functions are progressively centralized in Hell

Security Perspective​

  • Heaven is considered exposed but controlled
  • Hell is considered trusted but not immune
  • Interactions between both environments are treated as sensitive flows

2. Trust Zones View​

Description​

The architecture is divided into multiple trust zones based on exposure and sensitivity.

Core Zones​

ZoneDescriptionTrust Level
Public Zone (Heaven)Internet-exposed services (web, repositories)Low
Service Zone (Heaven internal)Backend services behind reverse proxyMedium
Internal Core (Hell)Core infrastructure, identity, automationHigh
Security Zone (Hell)Monitoring, detection, logging (SOC)High
Administrative ZoneAdministrative access systemsVery High
Isolated ZoneHoneypots or experimental systemsUntrusted / Controlled

Security Principles​

  • Default-deny between zones
  • Controlled and minimal communication paths
  • Stronger controls as sensitivity increases

3. Sensitive Flows View​

Description​

Certain flows are considered critical due to the sensitivity of the data or the privileges involved.

Key Flows​

  • Log Forwarding (Heaven → Hell)

    • Security telemetry sent to central monitoring
    • One-way flow preferred

  • Administrative Access (Admin → Bastion → Targets)

    • Controlled entry point
    • Strong authentication required

  • Backup Flows (Systems → Backup Platform)

    • Data extraction toward protected storage
    • Integrity and confidentiality required

  • CI/CD & Automation (Gitea → Runners → Targets)

    • High privilege operations
    • Requires strict isolation and secret management

Security Considerations​

  • Flows must be:

    • authenticated
    • encrypted
    • restricted to necessary endpoints

  • Some flows must remain strictly unidirectional

4. Control & Monitoring Placement​

Description​

Security controls are not uniformly distributed across the architecture.

Observations​

  • Preventive controls are stronger at entry points (reverse proxy, firewall)
  • Detection capabilities are being centralized in Hell
  • Some areas still lack full visibility (transitional state)

Target State​

  • Centralized logging and detection
  • Correlation of events across environments
  • Improved coverage of critical assets and flows

5. Evolution Perspective​

The current architecture reflects a transitional state.

Key evolutions include:

  • stronger separation of public services
  • stricter enforcement of trust boundaries
  • full centralization of monitoring and logging
  • improved isolation of administrative access

These changes aim to progressively reduce risk exposure while maintaining operational flexibility.

Current Maturity​

At the current stage, architecture visualization is considered partially established.

Established​

  • high-level separation between Heaven and Hell
  • identification of core trust zones
  • initial mapping of critical flows
  • basic understanding of exposure levels

In Progress​

  • precise mapping of all inter-zone communications
  • alignment between documented flows and actual configurations
  • integration of monitoring and control placement into architecture views
  • consistency between architecture and risk documentation

Planned / Next Phase​

  • formal diagrams for each architecture view
  • automated or version-controlled architecture mapping
  • tighter linkage between architecture, risks, and controls
  • support for audit and traceability use cases

This section will evolve as the architecture becomes more structured and fully documented.