Compartilhar via

Estrutura de segurança: Segurança de comunicações | Atenuações

  • Artigo
Produto/Serviço Artigo
Hub de Eventos do Azure
Dynamics CRM
Azure Data Factory
Servidor de identidade
Aplicativo Web
Backup de banco de dados
Armazenamento do Azure
Cliente móvel
WCF
API da Web
Cache Redis do Azure
Gateway de Campo de IoT
Gateway de Nuvem IoT

Proteger comunicações para o Hub de Eventos usando SSL/TLS

Title Detalhes
Componente Hub de Eventos do Azure
Fase do SDL Build
Tecnologias aplicáveis Genérico
Atributos N/D
Referências Visão geral do modelo de autenticação e segurança dos Hubs de Eventos
Etapas Proteja conexões AMQP ou HTTP com o Hub de Eventos usando SSL/TLS

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

Title Detalhes
Componente Dynamics CRM
Fase do SDL Build
Tecnologias aplicáveis Genérico
Atributos N/D
Referências N/D
Etapas Verifique se os privilégios da conta do serviço e verifique se os serviços ou páginas ASP.NET personalizados respeitam a segurança do CRM.

Usar o Gateway de gerenciamento de dados durante a conexão local do SQL Server com o Azure Data Factory

Title Detalhes
Componente Fábrica de dados do Azure
Fase do SDL Implantação
Tecnologias aplicáveis Genérico
Atributos Tipos de serviços vinculados – no Azure e localmente
Referências Mover dados entre o armazenamento local e o Azure Data Factory
Etapas

