Azure Kochbuch

Kapitel 1. Sicherheit

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: [e-mail]

Daten Heutzutage kommt es häufig zu Datenschutzverletzungen. Hacker und böswillige Nutzer haben es auf die IT-Systeme von kleinen, mittleren und großen Unternehmen abgesehen. Diese Angriffe kosten jedes Jahr Millionen von Dollar, aber die Kosten sind nicht der einzige Schaden. Die angegriffenen Unternehmen sind tage-, wochen- oder sogar jahrelang in den Nachrichten, und ihr Ruf und ihr Kundenstamm können dauerhaft geschädigt werden. In den meisten Fällen folgen Gerichtsverfahren.

Du hast vielleicht den Eindruck, dass öffentliche Cloud-Dienste sehr sicher sind. Schließlich geben Unternehmen wie Microsoft Millionen von Dollar aus, um die Sicherheit ihrer Plattformen zu verbessern. Aber Anwendungen und Datensysteme, die in der öffentlichen Cloud von Microsoft (und auch in den Clouds anderer Anbieter) gehostet werden, sind nicht vor Cyberangriffen gefeit. Aufgrund des öffentlichen Charakters der Cloud sind sie sogar noch anfälliger für Datenschutzverletzungen.

Es ist wichtig zu verstehen, dass die Cloud-Sicherheit eine gemeinsame Verantwortung von Microsoft Azure und dir ist. Azure bietet physische Sicherheit für das Rechenzentrum, Richtlinien, Dokumentation und leistungsstarke Tools und Dienste, die dir helfen, deine Workloads zu schützen. Es liegt in deiner Verantwortung, die Ressourcensicherheit richtig zu konfigurieren. Azure Cosmos DB kann zum Beispiel so konfiguriert werden, dass es nur Datenverkehr aus einem bestimmten Netzwerk akzeptiert, aber standardmäßig sind alle Clients zugelassen, auch aus dem öffentlichen Internet.

Tipp

Cloud-Sicherheit ist ein sich ständig weiterentwickelndes Thema. Microsoft Azure führt ständig neue Sicherheitsfunktionen ein, um deine Workloads vor neuen Bedrohungen zu schützen. Microsoft pflegt die Dokumentation der bewährten Methoden und Muster für die Azure-Sicherheit, in der du die aktuellsten bewährten Methoden für die Sicherheit nachlesen kannst.

Wir haben die Sicherheit als Thema für das erste Kapitel dieses Buches gewählt, um diese wichtige Botschaft zu vermitteln: Sicherheit muss an erster Stelle stehen! Du solltest die Sicherheit im Blick haben, wenn du deine Cloud-Projekte konzipierst, implementierst und unterstützt. In diesem Kapitel stellen wir dir nützliche Rezepte vor, die dir zeigen, wie du die wichtigsten Azure-Dienste absicherst, und verwenden die Ergebnisse dieserRezepte im gesamten Buch.

Warnung

In diesem Kapitel behandeln wir wichtige Azure-Sicherheitsthemen. Es ist jedoch nicht möglich, alle Themen im Zusammenhang mit der Azure-Sicherheit zu behandeln. Die Azure-Dienste und -Funktionen entwickeln sich täglich weiter. Eine vollständige und aktuelle Liste findest du in der Microsoft-Dokumentation.

Konfiguration der Arbeitsstation

Bevor du mit den Rezepten in diesem Kapitel beginnst, musst du deine Workstation vorbereiten. Folge dem Abschnitt "Was du brauchst", um deinen Rechner für die Ausführung von Azure CLI-Befehlen einzurichten. Klone das GitHub-Repository des Buches mit dem folgenden Befehl:

git clone https://github.com/zaalion/AzureCookbook.git

Einen neuen Benutzer in deinem Azure-Konto anlegen

Problem

Das Benutzerkonto Besitzer (Administrator) hat viel mehr Berechtigungen, als für die täglichen Entwicklungsaufgaben benötigt werden. Du musst ein neues Benutzerkonto für einen Entwickler erstellen, das gerade genug Berechtigungen hat, um die zugewiesenen Aufgaben zu erledigen.

Lösung

Zuerst erstellst du unter einen neuen Benutzer in deinem Azure Active Directory(Azure AD). Weisen Sie diesem Benutzer dann die RBAC-Rolle ( Contributor - rollenbasierte Zugriffskontrolle) zu, damit genügend Berechtigungen zugewiesen werden, ohne dass dieser Benutzer die gleiche Berechtigungsstufe wie der Eigentümer erhält. Abbildung 1-1 zeigt ein Diagramm der Lösungsarchitektur.

Abbildung 1-1. Zuweisung einer integrierten Rolle zu Azure AD-Benutzern/-Gruppen

Steps

1. Melde dich bei deinem Azure-Abonnement in der Rolle des Eigentümers an. Weitere Informationen findest du unter "Allgemeine Anweisungen zur Einrichtung der Workstation".

2. Besuche die Seite Standardverzeichnis | Übersicht im Azure-Portal, um den Namen deiner primären Azure Active Directory-Tenant-Domäne zu finden, wie in Abbildung 1-2 dargestellt.

Abbildung 1-2. Suche nach der primären Domäne deines Azure AD-Mandanten

3. Erstelle einen neuen Benutzer in Azure AD. Ersetze <password> durch das gewünschte Passwort und <aad-tenant-name> mit dem Namen deiner Azure AD-Tenant-Domäne. Das kann der Standard-Domänenname sein, der auf onmicrosoft.com endet, oder eine benutzerdefinierte Domäne, die in deinem Azure Active Directory registriert ist (z. B. zaalion.com):

   password="<password>"
   
   az ad user create \
     --display-name developer \
     --password $password \
     --user-principal-name developer@<aad-tenant-name>

Warnung

Verwende ein sicheres Passwort mit Klein- und Großbuchstaben, Zahlen und Sonderzeichen. Die Wahl eines sicheren Passworts ist der erste und wichtigste Schritt, um deinAzure-Abonnement zu schützen.

4. Das Benutzerkonto, das du erstellt hast, hat keine Berechtigungen. Du kannst das ändern, indem du ihm eine Azure RBAC-Rolle zuweist. In diesem Rezept nehmen wir die integrierte Rolle Contributor, aber du kannst jede Rolle wählen, die deinen Bedürfnissen entspricht. Die RBAC-RolleContributor gewährt vollen Zugriff auf Ressourcen, erlaubt aber nicht die Zuweisung von Rollen in Azure RBAC oder die Verwaltung von Azure Blueprints-Zuweisungen. Du weist eine RBAC-Rolle einem Zuweiser über einen Bereich zu. In unserem Fall ist der Empfänger der Benutzer, den du gerade erstellt hast, der Rollenname ist Contributor und der Bereich ist die aktuelle Azure-Subscription. Speichere zunächst deine Abonnement-ID in einer Variablen:

   subscriptionId=$(az account show \
     --query "id" --output tsv)
   
   subscriptionScope="/subscriptions/"$subscriptionId

