Firewall-Regeln für Make, n8n und Zapier: Zugriff absichern

Das Problem: Workflow-Plattformen wollen überall hin

Workflow-Plattformen wie Make, n8n oder Zapier verbinden Ihre internen Systeme mit externen Diensten. CRM, Buchhaltung, Marketing-Tools, manchmal auch Produktionsdatenbanken. Jeder dieser Verbindungswünsche landet früher oder später vor Ihrer Firewall. Wenn Sie pauschal alle ausgehenden Verbindungen erlauben, öffnen Sie ein Scheunentor. Wenn Sie zu restriktiv filtern, stehen die Workflows am nächsten Morgen still, weil ein Webhook nicht mehr durchkommt oder eine API-Anfrage hängt.

Der Mittelstand steht vor der Frage: Welche IP-Bereiche, Ports und Protokolle müssen Sie tatsächlich freigeben, ohne die Sicherheit zu opfern? Und wie dokumentieren Sie das so, dass ein Wirtschaftsprüfer oder Datenschutzbeauftragter nachvollziehen kann, wer warum wohin darf?

Was Firewall-Regeln für Workflow-Plattformen leisten müssen

Eine Firewall-Regel definiert, welche Verbindung zwischen zwei Netzwerksegmenten erlaubt ist. Für Workflow-Plattformen bedeutet das konkret:

• Ausgehende Verbindungen: Die Plattform muss APIs externer Dienste erreichen, etwa die REST-API von DATEV oder die Webhook-URL von Slack.
• Eingehende Verbindungen: Webhooks von externen Systemen müssen die Plattform erreichen können, ohne dass dabei das gesamte interne Netz exponiert wird.
• Protokoll und Port: HTTPS auf Port 443 ist Standard, manche Legacy-APIs nutzen HTTP auf Port 80 oder proprietäre Ports.
• IP-Whitelist: Cloud-gehostete Plattformen wie Make oder Zapier kommunizieren aus festen IP-Bereichen, die Sie in der Firewall hinterlegen können.

Bei selbst gehosteten Lösungen wie n8n auf eigenem Server haben Sie zusätzlich die Aufgabe, die Plattform selbst abzusichern: Welche IP-Adressen dürfen überhaupt auf das Admin-Interface zugreifen?

Unterschiede zwischen Cloud und Self-Hosted

Make und Zapier (Cloud)

Make und Zapier veröffentlichen Listen ihrer ausgehenden IP-Adressen. Make nutzt laut Produktdokumentation aktuell einen Pool von rund 20 IPv4-Adressen für Europa, die Sie in der Firewall als Quell-IPs für eingehende Webhooks hinterlegen. Zapier bietet eine ähnliche Liste. Beide Plattformen kommunizieren ausschließlich über HTTPS auf Port 443.

Vorteil: Sie müssen keine eigene Infrastruktur bereitstellen.
Nachteil: Sie haben keinen Einfluss darauf, welche Zertifikate die Plattform für ausgehende Verbindungen nutzt, und ob Logdateien im Drittland gespeichert werden.

n8n (Self-Hosted)

Wenn Sie n8n auf eigenem Server betreiben, kontrollieren Sie jede ausgehende Verbindung. Die Plattform läuft in einem Container oder einer virtuellen Maschine, die Sie in ein eigenes Netzwerksegment legen können. Firewall-Regeln definieren Sie dann so:

• Eingehend zum n8n-Container: Nur aus dem IP-Bereich Ihrer Verwaltung oder via VPN.
• Ausgehend vom Container: Nur zu den tatsächlich benötigten API-Endpunkten. Das erfordert Whitelist-Pflege, zahlt sich aber in der Sicherheit aus.

Firewall-Regeln Schritt für Schritt aufbauen

1. Inventarisieren Sie alle Verbindungen

Listen Sie auf, welche externen Dienste die Workflows ansprechen. Beispiel:

• DATEV-API unter api.datev.de
• Slack-Webhook hooks.slack.com
• Google Sheets API sheets.googleapis.com

