Evaluación de los requisitos de soberanía

  • Artículo

Microsoft Cloud Adoption Framework para Azure es un marco de ciclo de vida completo que ayuda a los arquitectos de la nube, profesionales de TI y tomadores de decisiones empresariales alcanzar sus objetivos de adopción de la nube. Proporciona mejores prácticas, documentación y herramientas que le ayudan a crear e implementar estrategias empresariales y tecnológicas para la nube. Las organizaciones del sector público que tienen estrictos requisitos de soberanía pueden incorporar sus objetivos de soberanía en sus esfuerzos de planificación, de modo que las decisiones estratégicas sobre la adopción de la nube estén alineadas con esos requisitos de soberanía.

Este articulo destaca los aspectos en los que las organizaciones pueden querer evaluar, identificar y documentar sus requisitos de soberanía, y proporciona recomendaciones sobre dónde estos requisitos pueden encajar en esfuerzos de planificación más amplios asociados con la nube. Marco de adopción para Azure.

Identificación de los datos de soberanía

Los requisitos de soberanía de datos pueden incluir mandatos para conservar la propiedad de los datos y especificar métodos para el almacenamiento, uso y transmisión de datos. A veces, los requisitos de soberanía de los datos también pueden incluir limitaciones o mandatos con respecto a la residencia de los datos. Comprender estos requisitos en las primeras etapas del viaje a la nube de una organización puede ayudar a establecer patrones de diseño comunes para la soberanía de los datos, en lugar de esperar que los propietarios de las cargas de trabajo desarrollen soluciones para abordar los requisitos de soberanía.

Las organizaciones que siguen Cloud Adoption Framework para Azure identifican cargas de trabajo candidatas para migrar a la nube durante la fase de planificación y luego diseñan el entorno para alojar estas cargas de trabajo durante la fase de preparación. Estas actividades pueden permitir a una organización identificar tipos de datos soberanos que requieren un manejo especial en el entorno de nube del estado objetivo.

Microsoft utiliza muchos tipos de datos, como información personal que se proporciona a Microsoft y datos de clientes que se cargan en servicios en la nube para brindar servicios profesionales y en línea. Las responsabilidades de protección de datos de Microsoft están documentadas en el Anexo de protección de datos (DPA) de productos y servicios de Microsoft y se incluyen en los acuerdos de una organización con Microsoft. El DPA especifica los diferentes tipos de datos que Microsoft administra y describe las prácticas utilizadas por Microsoft para proteger esos tipos de datos.

Muchas organizaciones cuentan con programas de gobernanza de datos que especifican requisitos para el manejo de datos confidenciales y pueden usar esta información para determinar si los requisitos de soberanía de datos se aplican a todas o solo a un subconjunto de clasificaciones de datos. Cuando una organización carga y mantiene sus datos en un servicio en la nube, es su responsabilidad clasificar, etiquetar y gestionar con precisión los datos siguiendo sus requisitos de manejo de datos. Es posible que algunas organizaciones quieran aprovechar la adopción de la nube como una oportunidad para revisar sus programas de clasificación de datos.

Para obtener más información sobre cómo se aplica la clasificación de datos a la adopción de la nube, consulte Clasificación de datos en Azure y Guías de gobernanza de la nube.

Ejemplos de requisitos de soberanía de datos

Es posible que las organizaciones que tienen requisitos estrictos de soberanía de datos deban planificar algunos de los siguientes escenarios representativos cuando migran cargas de trabajo a la nube.

Etiquetar clasificación de datos

Las etiquetas de clasificación identifican recursos con requisitos de manipulación especiales. Si bien las etiquetas de clasificación se aplican a los documentos, también se pueden aplicar a los activos. Los clientes pueden usar las funciones de etiquetado nativas en Azure para aplicar etiquetas de clasificación a recursos como servicios informáticos y almacenes de datos y para estructuras lógicas en Azure, como suscripciones y grupos de administración.

Para obtener más información, consulte Etiquetado en Azure y Soluciones de exhibición de documentos electrónicos de Microsoft Purview.

Límites de clasificación de datos

Cuando una organización elige agregar datos (o aplicaciones) de una clasificación similar, a menudo se implementa un perímetro de seguridad para que sirva como límite de la ubicación donde se permite el almacenamiento de datos. Cuando los clientes implementan cargas de trabajo en Azure, pueden usar suscripciones y grupos de administración para crear límites lógicos dentro del entorno de nube de la organización. Estos límites ayudan a mitigar los riesgos de confidencialidad relacionados con el acceso no autorizado y los riesgos de privacidad relacionados con la agregación y atribución de datos.

Las organizaciones que tienen requisitos estrictos de soberanía de datos pueden considerar si desean organizar su entorno en un modelo jerárquico, donde los niveles más altos de privilegios heredan niveles más bajos de privilegios (por ejemplo, como en el modelo Bell-LaPadula), o si prefieren implementar un modelo no jerárquico donde se utilizan controles de acceso obligatorios para crear límites que compartimentan partes del entorno del resto del entorno. Las decisiones sobre cómo una organización gestiona los límites de clasificación de datos son cruciales al diseñar zonas de aterrizaje en la fase de preparación de Cloud Adoption Framework para Azure.

