Overview
This documentation contains the technical product description for the Managed OS service. Contract-relevant information can be found in the respective customer contract and the service description.
Managed OS comprises the operation of a server operating system by Swisscom as a service provider. The table shows an overview of the most important functions:
Functions | Managed OS Service |
---|---|
SLA on the OS | X |
Monitoring | X |
Alarming | Swisscom |
Troubleshooting | Swisscom |
Malware Protection | X |
Patching | X |
Reporting | X |
Lifecycle (Swisscom Agents and Tools) | X |
On a Managed OS VM, only Swisscom has administration or root authorization on the server. The flag SeDenyRemoteInteractiveLogonRight is set for Windows service accounts.
Rights | Managed OS Service |
---|---|
Administration rights on the server | Swisscom |
The application of temporary administration rights by the customer is possible, but leads to the suspension of the SLA.
Prerequisites and general conditions
The supported operating systems and versions as well as the other prerequisites for the purchase of the two product versions are described in this chapter
- A operating system certified accordingly by Swisscom. An operating system is certified by means of compliance checks, which are an integral part of the requirements.
- The virtual machine must be based on an Swisscom Enterprise Service Cloud Blueprint
Supported operating systems and versions
The Managed OS Service can be ordered for the following operating systems and versions:
Operating systems Microsoft Windows:
- Microsoft Windows 2016
- Microsoft Windows 2019
Operating systems Linux:
- Red Hat Enterprise Linux RHEL 7
- Red Hat Enterprise Linux RHEL 8
Requirements
To obtain Managed OS Service, the following requirements must be met, among others:
- The server must have run through the Swisscom ESC staging process and provisioned with a managed OS blueprint.
- No customer-specific malware protection solution (agent) must be installed on the server.
- The operating system must not be connected to a customer-specific patching solution.
- The server must not be a domain controller server or installed any other domain services.
- No customer configuration agent (Puppet, SCCM, LANdesk, etc.) may be installed or configured on the server.
- The current VMware Tools must be installed on the server.
- The server must be "hardened" according to Swisscom specifications.
- The compliance check must be successfully completed. If one of the tests fails, Managed OS Service cannot be offered. The customer is informed and can resolve the problems or apply to Swisscom for an exception. This can either be approved or rejected.
Note: Detailed technical details on the requirements can be found in the compliance checks section
For Managed Windows, the following prerequisite must also be fulfilled:
- No applications may be installed on drive C:.
- Service accounts must not be in the local administrator group.
- The local user account Administrator (SID: S-1-5-21Domain-500) will switch to the responsibility of Swisscom.
- The password for the User Administrator will be changed.
For Managed RHEL, the following requirements must also be fulfilled:
- The server must have the
sudo
command installed. - The account handed over when ordering the service must have unlimited sudo privileges and not be asked for a password. (Example entry in sudoers file:
username ALL=(ALL) NOPASSWD: ALL
). - The option
requiretty
must be deactivated for the account that is transferred when ordering the service (example entry in sudoers:Defaults:username !requiretty
). - Local users (service/application users) may not log in remotely.
- OS data must be separated from application data. Dedicated file systems must be created for applications in the volume group
datavg
. - Disk space must be managed with LVM, application data must reside in the volume group
datavg
. - Swisscom file system layout must be adhered to.
- No custom kernels may be installed, only standard Red Hat Enterprise Linux kernels.
Restrictions for Managed RHEL:
- Please note that Managed RHEL is not ready for container services like Docker, Openshift, etc. As an alternative to Docker you can use Podman:
Podman is a full-fledged container engine that provides the same functionality as Docker, the quasi-industry standard. However, Podman does not use a so-called daemon and also offers containers without root access. Security should therefore be at the forefront of the project. Podman is available from RHEL version 7.6 and higher. For its work, it relies on a CLI that is compatible with Docker. For security reasons, the customer/user should always obtain downloaded container images from the trusted source. For building own images Podman relies on Buildah, which comes from the same group of developers as Podman, CRI-O and Skopeo. A container is executed without root rights on the Managed OS VM. In fact, the process only runs inside the container as root, but on the host as a normal user.
More information here:
Podman
Running containers without root
Running and building Podman containers
Compliance Check Exception
A succesful compliance check is prerequisite for using Managed OS. If one of the tests fails, Managed OS Service cannot be offered. The customer is informed and can resolve (recommended solution) the issue or apply to Swisscom for an exception. This can either be approved or rejected. The approval needs to be requested via ESC Service Request.
Active Directory Resource Domain
Each Managed Windows VM is member of a Active Directory Resource Domain owned and managed by Swisscom. For each customer at least one resource domain is built into which a Managed Windows VM is added. The Active Directory Resource Domain belongs to Swisscom in any case and cannot be reclaimed by the customer without the resource domain being deleted.
Between the customer domain and the resource domain there is a one-way trust. This means the resource domain trusts the customer domain. This also ensures that Swisscom employees cannot see or have access to objects in the customer domain.
Access to objects in the resource domain is controlled by delegations (View & Edit). This ensures that only the objects that are necessary for the customer are visible from the customer domain.