2019-09-10

Juli 2019

Band 34, Nummer 7

[ASP.NET Core 3.0]

Einschränken des Zugangs zum Standort mit KI-gesteuerten Autorisierungsrichtlinien in ASP.NET Core

ASP.NET Core führt einen Anspruchsautorisierungsmechanismus ein, der benutzerdefinierte Richtlinien akzeptiert, um den Zugriff auf Anwendungen oder Teile einer Anwendung abhängig von bestimmten Berechtigungsattributen des authentifizierten Benutzers zu beschränken. In meinem vorherigen Artikel „KI-gestützte biometrische Sicherheit in ASP.NET Core“ in der Ausgabe des MSDN Magazine aus Juni 2019 (msdn.com/magazine/mt833460) habe ich ein richtlinienbasiertes Modell zur Entkopplung der Autorisierungslogik von den zugrunde liegenden Benutzerrollen vorgestellt und eine spezifische Verwendung solcher Autorisierungsrichtlinien zur Beschränkung des physischen Zugangs zu Gebäuden gezeigt, wenn ein unbefugtes Eindringen erkannt wird. In diesem zweiten Artikel werde ich mich auf die Konnektivität von Sicherheitskameras und das Streaming von Daten zu einem Azure IoT Hub konzentrieren, den Autorisierungsdatenfluss auslösen und den Schweregrad eines potenziellen Eindringens mit einem in Azure Machine Learning integrierten Anomalieerkennungsdienst bewerten.

Weitere Informationen zum ASP. NET Core-Autorisierungsframework finden Sie unter bit.ly/2VN9Hmo. Den Quellcode meiner Web-API finden Sie unter bit.ly/2IXPZCo.

Einschränken des Zugangs

In meinem Szenario wird der Zutritt zu Gebäuden durch Autorisierungsrichtlinien gesteuert, die erfüllt sein müssen, bevor die Türen entriegelt werden. ASP.NET Core 3 bietet ein integriertes Framework für die Verwaltung von Autorisierungsrichtlinien, das ich in dieser Lösung nutze und über eine Web-API bereitstelle. Vor diesem Hintergrund beschreibt Abbildung 1 ein Szenario, in dem eine Person durch Durchziehen eines Zutrittsausweises durch einen Kartenleser den Zutritt zu einem Gebäude anfordert, und Kameras Bewegungen erkennen und Gesicht, Körper und Stimme der Person erfassen. Der Kartenleser und die Kameras werden als IoT-Geräte registriert und übertragen die aufgezeichneten Daten an Azure IoT Hub.

Abbildung 1: Der Autorisierungsdatenfluss

In meinem vorigen Artikel habe ich die Verwendung von benutzerdefinierten Autorisierungsrichtlinien in der ASP.NET Core-Web-API zur Überprüfung auf bestimmte Ansprüche des Benutzers beschrieben, die dieser besitzt. Diese Ansprüche werden als biometrische Informationen für Gesicht, Körper und Stimme ausgewertet und mithilfe von Azure Cognitive Services für Bild-und Spracherkennung rechtzeitig erkannt.

Ich beschreibe nun den Prozess der Registrierung von Kameras als IoT-Geräte in Azure IoT Hub sowie die Definition von Regeln, die den Autorisierungsdatenfluss auslösen.

Registrieren von IoT-Geräten

