Gemeinsame Verantwortung für die Liveness-Erkennung bei Gesichtern

Azure und seine Kunden sind gemeinsam dafür verantwortlich, eine sichere und konforme Liveness-Lösung für die Gesichtserkennung zu entwickeln. Weitere Informationen zur gemeinsamen Verantwortung von Azure finden Sie unter Gemeinsame Verantwortung in der Cloud. Das Verständnis des Modells der gemeinsamen Verantwortung ist besonders wichtig für Liveness-Erkennungslösungen. Dieses Dokument behandelt verschiedene Aspekte, wie Sie Ihre Lösung sichern und überwachen können.

Sichern der Verbindungen

Das folgende Diagramm zeigt, wie Kunden mit Azure zusammenarbeiten, um eine End-to-End-Sicherung der Verbindungen zu erreichen.

Befolgen Sie diese Richtlinien, um die Verbindungen zu sichern:

• Stellen Sie sicher, dass Ihr Back-End-Dienst als Orchestrator in Liveness-Erkennungsanwendungen fungiert, und nutzen Sie die Sicherheitsinfrastruktur von Azure, um Liveness-Erkennungssitzungen zu initiieren und die Ergebnisse zu untersuchen. Kunden sind für die Sicherung ihrer Back-End-Dienste verantwortlich.
• Implementieren Sie eine ordnungsgemäße Authentifizierung und Autorisierung für die Clientanwendung im Back-End. Stellen Sie sicher, dass die Kommunikation zwischen der Clientanwendung und dem Back-End-Dienst vor Manipulationen geschützt ist.
• Authentifizieren Sie die reale Identität von Endbenutzenden, und verknüpfen Sie deren Kontoinformationen mit der Liveness-Sitzung.
• Signieren Sie die Anwendung, und vertreiben Sie sie nur über offizielle Stores.

Die Azure-Liveness-Erkennung sichert die Verbindung auf folgende Weise:

• Überprüfen aller Transaktionen mithilfe des Sitzungsautorisierungstokens, das über die Sitzungserstellungs-API abgerufen wird.
• Nur HTTPS-Aufrufe an den Back-End-Dienst werden zugelassen.
• Unterstützung der Einrichtung von IAM-Rollen (Identity Access Management) für Kunden zur Authentifizierung und Durchführung von Aktionen.

Sichern der Clientanwendung

Ein erfahrener Angreifer könnte die Clientanwendung ändern oder manipulieren, wodurch das Liveness-Ergebnis möglicherweise nicht mehr vertrauenswürdig ist. Verwenden Sie je nach Plattform Ihrer Anwendung unterschiedliche Ansätze:

Mobile Anwendungen

Sowohl für Android- als auch für iOS-Plattformen gibt es native Lösungen und Lösungen von Drittanbietern zur Überprüfung der Anwendungsintegrität, wie z. B. iOS App Attest und Android Play Integrity. Es liegt in der Verantwortung des Anwendungsentwicklers, die Integritätsprüfungsfunktion zu integrieren und umgehend auf potenzielle Hacks zu reagieren.

Die Azure-Liveness-Erkennung implementiert Schutzmaßnahmen gegen nicht vertrauenswürdige Runtimeumgebungen. Das Liveness-Erkennungs-SDK bietet einen Digest der Aufrufe seines Liveness-Erkennungsdiensts, der an die APIs für die Anwendungsintegrität weitergeleitet werden kann.

Webanwendungen

Webanwendungen werden im Kontext der Browser ausgeführt, in denen sie geladen werden. Moderne Browser unterstützen robuste Anwendungsintegritätsprüfungen. Sie sind für die Implementierung der Integritätsprüfungen der Webanwendung verantwortlich, die in Browsern bereitgestellt wird. Zu diesen Verantwortlichkeiten gehören unter anderem:

• Sicherstellen, dass Sicherheitsheader ordnungsgemäß konfiguriert sind. Insbesondere sollte besonderes Augenmerk auf Zwischenspeichern, HTTP Strict Transport Security (HSTS), iframe und ursprungsübergreifende Richtlinien gelegt werden.
• Konfigurieren der strengstmöglichen Richtlinie für Inhaltssicherheit (Content Security Policy, CSP) für alle Ressourcen. CSP hilft dabei, Cross-Site-Scripting-Angriffe (XSS), Clickjacking und Schwachstellen im Zusammenhang mit Seiten mit gemischten Inhalten zu verhindern.
• Aktivieren der Integrität von Unterressourcen (Sub-Resource Integrity, SRI) über CSP und Überprüfen, ob das geladene SDK eine authentische von Microsoft veröffentlichte Kopie ist.

