Entwicklerzugriff mit Point-to-Site-VPN¶
Mit einem Zero-Trust-Ansatz haben die meisten Azure-Ressourcen keinen öffentlichen Endpunkt: Sie sind nur über ein privates Netzwerk erreichbar. Dennoch müssen Engineers von dort, wo sie arbeiten, Storage Accounts, Key Vaults und Datenbanken in ihren Spokes erreichen. Ein Point-to-Site-(P2S-)VPN in das Virtual WAN ist eine Möglichkeit, das anzubieten. Diese Seite beschreibt ein Design und die Überlegungen dahinter. Es ist ein Muster, keine Beschreibung dessen, was jede Plattform hat.
Was MCP bietet
Die Plattform kann ein Point-to-Site-VPN-Gateway erstellen (create_point_to_site_vpn_gateway, siehe
Plattform-Features). Die unten beschriebene Segmentierung pro workload
(Benutzergruppen mit eigenen Adresspools, firewall-Regeln pro Pool) ist ein Design auf dieser Grundlage. Prüfe, was deine
Plattform umsetzt, bevor du es Teams zusagst.
Umfang¶
- Zugriff vom Gerät eines Engineers auf workload-Spokes: private endpoints, Key Vaults, Storage Accounts, virtuelle Maschinen.
- Kein Zugriff auf On-Premises-Standorte, Niederlassungen von Tochtergesellschaften oder SaaS-Dienste. Halte diese aus dem workload-VPN heraus.
- Nur für Nutzer der Plattform.
Prinzipien¶
| Prinzip | Grund |
|---|---|
| Eine bestehende Plattform (Virtual WAN) nutzen statt einer neuen | Weniger Plattformen bedeuten weniger Komplexität, Kosten und Wartung |
| Anmeldung mit Entra-ID-Single-Sign-On und Conditional Access | Ein zentraler Ort für Authentifizierung und Autorisierungs-Policy |
| Die Datenklassifizierung bestimmt die Conditional-Access-Policy | Die Klassifizierung gibt den Schutz vor |
| Den VPN-Zugriff konfigurieren, wenn der workload erstellt wird | Weniger Änderungsanfragen |
| Die Autorisierung auf das Rollenmodell des workloads stützen, nicht auf einzelne Zuweisungen | Weniger Wartung |
| Nicht-Produktions-Spokes: für alle Nutzer erreichbar, für die erlaubten Protokolle | Einfach, und Produktion wird separat geschützt |
| Produktions-Spokes: Der Zugriff braucht eine PIM-Aktivierung, die vom Genehmiger des workloads freigegeben wird | Produktionszugriff ist explizit und wird protokolliert |
| Eine Produktionssitzung erreicht nur einen workload | Verhindert direkten Datenaustausch zwischen Produktions-workloads |
Designentscheidungen¶
| Entscheidung | Grund |
|---|---|
| Ein separates P2S-Gateway im Virtual WAN, nicht das Site-to-Site-Gateway | Die Bandbreite der Site-Verbindungen wird nicht beeinträchtigt, und es skaliert unabhängig |
| Hochverfügbar, aber zunächst klein | Der P2S-Zugriff ist für den Support kritisch, die anfängliche Nutzung ist aber begrenzt |
| P2S-Konfiguration und firewall-Regeln werden im hub gepflegt | Verhindert Missbrauch |
| Zwei Client-Adresspools: einer für Nicht-Produktion, einer für Produktion, reserviert aus dem Connectivity-Bereich | Die Quell-IP eines Pakets zeigt dann, ob der Benutzer für Nicht-Produktion oder für Produktion freigegeben war |
| Im Produktionspool ein kleines Subnetz pro workload (ein /28 oder /29, je nach Anzahl der Benutzer) | Isoliert eine Produktionssitzung auf einen workload |
| Eine Produktions-Benutzergruppe hat Vorrang vor der generischen Nicht-Produktions-Gruppe | Ein Produktionsbenutzer behält die Isolation auf diesen workload |
| Die firewall-Regel für Nicht-Produktion ist generisch und liegt bei den Plattformregeln. Die firewall-Regeln für Produktion sind Teil der eigenen Regeldatei des workloads. | Die Regel wird zusammen mit dem workload entfernt oder geändert |
Technische Hinweise¶
- Protokoll und Clients. OpenVPN ist das Protokoll, das Entra-ID-Authentifizierung und sowohl Windows- als auch macOS-Clients unterstützt. Prüfe die aktuelle Client-Unterstützung für andere Systeme.
- Benutzergruppen. Azure P2S unterstützt Benutzergruppen, die eine Entra-ID-Identität einem Adresspool zuordnen. Nutze eine Gruppe für Nicht-Produktion und eine pro workload für Produktion.
- Split Tunnelling. Nur Verkehr nach Azure läuft durch das VPN. Internetverkehr passiert nicht die Azure Firewall. Sende den gesamten DNS-Verkehr nach Azure, damit private Namen aufgelöst werden (DNS-Design).
- Kosten. Plane die Scale Unit und die Connection Units. Ein kleines Deployment mit einer Scale Unit und einer Handvoll Verbindungen ist günstig; der Datentransfer wird zusätzlich berechnet.
- Monitoring. Alarmiere bei Verfügbarkeit des Gateways, Bandbreitennutzung und Anzahl gleichzeitiger Verbindungen.
Conditional Access nach Datenklassifizierung¶
| Datenklassifizierung | Zugriff auf | Typische Policy |
|---|---|---|
| Niedrig (Nicht-Produktion) | Nicht-Produktions-Spokes | MFA erforderlich, Anmelde- und Benutzerrisiko bei Medium |
| Mittel (Produktion) | Der Produktions-Spoke des workloads | MFA erforderlich, höhere Risikoschwellen als bei der Nicht-Produktions-Policy |
| Hoch (Produktion) | Der Produktions-Spoke des workloads | Die mittlere Policy plus ein konformes Gerät und eine Standortbeschränkung |
Die Stufen und Schwellenwerte sind Beispiele. Siehe Sicherheitsklassifizierung.
Prozesse¶
Wenn ein workload erstellt wird:
- Füge die Benutzer der Gruppe für den VPN-Zugriff auf Nicht-Produktion hinzu.
- Erstelle eine Entra-ID-Gruppe für den VPN-Zugriff auf Produktion.
- Richte den PIM-Prozess für diese Gruppe ein.
- Erstelle die firewall-Regel für den Produktionszugriff in der Regeldatei des workloads.
- Erstelle die Benutzergruppe in der P2S-Konfiguration.
Wenn einem workload ein Spoke hinzugefügt wird: Ändere die firewall-Regel so, dass sie den Adressbereich des Spokes enthält.