Compartilhar via

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

Produto/Serviço Artigo
Hub de Eventos do Azure
Dynamics CRM
Fábrica de dados do Azure
Servidor de identidade
Aplicativo Web
Banco de dados
Azure Storage
Cliente móvel
WCF
Web API
Cache do Azure para Redis
Gateway de Campo de IoT
Gateway de Nuvem IoT

Proteger a comunicação com o Hub de Eventos usando SSL/TLS

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

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

Título Detalhes
Componente Dynamics CRM
Fase do SDL Construir
Tecnologias aplicáveis Genérico
Atributos Não aplicável
Referências Não aplicável
Etapas Verifique os privilégios da conta de serviço e verifique se os Serviços personalizados ou ASP.NET Páginas 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 Fábrica de dados do Azure
Fase do SDL Implantaçã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
Etapas

A ferramenta DMG (Gateway de Gerenciamento de Dados) é necessária para se conectar a fontes de dados protegidas por trás da corpnet ou de um firewall.

  1. Bloquear o computador isola a ferramenta DMG e impede que programas defeituosos prejudiquem ou bisbilhotem o computador 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.)
  2. A chave do Gateway de Dados precisa ser trocada em intervalos frequentes ou sempre que a senha da conta do serviço do DMG for renovada
  3. Os trânsitos de dados por meio do Serviço de Link devem ser criptografados

Verifique se todo o tráfego para o Identity Server é por meio da conexão HTTPS

Título Detalhes
Componente Servidor de identidade
Fase do SDL Implantação
Tecnologias aplicáveis Genérico
Atributos Não aplicável
Referências Não aplicável
Etapas Por padrão, o IdentityServer requer que todas as conexões de entrada sejam acessadas por HTTPS. É absolutamente obrigatório que a comunicação com o IdentityServer seja feita somente em transportes protegidos. 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 Aplicativo Web
Fase do SDL Construir
Tecnologias aplicáveis Genérico
Atributos Não aplicável
Referências Não aplicável
Etapas

Os aplicativos que usam SSL, TLS ou DTLS devem verificar completamente os certificados X.509 das entidades às quais se conectam. Isso inclui a verificação dos certificados para:

  • Nome de domínio
  • Datas de validade (datas de início e de término)
  • Status 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 AC (autoridade de certificação) raiz confiável pela plataforma ou explicitamente configurada 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 Aplicativo Web
Fase do SDL Construir
Tecnologias aplicáveis Genérico
Atributos Tipo de ambiente - Azure
Referências Habilitar HTTPS para um aplicativo no Serviço de Aplicativo do Azure
Etapas Por padrão, o Azure já habilita HTTPS para cada aplicativo usando um certificado curinga para o domínio *.azurewebsites.net. No entanto, como todos os domínios curinga, ele não é tão seguro quanto usar um domínio personalizado com o próprio certificado Refer. É 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 por meio da conexão HTTPS

Título Detalhes
Componente Aplicativo Web
Fase do SDL Construir
Tecnologias aplicáveis Genérico
Atributos Tipo de ambiente - Azure
Referências Impor HTTPS no Serviço de Aplicativo do Azure
Etapas

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 precisa ser imposto explicitamente. ASP.NET aplicativos MVC devem usar o filtro RequireHttps que força uma solicitação HTTP não confiável a ser reenançada por HTTPS.

Como alternativa, o módulo Regravação de URL, que está incluído no Serviço de Aplicativo do Azure, pode ser usado para impor HTTPS. O módulo de Regravação de URL permite que os desenvolvedores definam regras aplicadas a solicitações de entrada antes que as solicitações sejam entregues ao seu aplicativo. As regras de regravaçã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 reescrita 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>

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

Habilitar O HSTS (Segurança de Transporte Estrito HTTP)

Título Detalhes
Componente Aplicativo Web
Fase do SDL Construir
Tecnologias aplicáveis Genérico
Atributos Não aplicável
Referências Folha de dados do OWASP sobre Segurança de Transporte Estrito HTTP
Etapas

O HSTS (Http Strict Transport Security) é um aprimoramento de segurança de aceitação especificado por um aplicativo Web por meio do uso de um cabeçalho de resposta especial. Depois que um navegador com suporte receber esse cabeçalho, esse navegador impedirá que qualquer comunicação seja enviada via HTTP para o domínio especificado e, em vez disso, enviará todas as comunicações por HTTPS. Ele também impede cliques via HTTPS em prompts de navegadores.

Para implementar o HSTS, o cabeçalho de resposta a seguir precisa ser configurado para um site globalmente, no código ou na configuração. Strict-Transport-Security: max-age=300; includeSubDomains HSTS aborda as seguintes ameaças:

  • O usuário marca ou digita https://example.com e fica sujeito a um ataque man-in-the-middle: a HSTS automaticamente redireciona as solicitações de 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 por HTTP: o HSTS redireciona automaticamente solicitações HTTP para HTTPS para o domínio de destino
  • Um atacante do tipo man-in-the-middle tenta interceptar o tráfego de um usuário-vítima utilizando um certificado inválido e espera que o usuário aceite o certificado ruim: o HSTS não permite que um usuário ignore 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 do SDL Construir
