© i3d, 123RF

Vamigru verspricht umfassende Automatisierung und Management von Linux-Systemen für KMUs. Wie gut funktioniert das Produkt, das im Kleinen gegen große Konkurrenten wie Ansible & Co. antritt?

Ein Bonmot innerhalb der Agile-Community besagt, dass heute eigentlich jedes Unternehmen eine IT-Firma ist und sich diese Firmen erst anhand ihrer Produkte unterscheiden lassen. Das ist zwar plakativ – doch steckt in der Aussage ein Funken Wahrheit: Heute hängt praktisch jede Firma in irgendeiner Art und Weise von ihrer IT-Infrastruktur ab, ganz gleich ob großer Konzern oder mittelständisches Unternehmen.

Die Größe einer Firma ist aber ausschlaggebend für die Art und Weise, wie das Unternehmen mit der IT umgeht: Große Konzerne beschäftigen riesige IT-Abteilungen oder gründen gleich eine Tochterfirma, die sich um die gesamte Konzern-IT kümmert. Kleine und mittelständische Unternehmen (KMUs) gehen mit IT-Infrastruktur hingegen oft stiefmütterlich um: Dann liegt die ganze Last auf den Schultern eines Admin, der Mädchen für alles ist und die Technik so gut wie eben möglich am Leben hält.

Wer eine riesige IT-Umgebung betreibt, ist eher gewillt, sich mit Themen wie Automatisierung und zentralem Management zu befassen: In einer großen Umgebung multipliziert sich die Zeitersparnis. In kleineren Setups ist Automatisierung oft kein Thema, weil die Überzeugung vorherrscht, der Aufwand für das Design und die Umsetzung stünde letztlich nicht in Relation zum Nutzen.

Dass dies in den meisten Fällen nicht stimmt und Automatisierung auch in kleinen Umgebungen eine Daseinsberechtigung hat, bewies das Linux-Magazin schon oft. Gute Gegenargumente liefert beispielsweise das erst kürzlich vorgestellte Debops [1] : Hier erhalten Admins Playbooks für Ansible, die ohne großen Aufwand nutzbar sind.

Einen anderen Ansatz zur Lösung desselben Problems verfolgt die Secuvera GmbH aus Gäufelden südlich von Stuttgart mit ihrem Produkt Vamigru: Das ist eine Automatisierungslösung, die sich besonders für kleine Setups eignet und eine grafische Oberfläche mitbringt. Nach der Installation eines Masterservers, so das Versprechen des Herstellers, lassen sich Hosts von dort aus problemlos aus der Ferne administrieren, etwa mit Sicherheitsupdates per Mausklick versorgen. Auch um die Themen Monitoring und Alerting kümmert sich Vamigru.

Zusätzliche Sicherheit erhalten mit Vamigru verwaltete Systeme durch die automatische Hinterlegung von Firewallregeln (Abbildung 1) und das Einspielen von Hardening-Paketen. Kurz: Die Funktionsbeschreibung [2] liest sich imposant. Aber hält die Software, was sie verspricht? Macht sie den Admins kleinerer Unternehmen das Leben leichter?

Abbildung 1: Vamigru zeigt direkt im Webinterface an, welche Firewallregeln für einen bestimmten Host gesetzt sind, und bietet auch die Option, diese direkt im GUI zu editieren.

Die Architektur

Wie bereits erwähnt basiert Vamigru auf dem Prinzip einer zentralen Instanz. Zunächst installiert es der Admin auf einem dedizierten Management-Host. Danach fügt er die anderen Hosts seiner Installation per Mausklick über ein Web-GUI hinzu. Bemerkenswert: Die Vamigru-Architektur basiert nicht auf dem Client-Server-Prinzip. Einen separaten Agent, der auf den durch Vamigru verwalteten Hosts läuft und über ein spezielles Protokoll Befehle vom Masterserver entgegennimmt, gibt es nicht.

Stattdessen setzt Vamigru an dieser Stelle auf das standardisierte SSH-Protokoll und tut es damit Ansible gleich, wo eben dieser Ansatz seit Jahren bestens funktioniert. Für den Admin ist das von Vorteil: Geht mal etwas schief, sieht er sich keinen speziellen Programmen und Protokollen gegenüber, sondern kann direkt in den gängigen Logs nach der Ursache für das Problem suchen.

Der Vamigru-Server