5. Verwende den folgenden CLI-Befehl, um dem Benutzerkonto developer@<aad-tenant-name> die Rolle Contributor zuzuweisen. Wenn du aufgefordert wirst, die Kontenerweiterung zu installieren, antworte mit J. Jetzt kannst du das neue Entwicklerkonto verwenden, um die Rezepte in diesem Buch auszuführen:

   MSYS_NO_PATHCONV=1 az role assignment create \
     --assignee "developer@<aad-tenant-name>" \
     --role "Contributor" \
     --scope $subscriptionScope

Tipp

Git Bash übersetzt Ressourcen-IDs automatisch in Windows-Pfade, was dazu führt, dass dieser Befehl fehlschlägt. Füge einfach MSYS_NO_PATHCONV=1 vor den Befehl, um dieses Verhalten vorübergehend zu deaktivieren. Weitere Informationen findest du in der Bash-Dokumentation.

6. Führe den folgenden Befehl aus, um die neue Rollenzuweisung zu überprüfen. In der Ausgabe suchst du das Feld roleDefinitionId. Sein Wert sollte mit /role​Def⁠ini⁠tions/b24988ac-6180-42a0-ab88-20f7382dd24c enden. Das ist die ID der Contributor-Rollendefinition:

   az role assignment list \
     --assignee developer@<aad-tenant-name>

Diskussion

Es gehört nicht zu den bewährten Methoden von , ein hochprivilegiertes Konto wie das des Eigentümers (Administrators) zu verwenden, um alltägliche Entwicklungs-, Überwachungs- und Testaufgaben durchzuführen. Ein Entwickler, der nur die Daten eines Cosmos DB-Containers lesen soll, braucht beispielsweise keine Berechtigung für andere Ressourcen im Abonnement.

Azure hat mehrere integrierte RBAC-Rollen für allgemeine und spezifische Dienste. Die RBAC-Rolle "Contributor" ermöglicht den Zugriff auf alle Azure-Dienste. Du kannst dienstspezifische Rollen verwenden, wenn dein Nutzer nur mit einem einzigen Dienst arbeiten muss. Zum Beispiel erlaubt die Rolle Cosmos DB Operator nur die Verwaltung einer Cosmos DB-Datenbank. In der Microsoft-Dokumentation findest du eine vollständige Liste der integrierten Rollen.

Warnung

Einem Benutzer eine höhere Zugriffsstufe als nötig zu gewähren, ist ein Rezept für ein Desaster. Du musst herausfinden, welche Aufgaben ein/e Benutzer/in ausführen muss, und ihm/ihr nur den erforderlichen Zugriff gewähren. Dies wird als Prinzip der geringsten Privilegien bezeichnet.

In diesem Rezept haben wir unserem Entwickler-Benutzerkonto die Rolle "Contributor" zugewiesen. Damit kann unser Benutzer alle Azure-Dienste außer RBAC-Rollen und die Zuweisung von Blueprints verwalten. Weitere Informationen findest du in der Dokumentation zur RBAC-Rolle Contributor. Wenn die in Azure eingebauten RBAC-Rollen nicht genau deinen Bedürfnissen entsprechen, kannst du benutzerdefinierte RBAC-Rollen erstellen und sie den Benutzern zuweisen. Wir werden uns das im nächsten Rezept ansehen.

Eine neue benutzerdefinierte Rolle für unseren Benutzer erstellen

Problem

Du musst einem Benutzer, einer Gruppe oder einem Azure AD Principal eine begrenzte Anzahl von Berechtigungen erteilen. Es gibt keine eingebaute Azure RBAC-Rolle, die genau diese Berechtigungen bietet.

Lösung

Erstelle zunächst eine benutzerdefinierte Azure-Rolle und weise die Rolle dann den Benutzern, Gruppen oder Prinzipalen zu (siehe Abbildung 1-3).

Abbildung 1-3. Zuweisung einer benutzerdefinierten Rolle zu einem Azure AD-Benutzer/einer Azure AD-Gruppe

Steps

1. Melde dich bei deinem Azure-Abonnement in der Rolle des Eigentümers an. Weitere Informationen findest du unter "Allgemeine Anweisungen zur Einrichtung der Workstation".

2. Notiere dir das Benutzerkonto, das du in "Erstellen eines neuen Benutzers in deinem Azure-Konto" erstellt hast . Später in diesem Rezept werden wir diesem Benutzer unsere eigene Rolle zuweisen.

3. Wenn du unter eine eigene Rolle definierst, musst du einen Bereich angeben. Die neue Rolle wird nur in den übergebenen Scopes verfügbar sein. Ein Bereich kann eine oder mehrere Azure-Abonnements oder Managementgruppen sein. Führe den folgenden Befehl aus, um deine aktuelle Abonnement-ID zu ermitteln:

   subscriptionId=$(az account show \
     --query "id" --output tsv)
   
   subscriptionScope="/subscriptions/"$subscriptionId
   
   echo $subscriptionScope

4. Wir brauchen eine benutzerdefinierte Azure-Rolle, mit der Nutzer Daten-Blobs inAzure-Speicherkonten lesen können. Erstelle eine JSON-Datei mit dem folgenden Inhalt, nenne die DateiCustomStorageDataReader.json und speichere sie auf deinem Rechner. Ersetze als nächstes <subscription-scope> durch den Wert der Variable $subscriptionScope aus dem vorherigen Schritt. Da wir nur Blobs lesen müssen, ist die einzige Aktion,die wirhinzufügen müssen, Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read. In der Microsoft-Dokumentation findest du eine vollständige Liste der Variablen Actions und DataActions, die du in deinen benutzerdefinierten Rollen verwenden kannst:

   {
     "Name": "Custom Storage Data Reader",
     "IsCustom": true,
     "Description": "Read access to Azure storage accounts",
     "DataActions": [
       "Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read"
     ],
     "AssignableScopes": [
       "<subscription-scope>"
     ]
   }

Tipp

Vergewissere dich, dass die Actions zum richtigen Abschnitt in der JSON-Datei hinzugefügt werden. Zu diesen Abschnitten gehören Actions, DataActions, Not​A⁠ctions und NotDataActions. Unter "Azure-Rollendefinitionen verstehen" findest du weitere Informationen zu den Rollenabschnitten.

5. Wir haben die Definition der benutzerdefinierten Rolle fertig, also können wir jetzt die benutzerdefinierte Rolle erstellen:

   az role definition create \
     --role-definition CustomStorageDataReader.json

