Introduzione allo sviluppo di app di Windows sicure

Articolo
07/17/2024

Questo articolo introduttivo aiuta gli architetti e gli sviluppatori di app a comprendere meglio le varie funzionalità della piattaforma Windows 10 che accelerano la creazione di app UWP (Universal Windows Platform) sicure. Descrive in dettaglio come utilizzare le funzionalità di sicurezza di Windows disponibili in ciascuna delle fasi seguenti: autenticazione, dati in transito e dati inattivi. È possibile trovare informazioni più approfondite su ciascun argomento esaminando le risorse aggiuntive incluse in ciascun capitolo.

1 Introduzione

Sviluppare un'app sicura può essere una sfida. Nel frenetico mondo di oggi, caratterizzato da app mobili, social, cloud e complesse aziende, i clienti si aspettano che le app diventino disponibili e aggiornate più velocemente che mai. Utilizzano inoltre molti tipi di dispositivi, il che aumenta ulteriormente la complessità della creazione di esperienze con le app. Se crei per Windows piattaforma UWP (Universal Windows Platform) (UWP), che potrebbe includere l'elenco tradizionale di desktop, portatili, tablet e dispositivi mobili, oltre a un elenco crescente di nuovi dispositivi che si estendono su Internet delle cose, Xbox One, Microsoft Surface Hub e HoloLens. In qualità di sviluppatore, devi garantire che le tue app comunichino e archivino i dati in modo sicuro, su tutte le piattaforme o dispositivi coinvolti.

Ecco alcuni dei vantaggi dell'uso delle funzionalità di sicurezza di Windows.

Si avrà una sicurezza standardizzata in tutti i dispositivi che supportano Windows, usando API coerenti per i componenti e le tecnologie di sicurezza.
Scrivi, testi e mantieni meno codice di quello che faresti se implementassi un codice personalizzato per coprire questi scenari di sicurezza.
Le tue app diventano più stabili e sicure perché utilizzi il sistema operativo per controllare il modo in cui l'app accede alle proprie risorse e alle risorse del sistema locale o remoto.

Durante l'autenticazione viene convalidata l'identità di un utente che richiede l'accesso ad un particolare servizio. Windows Hello è il componente di Windows che consente di creare un meccanismo di autenticazione più sicuro nelle app di Windows. Con esso, puoi utilizzare un numero di identificazione personale (PIN) o dati biometrici come le impronte digitali, il viso o l'iride dell'utente per implementare l'autenticazione a più fattori per le tue app.

I dati in volo si riferiscono alla connessione e ai messaggi trasferiti attraverso di essa. Un esempio di ciò è il recupero dei dati da un server remoto utilizzando i servizi web. L'uso di Secure Sockets Layer (SSL) e Secure Hypertext Transfer Protocol (HTTPS) garantisce la sicurezza della connessione. Impedire agli intermediari di accedere a questi messaggi o alle app non autorizzate di comunicare con i servizi web è fondamentale per proteggere i dati in volo.

Infine, i dati at-rest si riferiscono ai dati che risiedono in memoria o su supporti di memorizzazione. Le app di Windows hanno un modello di app che impedisce l'accesso non autorizzato ai dati tra le app e offre API di crittografia per proteggere ulteriormente i dati nel dispositivo. Una funzionalità chiamata Credential Locker può essere utilizzata per archiviare in modo sicuro le credenziali dell'utente sul dispositivo, con il sistema operativo che impedisce ad altre app di accedervi.

2 Fattori di autenticazione

Per proteggere i dati, la persona che richiede l'accesso agli stessi deve essere identificata e autorizzata ad accedere alle risorse dati richieste. Il processo di identificazione di un utente è chiamato autenticazione e la determinazione dei privilegi di accesso a una risorsa è chiamata autorizzazione. Si tratta di operazioni strettamente correlate e per l'utente potrebbero essere indistinguibili. Possono essere operazioni relativamente semplici o complesse, a seconda di molti fattori: ad esempio, se i dati risiedono su un server o sono distribuiti su più sistemi. Il server che fornisce i servizi di autenticazione e autorizzazione viene definito provider di identità.

Per autenticarsi con un particolare servizio e/o app, l'utente utilizza credenziali composte da qualcosa che conosce, qualcosa che ha e/o qualcosa che è. Ognuno di questi è chiamato fattori di autenticazione.

Qualcosa che l'utente conosce è solitamente una password, ma può anche essere un numero di identificazione personale (PIN) o una coppia di domande e risposte "segrete".
Qualcosa che l'utente ha è molto spesso un dispositivo di memoria hardware come una chiavetta USB contenente i dati di autenticazione univoci dell'utente.
Qualcosa che l'utente spesso comprende le impronte digitali, ma ci sono fattori sempre più popolari come il linguaggio dell'utente, le caratteristiche facciali, oculari (occhi) o i modelli di comportamento. Se archiviate come dati, queste misurazioni sono chiamate biometriche.