Wer Vamigru produktiv nutzen will, benötigt vom Hersteller dafür eine zur Gesamtzahl der zu verwaltenden Knoten passende Lizenz. Auf das Preismodell von Vamigru geht der Artikel später noch im Detail ein. Wichtig für den Augenblick ist, dass der Admin nicht gezwungen ist, die Katze zu Sack kaufen: Eine 30-tägige Trial-Lizenz stellt er sich auf der Vamigru-Website [3] einfach selbst aus. Die ist zwar auf nur drei Ziel-Hosts beschränkt, bietet sonst aber alle Funktionen.

Die Lizenz hinterlegt der Admin direkt im Webinterface von Vamigru. Damit das geht, muss zunächst der Vamigru-Server selbst laufen. Das funktioniert aktuell nur unter Ubuntu 16.04. Zwar schreibt der Anbieter in seinen FAQ, dass prinzipiell auch Debian-Systeme nutzbar seien, möchte hierfür jedoch weder Garantie noch Support geben.

Auch bei den Zielsystemen dominiert Ubuntu, wo Vamigru alle aktuellen LTS-Distributionen unterstützt. Damit ist klar: Wer kein Ubuntu nutzt, findet mit Vamigru keine Hilfe. Umgekehrt schon: Für Ubuntu 16.04 bietet der Hersteller fertige Debian-Pakete an, die sich per »apt-get« installieren lassen, sodass der Remote-Verwaltung danach eigentlich nichts mehr im Wege steht. Im Test war das Setup des Vamigru-Servers aber deutlich unbequemer als vom Hersteller versprochen – und zwar aus mehreren Gründen.

Die Installation des Masters

Wer den Vamigru-Master installieren möchte, findet auf der Vamigru-Website dazu die entsprechende Anleitung [4]. Zwei CLI-Befehle reichen aus: Im ersten Schritt fügt der Admin auf seiner – idealerweise frischen – Installation von Ubuntu 16.04 den GPG-Schlüssel von Vamigru in seinen APT-Keyring ein, damit »apt-get« das Vamigru-Repository als vertrauenswürdige Paketquelle nutzt. Im zweiten Schritt installiert er das Vamigru-Paket, das im selben Atemzug alle nötigen Dienste aufspielt und auch entsprechend vorkonfiguriert. Sobald das Vamigru-Paket installiert ist, soll sich der Master-Host nutzen lassen.

In der Praxis sorgt allerdings zunächst das ».deb«-Paket, das der Hersteller anbietet, für ungläubiges Staunen: Der Autor dieses Artikels ist seit 14 Jahren Debian-Entwickler und hat zwischenzeitlich selbst künftige Debian-Entwickler ausgebildet. Die qualitativen Ansprüche an ».deb«-Pakete sind ihm also durchaus geläufig, ebenso wie die Tatsache, dass sich ein Paket mit »lintian« hervorragend auf seine Compliance mit der Debian-Policy hin überprüfen lässt. Jene ist für Debian-Paketbauer wie eine Bibel: In ihr sind die Standards definiert, an die Pakete sich halten müssen, um Einzug in Debian und damit sukzessive auch in Ubuntu halten zu können.

Beim ».deb«-Paket für Vamigru haben dessen Entwickler aber offensichtlich geschlampt. Über 600 kritische Fehler (»Error«) wirft Lintian aus, von denen der größte Teil auf Dateien in »/opt« entfällt. Bei jenen Fehlern handelt es sich zwar um False Positives, denn laut Filesystem Hierarchy Standard (FHS, [5]) ist »/opt« gerade dafür vorgesehen, zusätzliche Software von Drittanbietern zu beherbergen. Aber: Einerseits hätte man diese Fehler per »overrides«-File innerhalb des Pakets ausblenden können, andererseits beläuft sich die Zahl der kritischen Fehler auch ohne die Dateien in »/opt« noch auf deutlich über 40.

Weil Debian-Pakete auf dem Zielsystem notwendigerweise mit Rechten von »root« laufen, hinterlässt eine solch radikale Ignoranz der gängigen Paketstandards von Debian einen mehr als faden Beigeschmack – und das erst recht bei einer Lösung, die sich an Admins wendet und vorgibt, ihnen das Leben durch definierte Standards zu erleichtern.

Das erste Login

