Marzo de 2018

Volumen 33, número 3

Azure: protección de la información empresarial confidencial con Azure Key Vault

Por Srikantan Sankaran

Azure Key Vault es un servicio basado en la nube que permite a las organizaciones almacenar información empresarial confidencial de forma segura. Permite realizar operaciones criptográficas con los datos y proporciona un marco para implementar directivas para regular el acceso a las aplicaciones, así como un modelo de API para que las aplicaciones funcionen con las claves, secretos y certificados que contiene. Los SDK que proporciona Azure Key Vault admiten distintas plataformas de dispositivo y lenguajes de programación, lo que le permite elegir su lenguaje preferido e implementar estas aplicaciones en Azure App Service como aplicaciones web administradas. Para exponer estas aplicaciones empresariales de forma segura a los usuarios dentro y fuera de la organización, Azure Active Directory (Azure AD) y Azure Active Directory B2C (Azure AD B2C) proporcionan implementaciones preconfiguradas para habilitar la autenticación y la autorización en las aplicaciones con poco o ningún código personalizado. En este artículo, presentaré una solución que muestra cómo Azure Key Vault puede aportar seguridad mejorada a la organización.

Escenario de caso de uso

Se asigna a una agencia central la implementación de una solución para emitir, administrar y hacer el seguimiento de pólizas de seguros para vehículos. La agencia genera números de serie de documento únicos al recibir los pedidos y el pago de las empresas aseguradoras. Estas empresas, directamente o a través de agentes, asignan pólizas de seguro a los números de serie de documento a medida que se venden a motoristas. Los números de serie de documento son únicos para todas las empresas aseguradoras.

El objetivo de la solución es hacer un seguimiento del ciclo de vida del número de serie de documento. Cuando se crea, un número de serie de documento solo contiene un número y el nombre de la empresa aseguradora a la que se vende. En una fase posterior del proceso empresarial, se agregará información adicional, como el registro del vehículo, el número de documento de la póliza, la identidad del cliente y el periodo de validez de la póliza de seguros. Se debe realizar un seguimiento de todas las versiones de este registro, incluidos los cambios aplicados, la fecha y la hora de los cambios y la identidad de la aplicación que hizo el cambio.

Los clientes deben poder acceder a la póliza electrónicamente y descargar la información de forma segura para verificarla o consultarla fácilmente.

Arquitectura de la solución

La solución usa Azure Key Vault para almacenar el número de serie del documento, junto con las propiedades de la póliza del seguro asociada, como secreto. Para mayor seguridad, los datos almacenados como secreto se cifran de antemano mediante claves asimétricas generadas en Azure Key Vault. Aunque en el secreto solo se capturan los datos mínimos necesarios para proteger y validar cada directiva, también se almacena información complementaria adicional en una instancia de Azure SQL Database. La base de datos también implementa restricciones sobre los datos para garantizar, por ejemplo, que un vehículo registrado tiene un único número de póliza activa, que no se ha usado el mismo número de póliza para varios registros, etc. En la Figura 1 se representa la arquitectura usada en la solución.

Arquitectura de la solución
Figura 1 Arquitectura de la solución

En esta solución, he implementado dos aplicaciones de portal: una que usa la agencia central y las empresas aseguradoras, y otra que usan los clientes que adquieren pólizas de seguro y las autoridades competentes que necesitan comprobar la validez de las pólizas.

El portal de administración y el portal de cliente son aplicaciones MVC de ASP.NET 2.0 Core que usan Entity Framework para almacenar datos de pólizas en Azure SQL Database, después de almacenarlos en Azure Key Vault. El SDK de .NET para Azure Key Vault se usa para realizar operaciones criptográficas sobre los datos, como la creación de secretos y sus versiones, y el cifrado y descifrado de secretos mediante claves. Los usuarios del portal de administración se autentican con Azure AD, mientras que los clientes, que son usuarios externos, usan Azure AD B2C para autoregistrarse e iniciar sesión en el portal del cliente.

Se crean distintas entidades de servicio en Azure AD para los portales de administración y cliente. También se definen distintas directivas para bloquear su acceso a las operaciones en Azure Key Vault. La directiva del portal de administración permite la creación de claves y secretos, así como el rendimiento de operaciones como el cifrado y el descifrado de datos. En cambio, al portal del cliente se le asigna una directiva que solo permite la operación “get” sobre un secreto y la operación “decrypt” sobre el secreto recuperado. Esto garantiza que las aplicaciones individuales no tengan más acceso del necesario a Azure Key Vault.

