Block 10 · Netzwerk, IoT & Infrastruktur – Lösungen

a) Zuordnung (3 P)

b) Aufgaben der Gateways (2 P)

• Sie empfangen die Funknachrichten (LoRa, 868 MHz) aller Messstellen, Hochbehälter und Pumpstationen in ihrer Reichweite.
• Sie setzen Funk auf IP um und leiten die Pakete über das LAN des Standorts und das Internet an den Network Server im Rechenzentrum weiter (Protokollumsetzung, Bündelung vieler Geräte auf eine IP-Verbindung).
• Sie senden Downlink-Nachrichten des Network Servers an die Endgeräte, z. B. Befehle an Schieber und Pumpen oder neue Einstellungen (Sendeintervall, Spreading Factor).

Erklärung: Sensor = liest die Umwelt (Wasserstand, Durchfluss), Aktor = verändert sie (Schieber, Pumpe). Typischer Fehler: Den Durchflussmesser als Aktor einordnen, weil er „in der Leitung sitzt“ – er misst aber nur.

a) Funktechnik wählen (6 P)

b) Duty Cycle prüfen (3 P)

erlaubte Sendezeit:     1 % von 3600 s            = 36 s pro Stunde
Nachrichten pro Stunde: 60 min ÷ 2 min            = 30
benötigte Sendezeit:    30 × 1,48 s (SF12)        = 44,4 s pro Stunde
Vergleich:              44,4 s > 36 s  →  Duty Cycle wird überschritten, nicht zulässig

(Höchstens 36 s ÷ 1,48 s = 24,3 → 24 Nachrichten pro Stunde, also frühestens alle 2,5 Minuten.)

c) Maßnahme (1 P)

Eine der folgenden: mit kleinerem Spreading Factor senden, z. B. SF9: 30 × 0,21 s = 6,3 s ≤ 36 s (nur bei ausreichendem Empfang, ADR) · Intervall auf mindestens 2,5 Minuten verlängern (z. B. 3 Minuten) · mehrere Messwerte sammeln und gebündelt in einer Nachricht senden · zusätzliches Gateway näher an der Messstelle, damit ein kleinerer SF reicht.

Erklärung: Bei Auswahlfragen erst die K.-o.-Kriterien prüfen (Video → hohe Datenrate; Batterie → kein WLAN/5G; km-Entfernung → kein BLE/WLAN) und dann mit Anlagenwerten argumentieren. Typischer Fehler bei b): mit 15 statt 2 Minuten rechnen oder 1 % von 60 Minuten als 0,6 s ansetzen.

aa) Drei Merkmale aus dem Text (3 P)

Drei der folgenden: offenes Netzwerkprotokoll für LPWAN und batteriebetriebene Geräte · basiert auf der LoRa-Modulation (Chirp Spread Spectrum), sehr störfest, Empfang sogar unterhalb des Rauschpegels · große Reichweite: ländlich über 10 km, in Städten und hügeligem/bewaldetem Gelände 2–5 km · Stern-von-Sternen-Topologie, Endgeräte keinem Gateway zugeordnet · lizenzfreie Frequenzbänder (868 MHz), keine Gebühren, aber Duty Cycle von 1 % · geringe Datenrate (ca. 0,3–50 kbit/s) und nur 51–222 Byte Nutzdaten je Nachricht, ungeeignet für Bilder/Audio/Video · sehr geringer Energiebedarf, Batterie bis zu zehn Jahre · AES-128: Integritätsschutz und Ende-zu-Ende-Verschlüsselung der Nutzdaten.

ab) Zwei Gründe für die Pegelmessstellen (4 P)

• Geringer Energiebedarf: Die Messstellen haben keinen Stromanschluss. LoRaWAN-Geräte schlafen fast immer und senden nur kurz, die Batterie hält bis zu zehn Jahre. Dadurch sind keine Stromleitungen nötig und kaum Wartungsfahrten zu den 38 entlegenen Messstellen.
• Große Reichweite: Die Messstellen liegen bis zu 14 km entfernt verteilt über 420 km². Mit mehreren Kilometern Reichweite je Gateway decken die drei vorhandenen Gateways GW1–GW3 das Gebiet weitgehend ab; Kabel oder Mobilfunkverträge je Messstelle entfallen.
• Ebenfalls richtig: Die Datenmenge ist klein (11 Byte alle 15 Minuten), die geringe Datenrate reicht also; lizenzfreies Band → keine laufenden Funkgebühren für 38 Messstellen · eingebaute AES-Verschlüsselung schützt die für die Hochwasserwarnung wichtigen Werte.

