Die Cache-Hitrate (CHR) als Sicherheitskennzahl

Die Cache-Hitrate (CHR) ist eine wichtige Kennzahl für jedes System, das einen Cache enthält – häufig sogar die einzige Metrik. Sie wird berechnet, indem man den Cache auf bestimmte Inhalte überprüft und die Anzahl der Cache Hits durch die Gesamtzahl der geprüften Cache Hits und Cache Misses dividiert. Wenn das Ergebnis jeder Prüfung entweder ein Hit (Inhalt gefunden) oder ein Miss (Inhalt nicht gefunden) sein kann, lautet die Formel wie folgt:

In der Vergangenheit wurde die CHR als Performance-Metrik verstanden, der Sie unbedingt Beachtung schenken sollten, denn je mehr Inhalte Sie cachen, desto mehr Geld sparen Sie und desto schneller ist Ihre Website. Eine höhere Cache-Hitrate kann folgende Vorteilen mit sich bringen:

Geringerer Hardwarebedarf für Ihren Origin-Server
Weniger Komplexität bei der Origin-Architektur
Drastische Einsparungen bei den Egress–Kosten
Weniger Latenz durch Inhaltsauslieferung aus dem Cache

Weniger Beachtung genießen oft die Sicherheitsvorteile, die neben einer besseren Performance mit einer Verbesserung der CHR einhergehen. So berichtete beispielsweise ein Befragter in einer kürzlich durchgeführten Studie* von einem 40-prozentigen Rückgang der Sicherheitsvorfälle allein durch die Umstellung auf das CDN von Fastly. (Vollständige Studie lesen.) Es ist also höchste Zeit, sich darüber Gedanken zu machen, warum Sie Ihre CHR auch als Sicherheitsmetrik verstehen sollten.

Die Cache-Hitrate als Sicherheitskennzahl

Bevor wir genauer auf die potenziellen Vorteile einer besseren CHR bei der Risikominderung eingehen, wollen wir uns aber zunächst mit den Risikofaktoren im Security-Bereich befassen.

Größere Angriffsfläche

Je größer die Anzahl Ihrer Server, desto mehr potenzielle Angriffspunkte müssen Sie verwalten. Selbst wenn Sie in der privilegierten Lage sind, horizontal skalieren zu können, um Ihren wachsenden Kapazitätsanforderungen gerecht zu werden, und jeder Ihrer Server gemäß Ihren Best Practices abgesichert ist, steigt mit der Wahrscheinlichkeit einer Fehlkonfiguration oder Schwachstelle auch die Angriffswahrscheinlichkeit.

Komplexere Anwendungen

Wenn Sie diesen Luxus der horizontalen Skalierbarkeit nicht genießen und Ihr System dadurch immer komplexer wird, haben Sie gleich zweierlei Probleme: Ein komplexeres System lässt sich schwieriger verwalten und absichern, da es eine größere Zahl an möglichen Angriffspunkten gibt.

Die Komplexität einer Anwendung erhöht sich außerdem mit einer höheren Auslastung Ihres Origin-Servers. Bei einem Anstieg Ihres Traffic-Volumens besteht zum Beispiel möglicherweise die Notwendigkeit, Loadbalancing für mehrere Server zu betreiben oder Replika Ihrer primären Datenbank einzuführen. Wenn Sie das Traffic-Volumen mit Ihrem Edge CDN bewältigen können, lässt sich Ihre Gesamtkapazität unabhängiger von der Kapazität Ihres Origin-Servers skalieren, sodass Sie den Origin Footprint Ihrer Anwendungen einfacher und sicherer gestalten können.

Komplexere Bereitstellungsmodelle

Komplexere Bereitstellungsmodelle stellen ein weiteres Risiko für Ihre Architektur dar. Wir definieren komplexere Bereitstellungsmodelle als Modelle, die sich beispielsweise auf mehrere Regionen oder Verfügbarkeitszonen erstrecken oder auf Multi- oder Hybrid-Cloud-Architekturen basieren. Aber auch Modellformen, bei denen die Services großer Cloud-Anbieter, wie Identitäts- und Zugriffsmanagement (IAM) oder Datenbank- und Netzwerkangebote, genutzt werden, zählen dazu. Wenn Sie die Komplexität durch das Hinzufügen bestimmter Regionen oder Zonen erhöhen oder vermehrt Cloud-Anbietertools verwenden, verlagern Sie einen Großteil Ihrer Sicherheit auf diese Tools und Anbieter. Da zwischen diesen Tools und Ihren Origin-Systemen sowie unter den verschiedenen Tools mehr Hindernisse bestehen, erhöht sich Ihr Risiko für Konfigurationsprobleme.

