Teilen über

Resilienz durch Best Practices für Entwickler

  • Artikel

In diesem Artikel teilen wir Erkenntnisse, die wir durch die Zusammenarbeit mit Großkunden gewonnen haben. Sie können diese Empfehlungen beim Entwerfen und Implementieren Ihrer Dienste berücksichtigen.

Diagramm: Komponenten der Entwicklerumgebung

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 für Anwendungen. Diese Bibliotheken sind für die Unterstützung von Microsoft Identity optimiert und bieten Features, die die Anwendungsresilienz verbessern.

Entwickler können die aktuellen Releases der MSAL verwenden und stets auf dem neuesten Stand bleiben. Erfahren Sie, wie Sie die Resilienz bei Authentifizierung und Autorisierung in Ihren Anwendungen erhöhen können. Implementieren Sie nach Möglichkeit keinen eigenen Authentifizierungsstapel. Verwenden Sie stattdessen bewährte Bibliotheken.

Optimieren von Lese- und Schreibvorgängen im Verzeichnis

Der Azure Active Directory B2C-Verzeichnisdienst (AAD B2C) unterstützt Milliarden von Authentifizierungen pro Tag mit einer hohen Anzahl von Lesevorgängen pro Sekunde. Optimieren Sie Schreibvorgänge, um Abhängigkeiten zu minimieren und die Resilienz zu erhöhen.

So optimieren Sie Lese- und Schreibvorgänge im Verzeichnis

  • Schreiben Sie während der Anmeldung keine Funktionen in das Verzeichnis: Vermeiden Sie in Ihren benutzerdefinierten Richtlinien das Ausführen eines Schreibvorgangs bei der Anmeldung ohne Vorbedingung (If-Klausel). Ein Anwendungsfall, der während der Anmeldung einen Schreibvorgang erfordert, ist die Just-In-Time-Migration von Benutzerkennwörtern. Es sollte nicht bei jeder Anmeldung ein Schreibvorgang erforderlich sein. Vorbedingungen in einer User Journey sehen wie folgt aus:

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

  • Machen Sie sich mit der Drosselung vertraut: 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 gelten andere Grenzwerte.

    • Ein Schreibvorgang während der Anmeldung ist ein POST-Vorgang für neue Benutzer oder ein PUT-Vorgang für vorhandene Benutzer.
    • Eine benutzerdefinierte Richtlinie, die bei jeder Anmeldung einen Benutzer erstellt oder aktualisiert, kann dazu führen, dass eine PUT- oder POST-Ratenbegrenzung auf Anwendungsebene erreicht wird. 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-Faktor-Authentifizierung (MFA) berücksichtigt werden. Testen Sie sowohl das AAD B2C-System als auch Ihre Anwendung auf Datenverkehrsspitzen. Es kann vorkommen, dass AAD B2C die Last ohne Drosselung verarbeiten kann, Ihre Downstreamanwendungen oder -dienste aber nicht.
    • Erarbeiten Sie einen Zeitplan für die Migration. Wenn Sie planen, Benutzer mithilfe von Microsoft Graph zu AAD B2C zu migrieren, berücksichtigen Sie die Anwendungs- und Mandantengrenzwerte, um den Zeitaufwand für die Benutzermigration zu berechnen. Wenn Sie den Auftrag oder das Skript zum Erstellen von Benutzern auf zwei Anwendungen aufteilen, können Sie einen anwendungsbasierten Grenzwert verwenden. Stellen Sie sicher, dass dieser Grenzwert immer unter dem Schwellenwert pro Mandant liegt.
    • Informieren Sie sich gründlich über die Auswirkungen des Migrationsauftrags auf andere Anwendungen. Berücksichtigen Sie den Livedatenverkehr aus anderen abhängigen Anwendungen, um eine Drosselung auf Mandantenebene und Ressourcenknappheit für Ihre Liveanwendung auszuschließen. 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.

Tokengültigkeitsdauer

Stellen Sie eine Lösung zum Entschärfen des Problems für bereits angemeldete Benutzer bereit, wenn der AAD B2C-Authentifizierungsdienst keine neuen Registrierungen und Anmeldungen durchführen kann. Per Konfiguration können bereits angemeldete Benutzer die Anwendung ohne Unterbrechung weiter nutzen, bis sie sich von der Anwendung abmelden oder für die Sitzung aufgrund von Inaktivität ein Timeout auftritt.

Ihre geschäftlichen Anforderungen und das Endbenutzererlebnis bestimmen die Häufigkeit der Tokenaktualisierung für Webanwendungen und Single-Page-Webanwendungen (Single-Page-Application, SPA).