Azure veröffentlicht kryptografische Hashes des Web-SDK für Liveness-Erkennung zusammen mit jeder Version, die Kunden in ihrem CSP-Header für Skriptintegrität verwenden können. Azure stellt außerdem sicher, dass das Web-SDK innerhalb der Funktionseinschränkungen des Sicherheitskontexts in modernen Browsern ausgeführt werden kann.

Sichern des Clientgeräts

Verschiedene Anwendungen haben je nach ihren spezifischen Anwendungsfällen und Szenarien unterschiedliche Sicherheitsanforderungen, die von grundlegenden bis hin zu sehr strengen Protokollen reichen. Sie sollten die Sicherheitsmaßnahmen an diese Anforderungen anpassen. Hier stellen wir die verschiedenen Sicherheitsstufen vor, die für unterschiedliche Umgebungen erforderlich sind.

Sowohl auf Android- als auch auf iOS-Plattformen umfassen Lösungen für die Anwendungsintegrität (einschließlich ihrer jeweiligen Erstanbieterangebote) bereits die Geräteintegrität und/oder -zuverlässigkeit. Kunden, die Webanwendungen implementieren und deren Sicherheitsbaseline die Geräteintegrität umfassen muss, müssen sicherstellen, dass auf die Anwendung nur über einen vertrauenswürdigen modernen Browser auf einem vertrauenswürdigen Gerät zugegriffen wird. In der Regel umfasst dieser Prozess Folgendes:

• Verwaltungslösung für Unternehmensgeräte, die für die Verwaltung des Geräts durch Zugriff auf die Anwendung konfiguriert ist
• Virtuelles Netzwerk zur Isolierung der Gerätekommunikation mit Azure, durchgesetzt von der Geräteverwaltung
• Sicherer Start zur Gewährleistung der Hardwareintegrität, durchgesetzt von der Geräteverwaltung
• Lieferkettensicherheit für höhere Sicherheitsbaselines, die sicherstellen können, dass das Gerät bereits verwaltet wird und alle seine Sicherheitsrichtlinien ab dem Zeitpunkt der Herstellung durchgesetzt werden

Diese Überlegungen gelten auch für Android- und iOS-Plattformen.

Die Azure-Gesichtserkennungs-API unterstützt virtuelle Netzwerke und private Endpunkte. Weitere Informationen finden Sie in der Anleitung.

Kunden, die eine hohe Sicherheitsbaseline verwenden, können auf eine Geräteverwaltungslösung wie Microsoft Defender für Endpunkte zurückgreifen.

Lösung auf dem neuesten Stand halten

Microsoft aktualisiert regelmäßig das Client-SDK und den Dienst zur Liveness-Erkennung, um die Sicherheit, Zuverlässigkeit und Benutzerfreundlichkeit zu verbessern. Es ist von entscheidender Bedeutung, bei diesen Updates auf dem neuesten Stand zu bleiben, da das Liveness-Erkennungsfeld aktiven und ausgereiften Angriffen ausgesetzt ist. Kunden sollten immer das neueste clientseitige SDK, den neuesten Dienst und das neueste Modell verwenden. Weitere Informationen finden Sie unter Grundlegendes zu clientseitigen SDK-Versionen.

Überwachen von Missbrauch

Gesichtserkennungstechnologie kann, wenn sie für die Zugriffsautorisierung verwendet wird, ein Ziel für Angreifer sein, die versuchen, sie oder die darauf aufbauende Liveness-Erkennungstechnologie zu umgehen. Diese Versuche beinhalten oft Brute-Force-Angriffe auf verschiedene Materialien, wie z. B. verschiedene gedruckte Fotos, vor dem System, was als Systemmissbrauch gilt. Um solche Brute-Force-Angriffe abzuschwächen, können Sie bestimmte Maßnahmen in Bezug auf die Anzahl der Wiederholungsversuche und die Ratenbegrenzung ergreifen.