Auch wenn jedes dieser Elemente für sich genommen einen erheblichen Beitrag zur Sicherheit leistet, bringen die Schnittstellen zwischen diesen Elementen in Ihrer Programmlogik immer ein gewisses Risiko mit sich. Sie müssen nicht gleich alles schwarzsehen, aber wenn Sie sich vor den Risiken in Ihrem System schützen wollen, ist es wichtig zu wissen, wo diese angesiedelt sind und wie Sie sie mindern können.

Erhöhte Wahrscheinlichkeit für menschliche Fehler

Neben Schwachstellen in den Systemen besteht auch das Risiko für menschliches Versagen. Mit zunehmender Komplexität steigt auch die Fehlergefahr, ganz gleich, ob es sich dabei um die Architektur, den Umfang der zu verwaltenden und zu wartenden Hardware oder um die Verwaltung zusätzlicher Abläufe handelt. Je undurchsichtiger ein System, desto schwieriger ist es, Fehler zu erkennen, zu beheben oder das Risiko von durch Menschen verursachten Fehlern zu verringern. Jeder Lösungsansatz, bei dem Sie intensiver über das Problem nachdenken müssen, stellt ein Risiko dar. Ein tropfender Wasserhahn lässt sich ja schließlich auch nicht reparieren, indem Sie neue Rohre verlegen.

Je höher also die Komplexität, desto höher auch das Risiko für menschliche Fehler. Der Risikofaktor besteht schon alleine dann, wenn alles reibungslos läuft. Wie katastrophal die Lage werden kann, wenn tatsächlich einmal etwas schiefgeht und es Ihnen nicht gelingt, die Ursache des Problems zu ermitteln, brauchen wir wohl kaum betonen.

Ausfälle (sind ein Sicherheitsrisiko)

Ausfälle stellen in vielerlei Hinsicht ein Sicherheitsrisiko dar. Zunächst einmal haben es DDoS-Angriffe auf Ihre Sicherheit abgesehen, und ein fehlender DDoS-Schutz ist als Sicherheitsproblem auszulegen. Außerdem steigt jedes Mal, wenn normale Abläufe unterbrochen werden, das Risiko einer Sicherheitsverletzung, da Sie alternative Methoden und Prozesse verwenden, die weniger gut abgesichert sind oder bei denen Ihr Team in Hektik gerät. So erhöht sich die Anfälligkeit für Angriffe, die unter normalen Umständen abgefangen würden. Drittens bedeutet jede Minute, die ein SecOps-Team an Stelle eines automatisierten Tools mit der Abwehr aktiver DDoS-Angriffe verbringt, weniger Zeit für die proaktive Umsetzung von Unternehmenszielen.

https://www.fastly.com/de/products/ddos-mitigation

Aber wie genau trägt die CHR zur Minderung dieser Sicherheitsrisiken bei?

Werfen wir einen Blick auf die Vorteile einer höheren CHR:

Kleinere Angriffsfläche dank geringerem Hardwarebedarf
Weniger Komplexität von Anwendung und Architektur
Geringerer Verwaltungs- und Wartungsaufwand bei der Origin-Infrastruktur
Auslagerung von Origin-Traffic auf eine äußerst widerstandsfähige, automatisierte und sichere Edge-Plattform

Wie bereits besprochen ergibt sich ein erhöhtes Risiko durch zusätzlichen Aufwand bei der Hardwareverwaltung, erhöhte Komplexität bei Anwendungen, Architekturen und der Bereitstellung, den Einsatz undurchsichtiger Systeme und Ausfallzeiten. Eine höhere CHR ist ein Indikator dafür, dass der Umfang an benötigter Hardware und die Komplexität Ihrer Anwendungen, Architekturen und Bereitstellung erfolgreich reduziert wurden, und zwar indem Sie Systeme einsetzen, die übersichtlicher sind und dank eines robusten und reaktionsschnellen CDN-Partners eine höhere Verfügbarkeit und Zuverlässigkeit bieten.

