Resilienz durch Best Practices für Entwickler

  • Artikel

In diesem Artikel möchten wir einige Erkenntnisse aus unserer langjährigen Erfahrung mit der Arbeit mit Großkunden an Sie weitergeben. Sie können beim Entwurf und bei der Implementierung Ihrer Dienste von diesen Empfehlungen profitieren.

Image shows developer experience components

Verwenden der Microsoft Authentication Library (MSAL)

Die Microsoft Authentication Library (MSAL) und die Microsoft Identity-Webauthentifizierungsbibliothek für ASP.NET vereinfachen das Abrufen, Verwalten, Zwischenspeichern und Aktualisieren der Token, die für eine Anwendung erforderlich sind. Diese Bibliotheken sind speziell für die Unterstützung von Microsoft Identity optimiert und bieten Features zur Verbesserung der Anwendungsresilienz.

Entwickler sollten die neuesten Versionen der MSAL verwenden und diese stets aktualisieren. Erfahren Sie, wie Sie die Resilienz bei Authentifizierung und Autorisierung in Ihren Anwendungen erhöhen können. Vermeiden Sie nach Möglichkeit die Implementierung eines eigenen Authentifizierungsstapels, und verwenden Sie stattdessen eingeführte und bewährte Bibliotheken.

Optimieren von Lese- und Schreibvorgängen im Verzeichnis

Der Azure AD B2C-Verzeichnisdienst unterstützt Milliarden von Authentifizierungen pro Tag. Er ist auf eine hohe Anzahl von Lesevorgängen pro Sekunde ausgelegt. Optimieren Sie Schreibvorgänge, um Abhängigkeiten zu minimieren und die Resilienz zu erhöhen.

So optimieren Sie Lese- und Schreibvorgänge im Verzeichnis

  • Vermeiden Sie das Schreiben von Funktionen in das Verzeichnis während der Anmeldung: Führen Sie in Ihren benutzerdefinierten Richtlinien einen Schreibvorgang bei der Anmeldung niemals ohne Vorbedingung (if-Klausel) aus. Ein Anwendungsfall, der während der Anmeldung einen Schreibvorgang erfordert, ist die Just-In-Time-Migration von Benutzerkennwörtern. Vermeiden Sie alle Szenarien, die bei jeder Anmeldung einen Schreibvorgang erfordern. Vorbedingungen in einer User Journey sehen wie folgt aus:

    <Precondition Type="ClaimEquals" ExecuteActionsIf="true"> 
<Value>requiresMigration</Value>
...
<Precondition/>

  • Grundlegendes zur Drosselung: Das Verzeichnis implementiert Drosselungsregeln sowohl auf Anwendungs- als auch auf Mandantenebene. Es gibt weitere Ratenbegrenzungen für die Vorgänge zum Lesen/GET, Schreiben/POST, Aktualisieren/PUT und Löschen/DELETE. Für jeden Vorgang gilt ein anderes Limit.

    • Ein Schreibvorgang zum Zeitpunkt der Anmeldung gehört zu einem POST-Vorgang für neue Benutzer oder einem PUT-Vorgang für vorhandene Benutzer.
    • Eine benutzerdefinierte Richtlinie, die bei jeder Anmeldung einen Benutzer erstellt oder aktualisiert, kann möglicherweise eine PUT- oder POST-Ratenbegrenzung auf Anwendungsebene erreichen. Die gleichen Grenzwerte gelten beim Aktualisieren von Verzeichnisobjekten über Microsoft Entra ID oder Microsoft Graph. Untersuchen Sie auch die Lesevorgänge, um die Anzahl dieser Vorgänge bei jeder Anmeldung auf ein Minimum zu beschränken.
    • Schätzen Sie die Spitzenlast, um die Rate der Verzeichnisschreibvorgänge vorherzusagen und eine Drosselung zu vermeiden. Bei der Schätzung von Datenverkehrsspitzen müssen auch Schätzwerte für Aktionen wie Registrierung, Anmeldung und Multi-Factor Authentication (MFA) berücksichtigt werden. Testen Sie unbedingt sowohl das Azure AD B2C-System als auch Ihre Anwendung auf Datenverkehrsspitzen. Es ist möglich, dass Azure AD B2C die Last ohne Drosselung verarbeiten kann, Ihre nachgelagerten Anwendungen oder Dienste aber nicht.
    • Erarbeiten Sie einen Zeitplan für die Migration. Wenn Sie planen, Benutzer mithilfe von Microsoft Graph zu Azure AD B2C zu migrieren, berücksichtigen Sie die Grenzwerte für Anwendung und Mandant, um die Zeit zu berechnen, die für die vollständige Migration der Benutzer benötigt wird. Wenn Sie den Auftrag oder das Skript zum Erstellen von Benutzern auf zwei Anwendungen aufteilen, können einen anwendungsbasierten Grenzwert verwenden. Dieser Grenzwert muss jedoch unter dem Schwellenwert pro Mandant liegen.
    • Informieren Sie sich gründlich über die Auswirkungen des Migrationsauftrags auf andere Anwendungen. Berücksichtigen Sie den Livedatenverkehr aus anderen abhängigen Anwendungen, um sicherzustellen, dass Sie keine Drosselung auf Mandantenebene und keine Ressourcenknappheit für Ihre Liveanwendung verursachen. Weitere Informationen finden Sie im Leitfaden zu Einschränkungen in Microsoft Graph.
    • Nutzen Sie ein Beispiel für Auslastungstests, um Registrierungen und Anmeldungen zu simulieren.
    • Weitere Informationen finden Sie unter Dienstlimits und -einschränkungen für Azure Active Directory B2C.