A ferramenta Gateway de Gerenciamento de Dados (DMG) é necessária para conectar fontes de dados protegidas por um firewall ou pela rede corporativa.

  1. Blindar a máquina isola a ferramenta DMG e evita que programas com defeito danifiquem ou espionem o computador da fonte de dados. (Por exemplo, instalando das atualizações mais recentes, habilitando o mínimo necessário de portas, provisionando contas controladas, habilitando a auditoria, habilitando a criptografia de disco, 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. O tráfego de dados pelo serviço de vinculação deve ser criptografado.

Garantir que todo o tráfego para o servidor de identidade passe pela conexão HTTPS

Title Detalhes
Componente Servidor de identidade
Fase do SDL Implantação
Tecnologias aplicáveis Genérico
Atributos N/D
Referências IdentityServer3 - chaves, assinaturas e criptografia, IdentityServer3 - implantação
Etapas Por padrão, o IdentityServer exige que todas as conexões de entrada sejam feitas via HTTPS. É absolutamente obrigatório que a comunicação com IdentityServer seja feita apenas transportes protegidos. Em alguns cenários de implantação, como o de descarregamento de TLS, esse requisito pode ser relaxado. Consulte a página de implantação do Servidor de identidade indicada nas referências para obter mais informações.

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

Title Detalhes
Componente Aplicativo Web
Fase do SDL Build
Tecnologias aplicáveis Genérico
Atributos N/D
Referências N/D
Etapas

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

  • Nome de domínio
  • Datas de validade (datas de início e vencimento)
  • Status de revogação
  • Uso (por exemplo, autenticação de servidor para servidores de autenticação de cliente para clientes)
  • Cadeia de confiança (os certificados devem estar vinculados a uma autoridade de certificação (CA) raiz de confiança da plataforma ou serem configurados explicitamente pelo administrador)
  • O comprimento da chave pública do certificado deve ser maior que >2048 bits
  • Algoritmo de hash deve ser SHA256 e superior

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

Title Detalhes
Componente Aplicativo Web
Fase do SDL Build
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 o HTTPS para todos os aplicativos com um certificado curinga para o domínio *.azurewebsites.net. No entanto, assim como todos os domínios curinga, ele não é tão seguro quanto usar um domínio personalizado com seu próprio certificado. Consulte este artigo. É 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

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

Embora os Serviços de Aplicativos do Azure já habilite o HTTPS com um certificado curinga para o domínio *.azurewebsites.net, ele não impõe o HTPPS. Os visitantes podem continuar acessando o aplicativo com o HTTP, possibilitando que a segurança do aplicativo seja comprometida, por isso o HTTPS deve ser explicitamente imposto. Os aplicativos do ASP.NET MVC devem usar o filtro RequireHttps que obriga uma solicitação HTTP desprotegida a ser reenviada pelo HTTPS.

O módulo de Reescrita de URL, incluído no Serviço de Aplicativo do Azure, também pode ser usado para impor o HTTPS. Esse módulo permite que desenvolvedores definam as regras aplicadas às solicitações recebidas antes que elas cheguem ao aplicativo. As regras de Reescrita de URL são definidas em um arquivo web.config, que fica armazenado na raiz do aplicativo.

Exemplo

O exemplo abaixo contém uma regra básica de Reescrita de URL que força todo o tráfego de entrada a usar o protocolo 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 de protocolo HTTP 301 (redirecionamento permanente) quando o usuário solicita uma página usando o protocolo HTTP. O 301 redireciona a solicitação para a mesma URL solicitada pelo visitante, mas substitui a parte do protocolo HTTP da solicitação com o protocolo HTTPS. Por exemplo, HTTP://contoso.com seria redirecionado para HTTPS://contoso.com.

Habilitar HSTS (Segurança de Transporte Estrito HTTP)

Title Detalhes
Componente Aplicativo Web
Fase do SDL Build
Tecnologias aplicáveis Genérico
Atributos N/D
Referências Folha de dados do OWASP sobre Segurança de Transporte Estrito HTTP
Etapas

A Segurança de Transporte Estrito HTTP (HSTS) é um aperfeiçoamento de segurança opcional, que é especificado por um aplicativo Web por meio de um cabeçalho de resposta especial. Depois que um navegador em conformidade recebe o cabeçalho, esse navegador impede que todas as comunicações sejam enviadas pelo HTTP para o domínio especificado e envia todas as comunicações pelo HTTPS. Ele também impede cliques via HTTPS em prompts de navegadores.

Para implementar a HSTS, o seguinte cabeçalho de resposta precisa ser configurado globalmente para um site, por meio de um código ou de um arquivo de configuração. Strict-Transport-Security: max-age=300; includeSubDomains HSTS resolve 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 da Web que se destina a ser puramente HTTPS acaba contendo links HTTP ou envia pelo HTTP: a HSTS automaticamente redireciona as solicitações de HTTP para HTTPS para o domínio de destino.
  • Um ataque MITM tenta interceptar o tráfego de um usuário utilizando um certificado inválido e espera que o usuário aceite o certificado incorreto: a HSTS não permite que um usuário substitua a mensagem de certificado inválido.

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

Title Detalhes
Componente Banco de dados
Fase do SDL Build
Tecnologias aplicáveis SQL Azure
Atributos Versão do SQL - V12
Referências Práticas recomendadas para escrever cadeias de caracteres 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 protocolo TLS (anteriormente conhecido como protocolo SSL) em todos os momentos. O Banco de Dados SQL não dá suporte a conexões não criptografadas. Para validar certificados com o código do aplicativo ou as 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 solicitam uma conexão criptografada, eles continuarão receberão conexões criptografadas.

No entanto, eles não podem validar certificados de servidor e, portanto, ficarão suscetíveis a ataques de "man in the middle". Para validar certificados com o código de aplicativo ADO.NET, defina Encrypt=True e TrustServerCertificate=False na cadeia de conexão de banco de dados. Para validar certificados por meio do SQL Server Management Studio, abra a caixa de diálogo Conectar ao Servidor. Na guia Propriedades da Conexão, clique em Criptografar conexão.

Forçar a comunicação criptografada para o SQL Server

Title Detalhes
Componente Banco de dados
Fase do SDL Build
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 com o Mecanismo de Banco de Dados
Etapas Habilitar a criptografia TLS aumenta a segurança dos dados transmitidos pelas redes entre instâncias do SQL Server e aplicativos.

Garantir que as comunicações para o Armazenamento do Azure sejam feitas via HTTPS

Title Detalhes
Componente Armazenamento do Azure
Fase do SDL Implantação
Tecnologias aplicáveis Genérico
Atributos N/D
Referências Criptografia no nível do transporte do Armazenamento do Azure – usando HTTPS
Etapas Para garantir a segurança dos dados do Armazenamento do Azure que estão em trânsito, use sempre o protocolo HTTPS ao chamar 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 apenas o protocolo HTTPS seja utilizado com as Assinaturas de Acesso Compartilhado, garantindo que qualquer pessoa que envie links com tokens SAS usará o protocolo adequado.

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

Title Detalhes
Componente Armazenamento do Azure
Fase do SDL Build
Tecnologias aplicáveis Genérico
Atributos StorageType - Blob
Referências Visão geral da MD5 do Blob do Azure
Etapas

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

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

Title Detalhes
Componente Cliente móvel
Fase do SDL Build
Tecnologias aplicáveis Genérico
Atributos Tipo de armazenamento - Arquivo
Referências Arquivos do Azure, Suporte do SMB para os Arquivos do Azure em Clientes Windows
Etapas Os Arquivos do Azure dão suporte a HTTPS ao usar a API REST, mas é mais frequentemente usado como um compartilhamento de arquivos SMB conectado a uma VM. O SMB 2.1 não é compatível com a criptografia, de modo que as conexões só são permitidas dentro da mesma região no Azure. No entanto, o SMB 3.x é compatível com a criptografia e pode ser usado com o Windows Server 2012 R2, o Windows 8, o Windows 8.1 e o Windows 10, permitindo o acesso entre regiões e até mesmo o acesso no desktop.

Implementar a anexação de certificado

Title Detalhes
Componente Armazenamento do Azure
Fase do SDL Build
Tecnologias aplicáveis Genérico, Windows Phone
Atributos N/D
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 uma chave pública forem conhecidas ou vistos para um host, o certificado ou a chave pública serão associados ou “anexados” 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 - proteger o canal de transporte

Title Detalhes
Componente WCF
Fase do SDL Build
Tecnologias aplicáveis NET Framework 3
Atributos N/D
Referências MSDN, Fortify Kingdom
Etapas A configuração do aplicativo deve garantir que o HTTPS seja usado para todos os acessos a informações confidenciais.
  • EXPLICAÇÃO: se um aplicativo contiver informações confidenciais e não usar a criptografia no nível da mensagem, ele só poderá se comunicar por meio de um canal de transporte criptografado.
  • RECOMENDAÇÕES: verifique se o transporte HTTP está desabilitado e habilite o transporte HTTPS em vez disso. Por exemplo, substitua <httpTransport/> pela marcação <httpsTransport/>. Não confie em uma configuração de rede (firewall) para garantir que o aplicativo seja acessado apenas por um canal seguro. Do ponto de vista filosófico, o aplicativo não deve depender da rede para garantir sua segurança.

Do ponto de vista prático, as pessoas responsáveis pela segurança da rede nem sempre monitoram os requisitos de segurança do aplicativo à medida que eles evoluem.

WCF: definir o nível de proteção da segurança de mensagens como EncryptAndSign

Title Detalhes
Componente WCF
Fase do SDL Build
Tecnologias aplicáveis .NET Framework 3
Atributos N/D
Referências MSDN
Etapas
  • EXPLICAÇÃO: quando o nível de proteção estiver definido como "none", a proteção de mensagem será desabilitada. A confidencialidade e a integridade dos dados só são conquistadas com o nível apropriado de configuração.
  • RECOMENDAÇÕES:
    • Mode=None - desabilita a proteção de mensagem
    • Mode=Sign - assina, mas não criptografa a mensagem (deve ser usada quando a integridade dos dados for importante)
    • Mode=EncryptAndSign - assina e criptografa a mensagem

Considere desativar a criptografia e apenas assinar uma mensagem quando você só precisar validar a integridade das informações sem se preocupar com sua confidencialidade. Isso pode ser útil para operações ou contratos de serviço nos quais você precisa validar o remetente original, mas que não transmitem dados confidenciais. Quando você reduzir o nível de proteção, verifique se a mensagem não contém nenhum dado pessoal.

Exemplo

A configuração do serviço e a operação de apenas assinar a mensagem são mostradas nos exemplos aabaixo. Exemplo de contrato de serviço de ProtectionLevel.Sign: o exemplo abaixo mostra 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 um controle granular): veja abaixo um exemplo do uso de ProtectionLevel.Sign no nível do contrato de operação.

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