Para más información, ver Grupos de administración en Azure y Dato de gobernanza.

Residencia de datos

Las organizaciones que deben cumplir requisitos de residencia de datos deben prestar especial atención a qué servicios de Azure necesitan para admitir una carga de trabajo y dónde están disponibles geográficamente esos servicios. Los servicios de Azure se implementan en regiones que admiten conexiones de red de baja latencia y características como zonas de disponibilidad. Estas regiones se agrupan en geografías, lo que proporciona características adicionales de resiliencia y recuperación ante desastres.

Si una organización necesita mantener la residencia de datos para su carga de trabajo, debe asegurarse de que los servicios de Azure que se utilizan estén disponibles en su región y geografía preferidas. Además, algunos servicios se implementan globalmente y no ofrecen residencia de datos dentro de una región o geografía determinada para los datos almacenados dentro de ese servicio.

Para obtener más información sobre la residencia de datos, las regiones y zonas de disponibilidad de Azure y la disponibilidad regional de los servicios de Azure, consulte los siguientes artículos:

Propiedad, custodia y portabilidad de los datos

Los clientes con requisitos estrictos de soberanía de datos a menudo tienen muchas preguntas sobre quién conserva la propiedad de los datos almacenados en Azure, quién puede acceder a esos datos y qué sucede con esos datos si un cliente decide trasladar su carga de trabajo a otra plataforma. Estos requisitos pueden variar en alcance y especificidad, pero generalmente tienden a estar relacionados con la pregunta fundamental de qué sucede con los datos cuando los aloja en un Microsoft Cloud Service.

Para ayudar a abordar estas preguntas a un alto nivel y brindar a los clientes un punto de partida para identificar sus requisitos de soberanía de datos que se aplican a los proveedores de servicios en la nube, Microsoft ha publicado una serie de artículos sobre la protección y administración de datos de los clientes que abordan muchas de estas preguntas, y esos artículos están disponibles en línea en el Centro de confianza.

Para obtener más información, consulte Administración de datos en Microsoft.

Mantenga la soberanía operativa en la nube

Los requisitos de soberanía operativa pueden afectar la forma en que se diseña, actualiza y administra un entorno en Azure. Por lo tanto, es importante tener una comprensión clara de estos requisitos antes de finalizar los diseños técnicos como parte de la fase de preparación del Cloud Adoption Framework para Azure. Los requisitos comunes de soberanía operativa pueden incluir:

  • Limitaciones a la ubicación y nacionalidad del personal administrativo.
  • Requisitos de control de acceso que limitan el acceso privilegiado por parte de los proveedores de servicios en la nube.
  • Mandatos para alta disponibilidad y recuperación ante desastres.

Es importante comprender claramente la intención y los riesgos que mitigan estos requisitos, ya que muchos de estos requisitos se cumplen en la nube utilizando métodos diferentes a los que se usan comúnmente local.

Una vez que la organización identifica los requisitos de soberanía operativa, puede seleccionar los controles de soberanía técnicos y administrativos adecuados para proporcionar el nivel adecuado de mitigación y garantía de riesgos. Al seleccionar controles de soberanía, es importante comprender que seleccionar algunas capacidades que pueden proporcionar soberanía operativa adicional limita las opciones de una organización para adoptar otros servicios de Azure.

Por ejemplo, una organización que requiere informática confidencial para sus cargas de trabajo de Azure tiene que limitar sus opciones de arquitectura a servicios que puedan ejecutarse en Azure Confidential Computing, como máquinas virtuales confidenciales o contenedores confidenciales. Por este motivo, suele ser una buena idea asociar los requisitos de soberanía operativa con una clasificación de datos determinada, en lugar de adoptar un enfoque en el que todas las cargas de trabajo y los datos deben cumplir el conjunto más restrictivo de requisitos de soberanía.

Además, algunos requisitos de soberanía operativa, como Autarky (por ejemplo, poder ejecutarse independientemente de redes y sistemas externos) no son factibles en plataformas de computación en la nube a hiperescala como Azure, que dependen de actualizaciones periódicas de la plataforma para mantener los sistemas en un estado óptimo.

Ejemplos de requisitos de soberanía operacional

Algunos requisitos comunes de soberanía operativa junto con ejemplos de servicios y capacidades de Azure relevantes que pueden abordar esos requisitos son los siguientes:

Software de seguridad

Los requisitos de seguridad del software pueden incluir actividades de desarrollo, como la aplicación de salvaguardas criptográficas específicas, la realización de revisiones de código y la realización de pruebas de seguridad y penetración de aplicaciones. También puede incluir procesos operativos, como la implementación de controles de acceso, el uso de tecnologías de cifrado y la supervisión de eventos de seguridad.