ac) Empfang durch zwei Gateways (2 P)

Jedes Gateway in Reichweite leitet die Nachricht weiter, sie kommt also doppelt (als Duplikat) beim Network Server an. Der Network Server erkennt das Duplikat, verwirft es und prüft die Integrität, sodass der Messwert nur einmal an den Application Server bzw. die Datenbank gelangt. Positiver Nebeneffekt: Fällt GW1 aus, kommt die Nachricht trotzdem über GW2 an.

b) JSON-Objekt für P-23 (4 P)

{
  "devEUI": "4D:57:41:00:00:00:02:03",
  "messstelle": "P-23 Aue, Wehr Kleinfeld",
  "batterie": 34,
  "messwerte": [
    { "zeitstempel": "2026-10-08T06:15:00Z", "wasserstand_cm": 311, "temperatur_c": 10.4 },
    { "zeitstempel": "2026-10-08T06:30:00Z", "wasserstand_cm": 318, "temperatur_c": 10.3 }
  ]
}

c) Stellungnahme zu RSA auf der Messstelle (4 P)

Der Vorschlag ist nicht sinnvoll:

• RSA ist ein asymmetrisches Verfahren und deutlich rechen- und damit energieaufwendiger als symmetrische Verfahren. Der schwache Mikrocontroller (48 MHz, 32 KB RAM) bräuchte lange und würde die Batterie stark belasten – die angestrebte Laufzeit von vielen Jahren wäre gefährdet.
• Ein RSA-2048-Chiffrat ist immer 256 Byte groß. Eine LoRaWAN-Nachricht trägt aber nur 51 bis 222 Byte Nutzdaten (Anlage 4) – aus 11 Byte Messwert würde eine Nachricht, die gar nicht hineinpasst; außerdem stiege die Sendezeit (Duty Cycle).
• Zusätzliche Verschlüsselung ist unnötig: LoRaWAN verschlüsselt die Nutzdaten bereits Ende-zu-Ende mit AES-128 und sichert mit einem zweiten Schlüssel die Integrität.
• Empfehlung: die eingebaute symmetrische AES-128-Verschlüsselung nutzen, mit individuellen Schlüsseln je Messstelle (Aktivierung per OTAA). Falls doch asymmetrisch (z. B. für Signaturen von Firmware-Updates), dann elliptische Kurven (ECC) statt RSA.

d) Edge Computing (3 P)

Bei Edge Computing werden Daten direkt am Entstehungsort verarbeitet – hier in einer lokalen Steuerung (z. B. SPS oder Edge-Gateway) am Hochbehälter. Die Regel „Füllstand ≥ Grenzwert → Zulaufschieber schließen“ wird lokal ausgewertet und der Aktor direkt angesteuert, ohne Umweg über das Rechenzentrum. Dadurch funktioniert der Überfüllschutz auch bei gestörter Verbindung und reagiert sofort (keine Übertragungs- oder Duty-Cycle-Wartezeit). Das Rechenzentrum erhält weiterhin Messwerte und Statusmeldungen für Dashboard und Langzeitauswertung, sobald die Verbindung wieder steht.

Erklärung: Das ist der Aufgabentyp aus S26 (englischer LoRa-Text, RSA-Fangfrage) und S23 (Verschlüsselung auf batteriebetriebenen Sensoren, JSON-Messwerte). Typische Fehler: in aa) Merkmale nennen, die nicht im Text stehen (z. B. Geräteklassen); in b) Komma nach dem letzten Array-Element oder Dezimalkomma; in c) nur „RSA ist sicher“ – die Frage zielt auf die Eignung für schwache Geräte.

a) Tabelle (3 P)

b) Topologien (3 P)

