Das passende Werkzeug – Azure Storage Account Static Website

IT Abteilungen stehen immer wieder vor der Herausforderung, relativ statische Web-Inhalte „hoch verfügbar“ bereitzustellen. Das darf dann weder „ausfallen“ noch „Geld kosten“. Zumindest erlebe ich das immer wieder so.

Ein verbreitetes Beispiel ist dabei die „Certificate revocation list„, kurz CRL. Stelle eine Firma also eigene (SSL) Zertifikate aus, gibt es eine Liste, die die nicht länger gültigen, aber ausgestellten Zertifikate enthält. Das ist eine wichtige Funktion, denn besteht der Verdacht, dass das Zertifikat missbraucht sein/werden könnte, so muss bekannt sein, dass dieses nicht länger gültig ist.

Was also tun? „Hochverfügbar“ bedeutet in der Regel, dass es mindestens zwei Server gibt, die die CRL bereitstellen. Fällt ein Server aus, übernimmt der andere bzw. je nach Load-Balancer wird die „Last“ der CRL-Abrufe auf beide Server verteilt.
Wer also bereits ein solches Web-Server Konstrukt betreibt, kann dieses kostengünstig auch für die CRL nutzen. Wer das nicht hat, müsste entsprechend zwei Server aufsetzen und betreiben. Für mich fällt das in die Kategorie „kann man so machen“.

Die traditionelle Lösung

Eine traditionelle Lösung würde vermutlich so, oder so ähnlich aussehen:

Schaubild: CRL mit Web Server

Hierbei legt die PKI die CRL periodisch auf zwei Web-Servern (hochverfügbar und so) ab, welche über einen Load Balancer veröffentlicht wird.
Würde man dies so in Azure abbilden, wäre die günstige Variante wie folgt:

  • 2x Azure Ubuntu VM in B2s (2 vCPUs, 4 GB RAM, 32 GB Disk [P4]) ~70€/Monat
  • 1x Azure Load Balancer Standard ~ 20€/Monat
  • 1x (geschätzt 100GB Datentransfer Azure -> Internet) ~ 6€/Monat

Das ergibt gesamt rund 95€ jeden Monat. Werden in den VMs statt Ubuntu andere Betriebssysteme verwendet, kommen noch die jeweiligen Betriebssystemlizenzen (RHEL, SLES, Windows Server, etc.) noch dazu.

Die Cloud-Lösung

Viel besser finde ich es, die CRL über die „Static website“ Funktion von Azure Storage Accounts bereitzustellen. Diese Funktion veröffentlicht sämtliche Inhalte, die in den „$web“ Container des Storage Accounts hochgeladen werden per http(s). Hierbei kann auch die Storage Account Firewall genutzt werden.
Aufgerufen werden dann die Inhalte über http(s)://<name-des-storage-accounts>.z6.web.core.windows.net/<datei-pfad-und-name> aufgerufen.
Ein paar Einstellungen sind noch wichtig.

Secure transfer required“ steuert, ob die Website nur per https oder auch per http erreichbar ist. Für den Use-Case „CRL“ wird auch http benötigt, also muss diese Einstellung auf „Disabled“ gesetzt werden.

Minimum TLS Version“ greift für den https Aufruf der Website. Sofern nicht anders erforderlich sollte hier TLS 1.2 verwendet werden.

Lösung 1: Static Website only

Bei der Lösung mit der Static Website, wird die CRL in den $web-Container des Storage Accounts übertragen, welcher die CRL dann gemäß der Redundanzeinstellung „hochverfügbar“ bereitstellt.

Schaubild: CRL mit Storage Static Website

Die Kalkulation von der traditionellen Lösung auf dieses Szenario übertragen, bedeutet ein Storage Account mit einer Kapazität von 1 GB (weniger geht im Azure Calculator nicht), 10x 10.000 Schreib-Operationen (vermutlich komplett überzogen), 1000 x 10.000 Lese-Operationen (auch vermutlich überzogen), 100 GB Datenabruf und 1 GB Daten schreiben.
Bei einer Redundanzeinstellung von ZRS, liegen die Azure Kosten bei 4,80€ je Monat. Ändern wir die Redundanzeinstellung von ZRS auf RA-GRS (eine der höchsten Redundanzen, mit einer Spiegelung der Daten über > 100KM Distanz) liegen die Azure Kosten bei 5,50€ je Monat.
Das ist – selbst wenn ich zugunsten von Storage Accounts kalkuliert habe – doch ein deutlicher Unterschied zu ~95€/Monat.

