Corp

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.

Achtung

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
10.32.0.0/26	2	2 * 27	10.32.0.0/27 10.32.0.32/27
10.32.0.0/26	4	4 * 11	10.32.0.0/28 10.32.0.16/28 10.32.0.32/28 10.32.0.48/28

Hinweis

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.

Hinweis

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.

Hinweis

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 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. Eine Anleitung ist im Tutorial Benutzerdefinierte DNS-Einträge zu finden.
• 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. Eine Anleitung ist im Tutorial PrivateLink DNS Eintrag zu finden.

Achtung

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.

Achtung

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.

Hinweis

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:

1. Der Dienst kommuniziert über das Hypertext Transfer Protocol (HTTP/HTTPS)
2. Der Dienst erstellt einen TCP/UDP-Socket, nutzt jedoch nicht HTTP/HTTPS

Internet nach Azure HTTP/HTTPS

Die ID betreibt ein zentrales Microsoft Azure Application Gateway, 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:

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 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.

Weiterführende Informationen

• Network Security Group (NSG)
• Azure Private DNS