Sie müssen die Sicherheitsschicht bei der Cloud-Migration nicht neu aufbauen
Cloud-Migrationen geraten in den meisten Organisationen an derselben Frage ins Stocken: „Müssen wir die Sicherheits- und Delivery-Schicht, die wir im Rechenzentrum über Jahre gereift haben, auf Azure neu aufbauen?" Mit den nativen Cloud-Diensten lautet die Antwort in der Regel „ja" — Regelwerke werden neu geschrieben, Teams lernen ein neues Werkzeug, Ausnahmelisten entstehen von Grund auf neu, und die Policy-Abweichung zwischen beiden Umgebungen beginnt schon am ersten Tag.
Die Verfügbarkeit von TR7 im Azure Marketplace verändert diese Gleichung. Dieselbe Software, die auf Ihren TR7-Hardware- oder virtuellen Appliances im Rechenzentrum läuft, startet jetzt in Minuten in Ihrem Azure-Abonnement: dieselbe WAF-Engine, dieselbe Policy-Sprache, dieselbe Verwaltungsoberfläche. Ihre Load-Balancing-Algorithmen, SSL/TLS-Profile, individuellen WAF-Regeln und Zugriffsrichtlinien wandern ohne Regelübersetzung nach Azure.
Dieser Beitrag behandelt drei Dinge: was das Marketplace-Deployment in der Praxis bringt, wo TR7 in Ihrer Azure-Architektur sitzt und welches Lizenzmodell zu welchem Szenario passt.
Warum ein eigener ADC und eine eigene WAF auf Azure?
Azure bietet native Dienste für grundlegendes Load Balancing und signaturbasierten Web-Schutz. Warum bringen Organisationen dennoch ihre eigene Application-Delivery-Plattform in die Cloud? Vier Gründe stechen hervor:
Policy-Konsistenz
WAF-Regeln, die im Rechenzentrum getestet und gereift sind, laufen auf Azure Zeile für Zeile identisch. Keine Regelübersetzung, kein Verhaltensunterschied, keine zwei getrennten Ausnahmelisten. Im Audit legen Sie einen einzigen Satz von Nachweisen vor.
Tiefe jenseits der nativen Dienste
Fähigkeiten wie fortgeschrittenes Bot-Management, verhaltensbasiertes DDoS-Lernen, Maskierung sensibler Daten, virtuelles Patching und forensische Aufzeichnung erfordern eine Plattform der Enterprise-Klasse. Die Lücke, die Basisdienste hinterlassen, ist genau der Raum, in dem Angreifer arbeiten.
Portabilität
TR7-Lizenzen sind an die Organisation gebunden, nicht an die Plattform. Sie wandern mit Ihrem Workload zwischen Azure, GCP, VMware und jedem unterstützten Hypervisor; ein Cloud-Lock-in entsteht nicht.
Eine einzige Managementebene
Alle TR7-Instanzen on-premises und auf Azure werden über eine einzige Konsole verwaltet; Logs, Metriken und Ereignisaufzeichnungen laufen an einem Ort zusammen. Für die Cloud-Seite bauen Sie kein separates Monitoring- und Reporting-Regime auf.
Deployment- und Lizenzmodelle
Das TR7-Image im Azure Marketplace ist mit zwei Lizenzmodellen nutzbar; für bestehende Hardware-Kunden gibt es zusätzlich einen dritten, hybriden Weg:
| Modell | Am besten geeignet für | Abrechnung |
|---|---|---|
| PAYG (über die Azure-Rechnung) | Schneller Einstieg, variable Lasten, PoC und kurzfristige Projekte | Stündlich, keine Vorabverpflichtung |
| Fixed-Term BYOL | Geplante Produktions-Workloads, vorhersehbare Kapazität | Laufzeitlizenz; übertragbar auf Azure und andere Plattformen |
| Hybrid (Hardware + Azure) | Schrittweise Cloud-Erweiterung, Disaster Recovery, Überlaufkapazität | Bestehende Hardware-Lizenz + Cloud-Instanz |
Wo sitzt TR7 in Ihrer Azure-Architektur?
Die häufigste Platzierung ist der Rand des Hub-VNet in einer Hub-Spoke-Topologie. TR7 wird als zentraler Eintrittspunkt für den gesamten eingehenden Traffic positioniert: SSL/TLS-Terminierung, WAF-Prüfung, Bot-Management und Load Balancing werden in einem einzigen Durchgang angewendet; der bereinigte Traffic wird an die Workloads in den Spoke-VNets verteilt. AKS-Cluster, App-Service-Anwendungen und VM Scale Sets werden als Backend-Pools definiert — die Layer-7-Routing-, Session-Affinitäts- und Health-Monitoring-Fähigkeiten von TR7 arbeiten vor diesen Diensten unverändert.
Für Hochverfügbarkeit werden TR7-Instanzen aktiv-aktiv über Verfügbarkeitszonen (Availability Zones) hinweg geclustert. Beim Ausfall einer Zone wird der Traffic unterbrechungsfrei an die Instanz in der gesunden Zone übergeben; Konfiguration und Sitzungszustand werden innerhalb des Clusters synchronisiert.
Im Hybrid-Szenario kommt TR7 GTM über eine ExpressRoute- oder VPN-Verbindung zwischen Rechenzentrum und Azure ins Spiel: Der Nutzer-Traffic wird nach Geografie, Latenz oder Rechenzentrums-Gesundheit zwischen dem On-Premises- und dem Azure-Standbein geroutet. Das ist zugleich das Rückgrat einer schrittweisen Migration — zunächst Azure als passives/DR-Standbein, dann Aktiv-aktiv-Betrieb und am Ende, wenn gewünscht, die vollständige Cloud.
Go-live in fünf Schritten
Plan im Marketplace auswählen
Suchen Sie TR7 im Azure Marketplace; wählen Sie den PAYG- oder BYOL-Plan und stellen Sie ihn in Ihrem Abonnement bereit.
Netzwerk und Größe festlegen
Wählen Sie die VNet-, Subnetz- und Public-IP-Konfiguration; bestimmen Sie die Instanzgröße passend zum erwarteten Traffic-Profil.
Lizenz aktivieren
Aktivieren Sie im Einrichtungsassistenten beim ersten Start — bei PAYG automatisch, bei BYOL mit Ihrem Lizenzschlüssel.
Policies importieren
Importieren Sie Ihre bestehende TR7-Konfiguration, Ihre WAF-Regeln und Zertifikate; definieren Sie die Backend-Pools.
Traffic schrittweise umleiten
Leiten Sie per DNS oder GTM einen Teil des Traffics auf das Azure-Standbein; erhöhen Sie den Anteil nach der Validierung.
Bestehende Lizenzen der virtuellen TR7-Plattform lassen sich ohne Zusatzkosten nach Azure übertragen. Ein Start mit PAYG und der Wechsel zu BYOL nach der Validierung ist möglich; die Lizenz folgt Ihrem Workload zwischen Azure und den anderen unterstützten Plattformen. In der Kapazitätsplanung werden Hardware- und Cloud-Instanzen als ein einziges Inventar verwaltet.
Testen Sie TR7 auf Azure
Übertragen Sie die Schutz- und Delivery-Policies aus Ihrem Rechenzentrum mit derselben Engine nach Azure. Entdecken Sie die Fähigkeiten der virtuellen TR7-Plattform oder fordern Sie bei unserem Team eine individuelle Demo für Ihr Azure-Deployment an.
Virtuelle TR7-Plattform entdecken