6. Deine benutzerdefinierte RBAC-Rolle ist nun erstellt und kann Benutzern oder Gruppen auf die gleiche Weise zugewiesen werden wie die integrierten Rollen. In unserem Fall ist der Zugewiesene der Benutzer, den du zuvor erstellt hast, der Rollenname ist Custom Storage Data Reader und der Geltungsbereich ist das aktuelle Azure-Abonnement. Neben Nutzern und Gruppen kannst du Azure-Rollen auch anderen Azure AD-Prinzipalen zuweisen, z. B. verwalteten Identitäten und App-Registrierungen.

7. Verwende den folgenden CLI-Befehl, um dem Benutzerkonto des Entwicklers die Rolle Custom Storage Data Reader zuzuweisen:

   MSYS_NO_PATHCONV=1 az role assignment create \
     --assignee "developer@<aad-tenant-name>" \
     --role "Custom Storage Data Reader" \
     --scope $subscriptionScope

Der Entwickler-Benutzer hat jetzt Lesezugriff auf alle Blobs des Azure Storage Account innerhalb deines Abonnements.

Diskussion

Benutzerdefinierte Rollen sind ideal für Situationen, in denen du einem Benutzer genau die richtige Menge an Berechtigungen zuweisen musst. Mit benutzerdefinierten Rollen kann auch der Zugriff auf mehrere Dienste gewährt werden. Die JSON-Dateien zur Rollendefinition können in einem Versionskontrollsystem gespeichert und mithilfe von Azure CLI, Azure PowerShell oder sogar ARM-Vorlagen bereitgestellt werden. Du kannst einem Benutzer oder einer Gruppe mehrere RBAC-Rollen zuweisen. Unserem Testbenutzer wurden sowohl Contributor als auch Custom Storage Data Reader zugewiesen. In realen Szenarien musst du die Contributor-Rolle von deinem Benutzer entfernen, da sie im Vergleich zur Custom-Rolle viel mehr Berechtigungen verleiht.

Hinweis

Möglicherweise gibt es bereits eine eingebaute Rolle, die die Bedürfnisse des Benutzers erfüllt und nicht mehr Berechtigungen als nötig erteilt. Bevor du Zeit in die Erstellung einer benutzerdefinierten Rolle investierst, solltest du die Microsoft-Dokumentation für integrierte Rollen lesen.

Erlaubte Azure-Ressourcentypen in einer Subscription zuweisen

Problem

Du musst die Azure-Ressourcentypen einschränken, die Abonnementnutzer erstellen können.

Lösung

Weisen Sie die Azure-Richtlinie "Erlaubter Ressourcentyp" den Verwaltungsgruppen-, Abonnement- oder Ressourcengruppenbereichen zu, wobei die Liste der erlaubten Ressourcentypen als Richtlinienparameter dient. Ein Architekturdiagramm dieser Lösung ist in Abbildung 1-4 dargestellt.

Abbildung 1-4. Zuweisung einer Azure-Richtlinie zu einem Bereich

Steps

1. Melde dich bei deinem Azure-Abonnement in der Rolle des Eigentümers an. Weitere Informationen findest du unter "Allgemeine Anweisungen zur Einrichtung der Workstation".

2. Zuerst musst du die Azure-Richtlinien-ID für "Erlaubte Ressourcentypen" finden. Verwende den folgenden Befehl, um diese ID zu erhalten:

   policyName=$(az policy definition list \
     --query "[?displayName == 'Allowed resource types'].name" --output tsv)

3. Verwende den folgenden Befehl, um die Liste der verfügbaren Richtlinien-IDs und -namen zu erhalten:

   az policy definition list \
     --query "[].{Name: name, DisplayName: displayName}"

4. Wenn deine Richtliniendefinition Parameter hat, musst du sie bei der Zuweisung angeben. In unserem Fall müssen wir der Richtlinie mitteilen, welche Ressourcen wir in unserem Abonnement zulassen wollen. Erstelle eine JSON-Datei mit folgendem Inhalt und nenne sie allowedResourcesParams.json:

   {
     "listOfResourceTypesAllowed": {
       "value": [
           "Microsoft.Storage/storageAccounts"
       ]
     }
   }

5. Jetzt haben wir alles, was wir brauchen, um die Richtlinienzuweisung zu erstellen. Verwende den folgenden Befehl, um die Richtliniendefinition deinem Abonnement zuzuweisen. Der Einfachheit halber lassen wir in diesem Abonnement nur die Erstellung von Konten für die Speicherung in Azure zu. In den meisten Fällen musst du mehrere Ressourcen für deine Projekte zulassen:

   az policy assignment create \
     --name 'Allowed resource types in my subscription' \
     --enforcement-mode Default \
     --policy $policyName \
     --params allowedResourcesParams.json

Hinweis

Wir haben die Richtlinie --enforcement-mode auf Default gesetzt. Dadurch wird verhindert, dass neue Ressourcen erstellt werden, wenn sie nicht in derzulässigen Liste enthalten sind. Du kannst den Durchsetzungsmodus auch aufDoNotEnforce setzen. Dann können die Ressourcen erstellt werden, und die Nichteinhaltung der Richtlinie wird nur in den Protokollen und auf der Übersichtsseite der Richtlinie gemeldet.

6. Wenn du diese Richtlinienzuweisung beibehältst, können nur Azure-Speicherkonten für dein Abonnement bereitgestellt werden. Da wir in diesem Kochbuch mehrere andere Ressourcentypen bereitstellen müssen, löschen wir diese Richtlinienzuweisung jetzt:

   az policy assignment delete \
     --name 'Allowed resource types in my subscription'

Diskussion

Verwende Azure-Richtlinien, um deine Azure-Ressourcen zu verwalten und die Einhaltung von Richtlinien durchzusetzen. Angenommen, du möchtest deinem Team nur erlauben, Azure-Speicherkonten und Cosmos DB für das Entwicklungsabonnement einzusetzen. Du könntest dich darauf verlassen, dass dein Team diese Richtlinien befolgt, und hoffen, dass sie sich daran halten, oder du könntest sie mithilfe von Richtlinien durchsetzen. Letzteres ist der sicherere Ansatz.

Es gibt zahlreiche integrierte Richtlinien, die du den gewünschten Bereichen zuweisen kannst. Mit diesen Richtlinien kannst du die Bereitstellung bestimmter Ressourcentypen erlauben oder verweigern oder die Regionen einschränken, in denen Ressourcen bereitgestellt werden können.

Hinweis

Wenn du eine Durchsetzung brauchst, stelle sicher, dass der Wert --enforcement-mode auf Default und nicht auf DoNotEnforce gesetzt ist.

