Artigo
04/09/2018

Março de 2018

Volume 33 – Número 3

Azure: Proteger Informações Comerciais Confidenciais com o Azure Key Vault

O Azure Key Vault é um serviço baseado em nuvem que oferece a empresas a possibilidade de armazenar informações confidenciais de forma segura. Ele permite que você realize operações de criptografia nos dados, e fornece uma estrutura para implementar políticas e regulamentar o acesso a aplicativos, assim como um modelo de API para que aplicativos funcionem com as chaves, segredos e certificados armazenados nela. Os SDKs que o Azure Key Vault fornece dão suporte a uma variedade de plataformas de dispositivos e linguagens de programação, permitindo que você escolha sua linguagem preferida e implemente esses aplicativos no Serviço de Aplicativo do Azure como aplicativos Web gerenciados. Para expor esses aplicativos de negócios de forma segura para usuários tanto em uma organização quanto fora dela, o Azure Active Directory (Azure AD) e o Azure Active Directory B2C (Azure AD B2C) fornecem implementações turnkey para permitir a autenticação e a autorização nos aplicativos com o mínimo de códigos personalizados ou nenhum. Neste artigo, apresentarei uma solução que demonstra como o Azure Key Vault pode fornecer segurança aprimorada à sua organização.

Cenário de casos de uso

Uma agência central recebeu a tarefa de implementar uma solução para emitir, rastrear e gerenciar apólices de seguros para automóveis. A agência gera números de série únicos para cada documento mediante a recepção dos pedidos e pagamentos das empresas de seguros. Essas empresas, seja diretamente ou por meio de seus agentes, atribuem apólices de seguro aos números de série dos documentos quando uma apólice é vendida a um motorista. Os números de série dos documentos são únicos em todas as empresas de seguros.

O objetivo da solução é rastrear o ciclo de vida do número de série do documento. Ao ser criado, um número de série de um documento contém apenas seu número e o nome da empresa de seguros para a qual ele foi vendido. Além do processo empresarial, serão adicionadas informações complementares, como o registro do veículo, número de documento da apólice, identidade do cliente e período de validade da apólice de seguro. Todas as versões desse registro devem ser rastreadas, incluindo todas as alterações feitas, a data e hora da alteração, assim como a identidade do aplicativo que efetuou a alteração.

Os clientes devem ser capazes de acessar a apólice eletronicamente e baixar as informações de forma segura para verificação e consulta com facilidade.

Arquitetura da Solução

A solução usa o Azure Key Vault para armazenar o número de série do documento, junto com as propriedades da apólice de seguro associada, como um segredo. Para segurança adicional, os dados que são armazenados como um segredo são criptografados de antemão usando chaves assimétricas geradas no Azure Key Vault. Enquanto só é necessária uma quantidade de dados mínima para proteger e validar cada apólice capturada no segredo, são armazenadas informações de suporte complementares em um Banco de Dados SQL do Azure. O banco de dados também implementa restrições nos dados, para assegurar, por exemplo, que o veículo registrado tem um único número de apólice ativo, que o mesmo número de apólice não foi usado para vários registros e assim por diante. A Figura 1 representa a arquitetura usada na solução.

Figura 1 - Arquitetura da solução

Implementei dois aplicativos de portal nesta solução, um que é usado pela agência central e seguradoras, e o outro pelos clientes que compram as apólices de seguro e pelas autoridades reguladoras que precisam verificar a validade das apólices.

O portal do administrador e o portal do cliente são aplicativos ASP.NET 2.0 Core MVC que usam o Entity Framework para armazenar dados das apólices em um Banco de Dados SQL do Azure, depois de terem sido armazenados primeiro no Azure Key Vault. O SDK .NET para o Azure Key Vault é usado para realizar operações criptográficas nos dados, como a criação de segredos e suas versões e a criptografia e descriptografia dos segredos usando chaves. Os usuários do portal do administrador são autenticados com o Azure AD, enquanto os clientes, que são usuários externos, usam o Azure AD B2C para se registrarem e entrarem no portal do cliente.

