Infrastruttura di sicurezza: sicurezza della comunicazione - Procedure di mitigazione

Prodotto o servizio Articolo
Hub eventi di Azure
Dynamics CRM
Data factory di Azure
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 Compilare
Tecnologie applicabili Generico
Attributi N/D
Riferimenti Panoramica del modello di sicurezza e autenticazione di Hub eventi
Passi 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 Compilare
Tecnologie applicabili Generico
Attributi N/D
Riferimenti N/D
Passi 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 nella connessione dell'istanza locale di SQL Server ad Azure Data Factory

Titolo Dettagli
Componente Data factory di Azure
Fase SDL Distribuzione
Tecnologie applicabili Generico
Attributi Tipi di servizio collegato: locale e Azure
Riferimenti Spostamento di dati tra origini locali e Azure Data Factory, Gateway di gestione dati
Passi

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, in caso di installazione degli ultimi aggiornamenti, abilitazione delle porte necessarie minime, provisioning degli account controllati, abilitazione del controllo e della crittografia dei dischi 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 Generico
Attributi N/D
Riferimenti IdentityServer3 - Keys, Signatures and Cryptography (IdentityServer3 - Chiavi, firme e crittografia), IdentityServer3 - Deployment (IdentityServer3 - Distribuzione)
Passi 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. In alcuni scenari di distribuzione, come l'offload SSL, questo requisito può essere meno rigido. 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 Compilare
Tecnologie applicabili Generico
Attributi N/D
Riferimenti N/D
Passi

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 superiore a 2048 bit
  • L'algoritmo di hash deve essere SHA256 o versione superiore

Configurare il certificato SSL per un dominio personalizzato nel servizio app di Azure

Titolo Dettagli
Componente Applicazione Web.
Fase SDL Compilare
Tecnologie applicabili Generico
Attributi Tipo di ambiente: Azure
Riferimenti Abilitare HTTPS per un'app in Azure App Service
Passi 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 SSL per il dominio personalizzato tramite il quale si accederà all'app distribuita.

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

Titolo Dettagli
Componente Applicazione Web.
Fase SDL Compilare
Tecnologie applicabili Generico
Attributi Tipo di ambiente: Azure
Riferimenti [Abilitare HTTPS nel servizio app di Azure]https://azure.microsoft.com/documentation/articles/web-sites-configure-ssl-certificate/#4-enforce-https-on-your-app)
Passi

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 Compilare
Tecnologie applicabili Generico
Attributi N/D
Riferimenti Foglio informativo di OWASP su HTTP Strict Transport Security
Passi

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 della risposta seguente per un sito Web a livello globale, nel codice o nella configurazione. Strict-Transport-Security: max-age=300; includeSubDomains. HSTS gestisce le minacce seguenti.

  • L'utente imposta come segnalibro o digita manualmente http://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 Compilare
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)
Passi

Tutte le comunicazioni tra il database SQL e un'applicazione client vengono crittografate usando sempre Secure Sockets Layer (SSL). Il 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 Compilare
Tecnologie applicabili Locale
Attributi Versione SQL: MsSQL2016, MsSQL2012, MsSQL2014
Riferimenti Abilitare le connessioni crittografate al motore di database
Passi Abilitando la crittografia SSL aumenta la sicurezza dei dati trasmessi sulle 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 Generico
Attributi N/D
Riferimenti Crittografia a livello di trasporto in Archiviazione di Azure: uso di HTTPS
Passi 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 Compilare
Tecnologie applicabili Generico
Attributi Tipo di archiviazione: BLOB
Riferimenti Windows Azure Blob MD5 Overview (Panoramica di MD5 nel servizio BLOB di Microsoft Azure)
Passi

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 un client compatibile con SMB 3.0 per garantire la crittografia dei dati in transito per le condivisioni file di Azure

Titolo Dettagli
Componente Client per dispositivi mobili
Fase SDL Compilare
Tecnologie applicabili Generico
Attributi Tipo di archiviazione: file
Riferimenti Archiviazione file di Azure, Come montare una condivisione file di Azure in Windows
Passi Il servizio di archiviazione 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.0 supporta la crittografia e può essere usato con Windows Server 2016, Windows Server 2012 R2, Windows 8.1 e Windows 10, consentendo l'accesso tra aree e anche l'accesso sul desktop.

Implementare l'associazione del certificato

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

L'associazione del certificato protegge da attacchi man-in-the-middle basati su TLS. L'associazione è il processo con cui una connessione TLS viene associata a una chiave pubblica o a un certificato X.509 previsto. Questa associazione può essere eseguita dopo la prima connessione riuscita ("attendibilità al primo utilizzo") o prima di questa connessione e in questo caso è richiesto il pre-caricamento.

Quando un antagonista tenta di eseguire un attacco man-in-the-middle TLS, il client verificherà che la chiave o il certificato ricevuti corrispondano al valore previsto. Di conseguenza, anche se l'antagonista ha un altro certificato valido e attendibile, la connessione avrà comunque esito negativo.

L'associazione del certificato può essere implementata in .NET tramite il delegato HttpWebRequest.ServerCertificateValidationCallback (scelta preferita) o ServicePointManager.ServerCertificateValidationCallback. Nell'esempio seguente, la convalida viene eseguita in base a una chiave pubblica hardcoded e a un algoritmo, ma in un'applicazione reale, tali valori devono essere archiviati in un'area di configurazione sicura ed essere aggiornati in base alle esigenze.

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 a 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 Compilare
Tecnologie applicabili .NET Framework 3
Attributi N/D
Riferimenti MSDN, Fortify Kingdom
Passi 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 Compilare
Tecnologie applicabili .NET Framework 3
Attributi N/D
Riferimenti MSDN
Passi
  • 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, assicurarsi che il messaggio non contenga informazioni 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 Compilare
Tecnologie applicabili .NET Framework 3
Attributi N/D
Riferimenti MSDN
Passi
  • 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 Compilare
Tecnologie applicabili MVC 5, MVC 6
Attributi N/D
Riferimenti Imporre SSL in un controller di API Web
Passi 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 illustra un filtro di autenticazione di API Web che verifica la presenza di SSL:

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 di API Web che richiedono SSL:

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

Verificare che per la comunicazione con Cache Redis di Azure venga usato SSL

Titolo Dettagli
Componente Cache Redis di Azure
Fase SDL Compilare
Tecnologie applicabili Generico
Attributi N/D
Riferimenti Supporto per SSL in Redis di Azure
Passi Il server Redis non offre il supporto predefinito per SSL, ma tale supporto è disponibile nella Cache Redis di Azure. Se ci si connette alla Cache Redis di Azure e il client supporta SSL, ad esempio StackExchange.Redis, è consigliabile usare SSL. Per impostazione predefinita, la porta non SSL è disabilitata per le nuove istanze di Cache Redis di Azure. Verificare che le impostazioni predefinite sicure non vengano modificate a meno che non esista una dipendenza dei client Redis dal supporto per SSL.

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 Compilare
Tecnologie applicabili Generico
Attributi N/D
Riferimenti N/D
Passi 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 Compilare
Tecnologie applicabili Generico
Attributi N/D
Riferimenti Scegliere il protocollo di comunicazione
Passi Proteggere i protocolli HTTP/AMQP e MQTT con SSL/TLS.