Teil 2: Authentifizierungsanforderungen in diesem Beispielszenario

Vorheriger Teil: Einführung und Hintergrund

In diesem Beispielszenario weist die Hauptanwendung drei unterschiedliche Authentifizierungsanforderungen auf:

• Azure Key Vault (ein Dienst zur sicheren Verwaltung kryptografischer Schlüssel)

  Die Anwendung muss sich bei Azure Key Vault authentifizieren, um einen sicher gespeicherten API-Schlüssel abzurufen, der zum Aufrufen eines Drittanbieterdiensts erforderlich ist.

• Drittanbieter-API

  Sobald die Anwendung den API-Schlüssel abruft, verwendet sie den Schlüssel, um sich mit der externen Drittanbieter-API zu authentifizieren.

• Azure Queue Storage (Warteschlangenspeicher)

  Nach der Verarbeitung der Anforderung muss sich die Anwendung bei Azure Queue Storage authentifizieren, um eine Nachricht für die asynchrone oder verzögerte Verarbeitung aufzufordern.

Für diese Aufgaben muss die App drei Gruppen von Anmeldeinformationen verwalten:

• Zwei Sätze für Azure Ressourcen (Key Vault und Speicher)

• Ein Satz für einen externen Dienst (Drittanbieter-API)

Wichtige Herausforderungen bei der Authentifizierung

Das Erstellen sicherer Cloudanwendungen erfordert eine sorgfältige Behandlung von Anmeldeinformationen, insbesondere, wenn mehrere Dienste beteiligt sind. Dieses Beispielszenario stellt mehrere kritische Herausforderungen dar:

• Zirkelabhängigkeit von Key Vault

  Die Anwendung verwendet Azure Key Vault, um geheime Schlüssel wie API-Schlüssel von Drittanbietern oder Azure Storage-Anmeldeinformationen sicher zu speichern. Um diese geheimen Schlüssel abzurufen, muss sich die App jedoch zuerst bei Key Vault authentifizieren. Diese Situation verursacht ein Zirkelproblem: Die App benötigt Anmeldeinformationen für den Zugriff auf Key Vault, aber Sie müssen diese Anmeldeinformationen sicher speichern. Ohne sichere Lösung könnte dieses Problem zu hartcodierten Anmeldeinformationen oder unsicheren Konfigurationen in Entwicklungsumgebungen führen.

• Sichere Handhabung von API-Schlüsseln von Drittanbietern

  Nach dem Abrufen des API-Schlüssels aus Dem Key Vault muss die Anwendung ihn verwenden, um einen externen Drittanbieterdienst aufzurufen. Behandeln Sie diesen Schlüssel mit extremer Sorgfalt:

  • Codieren Sie es niemals fest in den Quellcode oder in Konfigurationsdateien ein.
  • Protokollieren Sie es niemals in stdout, stderr oder Anwendungslogs.
  • Halten Sie sie nur im Arbeitsspeicher, und greifen Sie zur Laufzeit darauf zu, direkt vor der Verwendung
  • Entsorgen Sie sie umgehend, sobald die Anfrage abgeschlossen ist.

  Wenn Sie diese Praktiken nicht befolgen, erhöht sich das Risiko der Preisgabe von Anmeldeinformationen oder des unbefugten Gebrauchs.

• Sichern von Azure Queue Storage-Anmeldeinformationen

  Um Nachrichten in Azure Queue Storage zu schreiben, benötigt die App in der Regel eine Verbindungszeichenfolge oder ein freigegebenes Zugriffstoken. Diese Anmeldeinformationen:

  • Muss an einem sicheren Speicherort gespeichert werden, z. B. Key Vault
  • Dürfen nicht in Protokollen, Stapelspuren oder Entwicklertools angezeigt werden
  • Der Zugriff sollte nur über sichere Laufzeitmechanismen erfolgen.
  • Vorgeschriebene richtige RBAC-Konfiguration bei Verwendung einer verwalteten Identität

• Umgebungsflexibilität

  Die App muss sowohl in lokalen Entwicklungs- als auch in Cloudproduktionsumgebungen zuverlässig ausgeführt werden, wobei die gleiche Codebasis und minimale bedingte Logik verwendet werden.

  Diese Anforderung bedeutet:

  • Betten Sie keine umgebungsspezifischen Geheimschlüssel in den Code ein.
  • Schalten Sie Anmeldedaten oder Logikpfade nicht manuell um
  • Verwenden der identitätsbasierten Authentifizierung konsistent in allen Umgebungen

Azure-basierte Authentifizierung mit Microsoft Entra ID

Da Cloud-Anwendungen in ihrer Komplexität skalieren und mit mehr Diensten integriert werden, wird eine sichere und optimierte Authentifizierung unerlässlich. Azure bietet ein Azure erste Identitätsmodell über Microsoft Entra ID, wodurch einheitliche Identitätsverwaltung und nahtlose Integration mit Azure-Diensten für sichere, anmeldeinformationsfreie Authentifizierung ermöglicht werden.