Tecnologias aplicáveis SQL Azure
Atributos Versão do SQL - V12
Referências Práticas recomendadas para escrever cadeias de conexão seguras para o Banco de Dados SQL
Etapas

Todas as comunicações entre o Banco de Dados SQL e um aplicativo cliente são criptografadas usando o TLS (Transport Layer Security), anteriormente conhecido como SSL (Secure Sockets Layer), em todos os momentos. O Banco de Dados SQL não dá suporte a conexões não criptografadas. Para validar certificados com código ou ferramentas do aplicativo, solicite explicitamente uma conexão criptografada e não confie nos certificados do servidor. Se o código do aplicativo ou as ferramentas não solicitarem uma conexão criptografada, elas 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 "homem no meio". Para validar certificados com o código do aplicativo ADO.NET, 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 a comunicação criptografada com o SQL Server

Título Detalhes
Componente Base de dados
Fase do SDL Construir
Tecnologias aplicáveis OnPrem
Atributos Versão do SQL – MsSQL2016, Versão do SQL – MsSQL2012, Versão do SQL – MsSQL2014
Referências Habilitar conexões criptografadas para o mecanismo de banco de dados
Etapas A habilitação da criptografia TLS aumenta a segurança dos dados transmitidos pelas redes entre instâncias do SQL Server e aplicativos.

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

Título Detalhes
Componente Armazenamento do Azure
Fase do SDL Implantação
Tecnologias aplicáveis Genérico
Atributos Não aplicável
Referências Criptografia do Armazenamento Azure Transport-Level – Utilizando HTTPS
Etapas 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 do Armazenamento do Azure, incluem uma opção para especificar que somente o protocolo HTTPS pode ser usado ao usar Assinaturas de Acesso Compartilhado, garantindo que qualquer pessoa que envie links com tokens SAS use o protocolo adequado.

Validar o hash MD5 depois de baixar o blob se o HTTPS não puder ser habilitado

Título Detalhes
Componente Armazenamento do Azure
Fase do SDL Construir
Tecnologias aplicáveis Genérico
Atributos StorageType – Bloco de dados
Referências Visão geral do Windows Azure Blob MD5
Etapas

O serviço Blob do Windows Azure fornece mecanismos para garantir a integridade dos dados nas camadas de aplicativo e transporte. Se por algum motivo você precisar usar HTTP em vez de HTTPS e estiver trabalhando com blobs de blocos, 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 de camada de rede/transporte, mas não necessariamente com ataques intermediários. Se você puder usar HTTPS, que fornece segurança em nível de transporte, o uso da verificação MD5 é redundante e desnecessário.

Usar um 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 do SDL Construir
Tecnologias aplicáveis Genérico
Atributos Tipo de armazenamento - Arquivo
Referências Arquivos do Azure, Suporte ao SMB de Arquivos do Azure para clientes Windows
Etapas Os Arquivos do Azure dão suporte a HTTPS ao usar a API REST, mas são mais comumente usados como um compartilhamento de arquivos SMB anexado a uma VM. O SMB 2.1 não dá suporte à criptografia, portanto, as conexões só são permitidas dentro da mesma região no Azure. No entanto, o SMB 3.x dá suporte à 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 a anexação de certificado

Título Detalhes
Componente Armazenamento do Azure
Fase do SDL Construir
Tecnologias aplicáveis Genérico, Windows Phone
Atributos Não aplicável
Referências Anexação de chave pública e certificado
Etapas

A anexação de certificado protege contra ataques MITM (Man-In-The-Middle). A anexação é o processo de associar um host com sua chave pública ou seu certificado X509 esperado. Depois 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 invasor tentar promover um ataque MITM TLS, durante o handshake do TLS, a chave do servidor do invasor será diferente da chave do certificado anexado, e a solicitação será descartada, impedindo que o certificado de MITM seja anexado com a implementação do delegado ServerCertificateValidationCallback 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();
        }
    }
}

Habilitar HTTPS – Canal de Transporte Seguro

Título Detalhes
Componente WCF (Windows Communication Foundation)
Fase do SDL Construir
Tecnologias aplicáveis NET Framework 3
Atributos Não aplicável
Referências MSDN, Fortify Kingdom
Etapas 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: Verifique se o transporte HTTP está desabilitado e habilite o transporte HTTPS. Por exemplo, substitua a <httpTransport/> marca por <httpsTransport/> . Não dependa de uma configuração de rede (firewall) para garantir que o aplicativo só possa ser acessado por um canal seguro. Do ponto de vista filosófico, o aplicativo não deve depender da rede para sua segurança.

