Quadro de Segurança: Segurança da Comunicação | Atenuações

Produto/Serviço	Artigo
Hub de Eventos do Azure	Comunicação segura com o Hub de Eventos usando SSL/TLS
Dynamics CRM	Verifique os privilégios da conta de serviço e verifique se os Serviços personalizados ou as Páginas de ASP.NET respeitam a segurança do CRM
Fábrica de Dados do Azure	Usar o gateway de gerenciamento de dados ao conectar o SQL Server local ao Azure Data Factory
Servidor de identidade	Certifique-se de que todo o tráfego para o Identity Server está através de conexão HTTPS
Aplicação Web	Verificar certificados X.509 usados para autenticar conexões SSL, TLS e DTLS Configurar o certificado TLS/SSL para domínio personalizado no Serviço de Aplicativo do Azure Forçar todo o tráfego para o Serviço de Aplicativo do Azure pela conexão HTTPS Habilitar HSTS (HTTP Strict Transport Security)
Base de dados	Garantir a criptografia de conexão do SQL Server e a validação do certificado Forçar comunicação criptografada para o servidor SQL
Armazenamento do Azure	Verifique se a comunicação com o Armazenamento do Azure é feita por HTTPS Valide o hash MD5 após o download do blob se o HTTPS não puder ser habilitado Use o cliente compatível com SMB 3.0 para garantir a criptografia de dados em trânsito para Compartilhamentos de Arquivos do Azure
Cliente Móvel	Implementar fixação de certificado
WCF	Ativar HTTPS - Canal de Transporte Seguro WCF: Definir o nível de proteção de segurança de mensagem para EncryptAndSign WCF: Use uma conta menos privilegiada para executar seu serviço WCF
API Web	Forçar todo o tráfego para APIs da Web através da conexão HTTPS
Cache do Azure para Redis	Verifique se a comunicação com o Cache Redis do Azure é feita por TLS
Gateway de campo IoT	Comunicação segura de dispositivo para gateway de campo
Gateway de nuvem IoT	Comunicação segura de dispositivo para gateway de nuvem usando SSL/TLS

Comunicação segura com o Hub de Eventos usando SSL/TLS

Título	Detalhes
Componente	Hub de Eventos do Azure
Fase SDL	Criar
Tecnologias aplicáveis	Genérico
Atributos	N/A
Referências	Visão geral do modelo de autenticação e segurança dos Hubs de Eventos
Passos	Proteja conexões AMQP ou HTTP para o Hub de Eventos usando SSL/TLS

Verifique os privilégios da conta de serviço e verifique se os Serviços personalizados ou as Páginas de ASP.NET respeitam a segurança do CRM

Título	Detalhes
Componente	Dynamics CRM
Fase SDL	Criar
Tecnologias aplicáveis	Genérico
Atributos	N/A
Referências	N/A
Passos	Verifique os privilégios da conta de serviço e verifique se os Serviços personalizados ou as Páginas de ASP.NET respeitam a segurança do CRM

Usar o gateway de gerenciamento de dados ao conectar o SQL Server local ao Azure Data Factory

Título	Detalhes
Componente	Azure Data Factory
Fase SDL	Implementação
Tecnologias aplicáveis	Genérico
Atributos	Tipos de serviço vinculados - Azure e local
Referências	Movendo dados entre o Local e o Azure Data Factory
Passos	A ferramenta Data Management Gateway (DMG) é necessária para se conectar a fontes de dados protegidas por corpnet ou firewall. Bloquear a máquina isola a ferramenta DMG e evita que programas com mau funcionamento danifiquem ou bisbilhotem a máquina de fonte de dados. (Por exemplo, as atualizações mais recentes devem ser instaladas, habilitar portas mínimas necessárias, provisionamento de contas controladas, auditoria habilitada, criptografia de disco habilitada, etc.) A chave do Data Gateway deve ser girada em intervalos frequentes ou sempre que a senha da conta de serviço DMG for renovada Os trânsitos de dados através do Serviço Link devem ser criptografados

Certifique-se de que todo o tráfego para o Identity Server está através de conexão HTTPS