WCF: use uma conta com privilégios mínimos para executar o serviço WCF

Title Detalhes
Componente WCF
Fase do SDL Build
Tecnologias aplicáveis .NET Framework 3
Atributos N/D
Referências MSDN
Etapas
  • EXPLICAÇÃO: não execute serviços do WCF usando contas de administrador ou com privilégios altos. Se os serviços forem comprometidos, isso pode ter um impacto alto.
  • RECOMENDAÇÕES: use uma conta com privilégios mínimos para hospedar o serviço WCF, porque isso reduz a superfície de ataque do aplicativo e os potenciais danos causados se houver um ataque. Se a conta do serviço exigir direitos de acesso adicionais nos recursos de infraestrutura, como MSMQ, o log de eventos, contadores de desempenho e o sistema de arquivos, as permissões apropriadas para esses recursos devem ser concedidas, para que o serviço WCF seja executado ê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 da rede local, que é uma conta interna especial com privilégios limitados. 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 Web pela conexão HTTPS

Title Detalhes
Componente API Web
Fase do SDL Build
Tecnologias aplicáveis MVC5, MVC6
Atributos N/D
Referências Impondo o SSL em um controlador de API da Web
Etapas Se um aplicativo tiver uma associação HTTPS e HTTP, os clientes poderão usar o HTTP para acessar o site. Para impedir isso, use um filtro de ação para garantir que as solicitações para APIs protegidas serão sempre feitas via HTTPS.