Verlängern der Tokenlebensdauer

Für unwahrscheinliche Szenarien – wenn beispielsweise der Azure AD B2C-Authentifizierungsdienst keine neuen Registrierungen und Anmeldungen durchführen kann – können Sie dennoch eine Problementschärfung für bereits angemeldete Benutzer bereitstellen. Per Konfiguration können Sie es bereits angemeldeten Benutzern ermöglichen, die Anwendung ohne spürbare Unterbrechung weiter zu nutzen, bis sie sich von der Anwendung abmelden oder für die Sitzung aufgrund von Inaktivität ein Timeout auftritt.

Geschäftsanforderungen und das gewünschte Endbenutzererlebnis bestimmen die Häufigkeit der Tokenaktualisierung für Webanwendungen und Single-Page-Anwendungen (SPAs).

So verlängern Sie die Lebensdauer von Token

  • Webanwendungen: Bei Webanwendungen, bei denen das Authentifizierungstoken zu Beginn der Anmeldung überprüft wird, benötigt die Anwendung ein Sitzungscookie, um die Gültigkeit der Sitzung zu verlängern. Implementieren Sie rollierende Sitzungszeiten, die eine Sitzungsverlängerung basierend auf der Benutzeraktivität ermöglichen, damit Benutzer angemeldet bleiben können. Wenn für längere Zeit keine Token ausgestellt werden können, lassen sich diese Sitzungszeiten in Form einer einmaligen Konfiguration der Anwendung weiter verlängern. Legen Sie die Sitzungslebensdauer auf den maximal zulässigen Wert fest.
  • SPAs: Eine SPA benötigt möglicherweise Zugriffstoken, um APIs aufzurufen. Eine SPA verwendet traditionell den impliziten Flow, der nicht zu einem Aktualisierungstoken führt. Die SPA kann einen verborgenen iframe verwenden, um neue Tokenanforderungen beim Autorisierungsendpunkt auszuführen, wenn im Browser noch eine aktive Sitzung mit dem Azure AD B2C-Dienst vorhanden ist. Bei SPAs stehen einige Optionen zur Verfügung, um dem Benutzer die weitere Nutzung der Anwendung zu ermöglichen.
    • Verlängern Sie die Gültigkeitsdauer des Zugriffstokens, um Ihre Geschäftsanforderungen zu erfüllen.
    • Konfigurieren Sie Ihre Anwendung so, dass sie ein API-Gateway als Authentifizierungsproxy verwendet. In dieser Konfiguration wird die SPA ohne Authentifizierung geladen, und die API-Aufrufe erfolgen an das API-Gateway. Das API-Gateway leitet den Benutzer basierend auf einer Richtlinie per Zuweisung eines Autorisierungscodes durch einen Anmeldevorgang und authentifiziert den Benutzer. Anschließend wird die Authentifizierungssitzung zwischen API-Gateway und Client über ein Authentifizierungscookie beibehalten. Das API-Gateway stellt den APIs das vom API-Gateway bezogene Token zur Verfügung (oder eine andere direkte Methode zur Authentifizierung wie Zertifikate, Clientanmeldeinformationen oder API-Schlüssel).
    • Migrieren Sie Ihre SPA von implizite Genehmigungen zu einem Genehmigungsflow per Autorisierungscode mit Unterstützung für PKCE (Proof Key for Code Exchange) und CORS (Cross-Origin Resource Sharing). Migrieren Sie Ihre Anwendung von MSAL.js 1.x zu MSAL.js 2.x, um Resilienz für Ihre Webanwendungen zu erzielen.
    • Für mobile Anwendungen empfiehlt es sich, die Lebensdauer sowohl des Aktualisierungs- als auch des Zugriffstokens zu verlängern.
  • Back-End- oder Microserviceanwendungen: Da Back-End-Anwendungen (Daemon-Anwendungen) nicht interaktiv sind und nicht in einem Benutzerkontext ausgeführt werden, ist die Wahrscheinlichkeit eines Tokendiebstahls sehr gering. Es wird empfohlen, einen Mittelweg zwischen Sicherheit und Lebensdauer zu finden und eine lange Tokenlebensdauer festzulegen.

Konfigurieren des einmaligen Anmeldens