As entidades de serviço separadas no Azure AD são criadas para os portais do administrador e do cliente, e as apólices separadas são definidas para bloquear seu acesso a operações no Azure Key Vault. A política do portal do administrador permite a criação de chaves e segredos, assim como o desempenho de operações como a criptografia e a descriptografia de dados. Por outro lado, o portal do cliente é atribuído a uma política que permite somente a operação “get” em um segredo e a operação “decrypt” no segredo recuperado. Isso assegura que os aplicativos individuais não tenham mais acesso do que o necessário ao Azure Key Vault.

Para maior segurança, primeiro, os dados da apólice armazenados como um segredo no Azure Key Vault são criptografados. Toda vez que o segredo é atualizado, uma nova versão é criada e as versões anteriores dos dados são preservadas. Uma trilha de auditoria também é mantida para todas as operações realizadas no Key Vault, que são arquivadas para atender aos requisitos legais de conformidade.

O pacote de atributos dos segredos armazenados no Azure Key Vault captura as datas de início e de fim da apólice, que são usadas para verificar sua validade. Os parâmetros de tipo de conteúdo e de marca dos segredos são usados para armazenar informações adicionais pertencentes à apólice de seguro.

O trecho de código a seguir mostra como os atributos, marcas e tipos de conteúdo são adicionados aos dados da apólice armazenados como um segredo:

SecretAttributes attribs = new SecretAttributes
  {
    Enabled = true,
    Expires = DateTime.UtcNow.AddYears(1),
    NotBefore = DateTime.UtcNow.AddDays(1)
  };
IDictionary<string, string> alltags = new Dictionary<string, string>();
alltags.Add("InsuranceCompany", policydata.Inscompany);
string contentType = "DigitalInsurance";
SecretBundle bundle= await _keyVaultClient.SetSecretAsync(keyVaultUri, 
  policydata.Uidname,encrypteddata,alltags,contentType,attribs);

Implementando o cenário de caso de uso

Vejamos mais de perto o cenário de caso de uso que foi implementado pela solução. Aqui estão as etapas básicas:

Compra de códigos únicos pela empresa de seguros: Ao receber os pedidos das empresas de seguros, a agência central usa o portal do administrador para gerar um inventário de números de série de documentos e os armazena como segredos no Azure Key Vault. O portal do administrador cria a primeira versão de um segredo no Azure Key Vault e, em seguida, cria um registro no Banco de Dados SQL do Azure.

Criação da apólice: Quando um cliente compra uma apólice de seguro automóvel, um segredo não atribuído à etapa anterior é selecionado e são adicionadas informações complementares, como o número de registro do veículo, a identidade do cliente, o número do documento da apólice gerado e o período de validade da apólice. Uma nova versão do segredo original contendo essas informações adicionais é criada no processo, e o registro correspondente no Banco de Dados SQL do Azure também é atualizado.

Ativação da apólice pelo cliente: Assim que todos os detalhes de uma apólice são capturados no segredo, uma notificação é enviada ao cliente (fora do escopo deste artigo) com instruções para ativar a apólice. Os usuários se registram no portal do cliente seja usando suas credenciais sociais ou as credenciais armazenadas no Azure AD B2C. Quando o cliente está conectado ao portal, os detalhes da apólice são exibidos, junto com uma opção para ativá-la. Na ativação, o usuário baixa um código QR do portal e associa sua imagem ao veículo assegurado.

Validação da apólice: Os clientes ou autoridades reguladoras podem validar a apólice a qualquer momento usando um aplicativo nativo do Xamarin que lê o código QR no veículo e exibe os detalhes da apólice, para ser contabilizado com os detalhes do veículo. Esta validação não requer conexão com a Internet e pode ser realizada offline. Quando conectado com a Internet, é possível realizar uma validação adicional. O aplicativo nativo invoca uma API REST que é exposta no aplicativo MVC do portal do cliente, transmitindo os dados do código QR. Primeiro, a API compara esses dados com os contidos no Banco de Dados SQL do Azure e também com os dados armazenados no segredo no Azure Key Vault.

Aspectos técnicos da solução

