Infrastruttura di sicurezza: sicurezza della comunicazione - Procedure di mitigazione

  • Articolo
Prodotto o servizio Articolo
Hub eventi di Azure
Dynamics CRM
Azure Data Factory
Identity Server
Applicazione Web
Database
Archiviazione di Azure
Client per dispositivi mobili
WCF
API Web
Cache Redis di Azure
Gateway IoT sul campo
Gateway IoT cloud

Proteggere la comunicazione con l'hub eventi con SSL/TLS

Titolo Dettagli
Componente Hub eventi di Azure
Fase SDL Creazione
Tecnologie applicabili Generica
Attributi N/D
Riferimenti Panoramica del modello di sicurezza e autenticazione di Hub eventi
Passaggi Proteggere le connessioni AMQP o HTTP con l'hub eventi usando SSL/TLS

Verificare i privilegi dell'account del servizio e controllare che le pagine ASP.NET o i servizi personalizzati rispettino la sicurezza di CRM

Titolo Dettagli
Componente Dynamics CRM
Fase SDL Creazione
Tecnologie applicabili Generica
Attributi N/D
Riferimenti N/D
Passaggi Verificare i privilegi dell'account del servizio e controllare che le pagine ASP.NET o i servizi personalizzati rispettino la sicurezza di CRM

Usare il gateway di gestione dati durante la connessione di SQL Server locale ad Azure Data Factory

Titolo Dettagli
Componente Azure Data Factory
Fase SDL Distribuzione
Tecnologie applicabili Generica
Attributi Tipi di servizio collegati - Azure e locale
Riferimenti Spostamento di dati tra l'ambiente locale e Azure Data Factory
Passaggi

Lo strumento Gateway di gestione dati è necessario per la connessione a origini dati protette da un firewall o dalla rete aziendale.

  1. Bloccando il computer si isola lo strumento Gateway di gestione dati impedendo a programmi che non funzionano correttamente di danneggiare o analizzare il computer dell'origine dati. Ad esempio, gli aggiornamenti più recenti devono essere installati, abilitare le porte minime necessarie, il provisioning degli account controllati, il controllo abilitato, la crittografia del disco abilitata e così via.
  2. È necessario eseguire la rotazione della chiave del gateway dati a intervalli frequenti o a ogni rinnovo della password dell'account del servizio Gateway di gestione dati.
  3. I transiti di dati attraverso il servizio di collegamento devono essere crittografati.

Verificare che tutto il traffico verso Identity Server venga gestito su connessione HTTPS

Titolo Dettagli
Componente Identity Server
Fase SDL Distribuzione
Tecnologie applicabili Generica
Attributi N/D
Riferimenti IdentityServer3 - Keys, Signatures and Cryptography (IdentityServer3 - Chiavi, firme e crittografia), IdentityServer3 - Deployment (IdentityServer3 - Distribuzione)
Passaggi Per impostazione predefinita, IdentityServer richiede che tutte le connessioni in ingresso vengano effettuate tramite HTTPS. È assolutamente obbligatorio che per la comunicazione con IdentityServer vengano usati esclusivamente trasporti protetti. Esistono alcuni scenari di distribuzione, ad esempio l'offload TLS, in cui questo requisito può essere rilassato. Per altre informazioni, vedere la pagina relativa alla distribuzione di Identity Server indicata nei riferimenti.

Verificare i certificati X.509 usati per autenticare le connessioni SSL, TLS e DTLS

Titolo Dettagli
Componente Applicazione Web
Fase SDL Creazione
Tecnologie applicabili Generica
Attributi N/D
Riferimenti N/D
Passaggi

Le applicazioni che usano SSL, TLS o DTLS devono eseguire una verifica completa dei certificati X.509 delle entità a cui si connettono. Ciò include la verifica dei certificati in relazione a:

  • Nome di dominio
  • Date di validità (date sia di inizio che di scadenza)
  • Stato di revoca
  • Utilizzo (ad esempio, autenticazione server per i server o autenticazione client per i client)
  • Catena di certificati. I certificati devono essere concatenati a un'autorità di certificazione radice (CA) considerata attendibile dalla piattaforma o configurata in modo esplicito dall'amministratore
  • La lunghezza della chiave pubblica del certificato deve essere >di 2048 bit
  • L'algoritmo di hash deve essere SHA256 o versione superiore

