Überlegungen zur Verwendung von Domänennamen in einer mehrinstanzenfähigen Lösung

In vielen mehrinstanzenfähigen Webanwendungen kann ein Domänenname zur Identifizierung eines Mandanten, zur Unterstützung bei der Anforderungsweiterleitung an die korrekte Infrastruktur und zur Bereitstellung eines Markenerlebnisses für Ihre Kunden genutzt werden. Zwei gängige Ansätze sind die Verwendung von Unterdomänen und benutzerdefinierten Domänennamen. Auf dieser Seite bieten wir technischen Entscheidungsträgern eine Orientierungshilfe zu den in Frage kommenden Ansätzen und deren Kompromissen.

Unterdomänen

Jedem Mandanten kann eine eindeutige Unterdomäne unter einem gemeinsam genutzten Domänennamen zugewiesen werden. Das Format kann dabei beispielsweise wie folgt aussehen: tenant.provider.com.

Betrachten wir ein Beispiel für eine mehrinstanzenfähige Lösung, die von Contoso erstellt wurde. Kunden erwerben das Produkt von Contoso, um ihre Rechnungserstellung zu verwalten. Allen Mandanten von Contoso kann unter dem Domänennamen contoso.com eine eigene Unterdomäne zugewiesen werden. Bei Verwendung regionaler Bereitstellungen können alternativ Unterdomänen unter den Domänen us.contoso.com und eu.contoso.com zugewiesen werden. In diesem Artikel werden diese Domänen als Stammdomänen bezeichnet. Jeder Kunde erhält seine eigene Unterdomäne unter Ihrer Stammdomäne. Beispielsweise kann Tailwind Toys die Unterdomäne tailwind.contoso.com zugewiesen werden, und Adventure Works erhält die Unterdomäne adventureworks.contoso.com.

Verwalten Ihres Domänennamespace

Wenn Sie Unterdomänen unter Ihrem eigenen Domänennamen erstellen, müssen Sie bedenken, dass Sie über mehrere Kunden mit ähnlichen Namen verfügen können. Aufgrund der gemeinsamen Verwendung einer einzelnen Stammdomäne erhält der erste Kunde, der sich eine bestimmte Domäne sichert, den von ihm bevorzugten Namen. Nachfolgende Kunden müssen alternative Unterdomänennamen verwenden, da vollständige Domänennamen global eindeutig sein müssen.

Platzhalter-DNS-Einträge

Erwägen Sie die Verwendung von Platzhalter-DNS-Einträgen, um die Verwaltung von Unterdomänen zu vereinfachen. Anstelle einer Erstellung von DNS-Einträgen für tailwind.contoso.com, adventureworks.contoso.com usw. könnten Sie stattdessen einen Platzhaltereintrag für *.contoso.com erstellen und alle Unterdomänen auf eine einzige IP-Adresse (A-Eintrag) oder einen kanonischen Namen (CNAME-Eintrag) verweisen.

Unterdomänen mit mehrteiligen Stammdomänen

Viele mehrinstanzenfähige Lösungen sind auf mehrere physische Bereitstellungen verteilt. Dies ist eine übliche Vorgehensweise, wenn Sie die Anforderungen an die Datenresidenz erfüllen müssen oder wenn Sie eine bessere Leistung erzielen möchten, indem Sie Ressourcen in geografischer Nähe zu den Benutzern bereitstellen.

Selbst innerhalb einer einzelnen Region kann es zur Unterstützung Ihrer Skalierungsstrategie erforderlich sein, Ihre Mandanten auf unabhängige Bereitstellungen zu verteilen. Wenn Sie Unterdomänen für jeden Mandanten verwenden möchten, können Sie eine mehrteilige Unterdomänenstruktur in Betracht ziehen.

Ein Beispiel: Contoso veröffentlicht eine mehrinstanzenfähige Anwendung für seine vier Kunden. Adventure Works und Tailwind Traders sind in den USA ansässig, und ihre Daten werden auf einer freigegebenen Instanz der Contoso-Plattform in den USA gespeichert. Fabrikam und Worldwide Importers haben ihren Sitz in Europa, und ihre Daten werden auf einer europäischen Instanz gespeichert.

Wenn Contoso sich für die Verwendung einer einzelnen Stammdomäne (contoso.com) für alle Kunden entscheidet, könnte dies wie folgt aussehen:

Die DNS-Einträge (die zur Unterstützung dieser Konfiguration erforderlich sind) können wie folgt aussehen:

