Sicherheitsrahmen: Authentifizierung | Gegenmaßnahmen

• Verwenden Sie ggf. einen Standardauthentifizierungsmechanismus zur Authentifizierung bei Webanwendungen.
• Anwendungen müssen Szenarien mit nicht erfolgreicher Authentifizierung sicher behandeln.
• Aktivieren Sie Step-up-Authentifizierung oder adaptive Authentifizierung.
• Stellen Sie sicher, dass Administratoroberflächen angemessen gesperrt sind.
• Implementieren Sie sichere Funktionen für vergessene Kennwörter.
• Stellen Sie sicher, dass die Kennwort- und die Kontorichtlinie implementiert werden.
• Implementieren Sie Kontrollen, um die Enumeration von Benutzernamen zu verhindern.

• Verwenden Sie beim Herstellen einer SQL Server-Verbindung nach Möglichkeit die Windows-Authentifizierung.
• Verwenden Sie beim Herstellen einer SQL-Datenbank-Verbindung nach Möglichkeit die Microsoft Entra-Authentifizierung.
• Stellen Sie bei Verwendung des SQL-Authentifizierungsmodus sicher, dass die Konto- und die Kennwortrichtlinie für SQL Server erzwungen werden.
• Verwenden Sie für eigenständige Datenbanken keine SQL-Authentifizierung.

• Verwenden Sie gerätespezifische Authentifizierungsanmeldeinformationen mit SAS-Token.

• Aktivieren Sie die Multi-Faktor-Authentifizierung von Microsoft Entra für Azure-Administrator*innen.

• Beschränken Sie den anonymen Zugriff auf den Service Fabric-Cluster.
• Stellen Sie sicher, dass sich das Client-zu-Knoten-Zertifikat von Service Fabric vom Knoten-zu-Knoten-Zertifikat unterscheidet.
• Verwenden Sie Microsoft Entra ID, um Clients bei Service Fabric-Clustern zu authentifizieren.
• Stellen Sie sicher, dass Service Fabric-Zertifikate von einer genehmigten Zertifizierungsstelle (Certificate Authority, CA) bezogen werden.

• Verwenden Sie von Identity Server unterstützte Standardauthentifizierungsszenarien.
• Überschreiben Sie den standardmäßigen Identity Server-Tokencache mit einer skalierbaren Alternative.

• Stellen Sie sicher, dass die Binärdateien der bereitgestellten Anwendung digital signiert sind.

• Aktivieren Sie die Authentifizierung beim Herstellen einer Verbindung mit MSMQ-Warteschlangen in WCF.
• Legen Sie „message clientCredentialType“ nicht auf „None“ fest.
• Legen Sie „transport clientCredentialType“ nicht auf „None“ fest.

• Stellen Sie sicher, dass Web-APIs durch Standardauthentifizierungsverfahren geschützt sind.

• Verwenden Sie von Microsoft Entra ID unterstützte Standardauthentifizierungsszenarien.
• Überschreiben des standardmäßigen MSAL-Tokencaches mit einem verteilten Cache
• Sicherstellen, dass TokenReplayCache verwendet wird, um die Wiedergabe eingehender ADAL-Authentifizierungstoken zu verhindern
• Verwalten Sie Tokenanforderungen von OAuth2-Clients an Microsoft Entra ID (oder lokales AD) mit MSAL-Bibliotheken.

• Authentifizieren Sie Geräte, die eine Verbindung mit dem zwischengeschalteten Gateway herstellen.

• Stellen Sie sicher, dass Geräte, die eine Verbindung mit dem Cloudgateway herstellen, authentifiziert werden.
• Verwenden Sie gerätespezifische Anmeldeinformationen für die Authentifizierung.

• Stellen Sie sicher, dass nur die erforderlichen Container und Blobs anonymen Lesezugriff erhalten.
• Gewähren Sie mithilfe von SAS oder SAP eingeschränkten Zugriff auf Objekte im Azure-Speicher.

Bei der Authentifizierung wird die Identität einer Entität überprüft – in der Regel anhand von Anmeldeinformationen wie Benutzername und Kennwort. Hierzu stehen möglicherweise mehrere Authentifizierungsprotokolle zur Verfügung. Einige davon sind im Anschluss aufgeführt:

• Clientzertifikate
• Windows-basiert
• Formularbasiert
• Verbund – ADFS
• Verbund: Microsoft Entra ID
• Verbund – Identity Server

Verwenden Sie ggf. einen Standardauthentifizierungsmechanismus, um den Quellprozess zu identifizieren.

Anwendungen mit expliziter Benutzerauthentifizierung müssen Szenarien mit nicht erfolgreicher Authentifizierung sicher behandeln. Der Authentifizierungsmechanismus muss Folgendes bewirken:

• Er muss den Zugriff auf privilegierte Ressourcen verweigern, wenn die Authentifizierung nicht erfolgreich war.
• Er muss eine generische Fehlermeldung anzeigen, wenn die Authentifizierung nicht erfolgreich war und der Zugriff verweigert wird.

Überprüfen Sie, ob Folgendes erfüllt ist:

• Privilegierte Ressourcen sind nach nicht erfolgreicher Anmeldung geschützt.
• Bei nicht erfolgreicher Authentifizierung wird eine generische Fehlermeldung angezeigt, und es werden Zugriffsverweigerungsereignisse generiert.
• Konten werden nach einer übermäßigen Anzahl nicht erfolgreicher Versuche deaktiviert.

Vergewissern Sie sich, dass die Anwendung über eine zusätzliche Autorisierung verfügt, damit Benutzer*innen eine Aufforderung angezeigt wird, bevor sie Zugriff auf sensible Daten erhalten. Beispiele für eine solche Autorisierung wären etwa Step-up-Authentifizierung oder adaptive Authentifizierung, mehrstufige Authentifizierung (z. B. mittels OTP-Versand per SMS oder E-Mail) oder eine Aufforderung zur erneuten Authentifizierung. Diese Regel gilt auch für wichtige Änderungen an einem Konto oder an einer Aktion.

Das bedeutet auch, dass die Anpassung der Authentifizierung so implementiert werden muss, dass die Anwendung eine ordnungsgemäße kontextabhängige Autorisierung erzwingt, um nicht autorisierte Manipulationen (beispielsweise der Parameter) zu verhindern.

Vergewissern Sie sich zunächst, dass bei vergessenen Kennwörtern und bei anderen Wiederherstellungspfaden nicht das Kennwort, sondern ein Link mit einem Aktivierungstoken gesendet wird, das nur für einen bestimmten Zeitraum gültig ist. Bei Bedarf kann auch noch eine Softtoken-basierte Authentifizierung (beispielsweise per SMS-Token oder nativer mobiler Anwendung) erforderlich gemacht werden, bevor der Link übermittelt wird. Zweitens: Achten Sie darauf, dass das Benutzerkonto nicht während des Bezugs eines neuen Kennworts gesperrt wird.

Dies kann zu einem Denial-of-Service-Angriff führen, wenn ein Angreifer beschließt, die Benutzer mit einem automatisierten Angriff absichtlich auszusperren. Drittens: Bei der Initiierung der Anforderung eines neuen Kennworts muss eine generische Meldung angezeigt werden, um die Enumeration von Benutzernamen zu verhindern. Viertens: Unterbinden Sie immer die Verwendung alter Kennwörter, und implementieren Sie eine Richtlinie für sichere Kennwörter.

Implementieren Sie eine Kennwort- und eine Kontorichtlinie, die die Regeln und bewährten Methoden der Organisation erfüllen.

Zur Abwehr Brute-Force- und wörterbuchbasierter Angriffe muss eine Richtlinie für sichere Kennwörter implementiert werden, um sicherzustellen, dass Benutzer komplexe Kennwörter erstellen – beispielsweise mit einer Mindestlänge von 12 Zeichen sowie mit einer Kombination aus alphanumerischen Zeichen und Sonderzeichen.

Kontosperrungsrichtlinien werden möglicherweise wie folgt implementiert:

• Gemäßigte Sperrung: Eine gute Option, um Ihre Benutzer vor Brute-Force-Angriffen zu schützen. Falls der Benutzer beispielsweise dreimal ein falsches Kennwort eingibt, kann die Anwendung das Konto eine Minute lang sperren, um die Brute-Force-Ermittlung des Kennworts zu verlangsamen und somit für den Angreifer unattraktiver zu machen. Wenn Sie in diesem Beispiel eine harte Sperrung implementieren, bewirkt dies einen Denial-of-Service-Angriff, da Konten dauerhaft gesperrt werden. Alternativ kann die Anwendung ein Einmalkennwort (One Time Password, OTP) generieren und out-of-band (etwa per E-Mail oder SMS) an den Benutzer bzw. die Benutzerin senden. Eine weitere Möglichkeit ist die Implementierung eines CAPTCHAs nach Erreichen einer bestimmten Anzahl nicht erfolgreicher Versuche.
• Rigorose Sperrung: Diese Art von Sperrung empfiehlt sich, wenn ein Benutzerangriff auf Ihre Anwendung festgestellt wird und das Konto des Angreifers dauerhaft gesperrt werden soll, bis ein Sicherheitsteam Gelegenheit hatte, den Vorfall zu untersuchen. Danach können Sie dem Benutzer wieder Zugriff auf sein Konto gewähren oder rechtliche Schritte gegen ihn einleiten. Bei diesem Ansatz kann der Angreifer nicht weiter in Ihre Anwendung und Infrastruktur vordringen.

Vergewissern Sie sich zur Abwehr von Angriffen auf Standardkonten und vorhersehbare Konten, dass alle Schlüssel und Kennwörter ersetzbar sind und nach der Installation generiert oder ersetzt werden.

Falls die Anwendung Kennwörter automatisch generieren muss, stellen Sie sicher, dass es sich um Zufallskennwörter mit hoher Entropie handelt.

Das Event Hubs-Sicherheitsmodell basiert auf einer Kombination aus SAS-Token (Shared Access Signature) und Ereignisherausgebern. Der Herausgebername stellt die Geräte-ID dar, die das Token erhält. Dadurch lassen sich die generierten Token leichter den entsprechenden Geräten zuordnen.

Alle Nachrichten werden dienstseitig mit dem Ursprung markiert, was die Erkennung nutzlastbasierter Spoofingversuche ermöglicht. Generieren Sie beim Authentifizieren von Geräten ein gerätespezifisches SAS-Token, das einem eindeutigen Herausgeber zugeordnet ist.

Die Multi-Faktor-Authentifizierung (MFA) ist eine Authentifizierungsmethode, die die Verwendung mehrerer Überprüfungsmethoden erfordert und eine wichtige zweite Sicherheitsebene für Benutzeranmeldungen und Transaktionen bietet. Dies funktioniert durch das Anfordern von zwei oder mehr der folgenden Verifizierungsmethoden:

• Etwas, das Sie wissen (in der Regel ein Kennwort)
• Etwas, das Sie besitzen (ein vertrauenswürdiges Gerät, das nicht auf einfache Weise dupliziert werden kann, z. B. ein Telefon)
• Etwas, das Sie sind (biometrisch)

Cluster sollten immer gesichert werden, um zu verhindern, dass nicht autorisierte Benutzer eine Verbindung mit dem Cluster herstellen können, insbesondere dann, wenn im Cluster Produktionsworkloads ausgeführt werden.

Achten Sie beim Erstellen eines Service Fabric-Clusters darauf, dass der Sicherheitsmodus auf „Sicher“ festgelegt ist, und konfigurieren Sie das erforderliche X.509-Serverzertifikat. Bei Erstellung eines unsicheren Clusters kann jeder anonyme Benutzer eine Verbindung herstellen, wenn der Cluster Verwaltungsendpunkte im öffentlichen Internet verfügbar macht.

Client-zu-Knoten-Zertifikatsicherheit wird beim Erstellen des Clusters über das Azure-Portal, über Azure Resource Manager-Vorlagen oder über eine eigenständige JSON-Vorlage durch Angeben eines Administratorclientzertifikats und/oder eines Benutzerclientzertifikats konfiguriert.

Die angegebenen Administrator- und Benutzerclientzertifikate müssen sich von den primären und sekundären Zertifikaten unterscheiden, die Sie für Knoten-zu-Knoten-Sicherheit angeben.

