Sicherheitsrahmen: Authentifizierung | Gegenmaßnahmen

  • Artikel
Produkt/Dienst Artikel
Web Application
Datenbank
Azure Event Hub
Azure-Vertrauensstellungsgrenze
Service Fabric-Vertrauensstellungsgrenze
Identity Server
Computer-Vertrauensstellungsgrenze
WCF
Web-API
Microsoft Entra ID
Zwischengeschaltetes IoT-Gateway
IoT-Cloudgateway
Azure Storage (in englischer Sprache)

Verwenden Sie ggf. einen Standardauthentifizierungsmechanismus zur Authentifizierung bei Webanwendungen.

Titel Details
Komponente Webanwendung.
SDL-Phase Entwickeln
Zutreffende Technologien Allgemein
Attribute –
Referenzen –
Details

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 müssen Szenarien mit nicht erfolgreicher Authentifizierung sicher behandeln.

Titel Details
Komponente Webanwendung.
SDL-Phase Entwickeln
Zutreffende Technologien Allgemein
Attribute –
Referenzen –
Details

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.

    Aktivieren Sie Step-up-Authentifizierung oder adaptive Authentifizierung.

    Titel Details
    Komponente Webanwendung.
    SDL-Phase Entwickeln
    Zutreffende Technologien Allgemein
    Attribute –
    Referenzen –
    Details

    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.

    Stellen Sie sicher, dass Administratoroberflächen angemessen gesperrt sind.

    Titel Details
    Komponente Webanwendung.
    SDL-Phase Entwickeln
    Zutreffende Technologien Allgemein
    Attribute –
    Referenzen –
    Details Die erste Möglichkeit besteht darin, den Zugriff auf die Administratoroberfläche nur über einen bestimmten Quell-IP-Adressbereich zu gewähren. Sollte das nicht möglich sein, empfiehlt es sich, für die Anmeldung bei der Administratoroberfläche eine Step-up-Authentifizierung oder eine adaptive Authentifizierung zu erzwingen.

    Implementieren Sie sichere Funktionen für vergessene Kennwörter.

    Titel Details
    Komponente Webanwendung.
    SDL-Phase Entwickeln
    Zutreffende Technologien Allgemein
    Attribute –
    Referenzen –
    Details

    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.

    Stellen Sie sicher, dass die Kennwort- und die Kontorichtlinie implementiert werden.

    Titel Details
    Komponente Webanwendung.
    SDL-Phase Entwickeln
    Zutreffende Technologien Allgemein
    Attribute –
    Referenzen –
    Details

    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.

    Implementieren Sie Kontrollen, um die Enumeration von Benutzernamen zu verhindern.

    Titel Details
    Komponente Webanwendung.
    SDL-Phase Entwickeln
    Zutreffende Technologien Allgemein
    Attribute –
    Referenzen –
    Schritte Alle Fehlermeldungen müssen generalisiert werden, um die Enumeration von Benutzernamen zu verhindern. Manchmal lassen sich Informationslecks in Funktionen nicht vermeiden (beispielsweise bei einer Registrierungsseite). Hier müssen ratenbegrenzende Methoden wie CAPTCHA verwendet werden, um automatisierte Angriffe zu verhindern.

    Verwenden Sie beim Herstellen einer SQL Server-Verbindung nach Möglichkeit die Windows-Authentifizierung.

    Titel Details
    Komponente Datenbank
    SDL-Phase Entwickeln
    Zutreffende Technologien Lokal
    Attribute SQL-Version: Alle
    Referenzen Auswählen eines Authentifizierungsmodus
    Schritte Die Windows-Authentifizierung verwendet das Kerberos-Sicherheitsprotokoll, stellt Maßnahmen zur Durchsetzung von Kennwortrichtlinien, z. B. zur Überprüfung der Komplexität sicherer Kennwörter, bereit und bietet Unterstützung für Kontosperrungen und Ablauf von Kennwörtern.

    Verwenden Sie beim Herstellen einer SQL-Datenbank-Verbindung nach Möglichkeit die Microsoft Entra-Authentifizierung.

    Titel Details
    Komponente Datenbank
    SDL-Phase Entwickeln
    Zutreffende Technologien SQL Azure
    Attribute SQL-Version: V12
    Informationsquellen Herstellen einer Verbindung mit SQL-Datenbank unter Verwendung der Microsoft Entra-Authentifizierung
    Schritte Mindestversion: Azure SQL-Datenbank V12 ist erforderlich, um Azure SQL-Datenbank die Verwendung der Microsoft Entra-Authentifizierung für das Microsoft-Verzeichnis zu ermöglichen.

    Stellen Sie bei Verwendung des SQL-Authentifizierungsmodus sicher, dass die Konto- und die Kennwortrichtlinie für SQL Server erzwungen werden.

    Titel Details
    Komponente Datenbank
    SDL-Phase Entwickeln
    Zutreffende Technologien Allgemein
    Attribute –
    Referenzen Kennwortrichtlinie
    Schritte Bei Verwendung der SQL Server-Authentifizierung werden in SQL Server Anmeldungen erstellt, die nicht auf Windows-Benutzerkonten basieren. Der Benutzername und das Kennwort werden mithilfe von SQL Server erstellt und in SQL Server gespeichert. SQL Server kann die Kennwortrichtlinienmechanismen von Windows verwenden. Es kann die in Windows verwendeten Komplexitäts- und Ablaufrichtlinien auf in SQL Server verwendete Kennwörter anwenden.

    Verwenden Sie für eigenständige Datenbanken keine SQL-Authentifizierung.

    Titel Details
    Komponente Datenbank
    SDL-Phase Entwickeln
    Zutreffende Technologien SQL Azure, lokal
    Attribute SQL-Version: MSSQL2012, SQL-Version: V12
    Referenzen Bewährte Methoden für die Sicherheit eigenständiger Datenbanken
    Schritte Ohne erzwungene Kennwortrichtlinie kann sich das Risiko erhöhen, dass in einer eigenständigen Datenbank unsichere Anmeldeinformationen eingerichtet werden. Nutzen Sie die Windows-Authentifizierung.

    Verwenden Sie gerätespezifische Authentifizierungsanmeldeinformationen mit SAS-Token.

    Titel Details
    Komponente Azure Event Hubs
    SDL-Phase Entwickeln
    Zutreffende Technologien Allgemein
    Attribute –
    Referenzen Event Hubs-Authentifizierung und -Sicherheitsmodell (Übersicht)
    Schritte

    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.

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

    Titel Details
    Komponente Azure-Vertrauensstellungsgrenze
    SDL-Phase Bereitstellung
    Zutreffende Technologien Allgemein
    Attribute –
    Informationsquellen Was ist die Microsoft Entra-Multi-Faktor-Authentifizierung?
    Schritte

    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)

      Beschränken Sie den anonymen Zugriff auf den Service Fabric-Cluster.

      Titel Details
      Komponente Service Fabric-Vertrauensstellungsgrenze
      SDL-Phase Bereitstellung
      Zutreffende Technologien Allgemein
      Attribute Umgebung: Azure
      Referenzen Szenarien für die Clustersicherheit in Service Fabric
      Schritte

      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.

      Stellen Sie sicher, dass sich das Client-zu-Knoten-Zertifikat von Service Fabric vom Knoten-zu-Knoten-Zertifikat unterscheidet.

      Titel Details
      Komponente Service Fabric-Vertrauensstellungsgrenze
      SDL-Phase Bereitstellung
      Zutreffende Technologien Allgemein
      Attribute Umgebung: Azure, Umgebung: eigenständig
      Referenzen Szenarien für die Clustersicherheit in Service Fabric, Herstellen einer Verbindung mit einem sicheren Cluster
      Schritte

      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.

      Verwenden Sie Microsoft Entra ID, um Clients bei Service Fabric-Clustern zu authentifizieren.

      Titel Details
      Komponente Service Fabric-Vertrauensstellungsgrenze
      SDL-Phase Bereitstellung
      Zutreffende Technologien Allgemein
      Attribute Umgebung: Azure
      Referenzen Sicherheitsempfehlungen
      Schritte Unter Azure ausgeführte Cluster können den Zugriff auf die Verwaltungsendpunkte nicht nur mit Clientzertifikaten, sondern auch mit Azure Microsoft Entra ID schützen. Für Azure-Cluster wird die Verwendung von Microsoft Entra-Sicherheit empfohlen, um Clients und Zertifikate für Knoten-zu-Knoten-Sicherheit zu authentifizieren.

      Stellen Sie sicher, dass Service Fabric-Zertifikate von einer genehmigten Zertifizierungsstelle (Certificate Authority, CA) bezogen werden.

      Titel Details
      Komponente Service Fabric-Vertrauensstellungsgrenze
      SDL-Phase Bereitstellung
      Zutreffende Technologien Allgemein
      Attribute Umgebung: Azure
      Referenzen X.509-Zertifikate und Service Fabric
      Schritte

      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.

      Verwenden Sie von Identity Server unterstützte Standardauthentifizierungsszenarien.

      Titel Details
      Komponente Identity Server
      SDL-Phase Entwickeln
      Zutreffende Technologien Allgemein
      Attribute –
      Referenzen IdentityServer3 - The Big Picture (Übersicht über IdentityServer3)
      Schritte

      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).

      Überschreiben Sie den standardmäßigen Identity Server-Tokencache mit einer skalierbaren Alternative.

      Titel Details
      Komponente Identity Server
      SDL-Phase Bereitstellung
      Zutreffende Technologien Allgemein
      Attribute –
      Referenzen Identity Server Deployment - Caching (Identity Server-Bereitstellung – Caching)
      Schritte

      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.

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

      Titel Details
      Komponente Computer-Vertrauensstellungsgrenze
      SDL-Phase Bereitstellung
      Zutreffende Technologien Allgemein
      Attribute –
      Referenzen –
      Schritte Stellen Sie sicher, dass die Binärdateien der bereitgestellten Anwendung digital signiert sind, damit die Integrität der Binärdateien überprüft werden kann.

      Aktivieren Sie die Authentifizierung beim Herstellen einer Verbindung mit MSMQ-Warteschlangen in WCF.

      Titel Details
      Komponente WCF
      SDL-Phase Entwickeln
      Zutreffende Technologien Allgemein, .NET Framework 3
      Attribute –
      Referenzen MSDN
      Schritte Falls das Programm beim Herstellen einer Verbindung mit MSMQ-Warteschlangen keine Authentifizierung aktiviert, kann ein Angreifer anonym Nachrichten an die Warteschlange senden, die dann verarbeitet werden. Wenn bei der Verbindungsherstellung mit einer Warteschlange, die eine Nachricht an ein anderes Programm übermittelt, keine Authentifizierung verwendet wird, kann ein Angreifer eine anonyme (schädliche) Nachricht senden.

      Beispiel

      Das Element <netMsmqBinding/> der folgenden WCF-Konfigurationsdatei weist WCF an, die Authentifizierung zu deaktivieren, wenn zur Übermittlung einer Nachricht eine Verbindung mit einer MSMQ-Warteschlange hergestellt wird.

      <bindings>
    <netMsmqBinding>
        <binding>
            <security>
                <transport msmqAuthenticationMode=""None"" />
            </security>
        </binding>
    </netMsmqBinding>