Ermitteln Sie für jeden Dienst die IP-Adressen oder IP-Bereiche. DNS-Auflösung allein reicht nicht, da sich IPs ändern können. Dokumentieren Sie das Ergebnis in einer Tabelle mit Spalten: Dienst, FQDN, IP-Bereich, Port, Protokoll.

2. Segmentieren Sie Ihr Netzwerk

Legen Sie die Workflow-Plattform in ein eigenes VLAN oder Subnet, getrennt von Ihrer Produktionsdatenbank und den Arbeitsplatz-PCs. So begrenzen Sie den Schaden, falls die Plattform kompromittiert wird.

3. Definieren Sie Regeln nach dem Whitelist-Prinzip

Erlauben Sie nur, was explizit gebraucht wird. Beispiel für n8n auf eigenem Server:

• Eingehend: Port 443 (HTTPS) nur aus dem IP-Bereich (Ihr Büro-Netz).
• Ausgehend: Port 443 zu (DATEV-API-Range), (Slack), (Google Cloud IPs).
• Alles andere: Default Deny.

Bei Cloud-Plattformen wie Make tragen Sie die veröffentlichten IP-Adressen als erlaubte Quellen für eingehende Webhooks ein.

4. Aktivieren Sie Logging

Jede Firewall kann Verbindungsversuche protokollieren. Aktivieren Sie Logging für alle Deny-Regeln. So sehen Sie sofort, wenn ein Workflow versucht, eine nicht freigegebene API zu erreichen.

5. Testen Sie die Regeln in einer Staging-Umgebung

Rollen Sie die neuen Regeln zuerst auf einem Testsystem aus. Lassen Sie alle produktiven Workflows einmal durchlaufen und prüfen Sie die Logs. Erst wenn kein unerwarteter Deny mehr auftaucht, aktivieren Sie die Regeln produktiv.

Rechenbeispiel: Aufwand und Risikominderung

Angenommen, ein Mittelständler mit 50 Mitarbeitenden betreibt n8n selbst und verbindet 8 externe Dienste. Ohne präzise Firewall-Regeln sind alle ausgehenden Ports offen, die Angriffsfläche entspricht dem gesamten Internet. Ein Angreifer, der Zugang zum n8n-Container erhält, kann beliebige Command-and-Control-Server erreichen.

Mit Whitelist-Regeln reduziert sich die erlaubte Zielmenge auf 8 IP-Bereiche und Port 443. Der initiale Aufwand liegt bei etwa 4 Stunden für Inventarisierung, Regelaufbau und Test. Jeder neue Dienst erfordert rund 20 Minuten: DNS-Auflösung, IP-Bereich recherchieren, Regel hinzufügen, testen.

Im Schadensfall könnte ein kompromittierter Workflow ohne Firewall-Regeln Daten an beliebige Ziele exfiltrieren. Die DSGVO-Bußgeldleitlinien der Aufsichtsbehörden sehen bei vorsätzlicher Verletzung der Sicherheitspflichten aus Artikel 32 DSGVO Bußgelder bis zu 10 Millionen Euro oder 2 Prozent des weltweiten Jahresumsatzes vor, je nachdem, welcher Betrag höher ist (Artikel 83 Absatz 4 DSGVO). Präzise Firewall-Regeln gehören zu den technischen Maßnahmen, die das Risiko solcher Vorfälle senken.

Was in der Praxis oft schiefgeht

• Vergessene Regelaktualisierung: Ein Cloud-Dienst ändert seine IP-Bereiche, die Firewall blockt, der Workflow steht. Lösung: Abonnieren Sie Change-Notifications der Anbieter oder prüfen Sie quartalsweise.
• Zu breite Bereiche: Statt der konkreten API-IPs erlauben Sie den gesamten AWS- oder Azure-IP-Space. Damit verlieren Sie die Filterwirkung. Lösung: Nutzen Sie die vom Anbieter dokumentierten, schmalen Ranges.
• Keine Dokumentation: Sechs Monate später weiß niemand mehr, warum Port 8080 zu 203.0.113.42 offen ist. Lösung: Pflegen Sie eine zentrale Firewall-Dokumentation mit Begründung, Datum und Verantwortlichem.
• Eingehende Webhooks ohne TLS-Client-Auth: Jeder, der die Webhook-URL kennt, kann Daten senden. Lösung: Nutzen Sie Webhook-Tokens oder IP-Whitelisting auf Anwendungsebene zusätzlich zur Firewall.