Service Fabric verwendet X.509-Serverzertifikate für die Authentifizierung von Knoten und Clients.

Wichtige Punkte bei der Verwendung von Zertifikaten in Service Fabric:

• Zertifikate, die in Clustern mit Produktionsworkloads verwendet werden, müssen entweder mit einem korrekt konfigurierten Windows Server-Zertifikatsdienst erstellt oder über eine genehmigte Zertifizierungsstelle (Certificate Authority, CA) bezogen werden. Die Zertifizierungsstelle kann eine genehmigte externe Zertifizierungsstelle oder eine ordnungsgemäß verwaltete interne Public Key-Infrastruktur (PKI) sein.
• Verwenden Sie in der Produktion niemals temporäre Zertifikate oder Testzertifikate, die mit Tools wie „MakeCert.exe“ erstellt wurden.
• Verwenden Sie selbstsignierte Zertifikate nur für Testcluster, aber nicht in der Produktion.

Typische, von Identity Server unterstützte Interaktionen:

• Browser kommunizieren mit Webanwendungen.
• Webanwendungen kommunizieren mit Web-APIs (manchmal selbstständig, manchmal im Auftrag eines Benutzers).
• Browserbasierte Anwendungen kommunizieren mit Web-APIs.
• Native Anwendungen kommunizieren mit Web-APIs.
• Serverbasierte Anwendungen kommunizieren mit Web-APIs.
• Web-APIs kommunizieren mit Web-APIs (manchmal selbstständig, manchmal im Auftrag eines Benutzers).

Identity Server verfügt über einen einfachen integrierten In-Memory-Cache. Dieser eignet sich zwar gut für kleinere native Apps, lässt sich aber aus folgenden Gründen nicht für Mid-Tier- und Back-End-Anwendungen skalieren:

• Auf diese Anwendungen greifen viele Benutzer gleichzeitig zu. Die Speicherung aller Zugriffstoken im gleichen Speicher führt zu Isolationsproblemen sowie zu Herausforderungen bei umfangreichen Systemen: Bei einer großen Anzahl von Benutzern (jeder davon mit so vielen Token wie Ressourcen, auf die die App in seinem Auftrag zugreift) ergeben sich unter Umständen riesige Mengen und äußerst aufwendige Suchvorgänge.
• Diese Anwendungen werden in der Regel in verteilten Topologien bereitgestellt, in denen mehrere Knoten Zugriff auf den gleichen Cache benötigen.
• Zwischengespeicherte Token müssen bei Prozesswiederverwendungen und Deaktivierungen erhalten bleiben.
• Aus den oben genannten Gründen empfiehlt es sich bei der Implementierung von Web-Apps, den standardmäßigen Identity Server-Tokencache mit einer skalierbaren Alternative (beispielsweise Azure Cache for Redis) zu überschreiben.

Bei der Authentifizierung wird die Identität einer Entität überprüft – in der Regel anhand von Anmeldeinformationen wie Benutzername und Kennwort. Hierzu stehen möglicherweise mehrere Authentifizierungsprotokolle zur Verfügung. Einige davon sind im Anschluss aufgeführt:

• Clientzertifikate
• Windows-basiert
• Formularbasiert
• Verbund – ADFS
• Verbund: Microsoft Entra ID
• Verbund – Identity Server

Unter den Links im Abschnitt „Referenzen“ finden Sie detaillierte Informationen zur Implementierung der einzelnen Authentifizierungsschemas zum Schutz einer Web-API.

Microsoft Entra ID vereinfacht die Authentifizierung für Entwickler durch Bereitstellung von IaaS (Identity as a Service) sowie durch Unterstützung branchenüblicher Protokolle wie OAuth 2.0 und OpenID Connect. Microsoft Entra ID unterstützt fünf primäre Anwendungsszenarien:

• Webbrowser zu Webanwendung: Ein Benutzer oder eine Benutzerin muss sich bei einer durch Microsoft Entra ID geschützten Webanwendung anmelden.
• Single-Page-Webanwendung (SPA): Ein Benutzer oder eine Benutzerin muss sich bei einer durch Microsoft Entra ID geschützten Single-Page-Webanwendung anmelden.
• Native Anwendung zu Web-API: Eine native Anwendung auf einem Smartphone, Tablet oder PC muss einen Benutzer oder eine Benutzerin authentifizieren, um Ressourcen von einer durch Microsoft Entra ID geschützten Web-API abzurufen.
• Webanwendung zu Web-API: Eine Webanwendung muss Ressourcen von einer durch Microsoft Entra ID geschützten Web-API abrufen.
• Daemon- oder Serveranwendung zu Web-API: Eine Daemon- oder Serveranwendung ohne Webbenutzeroberfläche muss Ressourcen von einer durch Microsoft Entra ID geschützten Web-API abrufen.

Detaillierte Informationen zur Implementierung finden Sie unter den Links im Abschnitt „Referenzen“.

Der Standardcache von MSAL (Microsoft Authentication Library) ist ein skalierbarer In-Memory-Cache. Es gibt jedoch verschiedene Alternativen, z. B. einen verteilten Tokencache. Diese verfügen über L1/L2-Mechanismen, wobei L1 die Implementierung von In-Memory-Cache und L2 die des verteilten Caches ist. Diese können entsprechend konfiguriert werden, um L1-Arbeitsspeicher zu begrenzen, zu verschlüsseln oder Entfernungsrichtlinien festzulegen. Weitere Alternativen sind Redis-, SQL Server- oder Azure Cosmos DB-Caches. Eine Implementierung eines verteilten Tokencaches finden Sie im folgenden Tutorial: Erste Schritte mit ASP.NET Core MVC.

Mithilfe der TokenReplayCache-Eigenschaft können Entwickler einen Tokenwiedergabecache definieren. In diesem Speicher können Token gespeichert werden, um die mehrmalige Verwendung eines Tokens zu verhindern.

Hierbei handelt es sich um eine Maßnahme gegen so genannte Tokenwiedergabeangriffe: Ein Angreifer, der ein bei der Anmeldung gesendetes Token abfängt, kann versuchen, das Token erneut an die App zu senden (es also gewissermaßen wiederzugeben), um eine neue Sitzung zu initiieren. Ein Beispiel: Nach erfolgreicher Benutzerauthentifizierung erfolgt im OIDC-Codegewährungsflow eine Anforderung an den Endpunkt „/signin-oidc“ der vertrauenden Seite mit den Parametern „id_token“, „code“ und „state“.

Die vertrauende Seite überprüft diese Anforderung und initiiert eine neue Sitzung. Wenn nun ein Angreifer diese Anforderung abfängt und wiedergibt, kann er erfolgreich eine Sitzung initiieren und den Benutzer spoofen. Die Nonce in OpenID Connect kann die Umstände, unter denen der Angriff gelingt, nur einschränken, aber nicht vollständig beseitigen. Zum Schutz ihrer Anwendungen können Entwickler eine ITokenReplayCache-Implementierung bereitstellen und TokenReplayCache eine Instanz zuweisen.

Mit der Microsoft-Authentifizierungsbibliothek (MSAL) können Entwickler Sicherheitstoken von Microsoft Identity Platform abrufen, um Benutzer zu authentifizieren und auf geschützte Web-APIs zuzugreifen. Sie kann verwendet werden, um sicheren Zugriff auf Microsoft Graph, andere Microsoft-APIs, Web-APIs von Drittanbietern oder Ihre eigene Web-API zu gewährleisten. MSAL unterstützt verschiedene Anwendungsarchitekturen und -plattformen einschließlich .NET, JavaScript, Java, Python, Android und iOS.

• Allgemein: Authentifizieren Sie das Gerät mittels TLS (Transport Layer Security) oder IPsec. Die Infrastruktur sollte die Verwendung eines vorinstallierten Schlüssels (Pre-Shared Key, PSK) auf den Geräten unterstützen, bei denen keine vollständige asymmetrische Verschlüsselung möglich ist. Nutzen Sie Microsoft Entra ID, Oauth.
• C#: Beim Erstellen einer DeviceClient-Instanz erstellt die Create-Methode standardmäßig eine DeviceClient-Instanz, die das AMQP-Protokoll für die Kommunikation mit dem IoT Hub verwendet. Wenn Sie das HTTPS-Protokoll verwenden möchten, verwenden Sie die Überschreibung der Create-Methode, mit der Sie das Protokoll angeben können. Bei Verwendung des HTTPS-Protokolls müssen Sie Ihrem Projekt auch das NuGet-Paket Microsoft.AspNet.WebApi.Client hinzufügen, um den Namespace System.Net.Http.Formatting einzuschließen.

