Einführung in die Entwicklung sicherer Windows-Apps

Artikel
07/08/2024

Dieser einführende Artikel hilft App-Architekt*innen und Entwickler*innen, die verschiedenen Funktionalitäten der Windows 10 Plattform besser zu verstehen, die das Erstellen sicherer Universal Windows Platform-Apps (UWP) beschleunigen. Er beschreibt detailliert, wie Sie die Windows-Sicherheitsfunktionen nutzen können, die in jeder der folgenden Phasen zur Verfügung stehen: Authentifizierung, Data-in-Flight und Data-at-Rest. Vertiefende Informationen zu den einzelnen Themen finden Sie in den zusätzlichen Ressourcen, die in jedem Kapitel enthalten sind.

1 Einführung

Die Entwicklung einer sicheren App kann eine Herausforderung sein. In der heutigen rasanten Welt der mobilen, sozialen, Cloud- und komplexen Unternehmens-Apps erwarten die Kund*innen, dass Apps schneller als je zuvor verfügbar sind und aktualisiert werden. Außerdem verwenden sie viele verschiedene Geräte, was das Erstellen von Apps noch komplexer macht. Wenn Sie für die Windows Universelle Windows-Plattform (UWP) erstellen, könnte dies die herkömmliche Liste der Desktops, Laptops, Tablets und mobilen Geräte enthalten. Zusätzlich zu einer wachsenden Liste neuer Geräte, die das Internet der Dinge, Xbox One, Microsoft Surface Hub und HoloLens umfassen. Als Entwickler*in müssen Sie sicherstellen, dass Ihre Apps über alle beteiligten Plattformen oder Geräte hinweg sicher kommunizieren und Daten speichern.

Hier sind einige der Vorteile der Verwendung von Windows-Sicherheitsfeatures.

Sie verfügen über standardisierte Sicherheit auf allen Geräten, die Windows unterstützen, indem Sie konsistente APIs für Sicherheitskomponenten und -technologien verwenden.
Sie schreiben, testen und pflegen weniger Code, als wenn Sie angepassten Code zur Abdeckung dieser Sicherheitsszenarien implementieren würden.
Ihre Apps werden stabiler und sicherer, weil Sie das Betriebssystem nutzen, um zu steuern, wie die App auf ihre Ressourcen und lokale oder Remote-Systemressourcen zugreift.

Bei der Authentifizierung wird die Identität von Benutzenden, die Zugriff auf einen bestimmten Dienst anfordern, überprüft. Windows Hello ist die Komponente in Windows, die hilft, einen sichereren Authentifizierungsmechanismus in Windows-Apps zu erstellen. Mit ihr können Sie eine persönliche Identifikationsnummer (PIN) oder biometrische Daten wie die Fingerabdrücke, das Gesicht oder die Iris der Benutzenden verwenden, um eine Multi-Faktor-Authentifizierung für Ihre Apps zu implementieren.

Data-in-flight bezieht sich auf die Verbindung und die darüber übertragenen Nachrichten. Ein Beispiel hierfür ist der Abruf von Daten von einem Remoteserver mit Hilfe von Webdiensten. Die Verwendung von Secure Sockets Layer (SSL) und Secure Hypertext Transfer Protocol (HTTPS) gewährleistet die Sicherheit der Verbindung. Um zu verhindern, dass zwischengeschaltete Parteien auf diese Nachrichten zugreifen oder unbefugte Apps mit den Webdiensten kommunizieren, ist die Data-in-Flight-Sicherheit entscheidend.

Data-at-Rest schließlich bezieht sich auf Daten, die sich im Arbeitsspeicher oder auf Speichermedien befinden. Windows-Apps verfügen über ein App-Modell, das nicht autorisierten Datenzugriff zwischen Apps verhindert und Verschlüsselungs-APIs zum weiteren Sichern von Daten auf dem Gerät bietet. Eine Funktion namens Credential Locker kann verwendet werden, um Anmeldeinformationen sicher auf dem Gerät zu speichern, wobei das Betriebssystem den Zugriff anderer Apps darauf verhindert.

2 Authentifizierungsfaktoren

Um Daten zu schützen, muss die Person, die den Zugriff darauf beantragt, identifiziert und zum Zugriff auf die von ihr angeforderten Ressourcen autorisiert werden. Der Prozess der Identifizierung von Benutzenden wird als Authentifizierung bezeichnet, und die Festlegung der Zugriffsrechte auf eine Ressource wird als Autorisierung bezeichnet. Diese Vorgänge sind eng miteinander verbunden und für die Benutzenden möglicherweise nicht voneinander zu unterscheiden. Es kann sich um relativ einfache oder komplexe Vorgänge handeln, die von vielen Faktoren abhängen: zum Beispiel davon, ob die Daten auf einem Server liegen oder über viele Systeme verteilt sind. Der Server, der die Authentifizierungs- und Autorisierungsdienste bereitstellt, wird als Identitätsanbieter bezeichnet.

Um sich bei einem bestimmten Dienst und/oder einer App zu authentifizieren, verwenden die Benutzenden Anmeldeinformationen. Diese können mehrere Komponenten umfassen: eine den Benutzenden bekannte Information, ein Element im Besitz der Benutzenden oder ein persönliches Merkmal der Benutzenden. Jeder dieser Faktoren wird als Authentifizierungsfaktor bezeichnet.

Eine bekannte Information ist in der Regel ein Kennwort, es kann aber auch eine persönliche Identifikationsnummer (PIN) oder ein „geheimes“ Frage-Antwort-Paar sein.
Ein Element im Besitz der Benutzenden ist meist ein Hardware-Gerät wie ein USB-Stick, auf dem die Authentifizierungsdaten gespeichert sind.
Ein persönliches Merkmal der Benutzenden umfasst oft Fingerabdrücke. Es gibt aber auch zunehmend populäre Faktoren wie die Sprache, das Gesicht, die Augenmerkmale oder das Verhaltensmuster der Benutzenden. Wenn diese Informationen als Daten gespeichert werden, nennt man sie Biometriedaten.

Ein von Benutzenden erstelltes Kennwort ist an sich schon ein Authentifizierungsfaktor, reicht aber oft nicht aus; jede Person, die das Kennwort kennt, kann sich als Benutzer*in anmelden. Eine Smartcard kann ein höheres Maß an Sicherheit bieten, aber sie kann gestohlen werden, verloren gehen oder verlegt werden. Ein System, das Benutzende per Fingerabdruck oder Augenscan authentifizieren kann, bietet zwar die höchste und bequemste Sicherheitsstufe, erfordert aber teure und spezielle Hardware (z. B. eine Intel RealSense-Kamera für die Gesichtserkennung), die möglicherweise nicht für alle Benutzenden verfügbar ist.