Una password creata dall’utente è di per sé un fattore di autenticazione, ma spesso non è sufficiente; chiunque conosca la password può impersonare l'utente che la possiede. Una smart card può fornire un livello di sicurezza più elevato, ma potrebbe essere rubata, persa o smarrita. Un sistema in grado di autenticare un utente tramite l'impronta digitale o tramite una scansione oculare potrebbe fornire il livello di sicurezza più elevato e conveniente, ma richiede hardware costoso e specializzato (ad esempio, una fotocamera Intel RealSense per il riconoscimento facciale) che potrebbe non essere disponibile a tutti gli utenti.

Progettare il metodo di autenticazione utilizzato da un sistema è un aspetto complesso e importante della sicurezza dei dati. In generale, maggiore è il numero di fattori utilizzati nell'autenticazione, più sicuro è il sistema. Allo stesso tempo, l’autenticazione deve essere utilizzabile. Un utente solitamente accede più volte al giorno, quindi il processo deve essere veloce. La scelta del tipo di autenticazione è un compromesso tra sicurezza e facilità d'uso; l'autenticazione a fattore singolo è la meno sicura e più semplice da usare, mentre l'autenticazione a più fattori diventa più sicura, ma più complessa man mano che vengono aggiunti più fattori.

2.1 Autenticazione a fattore singolo

Questa forma di autenticazione si basa su una singola credenziale utente. Solitamente si tratta di una password, ma potrebbe anche essere un numero di identificazione personale (PIN).

Ecco il processo di autenticazione a fattore singolo.

L'utente fornisce il proprio nome utente e password al provider di identità. Il provider di identità è il processo server che verifica l'identità dell'utente.
Il provider di identità verifica se il nome utente e la password corrispondono a quelli memorizzati nel sistema. Nella maggior parte dei casi, la password verrà crittografata, fornendo ulteriore sicurezza in modo che altri non possano leggerla.
Il provider di identità restituisce uno stato di autenticazione che indica se l'autenticazione ha avuto esito positivo.
In caso di successo, inizia lo scambio di dati. In caso di esito negativo, l'utente dovrà essere nuovamente autenticato.

Autenticazione a fattore singolo

Oggi questo metodo di autenticazione è quello più comunemente utilizzato tra i servizi. È anche la forma di autenticazione meno sicura se utilizzata come unico mezzo di autenticazione. I requisiti di complessità della password, le "domande segrete" e le modifiche regolari delle password possono rendere più sicuro l'utilizzo delle password, ma comportano un onere maggiore per gli utenti e non costituiscono un deterrente efficace contro gli hacker.

La sfida con le password è che è più facile indovinarle con successo rispetto ai sistemi che hanno più di un fattore. Se rubano un database con account utente e password con hash da un piccolo negozio web, possono utilizzare le password utilizzate su altri siti web. Gli utenti tendono a riutilizzare continuamente gli account, perché le password complesse sono difficili da ricordare. Per un reparto IT, la gestione delle password comporta anche la complessità di dover offrire meccanismi di reimpostazione, richiedere aggiornamenti frequenti delle password e archiviarle in modo sicuro.

Nonostante tutti i suoi svantaggi, l'autenticazione a fattore singolo offre all'utente il controllo delle credenziali. Lo creano e lo modificano e per il processo di autenticazione è necessaria solo una tastiera. Questo è l’aspetto principale che distingue l’autenticazione a fattore singolo da quella a più fattori.

2.1.1 Broker di autenticazione web

Come discusso in precedenza, una delle sfide legate all'autenticazione della password per un reparto IT è il sovraccarico aggiuntivo derivante dalla gestione della base di nomi utente/password, meccanismi di reimpostazione, ecc. Un'opzione sempre più popolare è affidarsi a fornitori di identità di terze parti che offrono l'autenticazione tramite OAuth, uno standard aperto per l'autenticazione.

Usando OAuth, i reparti IT possono "esternalizzare" in modo efficace la complessità della gestione di un database con nomi utente e password, reimpostare la funzionalità delle password e così via a un provider di identità di terze parti come Facebook, X o Microsoft.

Gli utenti hanno il controllo completo sulla propria identità su queste piattaforme, ma le app possono richiedere al provider, dopo che l'utente è stato autenticato e con il suo consenso, che può essere utilizzato per autorizzare gli utenti autenticati.

Il gestore di autenticazione Web in Windows offre un set di API e infrastruttura per le app per l'uso di protocolli di autenticazione e autorizzazione come OAuth e OpenID. Le app possono avviare operazioni di autenticazione tramite WebAuthenticationBroker API, con conseguente restituzione di WebAuthenticationResult. Una panoramica del flusso di comunicazione è illustrata nella figura seguente.

