Ansible in der Elektrotechnik – Chancen, Grenzen und reale Anwendungen

Einordnung: Werkzeug oder Wunderwaffe?

Ansible hat in den letzten Jahren tatsächlich an Bedeutung in Umgebungen gewonnen, in denen IT- und OT-Infrastrukturen zusammenwachsen. Es ist jedoch eines von mehreren Werkzeugen – und nicht das einzige. Andere Technologien wie Terraform, Puppet, Chef oder SaltStack werden in ähnlichen Kontexten eingesetzt, sind aber in der OT oft weniger verbreitet, da sie agentenbasiert oder zu IT-zentriert sind.

Der größte Vorteil von Ansible in der OT ist seine Agentenlosigkeit – es nutzt SSH (Linux) oder WinRM (Windows) – sowie die deklarative Beschreibung von Zuständen in YAML. Das reduziert den Footprint auf den Zielgeräten und vereinfacht die Integration in bestehende Sicherheitsrichtlinien.

Automatisierung in der Elektrotechnik – ein historischer Abriss

Die Entwicklung der Automatisierungstechnik lässt sich grob in folgende Phasen unterteilen:

Die Behauptung, Ansible habe die Grenzen zwischen IT und OT so sehr verschoben wie kein anderes Werkzeug, ist aus fachlicher Sicht nicht haltbar. Hier spielen OPC UA, MQTT, Ethernet/IP, Profinet und Container-Technologien mindestens ebenso große Rollen.

Anwendungsszenarien – wo Ansible heute tatsächlich in der OT eingesetzt wird

Ansible findet vor allem in folgenden Bereichen praktische Anwendung:

1. Netzwerkautomatisierung im Energiesektor

Netzwerkkomponenten wie Switches, Router und Firewalls lassen sich mit Ansible standardisiert konfigurieren. Unternehmen wie IP Infusion bieten spezifische Collections für Zero-Touch-Provisioning (ZTP) an. Das bedeutet: Ein neuer Switch wird ans Netz angeschlossen, erhält per DHCP eine Grundkonfiguration und wird dann vollautomatisch in die gewünschte Topologie eingebunden.

2. Edge-Infrastrukturen (IT/OT-Grenzbereich)

Ein Beispiel ist die Zusammenarbeit von Schneider Electric und Red Hat: Hier wird Ansible genutzt, um den gesamten Technologie-Stack am industriellen Edge zu orchestrieren – vom Betriebssystem (RHEL) über die Container-Plattform (MicroShift) bis zur Steuerungssoftware EcoStruxure Automation Expert. Der Ansatz folgt GitOps-Prinzipien: Der gewünschte Zustand wird in Git hinterlegt, Ansible gleicht die physischen Geräte ab.

3. SCADA-Systeme am CERN

Am CERN werden hunderte SCADA-Systeme betrieben. Im Rahmen eines Upgrades 2024 wurde ein unbeaufsichtigter Upgrade-Workflow mit Ansible implementiert. Das zeigt, dass Ansible auch in sicherheitskritischen, hochkomplexen Umgebungen einsetzbar ist – allerdings mit entsprechendem Aufwand für Testing, Rollback-Strategien und Freigabeprozesse.

Die Grenzen von Ansible in der OT

Trotz aller Vorteile gibt es klare Einschränkungen:

Praxisbeispiel: community.cip

Die community.cip-Collection ist ein gutes Beispiel dafür, wie die Community die Lücke zwischen Ansible und der SPS-Welt schließt. Sie ermöglicht die Kommunikation mit Geräten über das Common Industrial Protocol (CIP), das bei Rockwell Automation und anderen Herstellern verbreitet ist.

Das zeigt: Ansible kann für bestimmte OT-Aufgaben nutzbar gemacht werden – allerdings meist mit Einschränkungen (z. B. keine Zykluszeiten im Millisekundenbereich, keine Sicherheitszertifikate).

Sicherheit – ein zentrales Thema

Die Automatisierung mit Ansible bringt neue Sicherheitsanforderungen mit sich:

• Ansible Vault verschlüsselt vertrauliche Daten wie Passwörter oder API-Keys.
• Die Schwachstelle CVE-2024-8775 zeigt jedoch, dass Verschlüsselung allein nicht ausreicht: Wenn bei bestimmten Tasks der Parameter no_log: true vergessen wird, können sensible Daten im Klartext in Logs erscheinen.
• Auch die Red Hat Ansible Automation Platform muss regelmäßig aktualisiert werden, um bekannte Sicherheitslücken zu schließen.

Grundsätzlich gilt: Die Automatisierung selbst ist nur so sicher wie ihre Implementierung. Governance, Code-Reviews und Zugriffskontrollen sind unerlässlich.

Feldversuche – die Praxis ist komplexer als die Theorie

Der eingangs erwähnte Feldversuch (Link im Originaltext) zeigt, dass Automatisierung in der realen OT-Welt oft an unvorhergesehenen Problemen scheitert:

• Unterschiedliche Firmware-Stände
• Proprietäre Protokolle
• Temporäre Netzwerkausfälle
• Fehlende Standardisierung bei der Gerätekonfiguration

Viele Projekte scheitern nicht an Ansible selbst, sondern an der mangelnden Vorbereitung der zugrundeliegenden Infrastruktur. Das ist ein typisches Problem bei der Einführung von DevOps-Praktiken in der OT.

Ausblick: Wohin entwickelt sich die Automatisierung?

Die Zukunft wird nicht darin bestehen, dass Ansible zur universellen Steuerungslösung wird. Vielmehr zeichnen sich folgende Trends ab:

Der Elektroingenieur wird zunehmend interdisziplinär arbeiten – aber er bleibt weiterhin für die physikalischen Randbedingungen (Sicherheit, Echtzeit, Verfügbarkeit) verantwortlich. Die Rolle des Software-Architekten ist eher eine ergänzende denn eine ersetzende.

Fazit

Ansible ist ein nützliches, aber nicht universelles Werkzeug für die Automatisierung von OT-Infrastrukturen. Seine Stärken liegen in der Netzwerkautomatisierung, der Edge-Orchestrierung und der Standardisierung von Konfigurationsprozessen. Seine Grenzen sind:

• Fehlende Echtzeitfähigkeit
• Keine Sicherheitszertifizierung
• Eingeschränkte Kompatibilität mit proprietären SPS-Systemen
• Abhängigkeit von der Standardisierung der Zielgeräte

Die erfolgreiche Nutzung von Ansible in der OT erfordert gut durchdachte Prozesse, Teststrategien und Sicherheitsmaßnahmen. Wer das beachtet, kann von erheblichen Effizienzgewinnen profitieren – ohne sich jedoch von der Vorstellung einer stillen Revolution blenden zu lassen.

Quellen

• CERN: „CERN SCADA systems 2024 large upgrade campaign retrospective“ (ICALEPCS2025)
• Red Hat: „Reinventing the industrial edge“ (Blog, 2026)
• IP Infusion: „OcNOS Network Automation“ (Dokumentation)
• SecurITm: CVE-2024-8775
• CIRCL: WID-SEC-W-2025-1437 (Red Hat Ansible Security Advisory)
• GitHub: community.cip – Ansible Collection for CIP