• ba) Stern: alle Geräte hängen am zentralen Switch SW2 (mit AP2 als weiterem Verteiler genau genommen ein erweiterter Stern/Baum – ebenfalls richtig).
• bb) Stern von Sternen (star-of-stars): Endgeräte funken sternförmig zu den Gateways, die Gateways sind sternförmig mit dem Network Server verbunden.
• bc) Fällt der zentrale Switch SW2 aus, ist das ganze LAN des Klärwerks getrennt (Single Point of Failure). Ebenfalls akzeptiert: hoher Verkabelungsaufwand.

a) Aktive Komponenten im Betriebshof (6 P)

b) Vorteile Client-Server (4 P)

• Zentrale Datenhaltung und Verfügbarkeit: Alle Schichtberichte liegen an einem Ort in einer aktuellen Version. Kollegen finden sie auch, wenn der PC des Verfassers ausgeschaltet oder defekt ist – heute fehlen die Berichte dann.
• Zentrale Datensicherung: Der Dateiserver im Rechenzentrum wird automatisch gesichert. Heute liegen die Berichte ungesichert auf vielen PCs; ein Festplattendefekt bedeutet Datenverlust.
• Ebenfalls richtig: zentrale Rechteverwaltung über Benutzerkonten und Gruppen statt offener Freigaben auf Arbeitsplatz-PCs (Sicherheit, Protokollierung) · Zugriff auch von anderen Standorten und per VPN · zentrale Wartung auf leistungsfähiger, redundanter Hardware.

a) Zuordnung und Begründung (12 P)

b) Remote-Access-VPN statt Portweiterleitung (3 P)

• Heute ist der RDP-Dienst von S4 (Port 3389) aus dem gesamten Internet erreichbar. Angreifer finden ihn per Portscan, können Passwörter durchprobieren oder Lücken des nicht mehr aktualisierten Windows 10 ausnutzen – und hätten damit direkten Zugang zur Leitwarte einer kritischen Infrastruktur.
• Mit VPN ist kein interner Dienst mehr direkt freigegeben, nur das VPN-Gateway R4 ist erreichbar. Zugang gibt es erst nach Authentifizierung des Geräts bzw. Mitarbeiters (Zertifikat, zweiter Faktor).
• Die gesamte Verbindung ist verschlüsselt und integritätsgeschützt; der Zugriff lässt sich auf die nötigen Systeme beschränken und zentral protokollieren. S4 und die Portweiterleitung können entfallen.

c) Risiko der Stern-Topologie (3 P)

Risiko: SW2 ist ein Single Point of Failure. Fällt er aus (Defekt, Stromausfall), sind Leitwarten-PCs, SPS, Gateway GW2 und Router voneinander getrennt – die Leitwarte kann das Klärwerk nicht mehr überwachen und steuern, Messwerte über GW2 fehlen.
Maßnahme: einen zweiten, redundanten Switch einsetzen und die wichtigen Geräte (Leitwarten-PCs, SPS, Router) doppelt anbinden (teilvermaschte Topologie mit Spanning Tree bzw. Link-Aggregation); zusätzlich USV für die Netzwerktechnik und ein Ersatzgerät vor Ort.

Erklärung: Wie in W24: Jede Zeile braucht ein Merkmal des Konzepts und den Bezug zum Gebiet. „SAN, weil Rechenzentrum“ ist nur die Zuordnung, keine Begründung. Typische Verwechslung: SAN mit NAS – ein NAS ist ein Dateispeicher im normalen LAN, kein eigenes Netz.

a) Aufbau der MAC-Adresse 7C:4F:B5:3A:07:D1 (3 P)

• Eine MAC-Adresse ist 48 Bit (6 Byte) lang und wird als 12 Hexadezimalziffern in sechs Zweiergruppen geschrieben.
• Die ersten 3 Byte 7C:4F:B5 sind der OUI (Organizationally Unique Identifier): die vom IEEE vergebene Kennung des Herstellers des Gateways.
• Die letzten 3 Byte 3A:07:D1 sind die Gerätekennung, die der Hersteller für diese Netzwerkschnittstelle eindeutig vergibt. Zusammen ist die Adresse weltweit eindeutig.

