Infrastruttura di sicurezza: sicurezza della comunicazione - Procedure di mitigazione

Prodotto o servizio	Articolo
Hub eventi di Azure	Proteggere la comunicazione con l'hub eventi con SSL/TLS
Dynamics CRM	Verificare i privilegi dell'account del servizio e controllare che le pagine ASP.NET o i servizi personalizzati rispettino la sicurezza di CRM
Azure Data Factory	Usare il gateway di gestione dati durante la connessione di SQL Server locale ad Azure Data Factory
Identity Server	Verificare che tutto il traffico verso Identity Server venga gestito su connessione HTTPS
Applicazione Web	Verificare i certificati X.509 usati per autenticare le connessioni SSL, TLS e DTLS Configurare il certificato TLS/SSL per il dominio personalizzato nel servizio app Azure Forzare tutto il traffico verso il servizio app di Azure su una connessione HTTPS Abilitare HTTP Strict Transport Security (HSTS)
Database	Verificare la crittografia della connessione e la convalida dei certificati di SQL Server Forzare la comunicazione crittografata con SQL Server
Archiviazione di Azure	Verificare che per la comunicazione con Archiviazione di Azure venga usato HTTPS Convalidare l'hash MD5 dopo il download di BLOB se non è possibile abilitare HTTPS Usare un client compatibile con SMB 3.0 per garantire la crittografia dei dati in transito per condivisioni file di Azure
Client per dispositivi mobili	Implementare l'associazione del certificato
WCF	Abilitare HTTPS: canale di trasporto sicuro WCF: impostare il livello di protezione per la sicurezza dei messaggi su EncryptAndSign WCF: usare un account con privilegi minimi per eseguire il servizio WCF
API Web	Forzare tutto il traffico verso le API Web su una connessione HTTPS
Cache Redis di Azure	Assicurarsi che la comunicazione con cache di Azure per Redis sia tramite TLS
Gateway IoT sul campo	Proteggere la comunicazione da dispositivo a gateway sul campo
Gateway IoT cloud	Proteggere la comunicazione da dispositivo a gateway nel cloud con SSL/TLS

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. 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. È 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. 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.