Die Gestaltung der von einem System verwendeten Authentifizierungsmethode ist ein komplexer und wichtiger Aspekt der Datensicherheit. Allgemein gilt: Je mehr Faktoren Sie bei der Authentifizierung verwenden, desto sicherer ist das System. Gleichzeitig muss die Authentifizierung aber auch benutzbar sein. Benutzende melden sich in der Regel viele Male am Tag an, daher muss der Prozess schnell sein. Die Wahl der Authentifizierungsart ist ein Kompromiss zwischen Sicherheit und Benutzungsfreundlichkeit. Die Ein-Faktor-Authentifizierung ist am wenigsten sicher und am einfachsten zu benutzen, während die Multi-Faktor-Authentifizierung zwar sicherer, aber auch komplexer wird, je mehr Faktoren hinzugefügt werden.

2.1 Ein-Faktor-Authentifizierung

Diese Form der Authentifizierung basiert auf einer einzigen Anmeldeinformation der Benutzenden. Dabei handelt es sich in der Regel um ein Kennwort, es kann aber auch eine persönliche Identifikationsnummer (PIN) sein.

Hier ist der Ablauf der Ein-Faktor-Authentifizierung.

Der/die Benutzende gibt den Namen und das Kennwort an den Identitätsanbieter weiter. Der Identitätsanbieter ist der Serverprozess, der die Identität der Benutzenden überprüft.
Der Identitätsanbieter prüft, ob der Name und das Kennwort mit den im System gespeicherten Daten übereinstimmen. In den meisten Fällen wird das Kennwort verschlüsselt, was zusätzliche Sicherheit bietet, damit andere es nicht lesen können.
Der Identitätsanbieter gibt einen Authentifizierungsstatus zurück, der angibt, ob die Authentifizierung erfolgreich war.
Wenn sie erfolgreich war, beginnt der Datenaustausch. Wenn die Authentifizierung nicht erfolgreich war, muss der/die Benutzende sich erneut authentifizieren.

Single-Factor Authentication

Diese Methode der Authentifizierung wird heute allgemein von allen Diensten am häufigsten verwendet. Sie ist auch die unsicherste Form der Authentifizierung, wenn sie als einziges Mittel zur Authentifizierung verwendet wird. Anforderungen an die Komplexität von Kennwörtern, „geheime Fragen“ und die regelmäßige Änderung von Kennwörtern können die Verwendung von Kennwörtern sicherer machen, aber sie belasten die Benutzenden stärker und sind keine wirksame Abschreckung gegen Hacker.

Die Herausforderung bei Kennwörtern besteht darin, dass es leichter ist, sie erfolgreich zu erraten als Systeme, die mehr als einen Faktor haben. Wenn sie eine Datenbank mit Konten und gehashten Kennwörtern aus einem kleinen Webshop stehlen, können sie die auf anderen Websites verwendeten Kennwörter verwenden. Benutzende neigen dazu, Konten immer wieder zu verwenden, weil komplexe Kennwörter schwer zu merken sind. Für eine IT-Abteilung bringt die Verwaltung von Kennwörtern auch die Komplexität mit sich, Rücksetzmechanismen anbieten zu müssen, häufige Aktualisierungen von Kennwörtern zu verlangen und diese auf sichere Weise zu speichern.

Trotz aller Nachteile gibt die Ein-Faktor-Authentifizierung dem/der Benutzenden die Kontrolle über die Anmeldeinformationen. Sie erstellen und ändern sie, und für den Authentifizierungsprozess wird lediglich eine Tastatur benötigt. Dies ist der Hauptaspekt, der die Ein-Faktor-Authentifizierung von der Multi-Faktor-Authentifizierung unterscheidet.

2.1.1 Web-Authentifizierungs-Broker

Wie bereits erwähnt, besteht eine der Herausforderungen bei der Authentifizierung mit Kennwörtern für die IT-Abteilung in dem zusätzlichen Aufwand für die Verwaltung der Basis von Namen/Passwörtern, Rücksetzmechanismen usw. Eine immer beliebtere Option ist es, sich auf Identitätsanbieter von Drittanbietern zu verlassen, die eine Authentifizierung über OAuth, einen offenen Standard für die Authentifizierung, anbieten.

Mit OAuth können IT-Abteilungen den Aufwand für die Verwaltung einer Datenbank mit Namen und Kennwörtern, die Funktion zum Zurücksetzen von Kennwörtern usw. effektiv an einen Drittanbieter wie Facebook, X oder Microsoft „auslagern“.

Benutzende haben auf diesen Plattformen die vollständige Kontrolle über ihre Identität, aber Apps können nach der Authentifizierung des/der Benutzenden und mit dessen/deren Zustimmung ein Token vom Anbieter anfordern, das zur Autorisierung authentifizierter Benutzender verwendet werden kann.

Der Webauthentifizierungsbroker in Windows stellt eine Reihe von APIs und Infrastruktur für Apps bereit, um Authentifizierungs- und Autorisierungsprotokolle wie OAuth und OpenID zu verwenden. Apps können über die WebAuthenticationBroker-API Vorgänge zur Authentifizierung initiieren, die zur Rückgabe eines WebAuthenticationResult führen. Die folgende Abbildung zeigt einen Überblick über den Kommunikations-Flow.

wab-Workflow

Die App fungiert als Broker und initiiert die Authentifizierung mit dem Identitätsanbieter über eine WebView in der App. Wenn der Identitätsanbieter den/die Benutzende*n authentifiziert hat, gibt er ein Token an die App zurück, mit dem Informationen über den/die Benutzende*n beim Identitätsanbieter angefordert werden können. Als Sicherheitsmaßnahme muss die App bei dem Identitätsanbieter registriert werden, bevor sie die Authentifizierungsprozesse mit dem Identitätsanbieter abwickelt. Diese Registrierungsschritte sind bei jedem Anbieter unterschiedlich.

Hier ist der allgemeine Workflow für den Aufruf der WebAuthenticationBroker-API zur Kommunikation mit dem Anbieter.

Konstruieren Sie die Anfragezeichenfolgen, die an den Identitätsanbieter gesendet werden sollen. Die Anzahl der Zeichenfolgen und die Informationen in jeder Zeichenfolge sind für jeden Webdienst unterschiedlich, aber in der Regel gehören dazu zwei URI-Zeichenfolgen, die jeweils eine URL enthalten: eine, an die die Authentifizierungsanfrage gesendet wird, und eine, an die der/die Benutzende nach erfolgter Autorisierung umgeleitet wird.
Rufen Sie WebAuthenticationBroker.AuthenticateAsync auf, übergeben Sie die Zeichenfolgen für die Anfrage, und warten Sie auf die Antwort des Identitätsanbieters.
Rufen Sie WebAuthenticationResult.ResponseStatus auf, um den Status zu erhalten, wenn die Antwort eingegangen ist.
Wenn die Kommunikation erfolgreich ist, verarbeiten Sie die Zeichenfolge der Antwort, die vom Identitätsanbieter zurückgegeben wird. Wenn sie nicht erfolgreich war, verarbeiten Sie den Fehler.