Zusatz (nicht verlangt): 7C = 0111 1100 – die beiden niederwertigsten Bits sind 0, es ist also eine Unicast-Adresse, die vom Hersteller global vergeben wurde (nicht zufällig/lokal).

b) OSI-Schichten (3 P)

a) Felder des Ethernet-Frames (6 P)

Die beiden übrigen Bezeichner gehören nicht zum Ethernet-Frame: Time to Live ist ein Feld im IP-Header (Schicht 3), Source Port steht im TCP- bzw. UDP-Header (Schicht 4). Beide stecken also innerhalb der Nutzdaten.

b) Mitschnitt auswerten (3 P)

ff ff ff ff ff ff   3c 52 82 5e 90 31   08 06   00 01 08 00 06 04 00 01 …
└── Ziel-MAC ───┘   └── Quell-MAC ──┘   Typ     Beginn der Nutzdaten

• Quell-MAC-Adresse: 3C:52:82:5E:90:31
• Ziel: FF:FF:FF:FF:FF:FF ist die Broadcast-Adresse – der Frame geht an alle Geräte im LAN des Klärwerks; jeder Switch leitet ihn an alle Ports weiter.
• Protokoll: Typfeld 0x0806 = ARP (Address Resolution Protocol).

Zusatz: In den Nutzdaten steht eine ARP-Anfrage (Opcode 00 01): Absender-IP 0a 0a 14 1f = 10.10.20.31 (Leitwarten-PC 1), gesuchte IP 0a 0a 14 32 = 10.10.20.50 (Gateway GW2). Der PC fragt also „Wer hat 10.10.20.50?“ – genau so könnte getMacAddress aus Anlage 7 intern arbeiten. Die 28 Byte der ARP-Nachricht werden mit Nullen auf die Mindestlänge von 46 Byte aufgefüllt.

c) IPv4-Netz (3 P)

10.10.20.31/24  →  24 Bit Netzanteil, 32 − 24 = 8 Bit Hostanteil
Maske             255.255.255.0
ca) Netzadresse   10.10.20.0      (Hostbits alle 0)
    Broadcast     10.10.20.255    (Hostbits alle 1)
cb) Hosts         2^8 − 2 = 256 − 2 = 254

cc) Der Messrechner (10.10.21.40/24) liegt im Netz 10.10.21.0/24, der Leitwarten-PC im Netz 10.10.20.0/24 – das dritte Oktett unterscheidet sich (21 ≠ 20), die Netzanteile sind verschieden. Der Messrechner hält den PC deshalb für ein fremdes Netz und schickt die Pakete an sein Standardgateway statt direkt über den Switch; ein Netz 10.10.21.0/24 gibt es im Klärwerk nicht. Abhilfe: eine freie Adresse aus 10.10.20.0/24 vergeben (am besten per DHCP).

a) Funktion inventarisiere (10 P)

funktion inventarisiere(netz : string) : string
  json : string := "["
  ersterEintrag : boolean := true
  zähle i von 1 bis 254                       // .0 = Netzadresse, .255 = Broadcast
    ip : string := netz + "." + i             // z. B. "10.10.20" + "." + 31
    mac : string := getMacAddress(ip)
    wenn mac <> null dann                     // nur Geräte, die geantwortet haben
      wenn ersterEintrag = false dann
        json := json + ", "                   // Komma nur vor jedem weiteren Objekt
      Ende wenn
      json := json + '{"ip": "' + ip + '", "mac": "' + mac + '"}'
      ersterEintrag := false
    Ende wenn
  Ende zähle
  json := json + "]"
  rückgabe json
Ende funktion

// Aufruf
ausgabe(inventarisiere("10.10.20"))

b) Erweiterung um den Hersteller (4 P)

Geänderte bzw. neue Zeilen innerhalb von wenn mac <> null dann:

      oui : string := mac.substring(0, 8)     // "5C:F2:86:00:14:01" → "5C:F2:86"
      hersteller : string := getVendor(oui)
      wenn hersteller = null dann
        hersteller := "unbekannt"
      Ende wenn
      …
      json := json + '{"ip": "' + ip + '", "mac": "' + mac
                   + '", "hersteller": "' + hersteller + '"}'

Java · Aufgabe_NET_03_3.java (Auszug, a und b)