Configurare il certificato TLS/SSL per il dominio personalizzato nel servizio app Azure

Titolo Dettagli
Componente Applicazione Web
Fase SDL Creazione
Tecnologie applicabili Generica
Attributi Tipo di ambiente: Azure
Riferimenti Abilitare HTTPS per un'app in Azure App Service
Passaggi Per impostazione predefinita, Azure abilita già HTTPS per ogni app con un certificato con caratteri jolly per il dominio *.azurewebsites.net. Come tutti i domini con caratteri jolly, tuttavia, non è sicuro quanto un dominio personalizzato con un proprio certificato (riferimento). È consigliabile abilitare TLS per il dominio personalizzato a cui verrà eseguito l'accesso all'app distribuita tramite

Forzare tutto il traffico verso il servizio app di Azure su una connessione HTTPS

Titolo Dettagli
Componente Applicazione Web
Fase SDL Creazione
Tecnologie applicabili Generica
Attributi Tipo di ambiente: Azure
Riferimenti Imporre HTTPS nel servizio app di Azure
Passaggi

Nonostante Azure abiliti già HTTPS per i servizi app di Azure con un certificato con caratteri jolly per il dominio *.azurewebsites.net, non impone HTTPS. I visitatori possono comunque accedere all'app usando HTTP e questo potrebbe compromettere la sicurezza dell'app. È quindi necessario imporre HTTPS in modo esplicito. Le applicazioni ASP.NET MVC dovranno usare il filtro RequireHttps che forza il nuovo invio di una richiesta HTTP non protetta su HTTPS.

In alternativa, per imporre HTTPS è possibile usare il modulo URL Rewrite incluso con Servizio app di Azure. Il modulo URL Rewrite consente agli sviluppatori di definire le regole applicate alle richieste in ingresso prima che queste vengano passate all'applicazione. Le regole di URL Rewrite sono definite in un file web.config archiviato nella radice dell'applicazione.

Esempio

L'esempio seguente contiene una regola di base di URL Rewrite che forza l'uso di HTTPS per tutto il traffico in ingresso.

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
  <system.webServer>
    <rewrite>
      <rules>
        <rule name="Force HTTPS" enabled="true">
          <match url="(.*)" ignoreCase="false" />
          <conditions>
            <add input="{HTTPS}" pattern="off" />
          </conditions>
          <action type="Redirect" url="https://{HTTP_HOST}/{R:1}" appendQueryString="true" redirectType="Permanent" />
        </rule>
      </rules>
    </rewrite>
  </system.webServer>
</configuration>

Il funzionamento di questa regola prevede la restituzione di un codice di stato HTTP 301 (reindirizzamento permanente) quando l'utente richiede una pagina mediante HTTP. Il codice 301 reindirizza la richiesta allo stesso URL richiesto dal visitatore, ma sostituisce la parte HTTP della richiesta con HTTPS. Ad esempio, HTTP://contoso.com viene reindirizzato a HTTPS://contoso.com.

Abilitare HTTP Strict Transport Security (HSTS)

Titolo Dettagli
Componente Applicazione Web
Fase SDL Creazione
Tecnologie applicabili Generica
Attributi N/D
Riferimenti Foglio informativo di OWASP su HTTP Strict Transport Security
Passaggi

HTTP Strict Transport Security (HSTS) è un miglioramento della sicurezza con consenso esplicito che viene specificato da un'applicazione Web usando una speciale intestazione della risposta. Quando un browser supportato riceve questa intestazione, impedisce l'invio tramite HTTP di qualsiasi comunicazione al dominio specificato e invia tutte le comunicazioni tramite HTTPS. Impedisce anche i messaggi di richiesta con click-through HTTPS nei browser.

