mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-03-23 10:14:28 -07:00
Translated ['', 'src/pentesting-cloud/azure-security/az-services/vms/az-
This commit is contained in:
Translator
@@ -1,26 +1,26 @@
|
||||
# Az - Azure Network
|
||||
# Az - Azure-Netzwerk
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Grundinformationen
|
||||
## Grundlegende Informationen
|
||||
|
||||
Azure bietet **virtuelle Netzwerke (VNet)**, die es Benutzern ermöglichen, **isolierte** **Netzwerke** innerhalb der Azure-Cloud zu erstellen. Innerhalb dieser VNets können Ressourcen wie virtuelle Maschinen, Anwendungen, Datenbanken... sicher gehostet und verwaltet werden. Das Netzwerk in Azure unterstützt sowohl die Kommunikation innerhalb der Cloud (zwischen Azure-Diensten) als auch die Verbindung zu externen Netzwerken und dem Internet.\
|
||||
Darüber hinaus ist es möglich, VNets mit anderen VNets und mit lokalen Netzwerken zu **verbinden**.
|
||||
Azure bietet **virtual networks (VNet)**, die es Benutzern ermöglichen, **isolierte** **Netzwerke** innerhalb der Azure-Cloud zu erstellen. Innerhalb dieser VNets können Ressourcen wie virtuelle Maschinen, Anwendungen, Datenbanken... sicher gehostet und verwaltet werden. Das Networking in Azure unterstützt sowohl die Kommunikation innerhalb der Cloud (zwischen Azure-Diensten) als auch die Verbindung zu externen Netzwerken und dem Internet.\
|
||||
Außerdem ist es möglich, VNets mit anderen VNets und mit lokalen Netzwerken zu **verbinden**.
|
||||
|
||||
## Virtuelles Netzwerk (VNET) & Subnetze
|
||||
## Virtuelles Netzwerk (VNet) & Subnetze
|
||||
|
||||
Ein Azure Virtual Network (VNet) ist eine Darstellung Ihres eigenen Netzwerks in der Cloud, das **logische Isolation** innerhalb der Azure-Umgebung bietet, die Ihrer Abonnements zugeordnet ist. VNets ermöglichen es Ihnen, virtuelle private Netzwerke (VPNs) in Azure bereitzustellen und zu verwalten, die Ressourcen wie virtuelle Maschinen (VMs), Datenbanken und Anwendungsdienste hosten. Sie bieten **vollständige Kontrolle über Netzwerkeinstellungen**, einschließlich IP-Adressbereiche, Erstellung von Subnetzen, Routentabellen und Netzwerk-Gateways.
|
||||
Ein Azure Virtual Network (VNet) ist die Darstellung Ihres eigenen Netzwerks in der Cloud und bietet **logische Isolation** innerhalb der Azure-Umgebung, die Ihrem Abonnement zugeordnet ist. VNets ermöglichen es Ihnen, virtuelle private Netzwerke (VPNs) in Azure bereitzustellen und zu verwalten sowie Ressourcen wie Virtual Machines (VMs), Datenbanken und Anwendungsdienste zu hosten. Sie bieten **volle Kontrolle über Netzwerkeinstellungen**, einschließlich IP-Adressbereichen, Erstellung von Subnetzen, Routentabellen und Netzwerkgateways.
|
||||
|
||||
**Subnetze** sind Unterteilungen innerhalb eines VNet, die durch spezifische **IP-Adressbereiche** definiert sind. Durch die Segmentierung eines VNet in mehrere Subnetze können Sie Ressourcen gemäß Ihrer Netzwerkarchitektur organisieren und sichern.\
|
||||
Standardmäßig können alle Subnetze innerhalb des gleichen Azure Virtual Network (VNet) **miteinander kommunizieren**, ohne Einschränkungen.
|
||||
**Subnetze** sind Unterteilungen innerhalb eines VNet, die durch spezifische **IP-Adressbereiche** definiert werden. Durch die Segmentierung eines VNet in mehrere Subnetze können Sie Ressourcen entsprechend Ihrer Netzwerkarchitektur organisieren und absichern.\
|
||||
Standardmäßig können alle Subnetze innerhalb desselben Azure Virtual Network (VNet) **ohne Einschränkungen** miteinander kommunizieren.
|
||||
|
||||
**Beispiel:**
|
||||
|
||||
- `MyVNet` mit einem IP-Adressbereich von 10.0.0.0/16.
|
||||
- **Subnetz-1:** 10.0.0.0/24 für Webserver.
|
||||
- **Subnetz-2:** 10.0.1.0/24 für Datenbankserver.
|
||||
- **Subnet-1:** 10.0.0.0/24 für Webserver.
|
||||
- **Subnet-2:** 10.0.1.0/24 für Datenbankserver.
|
||||
|
||||
### Aufzählung
|
||||
### Auflistung
|
||||
|
||||
Um alle VNets und Subnetze in einem Azure-Konto aufzulisten, können Sie die Azure Command-Line Interface (CLI) verwenden. Hier sind die Schritte:
|
||||
|
||||
@@ -47,9 +47,9 @@ Select-Object Name, AddressPrefix
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
## Netzwerk-Sicherheitsgruppen (NSG)
|
||||
## Network Security Groups (NSG)
|
||||
|
||||
Eine **Netzwerk-Sicherheitsgruppe (NSG)** filtert den Netzwerkverkehr sowohl zu als auch von Azure-Ressourcen innerhalb eines Azure Virtual Network (VNet). Sie enthält eine Reihe von **Sicherheitsregeln**, die angeben können, **welche Ports für eingehenden und ausgehenden Verkehr geöffnet werden sollen** nach Quellport, Quell-IP, Zielport, und es ist möglich, eine Priorität zuzuweisen (je niedriger die Prioritätsnummer, desto höher die Priorität).
|
||||
Eine **Network Security Group (NSG)** filtert den Netzwerkverkehr sowohl zu als auch von Azure-Ressourcen innerhalb eines Azure Virtual Network (VNet). Sie enthält eine Reihe von **Sicherheitsregeln**, die angeben können, **welche Ports für eingehenden und ausgehenden Verkehr** nach Quellport, Quell-IP und Zielport zu öffnen sind. Außerdem kann eine Priorität zugewiesen werden (je niedriger die Prioritätsnummer, desto höher die Priorität).
|
||||
|
||||
NSGs können mit **Subnetzen und NICs** verknüpft werden.
|
||||
|
||||
@@ -71,7 +71,7 @@ az network nsg show --name <nsg-name>
|
||||
az network nsg rule list --nsg-name <NSGName> --resource-group <ResourceGroupName> --query "[].{name:name, priority:priority, direction:direction, access:access, protocol:protocol, sourceAddressPrefix:sourceAddressPrefix, destinationAddressPrefix:destinationAddressPrefix, sourcePortRange:sourcePortRange, destinationPortRange:destinationPortRange}" -o table
|
||||
|
||||
# Get NICs and subnets using this NSG
|
||||
az network nsg show --name MyLowCostVM-nsg --resource-group Resource_Group_1 --query "{subnets: subnets, networkInterfaces: networkInterfaces}"
|
||||
az network nsg show --name <NSGName> --resource-group <ResourceGroupName> --query "{subnets: subnets, networkInterfaces: networkInterfaces}"
|
||||
```
|
||||
{{#endtab }}
|
||||
{{#tab name="PowerShell" }}
|
||||
@@ -81,30 +81,33 @@ Get-AzNetworkSecurityGroup | Select-Object Name, Location
|
||||
Get-AzNetworkSecurityGroup -Name <NSGName> -ResourceGroupName <ResourceGroupName>
|
||||
|
||||
# Get NSG rules
|
||||
(Get-AzNetworkSecurityGroup -ResourceGroupName <NSGName> -Name <ResourceGroupName>).SecurityRules
|
||||
Get-AzNetworkSecurityGroup -Name <NSGName> -ResourceGroupName <ResourceGroupName> |
|
||||
Select-Object -ExpandProperty SecurityRules |
|
||||
Select-Object Name, Priority, Direction, Access, Protocol, SourceAddressPrefix, DestinationAddressPrefix, SourcePortRange, DestinationPortRange
|
||||
|
||||
# Get NICs and subnets using this NSG
|
||||
(Get-AzNetworkSecurityGroup -Name <NSGName> -ResourceGroupName <ResourceGroupName>).Subnets
|
||||
(Get-AzNetworkSecurityGroup -Name <NSGName> -ResourceGroupName <ResourceGroupName>).NetworkInterfaces
|
||||
```
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
## Azure Firewall
|
||||
|
||||
Azure Firewall ist ein **verwalteter Netzwerk-Sicherheitsdienst** in Azure, der Cloud-Ressourcen schützt, indem er den Datenverkehr inspiziert und kontrolliert. Es handelt sich um eine **zustandsbehaftete Firewall**, die den Datenverkehr basierend auf Regeln für die Schichten 3 bis 7 filtert und die Kommunikation sowohl **innerhalb von Azure** (East-West-Datenverkehr) als auch **zu/von externen Netzwerken** (North-South-Datenverkehr) unterstützt. Bereitgestellt auf der **Virtual Network (VNet)-Ebene** bietet es zentralisierten Schutz für alle Subnetze im VNet. Azure Firewall skaliert automatisch, um den Anforderungen des Datenverkehrs gerecht zu werden, und gewährleistet hohe Verfügbarkeit, ohne dass eine manuelle Einrichtung erforderlich ist.
|
||||
Azure Firewall ist eine **verwaltete, zustandsbehaftete Firewall**, die den Datenverkehr (L3–L7) für Ost-West- und Nord-Süd-Flows filtert. Auf **VNet-Ebene** bereitgestellt, zentralisiert sie die Inspektion für alle Subnetze und skaliert automatisch für Verfügbarkeit.
|
||||
|
||||
Es ist in drei SKUs verfügbar—**Basic**, **Standard** und **Premium**, die jeweils auf spezifische Kundenbedürfnisse zugeschnitten sind:
|
||||
Verfügbare SKUs: **Basic**, **Standard**, und **Premium**:
|
||||
|
||||
| Kriterien/Funktion | Option 1 | Option 2 | Option 3 |
|
||||
| Criteria/Feature | Option 1 | Option 2 | Option 3 |
|
||||
| ------------------------------ | ------------------------------------------------- | ------------------------------------------- | --------------------------------------------------------- |
|
||||
| **Empfohlener Anwendungsfall** | Kleine/Mittlere Unternehmen (KMUs) mit begrenztem Bedarf | Allgemeine Unternehmensnutzung, Layer 3–7 Filtering | Hochsensible Umgebungen (z. B. Zahlungsabwicklung) |
|
||||
| **Leistung** | Bis zu 250 Mbps Durchsatz | Bis zu 30 Gbps Durchsatz | Bis zu 100 Gbps Durchsatz |
|
||||
| **Bedrohungsintelligenz** | Nur Warnungen | Warnungen und Blockierung (bösartige IPs/Domains) | Warnungen und Blockierung (erweiterte Bedrohungsintelligenz) |
|
||||
| **L3–L7 Filtering** | Basisfilterung | Zustandsbehaftete Filterung über Protokolle | Zustandsbehaftete Filterung mit erweiterter Inspektion |
|
||||
| **Erweiterter Bedrohungsschutz** | Nicht verfügbar | Bedrohungsintelligenz-basiertes Filtern | Beinhaltet Intrusion Detection and Prevention System (IDPS) |
|
||||
| **TLS-Inspektion** | Nicht verfügbar | Nicht verfügbar | Unterstützt eingehende/ausgehende TLS-Terminierung |
|
||||
| **Verfügbarkeit** | Fester Backend (2 VMs) | Autoskalierung | Autoskalierung |
|
||||
| **Verwaltungsaufwand** | Grundlegende Steuerung | Verwaltet über Firewall Manager | Verwaltet über Firewall Manager |
|
||||
| **Recommended Use Case** | Kleine/Mittelständische Unternehmen (SMBs) mit begrenzten Anforderungen | Allgemeiner Unternehmenseinsatz, Layer 3–7-Filterung | Sehr sensible Umgebungen (z. B. Zahlungsabwicklung) |
|
||||
| **Performance** | Bis zu 250 Mbps Durchsatz | Bis zu 30 Gbps Durchsatz | Bis zu 100 Gbps Durchsatz |
|
||||
| **Threat Intelligence** | Nur Warnungen | Warnungen und Blockierung (bösartige IPs/Domains) | Warnungen und Blockierung (erweiterte Threat Intelligence) |
|
||||
| **L3–L7 Filtering** | Grundlegende Filterung | Zustandsbehaftete Filterung über Protokolle | Zustandsbehaftete Filterung mit erweiterter Inspektion |
|
||||
| **Advanced Threat Protection** | Nicht verfügbar | Auf Threat Intelligence basierende Filterung | Beinhaltet Intrusion Detection and Prevention System (IDPS) |
|
||||
| **TLS Inspection** | Nicht verfügbar | Nicht verfügbar | Unterstützt eingehende/ausgehende TLS-Terminierung |
|
||||
| **Availability** | Festes Backend (2 VMs) | Automatische Skalierung | Automatische Skalierung |
|
||||
| **Ease of Management** | Einfache Steuerung | Verwaltet via Firewall Manager | Verwaltet via Firewall Manager |
|
||||
|
||||
### Enumeration
|
||||
|
||||
@@ -141,11 +144,16 @@ Get-AzFirewall
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
## Azure-Routing-Tabellen
|
||||
## Azure Routingtabellen
|
||||
|
||||
Azure **Routing-Tabellen** werden verwendet, um das Routing des Netzwerkverkehrs innerhalb eines Subnetzes zu steuern. Sie definieren Regeln, die angeben, wie Pakete weitergeleitet werden sollen, entweder zu Azure-Ressourcen, dem Internet oder einem bestimmten nächsten Hop wie einem Virtual Appliance oder Azure Firewall. Sie können eine Routing-Tabelle mit einem **Subnetz** verknüpfen, und alle Ressourcen innerhalb dieses Subnetzes folgen den Routen in der Tabelle.
|
||||
Azure **Routingtabellen (UDR)** ermöglichen es, das Standard-Routing zu überschreiben, indem Zielpräfixe definiert werden (z. B. `10.0.0.0/16` oder `0.0.0.0/0`) und ein nächster Hop festgelegt wird (Virtual Network, Internet, Virtual Network Gateway oder Virtual Appliance).
|
||||
|
||||
**Beispiel:** Wenn ein Subnetz Ressourcen hostet, die ausgehenden Verkehr über eine Network Virtual Appliance (NVA) zur Inspektion routen müssen, können Sie eine **Route** in einer Routing-Tabelle erstellen, um den gesamten Verkehr (z. B. `0.0.0.0/0`) an die private IP-Adresse der NVA als nächsten Hop umzuleiten.
|
||||
> Routen gelten auf Subnetz-Ebene; alle VMs in diesem Subnetz folgen der Tabelle.
|
||||
|
||||
**Beispiel:**
|
||||
|
||||
- Für internet-gebundenen Traffic verwenden Sie das Standard-`0.0.0.0/0` mit **Internet** als nächsten Hop.
|
||||
- Um ausgehenden Traffic zu inspizieren, routen Sie `0.0.0.0/0` an eine Network Virtual Appliance (NVA)-IP.
|
||||
|
||||
### **Enumeration**
|
||||
|
||||
@@ -155,8 +163,11 @@ Azure **Routing-Tabellen** werden verwendet, um das Routing des Netzwerkverkehrs
|
||||
# List Route Tables
|
||||
az network route-table list --query "[].{name:name, resourceGroup:resourceGroup, location:location}" -o table
|
||||
|
||||
# List routes for a table
|
||||
az network route-table route list --route-table-name <RouteTableName> --resource-group <ResourceGroupName> --query "[].{name:name, addressPrefix:addressPrefix, nextHopType:nextHopType, nextHopIpAddress:nextHopIpAddress}" -o table
|
||||
# List routes for a table (summary)
|
||||
az network route-table route list --resource-group <ResourceGroupName> --route-table-name <RouteTableName> --query "[].{name:name, addressPrefix:addressPrefix, nextHopType:nextHopType, nextHopIpAddress:nextHopIpAddress}" -o table
|
||||
|
||||
# List routes for a table (full)
|
||||
az network route-table route list --resource-group <ResourceGroupName> --route-table-name <RouteTableName>
|
||||
```
|
||||
{{#endtab }}
|
||||
{{#tab name="PowerShell" }}
|
||||
@@ -172,16 +183,16 @@ Get-AzRouteTable
|
||||
|
||||
## Azure Private Link
|
||||
|
||||
Azure Private Link ist ein Dienst in Azure, der **privaten Zugriff auf Azure-Dienste ermöglicht**, indem sichergestellt wird, dass **der Datenverkehr zwischen Ihrem Azure Virtual Network (VNet) und dem Dienst vollständig innerhalb des Backbone-Netzwerks von Microsoft Azure verläuft**. Es bringt den Dienst effektiv in Ihr VNet. Diese Konfiguration verbessert die Sicherheit, indem die Daten nicht dem öffentlichen Internet ausgesetzt werden.
|
||||
Azure Private Link ist ein Service in Azure, der **privaten Zugriff auf Azure-Dienste ermöglicht**, indem er sicherstellt, dass **der Datenverkehr zwischen Ihrem Azure virtual network (VNet) und dem Dienst vollständig innerhalb des Azure-Backbone-Netzwerks von Microsoft verläuft**. Er bringt den Dienst effektiv in Ihr VNet. Diese Konfiguration erhöht die Sicherheit, da die Daten nicht dem öffentlichen Internet ausgesetzt werden.
|
||||
|
||||
Private Link kann mit verschiedenen Azure-Diensten verwendet werden, wie Azure Storage, Azure SQL Database und benutzerdefinierten Diensten, die über Private Link geteilt werden. Es bietet eine sichere Möglichkeit, Dienste aus Ihrem eigenen VNet oder sogar aus verschiedenen Azure-Abonnements zu konsumieren.
|
||||
Private Link kann mit verschiedenen Azure-Diensten verwendet werden, wie Azure Storage, Azure SQL Database und benutzerdefinierten Diensten, die über Private Link geteilt werden. Es bietet eine sichere Möglichkeit, Dienste aus Ihrem eigenen VNet oder sogar aus verschiedenen Azure-Subscriptions zu konsumieren.
|
||||
|
||||
> [!CAUTION]
|
||||
> NSGs gelten nicht für private Endpunkte, was eindeutig bedeutet, dass die Zuordnung eines NSG zu einem Subnetz, das den Private Link enthält, keine Auswirkungen hat.
|
||||
> NSGs gelten nicht für private endpoints, was eindeutig bedeutet, dass die Zuordnung einer NSG zu einem Subnetz, das das Private Link enthält, keine Wirkung hat.
|
||||
|
||||
**Beispiel:**
|
||||
|
||||
Betrachten Sie ein Szenario, in dem Sie eine **Azure SQL-Datenbank haben, auf die Sie sicher von Ihrem VNet aus zugreifen möchten**. Normalerweise könnte dies den Zugriff über das öffentliche Internet erfordern. Mit Private Link können Sie einen **privaten Endpunkt in Ihrem VNet erstellen**, der direkt mit dem Azure SQL-Datenbankdienst verbunden ist. Dieser Endpunkt lässt die Datenbank so erscheinen, als wäre sie Teil Ihres eigenen VNet, zugänglich über eine private IP-Adresse, wodurch ein sicherer und privater Zugriff gewährleistet wird.
|
||||
Betrachten Sie ein Szenario, in dem Sie eine **Azure SQL Database haben, auf die Sie sicher von Ihrem VNet aus zugreifen möchten**. Normalerweise würde dies das Durchqueren des öffentlichen Internets erfordern. Mit Private Link können Sie einen **private endpoint in Ihrem VNet** erstellen, der direkt mit dem Azure SQL Database-Dienst verbunden ist. Dieser Endpoint lässt die Datenbank so erscheinen, als wäre sie Teil Ihres eigenen VNet und über eine private IP-Adresse erreichbar, wodurch sicherer und privater Zugriff gewährleistet wird.
|
||||
|
||||
### **Enumeration**
|
||||
|
||||
@@ -206,13 +217,60 @@ Get-AzPrivateEndpoint | Select-Object Name, Location, ResourceGroupName, Private
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
### DNS OverDoS via service Private DNS zone links
|
||||
|
||||
When a VNet has a **Virtual Network Link** to a **service Private DNS zone** (e.g., `privatelink.blob.core.windows.net`), Azure **forces hostname resolution** for Private Link registered resources of that service type through the zone. If the zone **lacks the required `A` record** for a resource that workloads still access via its public endpoint, DNS resolution returns **NXDOMAIN** and clients never reach the public IP, causing an **availability DoS** without touching the resource itself.
|
||||
|
||||
**Missbrauchsablauf (control-plane DoS):**
|
||||
|
||||
1. Erlange RBAC-Berechtigungen, die das Erstellen von **Private Endpoints** oder das Ändern von **Private DNS zone links** erlauben.
|
||||
2. Erstelle ein Private Endpoint für denselben Diensttyp in einem anderen VNet (Azure erstellt automatisch die service Private DNS zone und verknüpft sie mit diesem VNet).
|
||||
3. Verknüpfe diese **service Private DNS zone** mit dem Ziel-VNet.
|
||||
4. Weil das Ziel-VNet nun die Auflösung über die **Private DNS zone** erzwingt und kein `A`-Record für die Zielressource in dieser Zone existiert, schlägt die Namensauflösung fehl und die Workload kann den (weiterhin public) endpoint nicht erreichen. Dies gilt für jeden Private Link–unterstützten Dienst (storage, Key Vault, ACR, Cosmos DB, Function Apps, OpenAI, etc.).
|
||||
|
||||
**Erkennung im großen Maßstab (Azure Resource Graph):**
|
||||
|
||||
- VNETs, die mit der blob Private DNS zone verlinkt sind (erzwingt Auflösung für PL-registered blob endpoints):
|
||||
```kusto
|
||||
resources
|
||||
| where type == "microsoft.network/privatednszones/virtualnetworklinks"
|
||||
| extend
|
||||
zone = tostring(split(id, "/virtualNetworkLinks")[0]),
|
||||
vnetId = tostring(properties.virtualNetwork.id)
|
||||
| join kind=inner (
|
||||
resources
|
||||
| where type == "microsoft.network/privatednszones"
|
||||
| where name == "privatelink.blob.core.windows.net"
|
||||
| project zoneId = id
|
||||
) on $left.zone == $right.zoneId
|
||||
| project vnetId
|
||||
```
|
||||
- Storage accounts erreichbar über public endpoint aber **ohne** Private Endpoint connections (bricht wahrscheinlich, wenn der obige Link hinzugefügt wird):
|
||||
```kusto
|
||||
Resources
|
||||
| where type == "microsoft.storage/storageaccounts"
|
||||
| extend publicNetworkAccess = properties.publicNetworkAccess
|
||||
| extend defaultAction = properties.networkAcls.defaultAction
|
||||
| extend vnetRules = properties.networkAcls.virtualNetworkRules
|
||||
| extend ipRules = properties.networkAcls.ipRules
|
||||
| extend privateEndpoints = properties.privateEndpointConnections
|
||||
| where publicNetworkAccess == "Enabled"
|
||||
| where defaultAction == "Deny"
|
||||
| where (isnull(privateEndpoints) or array_length(privateEndpoints) == 0)
|
||||
| extend allowedVnets = iif(isnull(vnetRules), 0, array_length(vnetRules))
|
||||
| extend allowedIps = iif(isnull(ipRules), 0, array_length(ipRules))
|
||||
| where allowedVnets > 0 or allowedIps > 0
|
||||
| project id, name, vnetRules, ipRules
|
||||
```
|
||||
## Azure Service Endpoints
|
||||
|
||||
Azure Service Endpoints erweitern den privaten Adressraum Ihres virtuellen Netzwerks und die Identität Ihres VNet zu Azure-Diensten über eine direkte Verbindung. Durch die Aktivierung von Service-Endpunkten können **Ressourcen in Ihrem VNet sicher mit Azure-Diensten** verbinden, wie Azure Storage und Azure SQL Database, unter Verwendung des Backbone-Netzwerks von Azure. Dies stellt sicher, dass der **Verkehr vom VNet zum Azure-Dienst innerhalb des Azure-Netzwerks bleibt**, was einen sichereren und zuverlässigeren Pfad bietet.
|
||||
Azure Service Endpoints erweitern den privaten Adressraum Ihres virtuellen Netzwerks und die Identität Ihres VNet auf Azure services über eine direkte Verbindung. Durch das Aktivieren von Service Endpoints können **Ressourcen in Ihrem VNet sicher mit Azure services** wie Azure Storage und Azure SQL Database über das Azure-Backbone-Netzwerk verbunden werden. Dies ist besonders nützlich in Kombination mit Network Security Groups (NSGs) für eine granulare Steuerung des Datenverkehrs.
|
||||
|
||||
**Beispiel:**
|
||||
|
||||
Ein **Azure Storage**-Konto ist standardmäßig über das öffentliche Internet zugänglich. Durch die Aktivierung eines **Service-Endpunkts für Azure Storage innerhalb Ihres VNet** können Sie sicherstellen, dass nur der Verkehr von Ihrem VNet auf das Speicherkonto zugreifen kann. Die Firewall des Speicherkontos kann dann so konfiguriert werden, dass sie nur Verkehr von Ihrem VNet akzeptiert.
|
||||
- Wenn ein **Storage** Account und Service Endpoint **aktiviert** in a VNET sind, ist es möglich, eingehenden Verkehr **nur von einem VNET in der storage account firewall** zuzulassen, wodurch eine **sichere Verbindung** erzwungen wird, ohne dass für den Storage-Dienst public IP-Zugriff erforderlich ist.
|
||||
|
||||
Service Endpoints **require keine privaten IP-Adressen** für die Dienste und verlassen sich stattdessen auf das Azure-Backbone für sichere Konnektivität. Sie sind im Vergleich zu Private Links **einfacher einzurichten**, bieten jedoch **nicht dasselbe Maß an Isolation und Granularität** wie Private Links.
|
||||
|
||||
### **Enumeration**
|
||||
|
||||
@@ -223,7 +281,10 @@ Ein **Azure Storage**-Konto ist standardmäßig über das öffentliche Internet
|
||||
az network vnet list --query "[].{name:name, location:location, serviceEndpoints:serviceEndpoints}" -o table
|
||||
|
||||
# List Subnets with Service Endpoints
|
||||
az network vnet subnet list --resource-group <ResourceGroupName> --vnet-name <VNetName> --query "[].{name:name, serviceEndpoints:serviceEndpoints}" -o table
|
||||
az network vnet subnet list --resource-group <ResourceGroupName> --vnet-name <VNetName> --query "[].{name:name, serviceEndpoints:serviceEndpoints}"
|
||||
|
||||
# List Service Endpoints for a Subnet
|
||||
az network vnet subnet show --resource-group <ResourceGroupName> --vnet-name <VNetName> --name <SubnetName> --query "serviceEndpoints"
|
||||
```
|
||||
{{#endtab }}
|
||||
{{#tab name="PowerShell" }}
|
||||
@@ -237,71 +298,85 @@ Get-AzVirtualNetwork
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
### Unterschiede zwischen Service-Endpunkten und privaten Links
|
||||
### Unterschiede zwischen Service Endpoints und Private Links
|
||||
|
||||
Microsoft empfiehlt die Verwendung von privaten Links in den [**docs**](https://learn.microsoft.com/en-us/azure/virtual-network/vnet-integration-for-azure-services#compare-private-endpoints-and-service-endpoints):
|
||||
Microsoft empfiehlt die Verwendung von Private Links in den [**docs**](https://learn.microsoft.com/en-us/azure/virtual-network/vnet-integration-for-azure-services#compare-private-endpoints-and-service-endpoints):
|
||||
|
||||
<figure><img src="../../../../images/image (25).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
**Service-Endpunkte:**
|
||||
**Service Endpoints:**
|
||||
|
||||
- Der Datenverkehr von Ihrem VNet zum Azure-Dienst verläuft über das Microsoft Azure Backbone-Netzwerk und umgeht das öffentliche Internet.
|
||||
- Der Endpunkt ist eine direkte Verbindung zum Azure-Dienst und bietet keine private IP für den Dienst innerhalb des VNet.
|
||||
- Der Dienst selbst ist weiterhin über seinen öffentlichen Endpunkt von außerhalb Ihres VNet zugänglich, es sei denn, Sie konfigurieren die Dienstfirewall, um solchen Datenverkehr zu blockieren.
|
||||
- Es besteht eine Eins-zu-eins-Beziehung zwischen dem Subnetz und dem Azure-Dienst.
|
||||
- Günstiger als private Links.
|
||||
- Traffic von Ihrem VNet zum Azure-Dienst verläuft über das Microsoft Azure backbone network und umgeht das öffentliche Internet.
|
||||
- Der Endpoint ist eine direkte Verbindung zum Azure-Dienst und stellt keine private IP für den Dienst innerhalb des VNet bereit.
|
||||
- Der Dienst selbst ist weiterhin über seinen öffentlichen Endpoint von außerhalb Ihres VNet zugänglich, es sei denn, Sie konfigurieren die Service-Firewall, um solchen Traffic zu blockieren.
|
||||
- Es besteht eine Eins-zu-eins-Beziehung zwischen dem Subnet und dem Azure-Dienst.
|
||||
- Günstiger als Private Links.
|
||||
|
||||
**Private Links:**
|
||||
|
||||
- Private Link ordnet Azure-Dienste über einen privaten Endpunkt in Ihr VNet zu, der eine Netzwerkschnittstelle mit einer privaten IP-Adresse innerhalb Ihres VNet ist.
|
||||
- Der Azure-Dienst wird über diese private IP-Adresse aufgerufen, wodurch er wie ein Teil Ihres Netzwerks erscheint.
|
||||
- Dienste, die über Private Link verbunden sind, können nur von Ihrem VNet oder verbundenen Netzwerken aus aufgerufen werden; es gibt keinen öffentlichen Internetzugang zu dem Dienst.
|
||||
- Private Link mappt Azure-Dienste in Ihr VNet über einen privaten Endpoint, der ein Network Interface mit einer privaten IP-Adresse innerhalb Ihres VNet ist.
|
||||
- Auf den Azure-Dienst wird über diese private IP-Adresse zugegriffen, wodurch er so erscheint, als wäre er Teil Ihres Netzwerks.
|
||||
- Dienste, die über Private Link verbunden sind, können nur von Ihrem VNet oder verbundenen Netzwerken aus erreicht werden; es gibt keinen Zugriff über das öffentliche Internet auf den Dienst.
|
||||
- Es ermöglicht eine sichere Verbindung zu Azure-Diensten oder Ihren eigenen in Azure gehosteten Diensten sowie eine Verbindung zu von anderen geteilten Diensten.
|
||||
- Es bietet eine granularere Zugriffskontrolle über einen privaten Endpunkt in Ihrem VNet, im Gegensatz zu einer breiteren Zugriffskontrolle auf Subnetzebene mit Service-Endpunkten.
|
||||
- Es bietet granulare Zugriffskontrolle über einen privaten Endpoint in Ihrem VNet, im Gegensatz zur breiteren Zugriffskontrolle auf Subnet-Ebene bei Service Endpoints.
|
||||
|
||||
Zusammenfassend lässt sich sagen, dass sowohl Service-Endpunkte als auch private Links eine sichere Konnektivität zu Azure-Diensten bieten, **aber private Links ein höheres Maß an Isolation und Sicherheit bieten, indem sie sicherstellen, dass Dienste privat ohne Exposition gegenüber dem öffentlichen Internet aufgerufen werden**. Service-Endpunkte hingegen sind einfacher einzurichten für allgemeine Fälle, in denen ein einfacher, sicherer Zugriff auf Azure-Dienste erforderlich ist, ohne dass eine private IP im VNet benötigt wird.
|
||||
Zusammenfassend bieten sowohl Service Endpoints als auch Private Links eine sichere Konnektivität zu Azure-Diensten, jedoch **bieten Private Links ein höheres Maß an Isolation und Sicherheit, indem sie sicherstellen, dass Dienste privat erreicht werden, ohne sie dem öffentlichen Internet auszusetzen**. Service Endpoints hingegen sind einfacher einzurichten für allgemeine Fälle, in denen ein einfacher, sicherer Zugriff auf Azure-Dienste benötigt wird, ohne dass eine private IP im VNet erforderlich ist.
|
||||
|
||||
## Azure Front Door (AFD) & AFD WAF
|
||||
|
||||
**Azure Front Door** ist ein skalierbarer und sicherer Einstiegspunkt für die **schnelle Bereitstellung** Ihrer globalen Webanwendungen. Es **kombiniert** verschiedene Dienste wie globale **Lastverteilung, Standortbeschleunigung, SSL-Offloading und Web Application Firewall (WAF)**-Funktionen in einem einzigen Dienst. Azure Front Door bietet intelligentes Routing basierend auf dem **nächsten Edge-Standort zum Benutzer**, um optimale Leistung und Zuverlässigkeit zu gewährleisten. Darüber hinaus bietet es URL-basiertes Routing, Hosting mehrerer Standorte, Sitzungsaffinität und Sicherheit auf Anwendungsebene.
|
||||
**Azure Front Door** ist ein skalierbarer und sicherer Einstiegspunkt für die **schnelle Bereitstellung** Ihrer globalen Webanwendungen. Es **kombiniert** verschiedene Dienste wie **application acceleration, SSL offloading, and application layer security** (durch Web Application Firewall - WAF). Es basiert auf dem Konzept von edge POP (Point of Presence)-Standorten rund um die Welt, um Ihre Anwendungen näher zu Ihren Nutzern zu bringen.
|
||||
|
||||
**Azure Front Door WAF** ist darauf ausgelegt, **Webanwendungen vor web-basierten Angriffen** zu schützen, ohne dass Änderungen am Backend-Code erforderlich sind. Es umfasst benutzerdefinierte Regeln und verwaltete Regelsets, um vor Bedrohungen wie SQL-Injection, Cross-Site-Scripting und anderen gängigen Angriffen zu schützen.
|
||||
> Azure Front Door stellt ein global verteiltes Netzwerk von Edge-Standorten bereit, um eingehenden Traffic zu Ihren Webanwendungen (in Azure oder anderswo) zu **routen und zu beschleunigen**, die Performance zu verbessern und die Sicherheit zu erhöhen.
|
||||
|
||||
**Beispiel:**
|
||||
|
||||
Stellen Sie sich vor, Sie haben eine global verteilte Anwendung mit Benutzern auf der ganzen Welt. Sie können Azure Front Door verwenden, um **Benutzeranfragen an das nächstgelegene regionale Rechenzentrum** weiterzuleiten, das Ihre Anwendung hostet, wodurch die Latenz verringert, die Benutzererfahrung verbessert und **es vor Webangriffen mit den WAF-Funktionen geschützt wird**. Wenn eine bestimmte Region Ausfallzeiten hat, kann Azure Front Door den Datenverkehr automatisch an den nächstbesten Standort umleiten, um eine hohe Verfügbarkeit sicherzustellen.
|
||||
- Für eine globale E-Commerce-Plattform mit Nutzern weltweit **kann Azure Front Door statische Inhalte an Edge-Standorten cachen** und **SSL offloading** anbieten, wodurch Latenz reduziert und ein reaktionsschnelleres Nutzererlebnis erzielt wird. Zusätzlich bietet es **WAF**, um Ihre Anwendungen vor gängigen Web-Schwachstellen (wie SQL injection oder XSS) zu schützen.
|
||||
|
||||
### Aufzählung
|
||||
Azure Front Door bietet außerdem **smart load balancing**, indem Traffic basierend auf Health-Probes und Latenz an das nächstverfügbare Backend geroutet wird, wodurch eine konsistente Performance und Verfügbarkeit sichergestellt wird. Durch die Integration von **WAF** hilft es, gegen gängige Web-Bedrohungen zu schützen.
|
||||
|
||||
### **Aufzählung**
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="az cli" }}
|
||||
```bash
|
||||
# List Azure Front Door Instances
|
||||
# List Azure Front Door profiles
|
||||
az afd profile list --query "[].{name:name, location:location, resourceGroup:resourceGroup}" -o table
|
||||
|
||||
# List AFD endpoints
|
||||
az afd endpoint list --profile-name <ProfileName> --resource-group <ResourceGroupName> --query "[].{name:name, hostName:hostName, state:resourceState}" -o table
|
||||
|
||||
# Classic Azure Front Door (v1) profiles
|
||||
az network front-door list --query "[].{name:name, resourceGroup:resourceGroup, location:location}" -o table
|
||||
|
||||
# List Front Door WAF Policies
|
||||
# Classic Azure Front Door WAF policies
|
||||
az network front-door waf-policy list --query "[].{name:name, resourceGroup:resourceGroup, location:location}" -o table
|
||||
```
|
||||
{{#endtab }}
|
||||
{{#tab name="PowerShell" }}
|
||||
```bash
|
||||
# List Azure Front Door Instances
|
||||
# List Azure Front Door profiles
|
||||
Get-AzFrontDoorCdnProfile | Select-Object Name, Location, ResourceGroupName
|
||||
|
||||
# List AFD endpoints
|
||||
Get-AzFrontDoorCdnEndpoint -ProfileName <ProfileName> -ResourceGroupName <ResourceGroupName> | Select-Object Name, HostName, ResourceState
|
||||
|
||||
# Classic Azure Front Door (v1) profiles
|
||||
Get-AzFrontDoor
|
||||
|
||||
# List Front Door WAF Policies
|
||||
# Classic Azure Front Door WAF policies
|
||||
Get-AzFrontDoorWafPolicy -Name <policyName> -ResourceGroupName <resourceGroupName>
|
||||
```
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
## Azure Application Gateway und Azure Application Gateway WAF
|
||||
## Azure Application Gateway and Azure Application Gateway WAF
|
||||
|
||||
Azure Application Gateway ist ein **Web-Traffic-Lastenausgleich**-Dienst, der es Ihnen ermöglicht, den Traffic zu Ihren **Web**-Anwendungen zu verwalten. Es bietet **Layer 7 Lastenausgleich, SSL-Terminierung und Webanwendungsfirewall (WAF) Funktionen** im Application Delivery Controller (ADC) als Dienst. Zu den Hauptfunktionen gehören URL-basiertes Routing, cookie-basiertes Sitzungsaffinität und SSL-Offloading, die für Anwendungen, die komplexe Lastenausgleichsfunktionen wie globales Routing und pfadbasiertes Routing erfordern, entscheidend sind.
|
||||
Azure Application Gateway ist ein **Load Balancer für Web-Traffic**, der es Ihnen ermöglicht, den Traffic zu Ihren **Web**-Anwendungen zu verwalten. Er bietet **Layer 7 load balancing, SSL termination und web application firewall (WAF)-Funktionen** im Application Delivery Controller (ADC) als Service. Wichtige Merkmale sind URL-basiertes Routing, cookie-basierte Session-Affinität und Secure Sockets Layer (SSL) Offloading, die für Anwendungen, die komplexe Load-Balancing-Funktionen wie globales Routing und pfadbasiertes Routing benötigen, entscheidend sind.
|
||||
|
||||
**Beispiel:**
|
||||
|
||||
Betrachten Sie ein Szenario, in dem Sie eine E-Commerce-Website haben, die mehrere Subdomains für verschiedene Funktionen umfasst, wie z.B. Benutzerkonten und Zahlungsabwicklung. Azure Application Gateway kann **Traffic basierend auf dem URL-Pfad an die entsprechenden Webserver weiterleiten**. Zum Beispiel könnte der Traffic zu `example.com/accounts` an den Dienst für Benutzerkonten geleitet werden, und der Traffic zu `example.com/pay` könnte an den Zahlungsabwicklungsdienst geleitet werden.\
|
||||
Und **schützen Sie Ihre Website vor Angriffen mit den WAF-Funktionen.**
|
||||
Betrachten Sie ein Szenario, in dem Sie eine E-Commerce-Website haben, die mehrere Subdomains für verschiedene Funktionen enthält, wie Benutzerkonten und Zahlungsabwicklung. Azure Application Gateway kann **den Traffic basierend auf dem URL-Pfad an die entsprechenden Webserver routen**. Zum Beispiel könnte Traffic an `example.com/accounts` an den Service für Benutzerkonten geleitet werden, und Traffic an `example.com/pay` an den Zahlungsabwicklungsdienst.\
|
||||
Und **schützen Sie Ihre Website vor Angriffen mithilfe der WAF-Funktionen.**
|
||||
|
||||
### **Enumeration**
|
||||
|
||||
@@ -320,20 +395,20 @@ az network application-gateway waf-config list --gateway-name <AppGatewayName> -
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
## Azure Hub, Spoke & VNet Peering
|
||||
## VNet Peering & HUB and Spoke Topologien
|
||||
|
||||
**VNet Peering** ist eine Netzwerkfunktion in Azure, die **es ermöglicht, verschiedene Virtuelle Netzwerke (VNets) direkt und nahtlos zu verbinden**. Durch VNet Peering können Ressourcen in einem VNet mit Ressourcen in einem anderen VNet über private IP-Adressen kommunizieren, **als ob sie im selben Netzwerk wären**.\
|
||||
**VNet Peering kann auch mit On-Premise-Netzwerken verwendet werden**, indem ein Site-to-Site-VPN oder Azure ExpressRoute eingerichtet wird.
|
||||
### VNet Peering
|
||||
|
||||
**Azure Hub und Spoke** ist eine Netzwerk-Topologie, die in Azure verwendet wird, um den Netzwerkverkehr zu verwalten und zu organisieren. **Der "Hub" ist ein zentraler Punkt, der den Verkehr zwischen verschiedenen "Spokes" steuert und leitet**. Der Hub enthält typischerweise gemeinsame Dienste wie Netzwerkvirtualgeräte (NVAs), Azure VPN Gateway, Azure Firewall oder Azure Bastion. Die **"Spokes" sind VNets, die Workloads hosten und über VNet Peering mit dem Hub verbunden sind**, wodurch sie die gemeinsamen Dienste im Hub nutzen können. Dieses Modell fördert eine saubere Netzwerkstruktur und reduziert die Komplexität, indem es gemeinsame Dienste zentralisiert, die von mehreren Workloads in verschiedenen VNets genutzt werden können.
|
||||
**VNet Peering** ist eine Funktion in Azure, die **ermöglicht, verschiedene Virtual Networks (VNets) direkt und nahtlos zu verbinden**. Durch VNet Peering können Ressourcen in einem VNet mit Ressourcen in einem anderen VNet über private IP-Adressen kommunizieren, **als wären sie im selben Netzwerk**.\
|
||||
**VNet Peering kann auch mit On-Prem-Netzwerken verwendet werden**, indem ein site-to-site VPN oder Azure ExpressRoute eingerichtet wird.
|
||||
|
||||
> [!CAUTION] > **VNET-Peering ist in Azure nicht transitiv**, was bedeutet, dass, wenn Spoke 1 mit Spoke 2 verbunden ist und Spoke 2 mit Spoke 3 verbunden ist, Spoke 1 nicht direkt mit Spoke 3 kommunizieren kann.
|
||||
**Azure Hub and Spoke** ist eine Netzwerkarchitektur, die VNet Peering nutzt, um ein zentrales **Hub VNet** zu erstellen, das sich mit mehreren **Spoke VNets** verbindet. Der Hub enthält typischerweise gemeinsam genutzte Dienste (wie Firewalls, DNS oder Active Directory), während die Spokes Anwendungs-Workloads hosten. Dieses Design vereinfacht die Verwaltung, erhöht die Sicherheit durch zentralisierte Kontrollen und reduziert Redundanzen.
|
||||
|
||||
**Beispiel:**
|
||||
|
||||
Stellen Sie sich ein Unternehmen mit separaten Abteilungen wie Vertrieb, Personalwesen und Entwicklung vor, **die jeweils ihr eigenes VNet (die Spokes) haben**. Diese VNets **benötigen Zugriff auf gemeinsame Ressourcen** wie eine zentrale Datenbank, eine Firewall und ein Internet-Gateway, die sich alle in **einem anderen VNet (dem Hub)** befinden. Durch die Verwendung des Hub- und Spoke-Modells kann jede Abteilung **sicher auf die gemeinsamen Ressourcen über das Hub-VNet zugreifen, ohne diese Ressourcen dem öffentlichen Internet auszusetzen** oder eine komplexe Netzwerkstruktur mit zahlreichen Verbindungen zu schaffen.
|
||||
Ein großes Unternehmen mit mehreren Abteilungen (Finance, HR, IT) kann ein **Hub VNet mit gemeinsamen Diensten** wie Firewalls und DNS-Servern erstellen. Jede Abteilung kann ihr eigenes **Spoke VNet** haben, das über Peering mit dem Hub verbunden ist. Dadurch können die Abteilungen sicher kommunizieren und gemeinsam genutzte Dienste nutzen, ohne ihre Ressourcen dem öffentlichen Internet preiszugeben.
|
||||
|
||||
### Enumeration
|
||||
### **Enumeration**
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="az cli" }}
|
||||
@@ -341,8 +416,8 @@ Stellen Sie sich ein Unternehmen mit separaten Abteilungen wie Vertrieb, Persona
|
||||
# List all VNets in your subscription
|
||||
az network vnet list --query "[].{name:name, location:location, addressSpace:addressSpace}" -o table
|
||||
|
||||
# List VNet peering connections for a given VNet
|
||||
az network vnet peering list --resource-group <ResourceGroupName> --vnet-name <VNetName> --query "[].{name:name, peeringState:peeringState, remoteVnetId:remoteVnetId}" -o table
|
||||
# List VNet Peerings
|
||||
az network vnet peering list --resource-group <ResourceGroupName> --vnet-name <VNetName> --query "[].{name:name, remoteVnetId:remoteVirtualNetwork.id, allowForwardedTraffic:allowForwardedTraffic, allowGatewayTransit:allowGatewayTransit}"
|
||||
|
||||
# List Shared Resources (e.g., Azure Firewall) in the Hub
|
||||
az network firewall list --query "[].{name:name, location:location, resourceGroup:resourceGroup}" -o table
|
||||
@@ -353,8 +428,8 @@ az network firewall list --query "[].{name:name, location:location, resourceGrou
|
||||
# List all VNets in your subscription
|
||||
Get-AzVirtualNetwork
|
||||
|
||||
# List VNet peering connections for a given VNet
|
||||
(Get-AzVirtualNetwork -ResourceGroupName <ResourceGroupName> -Name <VNetName>).VirtualNetworkPeerings
|
||||
# List VNet Peerings
|
||||
Get-AzVirtualNetworkPeering -ResourceGroupName <ResourceGroupName> -VirtualNetworkName <VNetName>
|
||||
|
||||
# List Shared Resources (e.g., Azure Firewall) in the Hub
|
||||
Get-AzFirewall
|
||||
@@ -364,11 +439,11 @@ Get-AzFirewall
|
||||
|
||||
## Site-to-Site VPN
|
||||
|
||||
Ein Site-to-Site VPN in Azure ermöglicht es Ihnen, **Ihr lokales Netzwerk mit Ihrem Azure Virtual Network (VNet) zu verbinden**, sodass Ressourcen wie VMs innerhalb von Azure so erscheinen, als wären sie in Ihrem lokalen Netzwerk. Diese Verbindung wird über ein **VPN-Gateway hergestellt, das den Datenverkehr zwischen den beiden Netzwerken verschlüsselt**.
|
||||
Ein **Site-to-Site VPN** in Azure stellt eine sichere und **persistente Verbindung von Ihrem On-Premises-Netzwerk zu Ihrem Azure Virtual Network (VNet)** her, wodurch Ressourcen wie VMs in Azure so erscheinen, als wären sie in Ihrem lokalen Netzwerk. Diese Verbindung wird über ein **VPN-Gateway hergestellt, das den Datenverkehr zwischen den beiden Netzwerken verschlüsselt**.
|
||||
|
||||
**Beispiel:**
|
||||
|
||||
Ein Unternehmen mit seinem Hauptbüro in New York hat ein lokales Rechenzentrum, das sicher mit seinem VNet in Azure verbunden werden muss, das seine virtualisierten Workloads hostet. Durch die Einrichtung eines **Site-to-Site VPN kann das Unternehmen eine verschlüsselte Verbindung zwischen den lokalen Servern und den Azure VMs sicherstellen**, sodass Ressourcen sicher über beide Umgebungen hinweg zugegriffen werden kann, als wären sie im selben lokalen Netzwerk.
|
||||
Ein Unternehmen mit seinem Hauptsitz in New York hat ein lokales Rechenzentrum, das eine sichere Verbindung zu seinem VNet in Azure benötigt, das seine virtualisierten Workloads hostet. Durch die Einrichtung eines **Site-to-Site VPN kann das Unternehmen verschlüsselte Konnektivität zwischen den On-Premises-Servern und den Azure VMs sicherstellen**, sodass Ressourcen in beiden Umgebungen sicher genutzt werden können, als wären sie im selben lokalen Netzwerk.
|
||||
|
||||
### **Enumeration**
|
||||
|
||||
@@ -395,11 +470,11 @@ Get-AzVirtualNetworkGatewayConnection -ResourceGroupName <ResourceGroupName>
|
||||
|
||||
## Azure ExpressRoute
|
||||
|
||||
Azure ExpressRoute ist ein Dienst, der eine **private, dedizierte, hochgeschwindigkeits Verbindung zwischen Ihrer lokalen Infrastruktur und den Azure-Rechenzentren** bereitstellt. Diese Verbindung erfolgt über einen Konnektivitätsanbieter, umgeht das öffentliche Internet und bietet mehr Zuverlässigkeit, schnellere Geschwindigkeiten, geringere Latenzen und höhere Sicherheit als typische Internetverbindungen.
|
||||
Azure ExpressRoute ist ein Dienst, der eine **private, dedizierte Hochgeschwindigkeitsverbindung zwischen Ihrer lokalen Infrastruktur und Azure-Rechenzentren** bereitstellt. Diese Verbindung wird über einen Konnektivitätsanbieter hergestellt, um das öffentliche Internet zu umgehen, und bietet mehr Zuverlässigkeit, höhere Geschwindigkeiten, niedrigere Latenzen und höhere Sicherheit als typische Internetverbindungen.
|
||||
|
||||
**Beispiel:**
|
||||
|
||||
Ein multinationales Unternehmen benötigt eine **konstante und zuverlässige Verbindung zu seinen Azure-Diensten aufgrund des hohen Datenvolumens** und des Bedarfs an hoher Durchsatzrate. Das Unternehmen entscheidet sich für Azure ExpressRoute, um sein lokales Rechenzentrum direkt mit Azure zu verbinden, was großangelegte Datenübertragungen, wie tägliche Backups und Echtzeitanalysen, mit verbesserter Privatsphäre und Geschwindigkeit erleichtert.
|
||||
Ein multinationales Unternehmen benötigt aufgrund des hohen Datenvolumens und des Bedarfs an hohem Durchsatz eine **konstante und zuverlässige Verbindung zu seinen Azure-Diensten**. Das Unternehmen entscheidet sich für Azure ExpressRoute, um sein lokales Rechenzentrum direkt mit Azure zu verbinden und so großflächige Datenübertragungen zu ermöglichen, wie tägliche Backups und Echtzeitdatenanalysen, mit verbesserter Privatsphäre und höherer Geschwindigkeit.
|
||||
|
||||
### **Enumeration**
|
||||
|
||||
@@ -418,4 +493,10 @@ Get-AzExpressRouteCircuit
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
## Referenzen
|
||||
|
||||
- [DNS OverDoS: Sind Private Endpoints zu privat?](https://unit42.paloaltonetworks.com/dos-attacks-and-azure-private-endpoint/)
|
||||
- [Azure Private Endpoint DNS-Konfiguration](https://learn.microsoft.com/en-us/azure/private-link/private-endpoint-dns)
|
||||
- [Private DNS-Fallback zum Internet](https://learn.microsoft.com/en-us/azure/dns/private-dns-fallback)
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
Reference in New Issue
Block a user