Microsoft proporciona varias capacidades para ayudar a los clientes a cumplir con los requisitos de soberanía operativa para el software desarrollado por Microsoft y por el cliente. Microsoft sigue el ciclo de vida de desarrollo seguro (SDL) al desarrollar software a nivel de plataforma para Azure. Las 12 prácticas de SDL se incorporan a los procesos y procedimientos de ingeniería de Microsoft y se evalúan periódicamente como parte de las actividades de aseguramiento de Microsoft. Además, Microsoft proporciona capacidades para ayudar a los clientes a adoptar las prácticas del ciclo de vida de desarrollo seguro como parte de su ciclo de vida de desarrollo de software.

Para obtener más información, consulte Ciclo de vida de desarrollo seguro de Microsoft y Prácticas recomendadas de desarrollo seguro en Azure.

Infraestructura de seguridad

Las cargas de trabajo que se ejecutan en Azure pueden aprovechar las numerosas características que Microsoft ha desarrollado para garantizar la integridad de la plataforma. Las características incluyen su firmware, software e infraestructura de host. Las organizaciones pueden tener requisitos de soberanía operativa para aislar sus datos de los operadores de la nube. Azure proporciona capacidades que los clientes pueden utilizar para aprovechar la agilidad y la resiliencia de la nube pública mientras mantienen el aislamiento de los proveedores de servicios en la nube y su personal administrativo. Las organizaciones con requisitos relacionados con la certificación a nivel de hardware, la verificación de la integridad del software (por ejemplo, arranque seguro) y la administración segura de claves pueden revisar las prácticas de seguridad e integridad de la plataforma de Microsoft y acceder a la documentación de auditoría para validar la implementación de estas características.

Para obtener más información, consulte Integridad y seguridad de la plataforma y Seguridad de la infraestructura de Azure.

El cifrado de datos en reposo, en tránsito y en uso puede ayudar a satisfacer una amplia gama de requisitos de soberanía operativa relacionados con la confidencialidad y la privacidad de los datos. Sin embargo, las organizaciones que requieren estas funciones deben planificar la creación y gestión de claves de cifrado. Azure ofrece una amplia gama de modelos de cifrado de datos en reposo para que los clientes elijan, desde métodos de cifrado del lado del cliente que proporcionan cifrado sin conocimiento para datos alojados en la nube hasta claves administradas por servicios que ofrecen el mayor grado de interoperabilidad con Servicios nativos en la nube.

Además, las organizaciones que deseen minimizar la necesidad de confiar en los componentes de la plataforma, como el sistema operativo host, el kernel, el hipervisor y el personal administrativo, pueden implementar el cifrado de datos en uso. Azure Confidential Computing incluye varios servicios informáticos que se implementan en enclaves de seguridad basados ​​en hardware que cifran datos en la memoria mediante Intel Software Guard Extensions (SGX) o AMD Secure Encrypted Virtualization (SEV-SNP).

Las organizaciones con requisitos de soberanía operativa que requieren implementar cifrado deben familiarizarse con las siguientes características de cifrado en Azure:

Operaciones y resistencia

Los requisitos de seguridad operativa pueden aplicarse tanto al software a nivel de plataforma creado y administrado por Microsoft para operar la plataforma Azure como al software administrado por el cliente que forma parte de una carga de trabajo. El modelo de responsabilidad compartida para la informática en la nube traslada la responsabilidad administrativa del cliente al proveedor de servicios en la nube. Dependiendo del tipo de servicio en la nube que se esté consumiendo, Microsoft puede ser responsable de administrar y actualizar la infraestructura básica en nuestros centros de datos, sistemas operativos y tiempos de ejecución del servicio. La organización de ingeniería de seguridad de Microsoft implementa un programa de seguridad operativa que se basa en las prácticas del ciclo de vida de desarrollo seguro (SDL) de Microsoft con prácticas de seguridad operativa. Las prácticas incluyen gestión de secretos, pruebas de penetración y supervisión de seguridad, implementadas por el Centro de Respuestas de Seguridad de Microsoft.

En casos excepcionales, Microsoft puede requerir acceso a los datos del cliente para solucionar un problema que pueda afectar los servicios. Los clientes con requisitos de soberanía operativa relacionados con el control de cambios y la administración de acceso privilegiado pueden querer habilitar Caja de seguridad del cliente para Azure para que puedan aprobar las solicitudes de acceso como parte de los flujos de trabajo de soporte de Microsoft.

Además, los clientes con requisitos estrictos de aprobación y programación de actualizaciones de software de plataforma pueden considerar Azure Dedicated Hosts, que permiten a los clientes utilizar configuraciones de mantenimiento para controlar las actividades de mantenimiento de la plataforma a nivel de host. Además, los clientes deben revisar sus requisitos de resiliencia para determinar si existen limitaciones basadas en la soberanía en los servicios y regiones que se utilizan para alojar cargas de trabajo.

Los requisitos de soberanía operativa en torno a la continuidad de las operaciones (por ejemplo, exigir que las cargas de trabajo se implementen en configuraciones de alta disponibilidad para mantener el tiempo de actividad) pueden entrar en conflicto con los requisitos de soberanía de datos relacionados con la residencia de los datos (por ejemplo, restringir las cargas de trabajo a un límite geográfico que no ofrece diversidad ubicaciones).

Las organizaciones deben evaluar estos requisitos con anticipación y considerar la mejor manera de equilibrarlos.