Für jeden neu integrierten Kunden wird eine neue Unterdomäne benötigt, und die Anzahl von Unterdomänen steigt mit jedem Kunden.

Alternativ könnte Contoso bereitstellungs- oder regionsspezifische Stammdomänen wie diese verwenden:

In diesem Fall können Platzhalter-DNS-Einträge verwendet und die DNS-Einträge für diese Bereitstellung somit wie folgt aussehen:

Contoso muss nicht für jeden Kunden Unterdomäneneinträge erstellen. Stattdessen steht ein einzelner Platzhalter-DNS-Eintrag für die Bereitstellung in der jeweiligen geografischen Region zur Verfügung, und alle neuen Kunden, die unterhalb dieses Stamms hinzugefügt werden, erben automatisch den CNAME-Eintrag.

Jeder dieser Ansätze hat Vor- und Nachteile. Wenn Sie eine einzelne Stammdomäne verwenden, muss für jeden Mandanten, den Sie integrieren, ein neuer DNS-Eintrag erstellt werden. Dies führt zu einem operativen Mehraufwand. Gleichzeitig erhalten Sie jedoch mehr Flexibilität, um Mandanten zwischen Bereitstellungen zu verschieben, da Sie den CNAME-Eintrag ändern können, um den Datenverkehr an eine andere Bereitstellung weiterzuleiten. Diese Änderung wirkt sich nicht auf andere Mandanten aus. Bei Verwendung mehrerer Stammdomänen ist der Verwaltungsaufwand geringer. Außerdem können Sie Kundennamen in mehreren regionalen Stammdomänen wiederverwenden, da jede Stammdomäne praktisch einen eigenen Namespace darstellt.

Benutzerdefinierte Domänennamen

Vielleicht möchten Sie Ihren Kunden die Möglichkeit geben, weiterhin ihre eigenen Domänennamen zu verwenden. Einige Kunden betrachten dies als wichtigen Aspekt ihres Brandings. Benutzerdefinierte Domänennamen können auch erforderlich sein, um die Sicherheitsanforderungen der Kunden zu erfüllen – insbesondere, wenn diese ihre eigenen TLS-Zertifikate bereitstellen müssen. Wenngleich es trivial erscheinen mag, Kunden die Weiterverwendung ihrer eigenen Domänennamen zu ermöglichen, birgt dieser Ansatz einige Herausforderungen und erfordert eine gut durchdachte Planung.

Namensauflösung

Letztendlich muss jeder Domänenname in eine IP-Adresse aufgelöst werden. Wie Sie gesehen haben, kann der Ansatz für die Namensauflösung davon abhängen, ob Sie eine einzelne Instanz oder mehrere Instanzen Ihrer Lösung bereitstellen.

Kehren wir nun zu unserem Beispiel zurück. Einer der Kunden von Contoso, Fabrikam, möchte invoices.fabrikam.com als benutzerdefinierten Domänennamen für den Zugriff auf den Dienst von Contoso verwenden. Da Contoso über mehrere Bereitstellungen seiner Plattform verfügt, beschließt das Unternehmen, zur Erfüllung seiner Routinganforderungen Unterdomänen und CNAME-Einträge zu verwenden. Contoso und Fabrikam konfigurieren die folgenden DNS-Einträge:

Aus Sicht der Namensauflösung löst diese Kette von Einträgen Anforderungen für invoices.fabrikam.com ordnungsgemäß in die IP-Adresse der europäischen Bereitstellung von Contoso auf.

Hostheaderauflösung

Die Namensauflösung ist nur die Hälfte des Problems. Alle Webkomponenten (innerhalb der europäischen Bereitstellung von Contoso) müssen wissen, wie eingehende Anforderungen verarbeitet werden sollen, die im Host-Anforderungsheader den Domänennamen von Fabrikam enthalten. Abhängig von den spezifischen Webtechnologien, die Contoso verwendet, kann dies eine weitere Konfiguration für den Domänennamen jedes Mandanten erforderlich machen, was wiederum den Verwaltungsaufwand für das Onboarding von Mandanten erhöht.

