ADR-0004: Network Segmentation and Trust Boundaries¶

Status¶

Accepted

Context¶

With the introduction of a self-hosted server environment, the HomeOps Platform becomes part of a broader local network that may include personal devices, IoT equipment, and external network connections. Not all devices or network segments within this environment can be assumed to be equally trusted.

As additional services are deployed to the server—particularly stateful and network-accessible components, it becomes necessary to define clear trust boundaries. Without explicit segmentation, a compromise in one part of the network could more easily impact other components of the platform.

This decision builds upon the baseline security hardening defined earlier and establishes a conceptual network model that can guide future deployment, access control, and monitoring decisions.

Decision¶

The HomeOps Platform will adopt a segmented network model based on explicit trust boundaries.

Rather than treating the local network as a single trusted environment, network access will be conceptually divided into zones with different trust levels. Communication between zones will be restricted by default and permitted only where explicitly required.

At this stage, network segmentation is defined at a conceptual level. Specific implementation details—such as VLANs, firewall rules, or physical network topology, are intentionally left open and may be refined in later decisions.

Rationale¶

Introducing network segmentation and trust boundaries provides several advantages:

Limits the blast radius of potential security incidents
Reduces implicit trust between unrelated devices and services
Clarifies which components are expected to communicate with each other
Supports safer exposure of selected services without compromising the entire system
Aligns with the principle of least privilege at the network level

By defining trust boundaries early, later deployment and security decisions can be made more consistently and with clearer intent.

Conceptual Network Zones¶

The platform distinguishes between the following conceptual zones:

Management Zone
Used for administrative access to the server environment, such as system maintenance and configuration.
Service Zone
Hosts backend services, APIs, and containerized applications that implement platform functionality.
Data Zone
Hosts stateful internal services such as databases, data loggers (e.g. solar inverter telemetry), and file storage. Services in this zone are not directly exposed to client devices and are accessed only by authorized platform services.
Client Zone
Contains user-facing devices and applications that interact with platform services.
External Zone
Represents networks and services outside the local environment, including the public internet and third-party APIs.

Communication between zones is permitted only where required for platform functionality and should be explicitly documented and monitored. In particular, direct access from client-facing components to the Data Zone is explicitly avoided, reinforcing the separation between application logic and persistent data.

Consequences¶

Positive¶

Clear separation of trust levels within the network
Reduced risk of lateral movement in case of compromise
Improved reasoning about access control and exposure
Strong foundation for future security and deployment decisions

Negative¶

Increased complexity in network configuration
Additional effort required to diagnose connectivity issues
Potential need for future refactoring as service

ADR-0001: Decision to introduce a self-hosted server environment
ADR-0003: Baseline security hardening for self-hosted server
Future decisions regarding firewall policies and traffic filtering
Future decisions regarding authentication and authorization models
Future decisions regarding backup and data protection strategies