In diesem Artikel wir den 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 für Sie eingerichtet. Dieses Netzwerk wird in Azure Spoke genannt und wird automatisch mit dem Hub in Azure verbunden, welches 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. Die Ressource bekommt automatisch einen privaten IP Bereich zugewiesen, welcher direkt vom Netzwerk der Universität Bern erreichbar 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 sind somit durch den Subscription-Inhaber zu definieren.

Je nach bereitgestelltem Adressbereich ist es denkbar, dass entweder ein grosses oder mehrere kleinere 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.

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.

Network Security Group

Die Network Security Group (NSG) bietet einfache Firewall-Regeln für das eigene Subnetz, womit sich die Dienste durch die Nutzenden schützen lassen. In einer Corp Subscription wird automatisch eine Standard-NSG erstellt. Diese kann an die eigenen Bedürfnisse angepasst werden.

So 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 in der Universität 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 eine DNS-Zone in Azure basierend auf dessen 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 testvm01 wird also automatisch testvm01.<institutskürzel>..azure.cloud.unibe.ch erstellt 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 => Anleitung: Benutzerdefinierte DNS-Einträge.
• Die Namensauflösung für PaaS-Dienste wird in dienstspezifischen Zonen geführt, z.B. privatelink.azurewebsites.net oder privatelink.vaultcore.azure.net. Einträge in diesen Zonen werden automatisch durch Policies verwaltet. Manuelle Einträge sind hier nicht nötig und möglich => Anleitung: PrivateLink DNS Eintrag.

Ö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:

1. Der Dienst kommuniziert über das Hypertext Transfer Protocol (HTTP/HTTPS)
2. Der Dienst erstellt einen TCP/UDP-Socket, aber nutzt 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, muss er folgende Voraussetzungen erfüllen:

1. Der Dienst muss über HTTP/HTTPS erreichbar sein. Der Port ist dabei nicht relevant.
2. Das Application Gateway benötigt einen URL-Endpunkt, um den Status des Dienstes zu ermitteln (Health Probe).
3. Der Dienst hat einen DNS-Eintrag im Azure Private DNS und ein gültiges Zertifikat.
4. 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 müssen 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 exponieren.

Die Registrierung neuer Services auf der Firewall müssen per Ticket an die ID bestellt werden.

Nächste Schritte

Für alle Anpassungen wurde bisher zum das Azure Portal verwiesen. Azure bietet zudem einen Command Line Interface (CLI) client az an. Damit lassen sich Ressourcen via Scripts erstellen und ändern, was einige Vorteile mit sich bringt => Anleitung Azure CLI client.

Weiterführende Informationen

• Network Security Group (NSG)
• Azure Private DNS