// a) Inventarisierung als JSON-Array
static String inventarisiere(String netz) {
    String json = "[";
    boolean ersterEintrag = true;
    for (int i = 1; i <= 254; i++) {                 // .0 = Netzadresse, .255 = Broadcast
        String ip = netz + "." + i;
        String mac = getMacAddress(ip);
        if (mac != null) {                           // nur Geräte, die geantwortet haben
            if (!ersterEintrag) {
                json = json + ", ";                  // Komma nur vor jedem weiteren Objekt
            }
            json = json + "{\"ip\": \"" + ip + "\", \"mac\": \"" + mac + "\"}";
            ersterEintrag = false;
        }
    }
    json = json + "]";
    return json;
}

// b) Erweiterung um den Hersteller
static String inventarisiereMitHersteller(String netz) {
    String json = "[";
    boolean ersterEintrag = true;
    for (int i = 1; i <= 254; i++) {
        String ip = netz + "." + i;
        String mac = getMacAddress(ip);
        if (mac != null) {
            String oui = mac.substring(0, 8);        // "5C:F2:86:00:14:01" -> "5C:F2:86"
            String hersteller = getVendor(oui);
            if (hersteller == null) {
                hersteller = "unbekannt";
            }
            if (!ersterEintrag) {
                json = json + ", ";
            }
            json = json + "{\"ip\": \"" + ip + "\", \"mac\": \"" + mac
                        + "\", \"hersteller\": \"" + hersteller + "\"}";
            ersterEintrag = false;
        }
    }
    json = json + "]";
    return json;
}

Vollständige Datei mit simulierten Hilfsfunktionen getMacAddress/getVendor (11 Geräte, fiktive Hersteller), Subnetzrechnung und Testlauf: java\10_Netzwerk_IoT\Aufgabe_NET_03_3.java

Ausgabe des Testlaufs

a) inventarisiere("10.10.20"):
[{"ip": "10.10.20.1", "mac": "5C:F2:86:00:14:01"}, {"ip": "10.10.20.2", "mac": "5C:F2:86:00:14:02"}, {"ip": "10.10.20.31", "mac": "3C:52:82:5E:90:31"}, {"ip": "10.10.20.32", "mac": "3C:52:82:5E:90:32"}, {"ip": "10.10.20.41", "mac": "3C:52:82:5E:91:41"}, {"ip": "10.10.20.50", "mac": "7C:4F:B5:3A:07:D1"}, {"ip": "10.10.20.70", "mac": "00:0E:8C:A1:22:70"}, {"ip": "10.10.20.71", "mac": "00:0E:8C:A1:22:71"}, {"ip": "10.10.20.140", "mac": "A4:C1:38:0B:5D:8C"}, {"ip": "10.10.20.201", "mac": "F2:6B:19:C8:44:0E"}, {"ip": "10.10.20.254", "mac": "5C:F2:86:00:14:FE"}]

b) inventarisiereMitHersteller("10.10.20"):
[{"ip": "10.10.20.1", "mac": "5C:F2:86:00:14:01", "hersteller": "Nordwerk Netzwerktechnik"}, {"ip": "10.10.20.2", "mac": "5C:F2:86:00:14:02", "hersteller": "Nordwerk Netzwerktechnik"}, {"ip": "10.10.20.31", "mac": "3C:52:82:5E:90:31", "hersteller": "Lumetra Computer"}, {"ip": "10.10.20.32", "mac": "3C:52:82:5E:90:32", "hersteller": "Lumetra Computer"}, {"ip": "10.10.20.41", "mac": "3C:52:82:5E:91:41", "hersteller": "Lumetra Computer"}, {"ip": "10.10.20.50", "mac": "7C:4F:B5:3A:07:D1", "hersteller": "unbekannt"}, {"ip": "10.10.20.70", "mac": "00:0E:8C:A1:22:70", "hersteller": "Prozessa Automation"}, {"ip": "10.10.20.71", "mac": "00:0E:8C:A1:22:71", "hersteller": "Prozessa Automation"}, {"ip": "10.10.20.140", "mac": "A4:C1:38:0B:5D:8C", "hersteller": "Visiotec Kamerasysteme"}, {"ip": "10.10.20.201", "mac": "F2:6B:19:C8:44:0E", "hersteller": "unbekannt"}, {"ip": "10.10.20.254", "mac": "5C:F2:86:00:14:FE", "hersteller": "Nordwerk Netzwerktechnik"}]