Die CHR ist kein direkter Indikator für die Sicherheit, aber die Verbesserungen, die Sie bei Ihrer CHR erzielen, sind ein Beleg für Ihre erfolgreiche Umsetzung von Sicherheitsmaßnahmen. Für verschiedene Arten von Anwendungen gibt es unterschiedliche Obergrenzen für die CHR. In manchen Fällen ist es schwierig, 80 % oder 90 % zu überschreiten. Viele Fastly Kunden erreichen allerdings 95 % oder mehr. Dies wirkt sich sowohl positiv auf die Sicherheit als auch auf die Performance oder die Kosten aus.

Nachdem wir inzwischen die grundlegenden Zusammenhänge zwischen der CHR und Ihrer Sicherheit kennen, wollen wir uns nun näher mit der Cache-Hitrate und möglichen Maßnahmen zu ihrer Verbesserung befassen.

Die Cache-Hitrate im Fokus

Cache Hits und Cache Misses bewegen sich in der Regel im Bereich zwischen 0 und 1,0. Da sie oft als Prozentwert angegeben werden, sehen Sie unter Umständen auch Werte zwischen 0 % und 100 %. Eine CHR von 0 % bedeutet ausschließlich Cache Misses, also dass sämtliche Inhalte entweder vom Origin-Server abgerufen oder on demand generiert werden müssen. Eine CHR von 100 % bedeutet hingegen, dass alle Inhalte direkt aus dem Cache bedient werden.

Vorgänge, die bei einem Cache Miss ausgeführt werden, sind in der Regel mit höheren Kosten (für Bandbreite, CPU oder beides) verbunden, sodass ein höherer CHR-Wert in der Regel auf eine bessere Performance des Systems hinweist. Im Steady State hat jede Anwendung – abhängig von der Gültigkeitsdauer und den Zugriffspatterns der Inhalte – ihre eigene Cache-Hitrate. So können beispielsweise Inhalte, die nur selten abgerufen werden, vor Ablauf ihrer Gültigkeit gelöscht werden, um Platz für andere Inhalte zu schaffen. Im Allgemeinen gilt aber: Wenn Sie Ihre CHR so hoch wie möglich halten, kommt es weniger häufig zu unerwünschten Verzögerungen.

Hier ein Beispiel: Die Cache-Hitrate im Steady State

Um diese Ansicht zu untermauern, sehen wir uns einmal an, was passiert, wenn sich die Cache-Hitrate ändert. In dieser ersten Serie von Beispielen gehen wir davon aus, dass die Rate der Cache-Vorgänge (Hits und Misses zusammengenommen) in etwa gleich bleibt. Ihre Anwendung befindet sich im Steady State und es gibt keine besonderen Vorkommnisse.

Wenn Ihre CHR im Steady State aufgrund der äußeren Umstände sinkt, liegt das daran, dass einige Hits zu Misses geworden sind. Nehmen wir einmal an, Ihre Anwendung verzeichnet jede Sekunde 50 Hits und 50 Misses.

In diesem Fall beträgt Ihre Cache-Hitrate 50 %. Werfen wir nun einen Blick auf die Auswirkungen einer reduzierten Cache-Hitrate: Wenn die Hälfte der Hits zu Misses werden (25 Hits und 75 Misses), ergibt sich eine CHR von 0,25:

Die Auswirkungen einer niedrigeren Cache-Hitrate lassen sich wie folgt beschreiben:

Zunächst wird festgestellt, dass die Anzahl der Cache Misses um 50 % gestiegen ist. Dies bedeutet, dass Ihr Origin-Server 50 % mehr Anfragen für Inhalte erhält, da diese Inhalte nicht im Cache gefunden werden konnten. Gleichzeitig steigt der Hardwarebedarf Ihres Origin-Servers um 50 %.

Aber was passiert im umgekehrten Fall?

Wenn die Hälfte der ursprünglichen Misses zu Hits werden, beträgt Ihre Cache-Hitrate 75 %. So muss Ihr Origin-Server nur noch halb so viele Anfragen bedienen und der Hardwarebedarf sinkt auf 50 %. Auch hinsichtlich Softwarearchitektur kann dies zu Vereinfachungen führen oder dazu, dass für den Origin-Server weniger Verfügbarkeitszonen eingerichtet werden müssen, wodurch sich die Angriffsfläche für Ihre Anwendung verringert.

Die Cache-Hitrate als Schutzmechanismus für Ihren Origin-Server