Do ponto de vista prático, as pessoas responsáveis por proteger a rede nem sempre acompanham os requisitos de segurança do aplicativo à medida que evoluem.

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

Título Detalhes
Componente WCF (Windows Communication Foundation)
Fase do SDL Construir
Tecnologias aplicáveis .NET Framework 3
Atributos Não aplicável
Referências MSDN
Etapas
  • EXPLICAÇÃO: Quando o nível de proteção for definido como "nenhum", ele desabilitará a proteção de mensagens. A confidencialidade e a integridade são obtidas com o nível apropriado de configuração.
  • RECOMENDAÇÕES:
    • quando Mode=None – Desabilita a proteção de mensagens
    • quando Mode=Sign – Assina, mas não criptografa a mensagem; deve ser usado quando a integridade dos dados é importante
    • quando Mode=EncryptAndSign – assina e criptografa a mensagem

Considere desativar a criptografia e apenas assinar sua mensagem quando você só 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

Configurar o serviço e a operação para assinar apenas a mensagem é mostrado nos exemplos a seguir. Exemplo de Contrato de Serviço de ProtectionLevel.Sign: O exemplo a seguir demonstra o uso de ProtectionLevel.Sign no nível do Contrato de Serviço.

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

Exemplo

Exemplo de contrato de operação de ProtectionLevel.Sign (para controle granular): o seguinte é um exemplo do uso de ProtectionLevel.Sign no nível do Contrato de Operação.

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

WCF: usar uma conta com menos privilégios para executar seu serviço WCF

Título Detalhes
Componente WCF (Windows Communication Foundation)
Fase do SDL Construir
Tecnologias aplicáveis .NET Framework 3
Atributos Não aplicável
Referências MSDN
Etapas
  • EXPLICAÇÃO: Não execute os serviços do WCF em uma conta de alto privilégio ou administrador. em caso de comprometimento de serviços, isso resultará em alto impacto.
  • RECOMENDAÇÕES: Use uma conta com menos privilégios para hospedar seu serviço WCF, pois isso reduzirá a superfície de ataque do aplicativo e reduzirá o dano potencial se você for atacado. Se a conta de serviço exigir direitos de acesso adicionais em recursos de infraestrutura, como o MSMQ, o log de eventos, os contadores de desempenho e o sistema de arquivos, as permissões apropriadas deverão ser fornecidas a esses recursos para que o serviço WCF possa ser executado com êxito.

Se o serviço precisar acessar recursos específicos em nome do chamador original, use a representação e a delegação, para que a identidade do chamador passe por uma verificação de autorização de 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 personalizado com privilégios mínimos.

Forçar todo o tráfego para APIs Web pela conexão HTTPS

Título Detalhes
Componente Web API
Fase do SDL Construir
Tecnologias aplicáveis MVC5, MVC6
Atributos Não aplicável
Referências Imposição de SSL em um controlador de API Web
Etapas Se um aplicativo tiver um HTTPS e uma associação 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 estejam sempre sobre HTTPS.

Exemplo

O código a seguir mostra um filtro de autenticação da API 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 qualquer ação de API Web que exija TLS:

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

Certifique-se de que a comunicação com o Azure Cache para Redis seja feita sobre TLS.

Título Detalhes
Componente Azure Cache para Redis
Fase do SDL Construir
Tecnologias aplicáveis Genérico
Atributos Não aplicável
Referências Suporte ao Azure Redis TLS
Etapas O servidor Redis não oferece suporte ao TLS de forma nativa, mas o Cache do Azure para Redis oferece. Se você estiver se conectando ao Cache do Azure para Redis e seu cliente der suporte ao TLS, como StackExchange.Redis, você deverá usar o 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 de segurança não sejam alterados, a menos que haja uma dependência no suporte a 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 em que clientes não confiáveis podem acessar diretamente a porta TCP do Redis ou o soquete UNIX.

Proteger dispositivo para comunicações do Gateway de Campo

Título Detalhes
Componente Gateway de Campo de IoT
Fase do SDL Construir
Tecnologias aplicáveis Genérico
Atributos Não aplicável
Referências Não aplicável
Etapas Para dispositivos baseados em IP, o protocolo de comunicação normalmente pode ser encapsulado em um canal SSL/TLS para proteger dados em trânsito. Para outros protocolos que não dão suporte ao SSL/TLS, investigue se há versões seguras do protocolo que fornecem segurança na camada de transporte ou mensagem.

Proteger a comunicação do Dispositivo para o Gateway de Nuvem usando SSL/TLS

Título Detalhes
Componente Gateway de Nuvem IoT
Fase do SDL Construir
Tecnologias aplicáveis Genérico
Atributos Não aplicável
Referências Escolha o protocolo de comunicação
Etapas Proteja protocolos HTTP/AMQP ou MQTT usando SSL/TLS.
  • Last updated on