Agora, vamos mergulhar no código-fonte e nos scripts de automação usados na solução. Lembre-se de que o código e os scripts compartilhados neste artigo não são, de forma alguma, uma solução completa ou necessariamente tratam de todas as validações, exceções ou melhores práticas necessárias em um aplicativo pronto para produção. Em vez disso, eles têm a finalidade de ilustrar aspectos específicos de uma área tecnológica ou dar orientação para o desenvolvimento de uma solução completa.

Criar e configurar o Azure Key Vault Os arquivos de script do PowerShell PrepareContosoAKV.ps1 e PrepareContosousersAKV.ps1, incluídos no download, são usados para fornecer e configurar o cofre de chaves usado neste artigo. Eis o que eles conseguiram:

A criação de certificados autoassinados (para serem usado somente em cenários de desenvolvimento) para aplicativos MVC ASP.NET do portal de administração e do cliente, que são usados durante a criação das entidade de serviço no Azure AD.
A criação de uma entidade de serviço no Azure AD que está atribuída ao portal de administração. A política de acesso que é definida para esta entidade de serviço permite a criação e a atualização de chaves e segredos, assim como o desempenho de operações como criptografia e descriptografia:

# Specify privileges to the vault for the Admin Portal application
Set-AzureRmKeyVaultAccessPolicy -VaultName $vaultName `
  -ObjectId $servicePrincipal.Id `
  -PermissionsToKeys all `
  -PermissionsToSecrets all

A criação de uma entidade de serviço no Azure AD que está atribuída ao portal do cliente. A política de acesso que é definida por esta entidade de serviço permite operações Get em chaves e segredos, bem como a descriptografia de dados:

# Specify privileges to the vault for the Customer Portal application
Set-AzureRmKeyVaultAccessPolicy -VaultName $vaultName `
  -ObjectId $servicePrincipal.Id `
  -PermissionsToKeys get,list,decrypt `
  -PermissionsToSecrets get,list

Observe que há uma alternativa para criar essas entidades de serviço com o PowerShell, que é usar o recurso Identidade de Serviço Gerenciada no Serviço de Aplicativo do Azure. Aliás, isso é recomendável. Para obter mais detalhes, consulte as diretrizes em bit.ly/2BgB6mu.
A criação de uma chave usada para a criptografia e descriptografia de um segredo.
A criação de um segredo que armazena a cadeia de conexão no Banco de Dados SQL do Azure. (Isso pode ser feito diretamente no Portal do Azure, assim como outras etapas.)

Para simplificar, esta solução usa um único cofre de chaves e um único conjunto de chaves para todas as empresas de seguros e corretores para criptografar e descriptografar os dados. No mundo real, para adicionar isolamento e segurança à solução, devem ser criadas instâncias do Azure Key Vault para cada empresa de seguros, e agrupadas por região, por exemplo, ou qualquer outro critério. Isso garante que os dados mantidos por uma empresa de seguros não possam ser lidos por outras pessoas, pois não compartilhariam a mesma chave de criptografia.

Lembre-se de que os segredos armazenados no Azure Key Vault não devem ter mais de 25KB de tamanho. Consequentemente, para evitar sobrecarga, somente algumas propriedades dos dados da apólice são armazenados nele, como a ID (número de série do documento), nome do segredo, ID do usuário, número da apólice e ID da empresa de seguros. O arquivo Entity Insdata.cs na solução do Visual Studio 2017 ContosoInsAuthorityAdminPortal.sln contém essas propriedades. Outras propriedades, como as datas efetivas de início e de fim, o tipo de conteúdo, e assim por diante, são armazenadas como atributos do segredo no cofre de chaves.

Compilar os aplicativos do portal de administração e do cliente Consulte a solução do Visual Studio 2017 ContosoInsAuthorityAdminPortal.sln no download para o código-fonte do portal de administração, e ContosoinsExtPortal.sln para o código do portal do cliente.

Tanto o portal de administração quanto o do cliente são compilados usando o ASP.NET Core 2.0, que oferece suporte à injeção de dependência para adicionar serviços de estrutura — como a integração do Entity Framework e de módulos do serviço personalizado para acessar as APIs do Azure Key Vault — ao aplicativo na classe de inicialização.

Os modelos do projeto do Visual Studio 2017 fornecem integração turnkey com o Azure AD e o Azure AD B2C para experiências de conexão e inscrição do usuário para proteger o acesso aos aplicativos do portal.

