Partilhar via

Introdução para proteger o desenvolvimento de aplicativos do Windows

Este artigo introdutório ajuda os arquitetos e desenvolvedores de aplicativos a entender melhor os vários recursos da plataforma Windows 10 que aceleram a criação de aplicativos seguros da Plataforma Universal do Windows (UWP). Ele detalha como usar os recursos de segurança do Windows disponíveis em cada um dos seguintes estágios: autenticação, dados em trânsito e dados em repouso. Você pode encontrar informações mais detalhadas sobre cada tópico revisando os recursos adicionais incluídos em cada capítulo.

1 Introdução

Desenvolver um aplicativo seguro pode ser um desafio. No mundo acelerado de hoje de aplicativos móveis, sociais, na nuvem e empresariais complexos, os clientes esperam que os aplicativos fiquem disponíveis e sejam atualizados mais rápido do que nunca. Eles também usam muitos tipos de dispositivos, aumentando ainda mais a complexidade da criação de experiências de aplicativos. Se você criar para a Plataforma Universal do Windows (UWP), isso pode incluir a lista tradicional de desktops, laptops, tablets e dispositivos móveis; além de uma lista crescente de novos dispositivos que abrangem a Internet das Coisas, Xbox One, Microsoft Surface Hub e HoloLens. Como desenvolvedor, você deve garantir que seus aplicativos se comuniquem e armazenem dados de forma segura, em todas as plataformas ou dispositivos envolvidos.

Aqui estão alguns dos benefícios de utilizar os recursos de segurança do Windows.

  • Você terá segurança padronizada em todos os dispositivos que suportam o Windows, usando APIs consistentes para componentes e tecnologias de segurança.
  • Você escreve, testa e mantém menos código do que se implementasse código personalizado para cobrir esses cenários de segurança.
  • Seus aplicativos se tornam mais estáveis e seguros porque você usa o sistema operacional para controlar como o aplicativo acessa seus recursos e recursos do sistema local ou remoto.

Durante a autenticação, a identidade de um usuário que solicita acesso a um determinado serviço é validada. O Windows Hello é o componente do Windows que ajuda a criar um mecanismo de autenticação mais seguro em aplicativos do Windows. Com ele, você pode usar um Número de Identificação Pessoal (PIN) ou biometria, como impressões digitais, rosto ou íris do usuário, para implementar a autenticação multifator para seus aplicativos.

Os dados em voo referem-se à ligação e às mensagens transferidas através dela. Um exemplo disso é a recuperação de dados de um servidor remoto usando serviços Web. O uso de Secure Sockets Layer (SSL) e Secure Hypertext Transfer Protocol (HTTPS) garante a segurança da conexão. Impedir que partes intermediárias acessem essas mensagens ou aplicativos não autorizados se comuniquem com os serviços da Web é fundamental para proteger os dados em voo.

Por último, os dados em repouso referem-se aos dados que residem na memória ou em suportes de armazenamento. Os aplicativos do Windows têm um modelo de aplicativo que impede o acesso não autorizado a dados entre aplicativos e oferece APIs de criptografia para proteger ainda mais os dados no dispositivo. Um recurso chamado Cofre de Credenciais pode ser usado para armazenar com segurança as credenciais do usuário no dispositivo, com o sistema operacional impedindo que outros aplicativos as acessem.

2 Fatores de autenticação

Para proteger os dados, a pessoa que solicita acesso a eles deve ser identificada e autorizada a acessar os recursos de dados solicitados. O processo de identificação de um usuário é chamado de autenticação, e a determinação de privilégios de acesso a um recurso é chamada de autorização. Estas são operações estreitamente relacionadas, e para o usuário podem ser indistinguíveis. Podem ser operações relativamente simples ou complexas, dependendo de muitos fatores: por exemplo, se os dados residem em um servidor ou se estão distribuídos em muitos sistemas. O servidor que fornece os serviços de autenticação e autorização é chamado de provedor de identidade.

Para autenticar-se com um determinado serviço e/ou aplicativo, o usuário emprega credenciais compostas por algo que sabe, algo que tem e/ou algo que é. Cada um deles é chamado de fatores de autenticação.

  • Algo que o usuário sabe geralmente é uma senha, mas também pode ser um número de identificação pessoal (PIN) ou um par "secreto" de perguntas e respostas.
  • Algo que o usuário tem é na maioria das vezes um dispositivo de memória de hardware, como um pendrive contendo os dados de autenticação exclusivos para o usuário.
  • Algo que é inerente ao utilizador muitas vezes inclui as suas impressões digitais, mas há fatores cada vez mais populares como a fala do utilizador, características faciais, oculares (dos olhos) ou padrões de comportamento. Quando armazenadas como dados, essas medições são chamadas de biometria.

Uma senha criada pelo usuário é um fator de autenticação em si, mas muitas vezes não é suficiente; Qualquer pessoa que conheça a palavra-passe pode fazer-se passar pelo utilizador que a possui. Um cartão inteligente pode fornecer um nível mais elevado de segurança, mas pode ser roubado, perdido ou extraviado. Um sistema que pode autenticar um usuário por sua impressão digital ou por uma varredura ocular pode fornecer o nível mais alto e conveniente de segurança, mas requer hardware caro e especializado (por exemplo, uma câmera Intel RealSense para reconhecimento facial) que pode não estar disponível para todos os usuários.

