© Leung Cho Pan / 123RF.com

Im Fahrwasser skalierbarer Umgebungen ist das Thema Observability heute wichtiger denn je. Hier setzt Coroot an: Es klinkt sich über eBPF in den Traffic ein und sammelt die für die Überwachung und Angriffserkennung relevanten Daten.

Einbruchserkennung (Intrusion Detection) und Einbruchsvermeidung (Intrusion Prevention) gehören für Admins heute zum Alltag. Im Prinzip funktionieren Lösungen für derlei Themen denkbar einfach: Sie analysieren Datenströme und versuchen durch ausgefeilte heuristische Methoden Muster darin zu erkennen, die auf einen bevorstehenden oder schon stattfindenden Angriff hindeuten. Fällt ihnen eine verdächtige Aktivität auf, schlagen sie Alarm. Administratoren können dann frühzeitig gegensteuern.

Die Palette der Gegenmaßnahmen reicht dabei von einfachen Mitteln wie schnöden Paketfiltern bis hin zu ausgefeilten Firewall-Konstrukten. Letzteren dient beispielsweise der Zustand von Verbindungen als Parameter, um eine Entscheidung für oder gegen das Zustellen von Paketen zu treffen. Darüber hinaus decken klassische Intrusion-Detection- oder Intrusion-Prevention-Systeme längst nicht mehr nur Angriffe in Form von Einbrüchen ab. Oft bieten sie auch Möglichkeiten, um DDoS-Angriffe automatisiert zu identifizieren und vor ihnen zu warnen. So kann der zuständige Admin auf Netzwerkebene sofort dafür sorgen, dass eine Attacke ins Leere läuft.

Obwohl es alles andere als leicht fällt, die markttypischen Lösungen zu verwenden, die grundsätzlich einiges an Wissen und Können voraussetzen, sind solche Systeme an und für sich “dumm”. Immerhin ermitteln sie ausschließlich anhand vorgegebener Muster, ob es sich um einen Angriff handelt oder nicht. Das Prinzip ähnelt dem von Antivirussoftware: Sie erkennt einen Schädling ebenfalls nur, wenn sie die passende Signatur dafür in der eigenen Datenbank findet. Sie braucht also eine Beschreibung, welche Dateien mit welchen Checksummen der Virus umfasst. Fehlt eine solche Signatur, ist das Programm blind gegenüber einer Bedrohung. Nicht zuletzt deshalb existiert ein lukrativer Schadsoftwaremarkt im Darknet, auf dem noch unbekannte Exploits für viel Geld über die virtuelle Ladentheke gehen.

Besser mit KI

Als ein erster zaghafter Ansatz, böswillige Machenschaften im Netz anhand von Mustern automatisch zu unterbinden, dürfen aus heutiger Sicht klassische Anti-Spam-Werkzeuge gelten. SpamAssassin [1] und Rspamd [2] zum Beispiel setzen unter der Haube auf heuristische Methoden, um anhand verschiedener Faktoren zu entscheiden, ob eine E-Mail Spam ist. Dabei verbessern sie sich selbst, wenn der Nutzer sie einmal trainiert hat und regelmäßig korrigierend eingreift.

Das funktioniert frei nach dem Motto: Ist die E-Mail eines Prinzen aus Nigeria mit einem unmoralischen 20-Millionen-Angebot Spam, gilt das für eine E-Mail einer Bank aus Guinea mit demselben Angebot vermutlich ebenso. Dabei spielen etliche Faktoren eine Rolle. Dazu zählt beispielsweise die Wahrscheinlichkeit, dass ein solches Angebot eines Fremden per E-Mail völlig aus dem Blauen heraus beim Empfänger eintrudelt. Doch wie man es auch dreht und wendet: Mit künstlicher Intelligenz haben solche Systeme nichts zu tun. Sie funktionieren rein auf Basis händischen Trainings mit wenigen Automatismen.

Findige Unternehmen versprechen im Fahrwasser der gerade über die Industrie schwappenden KI-Welle bessere Spamfilter und bessere IDS/IPS auf Basis künstlicher Intelligenz. Zur Erinnerung: Hinter den allermeisten Inkarnationen von KI stecken vor allem große Sprachmodelle, also schlicht sehr ausgefuchste Statistik. Das Prinzip bleibt immer dasselbe und ähnelt der Heuristik von Spamfiltern: Auf der Grundlage beliebig vieler Trainingsdaten bringt man dem System bei, auf bestimmte Ereignisse mit bestimmten Mitteln zu reagieren.