Mehrere integrierte Richtlinien wurden entwickelt, um die Sicherheit deines Azure-Abonnements zu verbessern. Du kannst die Definitionen und Namen der integrierten Richtlinien im Azure-Portal oder mit Tools wie Azure CLI finden. Azure bietet auch Richtlinien, die auf bestimmte Azure-Ressourcentypen abzielen. Die Richtlinie "Schlüssel für Speicherkonten dürfen nicht ablaufen" sorgt beispielsweise dafür, dass die Schlüssel für Speicherkonten nicht ablaufen, wenn sie zugewiesen werden. Weitere Details zu Richtlinien findest du in der Microsoft-Dokumentation.

Erlaubte Standorte für Azure-Ressourcen zuweisen

Problem

Du musst die Standorte (Regionen) einschränken, in denen Azure-Ressourcen bereitgestellt werden können.

Lösung

Weise der Verwaltungsgruppe, dem Abonnement oder der Ressourcengruppe die Richtlinie "Erlaubte Standorte" mit der Liste der erlaubten Azure-Regionen als Richtlinienparameter zu.

Steps

1. Melde dich bei deinem Azure-Abonnement in der Rolle des Eigentümers an. Weitere Informationen findest du unter "Allgemeine Anweisungen zur Einrichtung der Workstation".

2. Zuerst musst du die ID der Azure-Richtlinie "Erlaubte Standorte" finden. Verwende den folgenden Befehl, um diese ID zu ermitteln:

   policyName=$(az policy definition list \
     --query "[?displayName == 'Allowed locations'].name" --output tsv)

3. Wenn deine Richtliniendefinition Parameter hat, musst du sie bei der Zuweisung angeben. In unserem Fall müssen wir der Richtlinie mitteilen, welche Azure-Regionen wir in unserem Abonnement zulassen wollen. Erstelle eine JSON-Datei mit dem folgenden Inhalt und nenne sie allowedLocationParams.json:

   {
     "listOfAllowedLocations": {
       "value": [
           "eastus",
           "westus"
       ]
     }
   }

4. Verwende den folgenden Befehl, um die Richtliniendefinition dem aktivenAbonnement zuzuweisen:

   az policy assignment create \
     --name 'Allowed regions for my resources' \
     --enforcement-mode Default \
     --policy $policyName \
     --params allowedLocationParams.json

5. Du kannst die Parameterdatei allowedLocationsParams.json ändern, um deine gewünschten Standorte an die Richtlinienzuweisung zu übergeben. Verwende den folgenden CLI-Befehl, um die Liste der verfügbaren Standorte abzurufen:

   az account list-locations --query "[].name"

Hinweis

Verwende den Parameter --scope mit dem az policy assignmentcreate um den Geltungsbereich für die Richtlinienzuweisung zu definieren. Der Geltungsbereich kann eine oder mehrere Verwaltungsgruppen, Abonnements, Ressourcengruppen oder eine Kombination aus diesen sein. Wenn nichts angegeben wird, ist der Standardbereich das aktuell aktive Abonnement.

6. Du kannst den folgenden Befehl verwenden, um diese Richtlinienzuweisung zu löschen:

   az policy assignment delete \
     --name 'Allowed regions for my resources'

Du hast unserem Abonnement erfolgreich die Richtliniendefinition "Erlaubte Standorte" zugewiesen. Von nun an können die Ressourcen nur noch in den Azure-Regionen eastus und westus bereitgestellt werden.

Diskussion

In vielen Ländern und Regionen gelten Gesetze zur Datenresidenz. Das bedeutet, dass die Nutzerdaten ihren geografischen Zuständigkeitsbereich nicht verlassen dürfen. Ein Beispiel für ein solches Gesetz ist die Allgemeine Datenschutzverordnung der EU (GDPR), die es verbietet, dass die Daten von EU-Bürgern die Grenzen der EU verlassen. Die Azure-Richtlinie "Erlaubte Standorte" ist das perfekte Instrument, um die Einhaltung von Standards wie der GDPR durchzusetzen.

Verbindung zu einer privaten virtuellen Azure-Maschine mit Azure Bastion

Problem

Du musst dich per RDP oder SSH mit einer virtuellen Azure-Maschine verbinden. Deine virtuelle Azure-Maschine (VM) ist eine private VM, das heißt, sie hat keine öffentliche IP-Adresse.

Lösung

Stelle eine Azure Bastion-Hostressource im selben virtuellen Netzwerk (VNet) wie deine Azure-VM bereit. Dann kannst du SSH oder RDP verwenden, um auf deine Azure VM zuzugreifen. Eine private Azure-VM hat keine öffentliche IP-Adresse und ist damit für das öffentliche Internet unsichtbar. Siehe das Diagramm der Lösungsarchitektur in Abbildung 1-5.

Abbildung 1-5. Verwendung von Azure Bastion zur Verbindung mit einer privaten Azure-VM

Steps

1. Melde dich in der Rolle des Eigentümers bei deinem Azure-Abonnement an und erstelle eine neue Ressourcengruppe für dieses Rezept. Weitere Informationen findest du unter "Allgemeine Anweisungen zur Einrichtung von Workstations".

2. Erstellen wir nun eine neue Azure VM. Jede Azure VM wird in einem Azure VNet bereitgestellt. Der folgende Befehl richteteine neue Azure-VM ein und platziert sie in einem neuen VNet mit dem Adressraum 10.0.0.0/16. Wenn du für--public-ip-address einen leeren String angibst, erstellst du eine private Azure-VM ohne öffentliche IP-Adresse. Der Parameter --nsg-rule SSH konfiguriert die SSH-Konnektivität für deine neue VM:

   az vm create --name MyLinuxVM01 \
     --resource-group $rgName \
     --image UbuntuLTS \
     --vnet-address-prefix 10.0.0.0/16 \
     --admin-username linuxadmin \
     --generate-ssh-keys \
     --authentication-type ssh \
     --public-ip-address "" \
     --nsg-rule SSH \
     --nsg "MyLinuxVM01-NSG"

Hinweis

Es wird empfohlen, SSH-Schlüssel für die Authentifizierung bei Linux-VMs zu verwenden. Du kannst auch eine Kombination aus Benutzernamen und Passwort verwenden. Durch die Übergabe von--authentication-type ssh hast du diese VM so konfiguriert, dass sie nur eine Authentifizierung mit SSH-Schlüsseln zulässt. Weitere Informationen findest du in der CLI-Dokumentation und unter "Verbinden mit einer Linux-VM".