Wenn die Kommunikation erfolgreich ist, verarbeiten Sie die Zeichenfolge der Antwort, die vom Identitätsanbieter zurückgegeben wird. Wenn sie nicht erfolgreich war, verarbeiten Sie den Fehler.

Ein Beispiel für C#-Code für diesen Prozess finden Sie unten. Informationen und eine ausführliche exemplarische Vorgehensweise finden Sie unter WebAuthenticationBroker. Ein vollständiges Code-Beispiel finden Sie im WebAuthenticationBroker-Beispiel auf GitHub.

string startURL = "https://<providerendpoint>?client_id=<clientid>";
string endURL = "http://<AppEndPoint>";

var startURI = new System.Uri(startURL);
var endURI = new System.Uri(endURL);

try
{
    WebAuthenticationResult webAuthenticationResult = 
        await WebAuthenticationBroker.AuthenticateAsync( 
            WebAuthenticationOptions.None, startURI, endURI);

    switch (webAuthenticationResult.ResponseStatus)
    {
        case WebAuthenticationStatus.Success:
            // Successful authentication. 
            break;
        case WebAuthenticationStatus.ErrorHttp:
            // HTTP error. 
            break;
        default:
            // Other error.
        break;
    }
}
catch (Exception ex)
{
    // Authentication failed. Handle parameter, SSL/TLS, and
    // Network Unavailable errors here. 
}

2.2 Multi-Faktor-Authentifizierung

Bei der Multi-Faktor-Authentifizierung wird mehr als ein Authentifizierungsfaktor verwendet. Normalerweise wird „eine dem/der Benutzenden bekannte Information“, wie z. B. ein Kennwort, mit „etwas im Besitz des/der Benutzenden“, wie z. B. ein Mobiltelefon oder eine Smartcard, kombiniert. Selbst wenn ein Angreifer das Kennwort herausfindet, ist das Konto ohne das Gerät oder die Karte unzugänglich. Und wenn nur das Gerät oder die Karte kompromittiert wird, ist es für den Angreifer ohne das Kennwort nicht von Nutzen. Die Multi-Faktor-Authentifizierung ist daher sicherer, aber auch komplexer als die Ein-Faktor-Authentifizierung.

Dienste, die eine Multi-Faktor-Authentifizierung verwenden, lassen den Benutzenden oft die Wahl, wie er die zweiten Anmeldeinformationen erhalten möchte. Ein Beispiel für diese Art der Authentifizierung ist ein allgemein verwendetes Verfahren, bei dem ein Verifizierungscode per SMS an das Mobiltelefon der Benutzenden gesendet wird.

Der/die Benutzende gibt den Namen und das Kennwort an den Identitätsanbieter weiter.
Der Identitätsanbieter überprüft den Namen und das Kennwort wie bei der Ein-Faktor-Autorisierung und sucht dann nach der im System gespeicherten Handynummer des/der Benutzenden.
Der Server sendet eine SMS-Nachricht mit einem generierten Verifizierungscode an das Mobiltelefon des/der Benutzenden.
Der/die Benutzende gibt den Code an den Identitätsanbieter weiter, und zwar über ein Formular, das dem/der Benutzenden vorgelegt wird.
Der Identitätsanbieter gibt einen Authentifizierungsstatus zurück, der angibt, ob die Authentifizierung beider Anmeldeinformationen erfolgreich war.
Wenn sie erfolgreich war, beginnt der Datenaustausch. Andernfalls muss der/die Benutzende erneut authentifiziert werden.

Zweistufige Authentifizierung

Wie Sie sehen, unterscheidet sich dieser Prozess auch insofern von der Ein-Faktor-Authentifizierung, indem die zweite Anmeldeinformation an den/die Benutzende*n geschickt wird, anstatt vom/von der Benutzenden erstellt oder bereitgestellt zu werden. Der/die Benutzende hat also nicht die vollständige Kontrolle über die erforderlichen Anmeldeinformationen. Dies gilt auch, wenn eine Smartcard als zweite Anmeldeinformation verwendet wird: Die Organisation ist für das Erstellen und Bereitstellen der Anmeldeinformationen für den/die Benutzende*n zuständig.

2.2.1 Azure Active Directory

Azure Active Directory (Azure AD) ist ein cloudbasierter Dienst für das Identitäts- und Zugriffsmanagement, der als Identitätsanbieter für die Ein-Faktor- oder Mehr-Faktor-Authentifizierung dienen kann. Die Azure AD-Authentifizierung kann mit oder ohne einen Verifizierungscode verwendet werden.

Azure AD kann zwar auch die Ein-Faktor-Authentifizierung implementieren, aber Unternehmen benötigen in der Regel die höhere Sicherheit der Multi-Faktor-Authentifizierung. Bei einer Multi-Faktor-Authentifizierung haben Benutzende, die sich mit einem Azure AD-Konto authentifizieren, die Möglichkeit, sich einen Verifizierungscode als SMS-Nachricht entweder an ihr Mobiltelefon oder an die Mobile-App Azure Authenticator senden zu lassen.

Darüber hinaus kann Azure AD als OAuth-Anbieter verwendet werden, der den Benutzenden einen Authentifizierungs- und Autorisierungsmechanismus für Apps auf verschiedenen Plattformen bietet. Mehr erfahren Sie unter Azure Active Directory und Multi-Faktor-Authentifizierung auf Azure.

2.4 Windows Hello

In Windows ist ein praktischer mehrstufiger Authentifizierungsmechanismus in das Betriebssystem integriert. Windows Hello ist das neue biometrische Anmeldesystem, das in Windows integriert ist. Da es direkt in das Betriebssystem integriert ist, bietet Windows Hello die Möglichkeit, die Geräte der Benutzenden per Gesichtserkennung oder Fingerabdruck zu entsperren. Der sichere Windows Store für Anmeldeinformationen schützt die biometrischen Daten auf dem Gerät.