Grundsätzlich können IoT-Anwendungen als Dinge (Geräte) bezeichnet werden, die Daten senden, die Erkenntnisse generieren. Die Erkenntnisse wiederum generieren Maßnahmen zur Verbesserung eines Unternehmens oder Prozesses. In meiner Anwendung ist ein Beispiel die Kamera (das IoT-Gerät), die Bild- und Sprachdaten sendet. Diese Daten werden verwendet, um zu beurteilen, ob die Person diejenige ist, für die sie sich ausgibt (die Erkenntnis). Die Erkenntnis wird verwendet, um die Person zu authentifizieren und ihr Zugang zum Standort (die Aktion) zu gewähren. Der Referenzarchitekturentwurf für diese Lösung in Abbildung 2 ähnelt der empfohlenen Azure IoT-Architektur (bit.ly/2I20Us2), die zwei Möglichkeiten zur Verarbeitung von Telemetriedaten beschreibt: warmer Pfad oder kalter Pfad. Der Unterschied liegt in den Anforderungen an die Latenzzeit und den Datenzugriff. Der warme Pfad analysiert Daten, sobald sie eingehen, in nahezu Echtzeit und mit sehr geringer Latenz. Dies ist der Fall, wenn es darum geht, mit Azure Cognitive Services Bild- und Spracherkennung auszulösen und dann den Benutzerzugang zu autorisieren. Der kalte Pfad erfasst historische Telemetriedaten zur Weiterverarbeitung, in der Regel zur Datenanalyse oder (wie in dieser Lösung) für Machine Learning (ML).

Abbildung 2: Azure IoT-Referenzarchitektur

Das Cloudgateway, in das die registrierten Geräte Daten streamen, ist Azure IoT Hub, ein verwalteter Dienst, der in der Cloud gehostet wird und als zentraler Nachrichtenhub für die bidirektionale Kommunikation zwischen den von ihm verwalteten Geräten und dem Autorisierungsanwendungs-Back-End dient. Der IoT-Hub unterstützt die Kommunikation sowohl vom Gerät in die Cloud als auch aus der Cloud mit dem Gerät. Er unterstützt auch mehrere Messagingmuster, z.B. Gerät-zu-Cloud-Telemetrie, Dateiupload von Geräten, Anforderung-Antwort-Methoden zur Steuerung Ihrer Geräte aus der Cloud und Direktmethoden, die Cloud-zu-Gerät-Befehle sind, die keine Antwort vom Gerät erfordern.

Ein Gerät muss bei Ihrem IoT-Hub registriert werden, bevor es eine Verbindung herstellen kann. Einer der manuellen Prozesse (es gibt viele!) für die Registrierung von Geräten ist die Verwendung von Azure Cloud Shell. Zuerst erstellen Sie die Geräteidentität mit dem folgenden Befehl:

az iot hub device-identity create --hub-name YourIoTHubName
    --device-id MyDotnetDevice

Ihr IoTHubName ist der Name des IoT-Hubs des Abonnenten in Azure (unter bit.ly/2JEMnph finden Sie eine detaillierte Beschreibung, wie Sie einen IoT-Hub mit dem Azure-Portal erstellen können), und MyDotnetDevice ist der Name des Geräts, das Sie registrieren. Nach der Registrierung benötigen Sie die Verbindungszeichenfolge des Geräts zum Streamen von Daten. Führen Sie diesen Befehl zum Abrufen der Verbindungszeichenfolge des Geräts aus, das Sie soeben registriert haben:

az iot hub device-identity show-connection-string --hub-name YourIoTHubName
  --device-id MyDotnetDevice --output table

Notieren Sie sich die Geräteverbindungszeichenfolge, die ähnlich wie dieses Beispiel aussehen sollte:

HostName={YourIoTHubName}.azure-devices.net; DeviceId=MyNodeDevice;
  SharedAccessKey={YourSharedAccessKey}

Sie benötigen außerdem den mit Event Hubs kompatiblen Endpunkt, den mit Event Hubs kompatiblen Pfad und den Primärschlüssel aus Ihrer Zugriffsrichtlinie, damit die Back-End-Anwendung eine Verbindung mit Ihrem IoT-Hub herstellen und die Nachrichten abrufen kann. Obwohl der IoT-Hub über eine vordefinierte „iothubowner“-Zugriffsrichtlinie verfügt, durch die er vollständige Kontrolle über den Hub besitzt, wird empfohlen, eine Richtlinie mit weniger Berechtigungen für die Geräteverbindung zu erstellen. Die folgenden Befehle rufen diese Werte für Ihren IoT-Hub ab:

az iot hub show --query properties.eventHubEndpoints.events.endpoint
  --name YourIoTHubName