• Erstellen einer Sitzung mit konservativen Aufruf- und Zeitbeschränkungen: Eine Sitzung dient als erste Verteidigungslinie des Liveness-Erkennungsprozesses, indem sie Brute-Force-Angriffe abwehrt. Für jede Sitzung wird ein Sitzungsautorisierungstoken generiert, das für eine voreingestellte Anzahl von Erkennungs- oder Liveness-Erkennungsversuchen verwendet werden kann. Wenn Benutzende der Anwendung die Versuchsgrenzwerte nicht einhalten, ist ein neues Token erforderlich. Die Anforderung eines neuen Tokens ermöglicht eine Neubewertung des mit weiteren Versuchen verbundenen Risikos. Durch die Festlegung einer konservativ niedrigen Anzahl zulässiger Aufrufe pro Sitzung können Sie dieses Risiko häufiger neu auswerten, bevor Sie ein neues Token ausgeben.
• Verwenden des entsprechenden Korrelationsbezeichners beim Erstellen einer Sitzung: Die Gerätekorrelations-ID ermöglicht die automatische Missbrauchsüberwachung innerhalb der Gesichtserkennungs-API, um Ihnen dabei zu helfen, missbräuchlichen Datenverkehr zu Ihrem System zu verweigern. Wenn ein bestimmter Korrelationsbezeichner den Schwellenwert für missbräuchliche Versuche erreicht, kann er nicht mehr zum Erstellen von Sitzungen verwendet werden. Generieren Sie eine zufällige GUID-Zeichenfolge, und ordnen Sie sie aufeinanderfolgenden Versuchen derselben einzelnen primären Kennung in Ihrem System zu. Die Auswahl des zuzuordnenden Bezeichners oder Bezeichners hängt von den Anwendungsanforderungen und anderen Parametern ab, die zum Bewerten des Zugriffsrisikos verwendet werden. Um bei Bedarf die erneute Generierung einer neuen zufälligen GUID zu ermöglichen, vermeiden Sie die Verwendung des primären Bezeichners Ihrer Anwendung.
• Gestaltung des Systems zur Unterstützung des menschlichen Urteilsvermögens: Wenn eine Gerätekorrelations-ID gekennzeichnet ist und keine weiteren Sitzungen mit dem Bezeichner erstellt werden können, implementieren Sie einen sinnvollen Prozess zur menschlichen Überprüfung, um sicherzustellen, dass Fehler nicht auf missbräuchlichen Datenverkehr oder Brute-Force-Angriffsversuche zurückzuführen sind. Wenn Sie nach der Überprüfung weitere Versuche derselben Entität zulassen möchten, weil frühere Fehler als legitim erachtet werden, setzen Sie die Zuordnung zurück, indem Sie eine neue zufällige GUID generieren, die dem einzelnen Bezeichner zugeordnet ist.

Azure-Support für die Überwachung von Missbrauch

Azure bietet mehrere Mechanismen zum Überwachen von Liveness-Erkennungssitzungen und zur Minderung von Missbrauch:

• Datenverkehrsüberwachung: Beobachtet Aktivitäten über mehrere Sitzungen hinweg, wenn sie vom Entwickler mit unterschiedlichen Korrelations-IDs bezeichnet werden, und löst Warnungen aus, wenn verdächtige Muster erkannt werden.
• Überwachung über API: Bietet API-Funktionen zum Überwachen und Herunterladen von Livenessbildern, wenn die Sitzung aktiv ist.
• Umfassende Protokollierung: Verwaltet detaillierte Protokolle, um Abstreitungsangriffe zu verhindern.

Melden von Missbrauch

Wenn die Gesichtserkennungs-API von Azure KI ein Instrument für Präsentationsangriffe nicht erkennt, das Ihrer Meinung nach als Spoofing erkannt werden sollte, erstellen Sie eine Azure-Supportanfrage.

Die Supportanfrage sollte Folgendes enthalten:

• Art des präsentierten Spoofing-Materials.
• Vom Dienst als Teil des API-Aufrufs zurückgegebene Dienstinformationen. Die Informationen müssen mindestens Folgendes enthalten: API-Pfad, Anforderungs-ID (apim-request-id), Sitzungs-ID (SID) und API-Modellversion (model-version).
• Spezifische Bedingungen, die zum Reproduzieren des Angriffs erforderlich sind.
• Schrittweise Anweisungen zum Reproduzieren des Angriffs.
• Exploit-Bild oder Proof-of-Concept-Bild (falls möglich).
• Beschreibung der geschäftlichen Auswirkungen des Angriffs.

Sie können versuchen, den Angriff zu reproduzieren, bevor Sie ihn an Microsoft melden. Die Schritte zur Reproduzierung sind besonders nützlich, wenn Sie kein Exploit-Bild bereitstellen können.

Nächster Schritt

Tutorial: Erkennen von Face Liveness