Windows Hello bietet eine robuste Möglichkeit für ein Gerät, eine*n einzelne*n Benutzer*in zu erkennen, was den ersten Teil des Weges zwischen einem/einer Benutzenden und einem angeforderten Dienst oder Datenelement darstellt. Nachdem das Gerät den/die Benutzende*n erkannt hat, muss es ihn/sie noch authentifizieren, bevor es entscheidet, ob es den Zugriff auf eine angeforderte Ressource gewährt. Windows Hello bietet außerdem eine starke Zwei-Faktor-Authentifizierung (2FA), die vollständig in Windows integriert ist und wiederverwendbare Kennwörter durch die Kombination aus einem bestimmten Gerät und einer biometrischen Geste oder PIN ersetzt. Die PIN wird von Benutzenden im Rahmen der Registrierung des Microsoft-Kontos festgelegt.

Windows Hello ist jedoch nicht nur ein Ersatz für traditionelle 2FA-Systeme. Das Konzept ähnelt dem von Smartcards: Die Authentifizierung erfolgt mit kryptographischen Verfahren anstelle von Zeichenfolgenvergleichen, und das Schlüsselmaterial der Benutzenden ist in manipulationssicherer Hardware geschützt. Microsoft Hello erfordert auch nicht die zusätzlichen Infrastrukturkomponenten, die für die Bereitstellung von Smartcards erforderlich sind. Insbesondere benötigen Sie keine Public Key Infrastructure (PKI) zur Verwaltung von Zertifikaten, wenn Sie noch keine haben. Windows Hello kombiniert die wichtigsten Vorteile von Smartcards – die Flexibilität bei der Bereitstellung von virtuellen Smartcards und die robuste Sicherheit von physischen Smartcards – ohne deren Nachteile.

Ein Gerät muss bei Windows Hello registriert werden, bevor sich Benutzende damit authentifizieren können. Windows Hello verwendet eine asymmetrische Verschlüsselung (öffentlicher/privater Schlüssel), bei der eine Partei einen öffentlichen Schlüssel verwendet, um die Daten zu verschlüsseln, die die andere Partei mit einem privaten Schlüssel entschlüsseln kann. Im Falle von Windows Hello erstellt es eine Reihe von Paaren öffentlicher/privater Schlüssel und schreibt die privaten Schlüssel auf den TPM-Chip (Trusted Platform Module) des Geräts. Nachdem ein Gerät registriert wurde, können UWP-Apps System-APIs aufrufen, um den öffentlichen Schlüssel eines Benutzenden abzurufen, der dann zur Registrierung des/der Benutzenden auf dem Server verwendet werden kann.

Der Workflow für die Registrierung einer App könnte wie folgt aussehen:

Windows Hello-Registrierung

Die Registrierungsdaten, die Sie sammeln, können sehr viel mehr identifizierende Informationen enthalten als in diesem einfachen Szenario. Wenn Ihre App beispielsweise auf einen gesicherten Dienst wie einen Bankdienst zugreift, müssen Sie im Rahmen der Anmeldung einen Identitätsnachweis und andere Dinge anfordern. Sobald alle Bedingungen erfüllt sind, wird der öffentliche Schlüssel dieses/dieser Benutzenden im Back-End gespeichert und zur Validierung bei der nächsten Nutzung des Dienstes durch den/die Benutzende*n verwendet.

Weitere Informationen zu Windows Hello finden Sie in der Übersicht über Windows Hello for Business und im Windows Hello-Entwicklerhandbuch.

3 Data-in-flight-Sicherheitsmethoden

Data-in-flight-Sicherheitsmethoden gelten für Daten bei der Übertragung zwischen Geräten, die mit einem Netzwerk verbunden sind. Die Daten können zwischen Systemen in der hochsicheren Umgebung eines privaten Firmenintranets oder zwischen einem Client und einem Webdienst in der unsicheren Umgebung des Internets übertragen werden. Windows-Apps unterstützen Standards wie SSL über ihre Netzwerk-APIs und arbeiten mit Technologien wie Azure API Management, mit denen Entwickler das geeignete Sicherheitsniveau für ihre Apps sicherstellen können.

3.1 Remote-System-Authentifizierung

Es gibt zwei allgemeine Szenarien, in denen die Kommunikation mit einem Remote-Computersystem stattfindet.

Ein lokaler Server authentifiziert Benutzende über eine direkte Verbindung. Zum Beispiel, wenn sich der Server und der Client in einem Firmenintranet befinden.
Mit einem Webdienst wird über das Internet kommuniziert.

Die Sicherheitsanforderungen für die Kommunikation mit Webdiensten sind höher als bei Direktverbindungsszenarien, da die Daten nicht mehr nur Teil eines sicheren Netzwerks sind und die Wahrscheinlichkeit, dass Angreifer versuchen, Daten abzufangen, ebenfalls höher ist. Da verschiedene Arten von Geräten auf den Dienst zugreifen werden, werden sie wahrscheinlich als RESTful-Dienste erstellt, im Gegensatz zu WCF beispielsweise, was bedeutet, dass die Authentifizierung und Autorisierung für den Dienst ebenfalls neue Herausforderungen mit sich bringt. Wir werden zwei Anforderungen für eine sichere Kommunikation mit Remote-Systemen erörtern.

Die erste Anforderung ist die Vertraulichkeit der Nachrichten: Die zwischen dem Client und den Webdiensten übermittelten Informationen (z. B. die Identität des/der Benutzenden und andere personenbezogene Daten) dürfen während der Übermittlung nicht von Dritten gelesen werden können. Dies wird in der Regel durch die Verschlüsselung der Verbindung, über die Nachrichten gesendet werden, und durch die Verschlüsselung der Nachricht selbst erreicht. Bei der Verschlüsselung mit privatem/öffentlichem Schlüssel ist der öffentliche Schlüssel für jedermann zugänglich und wird zur Verschlüsselung von Nachrichten verwendet, die an einen bestimmten Empfänger gesendet werden sollen. Der private Schlüssel befindet sich nur im Besitz des/der Empfänger*in und wird zum Entschlüsseln der Nachricht verwendet.

Die zweite Anforderung ist die Integrität der Nachrichten: Der Client und der Webdienst müssen in der Lage sein, zu überprüfen, ob die Nachrichten, die sie erhalten, auch wirklich von der anderen Partei gesendet wurden und ob die Nachricht während der Übertragung nicht verändert wurde. Dies wird durch das Signieren von Nachrichten mit digitalen Signaturen und die Verwendung von Zertifikaten erreicht.

3.2 SSL connections

Um sichere Verbindungen zu Clients herzustellen und aufrechtzuerhalten, können Webdienste Secure Sockets Layer (SSL) verwenden, das vom Secure Hypertext Transfer Protocol (HTTPS) unterstützt wird. SSL sorgt für die Vertraulichkeit und Integrität von Nachrichten, indem es sowohl die Verschlüsselung mit öffentlichen Schlüsseln als auch Server-Zertifikate unterstützt. SSL wurde durch Secure Socket Layer Security (TLS) abgelöst, aber TLS wird oft einfach nur als SSL bezeichnet.