az iot hub show --query properties.eventHubEndpoints.events.path
  --name YourIoTHubName
az iot hub policy show --name YourAccessPolicy --query primaryKey
  --hub-name YourIoTHubName

Sie können ein Gerät bei einem IoT-Hub auch mithilfe des Azure IoT Hub-Bereitstellungsdienstclients in .NET registrieren. Als Voraussetzung benötigen Sie das Microsoft.Azure.Devices.Provisioning.Service-Paket, das Sie in Ihrer Visual Studio-Projektmappe von NuGet installieren können.

Die Methode DeviceRegistrationAsync in Abbildung 3 registriert ein auf TPM (Trusted Platform Module) basierendes Gerät unter Verwendung des Endorsement Key des Geräts, der dauerhaft in die Hardware eingebettet wird (im Allgemeinen zum Zeitpunkt der Herstellung). Außerdem ist eine Registrierungs-ID erforderlich, die zur eindeutigen Identifizierung eines Geräts verwendet wird. Diese kann mit der Geräte-ID identisch sein, muss es aber nicht. Für TPM-basierte Geräten kann die Registrierungs-ID vom TMP selbst abgeleitet werden, z.B. ein SHA-256-Hash des TPM Endorsement Key.

Abbildung 3: Die DeviceRegistrationAsync-Methode

using Microsoft.Azure.Devices.Provisioning.Service;
static async Task DeviceRegistrationAsync()
{
  Attestation attestation = new TpmAttestation("<TpmEndorsementKey>");
  IndividualEnrollment enrollment = new IndividualEnrollment(
    "<RegistrationId>", attestation)
  {
    DeviceId = "DeviceId"
  };
  var serviceClient = ProvisioningServiceClient.CreateFromConnectionString(
    "<ConnectionString>");
  IndividualEnrollment enrollmentResult = await
    serviceClient.CreateOrUpdateIndividualEnrollmentAsync(enrollment)
      .ConfigureAwait(false);
}

Die Abfrage von enrollmentResult.RegistrationState gibt den Registrierungsstatus des Geräts an.

Streamen von Daten an den IoT-Hub

Sobald ein Gerät erfolgreich registriert wurde, kann es damit beginnen, Daten an den IoT-Hub zu streamen. Der IoT-Hub unterstützt die Protokolle HTTPS und AMQP (Advanced Message Queuing Protocol) für die Datenerfassung und ist formatunabhängig, was bedeutet, dass das Datenformat beliebig sein kann, von CS über JSON bis hin zu Avro (ein Apache Daten-Serialisierungsprojekt: avro.apache.org). Wenn Sie eine Verbindung mit Geräten von Remotestandorten entwerfen, bei denen ein kleiner Codefußabdruck erforderlich oder die Netzwerkbandbreite begrenzt ist, sollten Sie Message Queuing Telemetry Transport (MQTT: mqtt.org) in Betracht ziehen, ein schlankes Messagingprotokoll für kleine Sensoren und mobile Geräte, das für hochlatente oder unzuverlässige Netzwerke optimiert ist. Es gibt jedoch ein Limit von 256 KB in einer Gerät-zu-Cloud-Nachricht, wodurch das direkte Datenstreaming für die Erfassung von Bild- und Sprachdaten unpraktisch wird. Ein weiterer Ansatz zum Laden von Daten, den der IoT-Hub unterstützt, ist der Dateiupload in Blobspeicher. Eine Kamera zeichnet zunächst Audio und Video am Edge (also auf dem Gerät selbst) auf und lädt diese Daten dann in den IoT-Hub hoch. Wenn der Upload abgeschlossen ist, löst der IoT-Hub eine Benachrichtigung zum Dateiupload über einen dienstorientierten Endpunkt aus. Dieses Ereignis löst dann den Autorisierungsprozess aus, der schließlich die Web-API mit den ASP.NET Core-Autorisierungsrichtlinien aufruft. Es ist wichtig zu beachten, dass der Dateiuploadmechanismus ein Azure Blob-Speicherkonto erfordert. Nachrichten werden nicht über den IoT-Hub selbst vermittelt. Stattdessen fungiert der IoT-Hub als Verteiler für ein zugeordnetes Speicherkonto. Daher ist es natürlich wichtig, das Speicherkonto in Azure zu konfigurieren und es Ihrem IoT-Hub zuzuordnen. Ausführliche Anweisungen dazu finden Sie unter bit.ly/2YOMz8Q.