Sie können auch das Umschreiben von Hostheadern in Betracht ziehen, sodass dem Webserver unabhängig vom Host-Header der eingehenden Anforderung ein konsistenter Headerwert angezeigt wird. Beispielsweise können Sie mit Azure Front Door Host-Header umschreiben, sodass Ihr Anwendungsserver unabhängig von der Anforderung einen einzelnen Host-Header empfängt. Azure Front Door gibt den ursprünglichen Hostheader im X-Forwarded-Host-Header weiter, damit Ihre Anwendung diesen untersuchen und dann den Mandanten nachschlagen kann. Das Umschreiben eines Host-Headers kann jedoch andere Probleme verursachen. Weitere Informationen finden Sie unter Beibehalten von Hostnamen.

Domänenüberprüfung

Es ist wichtig, vor dem Onboarding den Besitz benutzerdefinierter Domänen zu überprüfen. Andernfalls besteht das Risiko, dass ein Kunde versehentlich oder in böser Absicht einen Domänennamen parkt.

Betrachten wir das Onboardingverfahren von Contoso für Adventure Works, die die Verwendung von invoices.adventureworks.com als benutzerdefinierten Domänennamen beantragt haben. Leider ist es beim Einbinden des benutzerdefinierten Domänennamens zu einen Tippfehler gekommen und die zwei s wurden übersehen. Der Domänenname wurde deshalb als invoices.adventurework.com eingerichtet. Dies verursacht zwei Probleme: 1. Der Datenverkehr wird für Adventure Works nicht ordnungsgemäß weitergeleitet. 2. Ein anderes Unternehmen mit dem Namen Adventure Work würde beim Hinzufügen seiner benutzerdefinierten Domäne zur Contoso-Plattform den Hinweis erhalten, dass die Domäne bereits verwendet wird.

Bei der Arbeit mit benutzerdefinierten Domänen, insbesondere im Rahmen von Self-Service-Verfahren oder automatisierten Prozessen, wird üblicherweise ein Schritt zur Überprüfung der Domäne vorgeschrieben. Dies kann es erforderlich machen, dass die CNAME-Einträge eingerichtet werden, bevor die Domäne hinzugefügt werden kann. Alternativ kann Contoso eine zufällige Zeichenfolge generieren und Adventure Works bitten, einen DNS-TXT-Eintrag mit dem Zeichenfolgenwert hinzuzufügen. Dadurch wird verhindert, dass der Domänenname hinzugefügt wird, bevor die Überprüfung abgeschlossen wurde.

Verwaiste DNS-Einträge und Angriffe zur Übernahme von Unterdomänen

Wenn Sie mit benutzerdefinierten Domänennamen arbeiten, sind Sie potenziell anfällig für eine bestimmte Angriffsklasse, auch bezeichnet als verwaiste DNS-Einträge oder Übernahme von Unterdomänen. Ein solcher Angriff kann erfolgen, wenn Kunden ihren benutzerdefinierten Domänennamen von Ihrem Dienst trennen, aber den Eintrag nicht von ihrem DNS-Server löschen. Dieser DNS-Eintrag verweist dann auf eine nicht vorhandene Ressource und ist anfällig für eine Übernahme.

Betrachten wir, wie sich die Beziehung zwischen Fabrikam und Contoso ändern könnte:

1. Fabrikam hat sich entschieden, nicht länger mit Contoso zusammenzuarbeiten, deshalb wurde die Geschäftsbeziehung beendet.
2. Contoso hat für den Fabrikam-Mandanten ein Offboarding durchgeführt und die Deaktivierung von fabrikam.contoso.com angefordert. Fabrikam hat jedoch vergessen, den CNAME-Eintrag für zu invoices.fabrikam.com löschen.
3. Ein böswilliger Akteur erstellt ein neues Contoso-Konto und gibt ihm den Namen fabrikam.
4. Der Angreifer integriert den benutzerdefinierten Domänennamen invoices.fabrikam.com in seinen neuen Mandanten. Da Contoso eine CNAME-basierte Domänenvalidierung durchführt, wird der DNS-Server von Fabrikam überprüft. Sie stellen fest, dass der DNS-Server einen CNAME-Eintrag für invoices.fabrikam.com zurückgibt, der auf fabrikam.contoso.com verweist. Contoso betrachtet die Überprüfung der benutzerdefinierten Domäne als erfolgreich.
5. Wenn Fabrikam-Mitarbeiter versuchten, auf die Website zu zugreifen, scheinen die Anforderungen zu funktionieren. Wenn der Angreifer seinen Contoso-Mandanten mit dem Fabrikam-Branding einrichtet, könnten Mitarbeiter dazu verleitet werden, auf die Website zuzugreifen und sensible Daten bereitzustellen, auf die der Angreifer dann zugreifen kann.