Darin liegt auch der Hauptunterschied zu Werkzeugen wie SpamAssassin: KI-Modelle, die unüberwachtes Lernen nutzen, zielen darauf ab, sich letztlich selbst ohne menschliches Eingreifen zu trainieren. So wundert es nicht, dass man in der IT mittlerweile flächendeckend den Wunsch hegt, KI zum Erkennen von Angriffen und Einbrüchen zu verwenden. In diesem Magazin war das bereits mehrmals Thema. Erinnert sei etwa an die verschiedenen KI-Plugins für Prometheus [3], mittels derer sich auf Grundlage von KI-Bibliotheken bestimmte Muster in Metrikdaten automatisiert erkennen lassen. Erst das versetzt Prometheus in die Lage, Alarme auszulösen.

In der Sache einen Schritt weiter gedacht haben die Entwickler von Coroot [4]: Sie bieten eine Art KI-IDS-as-a-Service an. Dabei liefern sie mehrere interessante technische Details, auf die ein genauerer Blick lohnt.

Zentraler Online-Dienst

So viel vorab: Coroot ist ein zentral in der Cloud gehosteter Dienst, dessen Geschäftsmodell auf Subskriptionen beruht. Zwar muss immer eine seiner Komponenten im lokalen Setup laufen, das betrifft aber lediglich die API. Die KI-Fähigkeiten der Lösung lagern dagegen in der Cloud.

Für europäische Kunden impliziert das potenziell Ungemach: Coroot greift tief in die Datenströme der Systeme ein, die es überwachen soll. Das geht gar nicht anders: Schließlich besteht seine zentrale Aufgabe darin, Bedrohungen auf Grundlage des durchfließenden Traffics zu identifizieren. Das heißt allerdings, dass die Daten automatisch den DSGVO-Raum verlassen. Abgesehen davon, dass Unternehmen das möglicherweise nicht möchten, spielt hier also die Compliance-Thematik zwischen amerikanischem CLOUD Act und DSGVO eine Rolle. Wer daran keinen Anstoß nimmt, erhält aber ein hochinteressantes Werkzeug.

Coroot richtet sich vorrangig an Betreiber moderner Systeme, die Containerorchestrierung nutzen. Kubernetes [5] ist dementsprechend in diesem Universum eine feste Größe, und das aus gutem Grund: Praktisch das gesamte Coroot-Modell zum Abgreifen von Daten setzt unter der Haube auf Kubernetes. Obendrein ist Coroot darauf ausgelegt, entsprechende Nutzdaten überhaupt nur von Containern zu sammeln. Das schließt freilich erst einmal nichts aus; heute lässt sich ja nahezu jede Anwendung relativ mühelos containerisiert einsetzen. Administratoren sollten sich mit dem Deployment-Modell jedoch zumindest etwas genauer befassen, wenn sie mit Coroot liebäugeln.

Zunächst gilt es, die wesentlichen Komponenten der Lösung kennenzulernen. Als Dreh- und Angelpunkt der Plattform fungiert Coroot selbst. Es dient einerseits als API und übernimmt andererseits im Hintergrund die Kommunikation mit den Clouddiensten des Anbieters, also dem Teil, der die eigentlichen KI-Funktionen liefert. Es setzt auf zwei Dienste, um seine Daten zu pflegen und zu verwalten. Metrikdaten legt es in der wohlbekannten Zeitreihendatenbank Prometheus ab, die sich einmal mehr als Quasi-Standard in Sachen Metrikdatenspeicherung erweist. Logs, Traces und erkannte Profile legt Coroot in ClickHouse [6] ab.

Bei ClickHouse handelt es sich ebenfalls nicht um eine Coroot-Eigenentwicklung, sondern um eine spaltenbasierte Datenbank, deren Fokus auf der Analyse eingehender Daten liegt. Mittels eines SQL-Dialekts kann sie gespeicherte Daten anhand verschiedener Parameter automatisch analysieren. Wer hier an eine Art Datenbank für Business Intelligence denkt, ist auf dem richtigen Dampfer. Parallel zur Möglichkeit, Daten darin abzulegen, können Prometheus und ClickHouse auch als Datenquelle dienen. Wir haben es also mit einem echten bidirektionalen Austausch zu tun.