A cadeia de conexão para o Banco de Dados SQL do Azure é armazenada no Azure Key Vault e é recuperada pelo portal do aplicativo Web na inicialização.

O trecho de código na Figura 2 mostra como a injeção de dependência no ASP.NET 2.0 Core é adicionada para a autenticação do Azure AD no Entity Framework e, para o provedor de acesso, a API do serviço Azure Key Vault, para acessar e ler os dados de configuração do aplicativo no appsettings.json.

Figura 2 - Estrutura de dependência no aplicativo MVC no ASP.NET Core 2.0

// This method gets called by the runtime. Use this method to add services to the container.
public void ConfigureServices(IServiceCollection services)
  {
    //Adding the Azure AD integration for User authentication
    services.AddAuthentication(sharedOptions =>
    {
      sharedOptions.DefaultScheme =
        CookieAuthenticationDefaults.AuthenticationScheme;
      sharedOptions.DefaultChallengeScheme =
        OpenIdConnectDefaults.AuthenticationScheme;
    })
    .AddAzureAd(options => Configuration.Bind("AzureAd", options))
    .AddCookie();
    services.AddMvc();
// Add the Key Vault Service Client Connection to the Context Object
    AKVServiceClient servClient =
      new AKVServiceClient(Configuration["AzureKeyVault:ClientIdWeb"],
      Configuration["AzureKeyVault:AuthCertThumbprint"],
      Configuration["AzureKeyVault:VaultName"],
      Configuration["AzureKeyVault:KeyName"]);
    services.AddSingleton<AKVServiceClient>(servClient);
// Get the Connection string to Azure SQL Database
// from the secret in Azure Key Vault
    string connection = servClient.GetDbConnectionString();
// Add the Azure SQL Database Connection to the Context Object
    services.AddDbContext<ContosoinsauthdbContext>(options =>
      options.UseSqlServer(connection));
    services.AddOptions();
  }

O provedor de configuração do Azure Key Vault do ASP.NET Core 2.0 (bit.ly/2DfOXeq), disponível como pacote NuGet, oferece uma implementação turnkey para recuperar todos os segredos do Azure Key Vault na inicialização do aplicativo. No entanto, este recurso não é usado na solução para evitar o carregamento de todos os dados empresariais desnecessariamente na inicialização do aplicativo, ou seja, os segredos da apólice de seguro, junto com outros segredos que o aplicativo requer, como a cadeia de conexão para acessar o Banco de Dados SQL do Azure. Os recursos poderão ser usados quando uma instância do cofre de chaves for usada para armazenar todas as cadeias de conexão necessárias pelo aplicativo, e uma instância de cofre de chaves for usada para os dados corporativos.

Criação do Serviço de Aplicativo Os aplicativos do portal do administrador e do cliente são implantados como aplicativos Web do Serviço de Aplicativo do Azure usando as ferramentas integradas no Visual Studio 2017. Os dois aplicativos Web são hospedados dentro de um único plano de Serviço de Aplicativo.

Durante o desenvolvimento, os aplicativos MVC ASP.NET Core podem ser implantados localmente usando o Visual Studio 2017. Quando os scripts do PowerShell que eu mencionei anteriormente são executados, dois certificados digitais são gerados, um para cada aplicativo do portal. Os arquivos .pfx são adicionados ao repositório de certificados do usuário atual. Eles são incluídos nas solicitações que os aplicativos MVC ASP.NET fazem para acessar as APIs do Azure Key Vault. As impressões digitais desses certificados são adicionadas ao arquivo appsettings.json na solução do Visual Studio 2017 dos respectivos aplicativos MVC ASP.NET.

Ao implantar o aplicativo ao Serviço de Aplicativo do Azure, você deve:

Carregue os dois arquivos .pfx para a instância do Serviço de Aplicativo do Portal do Azure.
Crie uma entrada “WEBSITE_LOAD_CERTIFICATES” nas folhas Configurações do Aplicativo dos aplicativos Web do portal do administrador e do cliente no Portal do Azure, e adicione a impressão digital do respectivo arquivo .pfx.