Per implementare HSTS, è necessario configurare l'intestazione di risposta seguente per un sito Web a livello globale, nel codice o nella configurazione. Strict-Transport-Security: max-age=300; includeSubDomains HSTS risolve le minacce seguenti:

  • L'utente imposta come segnalibro o digita manualmente https://example.com ed è soggetto a un attacco man-in-the-middle: HSTS reindirizza automaticamente le richieste HTTP a HTTPS per il dominio di destinazione
  • Un'applicazione Web che dovrebbe essere esclusivamente HTTPS inavvertitamente contiene collegamenti HTTP o fornisce contenuti tramite HTTP: HSTS reindirizza automaticamente le richieste HTTP a HTTPS per il dominio di destinazione
  • Un utente malintenzionato tenta con un attacco man-in-the-middle di intercettare il traffico da un utente vittima con un certificato non valido sperando che l'utente accetti tale certificato: HSTS non consente a un utente di eseguire l'override del messaggio di certificato non valido

Verificare la crittografia della connessione e la convalida dei certificati di SQL Server

Titolo Dettagli
Componente Database
Fase SDL Creazione
Tecnologie applicabili SQL Azure
Attributi Versione SQL: 12
Riferimenti Best Practices on Writing Secure Connection Strings for SQL Database (Procedure consigliate per la scrittura di stringhe di connessione sicure per il database SQL)
Passaggi

Tutte le comunicazioni tra database SQL e un'applicazione client vengono crittografate con Transport Layer Security (TLS), noto in precedenza come Secure Sockets Layer (SSL) in qualsiasi momento. database SQL non supporta connessioni non crittografate. Per convalidare i certificati con gli strumenti o il codice dell'applicazione, richiedere una connessione crittografata in modo esplicito e non considerare attendibili i certificati del server. Se il codice dell'applicazione o gli strumenti non richiedono una connessione crittografata, riceveranno comunque connessioni crittografate.

Tuttavia, potrebbero non convalidare i certificati del server e pertanto saranno soggetti ad attacchi "man in the middle". Per convalidare i certificati con il codice dell'applicazione ADO.NET, impostare Encrypt=True e TrustServerCertificate=False nella stringa di connessione del database. Per convalidare i certificati tramite SQL Server Management Studio, aprire la finestra di dialogo Connetti al server. Fare clic su Crittografa connessione nella scheda Proprietà connessione.

Forzare la comunicazione crittografata con SQL Server

Titolo Dettagli
Componente Database
Fase SDL Creazione
Tecnologie applicabili Locale
Attributi Versione SQL: MsSQL2016, MsSQL2012, MsSQL2014
Riferimenti Abilitare le connessioni crittografate nel motore di database
Passaggi Abilitando la crittografia TLS è possibile aumentare la sicurezza dei dati trasmessi nelle reti tra le istanze di SQL Server e le applicazioni.

Verificare che per la comunicazione con Archiviazione di Azure venga usato HTTPS

Titolo Dettagli
Componente Archiviazione di Azure
Fase SDL Distribuzione
Tecnologie applicabili Generica
Attributi N/D
Riferimenti Crittografia a livello di trasporto in Archiviazione di Azure: uso di HTTPS
Passaggi Per garantire la sicurezza dei dati di Archiviazione di Azure in transito, quando si chiamano le API REST o si accede a oggetti nelle risorse di archiviazione usare sempre il protocollo HTTPS. Le firme di accesso condiviso, che possono essere usate per delegare l'accesso a oggetti di Archiviazione di Azure, includono la possibilità di specificare che quando si usano firme di accesso condiviso può essere usato solo il protocollo HTTPS, in modo da garantire che chiunque invii collegamenti con token di firma di accesso condiviso usi il protocollo corretto.

Convalidare l'hash MD5 dopo il download di BLOB se non è possibile abilitare HTTPS

Titolo Dettagli
Componente Archiviazione di Azure
Fase SDL Creazione
Tecnologie applicabili Generica
Attributi Tipo di archiviazione: BLOB
Riferimenti Windows Azure Blob MD5 Overview (Panoramica di MD5 nel servizio BLOB di Microsoft Azure)
Passaggi

Il servizio BLOB di Microsoft Azure offre meccanismi per garantire l'integrità dei dati sia al livello dell'applicazione che al livello trasporto. Se per qualsiasi motivo è necessario usare HTTP anziché HTTPS e si usano BLOB in blocchi, è possibile usare il controllo MD5 per verificare l'integrità dei BLOB in fase di trasferimento.