c) Aufteilung 10.10.20.0/24 in vier gleich große Subnetze:
Maske /26 = 255.255.255.192, Hosts je Subnetz = 62
Büro         10.10.20.0/26     10.10.20.1     10.10.20.62    10.10.20.63
Leittechnik  10.10.20.64/26    10.10.20.65    10.10.20.126   10.10.20.127
Kameras      10.10.20.128/26   10.10.20.129   10.10.20.190   10.10.20.191
WLAN         10.10.20.192/26   10.10.20.193   10.10.20.254   10.10.20.255

d) nur Subnetz Leittechnik (Hosts 65 bis 126), heutiger Gerätebestand:
[{"ip": "10.10.20.70", "mac": "00:0E:8C:A1:22:70"}, {"ip": "10.10.20.71", "mac": "00:0E:8C:A1:22:71"}]

Kontrolle: leeres Netz 10.10.99 -> []

Die Ausgaben von a), b) und d) wurden zusätzlich mit einem JSON-Parser geprüft (gültige Arrays mit 11, 11 und 2 Objekten). Das Gerät mit .254 zeigt, dass die Obergrenze 254 nötig ist; die Tablet-MAC F2:… ist eine zufällige, lokal vergebene Adresse – deshalb „unbekannt“.

c) Aufteilung in vier /26-Subnetze (4 P)

Rechenweg: 4 Subnetze = 2² → 2 Bit vom Hostanteil leihen → Präfix /24 + 2 = /26, Maske 255.255.255.192. Es bleiben 32 − 26 = 6 Hostbits → Blockgröße 2⁶ = 64 Adressen → Subnetze beginnen bei .0, .64, .128, .192. Nutzbare Hosts: 2⁶ − 2 = 62 je Subnetz.

d) Nur das Subnetz Leittechnik durchsuchen (2 P)

Die Schleifenzeile zähle i von 1 bis 254 wird zu zähle i von 65 bis 126 (erste und letzte Hostadresse von 10.10.20.64/26); der Parameter "10.10.20" bleibt. Eleganter: Grenzen als Parameter inventarisiere(netz : string, von : integer, bis : integer).

e) Protokolle, Transport und Ports (4 P)

Erklärung: Die Skriptaufgabe entspricht W24 T1 A2c (dort 8 P, hier mit Erweiterungen). Die drei häufigsten Fehler: Schleife von 0 bis 255, ein Komma nach dem letzten Objekt (ungültiges JSON) und fehlende Anführungszeichen um die Werte. Wer unsicher ist, schreibt die Zeichenkette für ein Objekt erst einmal vollständig für ein konkretes Gerät auf und ersetzt dann die Werte durch Variablen.

a) Servicemodelle (3 P)

b) 3-2-1-Regel (3 P)

Von wichtigen Daten sollen mindestens 3 Kopien existieren (das Original und zwei Sicherungen), auf 2 unterschiedlichen Speichermedien bzw. -systemen, und 1 Kopie an einem anderen Ort (außer Haus bzw. offline). So übersteht mindestens eine Kopie Hardwaredefekt, Brand, Wasserschaden, Diebstahl oder Ransomware.

Beim WAL (Anlage 6) gibt es nur eine Sicherung auf dem NAS S5. Es steht im selben Raum wie die Server (unter Wasserrohren) und ist dauerhaft im Netz. Damit fehlen die zweite Kopie und die Kopie außer Haus bzw. offline: Brand, Wasser oder Ransomware würden Original und Sicherung zugleich vernichten. Zudem wird nur wöchentlich und manuell gesichert.

aa) Speicherbedarf einer Woche (2 P)

(1) inkrementell:  So 400 GB + Mo–Sa je 20 GB                        = 400 + 6 · 20  = 520 GB
(2) differenziell: So 400 GB + 20 + 40 + 60 + 80 + 100 + 120 GB          = 400 + 420     = 820 GB
    (jede differenzielle Sicherung enthält alle Änderungen seit Sonntag)

