Technischer Support
Dokumentation
Anmeldung
Kontakt
Gehen Sie direkt zu einer KI-Zusammenfassung dieses Blogbeitrags 
Wichtigste Erkenntnisse
- Abhängigkeiten vergrößern die Risikofläche im Zusammenhang mit dem Ende des Lebenszyklus (EOL), da das Go-Backend von Grafana, das TypeScript/React-Frontend und die mitgelieferten Bibliotheken zusätzliche Sicherheitslücken mit sich bringen, für die keine Patches mehr bereitgestellt werden, sobald Grafana das Ende des Lebenszyklus erreicht.
- Überstürzte Upgrades sind kostspielig, da größere Grafana-Upgrades zu Fehlfunktionen bei Dashboards, Plugins, Datenquellen und Bereitstellungsworkflows führen können, was ungeplante Migrationen komplex und kostspielig macht.
- Das Ende des Supports für Grafana bedeutet nicht das Ende der Sicherheit, denn der „Endless Lifecycle Support“ (ELS) von TuxCare stellt fortlaufend Patches für nicht mehr unterstützte Grafana-Versionen über den gesamten Abhängigkeitsbaum hinweg bereit – so können Sie das Upgrade ganz nach Ihrem eigenen Zeitplan durchführen.
Grafana bildet die Grundlage für die Dashboards, Warnmeldungen und Observability-Workflows, die weltweit in Unternehmen weit verbreitet sind. Es ist die Schnittstelle, über die Ingenieure und SREs Systeme in Echtzeit überwachen, die Plattform, auf der Geschäftskennzahlen in verwertbare Erkenntnisse umgewandelt werden, und in vielen Umgebungen der erste Ort, an den man sich wendet, wenn etwas schiefgeht.
Angesichts dieser zentralen Rolle übersieht man leicht eine unangenehme Tatsache: Grafana-Versionen haben einen festgelegten Supportzeitraum, und sobald dieser abgelaufen ist, werden keine Sicherheitspatches mehr bereitgestellt. Wenn Sie eine Grafana-Version nutzen, deren Support abgelaufen ist, müssen Sie sich ab diesem Zeitpunkt selbst um alle bekannt gewordenen CVEs kümmern, ohne Unterstützung durch den Hersteller.
In diesem Beitrag wird erläutert, wie der Release-Zyklus von Grafana in der Praxis funktioniert, was das Ende des Supports in Bezug auf Sicherheit und Compliance konkret bedeutet und welche Optionen Unternehmen zur Verfügung stehen, die noch nicht bereit sind, gemäß dem Zeitplan von Grafana ein Upgrade durchzuführen.
Wie sieht der Produktlebenszyklus von Grafana aus?
Grafana folgt einem monatlichen Release-Rhythmus, den man kennen sollte, bevor man über das Ende der Lebensdauer (EOL) spricht. Neue Nebenversionen – also solche, die neue Funktionen enthalten – werden in geraden Monaten veröffentlicht: Februar, April, Juni und so weiter. Patch-Releases, die Fehlerbehebungen und Sicherheitsupdates für unterstützte Versionen enthalten, erscheinen in ungeraden Monaten. Sicherheitslücken mit hohem Schweregrad führen zudem zu Ad-hoc-Releases, die nicht auf den regulären Zeitplan warten.
Grafana verwendet semantische Versionierung mit der Struktur MAJOR.MINOR.PATCH:
- Hauptversion (z. B. 11.x): Erhält neue Funktionen durch neue Nebenversionen. Nur die aktuelle Hauptversion wird „vollständig unterstützt“.
- Nebenversion (z. B. 11.3): Erhält bis zum EOL-Datum Patch-Releases, Fehlerbehebungen und Sicherheitspatches.
- Patch-Version (z. B. 11.3.2): Nur Sicherheits- und Fehlerbehebungen.
Die Regeln für die Supportdauer sind klar definiert. Für jede Minor-Version werden neun Monate lang nach dem Veröffentlichungsdatum Sicherheits- und Fehlerbehebungspatches bereitgestellt. Die letzte Minor-Version einer Major-Version erhält einen erweiterten Support von fünfzehn Monaten nach dem Veröffentlichungsdatum, wodurch ein längerer Zeitraum abgedeckt wird, um Unternehmen zu unterstützen, die nicht bei jeder Minor-Version ein Upgrade durchführen. Versionen, deren Supportzeitraum abgelaufen ist, fallen in die Kategorie „Nicht unterstützt“: keine Updates, keine Patches, keine Fehlerbehebungen.
| Grafana-Version | Status | Anmerkungen |
| 12.x (aktuellste Version) | Umfassende Unterstützung | Aktive Weiterentwicklung, Fehlerbehebungen, Sicherheitspatches und neue Funktionen |
| 11.x (letzte Nebenversion) | Eingeschränkter Support | Nur kritische Fehlerbehebungen und Sicherheitspatches (keine neuen Funktionen) |
| 11.x (nicht die letzte Nebenversion) | Nicht unterstützt | Keine Garantie für Fehlerbehebungen oder Updates |
| 10.x und früher | Eingeschränkte / vorübergehende Unterstützung | Erhält möglicherweise für einen kurzen Zeitraum wichtige Sicherheitsupdates (langfristig nicht garantiert) |
| 9.x und früher | Ende des Lebens | Keine Updates, keine Patches, kein Support |
Das Fazit: Wenn Sie nicht im Blick behalten, welche Minor-Version Sie gerade verwenden und wann deren neunmonatiger Supportzeitraum abläuft, geraten Sie leicht in einen nicht mehr unterstützten Bereich, ohne es zu merken.
Was bedeutet „Grafana EOL“?
Keine Sicherheitspatches mehr
Wenn eine Grafana-Version das Ende ihres Lebenszyklus (EOL) erreicht, stellt das Upstream-Projekt die Veröffentlichung von Sicherheitsupdates für diese Version ein. Dies gilt auch dann, wenn CVEs mit hohem oder kritischem Schweregrad bekannt werden. Die von Grafana Labs veröffentlichten Patches gelten nur für unterstützte Versionen; Ihre nicht mehr unterstützte Version erhält diese Patches einfach nicht.
Dies ist das entscheidende Sicherheitsproblem beim Einsatz von Software, deren Lebenszyklus abgelaufen ist: Es werden ständig neue Sicherheitslücken entdeckt und veröffentlicht, doch keine der entsprechenden Korrekturen wird für Ihre Version bereitgestellt. Ihr Sicherheitsrisiko steigt mit jeder neuen CVE, die bekannt wird.
Sicherheits- und Compliance-Risiken nach Ablauf der Lebensdauer
Die Auswirkungen auf die Compliance liegen auf der Hand. PCI DSS (Anforderung 6.3.3) schreibt vor, dass kritische und schwerwiegende Sicherheitslücken (CVSS-Score 7,0 und höher) innerhalb eines Monats nach Veröffentlichung des Patches für betroffene Systeme behoben werden müssen. HIPAA, FedRAMP und SOC 2 enthalten ähnliche Anforderungen für die von ihnen abgedeckten Umgebungen. Der Betrieb einer EOL-Version von Grafana in einer regulierten Umgebung bedeutet im Grunde, dass Sie eine Infrastruktur betreiben, die Sie nicht innerhalb des von den Prüfern geforderten Zeitrahmens patchen können, und das führt zu einer Compliance-Lücke, die sich nur schwer rechtfertigen lässt, unabhängig von kompensierenden Kontrollmaßnahmen.
Da Grafana im Zentrum von Observability-Stacks steht, hat es häufig Zugriff auf sensible Datenströme, Anmeldedaten für Dutzende von Datenquellen und Konfigurationen von Produktionssystemen. Diese Kombination aus Zugriffsmöglichkeiten und Transparenz macht es zu einem besonders attraktiven Ziel.
Grafanas CVE-Verlauf
Grafanas CVE-Eintrag veranschaulicht, wie sich Sicherheitslücken bei nicht mehr unterstützten Produkten in der Praxis auswirken.
CVE-2024-9264 (CVSS 9,9 – Kritisch): Hierbei handelte es sich um eine Sicherheitslücke hinsichtlich Befehlsinjektion und lokaler Dateieinbindung, die in Grafana 11 durch die experimentelle Funktion „SQL Expressions“ eingeführt wurde. Die Funktion ermöglichte die Nachbearbeitung der Abfrageergebnisse von Datenquellen mithilfe von SQL-Abfragen, die über die DuckDB-CLI ausgeführt wurden. Da die Abfragen nicht ordnungsgemäß bereinigt wurden, konnte ein Angreifer Befehle einschleusen und lokale Dateien auslesen. Die Schwachstelle wurde als Remote-Code-Ausführung eingestuft. Grafana veröffentlichte Notfall-Patches für unterstützte 11.x-Versionen, was bedeutet, dass Organisationen, die eine nicht mehr unterstützte Grafana-11-Nebenversion einsetzten, keinen Patch erhielten.
CVE-2021-43798 (CVSS 7.5 – High): This is one of the most widely discussed vulnerabilities in Grafana’s history. An unauthenticated attacker could traverse directories via the /public/plugins/<plugin-id>/ endpoint, bypassing path restrictions using standard ../ sequences. Because every Grafana installation ships with pre-installed plugins, there was no prerequisite that any instance on a vulnerable version was exposed. The vulnerability allowed attackers to read Grafana’s SQLite database file (which contains auth tokens and data source credentials), config files with plaintext passwords, OAuth credentials, and LDAP credentials. It was disclosed as a zero-day after proof-of-concept code was published publicly before the patch was ready, and it is listed in CISA’s Known Exploited Vulnerabilities catalog. Affected versions: 8.0.0-beta1 through 8.3.0.
Beide Sicherheitslücken wurden in den unterstützten Versionen behoben. Für keine der beiden hätte es Patches für nicht mehr unterstützte Nebenversionen gegeben.
Das Problem des Abhängigkeitsbaums
Grafana ist keine einfache Anwendung mit nur einer ausführbaren Datei – es handelt sich um eine Full-Stack-Observability-Plattform mit einem Go-Backend und einem TypeScript/React-Frontend, die jeweils umfangreiche Abhängigkeitsstrukturen aufweisen.
Das Backend nutzt Go-Module für die HTTP-Verarbeitung, Kryptografie, Datenbankschnittstellen, Alarmierungslogik und vieles mehr. Das Frontend basiert auf React, Redux für das State-Management, D3 für die Visualisierung, Emotion für das Styling, Recharts sowie einer umfangreichen Sammlung von Zusatzpaketen. Die package.json listet allein Dutzende direkter Frontend-Abhängigkeiten auf, von denen jede ihren eigenen transitiven Abhängigkeitsgraphen mitbringt.
Wenn Grafana das Ende des Supports erreicht, werden auch diese Abhängigkeiten nicht mehr gepatcht. Eine kritische Schwachstelle in einem Go-Modul, das vom Grafana-Backend verwendet wird, oder ein XSS in einer Frontend-Diagrammbibliothek wird in Ihrer nicht mehr unterstützten Version genauso sicher unberücksichtigt bleiben wie eine Schwachstelle in Grafana selbst. Das Upstream-Projekt wird keine Korrekturen dafür zurückportieren. Das EOL-Risiko betrifft nicht nur Grafana, sondern alles, wovon Grafana abhängt.
Möglichkeiten für Sicherheit und die Einhaltung von Vorschriften
Aktualisieren Sie auf eine unterstützte Grafana-Version
Ein Upgrade auf eine aktuell unterstützte Version ist immer eine Option und für viele Unternehmen letztendlich der richtige Weg. In den Upgrade-Anleitungen von Grafana werden kompatibilitätsbrechende Änderungen zwischen den Versionen dokumentiert, und Upgrades auf eine niedrigere Versionsnummer innerhalb derselben Hauptversion sind in der Regel mit einem geringeren Risiko verbunden als Upgrades auf eine höhere Hauptversion.
Die Komplexität hängt stark von Ihrer Umgebung ab. Unternehmen, die Dashboards aus Community-Plugins, komplexe Bereitstellungskonfigurationen oder Grafana-Versionen nutzen, die mehrere Hauptversionen hinterherhinken, stehen vor einer aufwändigeren Migration, die in der Regel Tests in einer Staging-Umgebung, die Überprüfung der Dashboard-Darstellung, die erneute Überprüfung der Datenquellenintegrationen sowie die Abstimmung zwischen den Teams erfordert, die für die Transparenz in der Produktion auf Grafana angewiesen sind.
Wechsel zu einer alternativen Observability-Plattform
Der Wechsel zu einer anderen Überwachungs- und Visualisierungsplattform – wie Kibana, Datadog, Grafana Cloud oder anderen gehosteten Alternativen – ist eine Option, die manche Unternehmen in Betracht ziehen, wenn sie ihren Observability-Stack umfassender neu bewerten. Dies ist eine Entscheidung mit langfristiger Perspektive: Plattformmigrationen dieser Art erfordern die Neukonfiguration von Datenquellen, die Neuerstellung von Dashboards, die Neufassung von Alarmregeln sowie einen erheblichen Aufwand für die Umschulung der Mitarbeiter.
Für die meisten Unternehmen, die lediglich die Sicherheitslücke in einer bestimmten Grafana-Version schließen müssen, ist dies keine praktikable kurzfristige Lösung.
Der empfohlene Weg: TuxCare – Lebenslanger Support für Grafana
Der „Endless Lifecycle Support“ (ELS) von TuxCare für Grafana ist die Lösung, die Sicherheits- und Compliance-Probleme direkt angeht, ohne dass ein sofortiges Upgrade erforderlich ist. TuxCare stellt fortlaufend Sicherheitspatches für Grafana-Versionen bereit, deren Support ausgelaufen ist – wobei sowohl die direkten als auch die transitiven Abhängigkeiten von Grafana ohne zusätzliche Kosten abgedeckt werden –, sodass Unternehmen eine vertretbare Sicherheitslage aufrechterhalten können, während sie das von ihnen gewünschte Upgrade planen.
In der Praxis: TuxCare überwacht die NVD, Sicherheitshinweise von Anbietern und GitHub-Sicherheitsfeeds auf Schwachstellen, die Grafana und seine Abhängigkeiten betreffen, und stellt anschließend über SLA-gestützte Prozesse Backports und Korrekturen für EOL-Versionen bereit. Sie können weiterhin die Version nutzen, die Sie bereits einsetzen, ohne die Sicherheits- und Compliance-Risiken, die normalerweise mit dem Ende des Supports einhergehen.
Die Risiken einer überstürzten Grafana-Aktualisierung
Wenn das Ende der Lebensdauer (EOL) naht, wird häufig der Fehler begangen, das Upgrade als eine Frist zu betrachten, auf die man unter Zeitdruck reagieren muss, anstatt es als ein Risiko zu sehen, das bewusst gesteuert werden muss.
Was ein Grafana-Upgrade wirklich beinhaltet
Ein Hauptversions-Upgrade von Grafana von 9.x auf 11.x ist beispielsweise kein einfacher Austausch. Es erfordert eine Anpassung des Codes aller Provisioning-Skripte, Infrastructure-as-Code-Konfigurationen oder API-Integrationen, die auf veralteten oder geänderten Endpunkten basieren. Dies erfordert eine Kompatibilitätsprüfung für jedes Plugin, das Ihre Dashboards verwenden, da Community-Plugins unabhängig versioniert sind und möglicherweise nicht für neuere Grafana-Versionen aktualisiert wurden. Dies erfordert Anpassung der Toolchain für alle CI/CD-Pipelines, die Grafana-Konfigurationen erstellen, testen oder bereitstellen. Und es umfasst Testaufwand: Dashboards müssen visuell validiert, Warnmeldungen erneut bestätigt und Datenquellenabfragen überprüft werden, um konsistente Ergebnisse zu erzielen.
Was passiert, wenn das Upgrade überstürzt durchgeführt wird?
Wenn Upgrades aufgrund einer EOL-Frist erzwungen werden, ohne dass die dafür erforderliche Planung vorliegt, folgen die Ergebnisse einem vorhersehbaren Muster. Die Support-Auslastung steigt sprunghaft an, da Dashboards auf unerwartete Weise ausfallen und die Bereitschaftstechniker ihre Zeit damit verbringen, Fehler bei der Visualisierung statt Systemausfälle zu beheben. Die Instabilität des Systems äußert sich während der Umstellung in Störungen des Alarmsystems, Verbindungsproblemen bei Datenquellen oder Inkonsistenzen bei der Darstellung. Technische Schulden häufen sich an, da Teams ordnungsgemäße Tests umgehen, um die Frist einzuhalten, wodurch Arbeit entsteht, die später erneut bearbeitet werden muss. Und ungeplante Kosten eskalieren – in Form von Entwicklungszeit, potenziellen Serviceunterbrechungen und dem betrieblichen Aufwand für die Verwaltung einer Migration, deren Umfang nicht richtig abgeschätzt wurde.
Die Unternehmen, die den Wechsel zu einer neuen Grafana-Version gut bewältigen, sind diejenigen, die ihn als geplante Migration und nicht als Notfallmaßnahme betrachten.
Die einfache Lösung: TuxCare ELS für Grafana
TuxCare hat über ein Jahrzehnt damit verbracht, die Automatisierung, das Fachwissen und die Prozesse aufzubauen, die es dem Unternehmen ermöglichen, Sicherheitspatches für Software, deren Support ausgelaufen ist, in großem Umfang bereitzustellen. Mit mehr als 220.000 Patches, die für das gesamte unterstützte Produktportfolio bereitgestellt wurden, hat TuxCare einen Patch-Workflow entwickelt, der sowohl schnell als auch zuverlässig ist.
Speziell für Grafana bietet das ELS von TuxCare folgende Vorteile:
- Schnelle, SLA-gestützte Sicherheitspatches: TuxCare überwacht kontinuierlich die Veröffentlichung von Sicherheitslücken und liefert Patches für hochgradige und kritische CVEs (CVSS 7.0+) gemäß festgelegten SLAs, sodass Ihre Grafana-Bereitstellung die von PCI DSS, HIPAA und anderen Compliance-Rahmenwerken geforderten Fristen einhält.
- Vollständige Abdeckung des Abhängigkeitsbaums: TuxCare deckt sowohl die direkten als auch die transitiven Abhängigkeiten in Ihrer Grafana-Bereitstellung ohne zusätzliche Kosten ab. Das bedeutet, dass die Go-Module und Frontend-Pakete, von denen Grafana abhängt, nicht zu einem versteckten EOL-Risiko werden.
- Nahtlose Integration in Ihre bestehenden Arbeitsabläufe: Ganz gleich, ob Sie Grafana-Updates derzeit über Paketmanager, Docker-Images oder Ihre bestehenden CI/CD-Pipelines beziehen – Sie können Ihre Update-Quelle mit minimalen Änderungen an Ihrem bestehenden Workflow auf das sichere Repository von TuxCare verweisen. Ihre aktuelle Toolchain bleibt davon unberührt.
- Signierte, manipulationssichere Pakete: Jeder von TuxCare bereitgestellte Patch wird vor der Bereitstellung in Ihrem Repository umfassend auf Integrität, Funktionalität und Regression getestet, und die Pakete sind kryptografisch signiert, sodass Sie genau wissen, was Sie bereitstellen.
- Kompetenter Support rund um die Uhr: Das Sicherheitsteam von TuxCare steht rund um die Uhr für die Einstufung von Sicherheitslücken, Patch-Anfragen und Fehlerbehebung zur Verfügung, sodass Sie bei Sicherheitsvorfällen im Zusammenhang mit dem Ende der Lebensdauer (EOL) stets Unterstützung erhalten.
Um zu sehen, welche Grafana-CVE-Probleme bereits behoben wurden, unterhält TuxCare einen Live-CVE-Tracker. Weitere Informationen zum Patch-Prozess von TuxCare und dazu, wie Patches vor der Bereitstellung validiert werden, finden Sie im technischen Whitepaper.
Lassen Sie nicht zu, dass das EOL von Grafana Ihre Überwachungsinfrastruktur gefährdet
Das Ende des Lebenszyklus von Grafana bedeutet nicht, dass Ihre Observability-Plattform sofort gefährdet ist. Es bedeutet jedoch, dass der Sicherheitsschutz, auf den sich Ihre Infrastruktur bisher verlassen hat, wegfällt, und diese Lücke muss bewusst gemanagt und darf nicht ignoriert werden.
Die Teams, die damit gut umgehen, betrachten das Ende der Lebensdauer von Grafana als ein Sicherheitsproblem, das es zu bewältigen gilt, und nicht als einen Countdown, auf den man reagieren muss. Sie können ein wohlüberlegtes Upgrade auf eine aktuelle Grafana-Version planen, wenn dies wirklich mit den Kapazitäten Ihres Teams, der Bereitschaft Ihres Plugin-Ökosystems und dem Release-Kalender Ihres Unternehmens vereinbar ist. Sie können den gesamten Migrationsumfang bewerten, bevor Sie sich auf einen Zeitplan festlegen. Oder Sie können TuxCare ELS nutzen, um die Sicherheit und Compliance-Abdeckung aufrechtzuerhalten, während Sie diese Entscheidungen nach Ihren eigenen Vorstellungen treffen – und nicht unter Druck.
ELS für Grafana ist keine Notlösung. Es ist die Lösung, die Ihre Überwachungsinfrastruktur schützt, Ihre Compliance-Anforderungen erfüllt und es Ihren Entwicklerteams ermöglicht, sich auf die eigentliche Entwicklung zu konzentrieren – statt auf Notfallmigrationen.
Wenn das EOL von Grafana derzeit auf Ihrem Sicherheitsradar steht, besuchen Sie den Endless Lifecycle Support für Grafana von TuxCare und erfahren Sie, wie erweiterter Support Ihre Observability-Infrastruktur so lange schützen kann, wie Sie es benötigen.