Ciò contribuisce a proteggere dagli errori a livello di rete/trasporto, ma non necessariamente dalle violazioni. Se è possibile utilizzare HTTPS, che fornisce la protezione a livello di trasporto, il controllo MD5 è ridondante e superfluo.

Usare il client compatibile con SMB 3.x per garantire la crittografia dei dati in transito nelle condivisioni file di Azure

Titolo Dettagli
Componente Client per dispositivi mobili
Fase SDL Creazione
Tecnologie applicabili Generica
Attributi Tipo di archiviazione: file
Riferimenti File di Azure, supporto SMB File di Azure per i client Windows
Passaggi Il servizio File di Azure supporta HTTPS quando si usa l'API REST, ma è più comunemente usato come una condivisione file SMB collegata a una VM. SMB 2.1 non supporta la crittografia, quindi le connessioni sono consentite solo all'interno della stessa area in Azure. Tuttavia, SMB 3.x supporta la crittografia e può essere usato con Windows Server 2012 R2, Windows 8, Windows 8.1 e Windows 10, consentendo l'accesso tra aree e persino l'accesso sul desktop.

Implementare l'associazione del certificato

Titolo Dettagli
Componente Archiviazione di Azure
Fase SDL Creazione
Tecnologie applicabili Generico, Windows Phone
Attributi N/D
Riferimenti Associazione del certificato e della chiave pubblica
Passaggi

L'associazione del certificato protegge da attacchi man-in-the-middle. L'associazione è il processo con cui un host viene associato alla chiave pubblica o al certificato X509 previsto. Quando per un host è noto o visibile un certificato o una chiave pubblica, questo viene associato all'host.

Pertanto, quando un avversario tenta di eseguire un attacco TLS MITM, durante l'handshake TLS la chiave dal server dell'utente malintenzionato sarà diversa dalla chiave del certificato aggiunto e la richiesta verrà eliminata, impedendo così l'aggiunta del certificato MITM può essere ottenuta implementando il delegato di ServerCertificateValidationCallback ServicePointManager.

Esempio

using System;
using System.Net;
using System.Net.Security;
using System.Security.Cryptography;

namespace CertificatePinningExample
{
    class CertificatePinningExample
    {
        /* Note: In this example, we're hardcoding the certificate's public key and algorithm for 
           demonstration purposes. In a real-world application, this should be stored in a secure
           configuration area that can be updated as needed. */

        private static readonly string PINNED_ALGORITHM = "RSA";

        private static readonly string PINNED_PUBLIC_KEY = "3082010A0282010100B0E75B7CBE56D31658EF79B3A1" +
            "294D506A88DFCDD603F6EF15E7F5BCBDF32291EC50B2B82BA158E905FE6A83EE044A48258B07FAC3D6356AF09B2" +
            "3EDAB15D00507B70DB08DB9A20C7D1201417B3071A346D663A241061C151B6EC5B5B4ECCCDCDBEA24F051962809" +
            "FEC499BF2D093C06E3BDA7D0BB83CDC1C2C6660B8ECB2EA30A685ADE2DC83C88314010FFC7F4F0F895EDDBE5C02" +
            "ABF78E50B708E0A0EB984A9AA536BCE61A0C31DB95425C6FEE5A564B158EE7C4F0693C439AE010EF83CA8155750" +
            "09B17537C29F86071E5DD8CA50EBD8A409494F479B07574D83EDCE6F68A8F7D40447471D05BC3F5EAD7862FA748" +
            "EA3C92A60A128344B1CEF7A0B0D94E50203010001";


        public static void Main(string[] args)
        {
            HttpWebRequest request = (HttpWebRequest)WebRequest.Create("https://azure.microsoft.com");
            request.ServerCertificateValidationCallback = (sender, certificate, chain, sslPolicyErrors) =>
            {
                if (certificate == null || sslPolicyErrors != SslPolicyErrors.None)
                {
                    // Error getting certificate or the certificate failed basic validation
                    return false;
                }

                var targetKeyAlgorithm = new Oid(certificate.GetKeyAlgorithm()).FriendlyName;
                var targetPublicKey = certificate.GetPublicKeyString();
                
                if (targetKeyAlgorithm == PINNED_ALGORITHM &&
                    targetPublicKey == PINNED_PUBLIC_KEY)
                {
                    // Success, the certificate matches the pinned value.
                    return true;
                }
                // Reject, either the key or the algorithm does not match the expected value.
                return false;
            };

            try
            {
                var response = (HttpWebResponse)request.GetResponse();
                Console.WriteLine($"Success, HTTP status code: {response.StatusCode}");
            }
            catch(Exception ex)
            {
                Console.WriteLine($"Failure, {ex.Message}");
            }
            Console.WriteLine("Press any key to end.");
            Console.ReadKey();
        }
    }
}