Um einen Dateiuploadprozess zu initialisieren, sendet ein Gerät eine POST-Anforderung im folgenden Format an einen Endpunkt auf dem IoT-Hub:

{iot hub}.azure-devices.net/devices/{deviceId}/files

Die POST-Anforderung enthält diesen JSON-Text:

{
  "blobName": "..."
}

Der IoT-Hub gibt eine JSON-Antwort zurück, die das Gerät zum Hochladen der Datei verwendet:

{
  "correlationId": "<correlation_id>",
  "hostName": "<yourstorageaccount>.blob.core.windows.net",
  "containerName": "<container_name>",
  "blobName": "<blob_name>",
  "sasToken": "<token>"
}

Wenn der Upload abgeschlossen ist, sendet das Gerät eine POST-Anforderung an:

{iot hub}.azure-devices.net/devices/{deviceId}/files/notifications

Diese enthält den folgenden JSON-Text:

{
  "correlationId": "<correlation ID received from the initial request>",
  "isSuccess": bool,
  "statusCode": XXX,
  "statusDescription": "Description of status"
}

Wenn Sie C# bevorzugen, können Sie eine Datei hochladen, indem Sie einen Geräteclient aus der Geräteverbindungszeichenfolge einrichten und die Datei asynchron als Stream an das Blob senden:

async void SendToBlobAsync(string blobName, Stream stream)
{
  using (DeviceClient deviceClient =
    DeviceClient.CreateFromConnectionString(
      "<ConnectionString>", TransportType.Http1))
  {
    await deviceClient.UploadToBlobAsync(blobName, stream);
  }
}

Eindringversuchserkennung

Alle bisher beschriebenen datenbezogenen Aktivitäten finden im sogenannten „Speicher des warmen Pfads“ statt, da die Datenverarbeitung in nahezu Echtzeit erfolgt. Telemetriedaten werden auch in Azure Blob Storage zur weiteren Analyse dauerhaft archiviert. Dies ist der „Speicher des kalten Pfads“, der als Datenquelle für das Trainieren eines Datenmodells und zum Erkennen von unbefugten Eindringversuchen von Azure Machine Learning Studio verwendet wird.

Bei einem Konflikt zwischen der erkannten Identität einer Person und ihrem Zugangsausweis wird der Zugang zum Standort sofort gesperrt. Andernfalls wird der Zugangsdatenfluss fortgesetzt, indem überprüft wird, ob eine der folgenden Anomalien aufgetreten ist:

Atypische Häufigkeit des Zugangs zum Gebäude.
Ob die Person das Gebäude zuvor verlassen hat (Checkout).
Anzahl der erlaubten Zutritte pro Tag.
Ob die Person im Dienst ist.
Relevanz des Gebäudes (Sie möchten den Zugang zu einer Kantine möglicherweise nicht einschränken, aber eine strengere Richtlinie für den Zugang zu einem Serverdatencenter durchsetzen).
Ob die Person jemanden oder etwas mitbringt.
Frühere Vorkommen ähnlicher Zugangstypologien für das gleiche Gebäude.
In der Vergangenheit gemessene Risikostufenänderungen.
Anzahl der in der Vergangenheit erkannten Eindringversuche.

Der Anomalieerkennungsdienst wird in Azure ML ausgeführt und gibt eine Bewertung zurück, ausgedrückt als Wahrscheinlichkeit, dass der Zutritt eine Abweichung vom Standard ist. Die Bewertung wird in einem Bereich zwischen Null und Eins ausgedrückt, wobei Null „kein Risiko erkannt“ bedeutet (alles OK, volle Vertrauenswürdigkeit), und Eins „roten Alarm“ auslöst, bei dem der Zugang sofort blockiert wird! Die Risikostufe jedes Gebäudes bestimmt den Schwellenwert, der als akzeptabel erachtet wird, um den Zugang zum Gebäude für jeden Wert größer als Null zu ermöglichen.