flusso di lavoro wab

L'app funge da broker, avviando l'autenticazione con il provider di identità tramite WebView nell'app. Quando il provider di identità ha autenticato l'utente, restituisce un token all'app che può essere utilizzato per richiedere informazioni sull'utente al provider di identità. Come misura di sicurezza, l'app deve essere registrata presso il provider di identità prima di poter mediare i processi di autenticazione con il provider di identità. I passaggi di registrazione differiscono per ciascun fornitore.

Ecco il flusso di lavoro generale per chiamare WebAuthenticationBroker API per comunicare con il provider.

Costruisci le stringhe di richiesta da inviare al provider di identità. Il numero di stringhe e le informazioni in ciascuna stringa sono diversi per ciascun servizio Web, ma solitamente includono due stringhe URI ciascuna contenente un URL: una a cui viene inviata la richiesta di autenticazione e una a cui l'utente viene reindirizzato dopo aver ottenuto l'autorizzazione. completare.
Chiamal WebAuthenticationBroker.AuthenticateAsync, passando le stringhe di richiesta e attendi la risposta dal provider di identità.
Chiama WebAuthenticationResult.ResponseStatus per ottenere lo stato quando viene ricevuta la risposta.
Se la comunicazione ha esito positivo, elaborare la stringa di risposta restituita dal provider di identità. In caso di esito negativo, elaborare l'errore.

Se la comunicazione ha esito positivo, elaborare la stringa di risposta restituita dal provider di identità. In caso di esito negativo, elaborare l'errore.

Di seguito è riportato il codice C# di esempio per questo processo. Per informazioni e una guida dettagliata, vedere il WebAuthenticationBroker. Per un esempio di codice completo, consulta l'esempio di WebAuthenticationBroker su 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 Autenticazione a più fattori

L'autenticazione a più fattori utilizza più di un fattore di autenticazione. Di solito, "qualcosa che conosci", come una password, è combinato con "qualcosa che hai", che può essere un telefono cellulare o una smart card. Anche se un utente malintenzionato scopre la password dell’utente, l’account resta inaccessibile senza il dispositivo o la carta. E se viene compromesso solo il dispositivo o la carta, senza la password non è utile all'aggressore. L’autenticazione a più fattori è quindi più sicura, ma anche più complessa, dell’autenticazione a fattore singolo.

I servizi che utilizzano l'autenticazione a più fattori spesso offrono all'utente la possibilità di scegliere come ricevere la seconda credenziale. Un esempio di questo tipo di autenticazione è un processo comunemente utilizzato in cui un codice di verifica viene inviato al telefono cellulare dell’utente tramite SMS.

L'utente fornisce il proprio nome utente e password al provider di identità.
Il provider di identità verifica il nome utente e la password come nell'autorizzazione a fattore singolo, quindi cerca il numero di cellulare dell'utente memorizzato nel sistema.
Il server invia un messaggio SMS contenente un codice di verifica generato al cellulare dell'utente.
L'utente fornisce il codice di verifica al provider di identità; attraverso un modulo presentato all'utente.
Il provider di identità restituisce uno stato di autenticazione che indica se l'autenticazione di entrambe le credenziali ha avuto esito positivo.
In caso di successo, inizia lo scambio di dati. In caso contrario, l'utente dovrà essere nuovamente autenticato.

autenticazione a due fattori

Come puoi vedere, questo processo differisce anche dall'autenticazione a fattore singolo in quanto la seconda credenziale utente viene inviata all'utente invece di essere creata o fornita dall'utente. L'utente non ha quindi il controllo completo delle credenziali necessarie. Ciò vale anche quando si utilizza una smart card come seconda credenziale: l'organizzazione ha il compito di crearla e fornirla all'utente.

2.2.1 Azure Active Directory

Azure Active Directory (Azure AD) è un servizio di gestione delle identità e degli accessi basato su cloud che può fungere da provider di identità nell'autenticazione a fattore singolo o a più fattori. L'autenticazione di Azure AD può essere utilizzata con o senza un codice di verifica.

Anche se Azure AD può implementare anche l'autenticazione a fattore singolo, le aziende in genere richiedono la maggiore sicurezza dell'autenticazione a più fattori. In una configurazione di autenticazione a più fattori, un utente che esegue l'autenticazione con un account Azure AD ha la possibilità di ricevere un codice di verifica inviato come messaggio SMS al proprio telefono cellulare o all'app mobile Azure Authenticator.

Inoltre, Azure AD può essere utilizzato come provider OAuth, fornendo all'utente standard un meccanismo di autenticazione e autorizzazione per le app su varie piattaforme. Per saperne di più, vedi Azure Active Directory e autenticazione a più fattori in Azure.

2.4 Windows Hello