Mindestens so wichtig wie die Frage nach dem Speichern von Daten ist aus Coroot-Sicht die nach dem Empfang der zu analysierenden Daten. Hier hilft es, sich verschiedene Datenarten vorzustellen, mit denen Coroot hantiert. Die Entwickler haben ihre Lösung inzwischen so weit ausgebaut, dass sie als Grundlage für ihre Analysen Telemetriedaten nach dem OpenTelemetry-Standard [7] heranziehen kann. Das umfasst vor allem zwei Arten von Daten, Protokolldateien und Traces, und lässt sich an bestehende Anwendungen auf zwei unterschiedlichen Wegen anflanschen. Entweder kommt das OpenTelemetry-SDK [8] zum Einsatz, das für eine Integration tief auf der API-Ebene einer Applikation sorgt, oder die Anwendung bekommt den OpenTelemetry Collector zur Seite gestellt, der fortan Logs und Traces mitschreibt.

Die Welt von eBPF

Darüber hinaus liest Coroot aus bestehenden Kubernetes-Clustern über deren API Metrikdaten, Logs, Traces und bestehende Überwachungsprofile aus. Darum kümmert sich Coroot-cluster-agent. Das eigentliche Alleinstellungsmerkmal im Hinblick auf das Abgreifen von Daten ist jedoch der Coroot-node-agent, der auf eBPF [9] setzt. Diese Technologie war im Linux-Magazin schon mehrmals Thema [10]. Hält man sich vor Augen, wie faszinierend und leistungsstark sie ist, wundert es doch, dass eBPF heute nicht sehr viel mehr Beliebt- oder zumindest Bekanntheit genießt.

Zur Erinnerung: eBPF ist ein Bestandteil des Netzwerk-Stacks des Linux-Kernels und ermöglicht, bestimmte Programme in einer Art virtuellen Maschine im Innern des Kernels mit vollem Zugriff auf den Netzwerk-Stack zu betreiben. So wie alle Pakete eines Systems durch den Netfilter gehen und sich mithilfe von Nftables manipulieren lassen, fließen sie auch durch die In-Kernel-VMs, die der Admin per eBPF konfiguriert hat. Dabei lässt sich der durchfließende Traffic nach Belieben analysieren und bei Bedarf verändern.

Als vergleichsweise moderne Technik schleppt eBPF keinen Ballast aus der Vergangenheit mit sich herum, was sie obendrein pfeilschnell macht. Auf dem Markt existieren bereits Proof-of-Concept-Projekte, um einen kompletten Paketfilter in eBPF zu implementieren. Der geht dann deutlich flinker ans Werk als der angestammte Netfilter. Da liegt es auf der Hand, dass eBPF das Interesse einer Lösung wie Coroot auf sich zieht.

Betrachtet man Coroot im weiteren Sinne als Monitoring-Werkzeug, steht es praktisch vor derselben Herausforderung wie jedes andere derartige System: Damit es etwas zu überwachen gibt, müssen Laufzeitdaten eines Tools oder einer Anwendung irgendwie ihren Weg zum Monitoring-Werkzeug finden. Im Fachjargon hat sich dafür die Bezeichnung Instrumentation etabliert (Abbildung 1).

Abbildung 1: Observability realisieren Admins verteilter Anwendungen heute oft mit Jaeger. Das setzt aber voraus, dass die Anwendung aktiv Daten an das Observability-Werkzeug ausgibt, weil Tracing sonst unmöglich wäre. Quelle: Jaeger

Bei klassischen Monitoring-Werkzeugen leisten die Checks, die der Administrator für bestimmte Dienste auf einzelnen Systemen hinterlegt, genau das: Sie sammeln die Daten, auf deren Grundlage das Monitoring arbeitet. Das Problem in verteilten Umgebungen und mithin in Containerumgebungen besteht darin, dass sie sehr dynamisch sind und klassische Monitoring-Werkzeuge mit dieser Komplexität kaum zurechtkommen. Obendrein entstehen an so vielen verschiedenen Stellen Metrikdaten, dass es ein mühsames Unterfangen wäre, für jede einzelne dieser Stellen einen Datenabgreifer auszurollen und in das Monitoring zu integrieren.