Immerhin: Der Anbieter hält mit seinem verkorksten Debian-Paket das Versprechen der simplen Installation. Am Ende von »apt-get install Vamigru« gibt das Paket auf der Kommandozeile eine Kombination aus Benutzernamen und Passwort aus. Im nächsten Schritt öffnet der Admin die IP-Adresse oder den Hostnamen des Vamigru-Servers im Browser und gelangt zu dessen Webinterface, wo mit den eben ausgegebenen Credentials das Login gelingt.

Jedenfalls wenn man zuvor die SSL-Warnung wegklickt: Vorbildlich installiert Vamigru nämlich den eigenen Management-Host gleich so, dass er nur per SSL erreichbar ist, und nutzt dafür notgedrungen ein selbst signiertes Zertifikat. Wer ein echtes SSL-Zertifikat für den Vamigru-Server hat, kann es nach der Vamigru-Installation einspielen und der SSL-Warnung sofort den Garaus machen.

Die Sache mit der Lizenz

Das Webinterface des Vamigru-Servers begrüßt den Admin direkt nach der erfolgreichen Installation mit diversen Warnmeldungen. So fordert es etwa dazu auf, eine gültige Mailserver-Konfiguration zu hinterlegen, sodass Vamigru selbst in der Lage ist, E-Mails zu verschicken – gerade im Monitoring-Kontext ist das wichtig.

Für den Hersteller scheint ebenso wichtig zu sein, dass der Admin eine Lizenz hinterlegt, um überhaupt Hosts zum Vamigru-Setup hinzufügen zu können, denn ab Werk liegt dem Dienst eine Pseudolizenz bei, die dies verhindert. Öffnet der Admin die Seite der Lizenzverwaltung, gibt Vamigru dort einen verschlüsselten Textblock aus, den er auf der Vamigru-Website eingibt. Die generiert dann einen weiteren verschlüsselten Text, die eigentliche Lizenz, die sich im Webinterface des Vamigru-Servers hinterlegen lässt.

Im Test funktionierte das leider nicht ganz reibungslos: Bei den ersten beiden Versuchen wies der Vamigru-Server die Lizenz als ungültig zurück. Erst zwei Klicks auf »Reset« und das nochmalige Pasten der Lizenzdatei von der Vamigru-Website führten dazu, dass Vamigru, wie bei der Trial-Lizenz vorgesehen, das Hinzufügen von drei externen Servern als Möglichkeit anbot (Abbildung 2).

Abbildung 2: Nach einigen Schwierigkeiten akzeptiert Vamigru schließlich die 30-tägige Trial-Lizenz, mit der sich drei Server verwalten lassen.

Der erste Host

Ist das Setup des Vamigru-Servers erfolgreich abgeschlossen, geht es mit dem Hinzufügen des ersten Hosts weiter. Hier bietet Vamigru über den im Webinterface vorhandenen Menüpunkt »Configuration | Overview« (Abbildung 3) zwei Arten von Hosts an: Ein Managed-Host ist ein Host, auf dem Vamigru sich per SSH einloggt, um ihn zum festen Bestandteil des Vamigru-Setups zu machen.

Abbildung 3: In der Übersicht der vorhandenen Server sieht der Admin sofort, welche Server vorhanden sind und welche Regeln für sie gelten.

Soll der Vamigru-Master einen anderen Host nur ins Monitoring aufnehmen, gibt es die Option des Monitor-only-Hosts. Dabei kommt es zu keinem SSH-Login, das integrierte Vamigru-Monitoring prüft lediglich einige Werte des Zielsystems. Für jeden Host legt der Admin sowohl den Hostnamen oder die IP-Adresse des Zielsystems fest als auch einen Displaynamen, unter dem der Host im Vamigru-Webinterface firmiert.

Wichtig für das Server-Setup ist, dass der Vamigru-Server den Ziel-Host per SSH erreichen kann. Ist das der Fall, klickt der Admin auf den giftgrünen »Next«-Button und staunt im nächsten Schritt vermutlich nicht schlecht: Vamigru zeigt einen länglichen Kommandozeilenbefehl an, den er nach einem SSH-Login auf dem Zielsystem per Copy & Paste auf eben jenem Server ausführen soll.

Der Befehl legt einen Nutzer »vamigru« an und stattet ihn mit »sudo«-Rechten aus; er hinterlegt auch einen SSH-Pubkey im »authorized_keys«-File des Nutzers, sodass Vamigru sich ohne Passwort auf dem System einloggen kann. Das ist etwas unkonventionell, hat im Test aber gut funktioniert: Nach diesem Schritt konnte Vamigru sich auf dem Rechner einloggen – die Einrichtung des Host war abgeschlossen.

