Merge branch 'server-fleet-use-case' into 'main'

Supporting use-cases:

* N/A

* [Server and host fleet lifecycle management](#4623-server-and-host-fleet-lifecycle-management)

> NOTE: This section doesn't have use-cases defined in this document due to lack of industry knowledge in the development of this document.

> NOTE: Further ICT device management scenarios (for example mobile device management) remain to be developed into use cases; see [Annex X](#annex-x-informative-standard-development-notes).

Device management can be considered to be a specialisation of ecosystem management.

It combines the partial or full control of the connected devices to device governance function.

In telecom deployments of NMS it is common to provide an in-house Public Key Infrastructure (PKI), that declares its own certificate authority (CA) or authorities deployed to the managed machines within the network. The number of these managed machines, number of CA's, and how the CA's are used is dependent on the design of the network. Alternatively, even at telecom scale, NMS can even provide its own certificates and form an independent and segregated trust domain.

#### 4.6.2.3 Server and host fleet lifecycle management

<mark>Editor's Note: A figure illustrating a management hub controlling a fleet of hosts, with optional proxies and an upstream content source, should be added.</mark>

In this use case the NMS manages the software lifecycle and configuration state of a fleet of general-purpose hosts — typically Linux servers, but also workstations or virtual machines — rather than their network traffic.

The product's role is to keep the managed hosts in a known, consistent, and compliant software state.

This is the domain of dedicated configuration and systems management products, for example software repository and patch managers, configuration-as-code controllers, and provisioning systems.

The NMS in this use case implements the [ICT device management](#414-ict-device-management) functions and draws on [ecosystem management](#413-ecosystem-management) for software delivery.

Its characteristic functions are:

* Package, patch, and content/channel management, including mirroring software content from an upstream source and curating it into controlled channels before delivery to the managed hosts.

* Configuration management, where the desired state of a host is declared centrally and enforced on the host, often through an agent running on the host.

* Provisioning of hosts, including operating system installation and initial configuration.

* Inventory of installed software and hardware for each managed host, as described in [4.2.4.2 Inventory management](#4242-inventory-management).

* Compliance and audit, where hosts are evaluated against a security baseline and deviations are reported.

* Delivery of configuration and software to hosts in a push model (initiated by the NMS) or a pull model (requested by the host), in both cases with host-side verification of the integrity and authenticity of the delivered content, as described in [4.2.4.3 Device management](#4243-device-management).

Managed hosts typically run an agent that registers with the NMS during enrolment.

Trust between the NMS and each host is established at enrolment, as described in [4.3.x Trust initialisation](#43x-trust-initialisation), and is thereafter used to authenticate the host and to deliver configuration, content, and commands.

The connectivity between the NMS and the managed hosts is, in this use case, usually provided by the surrounding network and is not controlled by the product, as described for [devices using provided connectivity](#421x-devices-using-provided-connectivity).

The NMS can be deployed as a single instance for a small estate, or scaled with intermediate proxies or hubs that cache content and relay commands to hosts in remote sites or segmented networks, following the [distributed deployment](#421-network-architecture) pattern.

The upstream software content source — and, depending on the product, subscription, licensing, or usage reporting — is commonly external to the product and is then a [remote data processing solution](#44-distribution-of-security-functions), to which the provisions of [Annex R](#annex-r-normative-additional-provisions-for-products-relying-on-remote-data-processing-solutions-rdps) apply.

Because the NMS holds privileged, often root-equivalent, control over the installed software and configuration of every managed host, a compromise of the NMS or of its content delivery path has an impact radius potentially spanning the entire fleet.

The integrity and authenticity of delivered content and configuration, the strength of host enrolment and authentication, and the isolation of the management plane are therefore the dominant risk factors in this use case.

The applicable risk tier follows the risk factors of the [security analysis](#annex-b-informative-security-analysis), in particular the criticality of the managed hosts and the complexity of the managed elements; the criticality scales with the role of the managed hosts, ranging from a small office estate to servers underpinning critical infrastructure.

> NOTE: This use case concerns the system that manages the hosts. The intrinsic security of the operating systems running on the managed hosts is addressed by ETSI EN 304 626 [\[i.5\]](#_ref_i.5).

#### 4.6.3 Alternative deployments

As the use of extremely large scale network services, or hyperscalers, becomes increasingly popular and the networked services perform an ever greater number of software functions, how we understand network structures depends on how we model their connectivity.