Anstatt Geheimnisse manuell zu verwalten oder Anmeldeinformationen in Anwendungscode einzubetten – eine Praxis, die Sicherheitsrisiken birgt –, ermöglicht Microsoft Entra ID Apps, sich durch die Verwendung verwalteter Identitäten sicher zu authentifizieren.

Die wichtigsten Vorteile von von Microsoft Entra verwalteten Identitäten sind:

• Keine geheimen Schlüssel im Code

  Anwendungen benötigen keine hartcodierten Verbindungszeichenfolgen, Client-Geheimnisse oder Zugangsschlüssel mehr.

• Integrierte Identität für Apps

  Azure können Ihrer App automatisch eine verwaltete Identität zuweisen, sodass sie ohne zusätzliche Anmeldeinformationen sicher auf Dienste wie Key Vault, Speicher und SQL zugreifen kann.

• Umgebungskonsistenz

  Dasselbe Code- und Identitätsmodell funktioniert sowohl in lokalen Entwicklungs- als auch in Azure gehosteten Umgebungen mithilfe der Azure SDKDefaultAzureCredential.

Umgebungsspezifischer Identitätsfluss

Anwendungen, die Microsoft Entra-ID für die Authentifizierung verwenden, profitieren von einem flexiblen Identitätsmodell, das nahtlos sowohl in von Azure gehosteten als auch in lokalen Entwicklungsumgebungen funktioniert. Das DefaultAzureCredential des Azure SDK gewährleistet diese Konsistenz, indem es abhängig von der Umgebung automatisch die entsprechende Identitätsmethode auswählt.

Azure-Umgebung

Wenn Sie die Anwendung für Azure bereitstellen:

• Die Anwendung erhält automatisch eine verwaltete Identität.
• Azure verwaltet die Tokenausstellung und den Lebenszyklus von Anmeldeinformationen intern, sodass Sie keine geheimen Schlüssel verarbeiten müssen.
• Die Anwendung greift mithilfe von Role-Based Access Control (RBAC) oder Key Vault Zugriffsrichtlinien auf Dienste zu.

Lokale Entwicklungsumgebung

Während der lokalen Entwicklung:

• Ein Dienstprinzipal dient als Identität der App.
• Entwickler authentifizieren sich mithilfe der Azure CLI (az login), Umgebungsvariablen oder Visual Studio/VS-Codeintegrationen.
• Derselbe Anwendungscode wird ohne Änderungen ausgeführt – nur die Identitätsquelle ändert sich.

In beiden Umgebungen verwenden Azure SDKs die DefaultAzureCredential, die die Identitätsquelle abstrahiert und automatisch die richtige Methode auswählt.

Bewährte Methoden für sichere Entwicklung

Während Sie geheime Schlüssel als Umgebungsvariablen festlegen können (z. B. über Azure-App Einstellungen), hat dieser Ansatz Nachteile:

• Sie müssen geheime Schlüssel in lokalen Umgebungen manuell replizieren.
• Es besteht das Risiko, dass Geheimnisse in die Versionsverwaltung gelangen.
• Möglicherweise benötigen Sie zusätzliche Logik, um zwischen Umgebungen zu unterscheiden.

Verwenden Sie stattdessen den folgenden Ansatz:

• Verwenden Sie Key Vault, um API-Schlüssel von Drittanbietern und andere geheime Schlüssel zu speichern.
• Weisen Sie Ihrer bereitgestellten App eine verwaltete Identität zu.
• Verwenden Sie einen Dienstprinzipal für die lokale Entwicklung, und weisen Sie ihm dieselben Zugriffsrechte zu.
• Verwenden Sie DefaultAzureCredential in Ihrem Code, um die Authentifizierungslogik zu abstrahieren.
• Vermeiden Sie das Speichern oder Protokollieren von Anmeldeinformationen.

Authentifizierungsfluss in der Praxis

So funktioniert die Authentifizierung zur Laufzeit:

• Ihr Code erstellt eine DefaultAzureCredential Instanz.
• Sie verwenden diese Anmeldeinformationen, um einen Client zu instanziieren (z. B. SecretClient, QueueServiceClient).
• Wenn die App eine Methode aufruft (z. B get_secret(). ), verwendet der Client die Anmeldeinformationen, um die Anforderung zu authentifizieren.
• Azure überprüft die Identität und überprüft, ob sie über die richtige Rolle oder Richtlinie zum Ausführen des Vorgangs verfügt.

Dieser Fluss stellt sicher, dass Ihre App sicher auf Azure-Dienste zugreifen kann, ohne geheime Schlüssel in Code- oder Konfigurationsdateien einzubetten. Außerdem können Sie nahtlos zwischen lokaler Entwicklung und Cloudbereitstellung wechseln, ohne Ihre Authentifizierungslogik zu ändern.

Teil 3 – API-Implementierung von Drittanbietern >>>