Wenn ein Client Zugriff auf eine Ressource auf einem Server anfordert, beginnt SSL einen Verhandlungsprozess mit dem Server. Dies wird als SSL-Handshake bezeichnet. Für die Dauer der SSL-Verbindung werden eine Verschlüsselungsstufe, ein Satz öffentlicher und privater Verschlüsselungsschlüssel sowie die Identitätsinformationen in den Zertifikaten von Client und Server als Grundlage für die gesamte Kommunikation vereinbart. Der Server kann auch eine Authentifizierung des Clients zu diesem Zeitpunkt vorschreiben. Sobald die Verbindung hergestellt ist, werden alle Nachrichten mit dem ausgehandelten öffentlichen Schlüssel verschlüsselt, bis die Verbindung geschlossen wird.

3.2.1 SSL-Pinning

SSL kann zwar mit Hilfe von Verschlüsselung und Zertifikaten die Vertraulichkeit von Nachrichten gewährleisten, aber es kann nicht überprüfen, ob der Server, mit dem der Client kommuniziert, der richtige ist. Das Verhalten des Servers kann von einem unbefugten Dritten nachgeahmt werden, der die sensiblen Daten abfängt, die der Client überträgt. Um dies zu verhindern, wird eine Technik namens SSL-Pinning verwendet, um zu überprüfen, ob das Zertifikat auf dem Server das Zertifikat ist, das der Client erwartet und dem er vertraut.

Es gibt verschiedene Möglichkeiten, SSL-Pinning in Apps zu implementieren, jede mit ihren eigenen Vor- und Nachteilen. Der einfachste Ansatz ist die Deklaration von Zertifikaten im Paket-Manifest der App. Diese Deklaration ermöglicht es dem App-Paket, digitale Zertifikate zu installieren und ihnen exklusiv zu vertrauen. Dies führt dazu, dass SSL-Verbindungen nur zwischen der App und Servern zugelassen werden, die die entsprechenden Zertifikate in ihrer Zertifikatskette haben. Dieser Mechanismus ermöglicht auch die sichere Verwendung von selbst signierten Zertifikaten, da keine Abhängigkeiten von einer dritten Partei zu vertrauenswürdigen öffentlichen Zertifizierungsstellen erforderlich sind.

SSL-Manifest

Um mehr Kontrolle über die Validierungslogik zu haben, stehen APIs zur Verfügung, mit denen Sie das/die Zertifikat(e) validieren können, die vom Server als Antwort auf eine HTTPS-Anfrage zurückgegeben werden. Beachten Sie, dass bei dieser Methode eine Anfrage gesendet und die Antwort geprüft werden muss. Fügen Sie dies also als Validierung hinzu, bevor Sie tatsächlich sensible Informationen in einer Anfrage senden.

Der folgende C#-Code veranschaulicht diese Methode des SSL-Pinning. Die Methode ValidateSSLRoot verwendet die Klasse HttpClient zur Ausführung einer HTTP-Anfrage. Nachdem der Client die Antwort gesendet hat, verwendet er die Sammlung RequestMessage.TransportInformation.ServerIntermediateCertificates, um die vom Server zurückgegebenen Zertifikate zu prüfen. Der Client kann dann die gesamte Zertifikatskette mit den enthaltenen Thumbprints validieren. Bei dieser Methode müssen die Zertifikats-Thumbprints in der App aktualisiert werden, wenn das Zertifikat des Servers abläuft und erneuert wird.

private async Task ValidateSSLRoot()
{
    // Send a get request to Bing
    var httpClient = new HttpClient();
    var bingUri = new Uri("https://www.bing.com");
    HttpResponseMessage response = 
        await httpClient.GetAsync(bingUri);

    // Get the list of certificates that were used to
    // validate the server's identity
    IReadOnlyList<Certificate> serverCertificates = response.RequestMessage.TransportInformation.ServerIntermediateCertificates;
  
    // Perform validation
    if (!ValidateCertificates(serverCertificates))
    {
        // Close connection as chain is not valid
        return;
    }
    // Validation passed, continue with connection to service
}

private bool ValidateCertificates(IReadOnlyList<Certificate> certs)
{
    // In this example, we iterate through the certificates
    // and check that the chain contains
    // one specific certificate we are expecting
    foreach (var cert in certs)
    {
        byte[] thumbprint = cert.GetHashValue();

        // Check if the thumbprint matches whatever you 
        // are expecting
        var expected = new byte[] { 212, 222, 32, 208, 94, 102, 
            252, 83, 254, 26, 80, 136, 44, 120, 219, 40, 82, 202, 
            228, 116 };

        // ThumbprintMatches does the byte[] comparison 
        if (ThumbprintMatches(thumbprint, expected))
        {
            return true;
        }
    }
    return false;
}

3.3 Veröffentlichen und Sichern des Zugriffs auf REST-APIs

Um einen autorisierten Zugriff auf Webdienste zu gewährleisten, müssen sie bei jedem API-Aufruf eine Authentifizierung voraussetzen. Auch die Kontrolle der Leistung und Skalierung ist ein wichtiger Aspekt, wenn Webdienste im Internet veröffentlicht werden. Azure API Management ist ein Dienst, der bei der Bereitstellung von APIs im Internet helfen kann und dabei Funktionen auf drei Ebenen bietet.

Publisher/Administrator*innen der API können die API ganz einfach über das Publisher-Portal von Azure API Management konfigurieren. Hier können API-Sets erstellt und der Zugriff auf sie verwaltet werden, um zu kontrollieren, wer auf welche APIs Zugriff hat.

Entwickler*innen, die Zugriff auf diese APIs wünschen, können über das Entwicklerportal Anfragen stellen, die entweder sofort Zugriff gewähren oder vom/von der Publisher/Administrator*in genehmigt werden müssen. Entwickler*innen können auch die API-Dokumentation und den Beispielcode im Entwicklerportal einsehen, um die vom Webdienst angebotenen APIs schnell zu adaptieren.

Die Apps, die diese Entwickler*innen erstellen, greifen dann über den von Azure API Management angebotenen Proxy auf die API zu. Der Proxy bietet eine transparente Schicht, die den tatsächlichen Endpunkt der API auf dem Server des/der Publishers/Administrator*in verbirgt, und kann auch zusätzliche Logik wie die API-Übersetzung enthalten, um sicherzustellen, dass die offengelegte API konsistent bleibt, wenn ein Aufruf einer API zu einer anderen umgeleitet wird. Außerdem kann der Dienst eine IP-Filterung verwenden, um API-Aufrufe zu blockieren, die von einer bestimmten IP-Domäne oder einer Gruppe von Domänen stammen. Azure API Management sorgt auch für die Sicherheit seiner Webdienste, indem es eine Reihe von öffentlichen Schlüsseln, die sogenannten API-Schlüssel, verwendet, um jeden API-Aufruf zu authentifizieren und zu autorisieren. Wenn die Autorisierung fehlschlägt, wird der Zugriff auf die API und die von ihr unterstützten Funktionen blockiert.

