Microsoft Azure Aufbau von hybriden Infrastrukturdiensten - inklusive Windows virtual Desktops

2 Azure Networking

2.1 Grundlagen

Eine ordnungsgemäß konfigurierte und gut segmentierte Netzwerkumgebung ist die Basis jedes IT-Infrastrukturprojektes. Um den Netzwerkverkehr innerhalb des Tenants entsprechend steuern zu können, bietet die Microsoft Azure Cloud die folgenden wichtigsten Komponenten bzw. Services an.

2.1.1 Virtual Network – VNET

Bevor das erste IaaS Service provisioniert werden kann, muss dem Tenant mindestens ein VNET zugewiesen werden. Das Azure VNET ist die Grundlage für den Aufbau eines privaten Netzwerks in der Azure Cloud. Alle Azure Ressourcen innerhalb eines VNETs können automatisch miteinander kommunizieren, die Verbindung zu einem on-premises Data-Center wird über einen speziellen Netzwerkbereich innerhalb des VNETs mittels VPN Technologien hergestellt.

• Alle Ressourcen innerhalb eines VNETs können standardmäßig miteinander kommunizieren
• Alle Ressourcen innerhalb eines VNETs haben standardmäßig Zugriff auf das Internet. Für eingehende Verbindungen muss der Ressource eine öffentliche IP-Adresse - oder die öffentliche IP-Adresse eines Load-Balancers – zugewiesen werden

Beim Anlegen eines VNETs müssen, neben einem eindeutigen Namen für das VNET - folgende Parameter konfiguriert werden:

Abonnement (Subscription) & Ressourcen Gruppe

Ein VNET muss einer Subscription und einer Ressourcen Gruppe zugewiesen werden, und kann auch nur immer mit einer Subscription bzw. Ressourcen Gruppe verknüpft sein. RBAC Regeln auf einem VNET werden standardmäßig auf alle Ressourcen innerhalb des VNETs vererbt.

Adressbereich

Einem VNET muss ein privater Adressbereich zugewiesen werden. Abhängig von der geplanten Größe der Umgebung kann ein privater Class-A, Class-B oder Class-C Bereich verwendet werden. Der Adressbereich darf sich dabei nicht mit in weiterer Folge angebunden privaten Netzwerken der on-premises Umgebung überlappen.

Subnetze

Wie bei einem klassischen Netzwerk, erfolgt die Segmentierung des VNETs mit Hilfe von Subnetzen. Hier empfiehlt es sich – wie in jedem Netzwerkdesign – eine Segmentierung auf Basis von Ressourcen mit unterschiedlichen Sicherheitsanforderungen über Subnetze vorzunehmen. Das Subnetz ist auch die primäre Sicherheitsbarriere, da mit Hilfe von sogenannten NSGs (Network Security Groups) in weiterer Folge der gesamte Netzwerkzugriff auf Ressourcen innerhalb des Subnetzes gesteuert wird.

Region

Ein VNET ist immer auf eine Azure Region beschränkt. Über das sogenannte VNET-Peering können virtuelle Azure Netzwerke regionsübergreifend miteinander verbunden werden. Der gesamte Datenverkehr erfolgt dabei ausschließlich über das interne, private Microsoft global network (MGN) über welches alle Azure Regionen miteinander verbunden sind.

Abbildung 2.1-1: Beispiel eines Azure Netzwerkkonzeptes

Multiple Netzwerkkarten

Nahezu alle IaaS-VMs und über den Marketplace angebotene virtuelle Appliances unterstützen mehrere Netzwerkkarten um ein einfaches Traffic-Management (beispielsweise isolierte Segmentierung mittels VM Firewall) abbilden zu können.

Abbildung 2.1-2: Azure Ressource mit multipler NIC Konfiguration

2.1.2 Service Endpoints

In jedem hybriden Umfeld kommt es normalerweise zur Nutzung von PaaS Diensten, welche per Design ausschließlich über die öffentliche Cloud angeboten werden (Shared managed Services). Um die Sicherheit beim Zugriff bzw. bei der Nutzung der PaaS Dienste aus dem eigenen VNET (Private Cloud) heraus können sogenannte Service Endpoints (Dienstendpunkte) definiert werden.

Die Service Endpoint Konfiguration bietet mehrere Vorteile:

• Erhöhte Sicherheit durch Zugriff auf die PaaS Dienste über das VNET und nicht dem Internet
• Direkte Weiterleitung über das Microsoft global network. Dadurch erfolgt die Nutzung der PaaS Dienste über hoch performante private Verbindungen mit niedriger Latenz
• Einfache Verwaltung da für den Verbindungsaufbau keine Gateway- und NAT Konfigurationen notwendig sind

