chrisbst48/itgrundschutzcompendium_2023 huggingface dataset:
SYS.1.8.A17 Dokumentation der Systemeinstellungen von Speichersystemen
Sofern die Dokumentation der Systemeinstellungen vertrauliche Informationen beinhaltet, SOLLTEN diese vor unberechtigtem Zugriff geschützt werden. Die Dokumentation SOLLTE regelmäßig überprüft werden. Sie SOLLTE immer aktuell sein. Alle Systemeinstellungen von Speichersystemen SOLLTEN dokumentiert werden. Die Dokumentation SOLLTE die technischen und organisatorischen Vorgaben sowie alle spezifischen Konfigurationen der Speichersysteme der Institution enthalten.
SYS.1.8.A18 Sicherheitsaudits und Berichtswesen bei Speichersystemen
Es SOLLTE geregelt werden, welche Sicherheitsreports mit welchen Inhalten regelmäßig zu erstellen sind. Zudem SOLLTE auch geregelt werden, wie mit Abweichungen von Vorgaben umgegangen wird und wie oft und in welcher Tiefe Audits durchgeführt werden. Alle eingesetzten Speichersysteme SOLLTEN regelmäßig auditiert werden. Dafür SOLLTE ein entsprechender Prozess eingerichtet werden.
SYS.1.8.A19 Aussonderung von Speicherlösungen
Werden ganze Speicherlösungen oder einzelne Komponenten einer Speicherlösung nicht mehr benötigt, SOLLTEN alle darauf vorhandenen Daten auf andere Speicherlösungen übertragen werden. Anschließend SOLLTEN alle Nutzdaten und Konfigurationsdaten sicher gelöscht werden. Aus allen relevanten Dokumenten SOLLTEN alle Verweise auf die außer Betrieb genommene Speicherlösung entfernt werden. Hierfür SOLLTE eine Übergangsphase eingeplant werden.
SYS.1.8.A2 Sichere Grundkonfiguration von Speicherlösungen
Danach MUSS eine sichere Grundkonfiguration hergestellt werden. Nicht genutzte Schnittstellen des Speichersystems MÜSSEN deaktiviert werden. Die Dateien zur Default-Konfiguration, zur vorgenommenen Grundkonfiguration und zur aktuellen Konfiguration SOLLTEN redundant und geschützt aufbewahrt werden. Bevor eine Speicherlösung produktiv eingesetzt wird, MUSS sichergestellt sein, dass alle eingesetzten Softwarekomponenten und die Firmware aktuell sind.
SYS.1.8.A20 Notfallvorsorge und Notfallreaktion für Speicherlösungen
Nach den Übungen und Tests sowie nach einem tatsächlichen Notfall SOLLTEN die dabei erzeugten Daten sicher gelöscht werden. Es SOLLTE ein Notfallplan für die eingesetzte Speicherlösung erstellt werden. Der Notfallplan SOLLTE genau beschreiben, wie in bestimmten Notfallsituationen vorzugehen ist. Auch SOLLTEN Handlungsanweisungen in Form von Maßnahmen und Kommandos enthalten sein, die die Fehleranalyse und Fehlerkorrektur unterstützen. Um Fehler zu beheben, SOLLTEN geeignete Werkzeuge eingesetzt werden. Regelmäßige Übungen und Tests SOLLTEN anhand des Notfallplans durchgeführt werden.
SYS.1.8.A21 Einsatz von Speicherpools zur Trennung von Mandanten(umbenannt von Einsatz von Speicherpools zur Mandantentrennung in Vorjahres-Edition)
Dabei SOLLTE ein Speichermedium immer nur einem einzigen Pool zugewiesen werden. Die logischen Festplatten (LUNs), die aus einem solchen Pool generiert werden, SOLLTEN nur einem einzigen Mandanten zugeordnet werden. Mandanten SOLLTEN Speicherressourcen aus unterschiedlichen sogenannten Speicherpools zugewiesen werden.
SYS.1.8.A22 Einsatz einer hochverfügbaren SAN-Lösung
Eine hochverfügbare SAN-Lösung SOLLTE eingesetzt werden. Die eingesetzten Replikationsmechanismen SOLLTEN den Verfügbarkeitsanforderungen der Institution an die Speicherlösung entsprechen. Außerdem SOLLTE ein Test- und Konsolidierungssystem vorhanden sein. Auch die Konfiguration der Speicherlösung SOLLTE den Verfügbarkeitsanforderungen gerecht werden.
SYS.1.8.A23 Einsatz von Verschlüsselung für Speicherlösungen
Dabei SOLLTE beachtet werden, dass die Verschlüsselung auf dem Transportweg auch bei Replikationen und Backup-Traffic relevant ist. Alle in Speicherlösungen abgelegten Daten SOLLTEN verschlüsselt werden. Es SOLLTE festgelegt werden, auf welchen Ebenen (Data-in-Motion und Data-at-Rest) verschlüsselt wird.
SYS.1.8.A24 Sicherstellung der Integrität der SAN-Fabric
• Fibre Channel Password Authentication Protocol (FCPAP). Um die Integrität der SAN-Fabric sicherzustellen, SOLLTEN Protokolle mit zusätzlichen Sicherheitsmerkmalen eingesetzt werden. Bei den folgenden Protokollen SOLLTEN deren Sicherheitseigenschaften berücksichtigt und entsprechende Konfigurationen verwendet werden: • Diffie Hellman Challenge Handshake Authentication Protocol (DH-CHAP), • Fibre Channel Authentication Protocol (FCAP) und
SYS.1.8.A25 Mehrfaches Überschreiben der Daten einer LUN
In SAN-Umgebungen SOLLTEN Daten gelöscht werden, indem die zugehörigen Speichersegmente einer LUN mehrfach überschrieben werden.
SYS.1.8.A26 Absicherung eines SANs durch Hard-Zoning
Um SANs zu segmentieren, SOLLTE Hard-Zoning eingesetzt werden.
SYS.1.8.A3 ENTFALLEN
Diese Anforderung ist entfallen.
SYS.1.8.A4 Schutz der Administrationsschnittstellen
Alle Administrations- und Management-Zugänge der Speichersysteme MÜSSEN eingeschränkt werden. Es MUSS sichergestellt sein, dass aus nicht-vertrauenswürdigen Netzen heraus nicht auf die Administrationsschnittstellen zugegriffen werden kann. Es SOLLTEN als sicher geltende Protokolle eingesetzt werden. Sollten dennoch unsichere Protokolle verwendet werden, MUSS für die Administration ein eigenes Administrationsnetz (siehe NET.1.1 Netzarchitektur und -design) genutzt werden.
SYS.1.8.A5 ENTFALLEN
Diese Anforderung ist entfallen.
SYS.1.8.A6 Erstellung einer Sicherheitsrichtlinie für Speicherlösungen
Die Richtlinie SOLLTE allen für Speicherlösungen zuständigen Administrierenden bekannt und grundlegend für ihre Arbeit sein. Ausgehend von der allgemeinen Sicherheitsrichtlinie der Institution SOLLTE eine spezifische Sicherheitsrichtlinie für Speicherlösungen erstellt werden. Darin SOLLTEN nachvollziehbar Vorgaben beschrieben sein, wie Speicherlösungen sicher geplant, administriert, installiert, konfiguriert und betrieben werden können. Wird die Richtlinie verändert oder wird von den Vorgaben abgewichen, SOLLTE dies mit dem oder der ISB abgestimmt und dokumentiert werden. Es SOLLTE regelmäßig überprüft werden, ob die Richtlinie noch korrekt umgesetzt ist. Gegebenenfalls SOLLTE sie aktualisiert werden. Die Ergebnisse SOLLTEN sinnvoll dokumentiert werden.
SYS.1.8.A7 Planung von Speicherlösungen
Darin SOLLTEN folgende Punkte berücksichtigt werden: • Integration in bestehende Prozesse. • Planung der Infrastruktur sowie • Planung des Netzanschlusses, • Entscheidung für oder gegen zentrale Verwaltungssysteme (Management-Systeme), • Auswahl von herstellenden Unternehmen und Liefernden, Bevor Speicherlösungen in einer Institution eingesetzt werden, SOLLTE eine Anforderungsanalyse durchgeführt werden. In der Anforderungsanalyse SOLLTEN unter anderem die Themen Performance und Kapazität betrachtet werden. Auf Basis der ermittelten Anforderungen SOLLTE dann eine detaillierte Planung für Speicherlösungen erstellt werden.
SYS.1.8.A8 Auswahl einer geeigneten Speicherlösung
Die Entscheidungskriterien für eine Speicherlösung SOLLTEN nachvollziehbar dokumentiert werden. Die technischen Grundlagen unterschiedlicher Speicherlösungen SOLLTEN detailliert beleuchtet werden. Die Auswirkungen dieser technischen Grundlagen auf den möglichen Einsatz in der Institution SOLLTEN geprüft werden. Die Möglichkeiten und Grenzen der verschiedenen Speichersystemarten SOLLTEN für die Verantwortlichen der Institution transparent dargestellt werden. Ebenso SOLLTE die Entscheidung für die Auswahl einer Speicherlösung nachvollziehbar dokumentiert werden.
SYS.1.8.A9 Auswahl von Liefernden für eine Speicherlösung(umbenannt von Auswahl von Lieferanten für eine Speicherlösung in Vorjahres-Edition)
Anhand der spezifizierten Anforderungen an eine Speicherlösung SOLLTEN geeignete Liefernde ausgewählt werden. Es SOLLTE genau geregelt werden, wann der Vertrag mit den Liefernden endet. Die SLAs SOLLTEN eindeutig und quantifizierbar sein. Außerdem SOLLTEN Aspekte der Wartung und Instandhaltung schriftlich in sogenannten Service-Level-Agreements (SLAs) festgehalten werden. Die Auswahlkriterien und die Entscheidung SOLLTEN nachvollziehbar dokumentiert werden.
SYS.1.9 Terminalserver
IT-System R2
SYS.1.9.A1 Erstellung einer Sicherheitsrichtlinie für den Einsatz von Terminalservern (neu seit Vorjahres-Edition)
Für den Einsatz von Terminalservern MUSS eine Sicherheitsrichtlinie erstellt werden. • Verschlüsselungsmechanismen und Authentisierungsmethoden, die zwischen Clients und Terminalservern zu benutzen sind, • Netze, aus denen heraus Kommunikationsverbindungen zu den Terminalservern initiiert werden dürfen, • Netze, in die Anwendungen auf den Terminalservern kommunizieren dürfen, • Kommunikationsprotokolle, die zwischen Clients und Terminalservern erlaubt sind, • Anforderungen an die Sicherheit von Clients, auf denen die Terminal-Client-Software ausgeführt wird, • Möglichkeiten, wie Dateien und Anwendungsdaten zusätzlich zur Bildschirmausgabe über das Terminalserver-Protokoll übertragen werden dürfen sowie • physisches Umfeld, in dem die Clients eingesetzt werden dürfen, • Anwendungen, die gemeinsam auf Terminalservern bereitgestellt werden dürfen, • Anwendungen, die auf Terminalservern bereitgestellt werden dürfen, Bei der Erstellung der Sicherheitsrichtlinie MÜSSEN mindestens folgende Punkte berücksichtigt werden: • Peripheriegeräte, die neben Ein- und Ausgabegeräten zusätzlich an den Client angebunden werden dürfen.
SYS.1.9.A10 Einsatz eines zentralen Identitäts- und Berechtigungsmanagements für Terminalserver (neu seit Vorjahres-Edition)
Für die Benutzung von Terminalservern SOLLTE ein zentrales System zum Identitäts- und Berechtigungsmanagement eingesetzt werden.
SYS.1.9.A11 Sichere Konfiguration von Profilen (neu seit Vorjahres-Edition)
Benutzende SOLLTEN ihre spezifischen Einstellungen (Benutzendenprofile) NICHT derart ändern dürfen, dass die Informationssicherheit oder die Nutzung des Terminalservers eingeschränkt wird. Für die Benutzendenprofile SOLLTE eine geeignete maximale Größe festgelegt werden. Wenn Verbünde aus Terminalservern eingesetzt werden, SOLLTEN die Benutzendenprofile zentral abgelegt werden.
SYS.1.9.A12 Automatisches Beenden inaktiver Sitzungen (neu seit Vorjahres-Edition)
Falls eine Sitzung automatisch beendet wird, SOLLTEN die Betroffenen darüber benachrichtigt werden. Wenn eine Sitzung beendet wird, SOLLTE auch der oder die Benutzende automatisch vom Betriebssystem des Terminalservers abgemeldet werden, sofern die Sitzung am Betriebssystem nicht weiterhin für laufende Anwendungen benötigt wird. Inaktive Sitzungen auf Terminalservern SOLLTEN nach einem vordefinierten Zeitraum beendet werden. Der Zeitraum, während dessen eine Sitzung maximal aktiv bleiben soll, SOLLTE abhängig von der jeweiligen Benutzendengruppe festgelegt werden.
SYS.1.9.A13 Protokollierung bei Terminalservern (neu seit Vorjahres-Edition)
• Anbindung von Peripheriegeräten der zugreifenden Clients über das Terminalserver-Protokoll, • Aktionen auf dem Terminalserver durch zugreifende Clients, die erweiterte Rechte benötigen sowie • Konfigurationsänderungen mit Auswirkungen auf den Terminalserver-Dienst. Für die Terminalserver SOLLTE entschieden werden, welche Ereignisse an eine zentrale Protokollierungsinfrastruktur (siehe OPS.1.1.5 Protokollierung) übermittelt werden sollen. Hierbei SOLLTEN mindestens die folgenden spezifischen Ereignisse an Terminalservern protokolliert werden:
SYS.1.9.A14 Monitoring des Terminalservers (neu seit Vorjahres-Edition)
Der Terminalserver SOLLTE zentral überwacht werden. • Latenz an den verbundenen Clients unter Berücksichtigung der jeweiligen Anforderungsprofile. Für das Monitoring SOLLTEN vorab die jeweiligen Schwellwerte ermittelt werden (Baselining). Diese Schwellwerte SOLLTEN regelmäßig überprüft und bei Bedarf angepasst werden. • verfügbare und genutzte Bandbreite der verbundenen Clients sowie • Auslastung der Netzschnittstellen des Terminalservers, • Auslastung der Ressourcen des Terminalservers, Hierfür SOLLTEN mindestens folgende Parameter überwacht werden:
SYS.1.9.A15 Härtung des Terminalservers (neu seit Vorjahres-Edition)
Ist das nicht möglich, SOLLTE deren Ausführung unterbunden werden. Nicht benötigte Anwendungen auf dem Terminalserver SOLLTEN entfernt werden. Der Zugriff aus einer Sitzung auf Peripheriegeräte SOLLTE auf die benötigten Geräte eingeschränkt werden.
SYS.1.9.A16 Optimierung der Kompression (neu seit Vorjahres-Edition)
Der Grad der Kompression bei der Übertragung der Daten von und zum Terminalserver SOLLTE entsprechend der Anforderungen der jeweiligen Anwendung an die grafische Qualität optimiert werden. Die Anforderungen der bereitgestellten Anwendungen an Genauigkeit von grafischen Elementen, an Farbtreue und die für die Nutzung notwendige Bildrate SOLLTEN berücksichtigt werden.
SYS.1.9.A17 Verschlüsselung der Übertragung (neu seit Vorjahres-Edition)
Jegliche Kommunikation zwischen Client und Terminalserver SOLLTE geeignet verschlüsselt werden. Dabei SOLLTEN sichere Protokolle gemäß BSI TR-02102 verwendet werden.
SYS.1.9.A18 Nutzung von Thin Clients (neu seit Vorjahres-Edition)
Physische Thin Clients SOLLTEN verwendet werden. Es SOLLTEN NUR Thin Clients eingesetzt werden, die das Unternehmen, das die Terminal-Client-Software herstellt, als kompatibel ausgewiesen hat.
SYS.1.9.A19 Erweitertes Monitoring des Terminalservers (neu seit Vorjahres-Edition)
Wird ein Security Information and Event Management (SIEM) genutzt, SOLLTE der Terminalserver darin eingebunden werden. Im SIEM SOLLTEN die überwachten Ereignisse hinsichtlich Anomalien inklusive Angriffsmustern automatisiert analysiert werden. Der Terminalserver SOLLTE regelmäßig auf Schwachstellen überprüft werden. Für den Terminalserver SOLLTE kontinuierlich überwacht werden, ob die in SYS.1.9.A13 Protokollierung bei Terminalservern beschriebenen Ereignisse auftreten.
SYS.1.9.A2 Planung des Einsatzes von Terminalservern (neu seit Vorjahres-Edition)
Das Lizenzschema der eingesetzten Anwendungen MUSS daraufhin geprüft werden, ob es dafür geeignet ist, diese Anwendungen auf Terminalservern einzusetzen. Für die Anwendungen, die auf einem Terminalserver bereitgestellt werden sollen, MÜSSEN die Anforderungen an die Funktionalität (Anforderungsprofil) ermittelt werden. Für alle benötigten Funktionen MUSS sichergestellt werden, dass diese tatsächlich auch über den Terminalserver abgerufen werden können. Darüber hinaus MUSS getestet werden, ob die Anwendungen die Anforderungen bei der Bereitstellung über den Terminalserver grundlegend erfüllen. Die Gesamtzahl der einzurichtenden Benutzenden MUSS prognostiziert werden. Dabei MÜSSEN alle Anwendungen mitgezählt werden, die auf dem Terminalserver bereitgestellt werden. Die Anzahl der Benutzenden, die den Terminalserver potenziell gleichzeitig benutzen, MUSS prognostiziert werden. Diese Prognosen MÜSSEN den Einsatzzeitraum des Terminalservers abdecken. Abhängig von der prognostizierten Anzahl der Benutzenden und den Anforderungen der bereitgestellten Anwendungen MÜSSEN die Leistungsanforderungen (z. B. hinsichtlich CPU und Arbeitsspeicher) an den Terminalserver ermittelt werden. Der Terminalserver MUSS anhand dieser Leistungsanforderungen dimensioniert und ausgestattet werden.
SYS.1.9.A20 Unterschiedliche Terminalserver für unterschiedliche Gruppen von Benutzenden oder Geschäftsprozesse (neu seit Vorjahres-Edition)
Ist dies nicht möglich, SOLLTEN dedizierte Terminalserver pro Geschäftsprozess eingesetzt werden. Ein Terminalserver SOLLTE NICHT mehreren Gruppen von Benutzenden zur Verfügung gestellt werden. Die Benutzenden von Terminalservern SOLLTEN anhand ähnlicher Berechtigungen und benötigter Anwendungen gruppiert werden.
SYS.1.9.A21 Nutzung hochverfügbarer IT-Systeme (neu seit Vorjahres-Edition)
Dazu SOLLTEN der Terminalserver sowie dessen Netzanbindung redundant ausgelegt werden. Der Terminalserver SOLLTE hochverfügbar betrieben werden. Für die zugreifenden Clients SOLLTEN Ersatzgeräte bereitgehalten werden. Die verwendeten Terminalserver SOLLTEN im Verbund betrieben werden.
SYS.1.9.A22 Unterbinden des Transfers von Anwendungsdaten zwischen Client und Terminalserver (neu seit Vorjahres-Edition)
Auch der Transfer der Zwischenablage SOLLTE deaktiviert werden. Der Transfer von Anwendungsdaten zwischen dem Client und dem Terminalserver SOLLTE deaktiviert werden.
SYS.1.9.A3 Festlegung der Rollen und Berechtigungen für den Terminalserver (neu seit Vorjahres-Edition)
• Zugriff auf das Dateisystem des Terminalservers, Auf Terminalservern DÜRFEN KEINE Sammelkonten verwendet werden, wenn dies gegen interne Regelungen oder Lizenzbedingungen verstößt. • Datei- und Objekttransfer zwischen Clients und Terminalservern (z. B. zum Drucken am Client) sowie • Anbindung von Peripheriegeräten am Client. Bei der Festlegung von Rollen und Berechtigungen für die Benutzung des Terminalservers MÜSSEN alle auf dem Terminalserver bereitgestellten Anwendungen und deren Anforderungen mit ausreichenden Berechtigungen ausgestattet werden. Die Rollen und Berechtigungen MÜSSEN so vergeben werden, dass zwischen Terminalserver-Sitzungen nur in dem Umfang kommuniziert werden kann, wie es für die Funktionalität der Anwendung erforderlich ist. Mindestens MÜSSEN die Berechtigungen für folgende Tätigkeiten festgelegt werden: • Ausführen von Anwendungen in fremdem Kontext (insbesondere als „root“), • Zugriff auf betriebssystemspezifische Funktionen, • Zugriff auf Schnittstellen und Dateisystem des verwendeten zugreifenden Clients, • Zugriff der auf dem Terminalserver bereitgestellten Anwendungen auf nachgelagerte Dienste,
SYS.1.9.A4 Sichere Konfiguration des Terminalservers (neu seit Vorjahres-Edition)
Ist dies der Fall, MÜSSEN diese für die Erstellung der Konfigurationsvorgaben angemessen berücksichtigt werden. Sowohl die Konfigurationsvorgaben als auch deren Umsetzung MÜSSEN regelmäßig geprüft und gegebenenfalls angepasst werden. Es MÜSSEN mindestens folgende Punkte für die Konfigurationsvorgaben berücksichtigt werden: • Rollen und Berechtigungen • Umfang der Verschlüsselung des Terminalserver-Protokolls • benötigte Authentisierungsfunktionen des Terminalserver-Protokolls Abhängig von den Anforderungen an die Sicherheit und Funktionalität der bereitgestellten Anwendungen MÜSSEN Vorgaben für die Konfiguration von Terminalservern erstellt werden. • Möglichkeit zum Anzeigen der Ausgabe fremder Sitzungen • Kommunikation zwischen Anwendungen in den Terminalserver-Sitzungen und Anwendungen auf anderen Servern • Kommunikation zwischen Terminalserver und anderen Servern Diese Vorgaben MÜSSEN vollständig umgesetzt und dokumentiert werden. Es MUSS geprüft werden, ob das Unternehmen, das den Terminalserver herstellt, Vorgaben oder Empfehlungen zur sicheren Konfiguration oder Härtung bereitstellt.
SYS.1.9.A5 Planung der eingesetzten Clients und Terminal-Client-Software (neu seit Vorjahres-Edition)
Zusätzlich MUSS festgelegt werden, auf welchen Clients diese Software ausgeführt werden darf, um sich mit dem Terminalserver zu verbinden. • Einsatz von Thin Clients oder Fat Clients, • Hardware-Konfiguration der zugreifenden Clients sowie • Betriebssystem der zugreifenden Clients. Es MUSS festgelegt werden, welche Software neben der Terminal-Client-Software zusätzlich auf den Clients zugelassen ist. Zusätzlich MUSS festgelegt werden, ob ein Client parallel Anwendungen auf unterschiedlichen Terminalservern benutzen darf. Es MUSS festgelegt werden, über welche Terminal-Client-Software auf den Terminalserver zugegriffen werden darf. Hierbei MÜSSEN mindestens die folgenden Punkte berücksichtigt werden:
SYS.1.9.A6 Planung der verwendeten Netze (neu seit Vorjahres-Edition)
Die Netze, über die Clients mit Terminalservern kommunizieren, MÜSSEN anhand der Anforderungen der bereitgestellten Anwendungen geplant und gegebenenfalls angepasst werden. • maximal tolerierbare Latenzzeit des Netzes. • maximal vertretbarer Jitter sowie • maximal vertretbarer Paketverlust, • benötigte Übertragungskapazität, • zu erwartende Anzahl gleichzeitiger Terminalserver-Sitzungen, Hierbei MÜSSEN mindestens folgende Punkte berücksichtigt werden:
SYS.1.9.A7 Sicherer Zugriff auf den Terminalserver (neu seit Vorjahres-Edition)
Es MUSS festgelegt werden, über welche Netze zwischen zugreifendem Client und Terminalserver kommuniziert werden darf. Zusätzlich MUSS festgelegt werden, wie die Kommunikation abgesichert werden soll. Es MUSS festgelegt werden, ob und wie mit dem Terminalserver-Protokoll verschlüsselt werden soll. Falls das Terminalserver-Protokoll in diesem Fall keine ausreichende Verschlüsselung bietet, MUSS die Kommunikation zusätzlich abgesichert werden. Falls die Clients und der Terminalserver über unzureichend vertrauenswürdige Netze kommunizieren, MÜSSEN sich sowohl die Benutzenden als auch der Terminalserver beim Kommunikationsaufbau authentisieren.
SYS.1.9.A8 Sichere Zuordnung des Terminalservers zu Netzsegmenten (neu seit Vorjahres-Edition)
Der Terminalserver MUSS in dedizierten Netzsegmenten oder in Client-Netzsegmenten positioniert werden. Eine bestehende Netztrennung DARF NICHT über einen Terminalserver umgangen werden können. Innerhalb von Client-Netzsegmenten MÜSSEN Terminalserver identifizierbar sein.
SYS.1.9.A9 Sensibilisierung der Benutzenden (neu seit Vorjahres-Edition)
• genutzte Authentisierung und Autorisierung der Benutzenden für die zur Verfügung gestellten Anwendungen • mögliche und erlaubte Speicherorte von Daten • zugelassene Austauschmöglichkeiten von Informationen zwischen dem Betriebssystem des Clients und dem Terminalserver (z. B. Zwischenablage) • Auswirkung des eigenen Ressourcenverbrauchs auf die zur Verfügung stehenden Ressourcen für andere Benutzende • eingerichtete Rollen und Berechtigungen für Terminalserver-Zugriffe • maximale Sitzungsdauer und automatische Abmeldevorgänge Alle Benutzenden von Terminalservern MÜSSEN über den sicheren Umgang mit Terminalservern sensibilisiert werden. Den Benutzenden MÜSSEN mindestens die folgenden Inhalte vermittelt werden: • grundsätzliche Funktionsweise und die Auswirkungen von Latenz und verfügbarer Bandbreite auf die Bedienbarkeit
SYS.2.1 Allgemeiner Client
IT-System R2
SYS.2.1.A1 Sichere Authentisierung von Benutzenden(umbenannt von Sichere Benutzerauthentisierung in Vorjahres-Edition)
Die Bildschirmsperre DARF NUR durch eine erfolgreiche Authentisierung wieder deaktiviert werden können. Die Bildschirmsperre SOLLTE automatisch aktiviert werden, wenn für eine festgelegte Zeitspanne keine Aktion durch Benutzende durchgeführt wurde. Benutzende SOLLTEN verpflichtet werden, sich nach Aufgabenerfüllung vom IT-System bzw. von der IT-Anwendung abzumelden. Benutzende MÜSSEN eine Bildschirmsperre verwenden, wenn sie den Client unbeaufsichtigt betreiben. Um den Client zu nutzen, MÜSSEN sich die Benutzenden gegenüber dem IT-System authentisieren.
SYS.2.1.A10 Planung des Einsatzes von Clients
Es SOLLTE im Vorfeld geplant werden, wo und wie Clients eingesetzt werden sollen. Alle Entscheidungen, die in der Planungsphase getroffen wurden, SOLLTEN so dokumentiert werden, dass sie zu einem späteren Zeitpunkt nachvollzogen werden können. Die Planung SOLLTE dabei nicht nur Aspekte betreffen, die typischerweise direkt mit den Begriffen IT- oder Informationssicherheit in Verbindung gebracht werden, sondern auch betriebliche Aspekte, die Anforderungen im Bereich der Sicherheit nach sich ziehen.
SYS.2.1.A11 Beschaffung von Clients
Auf Betriebssysteme, die über ein Rolling-Release-Modell aktualisiert werden, SOLLTE verzichtet werden. Die jeweiligen herstellenden Unternehmen von IT- und Betriebssystem SOLLTEN für den gesamten geplanten Nutzungszeitraum Patches für Schwachstellen zeitnah zur Verfügung stellen. Die zu beschaffenden Systeme SOLLTEN über eine Firmware-Konfigurationsoberfläche für UEFI SecureBoot und, sofern vorhanden, für das TPM verfügen, die eine Kontrolle durch die Institution gewährleistet und so den selbstverwalteten Betrieb von SecureBoot und des TPM ermöglicht. Bevor Clients beschafft werden, SOLLTE eine Anforderungsliste erstellt werden, anhand derer die am Markt erhältlichen Produkte bewertet werden.
SYS.2.1.A12 ENTFALLEN
Diese Anforderung ist entfallen.