Abilitare HTTPS: canale di trasporto sicuro

Titolo Dettagli
Componente WCF
Fase SDL Creazione
Tecnologie applicabili .NET Framework 3
Attributi N/D
Riferimenti MSDN, Fortify Kingdom
Passaggi La configurazione dell'applicazione deve garantire l'uso di HTTPS per tutti gli accessi a informazioni riservate.
  • SPIEGAZIONE: se un'applicazione che gestisce informazioni riservate non usa la crittografia a livello di messaggio, all'applicazione deve essere consentita la comunicazione solo tramite un canale di trasporto crittografato.
  • RACCOMANDAZIONI: verificare che il trasporto HTTP sia disabilitato e abilitare invece il trasporto HTTPS. Ad esempio, sostituire il tag <httpTransport/> con il tag <httpsTransport/>. Non basarsi su una configurazione di rete (firewall) per garantire che l'applicazione sia accessibile solo tramite un canale sicuro. Da un punto di vista teorico, l'applicazione non deve dipendere dalla rete per la sicurezza.

Da un punto di vista pratico, le persone responsabili della protezione della rete non sempre tengono traccia dell'evoluzione dei requisiti di sicurezza dell'applicazione.

WCF: impostare il livello di protezione per la sicurezza dei messaggi su EncryptAndSign

Titolo Dettagli
Componente WCF
Fase SDL Creazione
Tecnologie applicabili .NET Framework 3
Attributi N/D
Riferimenti MSDN
Passaggi
  • SPIEGAZIONE: quando il livello di protezione è impostato su "None", la protezione dei messaggi verrà disabilitata. La riservatezza e l'integrità si ottengono con il livello di impostazione appropriato.
  • RACCOMANDAZIONI:
    • Quando Mode=None, la protezione dei messaggi è disabilitata
    • Quando Mode=Sign, il messaggio viene firmato ma non crittografato. Questa impostazione deve essere usata quando è importante l'integrità dei dati
    • Quando Mode=EncryptAndSign, il messaggio viene firmato e crittografato

Quando è sufficiente convalidare l'integrità delle informazioni senza problemi di riservatezza, valutare la possibilità di disattivare la crittografia e limitarsi alla firma del messaggio. Questo può risultare utile per contratti di operazione o di servizio in cui è necessario convalidare il mittente originale ma non vengono trasmessi dati sensibili. Quando si riduce il livello di protezione, prestare attenzione che il messaggio non contenga dati personali.

Esempio

Gli esempi seguenti illustrano la configurazione del servizio e dell'operazione per la sola firma del messaggio. Esempio di contratto di servizio con ProtectionLevel.Sign: di seguito è riportato un esempio dell'uso di ProtectionLevel.Sign a livello di contratto di servizio.

