Energiespeicherung und Cybersicher-
heit: Risiken minimieren, ohne
Chancen zu verpassen

iStock-2168595727

Batteriespeicher sind unverzichtbar für die Energiewende. Aber sie werfen auch Fragen auf. Wie sicher sind sie? Was ist mit Cybersecurity? Und was passiert bei Problemen, auf die man keinen direkten Einfluss hat, etwa Netzwerkstörungen oder Cloud-Ausfälle? Mit durchdachter Software und robuster Cybersecurity lassen sich Risiken minimieren, ohne Chancen zu verpassen.


Eine Batterie allein macht nichts


Um ein häufiges Missverständnis direkt auszuräumen: Eine Batterie ist für sich genommen wenig mehr als ein Energiespeicher. Ohne Steuerung passiert nichts. Die eigentliche Kontrolle liegt beim Energy Management System (EMS). Diese Software entscheidet, wann und wie eine Batterie lädt oder entlädt.

Daneben gibt es das Battery Management System (BMS). Das wird vom Batteriehersteller geliefert und sorgt für den sicheren Betrieb, zum Beispiel durch Überhitzungsschutz. Wichtig zu verstehen: Das BMS hat keinen Einfluss auf die Energiesteuerung. Die liegt vollständig beim EMS und den Wechselrichtern. 


Sicherheitsrisiken: Mehrere Verteidigungslinien sind Pflicht


Einzelne Schutzmaßnahmen reichen nicht. Um Daten und Systeme zuverlässig abzusichern, braucht es mehrere unabhängige Verteidigungsebenen. Bei iwell sehen diese konkret so aus:

  • Eingeschränkter, kontrollierter Zugang: Nur wenige Mitarbeitende können sich über eine gesicherte VPN-Verbindung in ein EMS einloggen, ausschließlich per Zwei-Faktor-Authentifizierung und von einer begrenzten Anzahl streng geprüfter Geräte.
  • Netzwerksegmentierung: Das EMS läuft in einem eigenen Netzwerk, getrennt vom Netzwerk des Endnutzers. Ein Angriff auf andere Systeme hat damit keinen Einfluss auf den Betrieb des Speichers.
  • Regelmäßige Penetrationstests: Externe Cybersecurity-Spezialisten prüfen die Systeme regelmäßig auf Schwachstellen und beheben diese systematisch.
  • Sicherheitsschulungen für Mitarbeitende: Die häufigste Angriffsfläche in der Cybersecurity ist der Mensch. Unsere Mitarbeitenden werden regelmäßig im Erkennen von Phishing und anderen digitalen Bedrohungen geschult.
  • Kontrollierte Software-Updates: Gelegentlich sind BMS-Updates notwendig, etwa zur Optimierung der Batterieleistung. Diese erfolgen ausschließlich unter Aufsicht. Externe Anbieter erhalten erst nach unserer ausdrücklichen Freigabe temporären Zugang, der nach Abschluss des Updates sofort wieder entzogen wird.
  •  Nachgewiesene Informationssicherheit: Das System ist ISO 27001-zertifiziert und NIS2-konform.

 

Was tun, wenn trotzdem etwas passiert?


Auch mit allen Vorkehrungen lässt sich ein Sicherheitsvorfall nie vollständig ausschließen. Für diesen Fall sorgt ein Incident Response Plan (IRP) dafür, dass schnell und geordnet gehandelt werden kann.

Kern eines funktionierenden IRP ist die zügige Ursachenanalyse. Sobald ein Vorfall eintritt, beginnt sofort eine gründliche Root-Cause-Analyse, gefolgt von gezielten Maßnahmen zur Behebung und zur Vermeidung von Wiederholungen.

Ebenso wichtig: transparente, zeitnahe Kommunikation. Wenn ein Vorfall Nutzer eines Batteriesystems betrifft, werden diese umgehend und vollständig informiert und während des gesamten Prozesses begleitet. Keine offenen Fragen, kein Informationsvakuum.

Und bei technischen Störungen?


Neben Cyberangriffen kann auch die Technik selbst ausfallen, zum Beispiel durch Netzwerkprobleme bei einem Cloud-Anbieter, die dazu führen, dass ein EMS vorübergehend nicht remote erreichbar ist.

Wer auf eine getrennte Infrastruktur setzt (wie oben beschrieben), hat dabei einen klaren Vorteil: Das Batteriesystem bleibt lokal voll betriebsfähig. Ziel ist es dann, das Problem so schnell wie möglich zu identifizieren und zu beheben.

Ergänzend dazu ist eine solide Backup-Strategie unerlässlich. Konfigurations- und Betriebsdaten werden dabei sicher in voneinander getrennten Cloud-Umgebungen gespeichert, damit Systeme schnell wiederhergestellt und Datenverluste minimiert werden können.

Der Maersk-Angriff: Was ein Zufallsfund verhinderte


Ein konkretes Beispiel dafür, wie wichtig getrennte Cloud-Umgebungen sind, liefert der Cyberangriff auf den dänischen Schifffahrtskonzern Maersk im Jahr 2017. Damals gelang es Hackern, die Rechenzentren des Unternehmens lahmzulegen, mit gravierenden Folgen: Maersk wusste zeitweise nicht mehr, wo seine Schiffe sich befanden oder welche Container wohin gehörten. Vollständiger Betriebsstillstand.

Was den Fall besonders lehrreich macht: Maersk betrieb seine IT-Infrastruktur zu dieser Zeit vollständig auf eigenen physischen Servern an mehreren Standorten, unabhängig von externen Cloud-Anbietern wie Microsoft oder Google. Dieses Modell galt intern als robust. Im Ernstfall wurde es beinahe zum Verhängnis.

Dass sich Maersk vergleichsweise schnell erholen konnte, war purer Zufall. Kurz vor dem Angriff hatte es an einem Standort einen Stromausfall gegeben. Das dortige Rechenzentrum war offline, wurde damit von der Infektion verschont und enthielt alle zentralen Konfigurations- und Betriebsdaten. Von dort aus konnte das Unternehmen seine Systeme wiederherstellen. Innerhalb weniger Tage war der Betrieb wieder aufgenommen.

Risikobeherrschung statt Risikovermeidung

In der Debatte um die Sicherheit von Batteriesystemen dominiert oft die Risikoperspektive. Aber wer jeden möglichen Risikofaktor von vornherein ausschließen will, verliert gleichzeitig die Chancen aus dem Blick.

Der sinnvollere Ansatz: Risiken aktiv identifizieren, bewerten und durch konkrete Maßnahmen beherrschbar machen.

Bei iwell bedeutet das:

  • Vollständige Kontrolle über das eigene Energy Management System. 
  • Minimierung von Cyberbedrohungen durch konsequente Sicherheits- und Schutzmaßnahmen.
  • Betriebsstabilität auch bei Störungen, auf die wir keinen direkten Einfluss haben.

Batterien sind nur ein Teil des Gesamtsystems. Die eigentliche Kontrolle liegt bei der Software und der Infrastruktur dahinter. Und die liegt bei uns.

SHARE

Doe de quick scan

Beantwoord een paar korte vragen en ontdek hoe we jouw energievraagstuk kunnen omzetten in een businesscase.

Doe de quick scan
Example Image