Título	Detalhes
Componente	Servidor de identidade
Fase SDL	Implementação
Tecnologias aplicáveis	Genérico
Atributos	N/A
Referências	IdentityServer3 - Chaves, Assinaturas e Criptografia, IdentityServer3 - Implantação
Passos	Por padrão, o IdentityServer requer que todas as conexões de entrada sejam fornecidas por HTTPS. É absolutamente obrigatório que a comunicação com o IdentityServer seja feita apenas através de transportes seguros. Há certos cenários de implantação, como o descarregamento de TLS, em que esse requisito pode ser relaxado. Consulte a página de implantação do Identity Server nas referências para obter mais informações.

Verificar certificados X.509 usados para autenticar conexões SSL, TLS e DTLS

Título	Detalhes
Componente	Aplicação Web
Fase SDL	Criar
Tecnologias aplicáveis	Genérico
Atributos	N/A
Referências	N/A
Passos	Os aplicativos que usam SSL, TLS ou DTLS devem verificar completamente os certificados X.509 das entidades às quais se conectam. Tal inclui a verificação dos certificados para: Nome de domínio Datas de validade (datas de início e de validade) Estado de revogação Uso (por exemplo, Autenticação de servidor para servidores, Autenticação de cliente para clientes) Cadeia de confiança. Os certificados devem ser encadeados a uma autoridade de certificação (CA) raiz confiável pela plataforma ou configurada explicitamente pelo administrador O comprimento da chave pública do certificado deve ser >de 2048 bits O algoritmo de hash deve ser SHA256 e superior

Configurar o certificado TLS/SSL para domínio personalizado no Serviço de Aplicativo do Azure

Título	Detalhes
Componente	Aplicação Web
Fase SDL	Criar
Tecnologias aplicáveis	Genérico
Atributos	EnvironmentType - Azure
Referências	Habilitar HTTPS para um aplicativo no Serviço de Aplicativo do Azure
Passos	Por padrão, o Azure já habilita HTTPS para cada aplicativo com um certificado curinga para o domínio *.azurewebsites.net. No entanto, como todos os domínios curinga, não é tão seguro quanto usar um domínio personalizado com a própria referência de certificado. É recomendável habilitar o TLS para o domínio personalizado pelo qual o aplicativo implantado será acessado

Forçar todo o tráfego para o Serviço de Aplicativo do Azure pela conexão HTTPS

Título	Detalhes
Componente	Aplicação Web
Fase SDL	Criar
Tecnologias aplicáveis	Genérico
Atributos	EnvironmentType - Azure
Referências	Impor HTTPS no Serviço de Aplicativo do Azure
Passos	Embora o Azure já habilite HTTPS para serviços de aplicativo do Azure com um certificado curinga para o domínio *.azurewebsites.net, ele não impõe HTTPS. Os visitantes ainda podem acessar o aplicativo usando HTTP, o que pode comprometer a segurança do aplicativo e, portanto, o HTTPS tem que ser aplicado explicitamente. ASP.NET aplicativos MVC devem usar o filtro RequireHttps que força uma solicitação HTTP não segura a ser reenviada por HTTPS. Como alternativa, o módulo Reconfiguração de URL, incluído no Serviço de Aplicativo do Azure, pode ser usado para impor HTTPS. O módulo Regravação de URL permite que os desenvolvedores definam regras que são aplicadas às solicitações de entrada antes que as solicitações sejam entregues ao seu aplicativo. As regras de reconfiguração de URL são definidas em um arquivo web.config armazenado na raiz do aplicativo

Exemplo

O exemplo a seguir contém uma regra básica de reconfiguração de URL que força todo o tráfego de entrada a usar HTTPS

<?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>

Esta regra funciona retornando um código de status HTTP de 301 (redirecionamento permanente) quando o usuário solicita uma página usando HTTP. O 301 redireciona a solicitação para a mesma URL solicitada pelo visitante, mas substitui a parte HTTP da solicitação por HTTPS. Por exemplo, HTTP://contoso.com seria redirecionado para HTTPS://contoso.com.

Habilitar HSTS (HTTP Strict Transport Security)