</bindings>

      Konfigurieren Sie MSMQ so, dass bei allen ein- und ausgehenden Nachrichten immer die Windows-Domänenauthentifizierung oder die Zertifikatauthentifizierung erforderlich ist.

      Beispiel

      Das Element <netMsmqBinding/> der folgenden WCF-Konfigurationsdatei weist WCF an, die Zertifikatauthentifizierung zu aktivieren, wenn eine Verbindung mit einer MSMQ-Warteschlange hergestellt wird. Der Client wird mit X.509-Zertifikaten authentifiziert. Das Clientzertifikat muss im Zertifikatspeicher des Servers vorhanden sein.

      <bindings>
    <netMsmqBinding>
        <binding>
            <security>
                <transport msmqAuthenticationMode=""Certificate"" />
            </security>
        </binding>
    </netMsmqBinding>
</bindings>

      Legen Sie „message clientCredentialType“ nicht auf „None“ fest.

      Titel Details
      Komponente WCF
      SDL-Phase Entwickeln
      Zutreffende Technologien .NET Framework 3
      Attribute Art der Clientanmeldeinformationen: keine
      Referenzen MSDN, Fortify
      Schritte Ohne Authentifizierung kann jeder auf diesen Dienst zugreifen. Ein Dienst ohne Clientauthentifizierung gewährt allen Benutzern Zugriff. Konfigurieren Sie die Anwendung so, dass eine Authentifizierung anhand von Clientanmeldeinformationen erfolgt. Legen Sie hierzu „message clientCredentialType“ auf „Windows“ oder „Certificate“ fest.

      Beispiel

      <message clientCredentialType=""Certificate""/>

      Legen Sie „transport clientCredentialType“ nicht auf „None“ fest.

      Titel Details
      Komponente WCF
      SDL-Phase Entwickeln
      Zutreffende Technologien Generisch, .NET Framework 3
      Attribute Art der Clientanmeldeinformationen: keine
      Referenzen MSDN, Fortify
      Schritte Ohne Authentifizierung kann jeder auf diesen Dienst zugreifen. Ein Dienst ohne Clientauthentifizierung gewährt allen Benutzern Zugriff auf seine Funktionen. Konfigurieren Sie die Anwendung so, dass eine Authentifizierung anhand von Clientanmeldeinformationen erfolgt. Legen Sie hierzu „transport clientCredentialType“ auf „Windows“ oder „Certificate“ fest.

      Beispiel

      <transport clientCredentialType=""Certificate""/>

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

      Titel Details
      Komponente Web-API
      SDL-Phase Entwickeln
      Zutreffende Technologien Allgemein
      Attribute –
      Referenzen Authentication and Authorization in ASP.NET Web API (Authentifizierung und Autorisierung in der ASP.NET-Web-API), External Authentication Services with ASP.NET Web API (C#) (Externe Authentifizierungsdienste mit ASP.NET-Web-API (C#)
      Schritte

      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.

      Verwenden Sie von Microsoft Entra ID unterstützte Standardauthentifizierungsszenarien.

      Titel Details
      Komponente Microsoft Entra ID
      SDL-Phase Entwickeln
      Zutreffende Technologien Allgemein
      Attribute –
      Informationsquellen Authentifizierungsszenarien für Microsoft Entra ID, Microsoft Entra-Codebeispiele, Entwicklerhandbuch für Microsoft Entra
      Schritte

      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“.

      Überschreiben des standardmäßigen MSAL-Tokencaches mit einem verteilten Cache

      Titel Details
      Komponente Microsoft Entra ID
      SDL-Phase Entwickeln
      Zutreffende Technologien Allgemein
      Attribute –
      Referenzen Serialisierung des Tokencaches in MSAL.NET
      Schritte

      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.

      Sicherstellen, dass TokenReplayCache verwendet wird, um die Wiedergabe eingehender MSAL-Authentifizierungstoken zu verhindern

      Titel Details
      Komponente Microsoft Entra ID
      SDL-Phase Entwickeln
      Zutreffende Technologien Allgemein
      Attribute –
      Informationsquellen Moderne Authentifizierung mit Microsoft Entra ID für Webanwendungen
      Schritte

      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.

      Beispiel

      // ITokenReplayCache defined in MSAL
public interface ITokenReplayCache
{
bool TryAdd(string securityToken, DateTime expiresOn);
bool TryFind(string securityToken);
}

      Beispiel

      Hier sehen Sie eine Beispielimplementierung der ITokenReplayCache-Schnittstelle. (Passen Sie dieses Beispiel an, und implementieren Sie Ihr projektspezifisches Cacheframework.)

      public class TokenReplayCache : ITokenReplayCache
{
    private readonly ICacheProvider cache; // Your project-specific cache provider
    public TokenReplayCache(ICacheProvider cache)
    {
        this.cache = cache;
    }
    public bool TryAdd(string securityToken, DateTime expiresOn)
    {
        if (this.cache.Get<string>(securityToken) == null)
        {
            this.cache.Set(securityToken, securityToken);
            return true;
        }
        return false;
    }
    public bool TryFind(string securityToken)
    {
        return this.cache.Get<string>(securityToken) != null;
    }
}

      Auf den implementierten Cache muss in den OIDC-Optionen über die Eigenschaft „TokenValidationParameters“ verwiesen werden:

      OpenIdConnectOptions openIdConnectOptions = new OpenIdConnectOptions
{
    AutomaticAuthenticate = true,
    ... // other configuration properties follow..
    TokenValidationParameters = new TokenValidationParameters
    {
        TokenReplayCache = new TokenReplayCache(/*Inject your cache provider*/);
    }
}

      Melden Sie sich bei Ihrer lokalen, durch OIDC geschützten Anwendung an, und erfassen Sie die an den Endpunkt "/signin-oidc" gerichtete Anforderung in Fiddler, um die Wirksamkeit dieser Konfiguration zu testen. Wenn kein Schutz vorhanden ist und diese Anforderung in Fiddler wiedergegeben wird, wird ein neues Sitzungscookie festgelegt. Wird die Anforderung wiedergegeben, nachdem der TokenReplayCache-Schutz hinzugefügt wurde, löst die Anwendung eine Ausnahme aus: SecurityTokenReplayDetectedException: IDX10228: The securityToken has previously been validated, securityToken: 'eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik1uQ19WWmNBVGZNNXBPWWlKSE1iYTlnb0VLWSIsImtpZCI6Ik1uQ1......

      Verwalten Sie Tokenanforderungen von OAuth2-Clients an Microsoft Entra ID (oder lokales AD) mit MSAL-Bibliotheken.

      Titel Details
      Komponente Microsoft Entra ID
      SDL-Phase Entwickeln
      Zutreffende Technologien Allgemein
      Attribute –
      Referenzen MSAL
      Schritte

      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.

      MSAL bietet zahlreiche Möglichkeiten für den Tokenabruf und stellt eine konsistente API für viele Plattformen bereit. Sie müssen nicht direkt die OAuth-Bibliotheken oder Code für das Protokoll in Ihrer Anwendung verwenden und können Token im Auftrag eines Benutzers oder einer Anwendung beziehen (wenn dies für die Plattform zulässig ist).

      MSAL stellt auch einen Tokencache bereit und aktualisiert Token, bevor sie ablaufen. MSAL kann Ihnen auch bei der Angabe der Zielgruppe helfen, für die Sie Ihre Anwendung registrieren möchten, und beim Einrichten Ihrer Anwendung anhand von Konfigurationsdateien sowie bei der Problembehandlung helfen.

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

      Titel Details
      Komponente Zwischengeschaltetes IoT-Gateway
      SDL-Phase Entwickeln
      Zutreffende Technologien Allgemein
      Attribute –
      Referenzen –
      Schritte Stellen Sie sicher, dass jedes Gerät durch das zwischengeschaltete Gateway authentifiziert wird, bevor Daten des Geräts akzeptiert werden und die Upstreamkommunikation mit dem Cloudgateway zugelassen wird. Stellen Sie außerdem sicher, dass bei der Verbindungsherstellung gerätespezifische Anmeldeinformationen verwendet werden, damit einzelne Geräte eindeutig identifiziert werden können.

      Stellen Sie sicher, dass Geräte, die eine Verbindung mit dem Cloudgateway herstellen, authentifiziert werden.

      Titel Details
      Komponente IoT-Cloudgateway
      SDL-Phase Entwickeln
      Zutreffende Technologien Allgemein, C#, Node.js
      Attribute N/V, Wahl des Gateways – Azure IoT Hub
      Referenzen N/V, Erste Schritte mit Azure IoT Hub (.NET), Erste Schritte mit Azure IoT Hub (Node), Securing IoT with SAS and certificates (Schützen von IoT mit SAS und Zertifikaten), Git-Repository
      Schritte
      • 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.

      Beispiel

      static DeviceClient deviceClient;

static string deviceKey = "{device key}";
static string iotHubUri = "{iot hub hostname}";

var messageString = "{message in string format}";
var message = new Message(Encoding.ASCII.GetBytes(messageString));

deviceClient = DeviceClient.Create(iotHubUri, new DeviceAuthenticationWithRegistrySymmetricKey("myFirstDevice", deviceKey));

await deviceClient.SendEventAsync(message);

      Beispiel

      Node.JS: Authentifizierung

      Symmetrischer Schlüssel

      • Erstellen eines IoT-Hubs unter Azure
      • Erstellen Sie einen Eintrag in der Geräteidentitätsregistrierung. 
        var device = new iothub.Device(null);
device.deviceId = <DeviceId >
registry.create(device, function(err, deviceInfo, res) {})
      • Erstellen Sie ein simuliertes Gerät. 
        var clientFromConnectionString = require('azure-iot-device-amqp').clientFromConnectionString;
var Message = require('azure-iot-device').Message;
var connectionString = 'HostName=<HostName>DeviceId=<DeviceId>SharedAccessKey=<SharedAccessKey>';
var client = clientFromConnectionString(connectionString);

        SAS-Token

      • Wird bei Verwendung eines symmetrischen Schlüssels intern generiert, kann aber auch explizit generiert und verwendet werden.
      • Definieren Sie ein Protokoll: var Http = require('azure-iot-device-http').Http;
      • Erstellen Sie ein SAS-Token: 
        resourceUri = encodeURIComponent(resourceUri.toLowerCase()).toLowerCase();
var deviceName = "<deviceName >";
var expires = (Date.now() / 1000) + expiresInMins * 60;
var toSign = resourceUri + '\n' + expires;
// using crypto
var decodedPassword = new Buffer(signingKey, 'base64').toString('binary');
const hmac = crypto.createHmac('sha256', decodedPassword);
hmac.update(toSign);
var base64signature = hmac.digest('base64');
var base64UriEncoded = encodeURIComponent(base64signature);
// construct authorization string
var token = "SharedAccessSignature sr=" + resourceUri + "%2fdevices%2f"+deviceName+"&sig="
+ base64UriEncoded + "&se=" + expires;
if (policyName) token += "&skn="+policyName;
return token;
      • Stellen Sie eine Verbindung her, und verwenden Sie dabei das SAS-Token: 
        Client.fromSharedAccessSignature(sas, Http);

        Zertifikate

      • Generieren Sie ein selbst signiertes X.509-Zertifikat. Verwenden Sie hierzu ein Tool wie OpenSSL, um CERT- und KEY-Dateien zu erstellen und das Zertifikat und den Schlüssel zu speichern.
      • Stellen Sie ein Gerät bereit, das eine sichere Verbindung mit Zertifikaten akzeptiert. 
        var connectionString = '<connectionString>';
var registry = iothub.Registry.fromConnectionString(connectionString);
var deviceJSON = {deviceId:"<deviceId>",
authentication: {
    x509Thumbprint: {
    primaryThumbprint: "<PrimaryThumbprint>",
    secondaryThumbprint: "<SecondaryThumbprint>"
    }
}}
var device = deviceJSON;
registry.create(device, function (err) {});
      • Stellen Sie unter Verwendung eines Zertifikats eine Verbindung mit einem Gerät her. 
        var Protocol = require('azure-iot-device-http').Http;
var Client = require('azure-iot-device').Client;
var connectionString = 'HostName=<HostName>DeviceId=<DeviceId>x509=true';
var client = Client.fromConnectionString(connectionString, Protocol);
var options = {
    key: fs.readFileSync('./key.pem', 'utf8'),
    cert: fs.readFileSync('./server.crt', 'utf8')
};
// Calling setOptions with the x509 certificate and key (and optionally, passphrase) will configure the client //transport to use x509 when connecting to IoT Hub
client.setOptions(options);
//call fn to execute after the connection is set up
client.open(fn);

      Verwenden Sie gerätespezifische Anmeldeinformationen für die Authentifizierung.

      Titel Details
      Komponente IoT-Cloudgateway
      SDL-Phase Entwickeln
      Zutreffende Technologien Allgemein
      Attribute Wahl des Gateways: Azure IoT Hub
      Referenzen Azure IoT Hub Security Tokens (Azure IoT Hub – Sicherheitstoken)
      Schritte Verwenden Sie anstelle von SAS-Richtlinien auf IoT Hub-Ebene gerätespezifische Authentifizierungsanmeldeinformationen mit SAS-Token, die auf dem Geräteschlüssel oder Clientzertifikat basieren. Dies verhindert die Wiederverwendung der Authentifizierungstoken eines Geräts oder zwischengeschalteten Gateways durch ein anderes Gerät oder zwischengeschaltetes Gateway.

      Stellen Sie sicher, dass nur die erforderlichen Container und Blobs anonymen Lesezugriff erhalten.

      Titel Details
      Komponente Azure Storage
      SDL-Phase Entwickeln
      Zutreffende Technologien Allgemein
      Attribute StorageType: Blob
      Referenzen Verwalten des anonymen Lesezugriffs auf Container und Blobs, Verwenden von Shared Access Signatures (SAS)
      Schritte

      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.

      Gewähren Sie mithilfe von SAS oder SAP eingeschränkten Zugriff auf Objekte im Azure-Speicher.

      Titel Details
      Komponente Azure Storage
      SDL-Phase Entwickeln
      Zutreffende Technologien Allgemein
      Attribute –
      Referenzen Verwenden von Shared Access Signatures (SAS), Shared Access Signatures, Teil 2: Erstellen und Verwenden einer SAS mit Blob Storage, Delegieren des Zugriffs auf Objekte in Ihrem Konto mithilfe von SAS und gespeicherter Zugriffsrichtlinien
      Schritte

      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.