3. Der vorherige Befehl hat ein neues SSH-Schlüsselpaar (privater und öffentlicher Schlüssel) erzeugt und auf deinem Rechner gespeichert. Den Pfad zum privaten Schlüssel findest du in der Befehlsausgabe, zum Beispiel /home/reza/.ssh/id_rsa, wie in Abbildung 1-6 gezeigt. Notiere dir den Dateipfad des privaten Schlüssels. Du musst diesen Schlüssel in den Bastion-Dienst hochladen, um dich an deiner neuen VM anzumelden.

Abbildung 1-6. Speichern des SSH-Schlüssels auf deinem lokalen Rechner

4. Verwende den folgenden Befehl, um die Details des neuen virtuellen Netzwerks abzurufen, das als Teil deiner VM-Provisionierung erstellt wurde. Du brauchst diesen Namen, um deinen neuen Azure Bastion Host in den nächsten Schritten zu konfigurieren:

   vnetName=$(az network vnet list \
     --resource-group $rgName \
     --query "[].name" --output tsv)

5. Aus Sicherheitsgründen hat die Azure-VM, die wir erstellt haben, keine öffentliche IP-Adresse. Eine Möglichkeit, sich mit dieser VM zu verbinden, ist die Nutzung von Azure Bastion. Dieser Dienst ermöglicht sowohl SSH- als auch RDP-Verbindungen. Bevor du einen Azure Bastion-Host erstellst, musst du eine öffentliche IP-Ressource und ein neues Subnetz im VNet namens AzureBastionSubnet erstellen. Diese IP wird dem Bastion-Host zugewiesen - nicht der Azure-VM:

   ipName="BastionPublicIP01"
   
   az network public-ip create \
     --resource-group $rgName \
     --name $ipName \
     --sku Standard

6. Erstelle nun das neue Subnetz AzureBastionSubnet, indem du den folgenden Befehl ausführst. Azure Bastion wird in diesem Subnetz eingesetzt:

   az network vnet subnet create \
     --resource-group $rgName \
     --vnet-name $vnetName \
     --name 'AzureBastionSubnet'  \
     --address-prefixes 10.0.1.0/24

Tipp

Der Subnetzname muss genau AzureBastionSubnet lauten; andernfalls gibt der CLI-Befehl bastion create einen Validierungsfehler zurück.

7. Jetzt kannst du mit dem folgenden Befehl eine Azure Bastion Ressource erstellen. Vergewissere dich, dass die Variable $region ausgefüllt ist. Weitere Informationen findest du unter "Allgemeine Anweisungen zur Einrichtung der Workstation". Wenn du aufgefordert wirst, die Bastion-Erweiterung zu installieren, antworte mit Y:

   az network bastion create \
     --location $region \
     --name MyBastionHost01 \
     --public-ip-address $ipName \
     --resource-group $rgName \
     --vnet-name $vnetName

Hinweis

Die Bereitstellung von Azure Bastion kann bis zu 10 Minuten dauern.

8. Warte, bis der vorangegangene Befehl erfolgreich war. Jetzt kannst du dich über den Bastion-Host mit der VM verbinden. Melde dich im Azure-Portal an und finde deine neue virtuelle Maschine. Klicke sie an und wähle im Menü oben links Verbinden > Bastion, wie in Abbildung 1-7 dargestellt.

9. Gib den Benutzernamen ein. Als Authentifizierungstyp wählst du SSH Private Key from Local File und wählst deine private SSH-Schlüsseldatei. Klicke dann auf die Schaltfläche Verbinden, wie in Abbildung 1-8 gezeigt.

Abbildung 1-7. Auswahl von Bastion als Verbindungsmethode

Abbildung 1-8. Eingeben des VM-Benutzernamens und Hochladen des SSH-Schlüssels

10. Du solltest die Eingabeaufforderung für Linux sehen, wie in Abbildung 1-9 dargestellt.

Abbildung 1-9. Anmeldung bei der Azure VM mit Azure Bastion

11. Führe den folgenden Befehl aus, um die Ressourcen zu löschen, die du in diesem Rezept erstellt hast:

    az group delete --name $rgName

Warnung

Azure Bastion ist ein kostenpflichtiger Dienst. Stelle sicher, dass du den Befehl in diesem Schritt ausführst, um die VM, den Bastion-Host und ihreAbhängigkeiten zu löschen.

In diesem Rezept hast du dich mit einer privaten VM über einen Azure Bastion Host verbunden.

Diskussion

Azure Bastion fungiert als verwalteter Jump Server, Jump Box oder Jump Host. Du verwendest ihn, um private Azure-VMs zu verwalten. Bevor der Bastion-Dienst eingeführt wurde, mussten Azure-Administratoren ihre eigenen Jump-Box-Maschinen erstellen oder die Azure-VM sogar über eine öffentliche IP-Adresse dem Internet aussetzen. Funktionen wie der JIT-Zugang oder die Azure-Firewall können verwendet werden, um die Sicherheit der Verbindung zu verbessern, aber eine VM über eine öffentliche IP-Adresse auszusetzen, ist nie eine gute Idee.

Hinweis

Du kannst dich bei Azure Linux VMs entweder mit Passwörtern oder SSH-Schlüsseln authentifizieren. Azure Bastion unterstützt auch die Verwendung von SSH-Schlüsseln mit den Linux-VMs.

Schutz von Azure VM-Festplatten mit Azure Disk Encryption

Problem

Du musst deine Azure VM-Festplatten mit BitLocker oder dm-crypt verschlüsseln, um deine Daten zu schützen oder die Sicherheits- und Compliance-Standards deines Unternehmens zu erfüllen.

Lösung

Erstelle einen Verschlüsselungsschlüssel in Azure Key Vault und verwende ihn, um die BitLocker (Windows VM) oder dm-crypt (Linux VM) Verschlüsselung für deine Azure VMs zu konfigurieren (siehe Abbildung 1-10).

Abbildung 1-10. Verwendung von Azure Disk Encryption zum Schutz einer Azure-VM

Steps

1. Melde dich bei deinem Azure-Abonnement in der Rolle des Eigentümers an und erstelle eine neue Ressourcengruppe für dieses Rezept. Weitere Informationen findest du unter "Allgemeine Anweisungen zur Einrichtung von Workstations".

2. Erstelle eine neue Windows-VM mit dem folgenden CLI-Befehl. Ersetze <vm-password> durch ein sicheres Passwort:

   vmName="MyWinVM01"
   
   az vm create \
       --resource-group $rgName \
       --name $vmName \
       --image win2016datacenter \
       --admin-username cookbookuser \
       --admin-password <vm-password>