[ServiceContract(Protection Level=ProtectionLevel.Sign] 
public interface IService 
  { 
  string GetData(int value); 
  }

Esempio

Esempio di contratto di operazione con ProtectionLevel.Sign (per un controllo granulare): di seguito è riportato un esempio dell'uso di ProtectionLevel.Sign a livello di contratto di operazione.

[OperationContract(ProtectionLevel=ProtectionLevel.Sign] 
string GetData(int value);

WCF: usare un account con privilegi minimi per eseguire il servizio WCF

Titolo Dettagli
Componente WCF
Fase SDL Creazione
Tecnologie applicabili .NET Framework 3
Attributi N/D
Riferimenti MSDN
Passaggi
  • SPIEGAZIONE: non eseguire i servizi WCF con un account amministratore o con privilegi elevati, che comporterebbe un alto impatto in caso di compromissione dei servizi.
  • RACCOMANDAZIONI: per ospitare il servizio WCF usare un account con privilegi minimi, in modo da ridurre la superficie di attacco dell'applicazione e il potenziale danno in caso di attacco. Se l'account del servizio richiede diritti di accesso aggiuntivi per risorse dell'infrastruttura come MSMQ, il registro eventi, i contatori delle prestazioni e il file system, è necessario concedere autorizzazioni appropriate a tali risorse in modo da consentire la corretta esecuzione del servizio WCF.

Se il servizio deve accedere a risorse specifiche per conto del chiamante originale, usare la rappresentazione e la delega per trasferire l'identità del chiamante per un controllo di autorizzazione downstream. In uno scenario di sviluppo, usare l'account del servizio di rete locale, ovvero un account predefinito speciale con privilegi ridotti. In uno scenario di produzione, creare un account di servizio del dominio personalizzato con privilegi minimi.

Forzare tutto il traffico verso le API Web su una connessione HTTPS

Titolo Dettagli
Componente API Web
Fase SDL Creazione
Tecnologie applicabili MVC 5, MVC 6
Attributi N/D
Riferimenti Imporre SSL in un controller di API Web
Passaggi Se un'applicazione include sia un'associazione HTTPS che un'associazione HTTP, i client possono comunque usare HTTP per accedere al sito. Per impedirlo, usare un filtro azioni per garantire che per le richieste per le API protette venga sempre usato HTTPS.

Esempio

Il codice seguente mostra un filtro di autenticazione api Web che verifica la presenza di TLS:

public class RequireHttpsAttribute : AuthorizationFilterAttribute
{
    public override void OnAuthorization(HttpActionContext actionContext)
    {
        if (actionContext.Request.RequestUri.Scheme != Uri.UriSchemeHttps)
        {
            actionContext.Response = new HttpResponseMessage(System.Net.HttpStatusCode.Forbidden)
            {
                ReasonPhrase = "HTTPS Required"
            };
        }
        else
        {
            base.OnAuthorization(actionContext);
        }
    }
}

Aggiungere questo filtro a tutte le azioni dell'API Web che richiedono TLS:

public class ValuesController : ApiController
{
    [RequireHttps]
    public HttpResponseMessage Get() { ... }
}

Assicurarsi che la comunicazione con cache di Azure per Redis sia tramite TLS

Titolo Dettagli
Componente Cache Redis di Azure
Fase SDL Creazione
Tecnologie applicabili Generica
Attributi N/D
Riferimenti Supporto TLS di Azure Redis
Passaggi Il server Redis non supporta TLS predefinito, ma cache di Azure per Redis lo fa. Se ci si connette a Cache Redis di Azure e il client supporta TLS, ad esempio StackExchange.Redis, è consigliabile usare TLS. Per impostazione predefinita, la porta non TLS è disabilitata per le nuove istanze di cache di Azure per Redis. Assicurarsi che le impostazioni predefinite sicure non vengano modificate a meno che non esista una dipendenza dal supporto TLS per i client Redis.

Si noti che Redis è progettato per essere accessibile da client attendibili all'interno di ambienti attendibili. Di conseguenza, non è solitamente opportuno esporre l'istanza di Redis direttamente a Internet o, in generale, a un ambiente in cui client non attendibili possono accedere direttamente al socket UNIX o alla porta TCP di Redis.

Proteggere la comunicazione da dispositivo a gateway sul campo

Titolo Dettagli
Componente Gateway IoT sul campo
Fase SDL Creazione
Tecnologie applicabili Generica
Attributi N/D
Riferimenti N/D
Passaggi Per i dispositivi basati su IP, il protocollo di comunicazione può in genere essere incapsulato in un canale SSL/TLS per proteggere i dati in transito. Per altri protocolli che non supportano SSL/TLS, verificare se sono disponibili versioni sicure del protocollo che offrono sicurezza a livello di trasporto o di messaggio.

Proteggere la comunicazione da dispositivo a gateway nel cloud con SSL/TLS

Titolo Dettagli
Componente Gateway IoT cloud
Fase SDL Creazione
Tecnologie applicabili Generica
Attributi N/D
Riferimenti Scegliere il protocollo di comunicazione
Passaggi Proteggere i protocolli HTTP/AMQP e MQTT con SSL/TLS.