Skip to main content

Service Reference

Purpose

This page provides a functional view of services running within the Scheol Security Lab.

The objective is to:

  • describe what each service does
  • clarify its role in the overall architecture
  • support understanding of dependencies and exposure
  • complement the System Inventory (which focuses on systems, not services)

Scope

This page includes:

  • application services
  • infrastructure services
  • security-related services

It does not include:

  • system-level details (covered in System Inventory)
  • control definitions (covered in Control Framework)
  • detailed architecture (covered in Applied Security Architecture)

Service Model

Each service is described using the following attributes:

FieldDescription
Asset IDUnique identifier (A-XXX)
NameService name
CategoryApplication / Infrastructure / Security
DescriptionFunctional purpose
LocationHeaven / Hell
ExposurePublic / Internal
DependenciesOther services or components
NotesOptional context

Services

Public-Facing Services (Heaven)


A-062 - Reverse Proxy

FieldValue
CategoryInfrastructure
DescriptionEntry point for HTTP/HTTPS traffic, routing requests to backend services
LocationHeaven
ExposurePublic
DependenciesVPS-01
NotesCritical control point; misconfiguration directly linked to R-001

A-063 - Documentation Site

FieldValue
CategoryApplication
DescriptionPublic documentation platform (Docusaurus)
LocationHeaven
ExposurePublic
DependenciesReverse Proxy
NotesStatic content, low sensitivity

A-061 - Gitea

FieldValue
CategoryApplication
DescriptionSource code management and CI/CD entry point
LocationHeaven
ExposurePublic
DependenciesReverse Proxy
NotesSensitive due to code and potential automation secrets

A-064 - Dolibarr

FieldValue
CategoryApplication
DescriptionBusiness application (ERP/CRM)
LocationHeaven
ExposurePublic
DependenciesReverse Proxy, Database
NotesHandles business data; directly linked to R-002

A-065 - Database (Dolibarr)

FieldValue
CategoryInfrastructure
DescriptionData storage for Dolibarr
LocationHeaven
ExposureInternal (intended)
DependenciesDolibarr
NotesCurrently co-located; segmentation incomplete

Internal & Planned Services (Hell)


A-076 - Proxmox Platform

FieldValue
CategoryInfrastructure
DescriptionVirtualization platform hosting internal systems
LocationHell
ExposureInternal
DependenciesPhysical host
NotesCore infrastructure component

A-077 - Bastion (Planned)

FieldValue
CategorySecurity
DescriptionControlled entry point for administrative access
LocationHell
ExposureInternal
DependenciesIdentity system (future)
NotesKey control for R-003

A-066 - Logging & Detection (Wazuh - Planned)

FieldValue
CategorySecurity
DescriptionCentralized logging and detection platform
LocationHell
ExposureInternal
DependenciesAll systems (log sources)
NotesNot yet deployed

A-069 - Monitoring Stack (Planned)

FieldValue
CategoryInfrastructure
DescriptionMetrics and system monitoring (Prometheus / Grafana)
LocationHell
ExposureInternal
DependenciesInternal systems
NotesObservability improvement

A-071 / A-072 - Automation & CI/CD (Planned)

FieldValue
CategoryInfrastructure
DescriptionAutomation workflows (Ansible, runners)
LocationHell
ExposureInternal
DependenciesGitea
NotesHigh privilege operations

Observations

  • Multiple critical services are co-located on VPS infrastructure
  • Reverse proxy acts as a single point of control and failure
  • Several security services are not yet implemented
  • Some internal services have broad implicit trust

Known Limitations

At the current stage:

  • service dependencies are simplified
  • some services are grouped logically
  • planned services are not yet validated in real conditions

This reflects the current maturity of the lab.


Relationship with Other Sections

This page is used by:

  • System Inventory → mapping services to systems
  • Risk Register → identifying service-level risks
  • Control Framework → defining service-specific controls
  • Architecture → understanding flows and interactions

Governance Rule

Any new service must be documented in this reference.

Updates must occur:

  • when deploying a new service
  • when modifying service exposure
  • when introducing dependencies or integrations

Current Maturity

At the current stage, service documentation is considered partially established.

Established

  • identification of core services
  • separation between public and internal services
  • basic understanding of service roles

In Progress

  • refinement of dependencies
  • alignment with architecture and risk model
  • improved service classification

Planned / Next Phase

  • detailed dependency mapping
  • integration with monitoring and validation data
  • stronger linkage with control framework

This page provides a functional view of the services composing the Scheol Security Lab.