3. Du brauchst eine Azure Key Vault Ressource, in der du deinen Festplattenverschlüsselungsschlüssel speichern kannst. Du kannst eine Azure Key Vault Ressource mit dem folgenden CLI-Befehl erstellen. Der--enabled-for-disk-encryption Parameter macht diesen Key Vault für Azure VMs zugänglich. Ersetze <key-vault-name> durch einen eindeutigen Namen für deine neue Azure Key Vault Ressource:

   kvName="<key-vault-name>"
   
   az keyvault create \
     --name $kvName \
     --resource-group $rgName \
     --location $region \
     --enabled-for-disk-encryption

4. Jetzt sind die Voraussetzungen geschaffen, um Azure Disk Encryption für unsere Windows-VM zu aktivieren:

   az vm encryption enable \
     --resource-group $rgName \
     --name $vmName \
     --disk-encryption-keyvault $kvName

5. Du kannst überprüfen, ob Azure Disk Encryption aktiviert ist, indem du dich auf dem Rechner anmeldest und den BitLocker-Status überprüfst oder indem du den folgenden CLI-Befehl verwendest:

   az vm encryption show \
     --name $vmName \
     --resource-group $rgName

6. Führe den folgenden Befehl aus, um die Ressourcen zu löschen, die du in diesem Rezept erstellt hast:

   az group delete --name $rgName

Wir haben Azure Disk Encryption erfolgreich für unsere Windows-VM mit Azure Key Vault und BitLocker aktiviert. Azure Disk Encryption hat automatisch ein neues Geheimnis im Key Vault erstellt, um den Festplattenverschlüsselungsschlüssel zu speichern. Diese Verschlüsselung ist auch für Linux-VMs verfügbar (über dm-crypt). Weitere Einzelheiten findest du in der Microsoft-Dokumentation.

Diskussion

In diesem Szenario haben wir Azure Disk Encryption für eine Azure Windows VM aktiviert. Diese Verschlüsselung erfolgt auf der Ebene des Windows-Betriebssystems mit der bekannten BitLocker-Technologie.

Azure VM-Festplatten werden als Blob-Objekte in Azure Storage gespeichert. Microsoft Azure bietet noch eine weitere Verschlüsselungsart für Azure-VMs an. Diese Verschlüsselung wird Server-seitige Verschlüsselung(SSE) genannt und findet auf der Ebene der Azure Speicherung statt. Du kannst sowohl Azure Disk Encryption als auch SSE aktivieren, um den Schutz zu erhöhen.

Die Verschlüsselung deiner Azure-VM-Betriebssysteme und Datenfestplatten schützt deine Daten in dem höchst unwahrscheinlichen Fall, dass die Azure-Rechenzentren kompromittiert werden. Darüber hinaus verlangen viele Organisationen die Verschlüsselung von VM-Festplatten, um ihre Compliance- und Sicherheitsverpflichtungen zu erfüllen.

Blockieren des anonymen Zugriffs auf Azure Storage Blobs

Problem

Du musst verhindern, dass Entwickler/innen versehentlich anonymen öffentlichen Zugriff auf Azure Storage Blobs und Container gewähren.

Lösung

Setze das --allow-blob-public-access Flag programmatisch auf false oder setze das Feld "Allow Blob public access" im Azure-Portal auf Disabled (siehe Abbildung 1-11). Diese Einstellung kann sowohl für neue als auch für bestehende Speicherung-Konten vorgenommen werden.

Abbildung 1-11. Deaktivieren des öffentlichen BLOB-Zugriffs im Azure-Portal

Steps

1. Melde dich in der Rolle des Eigentümers bei deinem Azure-Abonnement an und erstelle eine neue Ressourcengruppe für dieses Rezept. Weitere Informationen findest du unter "Allgemeine Anweisungen zur Einrichtung von Workstations".

2. Erstelle ein neues Konto für die Speicherung in Azure. Ersetze <storage-account-name> durch den gewünschten Namen. In der Dokumentation zur Benennung von Speicherkonten findest du Regeln und Einschränkungen für die Benennung. Setze --allow-blob-public-access auf false, damit Entwickler keinen anonymen Blob- und Containerzugriff zulassen können:

   storageName="<storage-account-name>"
   
   az storage account create \
     --name $storageName \
     --resource-group $rgName \
     --location $region \
     --sku Standard_LRS \
     --allow-blob-public-access false

3. Du kannst den folgenden CLI-Befehl verwenden, um dieselbe Sicherung für ein bestehendes Speicherkonto zu konfigurieren:

   az storage account update \
     --name $storageName \
     --resource-group $rgName \
     --allow-blob-public-access false

4. Führe den folgenden Befehl aus, um die Ressourcen zu löschen, die du in diesem Rezept erstellt hast:

   az group delete --name $rgName

Weitere Informationen findest du unter "Anonymen öffentlichen Lesezugriff für Container und Blobs konfigurieren".

Diskussion

Wenn ein Container oder Blob eines Speicherkontos für den öffentlichen Zugriff konfiguriert ist, kann jeder Benutzer im Internet ohne Anmeldeinformationen darauf zugreifen. Die Deaktivierung von --allow-blob-public-access verhindert, dass Entwickler versehentlich den Schutz von Speicherkonto-Blobs und Containern aufheben.

Wenn du das --allow-blob-public-access Flag auf true setzt, wird kein anonymer Zugriff auf Container und Blobs ermöglicht. Es lässt Entwicklern die Möglichkeit offen, diesen Zugang versehentlich oder absichtlich zu ermöglichen.

In einigen Fällen kann es erforderlich sein, dass du deine Blobs öffentlich zugänglich machen musst (z. B. um Bilder für eine öffentliche Website zu hosten). In solchen Fällen empfiehlt es sich, ein separates Speicherkonto zu erstellen, das nur für den öffentlichen Zugriff bestimmt ist. Verwende niemals dasselbe Speicherkonto für eine Mischung aus öffentlichen und privaten Blobs.

Tipp

Du kannst die Azure-Richtlinie "Storage account public access should be disallowed" zuweisen, um die Deaktivierung des anonymen öffentlichen Zugriffs zu regeln.

Konfigurieren eines Azure-Speicherkontos zur ausschließlichen Verwendung der Azure AD-Autorisierung

Problem

Du möchtest verhindern, dass ein Azure-Speicherkonto Speicherschlüssel und SAS-Tokens zur Autorisierung akzeptiert. Auf diese Weise bleibt den Nutzern die sicherere Azure AD-Authentifizierungs-/Autorisierungsmethode.

Lösung

Setze das --allow-shared-key-access Flag programmatisch auf false oder setze das Feld "Zugriff auf Speicherkontenschlüssel zulassen" im Azure-Portal auf Deaktiviert (siehe Abbildung 1-12). Dies kann sowohl für neue als auch für bestehende Speicherkonten konfiguriert werden.

Abbildung 1-12. Einstellung von "Zugriff auf Speicherkontenschlüssel zulassen" im Azure-Portal auf Deaktiviert

