chrisbst48/itgrundschutzcompendium_2023 huggingface dataset:
SYS.2.2.3.A22 Verwendung der Windows PowerShell
Die PowerShell-Ausführung selbst SOLLTE zentral protokolliert und die Protokolle überwacht werden. Die PowerShell und die WPS-Dateien SOLLTEN NUR von Administrierenden ausgeführt werden können. Die Ausführung von PowerShell-Skripten SOLLTE mit dem Befehl Set-ExecutionPolicy AllSigned eingeschränkt werden, um zu verhindern, dass unsignierte Skripte versehentlich ausgeführt werden.
SYS.2.2.3.A23 Erweiterter Schutz der Anmeldeinformationen unter Windows(umbenannt von Erweiterter Schutz der Anmeldeinformationen unter Windows 10 in Vorjahres-Edition)
Auf UEFI-basierten Systemen SOLLTE SecureBoot verwendet und der Status des geschützten Modus für den Local Credential Store LSA beim Systemstart überwacht werden. Ist eine Fernwartung der Clients mittels RDP vorgesehen, SOLLTE beim Einsatz von Windows in einer Domäne ab dem Funktionslevel 2012 R2 von der Option „restrictedAdmin“ für RDP Gebrauch gemacht werden.
SYS.2.2.3.A24 Aktivierung des Last-Access-Zeitstempels
Es SOLLTE geprüft werden, ob der Last-Access-Zeitstempel im Dateisystem aktiviert werden kann, um die Analyse eines Systemmissbrauchs zu erleichtern. Bei der Prüfung SOLLTEN mögliche Auswirkungen dieser Einstellung, wie Performance-Aspekte oder resultierende Einschränkungen bei inkrementellen Backups, berücksichtigt werden.
SYS.2.2.3.A25 Umgang mit Fernzugriffsfunktionen der „Connected User Experience and Telemetry“
Ein solcher Fernzugriff auf den Windows-Client SOLLTE netzseitig geloggt und falls erforderlich geblockt werden. Es SOLLTE berücksichtigt werden, dass die Komponente „Connected User Experience and Telemetry“ (CUET) bei Windows fester Bestandteil des Betriebssystems ist und neben der Telemetriefunktion auch eine Fernzugriffsmöglichkeit für den Hersteller Microsoft auf das lokale System erlaubt.
SYS.2.2.3.A26 Nutzung des Virtual Secure Mode (VSM) (neu seit Vorjahres-Edition)
Bei der Nutzung des Virtual Secure Mode (VSM) SOLLTE berücksichtigt werden, dass forensische Untersuchungen, z. B. zur Sicherheitsvorfallbehandlung, eingeschränkt oder erschwert werden.
SYS.2.2.3.A3 ENTFALLEN
Diese Anforderung ist entfallen.
SYS.2.2.3.A4 Telemetrie und Datenschutzeinstellungen unter Windows(umbenannt von Telemetrie und Datenschutzeinstellungen unter Windows 10 in Vorjahres-Edition)
Wenn diese Einstellung nicht wirksam umgesetzt wird oder bei anderen Windows-Edition umgesetzt werden kann, dann MUSS durch geeignete Maßnahmen, etwa auf Netzebene, sichergestellt werden, dass die Daten nicht an den Hersteller übertragen werden. Um die Übertragung von Diagnose- und Nutzungsdaten an Microsoft stark zu reduzieren, MUSS das Telemetrie-Level 0 (Security) in der Enterprise-Edition von Windows konfiguriert werden.
SYS.2.2.3.A5 Schutz vor Schadsoftware unter Windows(umbenannt von Schutz vor Schadsoftware unter Windows 10 in Vorjahres-Edition)
Sofern nicht gleich- oder höherwertige Maßnahmen, wie z. B. Ausführungskontrolle, zum Schutz des IT-Systems vor einer Infektion mit Schadsoftware getroffen wurden, MUSS eine spezialisierte Komponente zum Schutz vor Schadsoftware auf Windows-Clients eingesetzt werden.
SYS.2.2.3.A6 Integration von Online-Konten in das Betriebssystem
Online-Konten zur Anmeldung, etwa ein Microsoft-Konto oder Konten anderer Identitätsmanagementsysteme, DÜRFEN NICHT verwendet werden, da hier personenbezogene Daten an die Systeme Dritter übertragen werden. Die Anmeldung am System sowie an der Domäne DARF NUR mit dem Konto eines selbst betriebenen Verzeichnisdienstes möglich sein. Anmeldungen mit lokalen Konten SOLLTEN Administrierenden vorbehalten sein.
SYS.2.2.3.A7 ENTFALLEN
Diese Anforderung ist entfallen.
SYS.2.2.3.A8 ENTFALLEN
Diese Anforderung ist entfallen.
SYS.2.2.3.A9 Sichere zentrale Authentisierung in Windows-Netzen
Für die zentrale Authentisierung SOLLTE ausschließlich Kerberos eingesetzt werden. Eine Gruppenrichtlinie SOLLTE die Verwendung älterer Protokolle verhindern. Ist dies nicht möglich, MUSS alternativ NTLMv2 eingesetzt werden. Die Authentisierung mittels LAN-Manager und NTLMv1 DARF NICHT innerhalb der Institution und in einer produktiven Betriebsumgebung erlaubt werden. Die eingesetzten kryptografischen Mechanismen SOLLTEN entsprechend dem ermittelten Schutzbedarf und basierend auf den internen Richtlinien konfiguriert und dokumentiert werden. Abweichende Einstellungen SOLLTEN begründet und mit dem Sicherheitsmanagement abgestimmt sein.
SYS.2.3 Clients unter Linux und Unix
IT-System R2
SYS.2.3.A1 Authentisierung von Administrierenden und Benutzenden(umbenannt von Authentisierung von Administratoren und Benutzern in Vorjahres-Edition)
Es SOLLTE verhindert werden, dass sich mehrere Benutzende auf einem Client gleichzeitig einloggen können. Personen mit Adminstrationsrechten DÜRFEN sich NICHT im Normalbetrieb als „root“ anmelden. Für die Systemadministrationsaufgaben SOLLTE „sudo“ oder eine geeignete Alternative mit einer geeigneten Protokollierung genutzt werden.
SYS.2.3.A10 ENTFALLEN
Diese Anforderung ist entfallen.
SYS.2.3.A11 Verhinderung der Überlastung der lokalen Festplatte
Es SOLLTEN Quotas für Konten bzw. Dienste eingerichtet werden, die ausreichend Freiraum für das Betriebssystem lassen. Alternativ SOLLTEN auch Mechanismen des verwendeten Dateisystems genutzt werden, die ab einem geeigneten Füllstand nur noch dem Konto „root“ Schreibrechte einräumen. Generell SOLLTEN unterschiedliche Partitionen für Betriebssystem und Daten genutzt werden.
SYS.2.3.A12 Sicherer Einsatz von Appliances
Es SOLLTE dokumentiert werden, wie entsprechende Sicherheitsanforderungen mit einer eingesetzten Appliance erfüllt werden. Es SOLLTE sichergestellt werden, dass Appliances ein ähnliches Sicherheitsniveau wie Clients auf Standard-IT-Systemen erfüllen. Wenn die Anforderungen nicht zweifelsfrei erfüllt werden können, SOLLTE eine Konformitätserklärung von den herstellenden Unternehmen angefordert werden.
SYS.2.3.A13 ENTFALLEN
Diese Anforderung ist entfallen.
SYS.2.3.A14 Absicherung gegen Nutzung unbefugter Peripheriegeräte
Kernelmodule für Peripheriegeräte SOLLTEN nur geladen und aktiviert werden, wenn das Gerät freigegeben ist. Peripheriegeräte SOLLTEN nur nutzbar sein, wenn sie explizit freigegeben sind.
SYS.2.3.A15 Zusätzlicher Schutz vor der Ausführung unerwünschter Dateien
Partitionen und Verzeichnisse, in denen Benutzende Schreibrechte haben, SOLLTEN so gemountet werden, dass keine Dateien ausgeführt werden können (Mountoption „noexec“).
SYS.2.3.A16 ENTFALLEN
Diese Anforderung ist entfallen.
SYS.2.3.A17 Zusätzliche Verhinderung der Ausbreitung bei der Ausnutzung von Schwachstellen
Die vorhandenen Standardprofile bzw. -regeln von SELinux, AppArmor sowie alternativen Erweiterungen SOLLTEN manuell überprüft und gegebenenfalls an die eigene Sicherheitsrichtlinie angepasst werden. Die Nutzung von Systemaufrufen SOLLTE insbesondere für exponierte Dienste und Anwendungen auf die unbedingt notwendige Anzahl beschränkt werden (z. B. durch seccomp). Falls erforderlich, SOLLTEN neue Regeln bzw. Profile erstellt werden.
SYS.2.3.A18 Zusätzlicher Schutz des Kernels
Es SOLLTEN mit speziell gehärteten Kernels (z. B. grsecurity, PaX) geeignete Schutzmaßnahmen wie Speicherschutz, Dateisystemabsicherung und rollenbasierte Zugriffskontrolle umgesetzt werden, die eine Ausnutzung von Schwachstellen und die Ausbreitung im Betriebssystem verhindern.
SYS.2.3.A19 Festplatten- oder Dateiverschlüsselung
Die dazugehörigen Schlüssel SOLLTEN NICHT auf dem IT-System gespeichert werden. Es SOLLTEN AEAD-Verfahren (Authenticated Encryption with Associated Data) bei der Festplatten- und Dateiverschlüsselung eingesetzt werden. Alternativ SOLLTE „dm-crypt“ in Kombination mit „dm-verity“ genutzt werden. Festplatten oder die darauf abgespeicherten Dateien SOLLTEN verschlüsselt werden.
SYS.2.3.A2 Auswahl einer geeigneten Distribution
Es MUSS für die geplante Einsatzdauer des Betriebssystems Support verfügbar sein. Auf Grundlage der Sicherheitsanforderungen und des Einsatzzwecks MUSS ein geeignetes Unix-Derivat bzw. eine geeignete Linux-Distribution ausgewählt werden. Alle benötigten Anwendungsprogramme SOLLTEN als Teil der Distribution direkt verfügbar sein. Sie SOLLTEN NUR in Ausnahmefällen aus Drittquellen bezogen werden. Distributionen, bei denen das Betriebssystem selbst kompiliert wird, SOLLTEN NICHT in Produktivumgebungen eingesetzt werden.
SYS.2.3.A20 Abschaltung kritischer SysRq-Funktionen
Es SOLLTE festgelegt werden, welche SysRq-Funktionen von den Benutzenden ausgeführt werden dürfen. Generell SOLLTEN keine kritischen SysRq-Funktionen von den Benutzenden ausgelöst werden können.
SYS.2.3.A3 ENTFALLEN
Diese Anforderung ist entfallen.
SYS.2.3.A4 Kernel-Aktualisierungen auf unixartigen Systemen
Der Client MUSS zeitnah neu gebootet werden, nachdem der Kernel des Betriebssystems aktualisiert wurde. Ist dies nicht möglich, MUSS alternativ Live-Patching des Kernels aktiviert werden.
SYS.2.3.A5 Sichere Installation von Software-Paketen
Anschließend DARF die zu installierende Software NICHT unkontrolliert in das Wurzeldateisystem des Betriebssystems installiert werden. Alle weiteren Installationsschritte SOLLTEN dabei ebenfalls dokumentiert werden. Anhand dieser Dokumentation SOLLTE die Software jederzeit nachvollziehbar und reproduzierbar kompiliert werden können. Wenn zu installierende Software aus dem Quellcode kompiliert werden soll, DARF diese NUR unter einem unprivilegierten Konto entpackt, konfiguriert und übersetzt werden. Wird die Software aus dem Quelltext übersetzt, dann SOLLTEN die gewählten Parameter geeignet dokumentiert werden.
SYS.2.3.A6 Kein automatisches Einbinden von Wechsellaufwerken
Wechsellaufwerke SOLLTEN NICHT automatisch eingebunden werden. Die Einbindung von Wechsellaufwerken SOLLTE so konfiguriert sein, dass alle Dateien als nicht ausführbar markiert sind (Mount-Option „noexec“).
SYS.2.3.A7 Restriktive Rechtevergabe auf Dateien und Verzeichnisse
Auf Verzeichnissen, in denen alle Konten Schreibrechte haben (z. B. „/tmp“), SOLLTE das Sticky Bit gesetzt werden. Es SOLLTE sichergestellt werden, dass Dienste und Anwendungen nur die ihnen zugeordneten Dateien erstellen, verändern oder löschen dürfen.
SYS.2.3.A8 Einsatz von Techniken zur Rechtebeschränkung von Anwendungen
Erweiterungen zur Rechtebeschränkung SOLLTEN im Zwangsmodus (Enforcing Mode) oder mit geeigneten Alternativen verwendet werden. Es SOLLTEN die von dem jeweiligen Unix-Derivat bzw. der Linux-Distribution am besten unterstützten Lösungen eingesetzt werden. Zur Beschränkung der Zugriffsrechte von Anwendungen auf Dateien, Geräte und Netze SOLLTE App-Armor oder SELinux eingesetzt werden. Rechte SOLLTEN grundsätzlich entzogen sein und wo nötig über Positivlisten explizit erteilt werden.
SYS.2.3.A9 Sichere Verwendung von Passwörtern auf der Kommandozeile
Passwörter SOLLTEN NICHT als Parameter an Programme übergeben werden.
SYS.2.4 Clients unter macOS
IT-System R2
SYS.2.4.A1 Planung des sicheren Einsatzes von macOS
Wird der Mac in einem Datennetz betrieben, MUSS zusätzlich berücksichtigt werden, welche Netzprotokolle eingesetzt werden sollen. Es MUSS geplant werden, wie Sicherheits- und sonstige Aktualisierungen für macOS und Anwendungen systematisch installiert werden können. Die Einführung von macOS MUSS sorgfältig geplant werden. Es MUSS entschieden werden, wo und wie Daten abgelegt werden. Es MUSS geplant werden, wie die Datensicherung in das institutionsweite Datensicherungskonzept integriert werden kann. Es MUSS ermittelt werden, welche Anwendungen bei einem Plattformwechsel zu macOS benötigt werden.
SYS.2.4.A10 Aktivierung der Personal Firewall unter macOS
Die in macOS integrierte Personal Firewall SOLLTE aktiviert und geeignet konfiguriert werden.
SYS.2.4.A11 Geräteaussonderung von Macs
Bei einer Aussonderung des Macs SOLLTEN der nichtflüchtige Datenspeicher NVRAM (Non Volatile Random Access Memory) sowie der SMC (System Management Controller) zurückgesetzt werden.
SYS.2.4.A12 Firmware-Kennwort und Boot-Schutz auf Macs
Auf älteren Macs SOLLTE die Abfrage eines sicheren Firmware-Kennworts im sogenannten „Command-Modus“ aktiviert werden, um ein unberechtigtes Booten des Macs von einem anderen Startlaufwerk zu verhindern. Die Option „Sicheres Starten: Volle Sicherheit“ SOLLTE aktiviert werden. Es SOLLTE geprüft werden, ob über den „Full-Modus“ ein Kennwort bei jedem Startvorgang abgefragt werden sollte. Die Option „Starten von externen Medien nicht zulassen“ SOLLTE aktiviert werden. Auf Macs mit T2-Sicherheitschip SOLLTE ein Firmware-Passwort über das Startsicherheitsdienstprogramm gesetzt werden.
SYS.2.4.A2 Nutzung der integrierten Sicherheitsfunktionen von macOS
Die in macOS integrierten Schutzmechanismen „System Integrity Protection“ (SIP), „Xprotect“ und „Gatekeeper“ MÜSSEN aktiviert sein. Gatekeeper DARF NUR die Ausführung signierter Programme erlauben, sofern unsignierte Programme nicht zwingend notwendig sind.
SYS.2.4.A3 Verwendung geeigneter Konten(umbenannt von Verwendung geeigneter Benutzerkonten in Vorjahres-Edition)
Das Gast-Konto MUSS deaktiviert werden. Das bei der Erstkonfiguration von macOS angelegte Konto hat Administrationsrechte und DARF NUR zu administrativen Zwecken verwendet werden. Sollte der Mac von mehreren Benutzenden verwendet werden, MUSS für jeden Benutzenden ein eigenes Konto angelegt werden. Für die normale Verwendung des Macs MUSS ein Konto mit Standard-Berechtigungen angelegt werden.
SYS.2.4.A4 Verwendung einer Festplattenverschlüsselung
Wird dazu die in macOS integrierte Funktion FileVault verwendet, DARF das Schlüsselmaterial NICHT online bei Apple gespeichert werden. Es SOLLTE geprüft werden, ob ein institutioneller Wiederherstellungsschlüssel für FileVault verwendet werden soll. Festplatten SOLLTEN, insbesondere bei mobilen Macs (z. B. MacBooks), verschlüsselt werden. Der von FileVault erzeugte Wiederherstellungsschlüssel MUSS an einem sicheren Ort aufbewahrt werden.
SYS.2.4.A5 Deaktivierung sicherheitskritischer Funktionen von macOS
Inhalte von optischen und anderen Medien SOLLTEN NICHT automatisch ausgeführt werden. Die in macOS integrierten Ortungsdienste SOLLTEN deaktiviert werden. Heruntergeladene Daten SOLLTEN NICHT automatisch geöffnet werden.
SYS.2.4.A6 Verwendung aktueller Mac-Hardware
Werden die Macs nicht mehr durch Apple unterstützt, SOLLTEN sie nicht mehr verwendet werden. Werden neue Macs beschafft, SOLLTEN aktuelle Modelle ausgewählt werden. Werden bereits vorhandene Macs eingesetzt, SOLLTE regelmäßig überprüft werden, ob diese sowie das darauf installierte Betriebssystem weiterhin von Apple mit Sicherheits-Updates versorgt werden.
SYS.2.4.A7 Zwei-Faktor-Authentisierung für Apple-ID
Die Zwei-Faktor-Authentisierung für die Verwendung des Apple-ID-Kontos SOLLTE aktiviert werden.
SYS.2.4.A8 Keine Nutzung von iCloud für schützenswerte Daten
Schützenswerte Daten SOLLTEN NICHT in iCloud gespeichert werden. Entwürfe, beispielsweise von E-Mails oder Dokumenten, SOLLTEN NICHT automatisch in iCloud gespeichert werden. Es SOLLTE verhindert werden, dass schützenswerte Daten zwischen mehreren Geräten über iCloud-Dienste synchronisiert werden. Stattdessen SOLLTEN Daten nur über selbst betriebene Dienste synchronisiert werden.
SYS.2.4.A9 Verwendung von zusätzlichen Schutzprogrammen unter macOS
Bei Bedarf, etwa wenn Macs in einem heterogenen Netz betrieben werden, SOLLTEN neben den integrierten Schutzmechanismen von macOS zusätzlich Virenschutz-Lösungen von Drittanbietern eingesetzt werden.
SYS.2.5 Client-Virtualisierung
IT-System R2
SYS.2.5.A1 Planung des Einsatzes virtueller Clients (neu seit Vorjahres-Edition)
Für diese Anwendungen MUSS überprüft und dokumentiert werden, welche Anforderungen an die Virtualisierungsinfrastruktur und deren etwaige Zusatzhardware (z. B. Grafikkarten) gestellt werden. Es MUSS festgelegt werden, welche Anwendungen auf den virtuellen Clients eingesetzt werden sollen. Die Aufgaben, die mit diesen Anwendungen gelöst werden sollen, MÜSSEN festgelegt werden. Der genutzte Virtualisierungsserver MUSS die notwendigen Ressourcen hinsichtlich CPU, Arbeitsspeicher und Datenspeicher bereitstellen.
SYS.2.5.A10 Bedarfsgerechte Zuweisung von Ressourcen zu virtuellen Clients und Gruppen (neu seit Vorjahres-Edition)
Anhand von Rollen und Tätigkeiten SOLLTEN die Leistungsanforderungen der einzelnen Benutzendengruppen an die virtuellen Clients identifiziert werden. Anhand dieser Anforderungen SOLLTE entschieden werden, wie viele Ressourcen (z. B. Prozessorkerne oder Arbeitsspeicher) den einzelnen virtuellen Clients zur Verfügung gestellt werden. Zusätzliche Ressourcen wie GPUs (Graphics Processing Units) SOLLTEN den Benutzenden nur bei Bedarf bereitgestellt werden.
SYS.2.5.A11 Vermeidung von verschachtelter Virtualisierung auf virtuellen Clients (neu seit Vorjahres-Edition)
Auf virtuellen Clients SOLLTEN keine weiteren virtuellen IT-Systeme eingerichtet werden. Falls technisch möglich, SOLLTEN in der zugrundeliegenden Virtualisierungsinfrastruktur Funktionen aktiviert werden, die eine verschachtelte Virtualisierung erschweren oder unterbinden.
SYS.2.5.A12 Sensibilisierung der Benutzenden (neu seit Vorjahres-Edition)
Falls die Sicherheitsanforderungen der auf virtuellen Clients ausgeführten Anwendungen besonders sind, SOLLTE kommuniziert werden, wie diese gegenüber physischen Clients abweichen. Alle Benutzenden von virtuellen Clients SOLLTEN über den sicheren Umgang mit virtuellen Clients sensibilisiert werden. Falls die Ressourcen dynamisch anhand der abgerufenen Leistung zwischen mehreren virtuellen Clients aufgeteilt werden, SOLLTEN die Benutzenden darüber aufgeklärt werden, dass ihr Verhalten potenziell andere Benutzende beeinflussen kann. Es SOLLTE auch kommuniziert werden, welche spezifischen Sicherheitsaspekte zu beachten sind.
SYS.2.5.A13 Verhinderung der Kommunikation zwischen virtuellen Clients an einem gemeinsam genutzten virtuellen Switch (neu seit Vorjahres-Edition)
Mechanismen SOLLTEN aktiviert werden, die eine unkontrollierte Layer-2-Kommunikation zwischen virtuellen Clients an einem gemeinsam genutzten virtuellen Switch unterbinden.
SYS.2.5.A14 Erweiterte Sicherheitsfunktionen für den Einsatz von virtuellen Clients (neu seit Vorjahres-Edition)
Die virtuellen Clients SOLLTEN mit zusätzlichen Sicherheitsfunktionen geschützt werden. • Intrusion-Detection- oder Intrusion-Prevention-Systeme, die entweder zentralisiert auf der Virtualisierungsinfrastruktur oder dezentral auf den virtuellen Clients bereitgestellt werden Dabei SOLLTEN mindestens die folgenden Techniken berücksichtigt werden: • Mikrosegmentierung für die virtuellen Clients
SYS.2.5.A15 Monitoring der virtuellen Clients (neu seit Vorjahres-Edition)
• freie Festplattenkapazität der virtuellen Clients sowie Der Zustand der virtuellen Clients SOLLTE zentral überwacht werden. Folgende Parameter SOLLTEN mindestens überwacht werden: • Erreichbarkeit der virtuellen Clients über alle vorgesehenen Netzschnittstellen, • Auslastung von CPU und Arbeitsspeicher der virtuellen Clients, • Verfügbarkeit der für den Zugriff eingesetzten Terminalserver-Dienste. Für das Monitoring SOLLTEN vorab die jeweiligen Schwellwerte ermittelt werden (Baselining). Diese Schwellwerte SOLLTEN regelmäßig überprüft und bei Bedarf angepasst werden.
SYS.2.5.A16 Erweiterte Protokollierung für virtuelle Clients (neu seit Vorjahres-Edition)
• Konfigurationsänderungen, Für virtuelle Clients SOLLTEN zusätzliche Ereignisse an eine zentrale Protokollierungsinfrastruktur (siehe OPS.1.1.5 Protokollierung) übermittelt werden. • Installation von Software, • erfolgreiche und fehlgeschlagene Updates und • alle Ereignisse, die durch den Schutz vor Schadsoftware entstehen. Hierbei SOLLTEN mindestens die folgenden Ereignisse protokolliert werden: • Aktionen, die mit administrativen Rechten ausgeführt werden,
SYS.2.5.A17 Erweitertes Monitoring der virtuellen Clients (neu seit Vorjahres-Edition)
Die virtuellen Clients SOLLTEN kontinuierlich darauf überwacht werden, ob die in SYS.2.5.A16 Erweiterte Protokollierung für virtuelle Clients beschriebenen Ereignisse auftreten. Wird ein Security Information and Event Management (SIEM) genutzt, SOLLTEN die virtuellen Clients darin eingebunden werden. Im SIEM SOLLTEN die überwachten Ereignisse auf Anomalien inklusive Angriffsmustern automatisiert analysiert werden. Die virtuellen Clients SOLLTEN automatisch und regelmäßig auf Schwachstellen überprüft werden.
SYS.2.5.A18 Hochverfügbare Bereitstellung der Virtualisierungsinfrastruktur (neu seit Vorjahres-Edition)
Dies SOLLTE durch die zugrundeliegende Virtualisierungsinfrastruktur sichergestellt werden. Die Virtualisierungsserver SOLLTEN redundant an die relevanten Netze angeschlossen werden. Bei Ressourcenknappheit SOLLTEN die virtuellen Clients automatisch zwischen den Virtualisierungsservern migriert werden. Bei Ausfall eines Virtualisierungsservers SOLLTEN die virtuellen Clients automatisiert auf einem anderen Virtualisierungsserver gestartet werden. Die virtuellen Clients SOLLTEN hochverfügbar bereitgestellt werden.
SYS.2.5.A2 Planung der verwendeten Netze für virtuelle Clients (neu seit Vorjahres-Edition)
Die Netze für die Verbindung zwischen zugreifenden Clients und virtuellen Clients sowie die Netze zur Anbindung nachgelagerter Dienste an die virtuellen Clients (z. B. Verzeichnisdienst, E-Mail oder Internetzugriff) MÜSSEN ausreichend leistungsfähig ausgelegt werden. Die Netzsegmente für virtuelle Clients MÜSSEN von Netzsegmenten für Server getrennt sein. Eine bestehende Netztrennung DARF NICHT mithilfe eines virtuellen Clients oder eines Virtualisierungsservers umgangen werden. Für virtuelle Clients MUSS festgelegt werden, ob und in welchem Ausmaß die Kommunikation in nicht vertrauenswürdige Netze eingeschränkt werden soll. Es MUSS geplant werden, welche Netzsegmente für die virtuellen Clients verwendet werden sollen.
SYS.2.5.A3 Schutz vor Schadsoftware auf den virtuellen Clients (neu seit Vorjahres-Edition)
Für die virtuellen Clients MUSS ein Schutz vor Schadsoftware gemäß den Bausteinen OPS.1.1.4 Schutz vor Schadprogrammen und SYS.2.1 Allgemeiner Client sowie unter Berücksichtigung der betriebssystemspezifischen Bausteine umgesetzt werden. Falls die virtuellen Clients mit zentralen Komponenten geschützt werden sollen, MÜSSEN diese zentralen Komponenten über eine ausreichende Leistung verfügen. Falls ein Virenschutzprogramm auf den virtuellen Clients ausgeführt wird, MUSS sichergestellt werden, dass die Leistung der Virtualisierungsinfrastruktur ausreicht. Wird ein Virenschutzprogramm eingesetzt, MUSS festgelegt und dokumentiert werden, ob dieser Schutz zentralisiert in der Virtualisierungsinfrastruktur, dezentralisiert auf den virtuellen Clients oder in Mischformen umgesetzt wird.
SYS.2.5.A4 Verwendung einer dedizierten Virtualisierungsinfrastruktur für die virtuellen Clients (neu seit Vorjahres-Edition)
Die virtuellen Clients SOLLTEN auf einer dedizierten Virtualisierungsinfrastruktur betrieben werden. Virtuelle Server SOLLTEN NICHT auf derselben Virtualisierungsinfrastruktur ausgeführt werden.
SYS.2.5.A5 Zusätzliche Netzsegmentierung für virtuelle Clients (neu seit Vorjahres-Edition)
• Nutzungsszenario für die virtuellen Clients und Gruppenzugehörigkeit der Benutzenden • auf den virtuellen Clients installierte und den Benutzenden zur Verfügung gestellte Anwendungen • für die Funktionsfähigkeit der virtuellen Clients notwendige Netzanbindungen • Vertrauenswürdigkeit der virtuellen Clients • Schutzbedarf der auf den virtuellen Clients verarbeiteten Informationen Folgende Kriterien SOLLTEN für eine zusätzliche Netztrennung der virtuellen Clients berücksichtigt werden: • aus der Gruppenzugehörigkeit abgeleitete Berechtigungen der Benutzenden
SYS.2.5.A6 Keine lokale Datenablage auf virtuellen Clients (neu seit Vorjahres-Edition)
Die Daten SOLLTEN NICHT dauerhaft auf den virtuellen Clients abgelegt werden. Falls eine solche Übertragung nachvollziehbar notwendig ist, SOLLTE sie auf das notwendige Minimum beschränkt werden. Durch die Benutzenden erstellte oder verarbeitete Daten SOLLTEN zentral gespeichert werden. Benutzende, die sich mit virtuellen Clients verbinden, SOLLTEN NICHT in der Lage sein, Daten aus den virtuellen Clients auf ihre lokalen IT-Systeme zu übertragen.