Projetar o método de autenticação usado por um sistema é um aspeto complexo e importante da segurança de dados. Em geral, quanto maior o número de fatores que você usa na autenticação, mais seguro é o sistema. Ao mesmo tempo, a autenticação deve ser utilizável. Um usuário geralmente faz login muitas vezes ao dia, então o processo deve ser rápido. A sua escolha do tipo de autenticação é um compromisso entre segurança e facilidade de utilização; A autenticação de fator único é a menos segura e mais fácil de usar, e a autenticação multifator torna-se mais segura, mas mais complexa à medida que mais fatores são adicionados.

2.1 Autenticação de fator único

Essa forma de autenticação é baseada em uma única credencial de usuário. Normalmente, trata-se de uma palavra-passe, mas também pode ser um número de identificação pessoal (PIN).

Aqui está o processo de autenticação de fator único.

  • O usuário fornece seu nome de usuário e senha para o provedor de identidade. O provedor de identidade é o processo do servidor que verifica a identidade do usuário.
  • O provedor de identidade verifica se o nome de usuário e a senha são os mesmos armazenados no sistema. Na maioria dos casos, a senha será criptografada, fornecendo segurança adicional para que outras pessoas não possam lê-la.
  • O provedor de identidade retorna um status de autenticação que indica se a autenticação foi bem-sucedida.
  • Se for bem-sucedida, inicia-se a troca de dados. Se não tiver êxito, o usuário deve ser autenticado novamente.

autenticação de fator único

Hoje, esse método de autenticação é o mais usado em todos os serviços. É também a forma menos segura de autenticação quando utilizada como único meio de autenticação. Requisitos de complexidade de senha, "perguntas secretas" e alterações regulares de senha podem tornar o uso de senhas mais seguro, mas colocam mais carga sobre os usuários e não são um dissuasor eficaz contra hackers.

O desafio com senhas é que é mais fácil adivinhá-las com sucesso do que sistemas que têm mais de um fator. Se eles roubarem um banco de dados com contas de usuário e senha com hash de uma pequena loja virtual, eles podem usar as senhas usadas em outros sites. Os usuários tendem a reutilizar contas o tempo todo, porque senhas complexas são difíceis de lembrar. Para um departamento de TI, o gerenciamento de senhas também traz consigo a complexidade de ter que oferecer mecanismos de redefinição, exigindo atualizações frequentes de senhas e armazenando-as de maneira segura.

Para todas as suas desvantagens, a autenticação de fator único dá ao usuário o controle da credencial. Eles criam-no e modificam-no, e apenas um teclado é necessário para o processo de autenticação. Este é o principal aspeto que distingue a autenticação de fator único da autenticação multifator.

2.1.1 Agente de autenticação da Web

Como discutido anteriormente, um dos desafios com a autenticação de senha para um departamento de TI é a sobrecarga adicional de gerenciar a base de nomes de usuário / senhas, mecanismos de redefinição, etc. Uma opção cada vez mais popular é confiar em provedores de identidade de terceiros que oferecem autenticação por meio do OAuth, um padrão aberto para autenticação.

Usando o OAuth, os departamentos de TI podem efetivamente "terceirizar" a complexidade de manter um banco de dados com nomes de usuário e senhas, redefinir a funcionalidade de senha, etc. para um provedor de identidade de terceiros como Facebook, X ou Microsoft.

Os usuários têm controle total sobre sua identidade nessas plataformas, mas os aplicativos podem solicitar um token do provedor, depois que o usuário é autenticado e com seu consentimento, que pode ser usado para autorizar usuários autenticados.

O agente de autenticação da Web no Windows fornece um conjunto de APIs e infraestrutura para que os aplicativos usem protocolos de autenticação e autorização, como OAuth e OpenID. Os aplicações podem iniciar operações de autenticação por meio da API WebAuthenticationBroker , resultando no retorno de um WebAuthenticationResult. Uma visão geral do fluxo de comunicação é ilustrada na figura a seguir.

fluxo de trabalho WAB

O aplicativo atua como o broker, iniciando a autenticação com o provedor de identidade por meio de um WebView no aplicativo. Quando o provedor de identidade autentica o usuário, ele retorna um token para o aplicativo que pode ser usado para solicitar informações sobre o usuário do provedor de identidade. Como medida de segurança, o aplicativo deve ser registrado com o provedor de identidade antes de poder intermediar os processos de autenticação com o provedor de identidade. Essas etapas de registro diferem para cada provedor.

Aqui está o fluxo de trabalho geral para chamar o WebAuthenticationBroker API para se comunicar com o provedor.

  • Construa as cadeias de caracteres de solicitação a serem enviadas ao provedor de identidade. O número de cadeias de caracteres e as informações em cada cadeia de caracteres é diferente para cada serviço Web, mas geralmente inclui duas cadeias de caracteres de URI, cada uma contendo uma URL: uma para a qual a solicitação de autenticação é enviada e outra para a qual o usuário é redirecionado após a conclusão da autorização.
  • Chame WebAuthenticationBroker.AuthenticateAsync, passando as strings de pedido e aguarde pela resposta do provedor de identidade.
  • Chame WebAuthenticationResult.ResponseStatus para obter o estado quando a resposta for recebida.
  • Se a comunicação for bem-sucedida, processe a cadeia de caracteres de resposta retornada pelo provedor de identidade. Se não tiver êxito, processe o erro.