Die Eindringungserkennung ist ein Problem der Anomalieerkennung, das seltene oder ungewöhnliche Vorkommen von Datenpunkten in einem Cluster identifiziert und vorhersagt. Die ML-Anomalieerkennung wurde allgemein zur Erkennung eines potenziellen Zahlungsbetrugs, zur Erfassung anormaler Gerätewerte, zur Erkennung von Netzwerkeinbrüchen sowie für jede Anwendung eingesetzt, bei der es notwendig ist, ein großes Dataset von unvorhersehbaren Aktivitäten oder Elementen zu untersuchen.

So kann beispielsweise der Zugang zu Standorten im Laufe der Zeit registriert und nach verschiedenen Kriterien gruppiert werden (Tageszeit, Rolle einer Person, ob allein oder in Begleitung, früherer Zugang usw.). Diese Kriterien werden „Merkmale“ genannt und identifizieren alle Bedingungen, die der ML-Algorithmus überprüft, um den Eindringungswert zu bewerten, einschließlich der Frage, ob es sich um einen neuen Zugang handelt und ob ein Datenpunkt innerhalb der durchschnittlichen aufgezeichneten Werte (im Cluster) oder außerhalb liegt. Befindet sich der Datenpunkt außerhalb, wird auch sein Abstand zum Rand (Abweichung) gemessen, um einen niedrigeren oder höheren Risikofaktor als Zahl zwischen Null und Eins anzugeben (siehe Abbildung 4).

Abbildung 4: Anormale Eindringungsdarstellung

Es kann Hunderte von Merkmalen geben, und jedes trägt in unterschiedlichem Maß zur Eindringungswahrscheinlichkeit bei. Der Grad, in dem jedes Merkmal zum Eindringungswert beiträgt, wird nicht von einer Person (z.B. dem Sicherheitsbeauftragten) bestimmt, sondern vom ML-Prozess als Teil des Modelltrainings abgeleitet. Was also den unbefugten Zutritt zu einem Gebäude betrifft, so wird die Gewichtung einer solchen Typologie des Eindringens ebenso hoch sein, wenn die Verwendung des Zutrittsausweise einer anderen Person nachgewiesen wird, um Zugang zu einem Gebäude zu erhalten. Und wenn dieser Vorgehensweise nachlässt, würde das Beitragsniveau parallel dazu sinken. Einfach ausgedrückt: Diese Modelle lernen selbst ohne explizite Programmierung, z.B. mit einer manuellen Überprüfung.

Der Vorgang der Analyse von Daten zur Extrapolation einer Bedeutung wird als Feature Engineering bezeichnet. Im Bereich der Anomalieerkennung möchten Sie sich in der Regel Folgendes ansehen:

Aggregierte Variablen: die Gesamtzahl der Transaktionen pro Standort in den letzten 24 Stunden, sieben Tagen oder 30 Tagen. Beispiel:
Diskrepanzwerte: Jede Diskrepanz zwischen den biometrischen Informationen des Benutzers und dem Zutrittsausweis oder die Erkennung der Anwesenheit von Personen an mehreren Orten gleichzeitig oder mit zu kurzer Zeitdifferenz zwischen zwei sehr weit voneinander entfernten Orten.
Risikotabellen: Eindringungsrisiken, die anhand der historischen Wahrscheinlichkeit berechnet werden, gruppiert nach Standort, Zugangsbeschränkung zu einem Gebäude usw.

Azure Machine Learning Studio

Azure ML Studio bietet einen visuellen Editor, mit dem ML-Experimente ausgehend von einem Dataset erstellt und dann Modelltraining, Bewertung und Auswertung durchgeführt werden können. Aber schön der Reihe nach. Abbildung 5 zeigt den gesamten ML-Datenfluss.