ab) Wiederherstellung nach Ausfall am Donnerstag, 14 Uhr (2 P)

• inkrementell: Vollsicherung vom Sonntag, dann der Reihe nach die inkrementellen Sicherungen von Montag, Dienstag und Mittwoch.
• differenziell: Vollsicherung vom Sonntag, dann nur die differenzielle Sicherung vom Mittwoch.

ac) Verlorene Daten (1 P)

In beiden Fällen fehlen alle Messwerte, die nach der letzten Sicherung (Mittwoch, 22 Uhr) bis zum Ausfall (Donnerstag, 14 Uhr) gespeichert wurden – also etwa 16 Stunden (rund 13 GB), sofern sie nicht aus einem Zwischenspeicher (z. B. im Network Server) nachgeladen werden können.

b) Gefahren und Maßnahmen (4 P)

c) RAID ersetzt keine Datensicherung (1 P)

RAID 6 schützt nur vor dem Ausfall von bis zu zwei Festplatten. Löscht jemand versehentlich Messwerte oder verschlüsselt Ransomware die Datenbank, wird diese Änderung sofort auf alle Platten geschrieben – ein früherer Stand existiert nicht. Auch bei Brand, Wasserschaden oder Diebstahl des Speichersystems sind alle Daten verloren.

Erklärung: Inkrementell = „seit der letzten Sicherung“, differenziell = „seit der letzten Vollsicherung“. Weil hier täglich nur neue Daten hinzukommen, wächst die differenzielle Sicherung jeden Tag um 20 GB. Typischer Fehler: bei der differenziellen Variante alle Differenzen zurückspielen – nötig ist nur die letzte.

a) Zwei Schwachstellen (4 P)

Zwei der folgenden (jeweils mit Beleg und Folge):

• Keine USV: Beim Stromausfall am 02.07. stürzten S1 und S3 ab; Dateisystemfehler machten den Dateiserver 1,5 Tage unbrauchbar.
• Keine Klimatisierung (bis 34 °C): S3 schaltete sich am 14.05. wegen Hitze ab – das Pegelportal war ausgerechnet während eines Starkregens 6 Stunden nicht erreichbar.
• Fehlende Redundanz: S3 nutzt RAID 0, eine defekte Platte zerstört alle Daten (19.09.); S1 hat nur ein Netzteil; S2 ist der einzige Anmeldeserver (bei Ausfall keine Anmeldung, kein DNS/DHCP) → Single Points of Failure.
• Unzureichende Datensicherung: nur wöchentlich und manuell, NAS im selben Raum und dauerhaft im Netz → beim Plattendefekt fehlten 11 Tage Messwerte; Brand, Wasser (Rohre unter der Decke) oder Ransomware träfen Original und Kopie.
• Veraltete, uneinheitliche Systeme: Hardware von 2013–2018, Betriebssysteme ohne Sicherheitsupdates (Windows Server 2012 R2, CentOS 7, Windows 10), fünf Hersteller, ein Administrator ohne Dokumentation → häufige Defekte, keine Ersatzteile, lange Fehlersuche; über die offene RDP-Freigabe von S4 könnten Angreifer Systeme lahmlegen.

b) Anforderungen (4 P)

• funktional (Beispiel): „Die neue Infrastruktur stellt Dateiserver, Messwert-Datenbank und Dashboard für alle Standorte und den Bereitschaftsdienst über verschlüsselte VPN-Verbindungen bereit.“ Alternativ: „Alle Server werden täglich automatisch gesichert, eine Kopie wird außer Haus gespeichert.“ · „Die Anmeldung erfolgt zentral mit einem Benutzerkonto an allen Standorten.“
• nicht-funktional (Beispiel): „Die Messwert-Plattform ist zu mindestens 99,9 % im Jahr verfügbar (höchstens ca. 8,8 Stunden Ausfall).“ Alternativ: „Fällt ein Host aus, laufen alle VMs nach spätestens 5 Minuten auf einem anderen Host weiter.“ · „Es dürfen höchstens eine Stunde Messwerte verloren gehen.“ · „Hochwasser-Warnungen erreichen den Bereitschaftsdienst innerhalb von 2 Minuten.“