Para mayor seguridad, en primer lugar, se cifran los datos almacenados de la póliza como secreto en Azure Key Vault. Cada vez que se actualiza el secreto, se crea una versión nueva y se conservan las versiones anteriores de los datos. También se mantiene un registro de auditoría para todas las operaciones que se realizan en Key Vault, que se archiva para cumplir los requisitos de conformidad.

La agrupación de atributos de los secretos almacenados en Azure Key Vault captura las fechas de inicio y fin de la póliza, que se usan para confirmar la validez de la póliza. Las etiquetas y los parámetros de tipo contenido de los secretos se usan para almacenar información adicional relativa a la póliza de seguros.

En el siguiente fragmento de código se muestra cómo se agregan los atributos, etiquetas y tipos de contenido a los datos de directiva almacenados como secreto:

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);

Implementación del escenario de caso de uso

Observemos de cerca el escenario de caso de uso que implementa la solución. Estos son los pasos básicos:

Adquisición de códigos únicos por parte de las empresas aseguradoras: al recibir los pedidos de las empresas aseguradoras, la agencia central usa el portal de administración para generar un inventario de números de serie de documento y almacenarlos como secretos en Azure Key Vault. El portal de administración crea la primera versión de un secreto en Azure Key Vault y, a continuación, crea un registro en Azure SQL Database.

Generación de la póliza: Cuando un cliente adquiere una póliza de vehículo, se elige un secreto sin asignar del paso anterior y se agrega información adicional, como el número de registro del vehículo, la identidad del cliente, el número de documento de póliza generado y el periodo de validez de la póliza. Se crea una versión nueva del secreto original que contiene esta información adicional en el proceso y también se actualiza el registro correspondiente en Azure SQL Database.

Activación de la póliza por parte del cliente: Una vez capturados todos los detalles de la póliza en el secreto, se envía una notificación al cliente (fuera del ámbito de este artículo) con instrucciones para activar la póliza. Los usuarios pueden autoregistrarse en el portal del cliente con sus credenciales sociales o las credenciales almacenadas en Azure AD B2C. Cuando el cliente inicia sesión en el portal, se muestran los detalles de la póliza, junto con una opción para activarla. Al activarla, el usuario descarga un código QR del portal y pega su imagen al vehículo asegurado.

Validación de la póliza: los clientes o las autoridades competentes pueden validar la póliza en cualquier lugar mediante una aplicación Xamarin nativa que lea el código QR del vehículo y muestre los detalles de la póliza para contrastarlos con los del vehículo. Esta validación no requiere conexión a Internet y se puede hacer sin conexión. Con conexión a Internet, se puede realizar una validación adicional. La aplicación nativa invoca una API REST que se expone en la aplicación MVC del portal del cliente y pasa los datos a partir del código QR. En primer lugar, la API contrasta estos datos con los de Azure SQL Database y, además, con los datos almacenados en el secreto en Azure Key Vault.

Aspectos técnicos de la solución

A continuación, inspeccionaremos el código fuente y los scripts de automatización que usa la solución. Recuerde que el código y los scripts que se comparten en este artículo no pretenden ser una solución completa ni incluyen necesariamente todas las validaciones, excepciones o procedimientos recomendados necesarios en una aplicación preparada para producción. Pretenden ilustrar aspectos concretos de un área tecnológica o proporcionar orientación para el desarrollo de una solución completa.

Crear y configurar Azure Key Vault Los archivos de script de PowerShell PrepareContosoAKV.ps1 y PrepareContosousersAKV.ps1, incluidos en la descarga complementaria, se usan para aprovisionar y configurar el almacén de claves que se usa en este artículo. Esto es lo que consiguen:

  • Creación de certificados autofirmados (que solo se usan en escenarios de desarrollo) para las aplicaciones MVC de ASP.NET del portal de administración y del cliente, que se usan al crear las entidades de servicio en Azure AD.
  • Creación de una entidad de servicio en Azure AD asignada al portal de administración. La directiva de acceso que se define para esta entidad de servicio permite crear y actualizar claves y secretos, así como llevar a cabo operaciones como el cifrado y el descifrado:
# Specify privileges to the vault for the Admin Portal application
Set-AzureRmKeyVaultAccessPolicy -VaultName $vaultName `
  -ObjectId $servicePrincipal.Id `
  -PermissionsToKeys all `
  -PermissionsToSecrets all
  • Creación de una entidad de servicio en Azure AD asignada al portal del cliente. La directiva de acceso definida para esta entidad de servicio permite operaciones Get en claves y secretos, así como el descifrado de datos:
# Specify privileges to the vault for the Customer Portal application
Set-AzureRmKeyVaultAccessPolicy -VaultName $vaultName `
  -ObjectId $servicePrincipal.Id `
  -PermissionsToKeys get,list,decrypt `
  -PermissionsToSecrets get,list
  • Tenga en cuenta que existe una alternativa a la creación de estas entidades de servicio con PowerShell, que consiste en usar la característica Managed Service Identity en Azure App Service. De hecho, se recomienda. Para obtener más información, consulte las instrucciones que se proporcionan en bit.ly/2BgB6mu.
  • Creación de una clave para el cifrado y el descifrado de un secreto.
  • Creación de un secreto que almacena la cadena de conexión en Azure SQL Database. (Se puede hacer directamente en Azure Portal, igual que el resto de pasos).

Para simplificar, esta solución usa un único almacén de claves y un único conjunto de claves para que todas las empresas aseguradoras y agentes cifren y descifren los datos. En el mundo real, para obtener un mayor aislamiento y seguridad, se deben crear instancias independientes de Azure Key Vault para cada empresa aseguradora y se deben agrupar por región, por ejemplo, o por cualquier otro criterio. Esto garantiza que otras personas no puedan leer los datos que mantiene una empresa aseguradora, ya que no comparten la misma clave de cifrado.

Recuerde que el tamaño de los secretos almacenados en Azure Key Vault no debe superar los 25 KB. Así pues, para evitar el sobredimensionamiento, solo se almacenan ciertas propiedades de los datos de la póliza, como el identificador (número de serie de documento), nombre de secreto, id. de usuario, número de póliza e id. de empresa aseguradora. El archivo Entity Insdata.cs de la solución de Visual Studio 2017 ContosoInsAuthorityAdminPortal.sln contiene estas propiedades. Otras propiedades, como las fechas de inicio y fin de vigencia, el tipo de contenido, etc., se almacenan como atributos del secreto en el almacén de claves.

Compilar las aplicaciones del portal de administración y del cliente Consulte la solución de Visual Studio 2017 ContosoInsAuthorityAdmin­Portal.sln de la descarga para obtener el código fuente del portal de administración, y ContosoinsExtPortal.sln para obtener el del portal del cliente.

Tanto los portales de administración como del cliente se compilan mediante ASP.NET Core 2.0, que admite la inyección de dependencias para agregar servicios de marco (como la integración con Entity Framework y los módulos de servicio personalizado para acceder a API de Azure Key Vault) a la aplicación en la clase de inicio.

Las plantillas de proyecto de Visual Studio 2017 proporcionan una integración preconfigurada con Azure AD y Azure AD B2C para proteger el acceso a las aplicaciones de portal en las experiencias de inicio de sesión y registro del usuario.

La cadena de conexión para Azure SQL Database se almacena en Azure Key Vault y la recupera la aplicación web del portal durante el inicio.

El fragmento de código de la Figura 2 muestra cómo se agrega la inyección de dependencias en ASP.NET 2.0 Core para la autenticación de Entity Framework Azure AD y para que el proveedor de acceso, la API de servicio de Azure Key Vault, pueda acceder a los datos de configuración de la aplicación del archivo appsettings.json y leerlos.

Figura 2 Marco de dependencia de la aplicación MVC de 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();
  }

El proveedor de configuración de Azure Key Vault para ASP.NET Core 2.0 (bit.ly/2DfOXeq), disponible como paquete NuGet, proporciona una implementación preconfigurada para recuperar todos los secretos de Azure Key Vault al iniciar la aplicación. Sin embargo, esta característica no se usa en la solución para evitar cargar todos los datos empresariales innecesariamente al iniciar la aplicación; es decir, los secretos de la póliza de seguros, junto con otros secretos que requiere la aplicación, como la cadena de conexión para acceder a Azure SQL Database. Esta característica se puede utilizar cuando se usa una instancia del almacén de claves para almacenar todas las cadenas de conexión que requiere la aplicación, y otra instancia del almacén de claves para los datos empresariales.

Creación de instancias de App Service Las aplicaciones del portal de administración y del cliente se implementan como aplicaciones web de Azure App Service mediante las herramientas integradas en Visual Studio 2017. Ambas aplicaciones web se hospedan en un único plan de App Service.

Durante el desarrollo, las aplicaciones MVC de ASP.NET Core se pueden implementar localmente mediante Visual Studio 2017. Cuando se ejecutan los scripts de PowerShell que se han descrito antes, se generan dos certificados digitales: uno para cada aplicación de portal. Los archivos .pfx se agregan al almacén de certificados del usuario actual. Estos se integran en las solicitudes que hacen las aplicaciones MVC de ASP.NET para acceder a las API de Azure Key Vault. Las huellas digitales de estos certificados se agregan al archivo appsettings.json en la solución de Visual Studio 2017 de las respectivas aplicaciones MVC de ASP.NET.

