Giugno 2019

Volume 34 Numero 6

Il presente articolo è stato tradotto automaticamente.

[ASP.NET Core 3.0]

Sicurezza biometrica basata su intelligenza artificiale in ASP.NET Core

Dal Stefano Tempesta

Questo articolo, in due parti, introduce il modello di autorizzazione basata su criteri in ASP.NET Core 3, che ha lo scopo di separare la logica di autorizzazione dai ruoli utente sottostante. Presenta un esempio specifico su questo processo di autorizzazione basato sulle informazioni biometriche, ad esempio il riconoscimento volto o chiamata vocale. In questo caso, l'accesso a una compilazione è limitato quando viene rilevato un tentativo di intrusione non autorizzata. La gravità di intrusione di valutazione viene eseguita da un servizio di rilevamento anomalie incorporato in Azure Machine Learning.

Accesso al sito

Il contesto è un sito estremamente protetto, si tratta di un'area di quelli militare, o un ospedale o un Data Center. L'accesso è limitato a persone autorizzate, con alcune limitazioni. I passaggi seguenti descrivono il flusso di sicurezza applicato all'ingresso di ogni compilazione per controllare le persone:

1. Una persona che richiede l'accesso a una compilazione di tessere magnetiche passare loro accesso lettore della porta.
2. Rilevare i movimenti di fotocamere e acquisiscono il viso e il corpo della persona; Ciò deve impedire l'uso di una stampata foto, ad esempio, a ingannare della fotocamera con riconoscimento del viso-only.
3. Il lettore di smart card e fotocamere vengono registrate come dispositivi Internet delle cose (IoT) e streaming di dati registrati all'IoT Hub di Azure.
4. Servizi cognitivi Microsoft mette a confronto la persona in un database di utenti autorizzati ad accedere la compilazione.
5. Un flusso di autorizzazione corrisponde alle informazioni biometriche raccolte dai dispositivi IoT con l'identità della persona al passaggio di accesso.
6. Per valutare il livello di rischio della richiesta di accesso, viene richiamato un servizio di Azure Machine Learning e se si tratta di un'intrusione non autorizzata.
7. Autorizzazione viene concessa per un'API Web ASP.NET Core tramite il controllo dei requisiti del criterio specifico di proprietà per il profilo definito nei passaggi precedenti.

Se si verifica una mancata corrispondenza tra l'identità della persona rilevato e il passaggio di accesso, l'accesso al sito viene bloccato immediatamente. In caso contrario, il flusso procede controllando se sono stato rilevato uno qualsiasi delle anomalie seguenti:

• Atipica frequenza di accesso per la compilazione.
• Indica se la persona che è stato terminato la compilazione in precedenza (check-out).
• È consentito un numero di accessi al giorno.
• Indica se l'utente è in servizio.
• Criticità dell'edificio (è non possibile limitare l'accesso a un mensa, ma applicare i criteri più severi per l'accesso a un Data Center server).
• Indica se la persona assolutamente innovativo, un utente o qualcos'altro insieme.
• Ultimi relative occorrenze simili accedere typologies a stesso edificio.
• Modifiche a livello di rischio è misurato in precedenza.
• Numero di intrusioni rilevati in passato.

Il servizio di rilevamento anomalie viene eseguito in Azure Machine Learning e restituisce un punteggio, espresso come una probabilità che l'accesso è una deviazione dallo standard, o No. Il punteggio è espressa in un intervallo compreso tra 0 e 1, dove zero non è "non è rilevato alcun rischio", tutti i trust valido e completo concesse; e uno è immediatamente "avviso rosso," Blocca l'accesso. Il livello di rischio di ogni edificio determina la soglia che viene considerata accettabile per consentire l'accesso per la compilazione per qualsiasi valore maggiore di zero.

Autorizzazione in ASP.NET Core

ASP.NET Core fornisce un ruolo dichiarativo autorizzazione semplice e un modello dettagliato basato su criteri. Autorizzazione viene espresso in requisiti e i gestori di valutare le attestazioni dell'utente su tali requisiti. Ai fini di autorizzazione degli utenti per accedere a un sito, descriverò come generare i requisiti dei criteri personalizzati e relativo gestore di autorizzazione. Per altre informazioni sul modello di autorizzazione in ASP.NET Core, consultare la documentazione all'indirizzo bit.ly/2UYZaJh.