Título	Detalhes
Componente	Aplicação Web
Fase SDL	Criar
Tecnologias aplicáveis	Genérico
Atributos	N/A
Referências	OWASP HTTP Estrito Segurança de Transporte Cheat Sheet
Passos	HSTS (HTTP Strict Transport Security) é um aprimoramento de segurança opcional especificado por um aplicativo Web por meio do uso de um cabeçalho de resposta especial. Assim que um navegador suportado receber esse cabeçalho, esse navegador impedirá que quaisquer comunicações sejam enviadas por HTTP para o domínio especificado e, em vez disso, enviará todas as comunicações por HTTPS. Também impede que HTTPS clique em prompts em navegadores. Para implementar o HSTS, o cabeçalho de resposta a seguir deve ser configurado para um site globalmente, seja em código ou em configuração. Estrita-Transporte-Segurança: max-age=300; includeSubDomains HSTS aborda as seguintes ameaças: O usuário marca ou digita https://example.com manualmente e está sujeito a um invasor man-in-the-middle: o HSTS redireciona automaticamente as solicitações HTTP para HTTPS para o domínio de destino O aplicativo Web que se destina a ser puramente HTTPS inadvertidamente contém links HTTP ou serve conteúdo sobre HTTP: HSTS redireciona automaticamente solicitações HTTP para HTTPS para o domínio de destino Um invasor man-in-the-middle tenta intercetar o tráfego de um usuário vítima usando um certificado inválido e espera que o usuário aceite o certificado inválido: o HSTS não permite que um usuário substitua a mensagem de certificado inválido

Garantir a criptografia de conexão do SQL Server e a validação do certificado

Título	Detalhes
Componente	Base de dados
Fase SDL	Criar
Tecnologias aplicáveis	SQL Azure
Atributos	Versão SQL - V12
Referências	Práticas recomendadas para escrever cadeias de conexão seguras para o Banco de dados SQL
Passos	Todas as comunicações entre o Banco de dados SQL e um aplicativo cliente são criptografadas usando Transport Layer Security (TLS), anteriormente conhecido como Secure Sockets Layer (SSL), em todos os momentos. O Banco de dados SQL não oferece suporte a conexões não criptografadas. Para validar certificados com código de aplicativo ou ferramentas, solicite explicitamente uma conexão criptografada e não confie nos certificados do servidor. Se o código ou as ferramentas do aplicativo não solicitarem uma conexão criptografada, eles ainda receberão conexões criptografadas No entanto, eles podem não validar os certificados do servidor e, portanto, serão suscetíveis a ataques "man in the middle". Para validar certificados com ADO.NET código de aplicativo, defina Encrypt=True e TrustServerCertificate=False na cadeia de conexão do banco de dados. Para validar certificados por meio do SQL Server Management Studio, abra a caixa de diálogo Conectar ao Servidor. Clique em Criptografar conexão na guia Propriedades da conexão

Forçar comunicação criptografada para o servidor SQL

Título	Detalhes
Componente	Base de dados
Fase SDL	Criar
Tecnologias aplicáveis	OnPrem
Atributos	Versão SQL - MsSQL2016, Versão SQL - MsSQL2012, Versão SQL - MsSQL2014
Referências	Ativar as Ligações Encriptadas para o Motor de Base de Dados
Passos	Habilitar a criptografia TLS aumenta a segurança dos dados transmitidos entre redes entre instâncias do SQL Server e aplicativos.

Verifique se a comunicação com o Armazenamento do Azure é feita por HTTPS

Título	Detalhes
Componente	Armazenamento do Azure
Fase SDL	Implementação
Tecnologias aplicáveis	Genérico
Atributos	N/A
Referências	Criptografia no Nível de Transporte do Armazenamento do Azure – Usando HTTPS
Passos	Para garantir a segurança dos dados do Armazenamento do Azure em trânsito, sempre use o protocolo HTTPS ao chamar as APIs REST ou acessar objetos no armazenamento. Além disso, as Assinaturas de Acesso Compartilhado, que podem ser usadas para delegar acesso a objetos de Armazenamento do Azure, incluem uma opção para especificar que apenas o protocolo HTTPS pode ser usado ao usar Assinaturas de Acesso Compartilhado, garantindo que qualquer pessoa que envie links com tokens SAS usará o protocolo adequado.

Valide o hash MD5 após o download do blob se o HTTPS não puder ser habilitado

Título	Detalhes
Componente	Armazenamento do Azure
Fase SDL	Criar
Tecnologias aplicáveis	Genérico
Atributos	StorageType - Blob
Referências	Visão geral do Blob MD5 do Windows Azure
Passos	O serviço de Blob do Windows Azure fornece mecanismos para garantir a integridade dos dados nas camadas de aplicativo e transporte. Se, por qualquer motivo, você precisar usar HTTP em vez de HTTPS e estiver trabalhando com blobs de bloco, poderá usar a verificação MD5 para ajudar a verificar a integridade dos blobs que estão sendo transferidos Isso ajudará na proteção contra erros da camada de rede/transporte, mas não necessariamente com ataques intermediários. Se você puder usar HTTPS, que fornece segurança de nível de transporte, usar a verificação MD5 é redundante e desnecessário.