Se a comunicação for bem-sucedida, processe a cadeia de caracteres de resposta retornada pelo provedor de identidade. Se não tiver êxito, processe o erro.

Exemplo de código C# que para este processo está abaixo. Para obter informações e um passo a passo detalhado, consulte WebAuthenticationBroker. Para obter um exemplo de código completo, confira o exemplo WebAuthenticationBroker no GitHub.

string startURL = "https://<providerendpoint>?client_id=<clientid>";
string endURL = "http://<AppEndPoint>";

var startURI = new System.Uri(startURL);
var endURI = new System.Uri(endURL);

try
{
    WebAuthenticationResult webAuthenticationResult = 
        await WebAuthenticationBroker.AuthenticateAsync( 
            WebAuthenticationOptions.None, startURI, endURI);

    switch (webAuthenticationResult.ResponseStatus)
    {
        case WebAuthenticationStatus.Success:
            // Successful authentication. 
            break;
        case WebAuthenticationStatus.ErrorHttp:
            // HTTP error. 
            break;
        default:
            // Other error.
        break;
    }
}
catch (Exception ex)
{
    // Authentication failed. Handle parameter, SSL/TLS, and
    // Network Unavailable errors here. 
}

2.2 Autenticação multifator

A autenticação multifator usa mais de um fator de autenticação. Normalmente, "algo que você sabe", como uma senha, é combinado com "algo que você tem", que pode ser um telefone celular ou um cartão inteligente. Mesmo que um invasor descubra a senha do usuário, a conta ainda estará inacessível sem o dispositivo ou cartão. E se apenas o dispositivo ou cartão estiver comprometido, não é útil para o atacante sem a senha. A autenticação multifator é, portanto, mais segura, mas também mais complexa, do que a autenticação de fator único.

Os serviços que usam autenticação multifator geralmente dão ao usuário uma escolha sobre como receber a segunda credencial. Um exemplo desse tipo de autenticação é um processo comumente usado em que um código de verificação é enviado para o celular do usuário usando SMS.

  • O usuário fornece seu nome de usuário e senha para o provedor de identidade.
  • O provedor de identidade verifica o nome de usuário e a senha como na autorização de fator único e, em seguida, procura o número de telefone celular do usuário armazenado no sistema.
  • O servidor envia uma mensagem SMS contendo um código de verificação gerado para o telemóvel do utilizador.
  • O usuário fornece o código de verificação ao provedor de identidade; através de um formulário apresentado ao utilizador.
  • O provedor de identidade retorna um status de autenticação que indica se a autenticação de ambas as credenciais foi bem-sucedida.
  • Se for bem-sucedida, inicia-se a troca de dados. Caso contrário, o usuário deve ser autenticado novamente.

autenticação de dois fatores

Como você pode ver, esse processo também difere da autenticação de fator único porque a segunda credencial de usuário é enviada ao usuário em vez de ser criada ou fornecida pelo usuário. O usuário não está, portanto, no controle total das credenciais necessárias. Isso também se aplica quando um cartão inteligente é usado como a segunda credencial: a organização é responsável por criá-lo e fornecê-lo ao usuário.

2.2.1 Azure Ative Directory

O Azure Ative Directory (Azure AD) é um serviço de gerenciamento de identidade e acesso baseado em nuvem que pode servir como o provedor de identidade na autenticação de fator único ou multifator. A autenticação do Azure AD pode ser usada com ou sem um código de verificação.

Embora o Azure AD também possa implementar a autenticação de fator único, as empresas geralmente exigem a maior segurança da autenticação multifator. Em uma configuração de autenticação multifator, um usuário autenticado com uma conta do Azure AD tem a opção de ter um código de verificação enviado como uma mensagem SMS para seu telefone celular ou para o aplicativo móvel Azure Authenticator.

Além disso, o Azure AD pode ser usado como um provedor OAuth, fornecendo ao usuário padrão um mecanismo de autenticação e autorização para aplicativos em várias plataformas. Para saber mais, consulte Azure Active Directory e Multi-Factor Authentication no Azure.

2.4 Windows Hello

No Windows, um mecanismo conveniente de autenticação multifator é incorporado ao sistema operacional. O Windows Hello é o novo sistema de início de sessão biométrico incorporado no Windows. Por ser integrado diretamente no sistema operacional, o Windows Hello permite a identificação facial ou por impressão digital para desbloquear os dispositivos dos usuários. O armazenamento seguro de credenciais do Windows protege os dados biométricos no dispositivo.

O Windows Hello fornece uma maneira robusta para um dispositivo reconhecer um usuário individual, que aborda a primeira parte do caminho entre um usuário e um serviço ou item de dados solicitado. Depois que o dispositivo reconhece o usuário, ele ainda deve autenticá-lo antes de determinar se deve conceder acesso a um recurso solicitado. O Windows Hello também fornece autenticação forte de dois fatores (2FA) que é totalmente integrada ao Windows e substitui senhas reutilizáveis pela combinação de um dispositivo específico e um gesto biométrico ou PIN. O PIN é especificado pelo usuário como parte de seu registro de conta da Microsoft.