In Windows, un pratico meccanismo di autenticazione a più fattori è integrato nel sistema operativo. Windows Hello è il nuovo sistema di accesso biometrico integrato in Windows. Poiché è integrato direttamente nel sistema operativo, Windows Hello consente l'identificazione del volto o dell'impronta digitale per sbloccare i dispositivi degli utenti. L'archivio credenziali sicure di Windows protegge i dati biometrici nel dispositivo.

Windows Hello offre a un dispositivo un modo affidabile per riconoscere un singolo utente, affrontando la prima parte del percorso tra un utente e un servizio o un elemento di dati richiesto. Dopo che il dispositivo ha riconosciuto l'utente, deve comunque autenticarlo prima di determinare se concedere l'accesso a una risorsa richiesta. Windows Hello fornisce inoltre una forte autenticazione a due fattori (2FA) completamente integrata in Windows e sostituisce le password riutilizzabili con la combinazione di un dispositivo specifico e un gesto biometrico o PIN. Il PIN viene specificato dall'utente come parte della registrazione dell'account Microsoft.

Tuttavia, Windows Hello non è solo un sostituto dei tradizionali sistemi 2FA. È concettualmente simile alle smart card: l'autenticazione viene eseguita utilizzando primitive crittografiche anziché confronti di stringhe e il materiale della chiave dell'utente è protetto all'interno di hardware a prova di manomissione. Microsoft Hello non richiede nemmeno i componenti infrastrutturali aggiuntivi necessari per la distribuzione delle smart card. In particolare, non hai bisogno di un’infrastruttura a chiave pubblica (PKI) per gestire i certificati, se al momento non ne disponi. Windows Hello combina i principali vantaggi delle smart card, ovvero flessibilità di distribuzione per le smart card virtuali e solida sicurezza per le smart card fisiche, senza nessuno dei relativi svantaggi.

Un dispositivo deve essere registrato con Windows Hello prima che gli utenti possano autenticarsi con esso. Windows Hello utilizza la crittografia asimmetrica (chiave pubblica/privata) in cui una parte utilizza una chiave pubblica per crittografare i dati che l'altra parte può decrittografare utilizzando una chiave privata. Nel caso di Windows Hello, crea un set di coppie di chiavi pubbliche/private e scrive le chiavi private sul chip TPM (Trusted Platform Module) del dispositivo. Dopo che un dispositivo è stato registrato, le app UWP possono chiamare le API di sistema per recuperare la chiave pubblica dell'utente, che può essere usata per registrare l'utente sul server.

Il flusso di lavoro di registrazione di un'app potrebbe essere simile al seguente:

registrazione di windows hello

Le informazioni di registrazione raccolte potrebbero includere molte più informazioni identificative rispetto a questo semplice scenario. Ad esempio, se la tua app accede a un servizio protetto come quello bancario, dovresti richiedere una prova di identità e altri elementi come parte del processo di registrazione. Una volta soddisfatte tutte le condizioni, la chiave pubblica di questo utente verrà archiviata nel back-end e utilizzata per convalidare la prossima volta che l'utente utilizzerà il servizio.

Per altre informazioni su Windows Hello, vedere la panoramica di Windows Hello for Business e la Guida per sviluppatori di Windows Hello.

3 Metodi di sicurezza dei dati in transito

I metodi di sicurezza dei dati in transito si applicano ai dati in movimento tra dispositivi connessi a una rete. I dati possono essere trasferiti tra sistemi nell'ambiente ad alta sicurezza di un'intranet aziendale privata o tra un cliente e un servizio web nell'ambiente non sicuro del web. Le app di Windows supportano standard come SSL tramite le API di rete e mettono a punto tecnologie come Azure Gestione API con cui gli sviluppatori possono garantire il livello di sicurezza appropriato per le app.

3.1 Autenticazione del sistema remoto

Esistono due scenari generali in cui avviene la comunicazione con un sistema informatico remoto.

Un server locale autentica un utente tramite una connessione diretta. Ad esempio, quando il server e il client si trovano su una intranet aziendale.
La comunicazione con un servizio Web avviene tramite Internet.

I requisiti di sicurezza per la comunicazione dei servizi Web sono più elevati rispetto a quelli degli scenari di connessione diretta, poiché i dati non fanno più solo parte di una rete sicura e anche la probabilità che aggressori malintenzionati cerchino di intercettare i dati è maggiore. Poiché vari tipi di dispositivi accederanno al servizio, saranno probabilmente creati come servizi RESTful, al contrario di WCF, ad esempio, il che significa che anche l'autenticazione e l'autorizzazione al servizio introducono nuove sfide. Discuteremo due requisiti per la comunicazione sicura del sistema remoto.

