Skip to main content

A-001 - Administrative Access

Purpose

Provide controlled and secure access to infrastructure components for administration, maintenance and operational tasks.

This capability ensures that administrative actions can be performed while limiting exposure, enforcing accountability and reducing the risk of unauthorized access.


Asset Type

  • Business Capability

Description

Administrative Access represents the mechanisms and practices used to access and manage systems across the Scheol environment.

At the current stage, access is primarily performed through:

  • direct SSH connections to servers (VPS and local infrastructure)
  • restricted authentication mechanisms (SSH keys, hardened configuration)

A more structured model (bastion / centralized access) is planned but not yet implemented.


Criticality

  • Critical

Administrative access directly controls all infrastructure components. Any compromise can lead to full system takeover, service disruption or data compromise.


Sensitivity

  • Highly Sensitive

This asset involves:

  • administrative credentials (SSH keys, accounts)
  • privileged access paths
  • system-level control capabilities

Exposure Level

  • Restricted

Access is not publicly exposed but reachable through:

  • SSH services on exposed systems (Heaven)
  • internal network paths (Hell)

Exposure is limited but still directly reachable without a centralized control layer.


Trust Zone

  • Hybrid

Administrative access spans:

  • Heaven (VPS access)
  • Hell (internal infrastructure management)

Dependencies

  • SSH services on managed systems
  • Network accessibility (firewall rules, routing)
  • Administrator workstation
  • Authentication material (SSH keys)

Relationships

  • All infrastructure assets (servers, VMs, network components)
  • Identity-related systems (future AD/LDAP)
  • Bastion (planned)
  • Monitoring and logging systems (partial)

Security Position (Architecture Context)

  • Primary entry point into the administrative plane
  • High-value attack surface for external and internal threats
  • Central to trust model: controls access to all other assets

Current structural weakness:

  • absence of centralized access control (no bastion)
  • distributed access paths increase attack surface and reduce traceability

Existing Protective Measures

  • SSH key-based authentication (no password login)
  • Root login disabled
  • Non-standard SSH port (where applicable)
  • Basic hardening (fail2ban on some systems)
  • Limited exposure of management interfaces

Limitations:

  • no centralized access control
  • limited session traceability
  • inconsistent logging across systems

Owner / Responsibility

  • Security Role (Sec)

Notes

This asset is a major focus for future improvement.

Planned evolution includes:

  • deployment of a bastion host
  • centralized access management
  • improved logging and session traceability

The current state reflects a transitional model with known limitations that are explicitly tracked in risk documentation.