ca) Vorteile der Virtualisierung (4 P)

• Hohe Verfügbarkeit: Im Cluster aus drei Hosts mit gemeinsamem Speichersystem starten die VMs bei Ausfall eines Hosts automatisch auf einem anderen; Wartung per Live-Migration ohne Unterbrechung. Damit verschwinden die Single Points of Failure aus Anlage 6.
• Konsolidierung und einheitlicher Betrieb: Statt fünf alter Geräte verschiedener Hersteller laufen alle Server auf einheitlicher, moderner Hardware im klimatisierten Rechenzentrum mit USV – weniger Hardware, geringerer Wartungs- und Energieaufwand, einheitliche Verwaltung für den einzigen Administrator.
• Ebenfalls richtig: Snapshots vor Updates und Sicherung ganzer VMs (schnelle Wiederherstellung) · neue Server in Minuten bereitstellen und Ressourcen flexibel anpassen · Hardwareunabhängigkeit (Austausch eines Hosts ohne Neuinstallation der Server).

cb) VM und Container (2 P)

Eine virtuelle Maschine enthält ein vollständiges eigenes Gast-Betriebssystem und läuft auf der vom Hypervisor virtualisierten Hardware. Ein Container enthält nur die Anwendung mit ihren Bibliotheken und teilt sich den Kernel des Host-Betriebssystems. Container sind deshalb viel kleiner (MB statt GB) und starten in Sekunden; VMs sind stärker voneinander isoliert und können ein anderes Betriebssystem als der Host haben.

d) Public Cloud (PaaS) – Vor- und Nachteile (6 P)

Vorteile (zwei davon):

• Skalierbarkeit: Bei Hochwasser (häufigere Messungen, viele Zugriffe auf das Dashboard) erweitert die Plattform automatisch die Ressourcen und reduziert sie danach wieder; bezahlt wird nach Verbrauch.
• Verfügbarkeit und Entlastung: Der Anbieter betreibt redundante Rechenzentren (vertraglich zugesicherte Verfügbarkeit) und übernimmt Betriebssystem- und Datenbank-Updates – das entlastet den einzigen Administrator des WAL.
• Kosten: keine Investition in eigene Hosts und Speichersysteme; laufende statt einmalige Kosten.

Nachteile / Risiken (zwei davon):

• Abhängigkeit von Internet und Anbieter: Die Hochwasserwarnung einer kritischen Infrastruktur fiele aus, wenn die Internetanbindung oder der Cloud-Dienst gestört ist; PaaS-Dienste sind oft anbieterspezifisch, ein Wechsel ist schwierig (Vendor-Lock-in).
• Datenschutz (DSGVO): Die App verarbeitet personenbezogene Daten des Bereitschaftsdienstes (Namen, Telefonnummern, Einsatzzeiten). Nötig sind ein Auftragsverarbeitungsvertrag und ein Serverstandort in der EU; bei Anbietern aus Drittländern (z. B. USA) ist die Datenübermittlung gesondert zu prüfen.
• Sicherheit und Kontrolle: Steuerfunktionen für Pumpen und Schieber liefen über eine fremde, öffentlich erreichbare Plattform; der WAL muss sich die Sicherheitsanforderungen für kritische Infrastrukturen vom Anbieter nachweisen lassen und hat weniger Einfluss auf Änderungen.
• Langfristige Kosten: Die Datenmenge wächst täglich; Speicher- und Datenverkehrskosten können auf Dauer höher und schwer planbar sein.

Mögliche Empfehlung (nicht verlangt): Hybrid – Steuerung und Alarmierung lokal bzw. im gemieteten Rechenzentrum (mit Edge-Funktionen an den Anlagen), unkritische Auswertungen oder das öffentliche Pegelportal in der Cloud.

Erklärung: Teil a) und b) entsprechen W22 T1 A1a/b. Der Unterschied zu einer allgemeinen Lehrbuchantwort ist der Beleg aus der Anlage („keine USV → Stromausfall am 02.07. …“). Typischer Fehler in b): „Die Infrastruktur soll sicher sein“ – ohne Maßstab bringt das kaum Punkte.