Ausgangslage

Ab dem 1. Januar 2025 müssen alle Unternehmen in Deutschland Rechnungen anderer inländischer Unternehmer im XML-Format empfangen und verarbeiten können.

Ziel dieser gesetzlichen Vorgabe ist es, Rechnungsprozesse durch Standardisierung effizienter zu gestalten - und mittelfristig das Finanzamt über jede Rechnung in Echtzeit informieren zu können. Besonders kleine und mittlere Unternehmen stehen jedoch vor der Herausforderung, ihre bisherigen Systeme und Abläufe an diese neuen Anforderungen anzupassen.

Was bedeutet die E-Rechnungspflicht für KMUs?

Die E-Rechnungspflicht erfordert, dass Rechnungen künftig in einem standardisierten XML-Format vorliegen, das speziell für den digitalen Austausch zwischen Unternehmen und öffentlichen Stellen entwickelt wurde. Spannenderweise gibt es gleich mehrere Formate, die die gesetzlichen Anforderungen erfüllen.

Diese Format ermöglichen eine automatisierte Verarbeitung, sind jedoch ohne spezielle Software nicht lesbar oder gar zu prüfen. Unternehmen, die diese Anforderungen nicht rechtzeitig umsetzen, können Schwierigkeiten bei der Rechnungsabwicklung oder der Einhaltung gesetzlicher Vorgaben bekommen.

Wie können Unternehmen die neuen Anforderungen umsetzen?

Die Einführung eines Systems, das XML-Rechnungen lesbar macht und verarbeitet, ist für die Einhaltung der gesetzlichen Anforderungen unerlässlich. Lösungen wie VeriBill wurden entwickelt, um den Umstieg auf die E-Rechnungspflicht zu erleichtern. Dabei stehen insbesondere folgende Funktionen im Vordergrund:

• Verarbeitung und Prüfung von XML-Rechnungen
  Rechnungen können eingelesen, geprüft und für die Weiterverarbeitung freigegeben werden.
• Übersichtlichkeit
  XML-Daten werden in ein lesbares Format umgewandelt, sodass Unternehmen weiterhin einen klaren Überblick behalten.
• Kompatibilität
  Neben der Kompatibilität zu allen gesetzeskonformen Standard sind Lösungen wie VeriBill häufig auch auf verschiedenen Plattformen (z. B. Windows und Mac) einsetzbar und unterstützen somit unterschiedliche Unternehmensumgebungen.
• Zukunftssicherheit
  Systeme, die speziell für diese neuen Anforderungen entwickelt wurden, sorgen dafür, dass Rechnungsprozesse langfristig gesetzeskonform und effizient bleiben.

Warum ist es wichtig, frühzeitig zu handeln?

Die Frist zur Einführung der E-Rechnungspflicht rückt näher, und Unternehmen sollten sich rechtzeitig auf die Umstellung vorbereiten. Neben der Auswahl einer passenden Softwarelösung ist es sinnvoll, bestehende Prozesse zu analysieren und anzupassen. Dies hilft nicht nur bei der Erfüllung der gesetzlichen Vorgaben, sondern kann auch langfristig zu effizienteren Abläufen beitragen.

Schritte zur Umsetzung

• Analyse der aktuellen Prozesse
  Welche Systeme und Prozesse werden derzeit zur Rechnungsverarbeitung genutzt, und wo bestehen Anpassungsbedarfe?
• Auswahl einer geeigneten Lösung
  Unternehmen sollten darauf achten, dass die gewählte Software sowohl gesetzeskonform ist als auch zu den eigenen Anforderungen passt.
• Schulung und Implementierung
  Mitarbeiter sollten in die Nutzung der neuen Systeme eingewiesen werden, um einen reibungslosen Übergang zu gewährleisten.
• Regelmäßige Überprüfung
  Nach der Umstellung sollten die neuen Prozesse regelmäßig überprüft werden, um sicherzustellen, dass sie den Anforderungen entsprechen.

Fazit

Die E-Rechnungspflicht ab 2025 ist ein bedeutender Schritt in Richtung Digitalisierung von Unternehmensprozessen. Während die Umstellung zunächst komplex erscheinen mag, kann sie mit der richtigen Vorbereitung und geeigneten Softwarelösungen gut gemeistert werden. Unternehmen, die frühzeitig handeln, profitieren nicht nur von der Einhaltung gesetzlicher Vorgaben, sondern oft auch von effizienteren Abläufen in der Rechnungsbearbeitung.

Ausgangssituation

In einem früheren Bericht hatten wir bereits über die Umstellung eines Kunden von ehemals Sophos auf Mikrotik berichtet. Der Kunde war - und ist - mit der Lösung auch weiterhin zufrieden, aber naturgemäß daran interessiert, eine Lösung aus einem Guss zu nutzen.