Al implementar la aplicación en Azure App Service, debe:

  • Cargar ambos archivos .pfx en la instancia de Azure App Service desde Azure Portal.
  • Crear la entrada “WEBSITE_LOAD_CERTIFICATES” en las hojas App Settings (Configuración de la aplicación) de las aplicaciones web de portal de administración y del cliente de Azure Portal y agregar la huella digital del archivo .pfx correspondiente.

Consulte la documentación disponible en bit.ly/2mVEKOq para obtener más información sobre los pasos que se deben seguir.

Creación de la base de datos El archivo de script que se usa para crear la base de datos para la solución está disponible para descargarse, junto con el resto de artefactos de la solución. El cifrado de datos transparente (TDE) y la auditoría están habilitados en la base de datos.

Creación de inquilinos de Azure AD y Azure AD B2C El inquilino de Azure AD predeterminado de la suscripción a Azure se usa como proveedor de identidades para los usuarios internos de la agencia central que acceden al portal de administración. Se crea otro inquilino de Azure AD en esta suscripción, donde se registran los usuarios que representan empresas aseguradoras. Estos usuarios se agregan como usuarios invitados al inquilino predeterminado de Azure AD para acceder a las aplicaciones de portal. Si las empresas aseguradoras tienen su propio inquilino de Azure AD, Azure AD B2B se puede usar para federar dicho inquilino con el inquilino predeterminado de Azure AD de esta suscripción.

Desde Azure Portal, se crea un inquilino de Azure AD B2C en la suscripción a Azure y se definen directivas para permitir a los clientes el autoregistro para acceder al portal del cliente. En la sección de proveedores de identidades de la configuración de Azure AD B2C, las cuentas locales de este inquilino se definen con un nombre de usuario, en lugar de una dirección de correo electrónico, y la verificación de correo electrónico del registro del usuario está deshabilitada por simplicidad. Consulte la documentación de Azure AD B2C para obtener instrucciones sobre la creación y configuración de directivas para las experiencias de inicio de sesión y registro (bit.ly/2n7Vro9).

Ejecución de la aplicación

Para que pueda ejecutar esta solución, he proporcionado credenciales de ejemplo para iniciar sesión en los portales de administración y del cliente del repositorio de GitHub asociado con este artículo.

Para que la solución de este artículo sea sencilla, no he implementado el paso en que las empresas aseguradoras compran códigos únicos. En su lugar, los usuarios del portal de administración ejecutarían directamente el paso siguiente, en que el número de serie de documento, la información del cliente, y los detalles de la póliza y el vehículo se calculan a la vez.

En la Figura 3 se muestra la página principal del portal de administración: Contoso Insurance. Para iniciar sesión en el portal de administración, use las credenciales de un usuario de empresa aseguradora y seleccione Create New (Crear nuevo) para especificar los detalles de un documento nuevo. La aplicación genera automáticamente el número de serie de documento, que solo se puede ver en el formulario New (Nuevo) o Edit Item (Editar elemento).

Lista de pólizas de seguros de la página principal del portal de administración de Contoso Insurance
Figura 3 Lista de pólizas de seguros de la página principal del portal de administración de Contoso Insurance

En la Figura 4 se muestran distintas versiones de los datos de la póliza de seguros almacenados como secreto. También puede ver información adicional, como el tipo de contenido, las etiquetas y los atributos. Tenga en cuenta que el secreto se cifra antes de almacenarse.

Distintas versiones de los datos de la póliza de seguros almacenados como secreto, según se muestran en Azure Portal
Figura 4 Distintas versiones de los datos de la póliza de seguros almacenados como secreto según se muestran en Azure Portal

Si inicia sesión en el portal del cliente, puede ver todas las pólizas de seguros que se han comprado y están listas para su activación. La página Edit policy (Editar póliza) proporciona una opción para activar la póliza que actualiza a Active (Activa) el estado de la póliza en Azure SQL Database. Una vez activada la póliza, puede usar la opción Download Policy (Descargar póliza), que genera un código QR para los datos de la póliza.

En la Figura 5 se muestra la experiencia del usuario en el portal del cliente para descargar el código QR. También se muestran los datos JSON que se leen del código QR mediante una aplicación en un dispositivo móvil. Una aplicación nativa escanea el código QR y muestra los detalles de la póliza con formato en la pantalla para facilitar la verificación sin conexión.

Generación de código QR
Figura 5 Generación de código QR