Come indicato, un meccanismo di autorizzazione personalizzata basata su criteri è costituito da requisiti e (in genere) un gestore di autorizzazione. Concedere l'accesso a un edificio costituito da richiamare un'API che sblocca lo sportello della voce. Dispositivi IoT trasmettere informazioni biometriche a un IoT Hub di Azure, che a sua volta attiva il flusso di lavoro verifica inviando l'ID del sito, un identificatore univoco del sito. Il metodo POST di API Web restituisce semplicemente un codice HTTP 200 e un messaggio JSON con l'ID sito e nome utente se l'autorizzazione ha esito positivo. In caso contrario, genera il codice di errore HTTP 401 non autorizzato accesso previsto. Ma torniamo nell'ordine: Inizia con la classe Startup dell'API Web, in particolare il metodo ConfigureServices, che contiene le istruzioni per configurare i servizi necessari per eseguire l'applicazione ASP.NET Core. I criteri di autorizzazione vengono aggiunti chiamando il metodo AddAuthorization sull'oggetto servizi. Il metodo AddAuthorization accetta una raccolta di criteri che deve possedere la funzione dell'API quando viene richiamato per autorizzare l'esecuzione. È necessario un solo criterio in questo caso, che viene chiamato "AuthorizedUser." Questo criterio, tuttavia, presenta diversi requisiti da soddisfare, che riflettono le caratteristiche biometriche di una persona a cui vuole verificare: viso, corpo e della voce. I tre requisiti vengono rappresentati ognuno da una specifica classe che implementa l'interfaccia di IAuthorizationRequirement, come illustrato nella figura 1. Quando si elencano i requisiti per il criterio AuthorizedUser, anche specificare il livello di confidenza necessario per soddisfare il requisito. Come ho accennato sopra, questo valore, compreso tra zero e uno, esprime l'accuratezza di identificazione del relativo attributo biometrico. Otterrà al seguente in un secondo momento quando si parla di riconoscimento biometrico con servizi cognitivi.

Figura 1 configurazione dei requisiti di autorizzazione nell'API Web