Die Arbeit mit Patchgroups

Hat der Admin das Hinzufügen seiner Hosts zum Setup erledigt, bietet der Menüpunkt »Configuration | Patchgroups« eine interessante Option: Hier kann er Hosts nämlich in Gruppen sortieren. Die beachtet Vamigru im weiteren Verlauf, etwa wenn es Sicherheitsupdates ausrollt: Das System bearbeitet nur die Hosts, die zu einer Patchgroup gehören, mit den Kommandos, die der Admin für diese Gruppe vorgesehen hat.

Das ist hilfreich: Wer etwa ein redundantes Setup pflegt, kann auf diese Weise nur die eine Hälfte der Server aktualisieren und danach prüfen, ob es zu Fehlfunktionen kommt. Erst wenn diese Hälfte erfolgreich aktualisiert ist, spielt der Admin dann auf der anderen Cluster-Hälfte auch Updates ein.

Damit Vamigru auf den gemanagten Systemen Updates installiert, braucht es mindestens eine Patchgroup. Für die darf der Admin genau festlegen, wann das Update stattfinden soll und in welcher Weise und in welcher Reihenfolge die einzelnen Server zu aktualisieren sind. Falls er nach dem Einspielen von Updates einen automatischen Reboot will, gibt es auch dafür eine Option. Schließlich gibt es hier auch noch den »PATCH NOW«-Button: Der startet das Update sofort und unabhängig von der konfigurierten Zeit.

Was leistet Vamigru in der Praxis?

Bei der Prüfung auf Herz und Nieren fallen sofort ein paar Dinge auf: Für jeden Host, der in Vamigru als Zielsystem konfiguriert wird, erscheinen im Webinterface des Vamigru-Servers sofort Graphen, die Auskunft über die Systemlast geben. Weil der Server beim Aufnehmen des Zielsystems in Vamigru einen Portcheck durchführt, erkennt er dort laufende Dienste und richtet für diese obendrein ein Dienst-Monitoring ohne Zutun des Admins ein. Auch ein Ping-Check gehört zum Programm, sodass es Vamigru auffällt, wenn der Host nicht mehr erreichbar ist. Dann gibt es entsprechende Warnungen per E-Mail.

Ein weiteres interessantes Detail verbirgt sich hinter den Hardening-Profilen: Unter diesem Oberbegriff fasst Vamigru verschiedene Aktionen zusammen, die es auf jenen Servern ausführt, die einem bestimmten Profil zugewiesen sind. Ab Werk kommt Vamigru mit vier Profilen daher:

• »Basic« bezieht sich auf grundlegende Schutzmaßnahmen wie die Anpassung von Dateirechten.
• »SSH« ist ein Profil speziell für SSH-Server. Es legt etwa fest, dass Firewall-Regeln den Zugriff nur auf Port 22 erlauben, und installiert zusätzlich den Dienst »fail2ban«, der ein Login verhindert, wenn ein bestimmter User zu oft ein falsches Passwort angegeben hat. Das SSH-Profil verändert auch das beim Login angezeigte Banner, sodass dieses auf die Überwachung aufmerksam macht (Abbildung 4). Obendrein konfiguriert Vamigru bei Anwendung dieses Profils den Server so um, dass das Login als Root nicht mehr funktioniert und das Passwort-basierte SSH-Login ebenso wenig. Das ist möglicherweise ein Problem: Wer für seine Nutzer noch keinen SSH-Key im ».ssh/authorized_keys«-File im persönlichen Ordner hinterlegt hat, kommt nach dem Ausführen des SSH-Profils weder per SSH noch als Root wieder auf das System – und sperrt sich so möglicherweise aus.

Abbildung 4: Wer sich auf einem von Vamigru verwalteten System einloggt, sieht das sofort anhand des installierten Banners.