Consulte a documentação em bit.ly/2mVEKOq para obter mais detalhes sobre as etapas a serem realizadas.

Criação de banco de dados O arquivo de script usado para criar o banco de dados para a solução está disponível para download junto com os outros artefatos da solução. A Transparent Data Encryption (TDE) e a auditoria estão habilitadas no banco de dados.

Criação de locatário do Azure AD e Azure AD B2C O locatário padrão do Azure AD na assinatura do Azure é usado como provedor de identidade para os usuários internos da agência central que acessa o portal do administrador. Um locatário separado do Azure AD é criado nesta assinatura onde os usuários representando as empresas de seguros são registrados. Esses usuários são adicionados como usuários convidados no locatário do Azure AD para acessar os aplicativos do portal. Se as empresas de seguros têm seu próprio locatário do Azure AD, o Azure AD B2B pode ser usado para federar esse locatário com o locatário padrão do Azure AD nesta assinatura.

No Portal do Azure, um locatário do Azure AD B2C é criado na assinatura do Azure e as políticas são definidas para permitir que os clientes façam sua própria inscrição para acessar o portal do cliente. Na seção de provedores de identidade da configuração do Azure AD B2C, as contas locais neste locatário são definidas como “nome de usuário” em oposição ao endereço de email, e a verificação de email na inscrição do usuário é desabilitada para simplificar o processo. Consulte a documentação do Azure AD B2C para obter orientações sobre como criar e configurar políticas para as experiências de logon e inscrição (bit.ly/2n7Vro9).

Executando o Aplicativo

Para permitir que você execute esta solução, forneci credenciais de amostra para entrar nos portais do administrador e do cliente no repositório do GitHub associado a este artigo.

Para manter a solução simples para este artigo, eu não implementei a etapa na qual as empresas de seguros adquirem códigos únicos. Em vez disso, os usuários do portal do administrador executariam diretamente a próxima etapa, na qual o número de série do documento, as informações do cliente, a apólice e os detalhes do veículo são capturados em uma única imagem.

A Figura 3 mostra a página inicial do portal do administrador — Contoso Insurance. Você pode entrar no portal do administrador usando as credenciais de um usuário da empresa de seguros e selecionar Criar Novo para inserir os detalhes para o novo documento. O número de série de um documento é gerado automaticamente pelo aplicativo e pode ser visualizado somente no formulário Novo ou Editar Item.

Figura 3 - Lista de apólices de seguros na página inicial do portal do administrador da Contoso Insurance

A Figura 4 mostra diferentes versões dos dados das apólices de seguro armazenados como segredo. Você também pode visualizar informações adicionais, como o tipo de conteúdo, marcas e atributos. Observe que o Segredo é criptografado antes de ser armazenado.

Figura 4 - Diferentes versões dos dados das apólices de seguro armazenados como Segredo, conforme visto no Portal do Azure

Se você entrar no portal do cliente, poderá visualizar todas as apólices de seguro que foram adquiridas e estão prontas para ativação. A página Editar apólice oferece uma opção para ativar a apólice, que então atualiza o status da apólice no Banco de Dados SQL do Azure para Ativo. Assim que a apólice é ativada, é possível usar a opção Baixar Apólice, que gera um código QR para os dados da apólice.

A Figura 5 mostra a experiência do usuário no portal do cliente para baixar o código QR. Também são mostrados os dados JSON que são lidos no código QR usando um aplicativo em um dispositivo móvel. O aplicativo nativo digitaliza o código QR e exibe os detalhes da apólice formatada na tela, para facilitar a verificação offline.

Figura 5 - Geração de código QR

Será possível implementar segurança adicional fazendo com que o portal do cliente assine os dados JSON usando uma chave privada no Azure Key Vault e gerando um código QR nos dados assinados. O aplicativo móvel nativo poderá ser enviado com a chave pública necessária para verificar os dados assinados antes de exibir os dados JSON no dispositivo para verificação.

O portal do cliente usa o gerador de código QR para JavaScript, disponível no GitHub em bit.ly/2sa3TWy, para gerar e exibir o código QR no portal.

Validação da apólice