Il primo requisito è la riservatezza dei messaggi: le informazioni scambiate tra il cliente e i servizi web (ad esempio, l'identità dell'utente e altre informazioni personali) non devono essere leggibili da terzi durante il transito. Ciò viene solitamente ottenuto crittografando la connessione su cui vengono inviati i messaggi e crittografando il messaggio stesso. Nella crittografia a chiave privata/pubblica, la chiave pubblica è disponibile a chiunque e viene utilizzata per crittografare i messaggi da inviare a un destinatario specifico. La chiave privata è conservata solo dal destinatario e viene utilizzata per decrittografare il messaggio.

Il secondo requisito è l'integrità del messaggio: il client e il servizio web devono essere in grado di verificare che i messaggi che ricevono siano quelli destinati ad essere inviati dall'altra parte e che il messaggio non sia stato alterato durante il transito. Ciò si ottiene firmando i messaggi con firme digitali e utilizzando l'autenticazione del certificato.

3.2 Connessioni SSL

Per stabilire e mantenere connessioni sicure ai client, i servizi Web possono utilizzare Secure Sockets Layer (SSL), supportato dal Secure Hypertext Transfer Protocol (HTTPS). SSL garantisce la riservatezza e l'integrità dei messaggi supportando la crittografia a chiave pubblica e i certificati del server. SSL è sostituito da Transport Layer Security (TLS), ma TLS viene spesso definito casualmente SSL.

Quando un client richiede l'accesso a una risorsa su un server, SSL avvia un processo di negoziazione con il server. Conosciuto come handshake SSL. Come base di tutte le comunicazioni per la durata della connessione SSL vengono concordati un livello di crittografia, una serie di chiavi di crittografia pubbliche e private e le informazioni sull'identità nei certificati client e server. Il server potrebbe anche richiedere l'autenticazione del client in questo momento. Una volta stabilita la connessione, tutti i messaggi vengono crittografati con la chiave pubblica negoziata fino alla chiusura della connessione.

3.2.1 SSL pinning

Sebbene SSL possa garantire la riservatezza dei messaggi utilizzando crittografia e certificati, non fa nulla per verificare che il server con cui il client sta comunicando sia quello corretto. Il comportamento del server può essere imitato da una terza parte non autorizzata, intercettando i dati sensibili trasmessi dal client. Per evitare ciò, viene utilizzata una tecnica chiamata blocco SSL per verificare che il certificato sul server sia quello che il client si aspetta e di cui si fida.

Esistono diversi modi per implementare il blocco SSL nelle app, ciascuno con i propri pro e contro. L'approccio più semplice è tramite la dichiarazione dei certificati nel manifest del pacchetto dell'app. Questa dichiarazione consente al pacchetto dell'app di installare certificati digitali e di specificarne l'attendibilità esclusiva. Ciò fa sì che le connessioni SSL siano consentite solo tra l'app e i server che dispongono dei certificati corrispondenti nella catena di certificati. Questo meccanismo consente inoltre l'uso sicuro dei certificati autofirmati, poiché non è necessaria alcuna dipendenza da terze parti da autorità di certificazione pubbliche attendibili.

manifesto ssl

Per un maggiore controllo sulla logica di convalida, sono disponibili API per convalidare i certificati restituiti dal server in risposta a una richiesta HTTPS. Tieni presente che questo metodo richiede l'invio di una richiesta e l'ispezione della risposta, quindi assicurati di aggiungerlo come convalida prima di inviare effettivamente informazioni sensibili in una richiesta.

Il codice C# seguente illustra questo metodo di blocco SSL. Il metodo ValidateSSLRoot utilizza la classe HttpClient per eseguire una richiesta HTTP. Dopo che il client ha inviato la risposta, utilizza la raccolta RequestMessage.TransportInformation.ServerIntermediateCertificates per controllare i certificati restituiti dal server. Il client può quindi convalidare l'intera catena di certificati con le identificazioni personali incluse. Questo metodo richiede l'aggiornamento delle identificazioni personali del certificato nell'app quando il certificato del server scade e viene rinnovato.

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 Pubblicazione e protezione dell'accesso alle API REST

Per garantire l'accesso autorizzato ai servizi web, devono richiedere l'autenticazione ogni volta che viene effettuata una chiamata API. Essere in grado di controllare le prestazioni e la scalabilità è un altro aspetto da considerare quando i servizi Web vengono esposti sul Web. Gestione API di Azure è un servizio che consente di esporre le API sul Web, fornendo funzionalità su tre livelli.

Gli editori/amministratori dell'API possono configurare facilmente l'API tramite il portale dell'editore di Gestione API di Azure. Qui è possibile creare set di API e gestirne l'accesso per controllare chi ha accesso a quali API.

Gli sviluppatori che desiderano accedere a queste API possono effettuare richieste tramite il portale degli sviluppatori, che può fornire immediatamente l'accesso o richiedere l'approvazione da parte dell'editore/amministratore. Gli sviluppatori possono anche visualizzare la documentazione API e il codice di esempio nel Portale sviluppatori, per adottare rapidamente le API offerte dal servizio web.