Gerade moderne Anwendungen, die auf dem Prinzip von Mikrokomponenten basieren, sorgen hier noch einmal für ein ganz neues Level an Komplexität: Neben der Überwachung der Anwendungen selbst entsteht auch das Problem, dass sich einzelne Informationsbrocken auf ihrem Weg durch die Komponenten eines solchen Konstrukts mannigfaltig verändern. Schon die Dokumentation dieser Veränderungen zu Überwachungszwecken ist oft wünschenswert oder sogar notwendig.

Praktisch beschäftigt sich das gesamte OpenTelemetry-Projekt den größten Teil seiner Zeit damit, Schnittstellen für den Austausch von Metrikdaten und Tracing anzubieten, an die externe Werkzeuge andocken können. Das Linux-Magazin hat in diesem Kontext beispielsweise Jaeger [11] bereits ausführlich vorgestellt: Das Werkzeug wertet OpenTelemetry-kompatible Traces aus und macht so nachverfolgbar, wie sich Daten auf ihrem Weg durch eine Mikrokomponenten-Anwendung verändern.

Damit das Prinzip allerdings funktioniert, muss die Anwendung wahlweise mit dem schon erwähnten OpenTelemetry-SDK integriert sein, oder der OpenTelemetry Collector muss die Daten so gut wie möglich von außen abgreifen. In beiden Fällen ist es notwendig, die App um spezifische Unterstützung für das benötigte Monitoring-System zu erweitern.

Überträgt man das Prinzip auf eine Lösung wie Coroot, würde das bedeuten, dass jede Anwendung auf einem beliebigen Kubernetes-Cluster irgendwo auf der Welt um die Existenz von Coroot wissen und es aktiv mit Metriken, Logs und Traces füttern müsste. Das erscheint weder komfortabel noch trivial.

Die Coroot-Entwickler setzen deshalb auf eine andere Strategie: Sie nutzen eBPF, um einen großen Teil der zur Analyse benötigten Daten bereits aus dem unmittelbaren Netzwerkverkehr einer Anwendung zu extrahieren und zu verarbeiten. Dieser Zero-Instrumentation-Ansatz ist aus Admin-Sicht attraktiv: Hat man die Coroot-Integration für einen Cluster einmal ausgerollt, wandern die Daten zur Überwachung automatisch von dort zu Coroot und werden dort analysiert. Es ist anders als in anderen Szenarien nicht mehr nötig, jede einzelne App separat anzubinden. Das gilt – ein wichtiger Punkt – völlig unabhängig davon, wie die Anwendung sich während ihrer Laufzeit verändert.

Startet Kubernetes etwa auf Basis eines Scale-Sets mehr Instanzen desselben Diensts, um höhere Last auszugleichen, deckt der Einsatz von Coroot-node-agent das automatisch ab. Diese Komponente hängt sich auf jedem zum Cluster gehörenden System in eBPF ein und schneidet so die relevanten Daten mit. Was schon in der Theorie gut klingt, funktioniert in der Praxis ganz hervorragend: Kurz nach der Inbetriebnahme in einem Cluster empfängt Coroot bereits umfassend Metriken, Logs und Traces. Es kann also direkt mit der Auswertung der Daten beginnen (Abbildung 2).

Abbildung 2: Die Coroot-UI präsentiert bereits kurz nach der Inbetriebnahme der Lösung erste Einblicke. Einen großen Teil der ausgerollten Ressourcen erkennt es dank Zero Instrumentation automatisch. Quelle: Coroot

Die Möglichkeiten

Die Coroot-Entwickler haben den Leistungsumfang ihrer Lösung in den vergangenen Jahren stark erweitert. War das Hauptverkaufsargument anfangs noch, auf Basis von KI Bedrohungslagen zu erkennen und umfassende, automatisiert erstellte Root-Cause-Analysen (RCA) zu schreiben, liegt der Fokus nun etwas weiter gefasst auf dem gesamten Themenkomplex der Observability. Noch immer spielt die KI-gestützte Erkennung von Angriffen zwar eine große Rolle, mittlerweile beherrscht Coroot aber deutlich mehr Funktionen. Ein paar Beispiele verdeutlichen das schnell.

