In dem Dokumentationssatz für dieses Produkt wird die Verwendung inklusiver Sprache angestrebt. Für die Zwecke dieses Dokumentationssatzes wird Sprache als „inklusiv“ verstanden, wenn sie keine Diskriminierung aufgrund von Alter, körperlicher und/oder geistiger Behinderung, Geschlechtszugehörigkeit und -identität, ethnischer Identität, sexueller Orientierung, sozioökonomischem Status und Intersektionalität impliziert. Dennoch können in der Dokumentation stilistische Abweichungen von diesem Bemühen auftreten, wenn Text verwendet wird, der in Benutzeroberflächen der Produktsoftware fest codiert ist, auf RFP-Dokumentation basiert oder von einem genannten Drittanbieterprodukt verwendet wird. Hier erfahren Sie mehr darüber, wie Cisco inklusive Sprache verwendet.
Cisco hat dieses Dokument maschinell übersetzen und von einem menschlichen Übersetzer editieren und korrigieren lassen, um unseren Benutzern auf der ganzen Welt Support-Inhalte in ihrer eigenen Sprache zu bieten. Bitte beachten Sie, dass selbst die beste maschinelle Übersetzung nicht so genau ist wie eine von einem professionellen Übersetzer angefertigte. Cisco Systems, Inc. übernimmt keine Haftung für die Richtigkeit dieser Übersetzungen und empfiehlt, immer das englische Originaldokument (siehe bereitgestellter Link) heranzuziehen.
In diesem Dokument wird beschrieben, wie die automatisierte Bereitstellung von Cisco FirePOWER Threat Defense Virtual (FTDv) in Azure in einer Umgebung mit hoher Vertrauenswürdigkeit möglich ist.
Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:
Die Informationen in diesem Dokument basierend auf folgenden Software- und Hardware-Versionen:
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 potenziellen Auswirkungen eines Befehls verstehen.
FTDv stellt die Firepower Next-Generation Firewall-Funktionalität von Cisco für virtualisierte Umgebungen bereit, die konsistente Sicherheitsrichtlinien für Workloads in physischen, virtuellen und Cloud-Umgebungen sowie zwischen Clouds ermöglicht.
Da diese Bereitstellungen in einer virtualisierten Umgebung verfügbar sind, ist derzeit keine Unterstützung für HA für NGFW verfügbar. Um eine hochverfügbare Lösung bereitzustellen, nutzt die Cisco Next-Generation Firewall (NGFW) die nativen Funktionen von Azure wie Availability Sets und Virtual Machine Scale Set (VMSS), um NGFW hochverfügbar zu machen und den wachsenden Datenverkehr nach Bedarf zu bewältigen.
Das vorliegende Dokument behandelt schwerpunktmäßig die Konfiguration der Cisco NGFW für die automatische Skalierung auf Basis verschiedener Parameter, wobei die NGFW ON-DEMAND skaliert bzw. skaliert werden kann. Dies gilt für den Anwendungsfall, in dem der Kunde ein FirePOWER Management Center (FMC) benötigt, das im Rechenzentrum am Standort verfügbar ist und für die zentrale Verwaltung der gesamten NGFW erforderlich ist. Kunden möchten auch keine FMC- und FTD-Kommunikation für Verwaltungsdatenverkehr über öffentliche IP.
Bevor wir uns näher mit der Konfiguration und dem Design befassen, sollten Sie die folgenden Konzepte auf Azure aufmerksam machen:
Derzeit bietet die für NGFW verfügbare AutoScale-Lösung keinen Verwaltungsplan für die Kommunikation mit dem lokalen Private IP-VNet und erfordert eine öffentliche IP für den Austausch der Kommunikation zwischen dem FirePOWER Management Center und der NGFW.
Dieser Artikel zielt darauf ab, dieses Problem zu beheben, bis die verifizierte Lösung für FirePOWER Management Center und NGFW-Kommunikation über private IP verfügbar ist.
Zum Erstellen einer automatisch skalierten NGFW-Lösung wird dieses Konfigurationshandbuch verwendet:
mit mehreren Änderungen, sodass die folgenden Anwendungsfälle behandelt werden können:
Um eine AutoScaled NGFW-Lösung mit den oben genannten Anwendungsfällen zu erstellen, müssen Sie diese in den Schritten ändern, die im offiziellen Leitfaden von Cisco erwähnt werden:
Die ARM-Vorlage wird für die Automatisierung in Azure verwendet. Cisco hat eine verifizierte ARM-Vorlage bereitgestellt, die zur Erstellung einer Lösung für automatische Skalierung verwendet werden kann. Diese ARM-Vorlage, die unter Public Github https://github.com/CiscoDevNet/cisco-ftdv/tree/master/autoscale/azure/NGFWv6.6.0/ARM%20Template verfügbar ist, erstellt eine Funktions-App, die nicht für die Kommunikation mit dem internen Netzwerk des Kunden konfiguriert werden kann, obwohl sie über Express Routes erreichbar sind. Daher müssen wir das ein wenig ändern, sodass Function App jetzt den Premium-Modus anstelle des Verbrauchsmodus verwenden kann. Die erforderliche ARM-Vorlage ist daher unter https://github.com/Madhuri150791/FunctionApp_with_Premiium_Plan.git verfügbar.
Die Funktions-App besteht aus einem Satz Azure-Funktionen. Zu den grundlegenden Funktionen gehören:
Wie in der Anforderung erwähnt, werden die verschiedenen Funktionen für die Erstellung oder Löschung einer NGFW bei Bedarf basierend auf der öffentlichen IP-Adresse der NGFW erstellt. Daher müssen wir C#-Code so anpassen, dass private IP anstelle von Public IP abgerufen wird. Nachdem Sie den Code geändert haben, steht die ZIP-Datei zum Erstellen der Function App unter https://github.com/Madhuri150791/FunctionApp_with_Premiium_Plan.git zur Verfügung.
mit dem Namen ASM_Function.zip. Dadurch kann die Functions-App mit internen Ressourcen kommunizieren, ohne über die öffentliche IP zu verfügen.
Die Auto Scale Logic App ist ein Workflow, d. h. eine Sammlung von Schritten in einer Sequenz. Azure-Funktionen sind unabhängige Einheiten und können nicht miteinander kommunizieren. Dieser Orchestrator knüpft die Ausführung dieser Funktionen und tauscht Informationen zwischen ihnen aus.
Hinweis: Die unter https://github.com/Madhuri150791/FunctionApp_with_Premiium_Plan.git verfügbaren Logic-App-Details müssen sorgfältig geändert und durch Bereitstellungsdetails, FUNSTIONAPP-Name, RESOURCE GROUP-Name, ABONNEMENT-ID, ersetzt werden.
Dieses Bild zeigt, wie ein- und ausgehender Datenverkehr innerhalb einer Azure-Umgebung über die NGFW fließt.
Erstellen Sie jetzt verschiedene Komponenten, die für eine automatische Skalierung erforderlich sind.
Verwenden Sie die ARM-Vorlage, und erstellen Sie VMSS, Logic APP, Function APP, App Insight, Network Security Group.
Navigieren Sie zu Startseite > Ressource erstellen > Nach Vorlage suchen, und wählen Sie dann Vorlagenbereitstellung aus. Klicken Sie jetzt auf Erstellen und erstellen Sie Ihre eigene Vorlage im Editor.
Nehmen Sie die erforderlichen Änderungen an dieser Vorlage vor, und klicken Sie auf Prüfen + Erstellen.
https://<function_app_name>.scm.azurewebsites.net/DebugConsole
Laden Sie die Datei ASM_Function.zip und ftdssh.exe auf site/wwwroot/folder hoch (Es ist obligatorisch, sie in den angegebenen Speicherort hochzuladen, da Function App verschiedene Funktionen nicht identifiziert.)
Es sollte wie folgt aussehen:
Navigieren Sie zu <prefix>-vmss> Zugriffskontrolle (IAM) > Rollenzuweisung hinzufügen. Stellen Sie diesem VMSS einen beitragenden Zugriff auf <prefix>-function-app bereit
Klicken Sie auf Speichern.
https://github.com/CiscoDevNet/cisco-ftdv/tree/master/autoscale/azure/NGFWv6.6.0/Logic%20App
Hier müssen Azure Subscription, Resource Group Name und Function App Name vor der Nutzung ausgetauscht werden. Andernfalls können keine Daten erfolgreich gespeichert werden.
Sobald die Logik-App aktiviert ist, beginnt sie sofort mit der Ausführung im Intervall von 5 Minuten.
Wenn alles korrekt konfiguriert ist, sehen Sie, dass die Triggeraktionen erfolgreich verlaufen.
Außerdem wird VM unter VMSS erstellt.
Melden Sie sich beim FMC an, und überprüfen Sie, ob FMC und NGFW über FTDv Private IP verbunden sind:
Wenn Sie sich bei der NGFW-CLI anmelden, sehen Sie Folgendes:
Daher kommuniziert FMC über Azure Private VNet-Subnetz mit NGFW.
Manchmal schlägt Logic App beim Aufbau einer neuen NGFW fehl, um eine solche Situation zu beheben. Gehen Sie wie folgt vor:
Klicken Sie auf den ausgefallenen Trigger.
Versuchen Sie, den Fehlerpunkt aus dem Codefluss zu identifizieren. Aus dem obigen Ausschnitt geht hervor, dass die ASM-Logik fehlschlug, da sie keine Verbindung mit dem FMC herstellen konnte. Als Nächstes müssen Sie ermitteln, warum das FMC laut Azure-Fluss nicht erreichbar war.