Exemplo

O código abaixo mostra um filtro de autenticação de API Web que verifica o 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 esse filtro às ações de API Web que exigem TLS:

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

Garantir que as comunicações para o Cache do Azure para Redis sejam feitas via TLS

Title Detalhes
Componente Cache Redis do Azure
Fase do SDL Build
Tecnologias aplicáveis Genérico
Atributos N/D
Referências Suporte a TLS do Redis do Azure
Etapas O servidor Redis não dá suporte ao TLS pronto para uso, enquanto o Cache do Azure para Redis dá. Se você estiver se conectando ao Cache do Azure para Redis, e seu cliente oferecer suporte a TLS, como StackExchange.Redis, você deverá usar 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 em ambientes confiáveis. Isso significa que normalmente não é uma boa ideia expor a instância do Redis diretamente à Internet ou, de uma forma geral, a um ambiente onde clientes não confiáveis podem acessar diretamente o soquete UNIX ou a porta TCP do Redis.

Proteger dispositivo para comunicações do Gateway de Campo

Title Detalhes
Componente Gateway de Campo de IoT
Fase do SDL Build
Tecnologias aplicáveis Genérico
Atributos N/D
Referências N/D
Etapas Para dispositivos baseados em IP, o protocolo de comunicação poderia ser encapsulado em um canal SSL/TLS para proteger os dados em trânsito. Para outros protocolos que não oferecem suporte a SSL/TLS, verifique se há versões protegidas do protocolo que fornecem segurança na camada de transporte ou de mensagens.

Proteger o dispositivo para comunicações do Gateway de Nuvem usando SSL/TLS

Title Detalhes
Componente Gateway de Nuvem IoT
Fase do SDL Build
Tecnologias aplicáveis Genérico
Atributos N/D
Referências Escolha seu protocolo de comunicação
Etapas Proteja os protocolos HTTP/AMQP ou MQTT usando SSL/TLS.