Le app create da questi sviluppatori accedono quindi all'API tramite il proxy offerto da Gestione API di Azure.. Il proxy fornisce uno strato di oscurità, nascondendo il punto finale effettivo dell'API sul server dell'editore/amministratore e può anche includere logica aggiuntiva come la traduzione dell'API per garantire che l'API esposta sia mantenuta coerente quando una chiamata a un'API viene reindirizzata a un altro. Può anche utilizzare il filtraggio IP per bloccare le chiamate API provenienti da un dominio IP specifico o da un insieme di domini. Gestione API di Azure garantisce inoltre la sicurezza dei servizi Web utilizzando un set di chiavi pubbliche, denominate chiavi API, per autenticare e autorizzare ogni chiamata API. Quando l'autorizzazione fallisce, l'accesso all'API e alle funzionalità da essa supportate viene bloccato.

Gestione API di Azure può anche ridurre il numero di chiamate API a un servizio (una procedura denominata limitazione) per ottimizzare le prestazioni del servizio Web. Per saperne di più, vedi Gestione API di Azure e Gestione API di Azure all'AzureCon 2015.

4 metodi di sicurezza dei dati inattivi

Quando i dati arrivano su un dispositivo, li chiamiamo "dati inattivi". Questi dati devono essere archiviati sul dispositivo in modo sicuro, in modo che utenti o app non autorizzati non possano accedervi. Il modello di app in Windows garantisce molto che i dati archiviati da qualsiasi app siano accessibili solo a tale app, fornendo api per condividere i dati quando necessario. Sono inoltre disponibili API aggiuntive per garantire che i dati possano essere crittografati e le credenziali possano essere archiviate in modo sicuro.

4.1 Modello dell'app Windows

Tradizionalmente, Windows non ha mai avuto una definizione di app. Più comunemente veniva definito eseguibile (.exe) e questo non includeva mai l'installazione, l'archiviazione dello stato, la durata dell'esecuzione, il controllo delle versioni, l'integrazione del sistema operativo o la comunicazione da app a app. Il modello Universal Windows Platform definisce un modello di app che copre installazione, ambiente di runtime, gestione delle risorse, aggiornamenti, modello di dati e disinstallazione.

Le app di Windows 10 vengono eseguite in un contenitore, il che significa che dispongono di privilegi limitati per impostazione predefinita (privilegi aggiuntivi possono essere richiesti e concessi dall'utente). Ad esempio, se un'app desidera accedere ai file nel sistema, un selettore di file dallo spazio dei nomi Windows.Storage.Pickers deve essere utilizzato per consentire all'utente di scegliere un file (non è abilitato l'accesso diretto ai file). Un altro esempio è che se un'app desidera accedere ai dati sulla posizione dell'utente, deve abilitare la dichiarazione della funzionalità del dispositivo di localizzazione, richiedendo all'utente al momento del download che questa app richiederà l'accesso alla posizione dell'utente. Inoltre, la prima volta che l'app desidera accedere alla posizione dell'utente, all'utente viene mostrata un'ulteriore richiesta di consenso, richiedendo l'autorizzazione ad accedere ai dati.

Tieni presente che questo modello di app funge da "prigione" per le app, il che significa che non possono essere raggiunte, ma non è un "castello" che non può essere raggiunto dall'esterno (le applicazioni con privilegi di amministratore possono ovviamente ancora entrare). . Device Guard in Windows, che consente alle organizzazioni/IT di specificare quali app (Win32) sono autorizzate a eseguire, possono contribuire ulteriormente a limitare questo accesso.

Il modello di app gestisce anche il ciclo di vita dell'app. Ad esempio, limita l'esecuzione in background delle app per impostazione predefinita; non appena un'app passa in background, il processo viene sospeso (dopo aver concesso all'app un breve periodo per risolvere la sospensione dell'app nel codice) e la sua memoria viene congelata. Il sistema operativo fornisce meccanismi affinché le app richiedano l'esecuzione di attività in background specifiche (secondo una pianificazione, attivata da vari eventi come connettività Internet/Bluetooth, cambiamenti di alimentazione, ecc. e in scenari specifici come la riproduzione di musica o il tracciamento GPS).

Quando le risorse di memoria del dispositivo stanno per esaurirsi, Windows libera spazio di memoria chiudendo le app. Questo modello di ciclo di vita obbliga le app a rendere persistenti i dati ogni volta che vengono sospese, perché non c'è tempo aggiuntivo disponibile tra la sospensione e la terminazione.

Per maggiori informazioni, vedere È universale: comprendere il ciclo di vita di un'applicazione Windows 10/11.

4.2 Protezione delle credenziali archiviate