Azure API Management kann auch die Anzahl der API-Aufrufe für einen Dienst reduzieren (ein Verfahren, das als Drosselung bezeichnet wird), um die Leistung des Webdienstes zu optimieren. Um mehr zu erfahren, lesen Sie Azure API Management und Azure API Management auf der AzureCon 2015.

4 Data-at-Rest-Sicherheitsmethoden

Wenn Daten auf einem Gerät eintreffen, bezeichnen wir sie als „Data-at-Rest“. Diese Daten müssen auf dem Gerät auf sichere Weise gespeichert werden, sodass unbefugte Benutzende oder Apps nicht darauf zugreifen können. Das App-Modell in Windows bietet viele Möglichkeiten, um sicherzustellen, dass die von jeder App gespeicherten Daten nur für diese App zugänglich sind, während APIs bereitgestellt werden, um die Daten bei Bedarf freizugeben. Darüber hinaus stehen zusätzliche APIs zur Verfügung, um sicherzustellen, dass Daten verschlüsselt und Anmeldeinformationen sicher gespeichert werden können.

4.1 Windows-App-Modell

Traditionell gab es in Windows nie eine Definition für eine App. Sie wurde allgemein als ausführbare Datei (.exe) bezeichnet, und dies beinhaltete nie die Installation, die Speicherung des Status, die Ausführungsdauer, die Versionsverwaltung, die Integration des Betriebssystems oder die Kommunikation von App zu App. Das Modell der Universal Windows Platform definiert ein App-Modell, das Installation, Laufzeitumgebung, Ressourcenverwaltung, Updates, Datenmodell und Deinstallation umfasst.

Windows 10-Apps werden in einem Container ausgeführt, was bedeutet, dass sie standardmäßig über eingeschränkte Berechtigungen verfügen (zusätzliche Berechtigungen können von Benutzenden angefordert und gewährt werden). Wenn eine App beispielsweise auf Dateien im System zugreifen möchte, muss ein File-Picker aus dem Windows.Storage.Pickers-Namespace verwendet werden, damit Benutzende eine Datei wählen können (der direkte Zugriff auf Dateien ist nicht aktiviert). Ein weiteres Beispiel: Wenn eine App auf die Standortdaten von Benutzenden zugreifen möchte, muss sie die Funktionalitäten für den Standort des Geräts aktivieren und den/die Benutzende*n beim Download darauf hinweisen, dass diese App den Zugriff auf den Standort des/der Benutzenden anfordern wird. Wenn die App das erste Mal auf den Standort des/der Benutzenden zugreifen will, wird dem/der Benutzenden außerdem eine zusätzliche Abfrage zur Genehmigung des Zugriffs auf die Daten angezeigt.

Beachten Sie, dass dieses App-Modell als „Jail“ für Apps fungiert, d. h. dass sie nicht nach außen gelangen können. Es handelt sich jedoch nicht um ein abgeschlossenes System, das von außen nicht erreicht werden kann (Anwendungen mit Administrator*innen-Rechten können natürlich trotzdem hineingelangen). Device Guard in Windows, mit dem Organisationen/IT angeben können, welche (Win32)-Apps ausgeführt werden dürfen, können diesen Zugriff weiter einschränken.

Das App-Modell verwaltet auch den Lebenszyklus von Apps. Es schränkt beispielsweise die Ausführung von Apps im Hintergrund standardmäßig ein. Sobald eine App in den Hintergrund tritt, wird der Prozess angehalten – nachdem der App eine kurze Zeit eingeräumt wurde, um die Aussetzung der App im Code zu behandeln – und ihr Speicher wird eingefroren. Das Betriebssystem verfügt über Mechanismen, mit denen Apps die Ausführung bestimmter Hintergrundaufgaben anfordern können (nach einem Zeitplan, ausgelöst durch verschiedene Ereignisse wie Internet-/Bluetooth-Verbindung, Energieänderungen usw., und in bestimmten Szenarien wie Musikwiedergabe oder GPS-Ortung).

Wenn die Ressourcen auf dem Gerät zur Neige gehen, gibt Windows den Speicherplatz frei, indem es Apps beendet. Dieses Lebenszyklusmodell zwingt Apps dazu, Daten immer dann zu speichern, wenn sie angehalten werden, da zwischen dem Anhalten und dem Beenden keine zusätzliche Zeit zur Verfügung steht.

Weitere Informationen finden Sie unter Universell: Den Lebenszyklus einer Windows 10/11 Anwendung verstehen.

4.2 Schutz gespeicherter Anmeldeinformationen

Windows Apps, die auf authentifizierte Dienste zugreifen, bieten den Benutzenden oft die Möglichkeit, ihre Anmeldeinformationen auf dem lokalen Gerät zu speichern. Dies ist für die Benutzenden sehr praktisch: Wenn sie ihren Namen und ihr Kennwort angeben, verwendet die App diese Daten automatisch bei späteren Starts der App. Da dies ein Sicherheitsproblem sein kann, wenn ein Angreifer Zugriff auf diese gespeicherten Daten erhält, bietet Windows die Möglichkeit für verpackte Apps, Benutzeranmeldeinformationen in einem sicheren Schließfach für Anmeldeinformationen zu speichern. Die App ruft die Credential Locker-API auf, um die Anmeldeinformationen im Locker zu speichern und abzurufen, anstatt sie im Speicher-Container der App zu speichern. Der Zugang zum Anmeldeinformationsspeicher wird vom Betriebssystem verwaltet, ist aber auf die App beschränkt, die die Anmeldeinformationen speichert, und bietet somit eine sicher verwaltete Lösung für die Speicherung von Anmeldeinformationen.

Wenn ein/eine Benutzende*r die Anmeldeinformationen angibt, die gespeichert werden sollen, erhält die App über das PasswordVault-Objekt im Windows.Security.Credentials-Namespace eine Referenz auf den Credential Locker. Sie erstellt dann ein PasswordCredential-Objekt, das einen Identifier für die Windows-App sowie den Namen und das Kennwort enthält. Dieser wird an die Methode PasswordVault.Add übergeben, um die Anmeldeinformationen im Locker zu speichern. Das folgende C#-Code-Beispiel zeigt, wie dies geschieht.