Verlängern der Tokenlebensdauer

  • Webanwendungen: Bei Webanwendungen, bei denen das Authentifizierungstoken bei 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 Sitzung basierend auf der Benutzeraktivität verlängern, 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 verlängern. Legen Sie die Sitzungslebensdauer auf den maximal zulässigen Wert fest.
  • Single-Page-Webanwendungen: Eine SPA benötigt möglicherweise Zugriffstoken, um die APIs aufzurufen. Für SPAs empfehlen wir die Verwendung des Autorisierungscodeflows mit dem Proof Key for Code Exchange (PKCE)-Flow als Option, damit Benutzer die Anwendung weiterhin verwenden können. Wenn Ihre SPA zurzeit einen impliziten Flow verwendet, erwägen Sie die Migration zum Autorisierungscodeflow mit PKCE. Migrieren Sie Ihre Anwendung von MSAL.js 1.x zu MSAL.js 2.x, um Resilienz für Ihre Webanwendungen zu erzielen. Der implizite Flow führt nicht zu einem Aktualisierungstoken. Die SPA kann einen verborgenen iframe verwenden, um neue Tokenanforderungen beim Autorisierungsendpunkt auszuführen, wenn im Browser eine aktive Sitzung mit dem AAD B2C-Dienst vorhanden ist. Bei SPAs sind einige Optionen verfügbar, um dem Benutzer die weitere Nutzung der Anwendung zu ermöglichen.
    • Verlängern Sie die Gültigkeitsdauer des Zugriffstokens.
    • 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 ihn. Die Authentifizierungssitzung zwischen API-Gateway und Client wird über ein Authentifizierungscookie aufrecht erhalten. Das API-Gateway stellt den APIs das vom API-Gateway bezogene Token oder eine andere direkte Methode zur Authentifizierung (z. B. Zertifikate, Clientanmeldeinformationen oder API-Schlüssel) zur Verfügung.
    • Wechseln Sie zur empfohlenen Option. Migrieren Sie Ihre SPA von impliziten Genehmigungen zu einem Flow zur Autorisierungscodezuweisung mit Unterstützung für PKCE und Cross-Origin Resource Sharing (CORS).
    • Verlängern Sie für mobile Anwendungen die Lebensdauer des Aktualisierungs- und Zugriffstokens.
  • 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 gering. Es wird empfohlen, einen Mittelweg zwischen Sicherheit und Lebensdauer zu finden und eine lange Tokenlebensdauer festzulegen.

Einmaliges Anmelden

Beim einmaligen Anmelden (Single Sign-On, SSO) melden sich Benutzer einmal mit einem Konto an und erhalten Zugriff auf Anwendungen – auf eine mobile Anwendung, eine Webanwendung oder eine SPA, wobei die Plattform oder der Domänenname keine Rolle spielen. Wenn ein Benutzer sich bei einer Anwendung anmeldet, speichert AAD B2C eine cookiebasierte Sitzung.

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

Konfigurieren von 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

Die häufigsten Gründe für Dienstunterbrechungen sind Code- und Konfigurationsänderungen. CI/CD-Prozesse und -Tools (Continuous Integration und Continuous Delivery) ermöglichen eine schnelle Bereitstellung in großem Stil und reduzieren menschliche Fehler während der Test- und Bereitstellungsphase. 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 usw. Eine Dokumentation dieser Risiken finden Sie unter OWASP Top 10. Stellen Sie eine Web Application Firewall (WAF) bereit, um Ihre Systeme und Benutzer vor gängigen Exploits und Sicherheitsrisiken zu schützen.

Geheimnisse

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 Schlüssel für die Nutzung durch legitime Entitäten autorisiert ist, als Kryptoperiode. Wählen Sie die erforderliche Länge der Kryptoperioden aus. Legen Sie den Ablauf fest, und rotieren Sie Geheimnisse, bevor sie ablaufen.

Implementieren der 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 der Schlüssel und Zertifikate an, die in AAD B2C konfiguriert sind. Diese Liste kann Schlüssel enthalten, die in benutzerdefinierten Richtlinien, APIs, signierenden ID-Token und Zertifikaten für Security Assertion Markup Language (SAML) verwendet werden.
  • Rotieren Sie mithilfe von CI/CD Geheimnisse, die innerhalb von zwei Monaten vor dem erwarteten Spitzenzeitraum ablaufen. Die empfohlene maximale Kryptoperiode für private Schlüssel, die einem Zertifikat zugeordnet sind, beträgt ein Jahr.
  • Überwachen und rotieren Sie die Anmeldeinformationen für den API-Zugriff (z. B. Kennwörter und Zertifikate).

REST-API-Tests

Zum Gewährleisten der Resilienz muss das Testen von REST-APIs die Überprüfung von HTTP-Codes, Antwortnutzdaten, Headern sowie der Leistung beinhalten. Testen Sie nicht nur die optimalen Pfade, und überprüfen Sie, ob die API Problemszenarien ordnungsgemäß verarbeitet.

Testplan

Ihr Testplan sollte umfassende API-Tests beinhalten. Überarbeiten Sie Ihre Auslastungstests mit neuen Schätzungen, wenn Anstiege aufgrund von Werbeaktionen oder Feiertagen zu erwarten sind. Führen Sie Auslastungstests für APIs und das Content Delivery Network (CDN) in einer Entwicklerumgebung durch, nicht in der Produktionsumgebung.

Nächste Schritte