Die Cache-Hitrate lässt sich auch als Maß für die Qualität des Schutzes Ihrer Origin-Server betrachten. Bei gleicher Anzahl an Anfragen bedeutet eine höhere Cache-Hitrate, dass weniger Traffic Ihre Infrastruktur erreicht. Wenn wir von Origin-Schutz sprechen, meinen wir in der Regel den Schutz vor Traffic-Spitzen, nicht vor Angreifern. Dieselben Vorteile gelten aber auch für die Sicherheit.

Wenn Anfragen von Fastly und nicht von Ihrer eigenen Infrastruktur bedient werden, beschränken Sie die Angriffsfläche auf unsere Plattform, die widerstandsfähiger ist und ständig aktualisiert wird, um größtmögliche Sicherheit zu gewährleisten.

Niedrigere Cache-Hitrate

Bei einer niedrigeren Cache-Hitrate wird ein größerer Teil Ihres Traffics direkt vom Origin-Server ausgeliefert. Dies bedeutet wiederum, dass Sie bei einem Angriff oder ungewöhnlichen Traffic-Spitzen entsprechend schlechter geschützt sind. Das Ergebnis: Lückenhafte Verfügbarkeit und mögliche Sicherheitsrisiken aufgrund von Ausfällen. Eine niedrigere Cache-Hitrate hat im Steady State aber auch Auswirkungen auf die Sicherheit. Wenn Sie mehr Anfragen direkt von Ihrem Origin-Server aus bedienen, benötigen Sie eine umfangreichere Infrastruktur und möglicherweise auch eine komplexere Architektur. Und damit wären wir wieder beim zuvor erwähnten zusätzlichen Risiko aufgrund der zunehmenden Komplexität und der erhöhten Gefahr menschlicher Fehler.

Höhere Cache-Hitrate bei kleinerer Angriffsfläche

Je höher die CHR, desto geringer die Angriffsfläche, da Cache Hits ausschließlich über Fastly ausgeliefert und Cache Misses von Ihrem Origin-Server abgerufen werden. Eine höhere Cache-Hitrate deutet auf einen höheren Prozentsatz an Hits und eine geringere Anzahl an Anfragen hin, die direkt von Ihren Servern bedient werden müssen.

So verbessern Sie Ihre Cache-Hitrate

Wir haben ein paar wertvolle Tipps zur Verbesserung Ihrer Cache-Hitrate für Sie zusammengestellt. Manche davon gelten nur für Fastly, da unsere Plattform grundsätzlich mehr Inhalte cachen kann als herkömmliche CDNs. Unternehmen von heute müssen Endnutzern bessere Erlebnisse bieten. Sie erreichen dies, indem sie immer mehr Inhalte immer schneller und effizienter ausliefern.

Erhöhen Sie Ihre TTL, damit Inhalte später bereinigt werden

Der wichtigste Parameter, mit dem Sie die Lebensdauer eines Objekts im Cache steuern können, ist die Time to Live (TTL). Sie bestimmt, wie lange Fastly die gecachten Inhalte wiederverwenden kann, um zukünftige Anfragen zu bedienen. Eine kürzere TTL führt dazu, dass Inhalte früher gelöscht werden, was wiederum Cache Misses und mehr Zugriffe auf Ihre Origin-Server begünstigt.

Wenn Sie der Meinung sind, dass Ihre Inhalte für eine lange TTL zu dynamisch sind oder sich zu oft ändern, beweisen wir Ihnen in einem persönlichen Gespräch gerne das Gegenteil. Eines der Tools, die Fastly zur Unterstützung dynamischer Inhalte anbietet, ist Instant Purge.

Verwenden Sie eine lange TTL und bereinigen Sie Inhalte mit Instant Purge, wenn sie sich ändern

Mit der Instant Purge API von Fastly können Sie Inhalte ganz nach Bedarf und besonders schnell aus unserem Netzwerk entfernen. Die weltweite Durchführung einer Bereinigung dauert im Durchschnitt nur 150 ms. Mit etwas Integrationsaufwand können Sie die Vorteile einer sehr langen TTL (z. B. von einem Jahr) in Ihrer Anwendung auch bei dynamischen Inhalten wie API-Antworten oder Live-Sportergebnissen nutzen. Sie werden feststellen, dass Sie viel mehr Inhalte cachen können, als Sie denken.

Aktivieren Sie Origin Shield

Mit Fastlys Origin Shield können Sie einen spezifischen POP als Origin-Server für unsere anderen POPs festlegen. Dadurch steigt die Wahrscheinlichkeit, dass Inhalte im Cache gefunden werden, erheblich. Außerdem wird Ihr Origin-Server entsprechend entlastet. Weitere Informationen zum Thema Origin Shielding erhalten Sie hier.