Mit dem Feature Einmaliges Anmelden (Single Sign-On, SSO) melden sich Benutzer einmal mit einem einzigen Konto an und erhalten Zugriff auf mehrere Anwendungen. Dabei kann es sich um eine mobile Anwendung, eine Webanwendung oder eine Single-Page-Anwendung handeln. Plattform und Domänenname spielen keine Rolle. Wenn ein Benutzer sich erstmals bei einer Anwendung anmeldet, speichert Azure AD B2C eine cookiebasierte Sitzung.

Bei nachfolgenden Authentifizierungsanforderungen liest und überprüft Azure AD B2C die cookiebasierte Sitzung und stellt ein Zugriffstoken aus, ohne den Benutzer zur erneuten Anmeldung aufzufordern. Wenn SSO mit eingeschränktem Gültigkeitsbereich auf Richtlinien- oder Anwendungsebene konfiguriert ist, wird für einen späteren Zugriff auf andere Richtlinien und Anwendungen eine erneute Authentifizierung benötigt.

So konfigurieren Sie SSO

Konfigurieren Sie SSO mandantenweit (dies ist die Standardeinstellung), sodass mehrere Anwendungen und Benutzerflows in Ihrem Mandanten dieselbe Benutzersitzung gemeinsam nutzen können. Eine mandantenweite Konfiguration bietet das höchste Maß an Resilienz für neue Authentifizierungen.

Sichere Bereitstellungsmethoden

Änderungen an Code und Konfiguration sind die häufigsten Gründe für Dienstunterbrechungen. CI/CD-Prozesse und -Tools (Continuous Integration und Continuous Delivery) helfen bei einer schnellen Bereitstellung in großem Stil und reduzieren menschliche Fehler während der Test-, Bereitstellungs- und Produktionsphase. Nutzen Sie CI/CD, um Fehler zu minimieren und mehr Effizienz und Konsistenz zu erzielen. Azure Pipelines ist ein Beispiel für CI/CD.

Schutz vor Bots

Schützen Sie Ihre Anwendungen vor bekannten Sicherheitsrisiken wie DDoS-Angriffen (Distributed Denial of Service), Einschleusung von SQL-Befehlen, Cross-Site Scripting, Remotecodeausführung und vielen weiteren. Eine Dokumentation dieser Risiken finden Sie unter OWASP Top 10. Mit einer Web Application Firewall (WAF) können Sie Ihre Systeme und Benutzer vor gängigen Exploits und Sicherheitsrisiken schützen.

Geheimnisrotation

Azure AD B2C verwendet Geheimnisse für Anwendungen, APIs, Richtlinien und Verschlüsselung. Diese Geheimnisse sichern die Authentifizierung, externe Interaktionen und den Speicher. Das National Institute of Standards and Technology (NIST) bezeichnet die Zeitspanne, in der ein bestimmter Schlüssel für die Nutzung durch legitime Entitäten autorisiert ist, als „cryptoperiod“ (Kryptoperiode). Wählen Sie die richtige Länge der Kryptoperiode für Ihre geschäftlichen Anforderungen. Entwickler müssen den Ablauf manuell festlegen und Geheimnisse weit vor ihrem Ablauf rotieren.

So implementieren Sie die Geheimnisrotation

  • Verwenden Sie verwaltete Identitäten, damit sich unterstützte Ressourcen bei jedem Dienst authentifizieren können, der die Microsoft Entra-Authentifizierung unterstützt. Mithilfe von verwalteten Identitäten können Sie Ressourcen automatisch verwalten, einschließlich der Rotation von Anmeldeinformationen.
  • Legen Sie ein Inventar sämtlicher Schlüssel und Zertifikate an, die in Azure AD B2C konfiguriert sind. Diese Liste enthält wahrscheinlich Schlüssel, die in benutzerdefinierten Richtlinien, APIs, signierenden ID-Token und Zertifikaten für SAML verwendet werden.
  • Rotieren Sie über CI/CD Geheimnisse, die innerhalb von zwei Monaten vor dem erwarteten Spitzenzeitraum ablaufen werden. Die empfohlene maximale Kryptoperiode für private Schlüssel, die einem Zertifikat zugeordnet sind, beträgt ein Jahr.
  • Überwachen und rotieren Sie proaktiv die Anmeldeinformationen für APIs (z. B. Kennwörter und Zertifikate).

Testen von REST-APIs

Im Kontext der Resilienz muss das Testen von REST-APIs die Überprüfung von HTTP-Codes, Antwortnutzdaten, Headern sowie der Leistung beinhalten. Hierbei muss nicht nur überprüft werden, ob Pfade funktionieren, sondern es muss auch getestet werden, ob die API Problemszenarien ordnungsgemäß verarbeitet.

So testen Sie APIs

Ihr Testplan sollte umfassende API-Tests beinhalten. Wenn Sie einen bevorstehenden Anstieg des Datenverkehrs aufgrund von Werbeaktionen oder Feiertagen planen, müssen Sie Ihre Auslastungstests mit den neuen Schätzungen überarbeiten. Führen Sie die Auslastungstests Ihrer APIs und des CDN (Content Delivery Network) in einer Entwicklerumgebung durch, nicht in der Produktionsumgebung.

Nächste Schritte