No entanto, o Windows Hello não é apenas um substituto para os sistemas 2FA tradicionais. É conceitualmente semelhante aos cartões inteligentes: a autenticação é realizada usando primitivas criptográficas em vez de comparações de cadeia de caracteres, e o material da chave do usuário é seguro dentro de hardware inviolável. O Microsoft Hello também não requer os componentes de infraestrutura adicionais necessários para a implantação de cartão inteligente. Em particular, você não precisa de uma PKI (infraestrutura de chave pública) para gerenciar certificados, se não tiver um. O Windows Hello combina as principais vantagens dos cartões inteligentes — flexibilidade de implantação para cartões inteligentes virtuais e segurança robusta para cartões inteligentes físicos — sem nenhuma de suas desvantagens.

Um dispositivo deve ser registrado no Windows Hello para que os usuários possam se autenticar com ele. O Windows Hello usa criptografia assimétrica (chave pública/privada) na qual uma parte usa uma chave pública para criptografar os dados que a outra parte pode descriptografar usando uma chave privada. No caso do Windows Hello, ele cria um conjunto de pares de chaves públicas/privadas e grava as chaves privadas no chip TPM (Trusted Platform Module) do dispositivo. Depois que um dispositivo é registrado, os aplicativos UWP podem chamar APIs do sistema para recuperar a chave pública do usuário, que pode ser usada para registrar o usuário no servidor.

O fluxo de trabalho de registro de um aplicativo pode ter a seguinte aparência:

registo do Windows Hello

As informações de registro que você coleta podem incluir muito mais informações de identificação do que neste cenário simples. Por exemplo, se seu aplicativo acessar um serviço seguro, como um para bancos, você precisará solicitar um comprovante de identidade e outras coisas como parte do processo de inscrição. Uma vez cumpridas todas as condições, a chave pública deste utilizador será armazenada no back-end e utilizada para validar da próxima vez que o utilizador utilizar o serviço.

Para obter mais informações sobre o Windows Hello, consulte a visão geral do Windows Hello for Business e o guia do desenvolvedor do Windows Hello.

3 Métodos de segurança de dados em voo

Os métodos de segurança de dados em voo aplicam-se aos dados em trânsito entre dispositivos ligados a uma rede. Os dados podem ser transferidos entre sistemas no ambiente de alta segurança de uma intranet corporativa privada, ou entre um cliente e um serviço Web no ambiente não seguro da web. Os aplicativos do Windows oferecem suporte a padrões como SSL por meio de suas APIs de rede e trabalham com tecnologias como o Gerenciamento de API do Azure, com as quais os desenvolvedores podem garantir o nível apropriado de segurança para seus aplicativos.

3.1 Autenticação remota do sistema

Existem dois cenários gerais em que a comunicação ocorre com um sistema de computador remoto.

  • Um servidor local autentica um usuário através de uma conexão direta. Por exemplo, quando o servidor e o cliente estão em uma intranet corporativa.
  • Um serviço Web é comunicado através da Internet.

Os requisitos de segurança para a comunicação de serviços Web são mais elevados do que em cenários de ligação direta, uma vez que os dados já não são apenas uma parte de uma rede segura e a probabilidade de atacantes maliciosos procurarem intercetar dados também é maior. Como vários tipos de dispositivos acessarão o serviço, eles provavelmente serão criados como serviços RESTful, ao contrário do WCF, por exemplo, o que significa que a autenticação e a autorização para o serviço também introduzem novos desafios. Discutiremos dois requisitos para a comunicação segura do sistema remoto.

O primeiro requisito é a confidencialidade da mensagem: as informações transmitidas entre o cliente e os serviços Web (por exemplo, a identidade do utilizador e outras informações pessoais) não devem ser legíveis por terceiros durante o trânsito. Isso geralmente é feito criptografando a conexão pela qual as mensagens são enviadas e criptografando a própria mensagem. Na criptografia de chave privada/pública, a chave pública está disponível para qualquer pessoa e é usada para criptografar mensagens a serem enviadas para um destinatário específico. A chave privada é mantida apenas pelo recetor e é usada para desencriptar a mensagem.

O segundo requisito é a integridade da mensagem: o cliente e o serviço Web devem ser capazes de verificar se as mensagens que recebem são as que se destinam a ser enviadas pela outra parte e se a mensagem não foi alterada em trânsito. Isso é feito assinando mensagens com assinaturas digitais e usando autenticação de certificado.

3.2 Conexões SSL

Para estabelecer e manter conexões seguras com clientes, os serviços Web podem usar SSL (Secure Sockets Layer), que é suportado pelo protocolo HTTPS (Secure Hypertext Transfer Protocol). O SSL fornece confidencialidade e integridade da mensagem, suportando criptografia de chave pública, bem como certificados de servidor. O SSL é substituído pelo Transport Layer Security (TLS), mas o TLS é frequentemente referido casualmente como SSL.

Quando um cliente solicita acesso a um recurso em um servidor, o SSL inicia um processo de negociação com o servidor. Isto é chamado de aperto de mão SSL. Um nível de criptografia, um conjunto de chaves de criptografia públicas e privadas e as informações de identidade nos certificados de cliente e servidor são acordados como a base de toda a comunicação durante a conexão SSL. O servidor também pode exigir que o cliente seja autenticado neste momento. Uma vez estabelecida a conexão, todas as mensagens são criptografadas com a chave pública negociada até que a conexão seja fechada.