Liefern Sie zeitweise auch veraltete Inhalte aus

Wenn Sie Ihren Fastly Service so konfigurieren, dass er veraltete Inhalte ausliefert, bleibt er auch bei Ausfällen Ihres Origin-Servers verfügbar.

Entscheiden Sie sich für ein CDN mit weniger, aber leistungsfähigeren POPs mit höherer Speicherkapazität

Es mag Ihnen zunächst vielleicht widersprüchlich erscheinen, aber je weniger POPs ein CDN besitzt, desto wahrscheinlicher ist es, dass Ihre Inhalte bereits im Cache eines einzelnen POPs vorhanden sind. Der Nachteil ist natürlich, dass jeder dieser POPs über wesentlich mehr Speicherkapazität verfügen muss, um einen größeren kombinierten Content Pool bedienen zu können. Dies ist eines der Kernprinzipien der CDN-Architektur von Fastly. Weitere Informationen zu den Vorteilen moderner POPs finden Sie hier.

Erwägen Sie die Nutzung weiterer Fastly Produkte mit engmaschigen Cache-Integrationen

Wenn Sie unseren Image Optimizer aktivieren, können Sie Bildbearbeitungslogik von Ihrem Origin-Server auslagern und die Bildbearbeitung auf der Edge durchführen. Es besteht außerdem eine sehr engmaschige Integration mit dem Fastly Cache, sodass der verfügbare Speicherplatz auch bei einer großen Vielfalt an gerätespezifischen Bildformaten und -größen optimal genutzt wird.

Dank der Integration mit Instant Purge werden bei der Bereinigung Ihrer hochauflösenden Originalbilder auch die davon abgeleiteten Bildversionen gelöscht. Gleichzeitig profitieren Sie aber von einer langen TTL – sogar bei veränderlichen Inhalten.

Weitere Einzelheiten und Ideen zur Verbesserung Ihrer Cache-Abdeckung finden Sie in unseren Best Practices für die Cache-Konfiguration.

Weitere Tipps für die Entlastung Ihrer Origin-Server

Eifrige Angreifer finden Wege, um sich Zugriff auf Ihren Origin-Server zu verschaffen. Die Auslagerung von Logik von Ihrem Origin-Server auf die Edge sorgt für eine wesentlich kleinere Angriffsfläche. Selbst nachdem Sie Ihre CHR maximiert haben, lassen sich Anfragen an Ihren Origin-Server weiter reduzieren – erstellen Sie dazu synthetische Inhalte mit unserer Edge-Compute-Plattform Compute.

Jede Anfrage, die über Compute eingeht, wird in ihrer eigenen von uns erstellten und wieder zerstörten Sandbox ausgeführt. Dies schränkt den Wirkungsradius von fehlerhaftem Code oder Konfigurationsfehlern anderer Nutzer ein und bedeutet eine Verkleinerung der Angriffsfläche. Es handelt sich dabei um ein extrem robustes Sicherheitsmerkmal, das es Ihnen ermöglicht, einen größeren Teil Ihrer Logik in eine Umgebung zu verlagern, die von Haus aus sicherer ist als Ihr Origin-Server. Sie stärken Ihre Sicherheitslage in zweierlei Hinsicht: durch zusätzlichen Schutz Ihres Origin-Servers mit mehr Logik auf der Edge und durch die Ausführung dieser Logik in einer sichereren Compute-Umgebung. Für weitere Informationen über die moderne Anwendungsentwicklung auf der Edge laden Sie hier das Playbook herunter.

Wenn Sie Ihre Logik auf die Fastly Edge verlagern, verringert sich die Angriffsfläche Ihres Origin-Servers von selbst. Zusätzlich werden Sie feststellen, dass auch Performance-Verbesserungen in greifbare Nähe rücken. Wir haben erst kürzlich unsere Core Cache API veröffentlicht, mit der Sie mit Compute generierte partielle oder synthetische Inhalte in den Cache verschieben können. Auf diese Weise genießen Sie sowohl Sicherheitsvorteile als auch die mit gecachten Inhalten verbundenen geringen Latenzzeiten.

* Die von Fastly in Auftrag gegebene und von Forrester Consulting durchgeführte Total Economic Impact™ Studie zu den Netzwerkservices von Fastly ist im Juli 2023 erschienen.