Steps

1. Melde dich in der Rolle des Eigentümers bei deinem Azure-Abonnement an und erstelle eine neue Ressourcengruppe für dieses Rezept. Weitere Informationen findest du unter "Allgemeine Anweisungen zur Einrichtung von Workstations".

2. Wenn du ein bestehendes Speicherkonto hast, fahre mit dem nächsten Schritt fort. Wenn nicht, verwende diesen Befehl, um ein neues Konto für die Speicherung zu erstellen. Ersetze <storage-account-name> durch den gewünschten Namen und setze das --allow-shared-key-access Flag auf false:

   storageName="<storage-account-name>"
   
   az storage account create \
     --name $storageName \
     --resource-group $rgName \
     --location $region \
     --sku Standard_LRS \
     --allow-shared-key-access false

3. Du kannst den folgenden CLI-Befehl verwenden, um diese Einstellung für ein bestehendes Speicherkonto zu konfigurieren:

   az storage account update \
     --name $storageName \
     --resource-group $rgName \
     --allow-shared-key-access false

4. Führe den folgenden Befehl aus, um die Ressourcen zu löschen, die du in diesem Rezept erstellt hast:

   az group delete --name $rgName

Du hast für dein Speicherkonto die Option Zugriff auf den Schlüssel des Speicherkontos zulassen deaktiviert. Das bedeutet, dass Clients wie Azure Functions, App Services usw. nur mit Azure AD-Authentifizierung/Autorisierung auf dieses Speicherkonto zugreifen können. Alle Anfragen, die Speicherkontoschlüssel oder SAS-Tokens verwenden, werden abgelehnt.

Diskussion

Azure-Speicherkonten unterstützen mehrere Autorisierungsmethoden, die sich in zwei Gruppen unterteilen lassen:

• Schlüsselbasierter Zugang, z. B. über die Schlüssel von Speicherkonten oder SAS-Tokens

• Azure Active Directory-Zugang über einen Azure AD-Prinzipal, -Benutzer oder -Gruppe und eine RBAC-Rolle

Einige Organisationen bevorzugen die zweite Methode, da kein Passwort, Kontoschlüssel oder SAS-Token gespeichert oder verwaltet werden muss, was eine sicherere Lösung darstellt.

In der Azure-Dokumentation findest du weitere Informationen zur Authentifizierung und Autorisierung von Speicherkonten.

Tipp

Du kannst die Azure-Richtlinie "Storage accounts should prevent shared key access" (Speicherkonten sollten den Zugriff auf gemeinsame Schlüssel verhindern) zuweisen, um zu steuern, dass Speicherkonten nur Azure AD-basierte Anfragen akzeptieren. In der Azure-Dokumentation erfährst du mehr über diese Richtlinie.

Speichern und Abrufen von Geheimnissen aus Azure Key Vault

Problem

Du musst Passwörter, Datenbankverbindungen und andere sensible Daten sicher in Azure speichern und abrufen können.

Lösung

Speichere deine Geheimnisse, Schlüssel und Zertifikate im Azure Key Vault Service. Gib den Clients Zugang, damit sie bei Bedarf die Geheimnisse aus dem Key Vault lesen können. Der Ablauf ist in Abbildung 1-13 dargestellt.

Abbildung 1-13. Speicherung von und Zugriff auf Schlüssel, Geheimnisse und Zertifikate in Azure Key Vault

Steps

1. Melde dich bei deinem Azure-Abonnement in der Rolle des Eigentümers an und erstelle eine neue Ressourcengruppe für dieses Rezept. Weitere Informationen findest du unter "Allgemeine Anweisungen zur Einrichtung von Workstations".

2. Erstelle zunächst mit diesem CLI-Befehl einen neuen Azure Key Vault-Dienst. Ersetze <key-vault-name> durch einen gültigen, weltweit eindeutigen Namen:

   kvName="<key-vault-name>"
   
   az keyvault create --name $kvName \
     --resource-group $rgName \
     --location $region

3. Verwende nun diesen Befehl, um ein Geheimnis im Key Vault zu erstellen:

   az keyvault secret set \
     --name MyDatabasePassword \
     --vault-name $kvName \
     --value P@$$w0rd

4. Dein Geheimnis ist jetzt im Azure Key Vault gespeichert. Nur Clients mit der Zugriffsrichtlinie "Geheimnis abrufen" können dieses Geheimnis aus dem Tresor lesen. Diese Berechtigung kann für verwaltete Identitäten, Azure AD Service Principals oder auch für Benutzer und Gruppen erteilt werden. Du hast dich bereits als Besitzer des CLI-Kontos angemeldet, also solltest du in der Lage sein, den Wert des Geheimnisses zu lesen. Achte auf die Eigenschaft value in der Befehlsausgabe:

   az keyvault secret show \
     --name MyDatabasePassword \
     --vault-name $kvName

5. Führe den folgenden Befehl aus, um die Ressourcen zu löschen, die du in diesem Rezept erstellt hast:

   az group delete --name $rgName

Diskussion

Azure Key Vault ist der Tresor von Azure, in dem sensible Daten gespeichert werden. Drei Arten von Entitäten können in einem Tresor gespeichert werden:

Geheimnisse

Alle benutzerdefinierten Werte, die du schützen musst, wie z. B. Datenbankverbindungszeichenfolgen oder Kontopasswörter

Schlüssel

Verschlüsselungsschlüssel, die von anderen Azure-Diensten zur Verschlüsselung von Festplatten, Datenbanken oder Speicherungen verwendet werden

Bescheinigungen

X.509-Zertifikate, die zur Sicherung der Kommunikation zwischen anderen Diensten verwendet werden

Auf Entitäten, die im Key Vault gespeichert sind, können andere Azure-Dienste zugreifen, vorausgesetzt, der Client hat den richtigen Zugriff auf den Tresor. Dieser Zugriff kann entweder über die Azure Key Vault Access Policy oder die Azure Key Vault RBAC definiert werden.

Hier sind ein paar dieser Kundendienste und wofür sie verwendet werden:

• Azure Function Apps und App Services, damit Geheimnisse wie Datenbankverbindungszeichenfolgen zur Laufzeit aus dem Key Vault geholt werden können

• Azure Cosmos DB oder Azure Storage, damit vom Kunden verwaltete Schlüssel für die Verschlüsselung für die Cosmos DB-Verschlüsselung im Ruhezustand verwendet werden können

• Azure VMs, so dass Verschlüsselungsschlüssel aus dem Tresor zur Verschlüsselung von VM-verwalteten Festplatten verwendet werden können

• Azure Application Gateway, so dass SSL-Zertifikate im Key Vault zur Sicherung der HTTPS-Kommunikation verwendet werden können

