Florian WildeandClaude Opus 5.5
70a3cd2d28
- Woche 13 Linux-Grundlagen (B3, A6, LF9) - Woche 14 Betrieb und Ueberwachung (A8, A5, LF11) - Woche 15 Serviceanfragen bearbeiten (A1, A2, A5, LF6) - Woche 16 Vorbereitung auf Teil 1 (C3, C4, A10, LF2, LF5) 12 Handouts, 36 Merkkarten, 4 Praxisaufgaben, 3 Checklisten, 2 Lernzielkontrollen und eine Probepruefung Teil 1 (90 Minuten, 100 Punkte, eine durchgehende Fallsituation). Alle Rechenbeispiele nachgerechnet. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
4.0 KiB
id, titel, block, woche, worum, rahmenplan, lernfeld, merksatz, karten
| id | titel | block | woche | worum | rahmenplan | lernfeld | merksatz | karten | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| S11 | Updates und Patches – planbar statt hektisch | system | 14 | Die meisten erfolgreichen Angriffe nutzen Lücken, für die es längst ein Update gibt. Patch-Management sorgt dafür, dass Updates zuverlässig ankommen, ohne dass dabei der Betrieb stehen bleibt. |
|
LF11 | Wissen, was läuft. Erst Test, dann Pilotgruppe, dann alle. Kritische Lücken sofort, der Rest im festen Takt. |
|
Das Wesentliche
- Ohne Bestand kein Patch-Management. Man muss wissen, welche Geräte, Betriebssysteme und Programme mit welcher Version im Betrieb laufen. Was nicht in der Liste steht, wird auch nicht aktualisiert.
- Fester Takt: Microsoft veröffentlicht am zweiten Dienstag im Monat. Viele Betriebe planen danach: Test in der Woche danach, Pilotgruppe, dann alle innerhalb von zwei bis drei Wochen.
- Ringe statt alle auf einmal: Testsysteme, Pilotgruppe (die IT selbst und einige freiwillige Nutzer), dann alle. Ein fehlerhaftes Update trifft so zehn Rechner, nicht hundert.
- Kritische Lücken außer der Reihe. Wird eine Lücke bereits aktiv ausgenutzt, wird sofort gehandelt – notfalls mit verkürztem Test. Hinweise liefern der Hersteller und die Warnungen des BSI.
- Nicht nur Windows: Programme wie Browser und PDF-Leser, Firmware von Firewall, Switch, NAS und BIOS, Linux-Server, Smartphones. Gerade Netzwerkgeräte werden oft jahrelang vergessen.
- Server im Wartungsfenster, angekündigt, mit Snapshot oder Sicherung vorher und einem Rückweg, falls etwas schiefgeht.
- Nachprüfen: Kam das Update überall an? Ein Bericht über den Stand aller Geräte gehört zum Abschluss jedes Zyklus.
- End of Life im Blick behalten. Software ohne Sicherheitsupdates wird rechtzeitig ersetzt – das Ende ist Jahre vorher bekannt.
Übersicht
| Ring | Wer | Wann nach Veröffentlichung |
|---|---|---|
| 0 – Test | Testsysteme der IT | sofort |
| 1 – Pilot | IT und einige freiwillige Nutzer | nach 2–3 Tagen |
| 2 – Breit | alle Arbeitsplätze | nach etwa einer Woche |
| 3 – Server | Server im Wartungsfenster | nach etwa zwei Wochen |
| Notfall | alle betroffenen Systeme | sofort, bei aktiv ausgenutzter Lücke |
Prüfungsfrage
Frage: In Ihrem Betrieb werden Updates bisher „wenn jemand Zeit hat" eingespielt. Entwerfen Sie ein Vorgehen für das Patch-Management und begründen Sie zwei Bestandteile.
Antwort: (1) Einen vollständigen Bestand aller Geräte und Programme mit Version führen. (2) Einen festen Takt nach dem monatlichen Patchday festlegen. (3) Updates in Ringen verteilen: Testsysteme, Pilotgruppe, alle Arbeitsplätze, Server im angekündigten Wartungsfenster mit Sicherung vorher. (4) Für aktiv ausgenutzte Lücken ein beschleunigtes Notfallverfahren vorsehen. (5) Nach jedem Zyklus prüfen und berichten, auf welchem Stand alle Geräte sind. (6) Firmware von Netzwerkgeräten und Software ohne automatische Aktualisierung einbeziehen. Begründungen etwa: Die Ringe begrenzen den Schaden eines fehlerhaften Updates auf wenige Geräte. Der Bestand ist Voraussetzung, weil ein Gerät, das niemand kennt, auch nie aktualisiert wird – und genau dort sitzt dann die Lücke.