Introdução ao desenvolvimento de aplicativos seguros do Windows

Artigo
07/08/2024

Este artigo introdutório ajuda 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 transição 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 desafiador. No mundo acelerado de aplicativos móveis, sociais, de nuvem e empresariais complexos de hoje, os clientes esperam que os aplicativos fiquem disponíveis e 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) do Windows, 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 com segurança, 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 dão suporte ao 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 os seus recursos e os do sistema local ou remoto.

Durante a autenticação, a identidade de um usuário que solicita acesso a um serviço específico é 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 PIN (número de identificação pessoal) ou biometria, como impressões digitais, rosto ou íris do usuário para implementar a autenticação multifator para seus aplicativos.

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

Por fim, os dados em repouso referem-se aos dados que residem na memória ou na mídia 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 intimamente relacionadas, podendo ser indistinguíveis para usuários. Elas podem ser operações relativamente simples ou complexas, dependendo de muitos fatores: por exemplo, se os dados residem em um servidor ou estão distribuídos em vários sistemas. O servidor que fornece os serviços de autenticação e autorização é chamado de provedor de identidade.

Para se autenticar com um determinado serviço e/ou aplicativo, o usuário emprega credenciais compostas por algo que conhece, 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 de perguntas e respostas "secreto".
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 o usuário é muitas vezes engloba suas impressões digitais, mas há fatores cada vez mais populares, como a fala do usuário, características faciais, oculares (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 senha pode se passar pelo usuário que a possui. Um cartão inteligente pode fornecer um nível mais alto 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 aspecto complexo e importante da segurança de dados. Em geral, quanto maior o número de fatores usados na autenticação, mais seguro é o sistema. Ao mesmo tempo, a autenticação deve ser utilizável. Usuários geralmente fazem logon muitas vezes ao dia, então o processo deve ser rápido. Sua escolha de tipo de autenticação é uma compensação entre segurança e facilidade de uso; a autenticação de fator único é a menos segura e mais fácil de usar, e a autenticação multifator é mais segura, mas mais complexa à medida que mais fatores são adicionados.

1.2 Autenticação de fator único

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

Este é 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 ela foi bem-sucedida.
Se for bem-sucedida, a troca de dados será iniciada. Se não for bem-sucedida, o usuário deverá ser autenticado novamente.

autenticação de fator único

Hoje, esse método de autenticação é o mais usado em serviços. É também a forma menos segura de autenticação quando usada como o ú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 sobrecarregam os usuários e não são um impedimento eficaz contra hackers.

O desafio das senhas é que é mais fácil adivinhá-las com sucesso do que sistemas que têm mais de um fator. Se agentes maliciosos roubarem um banco de dados com contas de usuário e senhas 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, exigir atualizações frequentes de senhas e armazená-las de maneira segura.

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

2.1.1 Agente de autenticação da Web

Como abordado anteriormente, um dos desafios da 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 é contar com provedores de identidade de terceiros que oferecem autenticação por meio do OAuth, um padrão aberto para autenticação.

Ao usar 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 aplicativos 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 do WAB

O aplicativo atua como o agente, 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.

Este é o fluxo de trabalho geral para chamar a API WebAuthenticationBroker 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 cadeias de caracteres de solicitação e aguarde a resposta do provedor de identidade.
Chame WebAuthenticationResult.ResponseStatus para obter o status 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# para esse processo abaixo. Para obter informações e um tutorial 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 faz uso de 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 invasor 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 ele recebe 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 através de 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 celular do usuário.
O usuário fornece o código de verificação para o provedor de identidade; através de um formulário apresentado ao usuário.
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, a troca de dados será iniciada. Caso contrário, o usuário deverá ser autenticado novamente.

autenticação de dois fatores

Como você pode ver, esse processo também difere da autenticação de fator único, pois 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 Active Directory

O Azure Active Directory (Azure AD) é um serviço de gerenciamento de acesso e identidade baseado em nuvem que pode servir como 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 que se autentica 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 Autenticação multifator no Azure.

2.4 Windows Hello

No Windows, um mecanismo de autenticação multifator conveniente é integrado ao sistema operacional. O Windows Hello é o novo sistema de entrada biométrica integrado ao Windows. Por ser integrado diretamente ao sistema operacional, o Windows Hello permite a identificação facial ou por impressão digital para desbloquear os dispositivos dos usuários. O armazenamento de credenciais seguras 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 deseja conceder acesso a um recurso solicitado. O Windows Hello também fornece autenticação forte de dois fatores (2FA) 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 do registro de sua conta da Microsoft.

No entanto, o Windows Hello não é apenas um substituto para os sistemas 2FA tradicionais. Ele é conceitualmente semelhante aos cartões inteligentes: a autenticação é realizada usando primitivos criptográficos em vez de comparações de cadeia de caracteres, e o material de chave do usuário fica protegido dentro de hardware resistente a violações. O Microsoft Hello também não requer os componentes de infraestrutura extra 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 uma no momento. 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.

Dispositivos deve ser registrados no Windows Hello para que os usuários possam se autenticar com eles. 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ública/privada 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:

Registro 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 serviços bancários, você precisará solicitar prova de identidade e outras coisas como parte do processo de inscrição. Uma vez que todas as condições sejam atendidas, a chave pública desse usuário será armazenada no back-end e usada para validar na próxima vez que o usuário usar o serviço.

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

3 Métodos de segurança de dados em trânsito

Os métodos de segurança de dados em trânsito aplicam-se aos dados sendo migrados entre dispositivos conectados 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 dão suporte a padrões como SSL por meio de suas APIs de rede e funcionam 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

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

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

Os requisitos de segurança para comunicação de serviço Web são mais altos do que aqueles em cenários de conexão direta, pois os dados não são mais apenas uma parte de uma rede segura e a probabilidade de invasores maliciosos que procuram interceptar 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. Abordaremos dois requisitos para a comunicação segura do sistema remoto.

O primeiro requisito é a confidencialidade da mensagem: as informações passadas entre o cliente e os serviços da Web (por exemplo, a identidade do usuário 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 a um receptor específico. A chave privada é mantida apenas pelo receptor e é usada para descriptografar a mensagem.

O segundo requisito é a integridade da mensagem: o cliente e o serviço da Web devem ser capazes de verificar se as mensagens que recebem são as que devem 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 ao oferecer suporte à criptografia de chave pública, bem como certificados de servidor. O SSL é substituído pelo Transport Layer Security (TLS), mas ele é muitas vezes casualmente referido como SSL.

Quando um cliente solicita acesso a um recurso em um servidor, o SSL inicia um processo de negociação com o servidor. Isso é chamado de handshake 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 definidos 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 que a conexão é estabelecida, todas as mensagens são criptografadas com a chave pública negociada até que a conexão seja fechada.

3.2.1 Fixação de 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, interceptando 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 a fixação SSL em aplicativos, cada uma com seus próprios prós e contras. A abordagem mais fácil é por meio da declaração de certificados no manifesto do pacote do aplicativo. 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, pois não é necessária 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 de 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. Esse método exige que as impressões digitais do certificado sejam atualizadas no aplicativo 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, ao mesmo tempo em que fornece recursos em três níveis.

Os editores/administradores da API podem configurar facilmente a API por meio do Portal do Publicador do Gerenciamento de API do Azure. Aqui, os conjuntos de APIs podem ser criados e o acesso a eles pode ser gerenciado para controlar quem tem acesso a quais APIs.

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

Os aplicativos criados por esses desenvolvedores acessam a API por meio do proxy oferecido pelo Gerenciamento de API do Azure. O proxy fornece uma camada de obscuridade, ocultando o ponto de extremidade 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 for redirecionada para outra. Ele também pode usar a 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 da 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 à qual ela oferece suporte é 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, consulte Gerenciamento de API do Azure e Gerenciamento de API do Azure no AzureCon 2015.

4 Métodos de segurança de dados em repouso

Quando os dados chegam a um dispositivo, nos referimos 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 sejam acessíveis apenas a esse aplicativo, ao mesmo tempo em que 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 usou aplicativos. Os programas eram mais comumente referido como executáveis (.exe), e isso nunca incluía instalação, armazenamento de estado, duração de execução, controle de versão, integração do 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 um aplicativo quiser acessar os dados de localização do usuário, ele precisa habilitar o recurso do dispositivo de localização precisa ser declarado, solicitando ao usuário no momento do download que esse aplicativo solicitará acesso à localização do usuário. Além disso, na primeira vez que o aplicativo deseja 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 "cadeia" 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 de fora (aplicativos com privilégios de administrador ainda podem entrar). O Device Guard no Windows, que permite que as organizações/TI especifiquem quais aplicativos (Win32) têm permissão para serem executados, 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 abordar 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 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 acabando, o Windows libera espaço de memória encerrando aplicativos. Esse modelo de ciclo de vida força os aplicativos a persistirem os dados sempre que forem suspensos, pois 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 um aplicativo do 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. Isso é uma comodidade para os usuários; quando eles fornecem seu nome de usuário e senha, o aplicativo os usa automaticamente em lançamentos subsequentes do aplicativo. Como isso pode ser um problema de segurança se um invasor obtiver acesso a esses dados armazenados, o Windows fornece 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 armazena as credenciais, 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 cofre. O código C# de exemplo 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 armário, o aplicativo solicitará ao usuário que as forneça. Em seguida, o usuário é 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, confira Cofre de Credenciais.

4.3 Proteção de dados armazenados

Quando você está lidando com dados armazenados, comumente chamados de 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 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. Em outras palavras, a integridade dos dados não pode ser garantida. Usar códigos de autenticação de mensagem, hashes e assinatura digital são técnicas comuns para resolver esse problema.

4.3.1 Criptografia de dados

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

Uma resposta para isso é a criptografia assimétrica, na qual um par de chaves pública/privada é 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 descriptografar os dados. Uma técnica comum para permitir a descoberta da chave pública é o uso de 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 email e país.

Os desenvolvedores de aplicativos do Windows podem usar as classes SymmetricKeyAlgorithmProvider e AsymmetricKeyAlgorithmProvider para implementar criptografia simétrica e assimétrica em 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 Detecção de adulteração de mensagens (MACs, hashes e assinaturas)

O MAC é um código (ou marcação) 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 combinados entre o remetente e o destinatário antes da transferência da mensagem.

Os MACs verificam mensagens da seguinte forma.

O remetente deriva a marcação MAC usando a chave secreta como entrada para o algoritmo MAC.
O remetente envia a marcação MAC e a mensagem para o receptor.
O receptor deriva a marcação MAC usando a chave secreta e a mensagem como entradas para o algoritmo MAC.
O receptor compara sua marcação MAC com a marcação MAC do remetente. Se forem iguais, 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 a classe CryptographicEngine para executar o algoritmo de criptografia MAC.

4.3.3 Uso de 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 bits de tamanho fixo chamada valor de hash. Há toda uma família de funções de 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 receptor 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 fazer hash repetidamente de dados diferentes sem precisar recriar o objeto para cada uso. O método Append da classe CryptographicHash adiciona novos dados a um buffer a ser transformado em 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. Esta é 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 usado.
O receptor usa a chave pública para descriptografar o resumo criptografado que recebeu. Em seguida, ele usa o algoritmo de hash para fazer hash da mensagem para criar um resumo próprio. E, finalmente, o receptor compara os dois resumos (o que recebeu e descriptografou, e o que fez). Somente se os dois corresponderem o receptor pode ter certeza de que a mensagem foi enviada pelo possuidor 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 agenciada com um provedor de identidade OAuth, as APIs existem para atenuar os desafios mais comuns com a autenticação. O Windows Hello fornece um novo sistema de entrada biométrico que reconhece o usuário e nulifica ativamente os esforços para contornar a identificação adequada. Ele também fornece 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 por meio do uso opcional de chaves de identidade de atestado e certificados.

Para proteger os dados em trânsito, 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 de 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 ele é instalado, atualizado e como acessa seus dados, ao mesmo tempo em que impede 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.

Partilhar via