• »Logging«-Profil ist ein weiteres interessantes Profil. Es aktiviert auf dem Host verschiedene Monitoring- und Logging-Dienste, die beispielsweise penibel über das Verändern von Dateien auf dem System Buch führen. So fällt im Falle eines Falles schneller auf, wenn sich jemand unbefugt Zugriff aufs System verschafft hat und es nun nach eigenem Gutdünken umkonfiguriert.
• »Webserver« – dieses Profil verrät schon durch seinen Namen den Zweck. Es hinterlegt eine für Webserver passende Konfiguration der Firewall und gewöhnt Apache verschiedene Verhaltensweisen ab, die gegebenenfalls ein Problem in Sachen Sicherheit und Compliance darstellen würden. Ein Manko ist allerdings, dass sich das »Webserver«-Profil nur auf solche Hosts anwenden lässt, auf denen Vamigru selbst einen Webserver erkannt hat. Bei einem Webserver, auf den Vamigru nicht von allein aufmerksam geworden ist, verweigert die Software beim Zuweisen des Profils stur den Dienst.

Compliance und Basismonitoring

In Summe lassen sich die Maßnahmen, die Vamigru auf den Zielservern umsetzt, eher der Compliance-Kategorie zuordnen. Secuvera weist auf der Vamigru-Website etwa explizit darauf hin, dass sich die installierten Firewallregeln und die Maßnahmen, die für das Abhärten eines Webservers genutzt werden, streng an den Vorgaben von BSI und NIST orientieren. Vamigru sorgt auf seinen Systemen also durch vorbeugende Maßnahmen dafür, dass Angriffe schwieriger sind und weniger Erfolg versprechen.

Die einzelnen Logging- und Protokollwerkzeuge der Lösung tragen dazu bei, Einbrüche früher und besser zu erkennen: Neben dem Überwachen der umgesetzten Firewallregeln loggt Vamigru auf den Zielsystemen auch ausgeführte Befehle mit. Wenn jemand direkt auf dem System Firewallregeln ändert, alarmiert Vamigru den Admin per E-Mail. Verändert jemand eine Datei, die Vamigru zuvor nach den eigenen Regeln abgehärtet hat, dann zeigt es das sofort im Webinterface an und gibt auch ein Diff aus, das kenntlich macht, welche Änderungen geschehen sind.

Explizit bewirbt Secuvera, dass Vamigru auch Monitoring-Funktionen enthält und bei Bedarf Alarm schlägt. Konkret prüft Vamigru regelmäßig diverse Parameter der Zielsysteme, zum Beispiel die CPU-Last, RAM-Nutzung oder die Verwendung des vorhandenen Speicherplatzes. Nutzt ein System aktiv Swapspace, versucht Vamigru, diesen automatisch zu leeren, und alarmiert den Admin, falls es dabei nicht den erhofften Erfolg hat. Fallen Netzdienste aus, erhält der Admin ebenfalls eine E-Mail.

De facto lässt sich das Vamigru-Monitoring am ehesten mit den von Icinga & Co. angebotenen Basischecks für neue Hosts vergleichen (Abbildung 5). Wer allerdings feineres Monitoring vorsehen will oder solche Parameter überwachen möchte, die in Vamigru als Monitoringziel nicht bekannt sind, schaut in die Röhre: Hier bräuchte der Admin dann wieder ein umfassenderes System, dessen Konfiguration und Betrieb aber auch deutlich aufwändiger wären.

Abbildung 5: Das durch Vamigru gebotene Monitoring ist rudimentär, genügt aber, wenn man lediglich die wichtigsten Parameter überwachen will.

Ungenutztes Potenzial

Vamigru ist kein vollwertiger Ersatz für Ansible, Puppet & Co. Das wird dem Admin spätestens dann schmerzlich klar, wenn er den Wunsch hat, mit Vamigru auf den gewarteten Systemen beliebige Software zu installieren. Anders als bei Ansible & Co. unterstützt Vamigru diese Funktionalität nämlich nicht: Wer beispielsweise für einen Webserver MySQL oder Apache ausrollen möchte, der tut das auf dem jeweiligen System zu Fuß. Er installiert also selbst die für den Dienst benötigten Pakete und spielt auch die Konfigurationsdatei selbst ein.

Im weiteren Verlauf ist das Setup zwar Teil des Vamigru-Workflow, etwa wenn es um das Aktualisierten der Pakete innerhalb der Patchgroup geht. Die eigentliche Basisarbeit, die etwa Debops für Ansible durchführt, bleibt jedoch bei Vamigru auf der Strecke. Damit fällt das Werkzeug eher in die Kategorie Systemverwaltungen als in die Kategorie Automatisierer: Verschiedene Tasks arbeitet Vamigru zwar automatisch ab, doch wer auch die Installation und Konfiguration externer Dienste automatisieren will, der ist gezwungen, zu anderen Hilfswerkzeugen wie Ansible zu greifen.