So haben die Coroot-Entwickler ihr Werkzeug mittlerweile um die Möglichkeit erweitert, Accounts bei den Hyperscalern hinsichtlich ihrer Kosten und Effizienz zu bewerten. Administratoren kennen die Herausforderung: Zwar ist es bei AWS, Azure und GCP spielend leicht, sich virtuelle Infrastruktur zu provisionieren und zu nutzen. Allerdings sieht sich keiner der drei Anbieter als IT-Caritas: Wer beim Deployment nicht mit Argusaugen auf die momentanen Kosten pro Stunde achtet, erlebt am Monatsende möglicherweise eine böse Überraschung. Gibt der Admin ihm die Login-Daten für einen Cloud-Account mit auf den Weg, verbindet sich Coroot automatisch mit der API, liest die geltenden Preise aus und erzeugt so eine Übersicht der real entstehenden Kosten.

Coroot nutzt einmal mehr KI, um eine Art dynamische Analyse des ausgerollten Setups zu erstellen. Es unterbreitet obendrein Vorschläge bezüglich möglicher Optimierungen. Das Mantra der Coroot-Entwickler ist klar: Nur wer einen umfassenden Datenschatz zur Verfügung hat, kann umfassende Analyse betreiben. Genau dabei greift Coroot dem Administrator unter die Arme. Die Cost-Tracking-Funktionen von Coroot beziehen sich allerdings vor allem auf die Managed-Kubernetes-Angebote der Hyperscaler. Wer also EKS, AKS oder GKS nutzt, kann Coroot unter anderem verwenden, um automatisiert aus dort ausgerollten Clustern Metrikdaten zu exportieren und zu analysieren (Abbildung 3).

Abbildung 3: In Kubernetes-Setups bei den Hyperscalern korreliert Coroot automatisch die genutzten Ressourcen und errechnet daraus anfallende Gebühren. Obendrein zeigt es Möglichkeiten an, das Setup sinnvoll zu optimieren. Das spart bares Geld. Quelle: Coroot

Daneben liegt eine weitere Sache auf der Hand: Wer im Rahmen der Bedrohungserkennung automatisiert verschiedenste Daten in seinem Setup erhebt, kann sie auch zu anderen Zwecken nutzen. So weisen die Coroot-Entwickler beispielsweise darauf hin, dass sich der Datenfundus hervorragend eignet, um Service Level Objectives zu überwachen. Das geht hinunter bis auf die einzelne Instanz eines einzelnen Diensts, deren Verfügbarkeit sich mit Coroot dauerhaft erfassen lässt. Dabei hilft die Coroot-GUI, die aus den vorliegenden Daten in Windeseile verständliche Grafiken zeichnet.

Wer möchte, treibt das Spiel auf die Spitze und kann einzelne Ausreißer etwa bei der Antwortzeit eines Diensts mit Coroot erfassen und grafisch darstellen. Dabei hilft, dass sich mittels Coroot für praktisch jede Anwendung in einem Cluster mit wenigen Mausklicks ein komplettes Performance-Profil erstellen lässt. Es enthält eine Darstellung der einzelnen aufgerufenen Funktionen und ihrer jeweiligen Verarbeitungsdauer.

Dennoch steht das Thema Observability absolut nicht im Verdacht, vergnügungssteuerpflichtig zu sein. Mit Coroot gehen aber viele Dinge leicht von der Hand, für die der Admin früher stundenlang Begleitdienste und ganze Observability-Plattformen ausrollen musste – das macht fast schon Spaß. Etliche Zusammenhänge, die den Augen des Admins zuvor vollständig verborgen blieben, lassen sich dank Coroot und dessen Andocken an eBPF überhaupt erst darstellen.

Wer etwa in einem virtuellen Kubernetes-Setup aus etlichen Containern die Kommunikationswege der Anwendungen nachvollziehen möchte, musste sich dazu früher oft stundenlang mit Papier und Stift hinsetzen. Bei Coroot fällt eine solche Kartendarstellung der gesamten Kommunikation in einem Setup quasi als Abfallprodukt der ohnehin stattfindenden Überwachung an (Abbildung 4).

Abbildung 4: Allein auf Grundlage der mitgeschriebenen Daten erzeugt Coroot eine vollständige Matrix der Kommunikation in einem Setup. Dieser Schritt wäre ansonsten nur mit viel Handarbeit zu leisten. Quelle: Coroot

Umfassendes Alerting