Es gibt noch einige andere Anwendungsfälle für Azure Key Vault, die wir im Laufe dieses Buches besprechen werden.

Aktivieren der Web Application Firewall (WAF) mit Azure Application Gateway

Problem

Du musst deine Azure-Webanwendungen vor gängigen Webangriffen wie SQL-Injection schützen.

Lösung

Setze eine Azure Application Gateway-Ressource vor deiner Webanwendung ein und aktiviere die WAF, wie in Abbildung 1-14 dargestellt.

Abbildung 1-14. Schutz deiner Webanwendungen mit Azure Application Gateway WAF

Hinweis

WAF ist eine der Funktionen von Azure Application Gateway. Azure Application Gateway ist ein Web-Load-Balancer mit einer Vielzahl von Funktionen. Zum Einrichten eines Azure Application Gateways gehört das Erstellen von HTTP-Listenern, Routing-Regeln usw. Weitere Informationen findest du in der Application Gateway CLI-Dokumentation.

Steps

1. Melde dich bei deinem Azure-Abonnement in der Rolle des Eigentümers an und erstelle eine neue Ressourcengruppe für dieses Rezept. Weitere Informationen findest du unter "Allgemeine Anweisungen zur Einrichtung von Workstations".

2. Erstelle zunächst einen einfachen App Service-Plan und eine Azure-Webanwendung darin. Dein Ziel ist es, diese Webanwendung vor gängigen Webangriffen zu schützen. Ersetze <web-app-name> durch den gewünschten Namen:

   appName="<web-app-name>"
   planName=$appName"-plan"
   
   az appservice plan create \
     --resource-group $rgName \
     --name $planName
   
   az webapp create \
     --resource-group $rgName \
     --plan $planName \
     --name $appName

3. Wenn du die Webanwendung erstellt hast, kannst du mit diesem Befehl ihre URL in einer Variablen speichern. Wir werden diese Variable bei der Konfiguration des Application Gateway verwenden:

   appURL=$(az webapp show \
     --name $appName \
     --resource-group $rgName \
     --query "defaultHostName" \
     --output tsv)

4. Das Azure Application Gateway wird in einem Azure VNet eingesetzt. Verwende also zunächst diesen Befehl, um ein neues Azure VNet mit einem Standardsubnetz zu erstellen:

   vnetName="AppGWVnet"
   
   az network vnet create \
     --resource-group $rgName \
     --name $vnetName \
     --address-prefix 10.0.0.0/16 \
     --subnet-name Default \
     --subnet-prefix 10.0.0.0/24

5. Da deine Azure App Service-Webanwendung über das neue Azure Application Gateway zugänglich sein wird, musst du eine neue öffentliche IP-Adresse erstellen, die dem Application Gateway zugewiesen wird. Verwende den folgenden Befehl, um die öffentliche IP-Adresse bereitzustellen:

   gwIPName="appgatewayPublicIP"
   
   az network public-ip create \
     --resource-group $rgName \
     --name $gwIPName \
     --sku Standard

6. Web Application Firewall-Richtlinien enthalten alle WAF-Einstellungen und -Konfigurationen des Application Gateway, einschließlich verwalteter Sicherheitsregeln, Ausnahmen und benutzerdefinierter Regeln. Verwenden wir den folgenden Befehl, um eine neue WAF-Richtlinienressource mit den Standardeinstellungen zu erstellen:

   wafPolicyName="appgatewayWAFPolicy"
   
   az network application-gateway waf-policy create \
     --name $wafPolicyName \
     --resource-group $rgName

7. Du hast alle notwendigen Ressourcen, um ein neues Azure Application Gateway zu erstellen. Stelle sicher, dass du die SKUs WAF_Medium, WAF_Large oder WAF_v2 einsetzt. Die WAF_v2 SKU ist die neueste Version der WAF - weitere Informationen findest du in der Dokumentation der WAF SKUs. Ersetze <app-gateway-name> durch den gewünschten Namen:

   appGWName="<app-gateway-name>"
   
   az network application-gateway create \
     --resource-group $rgName \
     --name $appGWName \
     --capacity 1 \
     --sku WAF_v2 \
     --vnet-name $vnetName \
     --subnet Default \
     --servers $appURL \
     --public-ip-address $ipName \
     --priority 1001 \
     --waf-policy $policyName

Hinweis

Eine Azure Application Gateway-Bereitstellung kann bis zu 15 Minuten dauern.

8. Du hast erfolgreich ein neues WAF-aktiviertes Azure Application Gateway bereitgestellt. Konfiguriere nun deine Webanwendung so, dass sie nur Datenverkehr aus dem Application Gateway-Subnetz akzeptiert, damit Endnutzer nicht mehr direkt auf die App Service-Webanwendung zugreifen können. Eine Schritt-für-Schritt-Anleitung findest du unter "Beschränkung des Netzwerkzugriffs auf einen Azure App Service". Der Zugriff auf deine Webanwendung über Azure Application Gateway (mit WAF) schützt sie vor gängigen Webangriffen wie SQL-Injection. Führe den folgenden Befehl aus, um die öffentliche IP-Adresse für dein Application Gateway zu erhalten. Diese IP-Adresse (sowie benutzerdefinierte Domainnamen) kann für den Zugriff auf deine Webanwendung über Azure Application Gateway verwendet werden:

   IPAddress=$(az network public-ip show \
     --resource-group $rgName \
     --name $gwIPName \
     --query ipAddress \
     --output tsv)
   
     echo $IPAddress

Hinweis

Bevor du über Azure Application Gateway auf deinen App-Dienst zugreifen kannst, müssen HTTP-Listener, Health Probes, Routing-Regeln und Backends richtig konfiguriert sein. Weitere Informationen findest du in der Azure Application Gateway Dokumentation und in der Konfiguration der HTTP-Einstellungen des Application Gateway.

9. Führe den folgenden Befehl aus, um die Ressourcen zu löschen, die du in diesem Rezept erstellt hast:

   az group delete --name $rgName

Diskussion

Zum Zeitpunkt des Verfassens dieses Buches unterstützen zwei Azure-Dienste die WAF-Funktion:

• Azure Application Gateway für Backends in derselben Azure-Region

• Azure Front Door für Backends in verschiedenen Regionen

WAF schützt deine Webanwendungen vor gängigen Webangriffen wie z. B.:

• SQL-Einschleusung

• Cross-Site-Scripting

• Befehlsinjektion

• HTTP-Anfrage-Schmuggel

• Aufteilung der HTTP-Antwort

• Ferneinbindung von Dateien

• Verstöße gegen das HTTP-Protokoll

Eine vollständige Liste der unterstützten Funktionen findest du in der Dokumentation der WAF-Funktionen.