Standardmäßig kann nur der Besitzer bzw. eine Benutzerin eines Speicherkontos auf einen Container und alle darin enthaltenen Blobs zugreifen. Wenn anonyme Benutzer Leseberechtigungen für einen Container und die enthaltenen Blobs erhalten sollen, kann der öffentliche Zugriff durch Festlegen der Containerberechtigungen gestattet werden. Anonyme Benutzer können Blobs innerhalb eines öffentlich zugänglichen Containers lesen, ohne dass die Anforderung authentifiziert werden muss.

Container stellen die folgenden Optionen zum Verwalten des Containerzugriffs bereit:

• Vollständiger öffentlicher Lesezugriff: Container- und Blobdaten können über anonyme Anforderungen gelesen werden. Clients können Blobs innerhalb des Containers über eine anonyme Anforderung aufzählen, können aber keine Container innerhalb des Speicherkontos aufzählen.
• Öffentlicher Lesezugriff nur für Blobs: Blob-Daten innerhalb dieses Containers können über anonyme Anforderungen gelesen werden, Containerdaten sind aber nicht verfügbar. Clients können keine Blobs innerhalb des Containers über anonyme Anforderungen aufzählen.
• Kein öffentlicher Lesezugriff: Container- und Blobdaten können nur vom Kontobesitzer gelesen werden.

Anonymer Zugriff ist am besten für Szenarien, in denen bestimmte Blobs immer für den anonymen Lesezugriff zur Verfügung stehen sollen. Für eine präzisere Steuerung kann eine SAS (Shared Access Signature) erstellt werden, die es ermöglicht, eingeschränkten Zugriff mithilfe verschiedener Berechtigungen und über einen bestimmten Zeitraum zu delegieren. Achten Sie darauf, dass Container und Blobs, die möglicherweise sensible Daten enthalten, nicht versehentlich anonymen Zugriff erhalten.

Shared Access Signatures (SAS) eignen sich sehr gut, um anderen Clients eingeschränkten Zugriff auf Objekte in Ihrem Speicherkonto zu gewähren, ohne den Kontozugriffsschlüssel weiterzugeben. Die SAS ist ein URI, dessen Abfrageparameter alle erforderlichen Informationen für den authentifizierten Zugriff auf eine Speicherressource enthalten. Für den Zugriff auf Speicherressourcen mit der SAS braucht der Client diese nur an den entsprechenden Konstruktor bzw. die entsprechende Methode zu übergeben.

Sie können eine SAS verwenden, um einem Client Zugriff auf Ressourcen in Ihrem Speicherkonto zu bieten, dem Sie Ihren Kontoschlüssel nicht anvertrauen möchten. Ihre Speicherkontoschlüssel bestehen aus Primär- und Sekundärschlüssel. Beide bieten Administratorzugriff auf Ihr Konto und alle enthaltenen Ressourcen. Wenn Sie Ihre Kontoschlüssel weitergeben, besteht die Gefahr von böswilliger oder fahrlässiger Nutzung. Shared Access Signatures bieten eine sichere alternative, um anderen Clients Lese-, Schreib- und Löschzugriff auf Daten in Ihrem Speicherkonto gemäß der von Ihnen definierten Berechtigungen zu bieten, ohne den Kontoschlüssel weitergeben zu müssen.

Wenn Sie über einen logischen Satz von Parametern verfügen, die jedes Mal ähnlich sind, empfiehlt sich die Verwendung einer gespeicherten Zugriffsrichtlinie (Stored Access Policy, SAP). Da Sie bei Verwendung einer SAS, die von einer gespeicherten Zugriffsrichtlinie abgeleitet ist, die SAS sofort widerrufen können, sollten Sie nach Möglichkeit immer die gespeicherte Zugriffsrichtlinie verwenden.