Abbildung 5: Experiment zur Eindringversuchserkennung am Standort in Azure Machine Learning Studio

Der erste Schritt importiert das Dataset. Da die Daten in einem Azure-Blob gespeichert sind, stellt Azure ML Studio ein spezifisches Modul namens „Daten importieren“ zur Verfügung, das Sie für die Verbindung mit einem Azure Blob-Dienst verwenden können. Nach dem Importieren der Daten müssen Sie diese mithilfe des Moduls „Daten aufteilen“ in Trainings- und Testdatensätze trennen. Je nachdem, welche Art von Daten Sie haben und wie Sie sie aufteilen möchten, können Sie verschiedene Aufteilungsmodi auswählen. Für diese Lösung habe ich die Option „Zeilen aufteilen“ ausgewählt, um die Daten in zwei zufällige Teile zu unterteilen, wobei 80 Prozent der Daten dem Trainingsdatensatz zugeordnet sind und der Rest zum Testen verwendet werden soll. Der ML-Datenfluss führt dann ein Training des Datasets aus. Die Anomalieerkennung ist ein Klassifizierungsproblem, das als beaufsichtigtes oder unbeaufsichtigtes Lernen mit einem der folgenden Ansätze durchgeführt werden kann:

Einklassiges Support Vector-Modell
Hauptkomponentenanalyse

Sie können das Modul „Einklassiges Support Vector-Modell“ verwenden, um ein Anomalieerkennungsmodell zu erstellen, das besonders nützlich in Szenarien ist, in denen die Daten meist „normale“ Daten sind, ohne viele Fälle der Anomalien, die Sie zu erkennen versuchen. Möglicherweise müssen Sie z.B. betrügerische Zutritte erkennen, haben aber nicht viele Beispiele für Betrug, die Sie verwenden können, um ein typisches Klassifizierungsmodell zu trainieren. Aber Ihnen liegen viele Beispiele für autorisierte Fälle vor.

Die Hauptkomponentenanalyse, die häufig als PCA (Principal Component Analysis) abgekürzt wird, ist im Gegensatz dazu eine etablierte ML-Technik, die auf die explorative Datenanalyse angewendet werden kann, wenn das Quelldataset nicht gut bekannt ist. Die PCA enthüllt die innere Struktur der Daten und erklärt die Varianz in den Daten durch die Analyse mehrerer Variablen und die mögliche Korrelation und Kombination von Werten, die die Unterschiede in den Ergebnissen am besten erfassen. Diese Werte werden als „Hauptkomponenten“ bezeichnet, da sie die Schlüsselfaktoren sind, die das Ergebnis beeinflussen.

Da ich zum jetzigen Zeitpunkt nicht voraussehen kann, welcher Ansatz besser funktioniert, werde ich beide Ansätze mit zwei separaten Modulen des Modells „Anomalieerkennung trainieren“ verwenden und dann die wechselseitigen Ergebnisse mit einer Auswertung der vorhergesagten Werte vergleichen. Das Modul „Modell bewerten“ bewertet Vorhersagen für ein trainiertes Modell, und das Modul „Modell auswerten“ wertet (wie der Name schon sagt) die Ergebnisse des Klassifikationsmodells mit Standardmetriken aus, z.B. Genauigkeit (Güte eines Klassifikationsmodells als Verhältnis der wahren Ergebnisse zu den Gesamtfällen), Genauigkeit (Verhältnis der wahren Ergebnisse zu allen positiven Ergebnissen) und Wiederholgenauigkeit (Anteil aller richtigen Ergebnisse, die vom Modell zurückgegeben werden). Das bewertete Dataset mit den höheren Metriken wäre das bevorzugte Dataset für die Generierung des Vorhersagediensts, der diesem Trainingsexperiment zugeordnet ist.