DSGVO und Auftragsverarbeitung

Wenn Sie eine Cloud-Plattform nutzen, fließen personenbezogene Daten möglicherweise über deren IP-Bereiche. Der Auftragsverarbeitungsvertrag muss Subunternehmer und deren Standorte auflisten. Ihre Firewall-Regeln sollten dazu passen: Erlauben Sie nur IPs in der EU oder in Ländern mit Angemessenheitsbeschluss, falls der AV-Vertrag das verlangt.

Bei Self-Hosted n8n auf eigenem Server in Deutschland haben Sie die volle Kontrolle. Die Firewall kann zusätzlich Geo-IP-Filter nutzen, um ausgehende Verbindungen in Drittländer zu blockieren, falls das Ihre Datenschutz-Folgenabschätzung vorschreibt.

Monitoring und Incident Response

Logs allein helfen nicht, wenn sie niemand liest. Richten Sie Alerts ein, die bei ungewöhnlichen Verbindungsmustern auslösen:

• Mehr als 10 Deny-Events pro Minute aus dem n8n-Segment.
• Verbindungsversuche zu IPs außerhalb der freigegebenen Bereiche.
• Plötzlicher Anstieg ausgehender Datenmenge.

Integrieren Sie die Firewall-Logs in Ihr SIEM oder ein einfaches Monitoring-Dashboard, das die Geschäftsführung täglich per E-Mail erhält.

Zusammenspiel mit SSL-Zertifikaten

Firewall-Regeln prüfen IP, Port und Protokoll, nicht den Inhalt verschlüsselter Verbindungen. Damit die Plattform HTTPS-APIs ansprechen kann, muss sie dem Zertifikat des Zielservers vertrauen. Bei Self-Hosted n8n pflegen Sie den Trust-Store des Containers. Achten Sie darauf, dass nur öffentlich vertrauenswürdige CAs enthalten sind, keine selbstsignierten Zertifikate ohne Prüfung.

Für eingehende Webhooks braucht die Plattform ein eigenes Zertifikat. Nutzen Sie Let’s Encrypt oder ein internes PKI-Zertifikat, das von allen externen Diensten akzeptiert wird. Die Firewall selbst terminiert kein TLS, das übernimmt ein Reverse Proxy vor der Plattform.

Regelmäßige Überprüfung und Anpassung

Firewall-Regeln sind kein Set-and-Forget. Planen Sie quartalsweise:

• Review der Regel-Dokumentation: Welche Verbindungen werden noch gebraucht?
• Test aller Workflows: Läuft alles durch, oder gibt es neue Deny-Einträge?
• Update der IP-Whitelists: Haben Make, Zapier oder API-Anbieter neue Ranges veröffentlicht?

Protokollieren Sie jede Änderung mit Datum, Grund und Freigabe durch die IT-Leitung. Das erfüllt nicht nur interne Compliance-Anforderungen, sondern hilft auch bei externen Audits.

Nächste Schritte

Präzise Firewall-Regeln schützen Ihre Workflow-Plattform vor ungewolltem Datenabfluss und erleichtern die DSGVO-Dokumentation. Wenn Sie wissen möchten, welche Regeln für Ihre konkrete Plattform und Ihre angebundenen Dienste nötig sind, oder Unterstützung bei der Netzwerksegmentierung brauchen, sprechen Sie uns an.

Sprechen Sie mit uns

Sie möchten das in Ihrem Betrieb umsetzen? Wir bauen die passende Maschine mit Ihnen.

Telefon: 040 468 967 680
E-Mail: info@whitefox-automations.com
Oder über unser Kontaktformular.