3.2.1 Fixação SSL

Embora o SSL possa fornecer confidencialidade de mensagens usando criptografia e certificados, ele não faz nada para verificar se o servidor com o qual o cliente está se comunicando é o correto. O comportamento do servidor pode ser imitado por um terceiro não autorizado, intercetando os dados confidenciais que o cliente transmite. Para evitar isso, uma técnica chamada fixação SSL é usada para verificar se o certificado no servidor é o certificado que o cliente espera e confia.

Existem algumas maneiras diferentes de implementar o SSL pinning em aplicações, cada uma com as suas próprias vantagens e desvantagens. A abordagem mais fácil é através da declaração de Certificados no manifesto do pacote da aplicação. Essa declaração permite que o pacote do aplicativo instale certificados digitais e especifique confiança exclusiva neles. Isso resulta em conexões SSL sendo permitidas apenas entre o aplicativo e os servidores que têm os certificados correspondentes em sua cadeia de certificados. Esse mecanismo também permite o uso seguro de certificados autoassinados, já que não é necessária a dependência de terceiros de autoridades de certificação públicas confiáveis.

manifesto ssl

Para obter mais controle sobre a lógica de validação, as APIs estão disponíveis para validar o(s) certificado(s) retornado(s) pelo servidor em resposta a uma solicitação HTTPS. Observe que esse método requer o envio de uma solicitação e a inspeção da resposta, portanto, certifique-se de adicioná-la como uma validação antes de realmente enviar informações confidenciais em uma solicitação.

O código C# a seguir ilustra esse método de fixação SSL. O método ValidateSSLRoot usa a classe HttpClient para executar uma solicitação HTTP. Depois que o cliente envia a resposta, ele usa a coleção RequestMessage.TransportInformation.ServerIntermediateCertificates para inspecionar os certificados retornados pelo servidor. O cliente pode então validar toda a cadeia de certificados com as impressões digitais incluídas. Este método exige que as impressões digitais do certificado sejam atualizadas na aplicação quando o certificado do servidor expirar e for renovado.

private async Task ValidateSSLRoot()
{
    // Send a get request to Bing
    var httpClient = new HttpClient();
    var bingUri = new Uri("https://www.bing.com");
    HttpResponseMessage response = 
        await httpClient.GetAsync(bingUri);

    // Get the list of certificates that were used to
    // validate the server's identity
    IReadOnlyList<Certificate> serverCertificates = response.RequestMessage.TransportInformation.ServerIntermediateCertificates;
  
    // Perform validation
    if (!ValidateCertificates(serverCertificates))
    {
        // Close connection as chain is not valid
        return;
    }
    // Validation passed, continue with connection to service
}

private bool ValidateCertificates(IReadOnlyList<Certificate> certs)
{
    // In this example, we iterate through the certificates
    // and check that the chain contains
    // one specific certificate we are expecting
    foreach (var cert in certs)
    {
        byte[] thumbprint = cert.GetHashValue();

        // Check if the thumbprint matches whatever you 
        // are expecting
        var expected = new byte[] { 212, 222, 32, 208, 94, 102, 
            252, 83, 254, 26, 80, 136, 44, 120, 219, 40, 82, 202, 
            228, 116 };

        // ThumbprintMatches does the byte[] comparison 
        if (ThumbprintMatches(thumbprint, expected))
        {
            return true;
        }
    }
    return false;
}

3.3 Publicação e proteção do acesso às APIs REST

Para garantir o acesso autorizado aos serviços Web, eles devem exigir autenticação sempre que uma chamada de API for feita. Ser capaz de controlar o desempenho e a escala também é algo a considerar quando os serviços da Web são expostos na Web. O Gerenciamento de API do Azure é um serviço que pode ajudar a expor APIs na Web, fornecendo recursos em três níveis.

Publicadores/Administradores da API podem facilmente configurá-la por meio do Portal do Editor do Gerenciamento de API do Azure. Aqui, conjuntos de APIs podem ser criados e o acesso a eles pode ser gerenciado para controlar quem tem acesso a quais APIs.

Desenvolvedores desejam ter acesso a essas APIs podem fazer solicitações por meio do Portal do Desenvolvedor, que pode fornecer acesso imediatamente ou exigir aprovação do editor/administrador. Os desenvolvedores também podem visualizar a documentação da API e o código de exemplo no Portal do Desenvolvedor, para adotar rapidamente as APIs oferecidas pelo serviço Web.

As aplicações que estes desenvolvedores criam acedem à API através do proxy oferecido pelo Azure API Management. O proxy fornece uma camada de obscuridade, ocultando o ponto final real da API no servidor do editor/administrador e também pode incluir lógica adicional, como tradução de API, para garantir que a API exposta seja mantida consistente quando uma chamada para uma API é redirecionada para outra. Ele também pode usar filtragem de IP para bloquear chamadas de API originadas de um domínio IP específico ou conjunto de domínios. O Gerenciamento de API do Azure também mantém seus serviços Web seguros usando um conjunto de chaves públicas, chamadas chaves de API, para autenticar e autorizar cada chamada de API. Quando a autorização falha, o acesso à API e à funcionalidade que ela suporta é bloqueado.