public void ConfigureServices(IServiceCollection services)
{
  var authorizationRequirements = new List<IAuthorizationRequirement>
  {
    new FaceRecognitionRequirement(confidence: 0.9),
    new BodyRecognitionRequirement(confidence: 0.9),
    new VoiceRecognitionRequirement(confidence: 0.9)
  };
  services
    .AddAuthorization(options =>
    {
      options.AddPolicy("AuthorizedUser", policy => policy.Requirements =
        authorizationRequirements);
    })

I criteri di autorizzazione AuthorizedUser contengono più i requisiti di autorizzazione e devono passare tutti i requisiti per la valutazione dei criteri abbia esito positivo. In altre parole, più i requisiti di autorizzazione aggiunti a un singolo criterio di autorizzazione vengono trattati in modo AND.

I requisiti dei criteri di tre che ho implementato nella soluzione sono tutte le classi che implementano l'interfaccia di IAuthorizationRequirement. Questa interfaccia è in realtà vuota. vale a dire non determina l'implementazione di qualsiasi metodo. I tre requisiti ho implementato in modo coerente, specificando una proprietà pubblica ConfidenceScore per acquisire il livello previsto di probabilità che l'API di riconoscimento deve soddisfare per prendere in considerazione questo requisito esito positivo. La classe FaceRecognitionRequirement simile alla seguente:

public class FaceRecognitionRequirement : IAuthorizationRequirement
{
  public double ConfidenceScore { get; }
  public FaceRecognitionRequirement(double confidence) =>
    ConfidenceScore = confidence;
}

Analogamente, gli altri requisiti per il riconoscimento vocale e corpo vengono implementati, rispettivamente, nelle classi BodyRecognitionRequirement e VoiceRecognitionRequirement.

L'autorizzazione a eseguire un'azione di API Web è controllata tramite l'attributo Authorize. Nella forma più semplice, l'applicazione AuthorizeAttribute a un controller o azione verrà limitato l'accesso a quel controller o azione da qualsiasi utente autenticato. L'API Web che controlla l'accesso a un sito espone un controller l'accesso single che contiene solo l'azione di Post. Questa azione è autorizzata se vengono soddisfatti tutti i requisiti del criterio di "AuthorizedUser" specificato:

[ApiController]
public class AccessController : ControllerBase
{
  [HttpPost]
  [Authorize(Policy = "AuthorizedUser")]
  public IActionResult Post([FromBody] string siteId)
  {
    var response = new
    {
      User = HttpContext.User.Identity.Name,
      SiteId = siteId
    };
    return new JsonResult(response);
  }
}

Gestito da un gestore di autorizzazione, come quella disponibile in ogni requisito figura 2, che è responsabile per la valutazione di un requisito dei criteri. È possibile scegliere di avere un singolo gestore per tutti i requisiti o gestori separati per ogni requisito. Questo secondo approccio è più flessibile perché consente di configurare una sfumatura di requisiti di autorizzazione che è possibile configurare facilmente nella classe Startup. I gestori di requisiti viso, corpo e della voce estendono la classe astratta AuthorizationHandler < TRequirement >, dove TRequirement è il requisito per essere gestiti. Poiché desidera valutare tre requisiti, è necessario scrivere un gestore personalizzato che estende AuthorizationHandler per FaceRecognitionRequirement, BodyRecognitionRequirement e VoiceRecognitionRequirement ogni. In particolare, il metodo di HandleRequirementAsync, che determina se è stato soddisfatto un requisito di autorizzazione. Questo metodo, perché è asincrona, non restituisce un valore reale, ad eccezione di to indicano che l'attività è stata completata. Gestione autorizzazione costituito da contrassegnare come "riuscito" un requisito richiamando il metodo hanno esito positivo nel contesto del gestore dell'autorizzazione. Questo è effettivamente verificato anche da un oggetto "riconoscimento", che usa l'API servizi cognitivi internamente (altre informazioni nella sezione successiva). L'azione di riconoscimento, eseguita dal metodo Recognize, ottiene il nome della persona identificato e restituisce un valore (punteggio) che esprime il livello di probabilità che l'identificazione è più (valore più vicino a uno) o meno (valore più vicino a zero) accurati. È stato specificato un livello previsto nel programma di installazione di API. È possibile ottimizzare questo valore su qualsiasi soglia è appropriato per la soluzione.

Figura 2, il gestore autorizzazioni personalizzato

public class FaceRequirementHandler :
  AuthorizationHandler<FaceRecognitionRequirement>
{
  protected override Task HandleRequirementAsync(
    AuthorizationHandlerContext context,
      FaceRecognitionRequirement requirement)
  {
    string siteId =
      (context.Resource as HttpContext).Request.Query["siteId"];
    IRecognition recognizer = new FaceRecognition();
    if (recognizer.Recognize(siteId, out string name) >=
      requirement.ConfidenceScore)
    {
      context.User.AddIdentity(new ClaimsIdentity(
        new GenericIdentity(name)));
      context.Succeed(requirement);
    }
    return Task.CompletedTask;
  }
}

Oltre a valutare i requisiti specifici, il gestore dell'autorizzazione aggiunge inoltre un'attestazione di identità per l'utente corrente. Quando viene creata un'identità, è possibile assegnare uno o più delle attestazioni rilasciate da un'entità attendibile. Un'attestazione è una coppia nome-valore che rappresenta l'oggetto è. In questo caso, sto assegnando l'attestazione di identità per l'utente nel contesto. Questa attestazione viene quindi recuperata nel post-azione del controller di accesso e restituita come parte della risposta dell'API.

L'ultimo passaggio da eseguire per abilitare questo processo di autorizzazione personalizzato è la registrazione del gestore all'interno dell'API Web. I gestori registrati dell'insieme di servizi durante la configurazione:

services.AddSingleton<IAuthorizationHandler, FaceRequirementHandler>();
services.AddSingleton<IAuthorizationHandler, BodyRequirementHandler>();
services.AddSingleton<IAuthorizationHandler, VoiceRequirementHandler>();

Questo codice registra ogni gestore requisito come un singleton usando il framework di inserimento di dipendenze predefinito in ASP.NET Core. Un'istanza del gestore verrà creata quando viene avviata l'applicazione e l'inserimento delle dipendenze verrà inserire la classe registrata nell'oggetto pertinente.

Identificazione viso

La soluzione Usa i servizi cognitivi di Azure per l'API visione artificiale per identificare visi e corpo di una persona. Per altre informazioni su servizi cognitivi e informazioni dettagliate sull'API, visita bit.ly/2sxsqry.

L'API visione artificiale fornisce verifica del viso e rilevamento attributo viso. Rilevamento viso si riferisce alla capacità di rilevare volti umani in un'immagine. L'API restituisce le coordinate del rettangolo della posizione del volto all'interno dell'immagine elaborato e, facoltativamente, consente di estrarre una serie di attributi relativi ai visi, ad esempio posa head, sesso, età, emozioni, viso selettore di precisione e bicchieri. Verifica del viso, al contrario, esegue l'autenticazione di un volto rilevato contro faccia già salvato di una persona. In pratica, valuta se due visi appartengano alla stessa persona. Questo è l'API specifica, usare questo progetto di protezione. Per iniziare, aggiungere il pacchetto NuGet seguente per la soluzione di Visual Studio: Microsoft.Azure.Cognitive­Services.Vision.Face 2.2.0-preview

Il pacchetto gestito .NET è disponibile in anteprima, assicurarsi di selezionare l'opzione "Includi versione preliminare" durante l'esplorazione di NuGet, come illustrato nella figura 3.

Figura 3 pacchetto NuGet per l'API viso

Usando il pacchetto di .NET, riconoscimento e rilevamento del viso sono semplici. Parlando in generale, riconoscimento facciale descrive le operazioni di confronto di due visi diversi per determinare se sono simili o appartenere alla stessa persona. Le operazioni di riconoscimento usano principalmente le strutture di dati racchiusi figura 4.

Figura 4 strutture di dati per l'API viso

L'operazione di verifica accetta un ID volto da un elenco di visi rilevati in un'immagine (raccolta DetectedFace) e determina se i visi appartengono alla stessa persona confrontandolo con l'ID per una raccolta di visi persistenti (PersistedFace). Persistente immagini viso che hanno un ID univoco e un nome di identificare una persona. Un gruppo di persone possibile, facoltativamente, raccolti in un gruppo di persone per migliorare le prestazioni di riconoscimento. In pratica, una persona è un'unità di base dell'identità e l'oggetto persona può avere uno o più visi noti registrati. Ogni persona è definito all'interno di un determinato gruppo di persone, ovvero una raccolta di utenti, e l'identificazione venga fatta rispetto a un gruppo di persone. Il sistema di sicurezza potrebbe creare uno o più oggetti di gruppo di persone e quindi associare gli utenti a esse. Dopo aver creato un gruppo, la raccolta gruppo di persone deve essere addestrata per poter eseguire un'identificazione di utilizzarlo. Inoltre, è possibile ripetere il training dopo l'aggiunta o rimozione di qualsiasi persona, o se qualsiasi persona che ha i volti registrato modificato. I corsi di formazione avviene tramite l'API di eseguire il training del gruppo di persone. Quando si usa la libreria client, si tratta semplicemente una chiamata al metodo TrainPersonGroupAsync:

await faceServiceClient.TrainPersonGroupAsync(personGroupId);

Il training è un processo asincrono. Può essere completata non ancora una volta completato il metodo TrainPersonGroupAsync. Si potrebbe essere necessario richiedere lo stato di formazione con il metodo GetPersonGroupTrainingStatusAsync fino a quando non è pronto prima di addentrarsi con rilevamento viso o verifica.

Quando si esegue una verifica del viso, l'API viso calcola la similarità di un volto rilevato tra tutti i volti all'interno di un gruppo e restituisce le persone più simili per tale viso test. Questa operazione viene eseguita tramite il metodo IdentifyAsync della libreria del client. Il quadrante di test deve essere rilevato tramite i passaggi indicati in precedenza e il face ID viene quindi passato all'API di identificare come secondo argomento. ID dei volti più può essere identificata in una sola volta e il risultato conterrà tutti i risultati di identità. Per impostazione predefinita, identificare restituisce solo una persona che corrisponde meglio la faccia di test. Se si preferisce, è possibile specificare il parametro facoltativo maxNumOfCandidatesReturned per consentire di identificare restituire altri candidati. Il codice nel figura 5 illustra il processo di identificazione e verifica per determinare se un volto:

Figura 5, il processo di riconoscimento del viso

public class FaceRecognition : IRecognition
{
  public double Recognize(string siteId, out string name)
  {
    FaceClient faceClient = new FaceClient(
      new ApiKeyServiceClientCredentials("<Subscription Key>"))
    {
      Endpoint = "<API Endpoint>"
    };
    ReadImageStream(siteId, out Stream imageStream);
    // Detect faces in the image
    IList<DetectedFace> detectedFaces =
      faceClient.Face.DetectWithStreamAsync(imageStream).Result;
    // Too many faces detected
    if (detectedFaces.Count > 1)
    {
      name = string.Empty;
      return 0;
    }
    IList<Guid> faceIds = detectedFaces.Select(f => f.FaceId.Value).ToList();
    // Identify faces
    IList<IdentifyResult> identifiedFaces =
      faceClient.Face.IdentifyAsync(faceIds, "<Person Group ID>").Result;
    // No faces identified
    if (identifiedFaces.Count == 0)
    {
      name = string.Empty;
      return 0;
    }
    // Get the first candidate (candidates are ranked by confidence)
    IdentifyCandidate candidate =
      identifiedFaces.Single().Candidates.FirstOrDefault();
    // Find the person
    Person person =
      faceClient.PersonGroupPerson.GetAsync("", candidate.PersonId).Result;
    name = person.Name;
    return candidate.Confidence;
  }

In primo luogo, è necessario ottenere un oggetto client per l'API viso, passando la chiave di sottoscrizione e l'endpoint dell'API. È possibile ottenere entrambi i valori dal portale di Azure in cui è stato effettuato il provisioning del servizio API viso. È quindi rilevare un viso visibile in un'immagine, passata come un flusso per il metodo DetectWithStreamAsync dell'oggetto di volti del client. L'oggetto volto implementa le operazioni di rilevamento e la verifica per l'API viso. Ricavati dai volti rilevati, è possibile garantire che solo uno in realtà viene rilevata e ottenere il relativo ID, ovvero il relativo identificatore univoco nella raccolta di visi registrato di tutte le persone autorizzate per accedere a tale sito. Il metodo IdentifyAsync quindi esegue l'identificazione del volto rilevato all'interno di un gruppo di persone e restituisce un elenco di corrispondenze migliori o candidati, ordinati in base al livello di confidenza. Con l'ID utente dei candidati prima, recuperare il nome di persona, che viene infine restituito all'API Web di accesso. Viene soddisfatto il requisito di autorizzazione di visi.

Riconoscimento vocale

Azure Cognitive Services API riconoscimento del parlante include algoritmi avanzatiPer la verifica e identificazione voce. Voices dispongono di caratteristiche univoche che possono essere utilizzate per identificare una persona, esattamente come un'impronta digitale. La soluzione di sicurezza in questo articolo Usa voce come segnale per il controllo di accesso in cui l'oggetto indicato una passphrase in un microfono registrato come un dispositivo IoT. Proprio come con riconoscimento del viso, riconoscimento vocale richiede inoltre una pre-registrazione di persone autorizzate. L'API voce chiama una persona registrata un "profilo". Durante la registrazione di un profilo, voce di chi parla verrà registrata che informa che una frase specifica, quindi alcune funzionalità viene estratti e la frase scelta è stata riconosciuta. Insieme, le caratteristiche estratte e della frase scelta form una firma vocale univoca. Durante la verifica, una voce di input e di una frase vengono confrontati con firma vocale e di una frase, la registrazione per verificare se siano dalla stessa persona e se la frase è corretta.

Esaminando l'implementazione del codice, l'API voce trae vantaggio da un pacchetto gestito in NuGet, ad esempio l'API viso, in modo che l'approccio che analizzerò consiste nel richiamare l'API REST direttamente con un meccanismo di richiesta e risposta client HTTP. La prima consiste nel creare un'istanza di un HttpClient con i parametri necessari per l'autenticazione e il tipo di dati:

public VoiceRecognition()
{
  _httpClient = new HttpClient();
  _httpClient.BaseAddress = new Uri("<API Endpoint>");
  _httpClient.DefaultRequestHeaders.Add("Ocp-Apim-Subscription-Key",
    "<Subscription Key>");
  _httpClient.DefaultRequestHeaders.Accept.Add(
     new MediaTypeWithQualityHeaderValue("application/json"));
}

Il metodo Recognize figura 6 sviluppa in diversi passaggi, come indicato di seguito: Dopo aver ottenuto il flusso audio dal dispositivo IoT nel sito, tenta di identificare tale audio su una raccolta di profili registrati. Identificazione viene codificato nel metodo IdentifyAsync. Questo metodo asincrono prepara un messaggio di richiesta multiparte che contiene il flusso audio e l'ID del profilo di identificazione e invia una richiesta POST a un endpoint specifico. Se la risposta dall'API di codice HTTP 202 (accettato), il valore restituito è un URI dell'operazione che viene eseguito in background. Questa operazione, in corrispondenza dell'URI identificato, viene controllata dal metodo di Recognize ogni 100 ms per il completamento. Quando viene completata, è stato ottenuto l'ID del profilo dell'utente identificato. Con tale ID, è possibile procedere con la verifica del flusso audio, ovvero la conferma finale che la voce registrata appartenga alla persona identificata. Viene implementato nel metodo VerifyAsync, che funziona in modo analogo al metodo IdentifyAsync ad eccezione del fatto che restituisce un oggetto VoiceVerificationResponse, che contiene il profilo dell'utente e, pertanto il relativo nome. La risposta di verifica include un livello di confidenza, viene restituito anche per l'API Web di accesso, come con l'API viso.

Figura 6 il riconoscimento vocale

public double Recognize(string siteId, out string name)
{
  ReadAudioStream(siteId, out Stream audioStream);
  Guid[] enrolledProfileIds = GetEnrolledProfilesAsync();
  string operationUri =
    IdentifyAsync(audioStream, enrolledProfileIds).Result;
  IdentificationOperation status = null;
  do
  {
    status = CheckIdentificationStatusAsync(operationUri).Result;
    Thread.Sleep(100);
  } while (status == null);
  Guid profileId = status.ProcessingResult.IdentifiedProfileId;
  VoiceVerificationResponse verification =
    VerifyAsync(profileId, audioStream).Result;
  if (verification == null)
  {
    name = string.Empty;
    return 0;
  }
  Profile profile = GetProfileAsync(profileId).Result;
  name = profile.Name;
  return ToConfidenceScore(verification.Confidence);
}

Voglio aggiungere alcuni commenti aggiuntivi su quest'API, che indica le differenze rispetto all'API viso. La verifica tramite chiamata vocale API restituisce un oggetto JSON che contiene il risultato complessivo dell'operazione di verifica (accettazione o rifiuto), livello di confidenza (Low, Normal o High) e la frase riconosciuta:

{
  "result" : "Accept", // [Accept | Reject]
  "confidence" : "Normal", // [Low | Normal | High]
  "phrase": "recognized phrase"
}

Viene eseguito il mapping di questo oggetto per il VoiceVerificationResponse C# classe per comodità dell'operazione all'interno del metodo VerifyAsync, ma il suo livello di confidenza è espressa come un testo:

public class VoiceVerificationResponse
{
  [JsonConverter(typeof(StringEnumConverter))]
  public Result Result { get; set; }
  [JsonConverter(typeof(StringEnumConverter))]
  public Confidence Confidence { get; set; }
  public string Phrase { get; set; }
}

L'API Web di accesso, invece, si aspetta che un valore decimale (tipo di dati double) compreso tra zero e uno, pertanto specificati alcuni valori numerici per l'enumerazione di confidenza:

public enum Confidence
{
  Low = 1,
  Normal = 50,
  High = 99
}

Questi valori quindi convertito in double prima della restituzione all'API Web di accesso:

private double ToConfidenceScore(Confidence confidence)
{
  return (double)confidence / 100.0d;
}

Conclusioni

Questo è tutto per la prima parte, in cui illustrato il flusso di sicurezza di accesso sito generale e illustrati l'implementazione del meccanismo di autorizzazione nell'API Web ASP.NET Core con i requisiti e criteri personalizzati. Quindi illustrati viso e riconoscimento della voce, usando l'API servizi cognitivi rilevanti, come un meccanismo per limitare l'accesso in base alle informazioni biometriche di pre-autorizzati, o registrati, i profili utente. Nella seconda parte di questo articolo, mi porto tramite i dati di streaming dai dispositivi IoT come punto di attivazione per la richiesta di accesso e la conferma finale dall'API di accesso per lo sblocco (o bloccare!) la porta di accesso. Tratta anche un servizio di rilevamento delle anomalie basato su apprendimento macchina in cui verrà eseguito alcun tentativo di accesso per identificare il rischio.

Il codice sorgente per questa parte iniziale della soluzione è disponibile in GitHub all'indirizzo bit.ly/2IXPZCo.

Stefano Tempestaè un Microsoft Regional Director, MVP su intelligenza artificiale e applicazioni aziendali e membro del Consiglio di Blockchain. Partecipa regolarmente come oratore a conferenze IT internazionali, tra cui Microsoft Ignite e Tech Summit, interessi di Tempesta estendono blockchain e tecnologie correlate per intelligenza artificiale. Ha creato spazio Blogchain (blogchain.space), un blog sulle tecnologie della blockchain, scrive per MSDN Magazine e MS Dynamics e pubblica esperimenti di machine learning in Azure AI Gallery (Gallery.Azure.ai).

Grazie al seguente esperto tecnico Microsoft che ha esaminato in questo articolo: Barry Dorrans

Discutere di questo articolo nel forum di MSDN Magazine