var vault = new PasswordVault();
vault.Add(new PasswordCredential("My App", username, password));

Im folgenden C#-Code-Beispiel fordert die App alle der App zugeordneten Anmeldeinformationen an, indem sie die Methode FindAllByResource des Objekts PasswordVault aufruft. Wenn mehr als eine zurückgegeben wird, wird der/die Benutzende aufgefordert, den Namen einzugeben. Befinden sich die Anmeldeinformationen nicht im Locker, fordert die App den/die Benutzende*n auf, sie einzugeben. Der/die Benutzende wird dann mit den Anmeldeinformationen beim Server angemeldet.

private string resourceName = "My App";
private string defaultUserName;

private void Login()
{
    PasswordCredential loginCredential = GetCredentialFromLocker();

    if (loginCredential != null)
    {
        // There is a credential stored in the locker.
        // Populate the Password property of the credential
        // for automatic login.
        loginCredential.RetrievePassword();
    }
    else
    {
        // There is no credential stored in the locker.
        // Display UI to get user credentials.
        loginCredential = GetLoginCredentialUI();
    }
    // Log the user in.
    ServerLogin(loginCredential.UserName, loginCredential.Password);
}

private PasswordCredential GetCredentialFromLocker()
{
    PasswordCredential credential = null;

    var vault = new PasswordVault();

    IReadOnlyList<PasswordCredential> credentialList = null;

    try
    {
        credentialList = vault.FindAllByResource(resourceName);
    }
    catch(Exception)
    {
        return null;
    }

    if (credentialList.Count == 1)
    {
        credential = credentialList[0];
    }
    else if (credentialList.Count > 0)
    {
        // When there are multiple usernames,
        // retrieve the default username. If one doesn't
        // exist, then display UI to have the user select
        // a default username.
        defaultUserName = GetDefaultUserNameUI();

        credential = vault.Retrieve(resourceName, defaultUserName);
    }
    return credential;
}

Weitere Informationen finden Sie unter Credential Locker.

4.3 Schutz gespeicherter Daten

Wenn Sie es mit gespeicherten Daten zu tun haben, die allgemein als Data-at-Rest bezeichnet werden, kann deren Verschlüsselung verhindern, dass unbefugte Benutzende auf die gespeicherten Daten zugreifen. Die beiden gängigen Mechanismen zur Verschlüsselung von Daten sind entweder die Verwendung symmetrischer Schlüssel oder die Verwendung asymmetrischer Schlüssel. Die Verschlüsselung von Daten kann jedoch nicht gewährleisten, dass die Daten zwischen dem Zeitpunkt, an dem sie gesendet wurden, und dem Zeitpunkt, an dem sie gespeichert wurden, unverändert geblieben sind. Mit anderen Worten: Die Integrität der Daten kann nicht gewährleistet werden. Die Verwendung von Codes zur Authentifizierung von Nachrichten, Hashes und digitalen Signaturen sind allgemeine Techniken zur Lösung dieses Problems.

4.3.1 Datenverschlüsselung

Bei der symmetrischen Verschlüsselung haben sowohl der/die Absender*in als auch der/die Empfänger*in denselben Schlüssel und verwenden diesen sowohl zur Verschlüsselung als auch zur Entschlüsselung der Daten. Die Herausforderung bei diesem Ansatz ist die sichere Weitergabe des Schlüssels, sodass beide Parteien ihn kennen.

Eine Antwort darauf ist die asymmetrische Verschlüsselung, bei der ein öffentliches/privates Schlüsselpaar verwendet wird. Der öffentliche Schlüssel wird mit jedem geteilt, der eine Nachricht verschlüsseln möchte. Der private Schlüssel wird immer geheim gehalten, sodass nur Sie ihn zur Entschlüsselung der Daten verwenden können. Eine allgemeine Technik, die die Möglichkeit bietet, den öffentlichen Schlüssel zu ermitteln, ist die Verwendung von digitalen Zertifikaten, die auch einfach als Zertifikate bezeichnet werden. Das Zertifikat enthält Informationen über den öffentlichen Schlüssel, zusätzlich zu Informationen über den/die Benutzende*n oder den Server wie Name, Aussteller, E-Mail-Adresse und Land.

Entwickler*innen von Windows-Apps können die Klassen SymmetricKeyAlgorithmProvider und AsymmetricKeyAlgorithmProvider verwenden, um symmetrische und asymmetrische Verschlüsselung in ihren UWP-Apps zu implementieren. Darüber hinaus kann die Klasse CryptographicEngine verwendet werden, um Daten zu ver- und entschlüsseln, Inhalte zu signieren und digitale Signaturen zu überprüfen. Apps können auch die Klasse DataProtectionProvider im Namespace Windows.Security.Cryptography.DataProtection verwenden, um lokal gespeicherte Daten zu ver- und entschlüsseln.

4.3.2 Erkennen von Manipulationen an Nachrichten (MACs, Hashes und Signaturen)

Ein MAC ist ein Code (oder Tag), der sich aus der Verwendung eines symmetrischen Schlüssels (des sogenannten Secret Key) oder einer Nachricht als Eingabe für einen MAC-Verschlüsselungsalgorithmus ergibt. Der geheime Schlüssel und der Algorithmus werden vor der Übertragung der Nachricht zwischen dem Sender und dem Empfänger vereinbart.

MACs verifizieren Nachrichten auf diese Weise.

Der Absender leitet das MAC-Tag ab, indem er den geheimen Schlüssel als Eingabe für den MAC-Algorithmus verwendet.
Der Absender sendet das MAC-Tag und die Nachricht an den Empfänger.
Der Empfänger leitet das MAC-Tag ab, indem er den geheimen Schlüssel und die Nachricht als Eingabe für den MAC-Algorithmus verwendet.
Der Empfänger vergleicht sein MAC-Tag mit dem MAC-Tag des Absenders. Wenn sie übereinstimmen, wissen wir, dass die Nachricht nicht verfälscht worden ist.

Mac-Überprüfung

Windows Apps können die Verifizierung von MAC Nachrichten implementieren, indem sie die MacAlgorithmProvider -Klasse aufrufen, um den Schlüssel zu generieren und die CryptographicEngine -Klasse, um den MAC Verschlüsselungsalgorithmus durchzuführen.

4.3.3 Verwendung von Hashes

Eine Hash-Funktion ist ein kryptographischer Algorithmus, der aus einem beliebig langen Datenblock eine Zeichenfolge fester Größe, den sogenannten Hash-Wert, zurückgibt. Es gibt eine ganze Familie von Hash-Funktionen, die dies tun können.