O Gerenciamento de API do Azure também pode reduzir o número de chamadas de API para um serviço (um procedimento chamado limitação) para otimizar o desempenho do serviço Web. Para saber mais, reveja Gerenciamento de API do Azure em e no AzureCon 2015.

Métodos de segurança para dados em repouso

Quando os dados chegam a um dispositivo, referimo-nos a eles como "dados em repouso". Esses dados precisam ser armazenados no dispositivo de forma segura, para que não possam ser acessados por usuários ou aplicativos não autorizados. O modelo de aplicativo no Windows faz muito para garantir que os dados armazenados por qualquer aplicativo só sejam acessíveis a esse aplicativo, enquanto fornece APIs para compartilhar os dados quando necessário. APIs adicionais também estão disponíveis para garantir que os dados possam ser criptografados e as credenciais possam ser armazenadas com segurança.

4.1 Modelo de aplicativo do Windows

Tradicionalmente, o Windows nunca teve uma definição de aplicativo. Era mais comumente referido como um executável (.exe), e isso nunca incluiu instalação, armazenamento de estado, comprimento de execução, versionamento, integração de sistema operacional ou comunicação entre aplicativos. O modelo da Plataforma Universal do Windows define um modelo de aplicativo que abrange instalação, ambiente de tempo de execução, gerenciamento de recursos, atualizações, modelo de dados e desinstalação.

Os aplicativos do Windows 10 são executados em um contêiner, o que significa que eles têm privilégios limitados por padrão (privilégios adicionais podem ser solicitados e concedidos pelo usuário). Por exemplo, se um aplicativo quiser acessar arquivos no sistema, um seletor de arquivos do namespace Windows.Storage.Pickers deverá ser usado para permitir que o usuário escolha um arquivo (nenhum acesso direto aos arquivos está habilitado). Outro exemplo é se uma aplicação quiser aceder aos dados de localização do utilizador, precisa declarar a capacidade do dispositivo de localização, informando o utilizador no momento do descarregamento que esta aplicação irá solicitar acesso à localização do utilizador. Além disso, na primeira vez que o aplicativo quiser acessar a localização do usuário, um prompt de consentimento adicional é mostrado ao usuário, solicitando permissão para acessar os dados.

Observe que esse modelo de aplicativo funciona como uma "prisão" para aplicativos, o que significa que eles não podem entrar em contato, mas não é um "castelo" que não pode ser alcançado do lado de fora (aplicativos com privilégios de administrador ainda podem, é claro, entrar). O Device Guard no Windows, que permite que organizações/TI especifiquem quais aplicativos (Win32) têm permissão para executar, pode ajudar ainda mais a limitar esse acesso.

O modelo de aplicativo também gerencia o ciclo de vida do aplicativo. Ele limita a execução em segundo plano de aplicativos por padrão, por exemplo; Assim que um aplicativo entra em segundo plano, o processo é suspenso – depois de dar ao aplicativo um breve período para lidar com a suspensão do aplicativo no código – e sua memória é congelada. O sistema operacional fornece mecanismos para que os aplicativos solicitem a execução de tarefas específicas em segundo plano (em um cronograma, acionado por vários eventos, como conectividade com Internet/Bluetooth, mudanças de energia, etc., e em cenários específicos, como reprodução de música ou rastreamento GPS).

Quando os recursos de memória no dispositivo estão com pouca energia, o Windows libera espaço de memória encerrando aplicativos. Esse modelo de ciclo de vida força os aplicativos a persistir os dados sempre que eles são suspensos, porque não há tempo adicional disponível entre a suspensão e o encerramento.

Para obter mais informações, consulte É Universal: Compreendendo o Ciclo de Vida de uma Aplicação Windows 10/11.

4.2 Proteção de credenciais armazenadas

Os aplicativos do Windows que acessam serviços autenticados geralmente fornecem aos usuários a opção de armazenar suas credenciais no dispositivo local. Esta é uma conveniência para os usuários; Quando fornecem o seu nome de utilizador e palavra-passe, a aplicação utiliza-os automaticamente em lançamentos subsequentes da aplicação. Como isso pode ser um problema de segurança se um invasor obtiver acesso a esses dados armazenados, o Windows oferece a capacidade de aplicativos empacotados armazenarem credenciais de usuário em um cofre de credenciais seguro. O aplicativo chama a API do Cofre de Credenciais para armazenar e recuperar as credenciais do armário em vez de armazená-las no contêiner de armazenamento do aplicativo. O cofre de credenciais é gerenciado pelo sistema operacional, mas o acesso é limitado ao aplicativo que os armazena, fornecendo uma solução gerenciada com segurança para armazenamento de credenciais.

Quando um usuário fornece as credenciais a serem armazenadas, o aplicativo obtém uma referência ao cofre de credenciais usando o objeto PasswordVault no namespace Windows.Security.Credentials. Em seguida, ele cria um objeto PasswordCredential contendo um identificador para o aplicativo do Windows e o nome de usuário e senha. Isso é passado para o método PasswordVault.Add para armazenar as credenciais no armário. O exemplo de código C# a seguir mostra como isso é feito.

var vault = new PasswordVault();
vault.Add(new PasswordCredential("My App", username, password));

