Skip to main content

Security Design Decisions

Purpose​

This page documents key architectural and security decisions made within the Scheol Security Lab.

The objective is not to describe the infrastructure itself, but to explain:

  • why specific design choices were made
  • which risks they address
  • which trade-offs were accepted
  • how they are expected to evolve

Each decision reflects a balance between security, complexity, and practical constraints in a learning environment.

Decision Model​

Each decision is documented using the following structure:

  • Context - situation or constraint
  • Decision - chosen approach
  • Rationale - why this choice was made
  • Risk Considerations - risks reduced and risks introduced
  • Status - Temporary / Transitional / Target
  • Next Steps - planned improvements

Key Decisions​

1. Mixed Exposure on a Single Public VPS​

Context Public-facing services (documentation, repositories) are currently hosted on the same exposed instance.

Decision Use a single VPS to host both static sites and development-related services.

Rationale

  • Simplifies deployment and management
  • Reduces cost and operational overhead
  • Enables rapid iteration during early lab stages

Risk Considerations

  • Increased attack surface due to service co-location
  • Potential lateral movement if one service is compromised
  • Dependency on isolation mechanisms (reverse proxy, service separation)

Status Transitional

Next Steps

  • Separate services across multiple instances
  • Introduce stronger isolation boundaries
  • Reduce trust between co-hosted components

2. Progressive Trust Boundary Implementation​

Context The target architecture includes multiple trust zones, but not all are fully implemented yet.

Decision Adopt a staged approach to segmentation rather than enforcing full isolation from the beginning.

Rationale

  • Allows incremental deployment and validation
  • Keeps the environment manageable during early phases
  • Aligns with iterative risk-driven design

Risk Considerations

  • Temporary over-permissive communication paths
  • Reduced containment in case of compromise

Status In Progress

Next Steps

  • Enforce stricter inter-zone filtering
  • Validate trust boundaries through testing scenarios
  • Align segmentation with critical assets and flows

3. Administrative Access Model (Transitional State)​

Context Administrative access is currently performed from a personal workstation.

Decision Allow direct administrative access during early stages.

Rationale

  • Practical constraint (no dedicated admin workstation yet)
  • Enables faster setup and iteration

Risk Considerations

  • Weak separation between personal and administrative environments
  • Increased risk of credential exposure or compromise

Status Transitional (High Risk Accepted)

Next Steps

  • Introduce dedicated admin workstation
  • Enforce bastion-based access
  • Restrict direct access paths

4. Local-First Logging with Planned Centralization​

Context Centralized logging infrastructure is not fully deployed yet.

Decision Keep logs locally on systems with planned forwarding to a central platform.

Rationale

  • Allows systems to operate independently
  • Avoids blocking deployment on missing components

Risk Considerations

  • Limited visibility across the environment
  • Delayed detection capabilities
  • Risk of log tampering on compromised hosts

Status In Progress

Next Steps

  • Deploy centralized logging (SOC)
  • Enforce log forwarding and retention policies
  • Validate detection coverage

5. Snapshot-Based Backup Strategy (Temporary)​

Context Backup strategy relies on provider snapshots.

Decision Use native snapshot mechanisms as primary backup.

Rationale

  • Easy to implement
  • No additional infrastructure required
  • Suitable for early-stage recovery needs

Risk Considerations

  • Lack of isolation from primary system
  • No protection against ransomware or provider failure
  • Limited recovery guarantees

Status Transitional

Next Steps

  • Implement external, immutable backups
  • Separate backup storage from production systems
  • Test restoration procedures

Decision Traceability​

Each decision should be traceable to:

  • one or more identified risks
  • specific architectural components
  • future validation or improvement actions

This ensures that architecture evolution remains aligned with risk management and governance objectives.

Evolution​

Security design decisions are expected to evolve as:

  • the infrastructure matures
  • new risks are identified
  • controls are implemented and validated

This page is therefore a living record of architectural reasoning rather than a fixed specification.