Bislang war die IT-Landschaft des Kunden im Hinblick auf WiFi ein wenig zersplittert; es wurden überwiegend UniFi-APs eingesetzt, kombiniert mit einigen WLAN-Repeatern aus dem Hause AVM.

Ziele

• Die bisherigen Access Point sollen abgelöst werden durch Mikrotik cAP AX
• Das Management soll weierhin zentral erfolgen, nur künftig über WinBox
• Die Repeater sollen nach Möglichkeit entfallen

Netzstruktur

Im Zuge der Umstellung auf Mikrotik hatten wir drei VLANs eingerichtet:

1. Firmen-internes Kommunikation
2. Gästenetz
3. Managementnetz

Diese Struktur sollte beibehalten werden. Der CAPsMAN-Traffic soll dabei über das Managementnetz laufen. Jeder AP soll sowohl das Firmennetz, als auch das Gästenetz ausstrahlen und natürlich Roaming bieten.

Vorgehen

Die Dokumentation von Mikrotik in Bezug auf CAPsMAN 2 ist ungewohnt schlecht, vieles bezieht sich auf veraltete Versionen. Ein paar Startschwierigkeiten blieben daher nicht aus.

Grundsätzlich ist der Ablauf aber tatsächlich recht simpel:

Zunächst werden die WiFi-Netze konfiguriert, separat für 2,4 und 5 GHz. Diesen werden dann Sicherheitsprofile (hier WPA3 für das interne Netz und WPA2 für das Gastnetz) zugewiesen. Auch wenn viele Stimmen davor warnen, wurden hier die SSIDs für 2,4 GHz und 5 Ghz identisch gewählt, aber separaten Roaming-Gruppen zugewiesen.

Dazu kommen dann die benötigen DataPaths. Um den CAPsMAN-Traffic über das Management-VLAN leiten zu können, wurden dabei die Switch-Ports der APs so konfiguriert, dass sie das Management-VLAN als PVID untagged benutzen, die beiden anderen VLANs wurden als tagged-VLAN zugewiesen. Entsprechend sind dann auch die DataPaths zu konfigurieren.

Letztlich muss noch die Provisionierung eingerichtet werden, sodass neue APs automatisch ihre Konfiguration erhalten können.

Ist diese Einrichtung soweit erfolgt, muss der neue AP nur noch ans Netz angeschlossen und durch längeres Drücken der Reset-Taste in den CAPsMAN-Modus versetzt werden (was nur unmittelbar nach dem Einschalten funktioniert). Der AP verbindet sich dann mit dem CAPsMAN auf dem Mikrotik-Router und zieht automatisch die Konfiguration.

Nach einigen Experimenten haben wir auf Interworking-Profile verzichtet, da sich hier Inkompatibilitäten mit einigen Endgeräten, insbesondere iPhones, zeigten.

Fazit

Die gewählten Access Points erwiesen sich als zuverlässig, die Reichweite war hoch genug, um die Repeater ersatzlos streichen zu können. Der Kunde ist zufrieden - sowohl im Hinblick auf die Leistung, als auch die Kosten.

Die gesamte Umstellung dauerte nicht länger als einen Arbeitstag.

Neben Softwareentwicklung und Datenschutz bieten wir bekanntlich auch IT-Security und damit zusammenhängende Dienstleistungen an. Heute berichten wir über die Umstellung der Firewall eines Kunden.

Ausgangslage

Bislang haben wir bei Kunden als Firewall in der Regel Hardware von Sophos, vornehmlich die Serien XG und XGS, verbaut. Sophos baut unserer Erfahrung nach zuverlässige Hardware zu einem durchaus akzeptablen Preis. Allerdings sind selbst für Firmware-Updates inzwischen Subscriptions nötig. Kauft man eine neue Sophos XGS sind nur noch 5 Firmwareupdates inkludiert. Selbst wenn man also, wie die meisten unserer Kunden, mit den Basis-Features auskommt, ist eine Subscription dennoch de-facto Pflicht.

Alternativen

Neben Sophos existieren natürlich auch andere namhafte Hersteller, die sich als Alternativen eigenen. Vorrangig zu nennen sind dabei:

• Cisco
• Fortinet
• SonicWall

Daneben existieren natürlich noch eine ganze Reihe anderer Lösungen, die aber in der Regel das Budget unserer Kunden sprengen und daher nicht Betracht kommen. Ferner besteht natürlich auch die Möglichkeit Open-Source-Systeme, wie etwa OPNsense, zu nutzen, wobei diese vom Kunden ausgeschlossen wurden.