Azure ML Studio generiert einen Webdienst aus einem Vorhersageexperiment und stellt diesen als REST-API bereit, die externe Anwendungen nutzen können. Die API verfügt über einen Endpunkt, der auf der services.azureml.net-Domäne gehostet wird, die für Ihren Dienst eindeutig ist. Sie erfordert die Authentifizierung mit einem API-Schlüssel, der im HTTP-Anforderungsheader als Authorization: Bearer-Eigenschaft übergeben wird. Der Inhaltstyp der Anforderung ist „application/json“, und Anforderungstext geht vom Format einer JSON-Nutzlast aus, die die Eingabewerte für den Vorhersagedienst enthält. Die Ausgabe des Diensts ist ebenfalls eine JSON-Antwort mit dem bewerteten Wert. Der C#-Code in Abbildung 6 zeigt, wie der ML-Dienst mit einem HTTP-Client genutzt wird. Nachdem die Anforderung als Sammlung von Zeichenfolgenarrays erstellt wurde, wird der HTTP-Client mit dem API-Schlüssel in der authorization-Eigenschaft des Anforderungsheaders initialisiert, und seine Basisadresse wird auf den URI des Webdiensts festgelegt. Die Anforderung wird asynchron durch POST als JSON-Nachricht übermittelt.

Abbildung 6: Aufrufen des Azure ML-Webdiensts

async Task InstrusionDetectionAsync()
{
  using (var client = new HttpClient())
  {
    var scoreRequest = new
    {
      Inputs = new Dictionary<string, StringTable>
      {
        ["input1"] = new StringTable
        {
          ColumnNames = new [] { "<Feature1>", "<Feature2>", "<Feature3>" },
          Values = new [,] { { "<Value1>", "<Value2>", "<Value3>" } }
        }
      }
    };
    client.DefaultRequestHeaders.Authorization =
      new AuthenticationHeaderValue("Bearer", "<ApiKey>");
    client.BaseAddress = new Uri("<EndpointURI>");
    HttpResponseMessage response = await client.PostAsJsonAsync("", scoreRequest);
    if (response.IsSuccessStatusCode)
    {
      string result = await response.Content.ReadAsStringAsync();
    }
  }
}
public class StringTable
{
  public string[] ColumnNames { get; set; }
  public string[,] Values { get; set; }
}

Zusammenfassung

Die Azure-Cloud bietet ein reichhaltiges Toolset an Ressourcen, die in der richtigen Kombination helfen, End-to-End-Lösungen zu entwickeln, die IoT, Machine Learning, Cognitive Services und die ASP.NET Core-API integrieren. Das im vorherigen Artikel dieser zweiteiligen Serie veranschaulichte Szenario zeigt die Vielfalt des benutzerdefinierten Richtlinienframeworks in .NET Core für die Benutzerautorisierung in Synergie mit den Bild- und Sprache-APIs von Cognitive Services zur Erkennung biometrischer Merkmale wie Gesicht und Stimme. Der aktuelle Artikel konzentriert sich auf die Erfassung solcher biometrischen Informationen von Kameras, die als IoT-Geräte registriert sind, und das Streamen von Daten zu einem IoT-Hub in Azure. Die Lösung wird durch einen ML-Dienst bereichert, der den Autorisierungsprozess mit der Analyse der Zugangsanforderung anhand eines historischen Datasets unterstützt, um einen möglichen unbefugten Zutritt zu erkennen.

Stefano Tempestaist Microsoft Regional Director, MVP für AI and Business Applications und Mitglied des Blockchain Councils. Tempesta ist regelmäßiger Referent auf internationalen IT-Konferenzen, darunter Microsoft Ignite and Tech Summit, und interessiert sich für blockchain- und KI-bezogene Technologien. Er hat Blogchain Space (blogchain.space) ins Leben gerufen, einen Blog über Blockchaintechnologien, schreibt für MSDN Magazine und MS Dynamics World und veröffentlicht Machine Learning-Experimente im Azure KI-Katalog (gallery.azure.ai).

Unser Dank gilt dem folgenden technischen Experten bei Microsoft für die Durchsicht dieses Artikels: Danilo Diaz

Diesen Artikel im MSDN Magazine-Forum diskutieren

Freigeben über