Einleitung
In diesem Dokument wird beschrieben, wie Sie die automatisch skalierte Cisco FirePOWER Threat Defense Virtual (FTDv) in Azure in einer Umgebung mit hohem Vertrauen bereitstellen.
Voraussetzungen
Anforderungen
Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:
- Die Kommunikation zwischen NGFW und FirePOWER Management Center sollte über private IP erfolgen.
- Der externe Load Balancer darf keine öffentliche IP-Adresse aufweisen.
- Die App der Funktion sollte mit Private IP kommunizieren können.
Verwendete Komponenten
Die Informationen in diesem Dokument basierend auf folgenden Software- und Hardware-Versionen:
- Azure
- FirePOWER Management Center
- Skalierbare virtuelle Systeme
Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.
Hintergrundinformationen
FTDv stellt die Firepower-Firewall der nächsten Generation von Cisco für virtualisierte Umgebungen bereit und ermöglicht die Durchsetzung konsistenter Sicherheitsrichtlinien, die Workloads in physischen, virtuellen und Cloud-Umgebungen sowie zwischen Clouds verfolgen.
Da diese Bereitstellungen in einer virtualisierten Umgebung zur Verfügung stehen, wird die NGFW derzeit nicht in Hochverfügbarkeit unterstützt. Um eine hochverfügbare Lösung bereitzustellen, nutzt die Cisco Next-Generation Firewall (NGFW) die nativen Funktionen von Azure, wie z. B. Availability Sets und Virtual Machine Scale Set (VMSS), um die NGFW hochverfügbar zu machen und den wachsenden Datenverkehr nach Bedarf zu bewältigen.
Der Schwerpunkt dieses Dokuments liegt auf der Konfiguration der Cisco NGFW für AutoScale basierend auf verschiedenen Parametern, wobei die NGFW bei Bedarf skaliert oder erweitert wird. Dies gilt für den Anwendungsfall, bei dem der Kunde das FirePOWER Management Center (FMC) nutzen muss, das im Rechenzentrum am Standort verfügbar ist und für die zentrale Verwaltung der gesamten NGFW benötigt wird. Außerdem möchten Kunden nicht, dass FMC und FTD über öffentliche IP für den Verwaltungsverkehr kommunizieren.
Bevor wir uns näher mit der Konfiguration und dem Design befassen, möchten wir Ihnen einige Konzepte vorstellen, die Azure gut verstehen sollte:
Verfügbarkeitszone: Eine Verfügbarkeitszone ist ein Hochverfügbarkeitsangebot, das Ihre Anwendungen und Daten vor Ausfällen im Rechenzentrum schützt. Verfügbarkeitsbereiche sind eindeutige physische Standorte innerhalb einer Azure-Region. Jede Zone besteht aus einem oder mehreren Rechenzentren, die mit unabhängiger Stromversorgung, Kühlung und Vernetzung ausgestattet sind.
VNET: Azure Virtual Network (VNet) ist der grundlegende Baustein für Ihr privates Netzwerk in Azure. VNet ermöglicht eine Vielzahl von Azure-Ressourcen wie Azure Virtual Machines (VM) für die sichere Kommunikation untereinander, mit dem Internet und mit lokalen Netzwerken. VNet ähnelt einem herkömmlichen Netzwerk, da Sie in Ihrem eigenen Rechenzentrum arbeiten würden, bietet jedoch zusätzliche Vorteile der Azure-Infrastruktur wie Skalierbarkeit, Verfügbarkeit und Isolierung. Jedes Subnetz innerhalb eines VNET ist standardmäßig für das jeweils andere erreichbar. Dies gilt jedoch nicht für Subnetze in verschiedenen VNETs.
Verfügbarkeitssatz: Verfügbarkeitssätze sind eine weitere Rechenzentrumskonfiguration, um VM-Redundanz und -Verfügbarkeit zu gewährleisten. Diese Konfiguration innerhalb eines Rechenzentrums stellt sicher, dass während eines geplanten oder ungeplanten Wartungsereignisses mindestens ein virtuelles System verfügbar ist und den Azure SLA von 99,95 % erfüllt.
VMSS: Mit Azure Virtual Machine-Skalierungssätzen können Sie eine Gruppe von VMs mit Lastausgleich erstellen und verwalten. Die Anzahl der VM-Instanzen kann automatisch nach Bedarf oder einem festgelegten Zeitplan erhöht oder verringert werden. Skalierbare Sets sorgen für eine hohe Verfügbarkeit Ihrer Anwendungen und ermöglichen Ihnen, eine große Anzahl von VMs zentral zu verwalten, zu konfigurieren und zu aktualisieren. Mit den Skalierungssets für virtuelle Systeme können Sie umfangreiche Services für Bereiche wie Computing, Big Data und Container-Workloads erstellen.
Funktionen App: Azure Functions ist ein bedarfsgesteuerter Cloud-Service, der alle für die Ausführung Ihrer Anwendungen erforderlichen, ständig aktualisierten Infrastrukturen und Ressourcen bereitstellt. Sie konzentrieren sich auf die Codebestandteile, die für Sie am wichtigsten sind, und Azure Functions übernimmt den Rest. Sie können Azure-Funktionen verwenden, um Web-APIs zu erstellen, auf Datenbankänderungen zu reagieren, IoT-Streams zu verarbeiten, Nachrichtenwarteschlangen zu verwalten und vieles mehr. In dieser AutoScaled Lösung, Azure-Funktion sind verschiedene API-Anfragen an FMC für die Erstellung von Objekten, Registrierung / Aufhebung der Registrierung FTDv, Überprüfung der Parameter, etc.
Logic App: Azure Logic Apps ist ein Cloud-Service, mit dem Sie Aufgaben, Geschäftsprozesse und Workflows planen, automatisieren und orchestrieren können, wenn Sie Anwendungen, Daten, Systeme und Services in Unternehmen oder Organisationen integrieren müssen. Logic Apps vereinfacht das Design und die Entwicklung skalierbarer Lösungen für Anwendungsintegration, Datenintegration, Systemintegration, Enterprise Application Integration (EAI) und Business-to-Business (B2B)-Kommunikation, ob in der Cloud, am Standort oder beides. Diese Lösung bietet eine logische Sequenzierung der Funktionen, die für die Funktion der Lösung Autoscaled ausgeführt werden sollen.
Derzeit bietet die für die NGFW verfügbare AutoScale-Lösung keinen Managementplan für die Kommunikation mit der lokalen privaten IP-Adresse des VNet und erfordert eine öffentliche IP-Adresse für den Austausch von Kommunikation zwischen dem FirePOWER Management Center und der NGFW.
Dieser Artikel soll dieses Problem lösen, bis die verifizierte Lösung für die FirePOWER Management Center- und NGFW-Kommunikation über private IP verfügbar ist.
Konfigurieren
Um eine automatisierte NGFW-Lösung zu erstellen, wird dieser Konfigurationsleitfaden mit verschiedenen Änderungen verwendet, sodass die folgenden Anwendungsfälle behandelt werden können:
- Die Anwendung der Funktion muss in der Lage sein, mit dem internen IP-Segment des Kunden zu kommunizieren.
- Der Load Balancer darf keine öffentliche IP-Adresse aufweisen.
- Management-Datenverkehr zwischen NGFW und FMC sollte über das private IP-Segment ausgetauscht werden
Um eine AutoScaled NGFW-Lösung mit den oben genannten Anwendungsfällen zu erstellen, müssen Sie diese wie im offiziellen Leitfaden von Cisco beschrieben ändern:
1. Azure ARM-Vorlage
Die ARM-Vorlage wird zum Aktivieren der Automatisierung in Azure verwendet. Cisco hat eine verifizierte ARM-Vorlage bereitgestellt, die zur Erstellung einer automatischen Skalierung verwendet werden kann. Diese ARM-Vorlage im Public Github erstellt jedoch eine Funktions-App, die nicht an das interne Netzwerk des Kunden übermittelt werden kann, obwohl sie über Express-Routen erreichbar ist. Daher müssen Sie diese ein wenig ändern, sodass Funktion App kann nun verwenden, Premium-Modus statt Consumption-Modus. Die erforderliche ARM-Vorlage ist daher unter https://github.com/Madhuri150791/FunctionApp_with_Premiium_Plan.git verfügbar.
2. Funktion APP
Die Funktions-App ist ein Satz von Azure-Funktionen. Zu den grundlegenden Funktionen gehören:
- Azure-Metriken regelmäßig kommunizieren/testen.
- Überwachen der FTDv-Last und Auslösen von Scale-In/Scale-Out-Vorgängen
- Registrieren Sie ein neues FTDv beim FMC.
- Konfigurieren eines neuen FTDv über FMC
- Deaktivieren (entfernen) Sie eine skalierte FTDv vom FMC.
Wie in der Anforderung erwähnt, erfolgt die Erstellung bzw. Löschung der verschiedenen Funktionen für On-Demand-NGFWs basierend auf der öffentlichen IP der NGFW. Aus diesem Grund müssen wir den C#-Code so anpassen, dass eine private IP statt einer öffentlichen IP erhalten wird. Nach dem Tweaking des Codes ist die ZIP-Datei zur Erstellung der Funktions-App unter https://github.com/Madhuri150791/FunctionApp_with_Premiium_Plan.git verfügbar.
mit dem Namen ASM_Function.zip. Dadurch kann die Funktions-App mit internen Ressourcen kommunizieren, ohne über die öffentliche IP zu verfügen.
3. Logik-App
Die Auto Scale Logic App ist ein Workflow, d.h. eine Sammlung von Schritten in einer Sequenz. Azure-Funktionen sind unabhängige Entitäten und können nicht miteinander kommunizieren. Dieser Orchestrator sequenziert die Ausführung dieser Funktionen und tauscht Informationen zwischen ihnen aus.
- Die Logik-App dient zum Orchestrieren und Übergeben von Informationen zwischen den Azure-Funktionen für die automatische Skalierung.
- Jeder Schritt stellt eine Azure-Funktion zur automatischen Skalierung oder eine integrierte Standardlogik dar.
- Die Logic App wird als JSON-Datei ausgeliefert.
- Die Logic App kann über die GUI oder die JSON-Datei angepasst werden.
Hinweis: Die Details der Logik-App unter https://github.com/Madhuri150791/FunctionApp_with_Premiium_Plan.git müssen sorgfältig geändert und durch Bereitstellungsdetails, den Namen der FUNSTIONAPP, den Namen der RESSOURCENGRUPPE und die Abonnement-ID ersetzt werden.
Netzwerkdiagramm
Dieses Bild zeigt, wie eingehender und ausgehender Datenverkehr in einer Azure-Umgebung über die NGFW fließt.
Konfigurationen
Erstellen Sie nun verschiedene Komponenten, die für eine automatisch skalierte Lösung erforderlich sind.
- Erstellen Sie Komponenten der automatischen Skalierung.
Verwenden Sie die ARM-Vorlage, und erstellen Sie VMSS, Logic APP, Function APP, App Insight und Network Security Group.
Navigieren Sie zu Home > Create a Resource > Search for Template
und dann Template Deployment
. Klicken Sie jetzt auf Create
und erstellen Sie Ihre eigene Vorlage im Editor.
- Klicken Sie
Save
.
Nehmen Sie die erforderlichen Änderungen an dieser Vorlage vor, und klicken Sie auf Review + create
.
- Dadurch werden alle Komponenten unter der genannten Ressourcengruppe erstellt.
- Melden Sie sich bei der URL an.
Datei hochladen ASM_Function.zip
und ftdssh.exe
zu site/wwwroot/
Ordner (es ist zwingend erforderlich, es an den angegebenen Speicherort hochzuladen Function App identifiziert nicht verschiedene Funktionen).
Es sollte wie dieses Bild aussehen:
- Einchecken im
Function app > Function
. Sie sollten alle Funktionen sehen.
- Ändern Sie die Zugriffsberechtigung, sodass VMSS die Funktionen in der Funktions-App ausführen kann. Navigieren Sie zu
-vmss> Access Control (IAM) > Add role assignement
. Stellen Sie diesen VMSS-Teilnehmerzugriff auf
-function-app
.
Klicken Sie auf Save
.
- Navigieren Sie zu
Logic App > Logic Code
Zeigen Sie den Logikcode mit dem Code unter https://github.com/CiscoDevNet/cisco-ftdv/tree/master/autoscale/azure/NGFWv6.6.0/Logic%20App an, und ändern Sie ihn. In diesem Fall müssen Azure-Abonnement, Ressourcengruppenname und Funktions-App-Name vor der Verwendung ersetzt werden. Eine erfolgreiche Speicherung ist nicht möglich.
- Klicken Sie auf
Save
. Navigieren Sie zu Logik-App - Übersicht und aktivieren Logic App
.
Überprüfung
Sobald die Logik-App sofort aktiviert ist, beginnt sie im Intervall von 5 Minuten auszuführen. Wenn alles richtig konfiguriert ist, werden die Auslöseraktionen erfolgreich ausgeführt.
Außerdem wird die VM unter VMSS erstellt.
Melden Sie sich bei FMC an, und überprüfen Sie, ob FMC und NGFW über eine private FTDv-IP-Adresse verbunden sind:
Wenn Sie sich bei der NGFW-CLI anmelden, werden folgende Informationen angezeigt:
Daher kommuniziert FMC über Azure Private VNet Subnet mit NGFW.
Fehlerbehebung
Wenn Sie eine neue NGFW aufbauen, schlägt Logic App manchmal fehl. Zur Fehlerbehebung können folgende Schritte ausgeführt werden:
- Überprüfen Sie, ob die Logik-App erfolgreich ausgeführt wird.
- Identifizieren der Fehlerursache Klicken Sie auf den fehlerhaften Auslöser.
Versuchen Sie, den Fehlerpunkt aus dem Codefluss zu identifizieren. Aus diesem Bild wird deutlich, dass die ASM-Logik fehlschlug, da sie keine Verbindung zu FMC herstellen konnte. Als Nächstes müssen Sie feststellen, warum FMC gemäß Azure-Datenfluss nicht erreichbar war.