Für Cisco und Fortinet sprach vor allem, dass wir hier bereits über Erfahrungen verfügen. Preislich bieten beide Anbieter gegenüber Sophos allerdings keinen Vorteil.

Durch einen kroatischen Kollegen wurden wir aufmerksam auf einen hierzulande verhältnismäßig unbekannten Hersteller - MikroTik aus Lettland.

Im Gegensatz zu den anderen genannten Lösungen erzeugt eine Lösung auf Basis der Produkte von MikroTik keine laufenden Kosten, die Geräte werden über viele Jahre mit kostenlosen Updates versorgt und sind darüber hinaus auch ausgesprochen preiswert.

Wir besprachen die Optionen mit unserem Kunden. Dieser wünschrte sich eine möglicht kostenffiziente Lösung und daher boten wir ihm an, eine Migration hin zu MikroTik Hardware durchzuführen - nicht ohne darauf hinzuweisen, dass dies für uns Neuland sein würde.

Vorarbeiten

Jeder Administrator, der einmal eine Sophos XG/S administriert hat, wird den enormen Komfort zu schätzen wissen. Die Weboberfläche ist logisch aufgebaut und die Handhabung schnell erlernt.

Arbeitet man hingegen mit MikroTik Routerboards sieht die Sache anders aus. Das Standardwerkzeug zur Administration ist WinBox, ein Programm das den spröden Charm von Windows 3.1 versprüht, ein klassiches MDI-Interface nutzt. Es gibt Alternativen, etwa WebFig, aber das sieht dann in etwa aus, als würde man WinBox im Browser ausführen. Natürlich bietet RouterOS, das Betriebssystem der MikroTik Routerboards, auch ein leistungsfähiges Terminal-Interface, das auch gut scriptbar ist. Für die Ersteinrichtung haben wir uns allerdings für WinBox entschieden.

Ein genereller Unterschied der beiden Systeme ist, dass unter RouterOS nahezu jeder Aspekt konfiguriert werden kann, häufig bis ins kleinste Detail. Dazu kommt, dass durchgängig keine symbolischen Bezeichner (etwa für Ports) verwendet werden. Dadurch fühlt sich die Konfiguration für Ein- und Umsteiger sehr hart und roh an.

Um eine möglichst geringe Downtime zu erzielen, haben wir uns entschieden, wie folgt vorzugehen:

• Dokumentation aller bestehenden Firewall-Regeln
• Dokumentation der gesamten IPsec VPN-Konfiguration
• Nachbau der Konfiguration in RouterOS
• Testen des Setups in unserer Labor-Umgebung
• Vulnerability Scans gegen das neue Setup im Labor
• Tausch der alten Sophos Hardware gegen das neue Routerboard
• Testen des gesamten Setups
• Vulnerability Scans in der Live-Umgebung

Umstellung

Die Dokumentation der Ausgangslage gestaltete sich relativ arbeitsaufwändig, da der Kunde bislang keine Dokumentation hierzu besaß; dieser erhielt er nun im Rahmen des Projekts gratis on-top. Einige nicht benötigte Regeln wurden identifiziert und für die Umstellung verworfen.

Die VPN-Konfiguration hatten wir erst vor einigen Monaten dokumentiert und konnten jetzt darauf zurückgreifen.

So begannen wir nun mit der Konfiguration des Routerboards, wobei wir uns für erste Tests eng an die vorliegende - und wirklich gute - Dokumentation von MikroTik hielten. Das Ergebnis war bereits eine gut arbeitende Firewall, die in dieser Form sicherlich vielen Mittelständlern gut gedient hätte.

Unser Kunde hat jedoch aus regulatorischen Gründen besonders hohe Sicherheitsanforderungen. Im Anschluss befassten wir uns daher genauer mit den Datenfluss-Diagrammen von MikroTik, diese sind übersichtlich und genau. Diese Diagramme sind gerade für Umsteiger extrem hilfreich, da sie auch die Unterschiede zwischen den einzelnen Chains, die sich sehr eng an iptables orientieren, verdeutlichen.

In der Folge bauten wir die alten Regeln nach und richteten die VPN-Verbindungen ein. Dabei stießen wir auf einige Fallstricke, etwa dass IPsec-Traffic nicht durch fast-tracked werden darf, die aber schnell geklärt werden konnten. Interessant hierbei ist, dass es verschiedene Wege gibt, dieses Ziel zu erreichen. Die häufigste Lösung ist die Nutzung von RAW-Regeln, die auf Adress-Bereiche abzielt, allerdings das Connection-Tracking umgeht. Wir haben uns statt dessen dafür entschieden, mangle-Rules und Connection Marking einzusetzen.