Use o cliente compatível com SMB 3.x para garantir a criptografia de dados em trânsito para compartilhamentos de arquivos do Azure

Título	Detalhes
Componente	Cliente Móvel
Fase SDL	Criar
Tecnologias aplicáveis	Genérico
Atributos	StorageType - Arquivo
Referências	Azure Files, Azure Files SMB Support para clientes Windows
Passos	O Azure Files dá suporte a HTTPS ao usar a API REST, mas é mais comumente usado como um compartilhamento de arquivos SMB anexado a uma VM. O SMB 2.1 não oferece suporte à criptografia, portanto, as conexões só são permitidas dentro da mesma região no Azure. No entanto, o SMB 3.x suporta criptografia e pode ser usado com o Windows Server 2012 R2, Windows 8, Windows 8.1 e Windows 10, permitindo acesso entre regiões e até mesmo acesso na área de trabalho.

Implementar fixação de certificado

Título	Detalhes
Componente	Armazenamento do Azure
Fase SDL	Criar
Tecnologias aplicáveis	Genérico, Windows Phone
Atributos	N/A
Referências	Fixação de Certificados e Chaves Públicas
Passos	A fixação de certificados defende contra ataques Man-In-The-Middle (MITM). A fixação é o processo de associar um host ao seu certificado X509 esperado ou chave pública. Uma vez que um certificado ou chave pública é conhecido ou visto para um host, o certificado ou chave pública é associado ou 'fixado' ao host. Assim, quando um adversário tenta fazer um ataque MITM TLS, durante o handshake TLS a chave do servidor do invasor será diferente da chave do certificado fixo, e a solicitação será descartada, impedindo assim que a fixação do Certificado MITM possa ser alcançada implementando o ServerCertificateValidationCallback delegado do ServicePointManager.

Exemplo

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

Ativar HTTPS - Canal de Transporte Seguro

Título	Detalhes
Componente	WCF
Fase SDL	Criar
Tecnologias aplicáveis	NET Framework 3
Atributos	N/A
Referências	MSDN, Reino Fortify
Passos	A configuração do aplicativo deve garantir que o HTTPS seja usado para todo o acesso a informações confidenciais. EXPLICAÇÃO: Se um aplicativo lida com informações confidenciais e não usa criptografia no nível da mensagem, ele só deve ter permissão para se comunicar por um canal de transporte criptografado. RECOMENDAÇÕES: Certifique-se de que o transporte HTTP está desativado e habilite o transporte HTTPS. Por exemplo, substitua a <httpTransport/> tag with <httpsTransport/> . Não confie em uma configuração de rede (firewall) para garantir que o aplicativo só possa ser acessado por um canal seguro. De um ponto de vista filosófico, a aplicação não deve depender da rede para a sua segurança. De um ponto de vista prático, as pessoas responsáveis pela segurança da rede nem sempre acompanham os requisitos de segurança da aplicação à medida que evoluem.

WCF: Definir o nível de proteção de segurança de mensagem para EncryptAndSign

Título	Detalhes
Componente	WCF
Fase SDL	Criar
Tecnologias aplicáveis	.NET Framework 3
Atributos	N/A
Referências	MSDN
Passos	EXPLICAÇÃO: Quando o nível de proteção é definido como "nenhum", ele desativará a proteção de mensagens. A confidencialidade e a integridade são alcançadas com um nível adequado de definição. RECOMENDAÇÕES: when Mode=None - Desativa a proteção de mensagens quando - Assina, mas não criptografa a mensagem; deve ser usado quando Mode=Sign a integridade dos dados é importante when Mode=EncryptAndSign - Assina e encripta a mensagem Considere desativar a criptografia e assinar sua mensagem apenas quando precisar validar a integridade das informações sem preocupações de confidencialidade. Isso pode ser útil para operações ou contratos de serviço nos quais você precisa validar o remetente original, mas nenhum dado confidencial é transmitido. Ao reduzir o nível de proteção, tenha cuidado para que a mensagem não contenha dados pessoais.

Exemplo