Le app Windows che accedono ai servizi autenticati spesso offrono agli utenti la possibilità di archiviare le proprie credenziali sul dispositivo locale. Questa è una comodità per gli utenti; quando forniscono nome utente e password, l'app li utilizza automaticamente nei successivi avvii dell'app. Poiché può trattarsi di un problema di sicurezza se un utente malintenzionato ottiene l'accesso a questi dati archiviati, Windows offre la possibilità per le app in pacchetto di archiviare le credenziali utente in una casella di sicurezza delle credenziali. L'app chiama l'API Credential Locker per archiviare e recuperare le credenziali dall'armadietto invece di archiviarle nel contenitore di archiviazione dell'app. L'armadietto delle credenziali è gestito dal sistema operativo, ma l'accesso è limitato all'app che le archivia, fornendo una soluzione gestita in modo sicuro per l'archiviazione delle credenziali.

Quando un utente fornisce le credenziali da archiviare, l'app ottiene un riferimento all'archivio delle credenziali utilizzando l'oggetto PasswordVault nel namespace Windows.Security.Credentials. Crea un oggetto PasswordCredential contenente un identificatore per l'app Windows, nome utente e password. Questo viene passato al metodo PasswordVault.Add conservare le credenziali. Nell'esempio di codice C# seguente viene illustrato come eseguire questa operazione.

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

Nell'esempio di codice C# seguente l'app richiede tutte le credenziali corrispondenti all'app chiamando il metodo FindAllByResource dell'oggetto PasswordVault. Se ne viene restituito più di uno, viene richiesto all'utente di inserire il proprio nome utente. Se le credenziali non sono nell'armadietto, l'app le richiede all'utente. L'utente viene quindi loggato nel server utilizzando le credenziali.

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;
}

Per maggiori informazioni, vedere Casella di sicurezza delle credenziali.

4.3 Protezione dei dati archiviati

Quando si ha a che fare con dati archiviati, comunemente definiti dati non attivi, la crittografia può impedire a utenti non autorizzati di accedere ai dati archiviati. I due meccanismi comuni per crittografare i dati utilizzano chiavi simmetriche o chiavi asimmetriche. Tuttavia, la crittografia dei dati non può garantire che i dati rimangano inalterati tra il momento in cui sono stati inviati e il momento in cui sono stati archiviati. In altre parole, l’integrità dei dati non può essere garantita. L'utilizzo di codici di autenticazione dei messaggi, hash e firma digitale sono tecniche comuni per risolvere questo problema.

4.3.1 Crittografia dei dati

Con la crittografia simmetrica, sia il mittente che il destinatario hanno la stessa chiave e la utilizzano sia per crittografare che per decrittografare i dati. La sfida con questo approccio è condividere in modo sicuro la chiave in modo che entrambe le parti ne siano consapevoli.

Una risposta a questo è la crittografia asimmetrica, in cui viene utilizzata una coppia di chiavi pubblica/privata. La chiave pubblica viene condivisa liberamente con chiunque desideri crittografare un messaggio. La chiave privata viene sempre mantenuta segreta in modo che solo tu possa utilizzarla per decrittografare i dati. Una tecnica comune per consentire il rilevamento della chiave pubblica consiste nell'utilizzare certificati digitali, detti anche semplicemente certificati. Il certificato contiene informazioni sulla chiave pubblica, oltre alle informazioni sull'utente o sul server come nome, emittente, indirizzo email e paese.

Gli sviluppatori di app Windows possono utilizzare SymmetricKeyAlgorithmProvider e le classi AsymmetricKeyAlgorithmProvider per implementare la crittografia simmetrica e asimmetrica nelle proprie app UWP. Inoltre, la classe CryptographicEngine può essere utilizzata per crittografare e decrittografare dati, firmare contenuti e verificare le firme digitali. Le app possono anche utilizzare la classe DataProtectionProvider nel nome dello spazio Windows.Security.Cryptography.DataProtection per crittografare e decrittografare i dati locali archiviati.

4.3.2 Rilevamento di manomissione dei messaggi (MAC, hash e firme)

Un MAC è un codice (o tag) che risulta dall'utilizzo di una chiave simmetrica (chiamata chiave segreta) o di un messaggio come input per un algoritmo di crittografia MAC. La chiave segreta e l'algoritmo vengono concordati dal mittente e dal destinatario prima del trasferimento del messaggio.

I MAC verificano messaggi come questo.

Il mittente deriva il tag MAC utilizzando la chiave segreta come input per l'algoritmo MAC.
Il mittente invia il tag MAC e il messaggio al destinatario.
Il ricevitore deriva il tag MAC utilizzando la chiave segreta e il messaggio come input per l'algoritmo MAC.
Il destinatario confronta il proprio tag MAC con il tag MAC del mittente. Se sono uguali allora sappiamo che il messaggio non è stato manomesso.