Para implementar seguridad adicional, el portal del cliente puede firmar los datos JSON mediante una clave privada en Azure Key Vault y generar un código QR para los datos firmados. La aplicación móvil nativa se puede enviar con la clave pública necesaria para verificar los datos firmados antes de mostrar los datos JSON en el dispositivo con fines de verificación.

El portal del cliente usa el generador de códigos QR para JavaScript disponible en GitHub en bit.ly/2sa3TWy para generar y mostrar el código QR en el portal.

Validación de la póliza

Las pólizas se pueden validar con o sin conexión. La validación sin conexión se puede realizar con cualquier aplicación con lector de código QR en un dispositivo móvil o mediante una aplicación Xamarin nativa. Una vez escaneado el código QR, los resultados se muestran de un modo fácil de usar con fines de verificación.

En cambio, en la Figura 6 se muestra una solicitud de validación enviada con la herramienta Postman (getpostman.com) a la API en la aplicación MVC, que devuelve el resultado de la validación como valor booleano. En este caso, la fecha de inicio de la póliza es posterior a la fecha actual, por lo que el resultado de la validación es “false”. Se usa una aplicación Xamarin para iniciar la sesión del usuario, ver y escanear el código QR, y hacer una solicitud a la API para realizar la validación en línea.

Llamada a la API REST para validar una póliza
Figura 6 Llamada a la API REST para validar una póliza

Se puede realizar la auditoría de todas las operaciones de Azure Key Vault y se pueden archivar los registros de conformidad con las disposiciones legales. Puede habilitar la auditoría desde la hoja Configuración de Azure Portal para la instancia de servicio de Azure Key Vault. Para ver los registros, desplácese al recurso de almacenamiento de Azure configurado para los registros. Puede usar el control de acceso basado en rol (RBAC) de Azure Portal para asegurarse de que solo los usuarios designados puedan acceder a esta información.

También se puede habilitar la auditoría de todas las operaciones con los datos en Azure SQL Database desde la hoja Configuración de la instancia de base de datos de Azure Portal. El cifrado de datos transparente de los datos en reposo en Azure SQL Database está habilitado de forma predeterminada.

Implementación de la solución

Para probar esta solución, descargue los archivos de origen y scripts del repositorio de GitHub desde bit.ly/2DRvwdh. Para implementar esta solución, necesitará el software siguiente:

  • Visual Studio 2017 Preview, Community o Enterprise Edition con Update 3
  • Una suscripción a Azure
  • Un editor de scripts de Windows PowerShell
  • Postman
  • Un generador de códigos QR para JavaScript

Para implementar la solución en su propia suscripción, tendrá que actualizar las entradas de configuración en el archivo appsettings.json después de ejecutar los scripts de PowerShell y aprovisionar el resto de recursos en la suscripción a Azure. Los pasos para hacerlo se proporcionan en el repositorio de GitHub junto con el código fuente y los archivos de solución que se describen en este artículo. Muchas gracias a Bindu Chinnasamy, del equipo de Microsoft CSE, por su ayuda para crear la solución que se incluye con este artículo.

Resumen

Azure Key Vault proporciona una plataforma útil y eficiente para que las empresas administren de forma segura la información confidencial mediante técnicas y algoritmos estándar del sector a fin de realizar operaciones criptográficas. Permite a los desarrolladores usar los SDK para las plataformas y lenguajes a los que están acostumbrados. Esto, unido al conjunto avanzado de servicios adicionales de Azure, como Azure App Service, Azure AD y Azure B2C, así como la completa compatibilidad con herramientas que proporcionan estos servicios, permite a los desarrolladores centrarse en crear características empresariales principales, lo que reduce considerablemente el tiempo necesario para desarrollar e implementar una solución integral.

En la continuación de este artículo, mostraré que la misma aplicación, sin cambios significativos, se puede implementar en Azure Container Service mediante contenedores de Docker y Kubernetes.


Srikantan Sankaran es uno de los principales evangelistas técnicos del equipo de One Commercial Partner de India, con sede fuera de Bangalore. Trabaja con muchos ISV en India y les ayuda a diseñar e implementar sus soluciones en Microsoft Azure. Puede ponerse en contacto con él a través de la dirección sansri@microsoft.com.

Gracias al siguiente experto técnico de Microsoft por revisar este artículo: Frank Hokhold, Bindu Chinnasamy
Muchas gracias a Frank Hokhold por revisar este artículo. Frank es director del programa de experiencia de desarrollador del equipo de Azure Key Vault.
Muchas gracias también a Bindu Chinnasamy, del equipo de Microsoft CSE, por su ayuda para crear la solución que se incluye con este artículo.


Discuta sobre este artículo en el foro de MSDN Magazine