A configuração do serviço e da operação para assinar apenas a mensagem é mostrada nos exemplos a seguir. Exemplo de contrato de serviço : Segue-se um exemplo de utilização de ProtectionLevel.Sign ao nível do contrato de ProtectionLevel.Signserviço:

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

Exemplo

Exemplo de contrato de operação (para controle granular): A seguir está um exemplo de ProtectionLevel.Sign uso ProtectionLevel.Sign no nível OperationContract:

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

WCF: Use uma conta menos privilegiada para executar seu serviço WCF

Título	Detalhes
Componente	WCF
Fase SDL	Criar
Tecnologias aplicáveis	.NET Framework 3
Atributos	N/A
Referências	MSDN
Passos	EXPLICAÇÃO: Não execute serviços WCF sob admin ou conta de alto privilégio. Em caso de comprometimento dos serviços, isso resultará em alto impacto. RECOMENDAÇÕES: Use uma conta menos privilegiada para hospedar seu serviço WCF, pois isso reduzirá a superfície de ataque do aplicativo e reduzirá os danos potenciais se você for atacado. Se a conta de serviço exigir direitos de acesso adicionais em recursos de infraestrutura, como MSMQ, o log de eventos, contadores de desempenho e o sistema de arquivos, permissões apropriadas devem ser dadas a esses recursos para que o serviço WCF possa ser executado com êxito. Se o seu serviço precisar acessar recursos específicos em nome do chamador original, use a representação e a delegação para fluir a identidade do chamador para uma verificação de autorização downstream. Em um cenário de desenvolvimento, use a conta de serviço de rede local, que é uma conta interna especial que tem privilégios reduzidos. Em um cenário de produção, crie uma conta de serviço de domínio personalizada com privilégios mínimos.

Forçar todo o tráfego para APIs da Web através da conexão HTTPS

Título	Detalhes
Componente	API da Web
Fase SDL	Criar
Tecnologias aplicáveis	MVC5, MVC6
Atributos	N/A
Referências	Impondo SSL em um controlador de API da Web
Passos	Se um aplicativo tiver uma ligação HTTPS e HTTP, os clientes ainda poderão usar HTTP para acessar o site. Para evitar isso, use um filtro de ação para garantir que as solicitações para APIs protegidas sejam sempre por HTTPS.

Exemplo

O código a seguir mostra um filtro de autenticação de API da Web que verifica se há 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);
        }
    }
}

Adicione este filtro a todas as ações da API Web que exijam TLS:

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

Verifique se a comunicação com o Cache Redis do Azure é feita por TLS

Título	Detalhes
Componente	Cache do Azure para Redis
Fase SDL	Criar
Tecnologias aplicáveis	Genérico
Atributos	N/A
Referências	Suporte do Azure Redis TLS
Passos	O servidor Redis não oferece suporte imediato ao TLS, mas o Cache Redis do Azure oferece suporte imediato. Se você estiver se conectando ao Cache Redis do Azure e seu cliente oferecer suporte a TLS, como StackExchange.Redis, use TLS. Por padrão, a porta não-TLS está desabilitada para novas instâncias do Cache do Azure para Redis. Certifique-se de que os padrões seguros não sejam alterados, a menos que haja uma dependência do suporte TLS para clientes redis.

Observe que o Redis foi projetado para ser acessado por clientes confiáveis dentro de ambientes confiáveis. Isso significa que geralmente não é uma boa ideia expor a instância do Redis diretamente à Internet ou, em geral, a um ambiente onde clientes não confiáveis possam acessar diretamente a porta Redis TCP ou o soquete UNIX.

Comunicação segura de dispositivo para gateway de campo

Título	Detalhes
Componente	Gateway de campo IoT
Fase SDL	Criar
Tecnologias aplicáveis	Genérico
Atributos	N/A
Referências	N/A
Passos	Para dispositivos baseados em IP, o protocolo de comunicação normalmente pode ser encapsulado em um canal SSL/TLS para proteger os dados em trânsito. Para outros protocolos que não suportam SSL/TLS, investigue se existem versões seguras do protocolo que forneçam segurança no transporte ou na camada de mensagens.

Comunicação segura de dispositivo para gateway de nuvem usando SSL/TLS

Título	Detalhes
Componente	Gateway de nuvem IoT
Fase SDL	Criar
Tecnologias aplicáveis	Genérico
Atributos	N/A
Referências	Escolha o seu Protocolo de Comunicação
Passos	Protocolos HTTP/AMQP ou MQTT seguros usando SSL/TLS.