Verifica mac

Le app Windows possono implementare la verifica dei messaggi MAC chiamando la classe MacAlgorithmProvider per generare la chiave e la classe CryptographicEngine per eseguire l'algoritmo di crittografia MAC.

4.3.3 Using hashes

Una funzione hash è un algoritmo crittografico che accetta un blocco di dati arbitrariamente lungo e restituisce una stringa di bit di dimensione fissa denominata valore hash. Esiste un'intera famiglia di funzioni hash che possono farlo.

Un valore hash può essere utilizzato al posto di un MAC nello scenario di trasferimento dei messaggi sopra. Il mittente invia un valore hash e un messaggio e il destinatario deriva il proprio valore hash dal valore hash e dal messaggio del mittente e confronta i due valori hash. Le app in esecuzione in Windows possono chiamare la classe HashAlgorithmProvider per enumerare gli algoritmi hash disponibili ed eseguirne uno. La classe CryptographicHash rappresenta il valore hash. Il metodo CryptographicHash.GetValueAndReset può essere utilizzato per eseguire ripetutamente l'hashing di dati diversi senza dover ricreare l'oggetto per ogni utilizzo. Il metodo Append della classe CryptographicHash aggiunge nuovi dati a un buffer da sottoporre ad hashing. L'intero processo è illustrato nell'esempio di codice C# seguente.

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 Firme digitali

L'integrità dei dati di un messaggio archiviato con firma digitale viene verificata in modo simile all'autenticazione MAC. Ecco come funziona il flusso di lavoro della firma digitale.

Il mittente ricava un valore hash (noto anche come digest) utilizzando il messaggio come input per un algoritmo hash.
Il mittente crittografa il digest utilizzando la propria chiave privata.
Il mittente invia il messaggio, il digest crittografato e il nome dell'algoritmo hash utilizzato.
Il destinatario utilizza la chiave pubblica per decrittografare il digest crittografato ricevuto. Quindi utilizza l'algoritmo hash per eseguire l'hashing del messaggio per creare un proprio digest. E infine il destinatario confronta i due digest (quello ricevuto e decrittografato e quello creato). Solo se i due coincidono il destinatario può essere sicuro che il messaggio è stato inviato dal possessore della chiave privata, e quindi è chi dice di essere, e che il messaggio non è stato alterato durante il transito.

firme digitali

Gli algoritmi di hashing sono molto veloci, quindi i valori hash possono essere ricavati rapidamente anche da messaggi di grandi dimensioni. Il valore hash risultante ha una lunghezza arbitraria e può essere inferiore al messaggio completo, quindi l'utilizzo di chiavi pubbliche e private per crittografare e decrittografare solo il digest anziché il messaggio completo rappresenta un'ottimizzazione.

Per maggiori informazioni, dai un'occhiata agli articoli sulle Firme digitali, MAC, hash e firme, e Crittografiay.

5 Riepilogo

Il piattaforma UWP (Universal Windows Platform) in Windows offre diversi modi per sfruttare le funzionalità del sistema operativo per creare app più sicure. In diversi scenari di autenticazione, come l'autenticazione a fattore singolo, a più fattori o intermediata con un provider di identità OAuth, esistono API per mitigare le sfide più comuni con l'autenticazione. Windows Hello fornisce un nuovo sistema di accesso biometrico che riconosce l'utente e vanifica attivamente i tentativi di eludere la corretta identificazione. Fornisce inoltre più livelli di chiavi e certificati che non possono mai essere rivelati o utilizzati al di fuori del modulo della piattaforma attendibile. Inoltre, è disponibile un ulteriore livello di sicurezza attraverso l'uso opzionale di chiavi di identità e certificati di attestazione.

Per proteggere i dati in volo, esistono API per comunicare con i sistemi remoti in modo sicuro tramite SSL, fornendo al contempo la possibilità di convalidare l’autenticità del server con il blocco SSL. La pubblicazione delle API in modo sicuro e controllato è un aspetto in cui Gestione API di Azure aiuta fornendo potenti opzioni di configurazione per esporre le API sul Web utilizzando un proxy che fornisce ulteriore offuscamento dell'endpoint API. L'accesso a queste API è protetto tramite chiavi API e le chiamate API possono essere limitate per controllare le prestazioni.

Quando i dati arrivano sul dispositivo, il modello di app Windows fornisce un maggiore controllo sul modo in cui l'app viene installata, aggiornata e accede ai dati, impedendogli di accedere ai dati di altre app in modo non autorizzato. La casella di sicurezza delle credenziali può fornire l'archiviazione sicura delle credenziali dell'utente gestita dal sistema operativo e altri dati possono essere protetti sul dispositivo utilizzando le API di crittografia e hashing offerte dalla piattaforma Windows universale.

Condividi tramite