No exemplo de código C# a seguir, o aplicativo solicita todas as credenciais correspondentes ao aplicativo chamando o método FindAllByResource do objeto PasswordVault. Se mais de um for retornado, ele solicitará que o usuário insira seu nome de usuário. Se as credenciais não estiverem no cofre, a aplicação solicitará ao usuário. O usuário é então conectado ao servidor usando as credenciais.

private string resourceName = "My App";
private string defaultUserName;

private void Login()
{
    PasswordCredential loginCredential = GetCredentialFromLocker();

    if (loginCredential != null)
    {
        // There is a credential stored in the locker.
        // Populate the Password property of the credential
        // for automatic login.
        loginCredential.RetrievePassword();
    }
    else
    {
        // There is no credential stored in the locker.
        // Display UI to get user credentials.
        loginCredential = GetLoginCredentialUI();
    }
    // Log the user in.
    ServerLogin(loginCredential.UserName, loginCredential.Password);
}

private PasswordCredential GetCredentialFromLocker()
{
    PasswordCredential credential = null;

    var vault = new PasswordVault();

    IReadOnlyList<PasswordCredential> credentialList = null;

    try
    {
        credentialList = vault.FindAllByResource(resourceName);
    }
    catch(Exception)
    {
        return null;
    }

    if (credentialList.Count == 1)
    {
        credential = credentialList[0];
    }
    else if (credentialList.Count > 0)
    {
        // When there are multiple usernames,
        // retrieve the default username. If one doesn't
        // exist, then display UI to have the user select
        // a default username.
        defaultUserName = GetDefaultUserNameUI();

        credential = vault.Retrieve(resourceName, defaultUserName);
    }
    return credential;
}

Para obter mais informações, consulte Cofre de credenciais.

4.3 Proteção de dados armazenados

Quando você está lidando com dados armazenados, comumente referidos como dados em repouso, criptografá-los pode impedir que usuários não autorizados acessem os dados armazenados. Os dois mecanismos comuns para criptografar dados estão usando chaves simétricas ou usando chaves assimétricas. No entanto, a criptografia de dados não pode garantir que os dados não sejam alterados entre o momento em que foram enviados e o momento em que foram armazenados. Por outras palavras, a integridade dos dados não pode ser assegurada. O uso de códigos de autenticação de mensagens, hashes e assinatura digital são técnicas comuns para resolver esse problema.

4.3.1 Encriptação de dados

Com criptografia simétrica, tanto o remetente quanto o destinatário têm a mesma chave e a usam para criptografar e descriptografar os dados. O desafio com essa abordagem é compartilhar a chave com segurança para que ambas as partes estejam cientes disso.

Uma resposta para isso é a criptografia assimétrica, na qual um par de chaves público/privado é usado. A chave pública é compartilhada livremente com qualquer pessoa que queira criptografar uma mensagem. A chave privada é sempre mantida em segredo para que apenas você possa usá-la para desencriptar os dados. Uma técnica comum para permitir a descoberta da chave pública é usando certificados digitais, também chamados simplesmente de certificados. O certificado contém informações sobre a chave pública, além de informações sobre o usuário ou servidor, como nome, emissor, endereço de e-mail e país/região.

Os desenvolvedores de apps do Windows podem usar as classes SymmetricKeyAlgorithmProvider e AsymmetricKeyAlgorithmProvider para implementar criptografia simétrica e assimétrica nos seus aplicativos UWP. Além disso, a classe CryptographicEngine pode ser usada para criptografar e descriptografar dados, assinar conteúdo e verificar assinaturas digitais. Os aplicativos também podem usar a classe DataProtectionProvider no namespace Windows.Security.Cryptography.DataProtection para criptografar e descriptografar dados locais armazenados.

4.3.2 Deteção de adulteração de mensagens (MACs, hashes e assinaturas)

Um MAC é um código (ou tag) que resulta do uso de uma chave simétrica (chamada de chave secreta) ou uma mensagem como entrada para um algoritmo de criptografia MAC. A chave secreta e o algoritmo são acordados entre o emissor e o recetor antes da transferência da mensagem.

Os MACs verificam mensagens como esta.

  • O remetente deriva a tag MAC usando a chave secreta como entrada para o algoritmo MAC.
  • O remetente envia a tag MAC e a mensagem para o recetor.
  • O recetor deriva a tag MAC usando a chave secreta e a mensagem como entradas para o algoritmo MAC.
  • O recetor compara sua tag MAC com a tag MAC do remetente. Se forem os mesmos, então sabemos que a mensagem não foi adulterada.

verificação MAC

Os aplicativos do Windows podem implementar a verificação de mensagens MAC chamando a classe MacAlgorithmProvider para gerar a chave e classe CryptographicEngine para executar o algoritmo de criptografia MAC.

4.3.3 Usando hashes

Uma função de hash é um algoritmo criptográfico que usa um bloco arbitrariamente longo de dados e retorna uma cadeia de caracteres de bit de tamanho fixo chamada valor de hash. Há toda uma família de funções hash que podem fazer isso.