RAW-Regeln haben wir ausschließlich als Pre-Checks eingesetzt.

Die Umstellung der VPN-Konfiguration indes war deutlich schwieriger, insbesondere weil MikroTik hier gern von der gängigen Terminologie abweicht und daher ein solides Studium der Dokumentation unerlässlich ist.

Die Vulnerability Scans, die wir zur Kontrolle durchgeführt haben, zeigten ein solides Bild. Nessus und GSA hatten beide nichts am neuen Setup auszusetzen. Tatsächlich gab es sogar einige Warnungen weniger als vorher, da Sophos XGS WebUI noch immer auf TLS 1.0 und TLS 1.1 setzt, was auch nicht ohne weiteres (und vor allem nicht update-sicher) abschaltbar ist.

Zu guter letzt implementierten wir noch einen DNS-basierten AD-Blocker, wofür MikroTik freundlicherweise von Hause aus Optionen mitbringt.

Die eigentliche Umstellung verlief dann tatsächlich ausgesprochen problemlos. Wir hatten ursprünglich eine Downtime von 2 Stunden eingeplant, tatsächlich betrug sie aber lediglich etwa 15 Minuten.

Fazit

Unser Kunde nutzte lediglich die Basis-Features seiner Sophos Firewall, vorrangig die eigentliche Firewall-Funktion (allerdings ohne irgendwelche Next-Gen-Funktionen) und IPsec VPN. Die Migration hat einschließlich der Vorarbeiten etwa 5 Manntage in Anspruch genommen. Die Downtime betrug etwa 15 Minuten.

Die Administration von RouterOS ist komplex und erfordert einige Einarbeitungszeit, die sich aber definitiv lohnt.

Das Routerboard, das ungefähr den gleichen Preis hatte, wie eine 1jährige Subscription bei Sophos, arbeitet problemlos, schnell und zuverlässig. Unser Kunde ist höchst zufrieden.

Der nächste Schritt wird voraussichtlich die Ablösung der Unifi-Access-Points durch MikroTik Hardware sein.

Der heutige Freitag wird überschattet von einem massiven Ausfall von IT-Systemen weltweit.

Hintergrund ist offenbar ein fehlerhaftes Update des CyberSecurity-Dienstleisters CrowdStrike für dessen Hauptprodukt Falcon. Falcon ist ein Softwaresystem, dass Geräte vor Bedrohungen schützen und im besten Fall auch aktiv dagegen vorgehen können soll.

Aufgrund eines Programmierfehlers, der offenbar auch in der Qualitätssicherung nicht bemerkt wurde, stürzten Windows-Systeme, die mit Falcon ausgestattet waren, nach dem automatischen Einspielen des Updates schlicht ab. Was aber noch deutlich schlimmer ist: Falcon ist tief im Betriebssystem verankert - das muss es auch, damit es seiner Aufgabe nachgehen kann. In diesem Fall aber führte das zu einem sogenannten Bootloop, d.h. betroffene Rechner starteten immer und immer wieder neu, ohne jemals betriebsbereit zu werden. Nur ein manueller Eingriff durch die verantwortlichen Administratoren konnte die Rechner wieder zu einem korrekten Systemstart bewegen.

Betroffen von diesem Desaster waren Schätzungen zufolge etwa 8,5 Millionen Rechner weltweit.

Bemerkenswert an diesem Vorfall ist einerseits die große Zahl an betroffenen Computern und andererseits die Frage, wieso ein solch kapitaler Fehler nicht durch die Qualitätssicherung bei CrowdStrike bemerkt werden konnte.

CrowdStrike wird sich sicherlich einige unangenehmen Fragen stellen lassen müssen.

Glücklicherweise waren die meisten Systeme recht schnell wieder einsatzbereit, nachdem CrowdStrike eine Anleitung veröffentlicht hat, um die betroffenen Geräte wiederherzustellen. Die Verzögerungen im weltweiten Flugverkehr werden allerdings sicherlich noch eine Weile andauern.

Einige Kommentatoren hinterfragen bereits, ob der generelle Trend in Richtung Cloud wirklich der richtige Weg ist. Die Frage mag berechtigt sein, allerdings ist der Trend kaum aufzuhalten. Das gesamte Windows-Ökosystem bewegt sich in diese Richtung und das auch nicht erst seit gestern. Ein einzelner Vorfall dieser Art wird daran auch nichts ändern.

Allerdings ist dieser Vorfall sicherlich ein guter Anlass, die eigene IT-Strategie zu prüfen und gegebenenfalls auch kritisch zu hinterfragen - schließlich ist auch Verfügbarkeit üblicherweise ein Schutzziel der Informationssicherheit.