Das ist schade, weil Vamigru hier viel Potenzial ungenutzt lässt: Debops etwa hat bewiesen, dass es durchaus möglich ist, fertige Ansible-Playbooks für die wichtigsten Dienste generisch zur Verfügung zu stellen. Und es gäbe sicher einen Mehrwert für Admins, wenn Vamigru auf einem Host eben nicht nur Complianceregeln für Webserver ausrollen könnte, sondern gleich auch ein einfaches Webserversetup inklusive der Installation der nötigen Software.

Insofern wäre es zu begrüßen, würde Vamigru hier seine Funktionalität erweitern – etwa um die wichtigsten Dienste, die KMUs üblicherweise einsetzen, zum Beispiel Apache, Maria DB, Postfix oder Samba. Die Grundlagen dafür sind in Vamigru angelegt, der Hersteller könnte solche Funktionen also nachrüsten.

Bare Münze

Erfrischend unkonventionell gibt sich Vamigru im Hinblick auf die Preise. Während andere Anbieter mauern und in der Öffentlichkeit überhaupt keine Zahlen nennen, nennt Secuvera alle Preise offen auf der Website [6]: Wer nicht mehr als fünf Server verwaltet, zahlt pro Server und Jahr rund 60 Euro. Bis zu 20 Server fallen gut 45 Euro pro Server und Jahr ins Gewicht. Bis 40 Server kostet jeder davon pro Jahr gut 40 Euro. Alle Angaben sind Brutto-Preise.

Wer mehr Server mittels Vamigru verwalten möchte, kann sich alternativ ein individuelles Angebot vom Anbieter vorlegen lassen. Der Preis für 40 Server ist durchaus marktfähig: 1500 Euro für die Fernverwaltung von 40 Servern sind ausgesprochen günstig. Das direkte Gegenprodukt, Canonicals Landscape, kommt pro Maschine mit deutlich größerem Preisschild daher.

Fazit

Vamigru hält, was der Hersteller verspricht: Mit relativ wenig Aufwand ist es den Admins kleiner Serverparks dank der Software möglich, ihre Systeme von einer zentralen Stelle aus zu steuern. Das umfasst Updates und auch die Option, auf den Zielservern die Einhaltung grundlegender Compliance-Regeln zu erzwingen. Wer lediglich simples Dienste-Monitoring und die Überwachung grundlegender Serverparameter braucht, ist mit dem Vamigru-Monitoring gut bedient.

Nachholbedarf besteht jedoch bei der Installation des Vamigru-Servers. Die Qualität des vom Hersteller angebotenen Debian-Pakets ist katastrophal und eigentlich ein Grund, die Installation der Software gar nicht erst in Betracht zu ziehen. Das Hinterlegen einer Lizenz in Vamigru ist hakelig und ließe sich sinnvoller gestalten; andere Anbieter machen es vor. Hat man die Hürden der ersten Installation überwunden, funktioniert der Dienst – mit Ubuntu – allerdings sehr gut und zuverlässig.

Wünschenswert wäre es, wenn Vamigru zusätzlich auch weitere wichtige Dienste auf seinen verwalteten Servern ausrollen könnte, die in KMUs regelmäßig zur Anwendung kommen. Auf der Basis von Ansible & Co. ließe sich das sogar hinreichend schnell umsetzen, weil es für praktisch jeden Linux-Standard-Dienst im Netz Playbooks gibt, die auch Ubuntu 16.04 abdecken.

Preislich attraktiv ist das Angebot allemal: Canonical will im Rahmen des Landscape-Programms 750 US-Dollar pro Jahr haben – wohlgemerkt pro Server. Dafür erhalten KMU-Admins viele Funktionen, die sie vermutlich gar nicht brauchen. Vamigru geht schlauer vor und bietet ihnen seine Dienste zu einem vernünftigen Preis an, der sich selbst dann begründen lässt, wenn das Unternehmen gar keinen IT-Schwerpunkt hat.

Zusammengefasst gilt: Gelingt es dem Hersteller, die wenigen unschönen Aspekte der aktuellen Implementierung auszumerzen, hat die Lösung eine reale Chance darauf, bei der relevanten Zielgruppe zu punkten.