Ein Hash-Wert kann in dem oben beschriebenen Szenario zur Übertragung von Nachrichten anstelle eines MAC verwendet werden. Der Absender sendet einen Hash-Wert und eine Nachricht, und der Empfänger leitet seinen eigenen Hash-Wert aus dem Hash-Wert des Absenders und der Nachricht ab und vergleicht die beiden Hash-Werte. Apps, die unter Windows ausgeführt werden, können die HashAlgorithmProvider-Klasse aufrufen, um die verfügbaren Hashalgorithmen aufzulisten und eine davon auszuführen. Die Klasse CryptographicHash stellt den Hash-Wert dar. Die Methode CryptographicHash.GetValueAndReset kann verwendet werden, um verschiedene Daten wiederholt zu hashen, ohne dass das Objekt für jede Verwendung neu erstellt werden muss. Die Methode Append der Klasse CryptographicHash fügt neue Daten zu einem Puffer hinzu, der gehasht werden soll. Dieser gesamte Prozess wird in dem folgenden C#-Code-Beispiel gezeigt.

public void SampleReusableHash()
{
    // Create a string that contains the name of the
    // hashing algorithm to use.
    string strAlgName = HashAlgorithmNames.Sha512;

    // Create a HashAlgorithmProvider object.
    HashAlgorithmProvider objAlgProv = HashAlgorithmProvider.OpenAlgorithm(strAlgName);

    // Create a CryptographicHash object. This object can be reused to continually
    // hash new messages.
    CryptographicHash objHash = objAlgProv.CreateHash();

    // Hash message 1.
    string strMsg1 = "This is message 1";
    IBuffer buffMsg1 = CryptographicBuffer.ConvertStringToBinary(strMsg1, BinaryStringEncoding.Utf16BE);
    objHash.Append(buffMsg1);
    IBuffer buffHash1 = objHash.GetValueAndReset();

    // Hash message 2.
    string strMsg2 = "This is message 2";
    IBuffer buffMsg2 = CryptographicBuffer.ConvertStringToBinary(strMsg2, BinaryStringEncoding.Utf16BE);
    objHash.Append(buffMsg2);
    IBuffer buffHash2 = objHash.GetValueAndReset();

    // Convert the hashes to string values (for display);
    string strHash1 = CryptographicBuffer.EncodeToBase64String(buffHash1);
    string strHash2 = CryptographicBuffer.EncodeToBase64String(buffHash2);
}

4.3.4 Digitale Signaturen

Die Datenintegrität einer digital signierten gespeicherten Nachricht wird auf ähnliche Weise wie bei der MAC-Authentifizierung überprüft. Der Workflow für digitale Signaturen läuft folgendermaßen ab.

Der Absender leitet einen Hash-Wert (auch als Digest bezeichnet) ab, indem er die Nachricht als Eingabe für einen Hash-Algorithmus verwendet.
Der Absender verschlüsselt den Hashwert mit seinem privaten Schlüssel.
Der Absender sendet die Nachricht, den verschlüsselten Digest und den Namen des verwendeten Hash-Algorithmus.
Der Empfänger verwendet den öffentlichen Schlüssel, um den verschlüsselten Digest, den er erhalten hat, zu entschlüsseln. Dann verwendet er den Hash-Algorithmus, um die Nachricht zu hashen und einen eigenen Digest zu erstellen. Und schließlich vergleicht der Empfänger die beiden Digests (den empfangenen und entschlüsselten und den selbst erstellten). Nur wenn die beiden übereinstimmen, kann der Empfänger sicher sein, dass die Nachricht von dem Besitzer des privaten Schlüssels gesendet wurde, dass er also derjenige ist, der er vorgibt zu sein, und dass die Nachricht während der Übertragung nicht verändert wurde.

Digitale Signaturen

Hash-Algorithmen sind sehr schnell, sodass Hash-Werte auch aus großen Nachrichten schnell abgeleitet werden können. Der resultierende Hash-Wert hat eine beliebige Länge und kann kürzer sein als die vollständige Nachricht, sodass die Verwendung öffentlicher und privater Schlüssel zum Ver- und Entschlüsseln nur des Digest und nicht der vollständigen Nachricht eine Optimierung darstellt.

Weitere Informationen finden Sie in den Artikeln Digitale Signaturen, MACs, Hashes und Signaturen und Kryptographie.

5 Zusammenfassung

Die Universelle Windows-Plattform in Windows bietet eine Reihe von Möglichkeiten zum Nutzen von Betriebssystemfunktionen zum Erstellen sichererer Apps. In verschiedenen Authentifizierungsszenarien, wie z. B. Ein-Faktor-, Multi-Faktor- oder vermittelte Authentifizierung mit einem OAuth-Identitätsanbieter, gibt es APIs, um die allgemeinsten Herausforderungen bei der Authentifizierung zu meistern. Windows Hello bietet ein neues, biometrisches Anmeldesystem, das Benutzende erkennt und Versuche, die korrekte Identifizierung zu umgehen, aktiv vereitelt. Außerdem bietet es mehrere Schichten von Schlüsseln und Zertifikaten, die niemals außerhalb des vertrauenswürdigen Plattformmoduls offengelegt oder verwendet werden können. Darüber hinaus steht eine weitere Sicherheitsschicht durch die optionale Verwendung von Identitätsschlüsseln und Zertifikaten zum Nachweis zur Verfügung.

Um Daten während der Übertragung zu schützen, gibt es APIs, die sicher über SSL mit Remote-Systemen kommunizieren und gleichzeitig die Möglichkeit bieten, die Authentizität des Servers durch SSL-Pinning zu überprüfen. Azure API Management hilft Ihnen dabei, APIs sicher und kontrolliert zu veröffentlichen, indem es leistungsstarke Konfigurationsoptionen für die Veröffentlichung von APIs im Web über einen Proxy bereitstellt, der eine zusätzliche Verschleierung des API-Endpunkts ermöglicht. Der Zugriff auf diese APIs wird durch die Verwendung von API-Schlüsseln gesichert, und API-Aufrufe können gedrosselt werden, um die Leistung zu kontrollieren.

Wenn die Daten auf dem Gerät ankommen, bietet das Windows App-Modell mehr Kontrolle darüber, wie die App installiert wird, wie sie aktualisiert wird und wie sie auf ihre Daten zugreift, und verhindert gleichzeitig, dass sie unbefugt auf Daten anderer Apps zugreift. Credential Locker kann einen sicheren Speicher für Anmeldeinformationen des/der Benutzenden bieten, der vom Betriebssystem verwaltet wird, und andere Daten können auf dem Gerät durch die von der Universal Windows Platform angebotenen Verschlüsselungs- und Hashing-APIs geschützt werden.

Freigeben über