Um valor de hash pode ser usado no lugar de um MAC no cenário de transferência de mensagens acima. O remetente envia um valor de hash e uma mensagem, e o recetor deriva seu próprio valor de hash do valor de hash e da mensagem do remetente e compara os dois valores de hash. Os aplicativos em execução no Windows podem chamar a classe HashAlgorithmProvider para enumerar os algoritmos de hash disponíveis e executar um deles. A classe CryptographicHash representa o valor de hash. O método CryptographicHash.GetValueAndReset pode ser usado para hash repetidamente dados diferentes sem ter que recriar o objeto para cada uso. O método Append da classe CryptographicHash adiciona novos dados a um buffer para ser hash. Todo esse processo é mostrado no exemplo de código C# a seguir.

public void SampleReusableHash()
{
    // Create a string that contains the name of the
    // hashing algorithm to use.
    string strAlgName = HashAlgorithmNames.Sha512;

    // Create a HashAlgorithmProvider object.
    HashAlgorithmProvider objAlgProv = HashAlgorithmProvider.OpenAlgorithm(strAlgName);

    // Create a CryptographicHash object. This object can be reused to continually
    // hash new messages.
    CryptographicHash objHash = objAlgProv.CreateHash();

    // Hash message 1.
    string strMsg1 = "This is message 1";
    IBuffer buffMsg1 = CryptographicBuffer.ConvertStringToBinary(strMsg1, BinaryStringEncoding.Utf16BE);
    objHash.Append(buffMsg1);
    IBuffer buffHash1 = objHash.GetValueAndReset();

    // Hash message 2.
    string strMsg2 = "This is message 2";
    IBuffer buffMsg2 = CryptographicBuffer.ConvertStringToBinary(strMsg2, BinaryStringEncoding.Utf16BE);
    objHash.Append(buffMsg2);
    IBuffer buffHash2 = objHash.GetValueAndReset();

    // Convert the hashes to string values (for display);
    string strHash1 = CryptographicBuffer.EncodeToBase64String(buffHash1);
    string strHash2 = CryptographicBuffer.EncodeToBase64String(buffHash2);
}

4.3.4 Assinaturas digitais

A integridade dos dados de uma mensagem armazenada assinada digitalmente é verificada de forma semelhante à autenticação MAC. Aqui está a maneira como o fluxo de trabalho de assinatura digital opera.

  • O remetente deriva um valor de hash (também conhecido como resumo) usando a mensagem como entrada para um algoritmo de hash.
  • O remetente criptografa o resumo usando sua chave privada.
  • O remetente envia a mensagem, o resumo criptografado e o nome do algoritmo de hash que foi usado.
  • O recetor usa a chave pública para desencriptar o resumo encriptado que recebeu. Em seguida, ele usa o algoritmo de hash para transformar a mensagem em um resumo próprio. E, finalmente, o recetor compara os dois resumos (o que recebeu e desencriptou e o que fez). Somente se os dois coincidirem é que o recetor pode ter certeza de que a mensagem foi enviada pelo detentor da chave privada e, portanto, eles são quem dizem ser, e que a mensagem não foi alterada em trânsito.

assinaturas digitais

Os algoritmos de hash são muito rápidos, de modo que os valores de hash podem ser derivados rapidamente até mesmo de mensagens grandes. O valor de hash resultante é um comprimento arbitrário e pode ser menor do que a mensagem completa, portanto, usar chaves públicas e privadas para criptografar e descriptografar apenas o resumo em vez da mensagem completa é uma otimização.

Para obter mais informações, consulte os artigos sobre assinaturas digitais , MACs, hashes e assinaturas , e Criptografia .

5 Resumo

A Plataforma Universal do Windows no Windows oferece várias maneiras de aproveitar os recursos do sistema operacional para criar aplicativos mais seguros. Em diferentes cenários de autenticação, como autenticação de fator único, multifator ou intermediada com um provedor de identidade OAuth, as APIs existem para mitigar os desafios mais comuns com a autenticação. O Windows Hello fornece um novo sistema de entrada biométrica que reconhece o usuário e derrota ativamente os esforços para contornar a identificação adequada. Ele também oferece várias camadas de chaves e certificados que nunca podem ser revelados ou usados fora do módulo de plataforma confiável. Além disso, uma camada adicional de segurança está disponível através do uso opcional de chaves de identidade e certificados de atestado.

Para proteger os dados em voo, as APIs existem para se comunicar com sistemas remotos de forma segura por SSL, ao mesmo tempo em que oferecem a possibilidade de validar a autenticidade do servidor com a fixação SSL. Publicar APIs de forma segura e controlada é algo no qual o Gerenciamento de API do Azure ajuda fornecendo opções de configuração poderosas para expor APIs na Web usando um proxy que fornece ofuscação adicional do ponto de extremidade da API. O acesso a essas APIs é protegido usando chaves de API e as chamadas de API podem ser limitadas para controlar o desempenho.

Quando os dados chegam ao dispositivo, o modelo de aplicativo do Windows fornece mais controle sobre como o aplicativo é instalado, atualizado e acessa seus dados, evitando que ele acesse dados de outros aplicativos de maneira não autorizada. O cofre de credenciais pode fornecer armazenamento seguro de credenciais de usuário que é gerenciado pelo sistema operacional e outros dados podem ser protegidos no dispositivo usando as APIs de criptografia e hash oferecidas pela Plataforma Universal do Windows.

6 recursos

6.1 Artigos de instruções

6.2 Exemplos de código

6.3 Referência da API