Gängige Strategien zum Schutz vor DNS-Angriffen:

• Legen Sie fest, dass der CNAME-Eintrag gelöscht werden muss, bevor der Domänenname aus dem Konto des Mandanten entfernt werden kann.
• Verhindern Sie die Wiederverwendung von Mandantenbezeichnern, und legen Sie fest, dass der Mandant einen TXT-Eintrag mit einem Namen erstellen muss, der sich aus dem Domänennamen und einem Zufallswert zusammensetzt, welcher sich bei jedem Onboardingversuch ändert.

TLS-/SSL-Zertifikate

Transport Layer Security (TLS) ist eine wesentliche Komponente bei der Arbeit mit modernen Anwendungen. TLS-Zertifikate bietet Vertrauen und Sicherheit für Ihre Webanwendungen. Der Besitz und die Verwaltung von TLS-Zertifikaten ist bei mehrinstanzenfähigen Anwendungen ein Punkt, der sorgfältig geplant werden muss.

In der Regel ist der Besitzer eines Domänennamens für die Ausstellung und Erneuerung seiner Zertifikate verantwortlich. Contoso ist beispielsweise für das Ausstellen und Erneuern von TLS-Zertifikaten für us.contoso.com sowie des Platzhalterzertifikats für *.contoso.com verantwortlich. In ähnlicher Weise ist Fabrikam im Allgemeinen für die Verwaltung aller Einträge für die Domäne fabrikam.com verantwortlich, invoices.fabrikam.com eingeschlossen. Von einem Domänenbesitzer können DNS-Einträge vom Typ „CAA“ (Certificate Authority Authorization) verwendet werden. CAA-Einträge stellen sicher, dass Zertifikate für die Domäne nur von bestimmten Zertifizierungsstellen erstellt werden können.

Wenn Sie Kunden die weitere Verwendung ihrer eigenen Domänen ermöglichen möchten, überlegen Sie, ob Sie das Zertifikat im Namen des Kunden ausstellen möchten, oder ob die Kunden ihre eigenen Zertifikate verwenden müssen. Jede dieser Optionen hat Vor- und Nachteile.

• Wenn Sie ein Zertifikat für einen Kunden ausstellen, können Sie die Erneuerung des Zertifikats übernehmen, damit der Kunde sich nicht um die Aktualisierung kümmern muss. Wenn die Kunden jedoch CAA-Einträge in ihren Domänennamen verwenden, benötigen Sie möglicherweise eine Autorisierung, um Zertifikate im Namen des Kunden auszustellen.
• Wenn Sie erwarten, dass Ihre Kunden eigenen Zertifikate ausstellen und Ihnen zur Verfügung stellen, sind Sie für den Erhalt und die sichere Verwaltung der privaten Schlüssel verantwortlich. Außerdem müssen Sie Ihre Kunden möglicherweise daran erinnern, das Zertifikat vor dessen Ablauf zu erneuern, um eine Dienstunterbrechung zu vermeiden.

Verschiedene Azure-Dienste unterstützen die automatische Verwaltung von Zertifikaten für benutzerdefinierte Domänen. Beispielsweise stellen Azure Front Door und App Service Zertifikate für benutzerdefinierte Domänen zur Verfügung und übernehmen automatisch deren Erneuerung. Dadurch wird Ihr Betriebsteam von der Verantwortung für die Zertifikatverwaltung entbunden. Sie müssen jedoch weiterhin die Frage des Besitzes und der Befugnisse klären, z. B. ob CAA-Einträge verwendet werden und ordnungsgemäß konfiguriert wurden. Außerdem müssen Sie sicherstellen, dass die Domänen Ihrer Kunden so konfiguriert sind, dass die von der Plattform verwalteten Zertifikate zulässig sind.

Beitragende

Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:

Hauptautor:

• John Downs | Principal Customer Engineer, FastTrack for Azure

Andere Mitwirkende:

• Daniel Scott-Raynsford | Partner Technology Strategist
• Arsen Vladimirskiy | Principal Customer Engineer, FastTrack for Azure

Melden Sie sich bei LinkedIn an, um nicht öffentliche LinkedIn-Profile anzuzeigen.

Nächste Schritte

Kehren Sie zur Übersicht der Architekturüberlegungen zurück. Alternativ können Sie zum Microsoft Azure Well-Architected Framework wechseln.