In diesem Artikel wird der Subscription-Typ Corp Subscription genauer beleuchtet, da er sich deutlich von den anderen beiden Typen unterscheidet.
Netzwerk
Bei der Erstellung der Corp Subscription wird automatisch ein Virtual Network eingerichtet. Dieses Netzwerk wird in Azure Spoke genannt und wird automatisch mit dem Hub in Azure verbunden, welcher wiederum mit dem Netzwerk der Universität Bern verbunden ist.
Nachfolgendes Diagramm zeigt den groben Aufbau:
architecture-beta
group unibe[UniBE]
group azure(logos:azure)
group connectivity(azure:subscriptions)[Connectivity] in azure
group subscription(azure:subscriptions)[UserSubscription] in azure
group vnetHub(azure:virtual-networks)[Hub] in connectivity
service azfirewall(simple-icons:fortinet)[Firewall] in vnetHub
group vnetSpoke(azure:virtual-networks)[Spoke] in subscription
service webapp(azure:virtual-machine)[App] in vnetSpoke
service firewall(simple-icons:fortinet)[Firewall] in unibe
webapp{group}:R -- L:azfirewall{group}
azfirewall{group}:R -- L:firewall{group}
Das Virtual Network ist als Ressource in der erstellten Corp Subscription sichtbar. Der Ressource wird automatisch ein privater IP-Bereich zugewiesen, welcher direkt vom Netzwerk der Universität Bern erreichbar ist.
Important
Diese Ressource wird automatisch von den ID zur Verfügung gestellt. Ausser im Rahmen der unten aufgeführten Vorgänge dürfen am Virtual Network keine Änderungen vorgenommen werden, da sonst dessen korrekte Funktion nicht mehr gewährleistet ist.
Der Adressbereich hat eine definierte Grösse, welche bei der Bestellung angegeben werden kann. Falls die initiale Grösse nicht genügt, kann mit den ID Kontakt aufgenommen werden, um diesen zu vergrössern.
Subnetz
Im bereitgestellten Virtual Network müssen zunächst Subnetze erstellt werden. In diesen können danach Services von Azure platziert werden. Die Netzwerksegmentierung ist abhängig von Services, die darin bereitgestellt werden sollen, und ist somit vom Subscription-Inhaber zu definieren.
Je nach bereitgestelltem Adressbereich kann entweder ein grosses oder mehrere kleinere Subnetze verwendet werden. Die nachfolgende Tabelle illustriert beispielhaft die Subnettierung eines Netzwerks der Grösse /26. Die Tabelle ist nicht abschliessend. Es ist auch möglich, unterschiedlich grosse Subnetze zu bilden.
| Adressbereich | Subnetze | Anzahl Adressen | Subnetz Adressbereiche |
|---|---|---|---|
| 10.32.0.0/26 | 1 | 59 |
|
| 10.32.0.0/26 | 2 | 2 * 27 |
|
| 10.32.0.0/26 | 4 | 4 * 11 |
|
Note
In jedem Subnetz sind die ersten drei IPs (x.x.x.1, x.x.x.2 und x.x.x.3) von Azure reserviert und stehen nicht zur Verfügung.
Route Table
Sämtlicher Datenverkehr wird in den Corp Subscriptions über die Azure Firewall der ID geleitet. Daher muss bei der Erstellung eines Subnetzes auch zwingend eine Route Table ausgewählt werden, die von der ID zur Verfügung gestellt wird. Diese Route Table setzt für das gesamte Subnetz die Firewall als Standardgateway.
Note
Als Benutzer kann weder eine eigene Route Table erstellt noch die von den ID zur Verfügung gestellte verändert werden! Falls ein Dienst eine angepasste Route Table benötigt, kann Kontakt mit den ID aufgenommen werden.
Network Security Group
Die Network Security Group (NSG) bietet einfache Firewall-Regeln für das eigene Subnetz, womit die Dienste durch die Nutzenden geschützt werden können. In einer Corp Subscription wird automatisch eine Standard-NSG erstellt. Diese kann an die eigenen Bedürfnisse angepasst werden.
Note
Die Standard-NSG verhindert den direkten Netzwerkverkehr vom Internet zum Subnetz. Selbst wenn dies angepasst würde, könnte wegen der Route Table keine Kommunikation von extern aufgebaut werden.
Wie bei der Route Table wird eine NSG beim Erstellen eines neuen Subnetzes vorausgesetzt.
DNS
Azure DNS ist mit dem DNS der Universität Bern integriert. Somit sind die Zonen der Azure Cloud auch innerhalb der Universität Bern abfragbar und Änderungen am Azure DNS unmittelbar auch innerhalb des DNS der Universität Bern sichtbar.
Für das Azure DNS sind zwei Anwendungsfälle relevant:
- Für jede Organisationseinheit gibt es eine DNS-Zone in Azure basierend auf deren Kürzel gemäss dem Schema
<institutskürzel>.azure.cloud.unibe.ch. Diese Zone wird primär für virtuelle Maschinen und Benutzereinträge verwendet.- Für virtuelle Maschinen wird automatisch ein DNS-Eintrag mit dem Namen der virtuellen Maschine innerhalb dieser Zone erstellt. Für eine VM
testvm01wird also automatischtestvm01.<institutskürzel>.azure.cloud.unibe.cherstellt und mit der korrekten IP-Adresse verknüpft. - Eigene arbiträre Einträge in dieser (und nur in dieser) Zone können über das Portal erstellt werden. Eine Anleitung ist im Tutorial Benutzerdefinierte DNS-Einträge zu finden.
- Für virtuelle Maschinen wird automatisch ein DNS-Eintrag mit dem Namen der virtuellen Maschine innerhalb dieser Zone erstellt. Für eine VM
- Die Namensauflösung für PaaS-Dienste wird in dienstspezifischen Zonen geführt, z. B.
privatelink.azurewebsites.netoderprivatelink.vaultcore.azure.net. Einträge in diesen Zonen werden automatisch durch Policies verwaltet. Manuelle Einträge sind hier nicht nötig und möglich. Eine Anleitung ist im Tutorial PrivateLink DNS Eintrag zu finden.
Important
Bei vielen Diensten wird bei deren Erstellung die Option angeboten, eine neue DNS-Zone für den Dienst erstellen zu lassen. Diese Option ist stets abzuwählen, da diese Zonen durch Policies automatisch erstellt werden. Ist die Option aktiv, schlägt die Erstellung des Dienstes mit einer entsprechenden Fehlermeldung fehl.
Warning
Die Ressourcen in einer Corp Subscription sind standardmässig nur innerhalb des Netzwerks erreichbar. Die Namensauflösung erfolgt jedoch weltweit, die Ressourcen können jedoch nicht erreicht werden.
Note
Domäneneinträge in der Zone .unibe.ch müssen per Ticket an den Hostmaster der Universität Bern bestellt werden.
Öffentliche Zugang
Falls ein Dienst in einer Corp Subscription bereitgestellt wird, der aus dem Internet erreichbar sein soll, kann dies in Zusammenarbeit mit der ID realisiert werden.
Dabei ist zwischen zwei Szenarien zu unterscheiden, abhängig davon, auf welche Art und Weise der Dienst erreichbar ist:
- Der Dienst kommuniziert über das Hypertext Transfer Protocol (HTTP/HTTPS)
- Der Dienst erstellt einen TCP/UDP-Socket, nutzt jedoch nicht HTTP/HTTPS
Internet nach Azure HTTP/HTTPS
Die ID betreibt ein zentrales , welches externe Anfragen annimmt und nach intern weiterleitet.
architecture-beta
group azure(logos:azure)
group connectivity(azure:subscriptions)[Connectivity] in azure
group subscription(azure:subscriptions)[UserSubscription] in azure
group vnetHub(azure:virtual-networks)[Hub] in connectivity
group vnetAppGW(azure:virtual-networks)[AppGateway] in connectivity
group vnetSpoke(azure:virtual-networks)[Spoke] in subscription
service azfirewall(simple-icons:fortinet)[Firewall] in vnetHub
service webapp(azure:virtual-machine)[App] in vnetSpoke
service appgw(azure:application-gateway)[Application Gateway] in vnetAppGW
service appgwpip(azure:public-ip)[Public IP] in vnetAppGW
appgwpip:R -- L:appgw
appgw:R -- L:azfirewall
azfirewall:T -- B:webapp
Um einen Dienst per HTTP/HTTPS auf dem Application Gateway aufschalten zu können, müssen folgende Voraussetzungen erfüllt sein:
- Der Dienst muss über HTTP/HTTPS erreichbar sein. Der Port ist dabei nicht relevant.
- Das Application Gateway benötigt einen URL-Endpunkt, um den Status des Dienstes zu ermitteln (Health Probe).
- Der Dienst hat einen DNS-Eintrag im Azure Private DNS und ein gültiges Zertifikat.
- Ein öffentlicher kanonischer DNS-Eintrag (CNAME) zeigt auf das Application Gateway
appgateway-azure-cloud.id.unibe.ch.
Die Registrierung neuer Services auf dem Application Gateway muss per Ticket an die ID bestellt werden.
Internet nach Azure Non-HTTP/HTTPS
In diesem Szenario muss auf der zentralen Firewall die Portnummer registriert werden, welche die Applikation exponiert.
Die Registrierung neuer Services auf der Firewall muss per Ticket an die ID bestellt werden.
Nächste Schritte
Für alle Anpassungen wurde bisher auf das Azure Portal verwiesen. Azure bietet zudem einen Command Line Interface (CLI) Client az an. Damit können Ressourcen via Scripts erstellt und geändert werden, was einige Vorteile mit sich bringt. Eine entsprechende Anleitung ist im Artikel Azure CLI zu finden.