Nun ist es freilich so, dass der praktische Nutzen einer Observability-Lösung stark eingeschränkt wäre, könnte sie über drohendes Ungemach und ganz generell ihre Erkenntnisse nicht irgendjemanden informieren. Das Problem lösen die Coroot-Entwickler aber umfassend: Ab Werk lässt Coroot sich nahtlos mit diversen Pager- und Operations-Diensten verbinden, darunter PagerDuty [12] und Opsgenie [13]. So lässt sich dann auch ein Alerting einrichten.

Wer es etwas bodenständiger mag, bindet Coroot unmittelbar an Slack oder Microsoft Teams an und empfängt entsprechende Nachrichten auf dem Standardweg per Instant Messenger. Obendrein steht eine Webhook-Option zur Verfügung: Dann ruft Coroot bei Vorliegen eines definierten Ereignisses einfach eine URL auf, hinter der sich praktisch jede Aktion verbergen kann, darunter der Versand von E-Mails oder SMS.

Alle zuvor beschriebenen Funktionen lassen sich mit dem Alerting übrigens koppeln. Verwendet man Coroot zur Überwachung von SLOs, kann es beim Überschreiten bestimmter Grenzwerte unmittelbar einen Administrator alarmieren, der sich die Situation dann ansieht.

Preise

Coroot selbst ist zwar Open-Source-Software, viele Tracing-Funktionen und insbesondere jene auf Grundlage von KI-Funktionen lassen sich aber nur über die Cloud abrufen. Dazu ist es nötig, einen Account bei Coroot anzulegen, über den die Coroot-Instanz im eigenen Rechenzentrum kommuniziert.

Coroot hält das Preismodell ausgesprochen angenehm: Es gibt die Standard- und die Premium-Edition, die sich vor allem im angebotenen Support voneinander unterscheiden. Die Premium-Edition bietet zudem proaktive Überwachung nach dem RED-Prinzip (“Rate, Error, Duration”), die bei Überschreiten bestimmter Schwellenwerte im Rahmen des SLO-Monitorings (Abbildung 5) alarmiert.

Abbildung 5: Wer seinen Kunden bestimmte Service-Ziele verspricht, sollte auch in der Lage sein, deren Einhaltung zu überwachen. In Coroot lassen sich SLOs abbilden und ihre Einhaltung automatisch prüfen. Quelle: Coroot

In der Standard-Edition fehlt das Feature. Sie schlägt mit 1 US-Dollar pro Monat pro überwachtem CPU-Kern zu Buche, wobei Coroot Mengenrabatt bietet. Die Preise für die Premium-Edition listet der Hersteller öffentlich nicht – gut möglich, dass sie der individuellen Vereinbarung mit dem jeweiligen Kunden unterliegen.

Fazit

Coroot fühlt sich in gewisser Hinsicht an wie ein Blick in die Zukunft der Observability in verteilten Setups. Wo früher träge Lösungen wie Nagios & Co. für die Überwachung zuständig waren, sprengen die technischen Anforderungen der Gegenwart deren Fähigkeiten längst und bringen neue Ansätze wie Coroot zutage.

Das Tool zeichnet sich in mehrerlei Hinsicht aus: Es braucht keine umfassende Instrumentalisierung, die Entwickler um ihre App herum legen müssen, um überhaupt zu funktionieren. Stattdessen sammelt es die relevanten Daten mittels eBPF selbst ein. Coroot beherrscht mittlerweile nicht nur Analyse auf Basis von Profiling einzelner Komponenten, sondern kann auch Metrikdaten aus Prometheus auswerten und Logdateien analysieren. All diese Quellen nutzt es, um tiefgreifende Einblicke in den momentanen Zustand eines containerbasierten Setups zu geben. Zusatzfunktionen wie eine automatisierte Erkennung von Bedrohungen, die umfassende Analyse der Qualität eines erbrachten Diensts und ein umfassendes Kosten-Monitoring für cloudbasierte Dienste machen die Sache rund.

Anders als bei anderen Lösungen müssen Unternehmen nicht unmittelbar für eine Insolvenz vorsorgen, falls sie Coroot nutzen möchten, denn die aufgerufenen Preise halten sich im Rahmen. Lediglich die Tatsache, dass ein großer Teil der Coroot-Funktionen nur in gehosteter Form in der Cloud verfügbar ist, trübt die Freude über die Lösung. (jcb/csi/jlu)