+ASST.5 Wartung
---+ASST.5.1 Wartungsbedarf dokumentieren
---+ASST.5.2 Geregelte Wartungen
---+ASST.5.3 Autorisierung von Wartungen
---+ASST.5.4 Behandlung als Änderungen und Tests
---+ASST.5.5 Wartungsfenster
---+ASST.5.6 Wartung durch Externe
---+ASST.5.7 Dokumentation von Wartungen
|
ASST.5 Wartung
1. Ħarsa ġenerali
| Titlu |
Standard |
|
ASST.5.1 Wartungsbedarf dokumentieren
|
Informationen und Assets für IT-Systeme SOLLTE den Wartungsbedarf für Systemkomponenten und die zum Betrieb erforderliche Infrastruktur dokumentieren. Erläuterung Wartungsbedarf meint die regelmäßig oder anlassbezogen erforderlichen Maßnahmen zur Instandhaltung, Aktualisierung und Funktionssicherung von Systemkomponenten und der Betriebsinfrastruktur eines IT-Systems. Unter Systemkomponenten sind hier sowohl Hardware-Elemente (Server, Netzwerkkomponenten, Speichergeräte) als auch Software-Elemente (Betriebssysteme, Middleware, Anwendungen) zu verstehen; die Infrastruktur umfasst unterstützende Einrichtungen wie Stromversorgung, Klimatisierung, Kommunikationsschnittstellen oder Brandabschottungen für Kabel- und Rohrdurchführungen. Ziel der Dokumentation ist es, einen strukturierten Überblick über alle Abhängigkeiten, Wartungszyklen und Zuständigkeiten zu schaffen, um sicherzustellen, dass Betrieb und Sicherheit des Systems über den gesamten Lebenszyklus hinweg gewährleistet bleiben. Die Dokumentation des Wartungsbedarfs kann verhindern, dass kritische Komponenten ungeplant ausfallen oder Sicherheitslücken durch versäumte Updates bestehen bleiben. Ohne klare Wartungsinformationen könnte beispielsweise ein Firmware-Update bei einer Netzkomponente übersehen werden, was Angreifern das Eindringen über bekannte Schwachstellen erleichtern könnte. Umgekehrt kann eine dokumentierte Wartungsplanung dazu beitragen, Systemverfügbarkeit und Integrität zu sichern, indem sie planbare Wartungsfenster und Zuständigkeiten ermöglicht. Durch das Zusammenführen der Herstellerangaben mit den vor Ort bekannten Rahmenbedingungen kann frühzeitig erkennbar werden, wann Eingriffe nötig sind, welche Abhängigkeiten bestehen und welche Fachkenntnisse oder Werkzeuge erforderlich sein können. Zum Ressourcenbedarf kann ebenso gehören, dass ein Testsystem bereitgestellt wird, dass administrative Zugänge vorbereitet werden oder dass ein Wartungsdienstleister während der Arbeiten abgesichert fernzugreifen kann. Für die praktische Umsetzung kann es hilfreich sein, einen zentralen Wartungskalender mit Ampel‑Logik zu führen, der sich aus dem Konfigurations‑ oder Asset‑Management speist. Eine Ticket‑ oder Change‑Management‑Lösung kann automatisch Termine auslösen, Erinnerungen versenden und Reports erzeugen.
|
|
ASST.5.2 Geregelte Wartungen
|
Informationen und Assets für IT-Systeme SOLLTE die Wartung [regelmäßig oder prädiktiv] ausführen. Erläuterung „Wartung“ bezeichnet hier sämtliche planmäßigen oder zustandsabhängigen Maßnahmen zur Erhaltung der Funktionsfähigkeit, Sicherheit und Integrität von IT-Systemen, Anwendungen und den zugehörigen physischen wie logischen Assets („maintenance“). Verschleißende Systeme und Infrastrukturen könnten zu Fehlerzuständen und hierdurch zu Ausfallzeiten und Sicherheitsrisiken führen. Das betrifft auch die für das IT-System verwendete Stromversorgung, USV, Klimatechnik, sowie Brandabschottungen für Kabel- und Rohrdurchführungen. Beispiele hierfür können vielfältig sein: Ein Server kann turnusmäßig mit Firmware‑Updates versorgt oder nach einer bestimmten Betriebsdauer auf Staubablagerungen überprüft werden; Netzwerkkomponenten können per Lifecycle‑Plan aktualisiert oder lüfterseitig gereinigt werden; USV‑Batterien können nach Herstellerempfehlung getauscht werden; Software‑Module können per Patch‑Management in ein Wartungsfenster eingeplant werden. Eine „regelmäßige Wartung“ bedeutet hierbei ein turnusmäßiges Vorgehen nach festen Zeitintervallen (Vorausbestimmte Instandhaltungsstrategie), während prädiktive Wartung den tatsächlichen Abnutzungs- oder Belastungszustand auswertet, um Eingriffe bedarfsgerecht zu planen (Prädiktive Instandhaltungsstrategie). Beide Ansätze verfolgen das Ziel, Sicherheits- und Betriebsrisiken zu minimieren, die aus dem Ausfall oder der Fehlfunktion technischer Komponenten resultieren könnten.
|
|
ASST.5.3 Autorisierung von Wartungen
|
Informationen und Assets für IT-Systeme KANN Wartungen durch [eine zuständige Person oder Rolle] autorisieren. Erläuterung Wartung ist die planbare oder anlassbezogene Änderung an Komponenten (z. B. Patches, Konfigurationsänderungen, Hardwaretausch, Firmware-Updates). Dies betrifft auch den Transfers des Systems oder von Komponenten für Reparatur oder Austausch an einem anderen Ort. Unklare oder fehlende Freigaben für Wartungen könnten zu unkoordinierten Änderungen, ungeplanten Ausfällen, Datenverlust oder der Einschleusung von Schadcode durch interne wie externe Dienstleister führen; außerdem könnten unpassende Zeitfenster oder inkompatible Firmwarestände Vertraulichkeit, Integrität und Verfügbarkeit beeinträchtigen. Zur Umsetzung kann die Institution ein schlankes Freigabeverfahren gestalten, z.B. (1) ein standardisiertes Wartungs-Ticket mit Pflichtangaben (Asset-ID, Maßnahme, Risiko-Einschätzung, Zeitfenster, Back-out-Plan, Ansprechpartner), das über CMDB-Bezüge (Konfigurationsdatenbank) automatisch an Asset-/Service-Owner geroutet und dort freigegeben werden kann; (2) technische Gates, sodass produktive Änderungen erst im Status „autorisiert“ durch CI/CD-Pipelines (Build-/Deployment-Kette), Change-Flags oder Just-in-Time-Privilegien mit zeitlich begrenzten Admin-Konten ausgeführt werden können; (3) ein Katalog vordefinierter, niedrig-riskanter Standardwartungen (z. B. Signatur-Updates, agentenlose Log-Rotation), die vorab genehmigt und ohne Einzelfallprüfung ausgelöst werden können.
|
|
ASST.5.4 Behandlung als Änderungen und Tests
|
Informationen und Assets für IT-Systeme SOLLTE zur Wartung erforderliche Änderungen im Einklang mit den Verfahren und Regelungen zum Management von Änderungen verankern. Erläuterung Werden bei Wartungsarbeiten Änderungen vorgenommen, so sind die Verfahren und Regelungen zum Management von Änderungen auch hier anzuwenden. Ein nicht abgestimmter oder ungetesteter Eingriff könnte etwa zu Systemausfällen, Datenverlust oder dem Einbringen von Schwachstellen führen, während ein geordnetes Änderungsmanagement solche Risiken deutlich reduzieren kann. Sinnvoll ist oft ein kurzer Wartungsleitfaden, in dem typische Abläufe (z. B. Vorab‑Backup, Rollback‑Option, Dokumentation des Ergebnisses) hinterlegt werden. Auf diese Weise kann jede Wartung reproduzierbar, überprüfbar und ressourcenschonend gestaltet werden, ohne sich auf konkrete Herstellerprodukte festzulegen.
|
|
ASST.5.5 Wartungsfenster
|
Informationen und Assets für IT-Systeme SOLLTE bei voraussichtlichen Verfügbarkeiteinschränkungen durch bevorstehende Wartungen die Nutzenden über Dauer und Umfang der Einschränkungen informieren. Erläuterung Wenn durch Wartungsarbeiten die Verfügbarkeit von Systemen, Anwendungen oder Daten in Geschäftsprozessen beeinträchtigt werden könnte, ist eine Information über die bevorstehende Wartung sinnvoll. Dazu gehört, dass über die Dauer (Beginn und Ende), sowie über den Umfang der Einschränkungen (z.B. betroffene Anwendungen, Netze oder Funktionen) informiert wird. Beispiele sind Firmware- oder Betriebssystemupdates von zentralen Speichersystemen oder Netzkomponenten, der Austausch von Komponenten an zentralen Stromverteilern oder eine Wartung an den Klimasystemen eines nicht redundant ausgelegten Serverraumes.
|
|
ASST.5.6 Wartung durch Externe
|
Informationen und Assets für Mitarbeitende KANN bei Wartungen, die von Externen ohne Sicherheitsüberprüfung vorgenommen werden, zur Beaufsichtigung durch internes Personal anweisen. Erläuterung Eine Sicherheitsüberprüfung bezeichnet hier die systematische Bewertung der Vertrauenswürdigkeit und Zuverlässigkeit von externen Dienstleistern oder deren Personal durch background checks, Referenzprüfungen oder formelle Sicherheitsclearance-Verfahren. Externe ohne Sicherheitsüberprüfung umfasst alle Dienstleister, Wartungstechniker oder Support-Personal von Drittanbietern, die nicht durch entsprechende Verfahren zur Vertrauenswürdigkeit validiert wurden. Beaufsichtigung durch internes Personal ist die kontinuierliche Anwesenheit und Überwachung von qualifizierten eigenen Mitarbeitenden während der gesamten Dauer der Wartungsarbeiten, um sowohl fachliche Aufsicht als auch Sicherheitskontrolle zu gewährleisten. Dazu gehört, dass die begleitenden Mitarbeitenden sicherstellen, dass Externe ausschließlich auf die für ihre Wartungsaufgabe notwendigen Systembereiche zugreifen und keine unauthorisierten Aktionen wie das Kopieren von Dateien oder die Installation nicht genehmigter Software durchführen. Externe Wartungskräfte ohne Sicherheitsüberprüfung könnten sonst vertrauliche Informationen einsehen, kopieren oder manipulieren, Malware einschleusen oder unbeabsichtigt Systemkonfigurationen beschädigen. Durch begleitendes internes Personal kann eine Institution kontinuierliche Aufsicht über alle durchgeführten Aktivitäten sicherstellen und gleichzeitig den Wissenstransfer für zukünftige Wartungsarbeiten fördern. Bei einer Fernwartung kann dies z.B. durch das Logging von Diagnose- und Wartungsaktivitäten, sowie die anschließende Überprüfung, dass alle Wartungsverbindungen getrennt sind, geschehen.
|
|
ASST.5.7 Dokumentation von Wartungen
|
Informationen und Assets für IT-Systeme SOLLTE Wartungen mit Asset, Anlass, Zeitpunkt, Beteiligten, durchgefürten Maßnahmen und Ergebnissen dokumentieren. Erläuterung Die Dokumentation von Wartungen an IT-Systemen kann Nachvollziehbarkeit, Verantwortlichkeit und Beweisfähigkeit herstellen; ohne sie könnten unerkannte Konfigurationsänderungen, verdeckte Schwachstellen oder verlängerte Ausfälle entstehen. Zur Umsetzung kann die Institution ein schlankes, einheitliches Wartungsprotokoll verwenden, das je Vorgang erfasst: (1) eindeutig referenziertes Asset/CI, Umgebung und betroffener Service, (2) Anlass, Art der Wartung (präventiv/korrektiv/notfall) und geplanter Zeitraum, (3) Verantwortliche, Beteiligte/Dienstleister und Kontakt, (4) geplante Maßnahmen, Backout-Plan sowie definierte Vor-/Nach-Checks, (5) tatsächlich durchgeführte Schritte („as-built“), verwendete Versionen/Images und geänderte Parameter, (6) Messergebnisse/Logs/Screenshots/Hashes als Nachweis, (7) Auswirkungen (Downtime, Kapazität), Abnahme/Testresultat und Freigabe, (8) Verweise auf Tickets/Changes/Störungsmeldungen, (9) Datum/Zeit mit Zeitzone und Protokollversion. Die Erfassung kann in einem vorhandenen Ticket- oder CMDB-Werkzeug stattfinden.
|
1.1 Referenzi
1.2 Rekwiżiti identifikati
1.3 Regolamenti relatati
2. Rekwiżiti identifikati
3. Regolamenti relatati
Regolamenti
| Sors |
Regolamentazzjoni |
|