Aktuell (Q1-2021) sind über die Service Endpoint Konfiguration nicht alle PaaS Dienste konfigurierbar, das Angebot wird allerdings ständig erweitert. Wichtige PaaS Dienste wie beispielsweise Azure Storage, Azure SQL oder auch Azure KeyVault sind bereits über diese Funktion verfügbar.

Abbildung 2.1-3: Service Endpoint Konfiguration

2.1.3 VPN Gateway

Ein VPN Gateway wird immer in einem eigenen Subnetz (GatewaySubnet) des VNETs provisioniert und stellt eine verschlüsselte und stetige Verbindung zwischen dem VNET in der Azure Cloud und einem lokalen Netzwerk über das Internet her. Das VPN Gateway wird auch für die Kommunikation zwischen zwei VNETs über das interne Microsoft global network verwendet.

Beim Anlegen des VPN Gateways muss eine Leistungsklasse definiert werden, alle VPN Verbindungen teilen sich in weitere Folge die Leistung dieses VPN Gateways. Aktuell gibt es 15 verschiedene VPN Gateway Klassen, das erste VPN Gateway Service (VPN Basic) startet z.B. bei 100Mbit/sec aggregierten Durchsatz und unterstützt maximal 10 gleichzeitige Site-2-Site VPN Verbindungen. Das aktuell leistungsstärkste VPN Gateway hat einen aggregierten Datendurchsatz von 10 Gbit/sec und unterstützt maximal 30 gleichzeitige Site-2-Site Verbindungen.

Nach der Erstellung des VPN Gateways im VNET über ein eigenes dediziertes Subnetz (Name lautet dabei immer GatewaySubnet) können folgende Verbindungen hergestellt werden:

Bei der Planung muss sichergestellt werden, dass das lokal eingesetzte VPN Device kompatibel ist und einen permanenten Site-2-Site Tunnel zur Microsoft Azure Infrastruktur herstellen kann.

Site-2-Site Verbindungen (S2S)

• Öffentliche IP-Adresse des Azure VPN Gateways (Microsoft)
• Öffentliche statische IP-Adresse des lokalen VPN Device welche nicht hinter einer Firewall liegen darf oder nur über eine aktive NAT Konfiguration erreichbar ist

Abbildung 2.1-4: Beispiel – Multi Site-2-Site Verbindung

Point-2-Site Verbindungen (P2S)

• Öffentliche IP-Adresse des Azure VPN Gateways (Microsoft)
• Keine lokale öffentliche statische IP-Adresse oder ein VPN Device erforderlich
• Herstellung von sicheren Verbindungen von einem Endgerät aus über Software-VPN in das Azure VNET und damit allen an das VNET angebunden Netzwerke
• Unterstützung der Multi-Faktor Authentifizierung

Abbildung 2.1-5: Beispiel – P2S Verbindungen

2.1.4 ExpressRoute

ExpressRoute Verbindungen laufen nicht über das öffentliche Internet, sondern über private MPLS Leitungen welche vom jeweiligen lokalen Internet-Provider direkt zum nächstgelegenen Einstiegspunkt des MGN (Microsoft Global Network) geschalten werden. Damit bieten ExpressRoute Verbindungen eine höhere Sicherheit, größere Zuverlässigkeit (sie werden standardmäßig immer über 2 parallele Verbindungen geschalten) und eine höhere Performance bei geringerer Latenz als herkömmliche öffentliche Verbindungen.

• Layer-3 Konnektivität direkt zum MGN über Any-to-Any VPN oder Point-to-Point Ethernet MPLS / WAN Verbindungen
• Dynamisches Routing (BGP) innerhalb des MGN zu den öffentlichen Diensten (Office365) bzw. den privaten Diensten der Azure Cloud (VNET)
• Integrierte Redundanz zu jedem Peering-Standort über MPLS
• QoS Unterstützung
• Flexibles Abrechnungsmodell (Flat-Rate / Daten-Taktung) und dynamische Skalierung der Bandbreite möglich

Abbildung 2.1-6: Darstellung ExpressRoute – Quelle: Microsoft TechNet

Azure ExpressRoute, Site-2-Site und Point-2-Site Verbindungen können beliebig miteinander kombiniert werden, um für jeden Standort bzw. jede Anforderung die optimale Technologie (natürlich auch abhängig von der Verfügbarkeit am Standort) einsetzen zu können. Seit Mitte 2019 wird an einigen Standorten auch ExpressRoute Direct...