Lösung 2: Static Website mit Traffic Manager

Die Lösung 1 wird prima funktionieren, hat aber zwei Herausforderungen, die ggf. angepasst werden sollten.

  1. Die URL ist fest auf http(s)://<name-des-storage-accounts>.z6.web.core.windows.net/ definiert.
  2. Der Storage Account ist in einer bestimmten Azure Region angelegt.

Solange der Aufruf der Webseite aus der gleichen Region kommt, ist der Aufruf auch zügig abgearbeitet. Liegt also der Storage Account in Europa, aber der Aufruf kommt aus Asien, so wird die Latenz schon deutlich spürbar sein.
Deshalb können auch in mehreren Regionen (z.B. Europa, Nord Amerika und Asien/Pazifik) Storage Accounts angelegt und mit Azure Traffic Manager veröffentlicht werden. Der Azure Traffic Manager sorgt dafür, dass der Traffic stets zum nahegelegensten Storage Account geleitet wird und somit eine Art von Load Balancing erfolgt.

Schaubild: Static Website mit Traffic Manager

Das Szenario mit dem Traffic Manager löst zumindest schon mal den Punkt 2 aus vorheriger Liste, der Punkt 1 ist so eine Sache. Theoretisch sollte das mit einem CNAME xxx.yourdomain.de -> xxx.trafficmanager.net funktionieren, habe ich aber nicht getestet. Gerade mit dem SSL Zertifikat könnte das zu Problemen führen.

Azure Kosten-seitig liegt diese Lösung bei rund 19€/Monat (Metriken wie in Lösung 1)

  • 1x Storage Account in West Europe: 4,80€/Monat
  • 1x Storage Account in Central US: 4,45€/Monat
  • 1x Storage Account in Southeast Asia: 5,20€/Monat
  • 1x Traffic Manager: 4,80€/Monat

Lösung 3: Static Website mit CDN

Eleganter wird die Lösung potentiell, wenn anstelle von drei Storage Accounts und dem Traffic Manager die CRL per (Azure) CDN veröffentlicht wird.
Azure CDNs unterstützen Custom Domains (Punkt 1 von oben abgehakt) und stellt die Daten geografisch verteilt zur Verfügung (Punkt 2 von oben abgehakt).

Schaubild: Static Website mit CDN

Die CRL wird auch hier wieder periodisch auf dem Storage Account aktualisiert, der Cache vom CDN (ganz automatisch) ebenfalls. Klar kann es so sein, dass zeitweise eine „veraltete“ Version der CRL vom CDN veröffentlicht wird, aber zum einen wird das nur eine kurze Zeit der Fall sein und zum anderen ist das vermutlich besser, als lange warten zu müssen. Außerdem kann im Bedarfsfall auch der Cache-Refresh manuell angestoßen werden. Das wäre dann hilfreich, wenn bspw. schnell auf ein zurückgezogenes Zertifikat reagiert werden muss.
Jetzt kommt bestimmt die Frage auf, wie sich diese Lösung kostenseitig verhält. Hier die Auflösung:

  • 1x Storage Account in West Europe: 4,80€/Monat
  • 1x CDN, 50GB Zone 1 (NA, EU), 50GB Zone 2 (APAC, Japan), 1GB „Cache“: 9€/Monat

Diese Lösung liegt also bei rund 14€ pro Monat.

Fazit

Wie so oft ist es wichtig die Möglichkeiten seiner Umgebung zu kennen und zu nutzen. Die Lösung 3 zeigt, wie sich so ein Szenario schnell, günstig und mit praktisch keinen/kaum Betriebsaufwand realisieren lässt. Schließlich müssen weder Storage Accounts noch Azure CDNs gepatcht und gewartet werden.