As apólices podem ser validadas offline ou online. A validação offline pode ser realizada usando qualquer aplicativo de leitura de código QR em um dispositivo móvel ou usando um aplicativo nativo do Xamarin. Depois do código QR ser escaneado, os resultados são exibidos de uma forma simples para verificação.

Em contraste, a Figura 6 mostra uma solicitação para validação enviada usando a ferramenta Postman (getpostman.com) para a API no aplicativo MVC, que retorna o resultado da validação como um booliano. Neste caso, a data de início da apólice é depois da data atual para que o resultado da validação seja “falso”. O aplicativo Xamarin é usado para o usuário se conectar, escanear e visualizar os dados do código QR e fazer uma solicitação para esta API realizar a validação online.

Figura 6 - Chamada da API REST para validar uma apólice

Todas as operações no Azure Key Vault podem ser auditadas e os logs arquivados em conformidade com os regulamentos legais. Você pode habilitar a auditoria na folha Configurações no Portal do Azure para a instância de serviço do Azure Key Vault. Para visualizar os logs, navegue até o recurso de armazenamento do Azure configurado para os logs. Você poderá usar o controle de acesso baseado em função (RBAC) no Portal do Azure para garantir que somente usuários designados possam acessar essas informações.

Todas as operações sobre os dados no Banco de Dados SQL do Azure também podem ser habilitadas para auditoria, na folha Configurações da instância do banco de dados no Portal do Azure. A criptografia de dados transparente dos dados inativos no Banco de Dados SQL do Azure está habilitada por padrão.

Implantando a solução

Se quiser experimentar esta solução por si mesmo, é possível baixar os arquivos de origem e os scripts do repositório GitHub em bit.ly/2DRvwdh. Você precisará do software a seguir para implementar esta solução:

Visual Studio 2017 Preview, Community ou Enterprise Edition com atualização 3
Uma assinatura do Azure
Um editor de scripts do Windows PowerShell
Postman
Um gerador de código QR para JavaScript

Para implantar a solução em sua própria assinatura, você precisará atualizar as entradas de configuração no arquivo appsettings.json depois dos scripts do PowerShell serem executados e os outros recursos serem fornecidos na assinatura do Azure. As etapas para fazer isso foram fornecidas no repositório do GitHub, junto com o código-fonte e os arquivos de solução descritos neste artigo. Muito obrigado a Bindu Chinnasamy, da equipe CSE da Microsoft, pela ajuda com a compilação da solução que acompanha o artigo.

Conclusão

O Azure Key Vault oferece uma plataforma útil e eficiente para as empresas gerenciarem de forma segura suas informações confidenciais, usando algoritmos padrão da indústria e técnicas para a realização de operações criptográficas. Ele permite que os desenvolvedores usem SDKs para as plataforma e linguagens com as quais já estão acostumados. Isso, combinado com o conjunto avançado de serviços adicionais no Azure, como o Azure App Service, Azure AD e o Azure B2C, além do suporte a ferramentas que estes serviços oferecem, permite que os desenvolvedores foquem na compilação de recursos corporativos, reduzindo significativamente o tempo necessário para desenvolver e implantar soluções ponta-a-ponta.

Na continuação deste artigo, demonstrarei como o mesmo aplicativo poderá, sem grandes alterações, ser implantado no Serviço de Contêiner do Azure usando os contêineres do Docker e o Kubernetes.

Srikantan Sankaran é um evangelista técnico da equipe One Commercial Partner na Índia, sediada em Bangalore. Trabalha com diversos ISVs na Índia e ajuda-os a arquitetar e implantar suas soluções no Microsoft Azure. Entre em contato com ele pelo e-mail sansri@microsoft.com.

Agradecemos aos seguintes especialistas técnicos da Microsoft pela revisão deste artigo: Frank Hokhold, Bindu Chinnasamy
Muito obrigado a Frank Hokhold pela revisão deste artigo. Frank é gerente de programação de experiência do desenvolvedor na equipe do Azure Key Vault.
Muito obrigado também a Bindu Chinnasamy, da equipe CSE da Microsoft, pela ajuda com a compilação da solução que acompanha este artigo.

Discuta esse artigo no fórum do MSDN Magazine