Dominio de seguridad: control de datos de seguridad y privacidad

Este dominio de seguridad está diseñado para garantizar que los datos consumidos de Microsoft 365 estén protegidos adecuadamente tanto en tránsito como en reposo. Este dominio también garantiza que los problemas de privacidad de los consumidores (interesados) están siendo cumplidos por el ISV, de conformidad con el RGPD (Reglamento general de protección de datos) y hipaa (Ley de portabilidad y responsabilidad de seguros de salud de 1996).

Datos en tránsito

Los requisitos de conectividad de aplicaciones o complementos desarrollados por Microsoft 365 requieren comunicación a través de redes públicas, específicamente Internet. Por lo tanto, los datos en tránsito deben protegerse adecuadamente. En esta sección se trata la protección de las comunicaciones de datos a través de Internet.

Control Nº 1

Proporcione pruebas de lo siguiente:

• Valide que la configuración de TLS es TLS1.2 o posterior.

• Se mantiene y mantiene un inventario de claves y certificados de confianza.

Intención: TLS

La intención de este subpunto es asegurarse de que los datos de Microsoft 365 que consume su organización se transmiten de forma segura. La configuración del perfil TLS se usa para definir requisitos específicos de TLS que ayudan a garantizar que el tráfico es seguro frente a ataques de tipo "man in the middle".

Directrices: TLS

La manera más fácil de demostrar esto es ejecutar la herramienta de prueba de servidor SSL de Qualys en TODOS los agentes de escucha web, incluidos los que se ejecutan en puertos no estándar.

Recuerde marcar la opción "No mostrar los resultados en los paneles", lo que impide que la dirección URL se agregue al sitio web.

Los requisitos de configuración del perfil TLS se pueden demostrar proporcionando pruebas de comprobaciones individuales. Para proporcionar pruebas de configuraciones específicas, como deshabilitar la compresión TLS, se pueden usar valores de configuración, scripts y herramientas de software.

Evidencia de ejemplo: TLS

En la captura de pantalla siguiente se muestran los resultados del examen SSL de Qualys para la webappfrontdoor- byendbagh6a0fcav.z01.azurefd.net.

En la sección Protocolos se muestra que TLS1.2 es el único protocolo compatible o habilitado.

Nota: Los analistas de certificación revisarán la salida completa del examen para confirmar que se cumplen todos los requisitos de configuración del perfil TLS. La expectativa será que se proporcionen exámenes para todos los puntos finales que se exponen públicamente (direcciones IP y direcciones URL) al entorno back-end que está en el ámbito. En función de las pruebas que se hayan proporcionado, los analistas pueden ejecutar su propio examen de Qualys.

Evidencia de ejemplo: TLS

En la captura de pantalla siguiente se muestran los valores de configuración de TLS en Azure App Service seguidos de la enumeración TLS a través de PowerShell.

Intención: claves y certificados

La intención de este subpunto es asegurarse de que se mantiene un inventario completo de claves y certificados de confianza, lo que implica la identificación de varios sistemas, servicios y aplicaciones que dependen de estos elementos criptográficos.

Directrices: claves y certificados

La evidencia debe demostrar que existe un inventario de claves y certificados de confianza y se mantiene. Además, se pueden proporcionar pruebas aplicables de las herramientas usadas para almacenar las claves y certificados reales, como Azure Key Vault, HashiCorp Vault Secrets, Confluence Cloud, etc.

Evidencia de ejemplo: claves y certificados

En la captura de pantalla siguiente se muestra que una clave y un inventario de certificados se mantienen en Confluence Cloud.

En la captura de pantalla siguiente se muestra la lista aprobada de claves y certificados de confianza. Incluye detalles como el certificado, las claves, los chiphers y los sistemas en los que están instalados.

La captura de pantalla siguiente es de HashiCorp Vault. Los certificados que se describen y registran en la lista de inventario se almacenan en este almacén en línea. HashiCorp Vault es una herramienta de código abierto para la administración de secretos, el cifrado como servicio y la administración de acceso con privilegios.

La captura de pantalla siguiente es un extracto del certificado real y las claves almacenadas dentro del almacén en línea.

Nota: La expectativa será que la ubicación de almacenamiento de las claves tenga los controles de acceso adecuados. Si la clave privada está en peligro, alguien podría suplantar el servidor con un certificado legítimo.

Evidencia de ejemplo: claves y certificados

También se puede mantener un inventario de claves y certificados de confianza con Microsoft 365 Defender, que proporciona una característica inventario, como se muestra en la siguiente captura de pantalla.

En la captura de pantalla siguiente se muestran los detalles del certificado.

Tenga en cuenta: Estos ejemplos no son capturas de pantalla completa, se le pedirá que envíe capturas de pantalla completa con cualquier dirección URL, el usuario que ha iniciado sesión y la marca de fecha y hora para la revisión de pruebas. Si es un usuario de Linux, esto se puede hacer a través del símbolo del sistema.

Control Nº 2

Proporcione pruebas de lo siguiente:

• Muestra que la compresión TLS está deshabilitada para todos los servicios orientados al público que controlan las solicitudes web para evitar CRIME (pérdida de información de relación de compresión que facilita).

• Valida que TLS HSTS está habilitado y configurado en 180 días en todos los sitios.

Intención: TLS

• El ataque CRIME (pérdida de información de relación de compresión que se facilita (CVE-2012-4929)) es una vulnerabilidad en la compresión de los protocolos De capa de sockets seguros (SSL)/Seguridad de la capa de transporte (TLS). Por este motivo, las recomendaciones del sector son deshabilitar la compresión SSL.

• Http Strict Transport Security (HSTS) es un mecanismo de seguridad diseñado para proteger los sitios web frente a ataques de tipo "man in the middle" al forzar conexiones TLS mediante un campo de encabezado de respuesta HTTPS denominado "Strict-Transport-Security".

Directrices: TLS

Esto se puede demostrar a través de la herramienta Qualys SSL Labs. Evidencia de ejemplo: TLS

En la captura de pantalla siguiente se muestra que la compresión SSL/TLS está deshabilitada.

En la captura de pantalla siguiente se muestra que HSTS está habilitado.

Nota: El analista de certificación revisará la salida completa para confirmar que se cumplen todos los requisitos de configuración del perfil TLS (proporcione capturas de pantalla de la salida del examen completo). En función de las pruebas que se hayan proporcionado, los analistas pueden ejecutar su propio examen de Qualys.

Otras herramientas que se pueden usar para comprobar que HSTS está habilitado son "HTTP Header Spy" y

securityheaders.com como se muestra en los ejemplos siguientes. Pruebas adicionales

Se pueden proporcionar capturas de pantalla, como la configuración de los encabezados de seguridad, específicamente HSTS para demostrar aún más la posición de seguridad de la superficie pública.

En las capturas de pantalla siguientes se muestra la configuración de Azure Front Door y el conjunto de reglas implementado para volver a escribir los encabezados.

En la captura de pantalla siguiente se muestra el examen de encabezados de seguridad realizado y que se implementan todos los encabezados de seguridad, no solo HSTS.

Nota: Si se usan el analizador SSL de Qualys o los encabezados de seguridad, la expectativa será que se proporcione el informe completo para una revisión.

Datos en reposo

Cuando los ISV almacenan los datos consumidos desde la plataforma de Microsoft 365, los datos deben protegerse adecuadamente. En esta sección se tratan los requisitos de protección de los datos almacenados en bases de datos y almacenes de archivos.

Control Nº 3

Proporcione pruebas demostrables de que los datos en reposo se cifran de acuerdo con los requisitos del perfil de cifrado, mediante algoritmos de cifrado como AES, Blowfish, TDES y tamaños de clave de cifrado de 128 bits y 256 bits.

Intención:

Se sabe que algunos algoritmos de cifrado antiguos contienen algunas debilidades criptográficas, lo que aumenta las posibilidades de que un actor de amenazas pueda descifrar los datos sin conocimiento de la clave. Por este motivo, la intención de este control es garantizar que solo se usen algoritmos de cifrado aceptados por el sector para proteger los datos almacenados de M365.

Directrices:

La evidencia se puede proporcionar mediante capturas de pantalla, que muestran el cifrado que se emplea para proteger los datos M365 dentro de bases de datos y otras ubicaciones de almacenamiento. La evidencia debe demostrar que la configuración de cifrado está en consonancia con los requisitos de configuración del perfil de cifrado de la certificación de Microsoft 365.

Evidencia de ejemplo:

En la captura de pantalla siguiente se muestra que TDE (cifrado de datos transparente) está habilitado en la base de datos de Contoso. En la segunda captura de pantalla se muestra la página de documentación de Microsoft Cifrado de datos transparente para SQL Database, SQL Managed Instance y Azure Synapse Analytics que muestra que se usa el cifrado AES 256 para Azure TDE.

Nota: En los ejemplos anteriores no se usaron capturas de pantalla completas, pero todas las capturas de pantalla de pruebas enviadas por ISV deben ser capturas de pantalla completas que muestren la dirección URL, la hora y la fecha de inicio de sesión del usuario y del sistema.

Evidencia de ejemplo:

En la captura de pantalla siguiente se muestra Azure Storage configurado con cifrado para blobs y archivos. En la captura de pantalla siguiente se muestra la página documentación de Microsoft Cifrado de Azure Storage para datos en reposo que muestra que Azure Storage usa AES-256 para el cifrado.

Retención, copia de seguridad y eliminación de datos

Cuando los ISV consumen y almacenan datos de Microsoft 365, existe el riesgo de que un actor de amenazas ponga en peligro el entorno de ISV. Para minimizar este riesgo, las organizaciones solo deben conservar los datos que necesitan para entregar servicios y no los datos que "puedan" usar en el futuro. Además, los datos solo se deben conservar durante el tiempo necesario para proporcionar los servicios para los que se capturaron los datos. La retención de datos debe definirse y comunicarse con los usuarios. Una vez que los datos superan el período de retención definido, se deben eliminar de forma segura para que los datos no se puedan reconstruir ni recuperar.

Control Nº 4

Proporcione pruebas de que se ha establecido y documentado formalmente un período de retención de datos aprobado.

Intención:

Una política de retención documentada y seguida es importante no solo para cumplir algunas obligaciones legales, por ejemplo, la legislación de privacidad de datos como, entre otras, el Reglamento general de protección de datos (RGPD de la UE) y la Ley de protección de datos (DPA del Reino Unido 2018), sino también para limitar el riesgo de las organizaciones. Al comprender los requisitos de datos de las organizaciones y cuánto tiempo se necesitan para que la empresa realice sus funciones, las organizaciones pueden asegurarse de que los datos se eliminen correctamente una vez que expire su utilidad. Al reducir los volúmenes de datos almacenados, las organizaciones reducen la cantidad de datos que se expondrían en caso de que se produzca un riesgo de datos. Esto limitará el impacto general.

A menudo, las organizaciones almacenarán datos porque es agradable tenerlos por si acaso. Sin embargo, si la organización no necesita los datos para realizar su servicio o función empresarial, los datos no deben almacenarse, ya que esto aumenta innecesariamente el riesgo de la organización.

El objetivo de este control es confirmar que la organización ha establecido y documentado formalmente un período de retención de datos aprobado para todos los tipos de datos pertinentes. Esto implica no solo especificar la duración durante la que se almacenarán los distintos tipos de datos, sino también definir los procedimientos para la eliminación de datos o el archivo después de la expiración.

Directrices:

Proporcione la directiva de retención de datos completa que detalla claramente cuánto tiempo deben conservarse los datos (debe cubrir todos los tipos de datos) para que la empresa pueda realizar sus funciones empresariales.

Evidencia de ejemplo:

En la captura de pantalla siguiente se muestra la directiva de retención de datos de Contoso.

Nota: Estas capturas de pantalla muestran una instantánea de un documento de directiva o proceso. La expectativa es que los ISV compartan la documentación real de procedimientos o directivas auxiliares y no simplemente proporcionen una captura de pantalla.

Control Nº 5

Demostrar que los datos solo se conservan durante el período de retención definido, como se describe en el control 4.

Intención:

La intención de este control es simplemente validar que se cumplen los períodos de retención de datos definidos. Como ya se ha comentado, las organizaciones pueden tener la obligación legal de cumplir esto, pero también manteniendo los datos necesarios y durante el tiempo necesario ayuda a reducir el riesgo para la organización en caso de que se produzca una vulneración de datos. Esto garantiza que los datos no se conserven durante una duración excesivamente larga ni se eliminen prematuramente, lo que podría suponer riesgos de naturaleza variable (legales, operativas o relacionadas con la seguridad).

Directrices:

Proporcione pruebas de captura de pantalla (o a través de un recurso compartido de pantalla) que muestren que los datos almacenados (en todas las distintas ubicaciones de datos, incluidas las bases de datos, los recursos compartidos de archivos, los archivos y las copias de seguridad) no superan la directiva de retención de datos definida. Entre los ejemplos de capturas de pantalla aceptables se incluyen:

• Registros de base de datos con un campo de fecha, buscados en el orden de registro más antiguo y/o
• Ubicaciones de almacenamiento de archivos que muestran marcas de tiempo que están dentro del período de retención. Nota: Los datos personales o confidenciales de los clientes deben redactarse en la captura de pantalla.
• Registros de copia de seguridad que muestran que los datos de copia de seguridad se conservan dentro del período de retención definido y se eliminan correctamente después de este período.

Evidencia de ejemplo:

La siguiente evidencia muestra una consulta SQL que muestra el contenido de la tabla de base de datos ordenada en orden ascendente en el campo "DATE_TRANSACTION" para mostrar los registros más antiguos de la base de datos. Esto muestra que los datos tiene menos de dos meses de antigüedad, lo que no supera el período de retención definido.

Nota: Se trata de una base de datos de prueba, por lo que no hay muchos datos históricos dentro de ella.

Nota: En los ejemplos anteriores no se usaron capturas de pantalla completas, pero todas las capturas de pantalla de pruebas enviadas por ISV deben ser capturas de pantalla completas que muestren la dirección URL, la hora y la fecha de inicio de sesión del usuario y del sistema.

Control Nº 6

Demostrar que los procesos están en vigor para eliminar datos de forma segura después de su período de retención.

Intención:

La intención de este control es asegurarse de que el mecanismo utilizado para eliminar datos que superan el período de retención lo está haciendo de forma segura. Los datos eliminados a veces se pueden recuperar; por lo tanto, el proceso de eliminación debe ser lo suficientemente sólido como para garantizar que los datos no se puedan recuperar una vez eliminados.

Directrices:

Si el proceso de eliminación se realiza mediante programación, proporcione una captura de pantalla del script que se usa para realizarlo. Si se ejecuta según una programación, proporcione una captura de pantalla que muestre la programación. Por ejemplo, un script para eliminar archivos dentro de un recurso compartido de archivos se puede configurar como un trabajo CRON, captura de pantalla del trabajo CRON que muestra la programación y el script que se ejecuta; y proporcione el script que muestra el comando usado.

Evidencia de ejemplo:

Se trata de un script sencillo que se podría usar para eliminar todos los registros de datos retenidos en función de la fecha -WHERE DateAdd es de -30 días, lo que purgará todos los registros retenidos anteriores a 30 días después de la fecha de retención de datos seleccionada. Tenga en cuenta que necesitaremos el script; evidencia del trabajo que se está ejecutando y los resultados.

Nota: En los ejemplos anteriores no se usaron capturas de pantalla completas, pero todas las capturas de pantalla de pruebas enviadas por ISV deben ser capturas de pantalla completas que muestren la dirección URL, la hora y la fecha de inicio de sesión del usuario y del sistema.

Evidencia de ejemplo:

La captura de pantalla siguiente se ha tomado de la directiva de retención de datos de Contoso (del control 4): muestra los procedimientos usados para la destrucción de datos.

Nota: Esta captura de pantalla muestra una instantánea de un documento de directiva o proceso. La expectativa es que los ISV compartan la documentación real de procedimientos o directivas auxiliares y no simplemente proporcionen una captura de pantalla.

Evidencia de ejemplo:

En este ejemplo se ha creado un Runbook y una programación correspondiente en Azure para eliminar de forma segura los registros que tienen una fecha de finalización creada a partir de los 30 días posteriores a la expiración de la directiva de retención de registros de datos. Este trabajo se establece para ejecutarse cada mes el último día del mes.

En la captura de pantalla siguiente se muestra que el Runbook se ha editado para buscar registros y que tiene comandos de eliminación que no están en la vista, como el script.

Nota: La dirección URL completa y el nombre de usuario deben estar en vista para estas capturas de pantalla y los ISV serán necesarios para mostrar una captura de pantalla de antes del recuento de registros de eliminación y una captura de pantalla del recuento de registros después de la eliminación.

Estas capturas de pantalla son simplemente ejemplos de las distintas formas en que se puede abordar esto.

Control Nº 7

Proporcione pruebas que demuestren lo siguiente:

• Un sistema de copia de seguridad automatizado está implementado y configurado para realizar copias de seguridad a horas programadas.

• La información de copia de seguridad se prueba de acuerdo con el procedimiento de programación de copia de seguridad y se restaura periódicamente para confirmar la confiabilidad y la integridad de los datos.

• Se implementan controles de acceso y mecanismos de protección adecuados (es decir, copias de seguridad inmutables) para garantizar que las copias de seguridad o las instantáneas del sistema estén protegidas contra el acceso no autorizado y para garantizar la confidencialidad, integridad y disponibilidad de los datos de copia de seguridad.

Intención:

El objetivo de este control es confirmar que la organización tiene un sistema de copia de seguridad automatizado, que está configurado para ejecutar copias de seguridad en tiempos predeterminados.

Directrices:

Proporcione capturas de pantalla de los valores de configuración de la solución de copia de seguridad que muestran que las copias de seguridad se realizan en períodos o intervalos de tiempo programados. Si la solución realiza automáticamente la programación de copia de seguridad, puede ser compatible con la documentación del proveedor.

Evidencia de ejemplo:

La captura de pantalla siguiente se aplica al Azure Database for MySQL, que es una instancia administrada. Indica que se ha completado una primera copia de seguridad automatizada.

La siguiente captura de pantalla se realiza una vez transcurrido un período que muestra que se han realizado más copias de seguridad completas. Las copias de seguridad en servidores flexibles se basan en instantáneas, donde la primera copia de seguridad de instantáneas se programa inmediatamente después de crear un servidor y se realizan más copias de seguridad de instantáneas una vez al día.

En la captura de pantalla siguiente se muestra una instantánea de documentación en línea que describe la frecuencia de copia de seguridad y la funcionalidad de copia de seguridad automatizada.

Intención:

El objetivo de este control es confirmar que la información de copia de seguridad no solo se genera según la programación, sino que también es confiable y mantiene su integridad a lo largo del tiempo. Para cumplir este objetivo, se realizarán pruebas periódicas en los datos de copia de seguridad.

Directrices:

Las pruebas para cumplir este control dependerán del proceso y el procedimiento de la organización para probar los datos de copia de seguridad. Se pueden proporcionar pruebas que muestren que las copias de seguridad se prueban correctamente junto con los registros de finalización de pruebas históricas.

Evidencia de ejemplo:

En la captura de pantalla siguiente se muestra que existe un procedimiento de programación y restauración de copia de seguridad y se mantiene y que se define una configuración de copia de seguridad para todos los sistemas aplicables, incluida la frecuencia de las copias de seguridad que se realizan en la plataforma de Confluence.

En la captura de pantalla siguiente se muestra una página de registros históricos de pruebas de copia de seguridad para cada uno de los sistemas aplicables. Observe que en el lado derecho de la tabla se hace referencia a los vales JIRA para cada una de las pruebas.

Las cuatro capturas de pantalla siguientes muestran el proceso de un extremo a otro de restaurar el Azure Database for MySQL a partir de una instantánea. Con la opción "Restauración rápida", podemos iniciar el proceso de restauración de la base de datos SQL.

En la captura de pantalla siguiente se muestra la página de configuración donde se puede personalizar la restauración.

Una vez seleccionada la ubicación de destino, las redes y la instantánea desde la que se restaurará la base de datos, podemos iniciar la implementación. Observe que nuestra instancia de base de datos se denomina ahora "test".

Después de un total de cinco minutos, la base de datos SQL se restauró correctamente y totalmente a partir de la instantánea de copia de seguridad, como se muestra a continuación.

Una vez completadas las pruebas, de acuerdo con el proceso, se creó un vale JIRA para registrar las pruebas de copia de seguridad y los detalles de la restauración realizada. Esto garantiza que los datos históricos estén disponibles con fines de cumplimiento, así como que existan registros completos para su revisión en la eventualidad de un incidente o desastre para permitir que la organización realice un análisis de la causa principal.

Intención:

A partir del control anterior, se deben implementar controles de acceso para limitar el acceso solo a usuarios individuales responsables de los datos de copia de seguridad. Al limitar el acceso, está limitando el riesgo de que se realicen cambios no autorizados y, por tanto, introducir cambios inseguros. Se debe adoptar un enfoque con privilegios mínimos para proteger las copias de seguridad.

Para proteger correctamente los datos, las organizaciones deben tener en cuenta qué datos consume su entorno o sistemas y dónde se almacenan los datos. Una vez que esto se comprenda y documente por completo.

A continuación, las organizaciones no solo pueden implementar una protección de datos adecuada, sino que también pueden consolidar dónde se encuentran los datos para implementar la protección de forma más eficaz. Además, cuando los datos se consolidan en el menor número posible, es mucho más fácil implementar un control de acceso basado en rol (RBAC) adecuado para limitar el acceso a los pocos empleados que sea necesario.

Directrices:

Se debe proporcionar evidencia del sistema o tecnología que se usa para demostrar los permisos de acceso a las copias de seguridad y las soluciones de copia de seguridad con documentación complementaria de la lista de acceso aprobada.

Evidencia de ejemplo:

Podemos ver en las capturas de pantalla siguientes que los controles de acceso se implementan en la instancia de base de datos para restringir el acceso solo a los usuarios autorizados en función del rol de trabajo.

Evidencia de ejemplo:

Azure SQL Las copias de seguridad automatizadas de Azure SQL Database y Azure SQL Managed Instances se administran mediante Azure y su integridad es responsabilidad de la plataforma Azure; ningún usuario tiene acceso a ellas y se cifran en reposo sin posibilidad de ataques de ransomware. También se replican en otras regiones para su protección.

Administración del acceso a datos

El acceso a datos necesita limitarse a tan pocas personas como sea necesario para reducir las posibilidades de que los datos se vean comprometidos de forma malintencionada o accidental. El acceso a los datos y las claves de cifrado debe limitarse a los usuarios con una necesidad empresarial legítima de acceso para cumplir su rol de trabajo. Se debe implementar un proceso bien documentado y bien establecido para solicitar acceso. El acceso a los datos y las claves de cifrado debe seguir el principio de privilegios mínimos.

Control Nº 8

Proporcione pruebas para demostrar que una lista de personas con acceso a datos o claves de cifrado:

• se mantiene incluyendo la justificación empresarial para cada individuo.

• se aprobaron formalmente en función de los privilegios de acceso necesarios para su función de trabajo.

• se configuran con los privilegios descritos en la aprobación.

Intención:

Las organizaciones deben limitar el acceso a los datos y las claves de cifrado al menor número posible de empleados. La intención de este control es garantizar que el acceso de los empleados a los datos o las claves de cifrado esté restringido a los empleados con una necesidad empresarial clara de dicho acceso.

Directrices:

Documentación o capturas de pantalla de sistemas internos que documenta a todos los empleados con acceso a datos o claves de cifrado junto con la justificación empresarial de por qué estas personas tienen acceso deben proporcionarse. El analista de certificación usará esta lista para muestrear a los usuarios para los controles siguientes.

Evidencia de ejemplo:

En el documento siguiente se muestra la lista documentada de usuarios con acceso a los datos y la justificación empresarial.

Nota: En esta captura de pantalla se muestra un documento de directiva o proceso, la expectativa es que los ISV compartan la documentación real sobre directivas o procedimientos auxiliares.

Intención:

El proceso para conceder acceso a datos o claves de cifrado debe incluir aprobación, lo que garantiza que se requiere el acceso de una persona para su función de trabajo. Esto garantiza que los empleados sin una verdadera razón de acceso no obtengan acceso innecesario.

Directrices:

Normalmente, la evidencia proporcionada para el control anterior puede ayudar a admitir este control. Si no hay una aprobación formal en la documentación proporcionada, las pruebas pueden constar de que se ha generado y aprobado una solicitud de cambio para el acceso dentro de una herramienta como Azure DevOps o Jira.

Evidencia de ejemplo:

Este conjunto de imágenes muestra los vales de Jira creados y aprobados para que el control (i) conceda o deniegue el acceso a datos confidenciales o claves de cifrado. Esta imagen muestra que se ha creado una solicitud en Jira para obtener la aprobación diaria de Sam para las claves de cifrado en el entorno de back-end de los sistemas. Esto se hace como el siguiente paso en el que se ha obtenido la autorización por escrito.

Esto muestra que jon smith ha aprobado la solicitud de acceso diario de Sam a una persona de la administración. (Tenga en cuenta que la aprobación debe proceder de alguien con autoridad suficiente para permitir la solicitud de cambio, no puede ser otro desarrollador).

El anterior muestra un flujo de trabajo en Jira para este proceso. Tenga en cuenta que no se puede agregar nada como Hecho a menos que haya pasado por el proceso de aprobación que está automatizado y, por tanto, no se puede omitir.

El panel Proyecto ahora muestra que se ha aprobado el acceso de Sam Daily a las claves de cifrado. En el trabajo pendiente siguiente se muestra la aprobación de la solicitud de Sam Daily y la persona asignada para realizar el trabajo.

Para cumplir los requisitos de este control, debe mostrar todas estas capturas de pantalla o pruebas similares o equivalentes aplicables con una explicación para demostrar que ha cumplido el requisito de control.

Nota: En los ejemplos anteriores no se usaron capturas de pantalla completas, pero todas las capturas de pantalla de pruebas enviadas por ISV deben ser capturas de pantalla completas que muestren la dirección URL, la hora y la fecha de inicio de sesión del usuario y del sistema.

Evidencia de ejemplo:

En el siguiente ejemplo, se han solicitado permisos de acceso de administrador y control total para un usuario a la base de datos de producción. La solicitud se ha enviado para su aprobación, como se puede ver a la derecha de la imagen y se ha aprobado como se muestra a la izquierda.

La siguiente imagen indica que el acceso se ha aprobado y firmado como se ha hecho.

Nota: En los ejemplos anteriores no se usaron capturas de pantalla completas, pero todas las capturas de pantalla de pruebas enviadas por ISV deben ser capturas de pantalla completas que muestren la dirección URL, la hora y la fecha de inicio de sesión del usuario y del sistema.

Intent

La intención de este subpunto es confirmar que el acceso a los datos o a la clave de cifrado está configurado según lo documentado.

Directrices:

La evidencia se puede proporcionar mediante una captura de pantalla que muestra los datos o los privilegios de acceso de clave de cifrado concedidos a las personas muestreadas. La evidencia debe cubrir todas las ubicaciones de datos.

Evidencia de ejemplo:

En esta captura de pantalla se muestran los permisos concedidos al usuario "John Smith" que serían cruzados

se hace referencia a la solicitud de aprobación de este mismo usuario según las pruebas del control anterior.

Tenga en cuenta que el ejemplo siguiente no es una captura de pantalla completa, se le pedirá que envíe capturas de pantalla completa con cualquier dirección URL, el usuario que ha iniciado sesión y la marca de fecha y hora para la revisión de pruebas. Si es un usuario de Linux, esto se puede hacer a través del símbolo del sistema.

Control Nº 9

Proporcione pruebas de que:

• Se mantiene una lista de todos los terceros con los que se comparten los datos.

• Los acuerdos de uso compartido de datos están vigentes con todos los terceros que consumen datos.

Intención:

Cuando se usan terceros para el almacenamiento o el procesamiento de datos de Microsoft 365, estas entidades pueden suponer un riesgo significativo. Las organizaciones deben desarrollar un buen proceso de administración y diligencia debida de terceros para garantizar que estos terceros almacenan o procesan datos de forma segura y para asegurarse de que respetarán las obligaciones legales que puedan tener, por ejemplo, como procesador de datos en virtud del RGPD.

Las organizaciones deben mantener una lista de todos los terceros con los que comparten datos con algunos o todos los siguientes:

• ¿Qué servicios se proporcionan?

• qué datos se comparten

• por qué se comparten los datos

• información de contacto clave (es decir, contacto principal, contacto de notificación de infracción, DPO, etc.)

• renovación o expiración del contrato

• obligaciones legales o de cumplimiento (es decir, RGPD, HIPAA, PCI DSS, FedRAMP, etc.)

Directrices:

Proporcione documentación en la que se detallan todos los terceros con los que se comparten los datos de Microsoft 365.

Nota: Si terceros no están en uso, será necesario confirmarlo por escrito (correo electrónico) por un miembro del equipo directivo sénior.

Evidencia de ejemplo:

Nota: - En los ejemplos anteriores no se usaron capturas de pantalla completas, pero todas las capturas de pantalla de pruebas enviadas por ISV deben ser capturas de pantalla completas que muestren la dirección URL, la hora y la fecha de inicio de sesión del usuario y del sistema.

Evidencia de ejemplo:

En la captura de pantalla siguiente se muestra un ejemplo de correo electrónico de un miembro del equipo directivo sénior que confirma que no se usan terceros para procesar datos de Microsoft 365.

Nota: - En estos ejemplos no se usaron capturas de pantalla completas, pero todas las capturas de pantalla de pruebas enviadas por ISV deben ser capturas de pantalla completas que muestren la dirección URL, la hora y la fecha de inicio de sesión del usuario y del sistema.

Intención:

Cuando los datos de M365 se comparten con terceros, es importante que los datos se administren de forma adecuada y segura. Los acuerdos de uso compartido de datos deben establecerse para garantizar que terceros solo procesan datos según sea necesario y que comprenden sus obligaciones de seguridad. La seguridad de las organizaciones es tan fuerte como el vínculo más débil. La intención de este control es asegurarse de que los terceros no se conviertan en un vínculo débil de las organizaciones.

Directrices:

Proporcione los acuerdos de uso compartido de datos vigentes con terceros.

Evidencia de ejemplo:

En la captura de pantalla siguiente se muestra un ejemplo simplista de un acuerdo de uso compartido de datos.

Nota: El contrato completo debe compartirse y no una captura de pantalla.

Privacidad

El cumplimiento de la privacidad y la administración de la información son esenciales para proteger los derechos de las personas y garantizar el control responsable de los datos. Para que una organización establezca un sistema de información de privacidad eficaz, deben ser conscientes de los datos personales que contienen y del propósito de procesar y almacenar dichos datos. Una organización debe asignar el flujo de información y cómo se procesa, reconociendo que pueden producirse varios tipos diferentes de procesamiento.

Control Nº 10: datos personales

Proporcione pruebas de que su organización:

A) Mantiene un inventario actualizado de todos los datos personales recopilados, procesados y almacenados, incluido el propósito de cada elemento de datos. 

B) Diseña formularios de recopilación de datos para incluir solo los campos necesarios para el propósito empresarial e implementa los campos obligatorios y opcionales adecuadamente. 

C) Desarrolla y aplica directivas que especifican los tipos de datos personales que se pueden recopilar y los fines para los que se pueden usar. 

D) Permite a los usuarios no participar en el procesamiento o ampliar la presentación de sus datos personales y no esenciales para la empresa. 

Intención:

La intención de este control es asegurarse de que se adhiere a la privacidad de los datos relacionada con la recopilación de datos, garantizando que haya una justificación para los datos que se capturan y que sea transparente con qué y por qué se recopilan los datos. También es importante que los usuarios (interesados) tengan la capacidad de no participar en el procesamiento.  

Directrices:

Este control podría demostrarse de la siguiente manera:

A) Proporcione una versión actual del registro de actividades de procesamiento (RoPA) de la organización, (consulte el artículo 30 del RGPD) o un documento similar en el que se detallan los elementos de datos y los propósitos del procesamiento (consulte el artículo 5.1.b del RGPD). 

En la mayoría de los casos, se trataría de una hoja de cálculo de Excel (que se podría extraer de herramientas, como OneTrust). 

Si el archivo es demasiado grande o contiene datos confidenciales, se podría proporcionar un extracto que muestre todos los campos de datos de una muestra de datos determinada, que se pueden redactar parcialmente siempre y cuando la evidencia pueda proporcionar garantía de que el RoPA está en vigor. 

No compatible: los registros no existen, son muy antiguos o obsoletos o faltan campos clave. 

B) A efectos de "Minimización de datos" (véase el artículo 5.1.c del RGPD), proporcione todos los formularios utilizados para obtener datos, ya sea en línea, con tabletas o dispositivos similares (por ejemplo, en una conferencia) o en papel. Podrían estar en blanco o en plantillas. 

No compatible: los formularios tienen campos obligatorios que no son necesarios para el propósito previsto de procesamiento. Por ejemplo, pedir números de teléfono, edad o sexo, para enviar un folleto por correo electrónico o a una dirección postal.  

C) Con el fin de "licitud, equidad y transparencia" (consulte el artículo 5.1.a del RGPD) la Política de privacidad (destinada a los empleados), el Aviso de privacidad (destinado a usuarios o clientes) debe estar en vigor. Normalmente, el Aviso de privacidad debe estar disponible públicamente en el sitio web de la organización.  

No compatible: las directivas no existen o faltan elementos clave. 

Elementos clave:

Política de privacidad/Aviso: recopilación y uso de información, elementos de datos procesados, la finalidad del procesamiento, la legalidad del procesamiento, las transferencias de datos a otros países, los derechos del interesado, el almacenamiento y la retención de datos.  

D) Para el mecanismo de exclusión (consulte el artículo 4.11 del RGPD, el artículo 6 del RGPD y el artículo 7 del RGPD), normalmente en una página web. Compruebe la navegación que el usuario tendría que seguir para llegar a esa página (por ejemplo, ¿es fácil de encontrar?). 

No compatible: no hay ninguna funcionalidad de exclusión clara o exclusión "genérica", sin granularidad. 

Evidencia de ejemplo:

Para A):

Para B):

Para C)::

Para D)::

Control Nº 11: reconocimiento del usuario

Proporcione pruebas de que los usuarios son conscientes de lo siguiente:

A) que tiene acceso a sus datos

B) que tiene acceso a los espacios en los que trabajan

C) que podrían obtener acceso a sus datos mediante el uso compartido o los flujos de datos para que puedan tomar decisiones informadas.

Intención:

La intención de este control es demostrar que se cumple el principio de "transparencia" de protección de datos (consulte el artículo 5.1.a del RGPD).

Directrices:

Para demostrar que esto está en vigor, lo ideal es que haya algún tipo de confirmación de usuario (por ejemplo, haber leído la Política de privacidad) que debe estar en su lugar y registrarse.

En la práctica, solo que la Política de privacidad (para empleados), el Aviso de privacidad (para usuarios y clientes), proporcionan suficientes detalles sobre lo siguiente:

- Con quién se comparten datos personales (procesadores, subprocesadores, terceros, contratistas, etc.).

No compatible: no existen confirmaciones o la Política de privacidad o el Aviso de privacidad no existen.

Evidencia de ejemplo:

OR

Control Nº 12: Acuerdos de procesamiento de datos (APA)

Proporcione pruebas del Acuerdo de procesamiento de datos, que debe tener una lista de todos los terceros o subprocesadores aprobados.

Intención:

Para garantizar que sea transparente con los interesados, asegúrese de que están informados sobre qué terceros o subprocesadores podrían tener acceso a sus datos, el rol que desempeñan en el procesamiento (controlador de datos, procesador de datos), sus respectivas responsabilidades y mecanismos de seguridad.

Además, cuando el uso compartido de datos implicaría transferencias de datos a territorios fuera de la UE (en virtud del RGPD), los detalles del mecanismo para garantizar que las transferencias sean lícitas. (Consulte el artículo 5 del RGPD y el artículo 44-50 del RGPD)

En el caso del RGPD, los territorios para el procesamiento deben cumplir una de las condiciones siguientes:

- Ser un Estado miembro de la Unión Europea.

- La Comisión Europea considera que proporciona «garantías adecuadas». La lista actual se puede encontrar aquí: Adecuación de la protección de datos para países que no son de la UE

A partir del^{13 de} junio de 2025:

- Forma parte del Marco de privacidad de datos (DPF) y aparece aquí: Marco de privacidad de datos

- Tener reglas corporativas vinculantes (BCR) en vigor.

- Tener Standard cláusulas contractuales (CCC) en vigor.

Directrices:

La evidencia podría ser mediante el muestreo de un par de acuerdos de procesamiento de datos (DPA) con subprocesadores existentes. En algunos casos, es posible que las organizaciones no tengan PDA, pero tendrían anexos a contratos o "cláusulas de privacidad".

No compatible:

- Falta la lista de 3 partes^rd /subprocesadores.

- No se proporcionan detalles sobre los países receptores.

- Los países no figuran como "países adecuados", y no existen BCR ni CCC.

Evidencia de ejemplo:

En este ejemplo se muestra un DPA de ejemplo de IAPP, o la evidencia podría ser un documento relacionado que enumera las partes con las que se comparten los datos.

Además, compruebe los mecanismos de transferencia de datos fuera de la UE.

Control Nº 13: Evaluaciones de impacto de la protección de datos (DPIA)

Proporcionar pruebas de que su organización lleva a cabo la evaluación de impacto de la protección de datos (DPIA)

     OR

Proporcione el nombre de la evaluación relacionada con la privacidad de los datos y la protección a la que está conectada esta revisión de privacidad.

Intención:

La intención de este control es asegurarse de que está realizando evaluaciones sobre los posibles riesgos para los derechos y libertades de las personas, especialmente relacionadas con la introducción de nuevas tecnologías, o los nuevos usos de las tecnologías existentes. (Consulte el artículo 35 del RGPD)

Directrices:

Este control se evaluaría revisando una dpia reciente o documentación de evaluación relacionada.

No compatible:

Una INSTANCIA de PPPA debe tener los siguientes elementos:

- Identificación de la necesidad de un DPIA.

- Descripción del tratamiento previsto, incluido el ámbito, el contexto y los propósitos.

- Evaluación de la necesidad y la proporcionalidad.

- Identificación y evaluación de riesgos.

- Identificación de medidas para reducir el riesgo.

- Resultados registrados.

Si falta alguno de los elementos anteriores o simplemente se realiza en un nivel de función, este control se puede marcar como no compatible.

Evidencia de ejemplo:

La plantilla completa de un DPIA se puede encontrar en el sitio web de ICO aquí dpia-template.docx

Control Nº 14: datos biométricos

¿Interactúa la aplicación con datos biométricos? Si es así,

Proporcione pruebas de que los datos biométricos han pasado una revisión legal, que están protegidos y que se informa a los usuarios y se les da la opción de participar o no en la recopilación de datos biométricos.

Intención:

Este control está interesado en garantizar una protección adecuada de los datos biométricos, que según el artículo 9 del RGPD se clasifica como una categoría especial de datos.  El uso de datos biométricos se ha sometido a un análisis de legalidad.

Directrices:

El uso de datos biométricos debe pasar por una revisión legal, por lo que debe proporcionarse como parte de la recopilación de pruebas. Si no existe ninguna, solicite la plantilla que se usaría (para comprobar su preparación).

No compatible:

La revisión legal sobre el procesamiento de datos biométricos debe contener lo siguiente:

- Base jurídica del procesamiento (uno o varios de los siguientes elementos):

Consentimiento	Rendimiento de un contrato	Otra obligación legal
Consentimiento	Rendimiento de un contrato	Otra obligación legal
Intereses vitales	Interés público	Interés legítimo

- Enumerar una condición válida para procesar datos biométricos (uno o varios de los siguientes):

Consentimiento explícito del usuario	Empleo o seguridad social
Consentimiento explícito del usuario	Empleo o seguridad social
Protección de intereses vitales	Actividades legítimas
Datos personales hechos públicamente por el interesado	Establecimiento, ejercicio o defensa de reclamaciones legales
Interés público sustancial	Medicina preventiva o profesional
Interés público en el área de salud pública	Fines de archivado de interés público, investigación científica o histórica

- Consideración dada al uso de alternativas, en lugar de datos biométricos.

Si falta alguno de los elementos anteriores o simplemente se realiza en un nivel de función, este control se puede marcar como no compatible.

Evidencia de ejemplo:

Fuentes:

- Artículo 9 del RGPD : Procesamiento de categorías especiales de datos: Art. 9 RGPD – Procesamiento de categorías especiales de datos personales - Reglamento general de protección de datos (RGPD)

- ICO '¿Cómo procesamos legalmente los datos biométricos?': ¿Cómo procesamos legalmente los datos biométricos? | ICO

 

Control Nº 15: Data Insights

Proporcione pruebas de que las métricas solo muestran datos agregados y anonimizados sin datos de identificación individual. El inquilino debe poder configurar su nivel de agregación preferido, con un mínimo absoluto de 5 permitido por el producto.

Intención:

La intención de este control es asegurarse de que ha implementado y mantiene el estado de los datos anonimizados y seudonimizados a lo largo del ciclo de vida de los datos. (Consulte

Directrices:

Para ayudar a demostrar que este control está implementado, la evidencia a través de la GUI o la CLI debe proporcionarse para demostrar lo siguiente:

- Configuración de nivel de usuario para los límites más bajos de los niveles de agregación.

- Un ejemplo de métricas.

Evalúe si el usuario puede configurar un umbral para sus niveles de agregación preferidos a un mínimo de 5. La evidencia debe demostrar que solo anonimizados está presente en la muestra de métricas.

No compatible:

- Los usuarios no pueden personalizar sus niveles de agregación a un mínimo de 5, o la aptitud técnica necesaria para hacerlo no se puede esperar del usuario típico.

- Los datos personales están presentes en el ejemplo de métricas; por ejemplo: nombre, apellidos, identificador, número de cliente, número de teléfono, dirección de correo electrónico, dirección postal, datos bancarios, familiares próximos, etc.

Evidencia de ejemplo:

Capturas de pantalla de los valores de configuración, que muestran los detalles específicos.

Ejemplo de métricas recopiladas. Quizás pregunte sobre el proceso para lograr el anonimato.

RGPD

La mayoría de las organizaciones procesarán datos potencialmente de un ciudadano europeo (interesados). Cuando se procesen los datos de CUALQUIER interesado, las organizaciones deberán cumplir con el Reglamento General de Protección de Datos (RGPD). Esto se aplica tanto a los controladores de datos (está capturando directamente dichos datos) como a los procesadores de datos (está procesando estos datos en nombre de un controlador de datos). Aunque esta sección no cubre toda la regulación, aborda algunos de los elementos clave del RGPD para ayudar a obtener cierta seguridad de que la organización se está tomando en serio el RGPD.

Control Nº 16

Proporcione pruebas que demuestren la adhesión a los derechos de los interesados mostrando:

A) Facilitación de la solicitud de acceso del sujeto (SAR):

La documentación que confirma que los interesados están informados de su derecho a acceder a sus datos personales y pueden enviar solicitudes de acceso del interesado (SAR) a su organización.

 

B) Detección de datos y cumplimiento de SAR:

Evidencia de la capacidad de su organización para localizar y recuperar todos los datos personales pertenecientes a un interesado individual en todos los sistemas y repositorios en respuesta a un SAR.

Intención:

La intención de este control es asegurarse de que existen mecanismos adecuados para que los interesados realicen solicitudes sobre sus datos personales en poder de la organización, y que el cumplimiento de las solicitudes legítimas sea exhaustivo. (Consulte el artículo 15 del RGPD).

Directrices:

R) El Aviso de privacidad debe contener detalles sobre cómo crear un SAR, que podría usar los métodos siguientes:

- Uso de un formulario web proporcionado por la organización

- Uso de una dirección de correo electrónico proporcionada por la organización

- Uso de un número de teléfono o webchat proporcionado por la organización

- Usar una autoridad de supervisión (por ejemplo, la ICO en el Reino Unido)

Solicitar pruebas del método en su lugar; capturas de pantalla deben ser suficientes.

B) Se puede usar un RoPA o un documento similar para identificar las ubicaciones en las que residen los datos personales relativos al interesado, ya sean digitales o como parte de los sistemas de presentación (físicos).

Como alternativa, los ejercicios de detección electrónica pueden lograr el mismo resultado.

Solicitar pruebas del proceso o flujo de trabajo que se usarían para cumplir una SAR, y una explicación sobre cómo se determinó que el proceso es exhaustivo y no se perdería ningún dato personal relacionado con el interesado.

No compatible:

R) No se proporciona información en el sitio web de la organización (normalmente en el Aviso de privacidad).

B) La evidencia indica que el proceso para recopilar los datos personales no es exhaustivo o puede carecer de detalles técnicos (por ejemplo, no se proporcionan nombres ni ubicaciones para las bases de datos).

Evidencia de ejemplo:

A) A continuación se muestran ejemplos de qué pruebas se podrían proporcionar para cubrir el punto A).

– Formulario web:

Fuente: Solicitud de acceso del sujeto - Police Care UK

- Email dirección o número de teléfono:

Origen: ¿Cuál? Política de privacidad: ¿Qué?

- Webchat:

Origen: Realice una solicitud de acceso de sujeto a HMRC- GOV.UK

- A través de una autoridad de supervisión (por ejemplo, la ICO):

Origen: Realizar la solicitud de acceso del sujeto | ICO

B) Elementos de evidencia proporcionados Detallando flujos de trabajo o descripciones de procesos con suficiente detalle técnico, que podrían utilizarse plausiblemente para cumplir con la RAE.

Control Nº 17

Proporcione el Aviso de privacidad que debe contener todos los elementos necesarios de la siguiente manera:

A) Los detalles de identidad y contacto de la organización, y del responsable de protección de datos (DPO), si procede.

B) Los tipos de datos personales que su organización controla (nombre, apellido, número de cliente, dirección de correo electrónico, número de teléfono, etc.). Además, los orígenes de datos personales (por ejemplo, de dónde proceden los datos personales), en caso de que la organización no los haya obtenido directamente de los interesados.

C) La finalidad del tratamiento de datos personales.

D) La base legal del tratamiento de datos personales (incluidos los intereses legítimos cuando proceda).

E) Partes con las que su organización comparte datos personales.

F) Detalles de cuánto tiempo se conservarán los datos personales.

G) Detalles de los derechos de los interesados:

• Derecho a ser informado

• Derecho de acceso

• Derecho a rectificación

• Derecho a borrar

• Derecho a la restricción del procesamiento

• Derecho a la portabilidad de datos

• Derecho al objeto

• Derechos en relación con la toma de decisiones automatizada, incluida la generación de perfiles

H) Los detalles relativos a cualquier transferencia de datos personales a un tercer país y las medidas de seguridad adoptadas.

I) El derecho a presentar una reclamación ante una autoridad de supervisión, proporcionando los datos de contacto de la autoridad de supervisión (por ejemplo, la ICO en el Reino Unido).

Intención:

La intención es garantizar que el Aviso de privacidad publicado contenga suficientes detalles incluyendo los elementos y principios anteriores, de conformidad con el capítulo 3 del RGPD.

Directrices:

Según control 10.c por el que debe publicar un Aviso de privacidad que cubra el servicio incluido en la certificación de Microsoft 365. Este Aviso de privacidad debe contener los elementos y principios resaltados anteriormente.

No compatible:

Consulte Control 10.c.

Evidencia de ejemplo:

Consulte Control 10.c.

HIPAA (Ley de portabilidad y responsabilidad del seguro de salud)

La Ley de Portabilidad y Responsabilidad del Seguro De Salud de 1996 (HIPAA) es una legislación federal aplicable a los ciudadanos estadounidenses y a las organizaciones sanitarias. Es importante tener en cuenta que esta legislación también cubre a todas las organizaciones fuera de ee. UU. que procesan datos de atención sanitaria de ciudadanos estadounidenses. La introducción de la legislación obligaba al Secretario del Departamento de Salud y Servicios Humanos (HHS) de los Estados Unidos a elaborar regulaciones que protesen la privacidad y la seguridad de cierta información sanitaria. Algunas organizaciones pueden procesar datos que son información de salud potencialmente protegida (ePHI), lo que significa información de salud identificable individualmente transmitida por medios electrónicos, mantenida en medios electrónicos, o transmitida o mantenida en cualquier otra forma o medio. Cuando se procesen los datos de estado de CUALQUIER interesado, las organizaciones deberán cumplir con HIPAA.

HIPAA tiene dos leyes que deben tenerse en cuenta: "La regla de privacidad", o estándares para la privacidad de la información de salud identificable individualmente, que describe los estándares nacionales para la protección de cierta información de salud, y "Los estándares de seguridad" para la protección de la información de salud protegida electrónica también se conocen como la "Regla de seguridad". Esta última establece un conjunto nacional de normas de seguridad para proteger cierta información sanitaria que se mantiene o transfiere en forma electrónica.

A partir de una introducción de alto nivel, "La regla de seguridad" es una implementación práctica de las protecciones que ofrece la "Regla de privacidad". En él se describen las medidas técnicas y no técnicas que las "entidades cubiertas" deben implementar para garantizar la seguridad de la "información sanitaria protegida electrónicamente" (e-FI). Aunque esta sección no cubre toda la regulación, aborda algunos de los elementos clave de HIPAA para ayudar a obtener cierta seguridad de que la organización cumple con el requisito y que la organización protege la información de salud que procesa.

Control Nº 18

Proporcione pruebas demostrables de que:

• Existe una directiva para el control de HIPAA e HIPAA dentro de su organización para el personal, contratistas, etc.

• ISV garantiza la confidencialidad, integridad y disponibilidad de ePHI que crea, recibe, mantiene o transmite.

• Proteja contra cualquier amenaza y peligro razonablemente previsto para la seguridad o integridad de ePHI.

Intención:

La intención de este subpunto es asegurarse de que las organizaciones han establecido protocolos que sirven como procedimientos estándar para administrar la información sanitaria, tratar las emergencias y las interrupciones del servicio, y el acceso del personal a la información sanitaria y la formación. Además, se espera que las organizaciones mantengan y describan estas medidas de seguridad administrativas como parte de su programa de seguridad HIPAA. Este es un aspecto crucial del cumplimiento de las regulaciones hipaa.

Directrices:

Esto se demostraría proporcionando la documentación establecida de la organización que describe la directiva y el procedimiento hipaa. Los analistas de certificación revisarán esto para asegurarse de que se aborda toda la información proporcionada dentro del control.

Evidencia de ejemplo:

Las capturas de pantalla muestran instantáneas de una directiva HIPAA. Tenga en cuenta: La expectativa es que los ISV compartan la documentación real de procedimientos o directivas auxiliares y no simplemente proporcionen una captura de pantalla.

Nota: La expectativa es que un ISV comparta la documentación completa real de procedimientos o directivas auxiliares y no simplemente proporcione una captura de pantalla.

Intención:

Para comprender la intención de este subpunto y garantizar el cumplimiento con la regla de seguridad, las "entidades cubiertas" primero deben saber cómo se definen los términos de confidencialidad, integridad y disponibilidad en § 164.304:

• Confidencialidad: "la propiedad de que los datos o la información no están disponibles o divulgados a personas o procesos no autorizados".

• Integridad: "la propiedad que los datos o la información no se han modificado o destruido de forma no autorizada".

• Disponibilidad: "la propiedad de que los datos o la información son accesibles y utilizables a petición de una persona autorizada".

La intención de este requisito es que las organizaciones implementen medidas o medidas técnicas como el acceso, la auditoría, la integridad y los controles de transmisión dentro de la infraestructura de TI para garantizar la confidencialidad de ePHI y, al mismo tiempo, mantener su integridad y disponibilidad para los usuarios autorizados.

Directrices:

Las pruebas se pueden proporcionar a modo de configuración de los mecanismos de protección utilizados para garantizar que los datos de ePHI estén protegidos de acuerdo con el requisito de control. Estos mecanismos pueden incluir controles de acceso, procedimientos de acceso de emergencia, RBAC, cifrado, etc.

Evidencia de ejemplo: controles de acceso e integridad

En la captura de pantalla siguiente se muestra que existe una lista de acceso autorizado de las personas que tienen permisos para controlar las ubicaciones de almacenamiento de ePHI y se mantiene en el documento de directiva HIPAA. Además, en las capturas de pantalla siguientes a la lista de inventario aprobada, se puede observar que el acceso de escritura en el clúster es limitado, ya que solo el administrador y el analista de mantenimiento de bases de datos pueden leer y escribir en el clúster.

La siguiente captura de pantalla tomada de una de las bases de datos de almacenamiento de ePHI en Atlas Mongo muestra que solo los usuarios autorizados tienen el acceso documentado y que todas las cuentas tienen identificadores de usuario únicos para garantizar la responsabilidad.

En la primera captura de pantalla se muestra la ubicación de almacenamiento principal o el clúster de base de datos para ePHI.

En la segunda captura de pantalla se muestra que los usuarios aprobados solo tienen documentados los roles y el acceso.

Las dos capturas de pantalla siguientes muestran una vista más pormenorizada de cada uno de los roles asignados y todos los permisos asociados que están en línea con la aprobación de acceso anterior.

Cada rol personalizado tiene un conjunto de permisos y un ámbito de acceso.

Por último, la siguiente captura de pantalla muestra desde una perspectiva de red que solo el intervalo IP autorizado que es la red corporativa segura tiene acceso al clúster.

Pruebas de ejemplo: controles de auditoría

Estas capturas de pantalla muestran que el registro y las alertas se implementan para el clúster de base de datos. En la primera captura de pantalla se muestra que las alertas están habilitadas. Tenga en cuenta que la expectativa es que la evidencia proporcionada también muestre las reglas de alerta establecidas en función de la necesidad o implementación de la organización. En la segunda captura de pantalla se muestra que se está habilitando la auditoría de base de datos.

En la captura de pantalla siguiente se muestra el historial de acceso al clúster de base de datos que se está registrando. La expectativa es que las alertas se establezcan y se basen en los registros de auditoría y cualquier acceso no autorizado que no cumpla las condiciones predefinidas desencadenará una alerta.

Las dos últimas capturas de pantalla muestran que se generan registros de auditoría para el clúster de base de datos y que los registros se pueden exportar para su análisis.

Tenga en cuenta que la expectativa es que haya un proceso para que los registros de auditoría generados se analicen, también se deben proporcionar pruebas del proceso de revisión. Si esto se logra mediante programación, se deben proporcionar capturas de pantalla de la configuración de la ingesta de registros en la plataforma o solución de registro utilizada, así como capturas de pantalla de las reglas para su revisión.

Evidencia de ejemplo: controles de cifrado y transmisión

En las capturas de pantalla siguientes se muestra que la ubicación de almacenamiento tiene datos en reposo cifrados de forma predeterminada. Tenga en cuenta que si la plataforma usada de forma predeterminada no realiza el cifrado y sus propias claves de cifrado están en uso, la expectativa es que esas claves estén adecuadamente protegidas y se proporcionen pruebas para demostrarlo.

Las dos capturas de pantalla siguientes muestran que la ubicación de almacenamiento tiene datos en tránsito cifrados de forma predeterminada. En la primera captura de pantalla se muestra que una API de datos está habilitada con permisos de "lectura y escritura".

Un examen SSL del punto de conexión muestra que los datos en tránsito se cifran a través de TLS 1.2.

Evidencia de ejemplo: controles de disponibilidad y recuperación

En la captura de pantalla siguiente se muestra que el clúster de base de datos se replica en tres regiones para garantizar la disponibilidad. Mongo Atlas lo hace de forma predeterminada. Además, la copia de seguridad está habilitada y está activa.

En la captura de pantalla siguiente se muestra el panel de copia de seguridad del clúster, que también muestra que ya se ha creado una instantánea.

En las dos capturas de pantalla siguientes se muestra que se ha implementado una directiva de copia de seguridad para realizar copias de seguridad programadas en distintos momentos del tiempo (PIT).

A continuación se indica que hay una directiva de retención para las instantáneas y la restauración a un momento dado (PIT).

Intención:

La intención de este subpunto se alinea con la regla de seguridad que se desarrolló para garantizar la flexibilidad y escalabilidad para que una "entidad cubierta" pueda implementar directivas, procedimientos y soluciones tecnológicas adecuadas para el tamaño de la entidad, su estructura organizativa y sus riesgos específicos, así como su apetito por el riesgo. Desde una perspectiva práctica, esto significa que las medidas de seguridad adecuadas implementadas dependerán de la naturaleza del negocio de la "entidad cubierta", así como de su tamaño y recursos.

Es fundamental que todas las organizaciones realicen un análisis de riesgos completo para descubrir posibles riesgos y vulnerabilidades para la confidencialidad, integridad y disponibilidad de la FI electrónica. A través de este análisis de riesgos, las organizaciones pueden implementar los controles de seguridad adecuados para mitigar estos riesgos identificados.

Directrices:

La evidencia se puede proporcionar mediante la salida del análisis de riesgos. Cuando el análisis de riesgos se realiza y se mantiene a través de una plataforma en línea, se deben proporcionar capturas de pantalla de toda la salida.

Evidencia de ejemplo:

En las capturas de pantalla siguientes se muestran instantáneas del proceso de evaluación de riesgos, seguidas del análisis de riesgos que se realizó para determinar hasta qué punto los controles se implementan correctamente y funcionan según lo previsto para proteger ePHI. En la segunda captura de pantalla se muestra un análisis de riesgos para los riesgos identificados en la evaluación de riesgos y los controles de compensación y mitigaciones implementados para reducir el nivel de riesgo.

Ejemplo 1: Instantánea del proceso de evaluación de riesgos dentro de la directiva HIPAA y el análisis de riesgos realizados

Nota: Esta captura de pantalla muestra una instantánea de un documento de análisis de riesgos, esto es solo un ejemplo, y la expectativa es que los ISV compartan la documentación real y no simplemente proporcionen una captura de pantalla.

Ejemplo 2: Capturas de pantalla del proceso de evaluación de riesgos dentro de la directiva HIPAA y el análisis de riesgos realizado (mantenido en Confluence Cloud Platform)

En la segunda captura de pantalla se muestra un análisis de riesgos para los riesgos identificados en la evaluación de riesgos y los controles de compensación y mitigaciones implementados para reducir el nivel de riesgo. Podemos ver que esto existe y se mantiene en la plataforma en la nube de Confluence.

Control Nº 19

Proporcione pruebas de que usted (ISV):

• Protege contra los usos o divulgaciones razonablemente previstos de dicha información que no están permitidos por la Regla de privacidad; y

• Garantizar el cumplimiento de la regla de seguridad por parte de su personal.

• Plan de copia de seguridad de datos y recuperación ante desastres en 164...308 (a)(7)(ii)(A) y 164.308 (a)(7)(ii)(B).

Intent

La Regla de privacidad define qué fragmentos de información de salud protegida (FI) están cubiertos por la ley y prohíbe los usos y divulgaciones inadecuados de FI. La intención de este subpunto es que una organización debe limitar el acceso y el uso de e-FI solo a aquellos que lo necesiten con fines autorizados y que deben cumplir la regla mínima necesaria, que les obliga a usar o revelar solo la cantidad mínima de FI e-FI necesarias para lograr su propósito previsto.

Debe existir una combinación de medidas de seguridad técnicas y administrativas para restringir el uso de ePHI y garantizar que se reduzca el riesgo de divulgación del ePHI.

Directrices:

Las pruebas proporcionadas deben mostrar las medidas de seguridad técnicas vigentes, como las tecnologías y los mecanismos que se usan para proteger la FI electrónica y cómo los controles de la organización comprueban el acceso y el movimiento de dichos datos.

Evidencia de ejemplo:

Las capturas de pantalla siguientes muestran Prevención de pérdida de datos de Microsoft Purview (DLP), que es una plataforma integrada que permite a las organizaciones administrar sus directivas DLP desde una única ubicación centralizada.

A continuación, puede observar que está habilitada una directiva "Mejorada por HIPAA de EE. UU.". Esto proporciona la capacidad de impedir que los usuarios peguen datos confidenciales en sitios web específicos, como correo electrónico personal, mensajes de IA generativos, sitios de redes sociales y mucho más cuando se accede a ellos a través de un explorador web compatible.

En la siguiente captura de pantalla se proporciona una información general más completa de la directiva, incluido el ámbito al que se aplica. La directiva se establece en todas las cuentas de ubicaciones como SharePoint, Dispositivos, OneDrive, etc.

Al seleccionar la opción "Editar directiva", se muestra una vista más detallada de las configuraciones específicas disponibles.

Las dos capturas de pantalla siguientes muestran la definición de contenido y las condiciones que se deben cumplir para que se aplique la directiva.

La directiva abarca varios tipos de datos confidenciales, así como un conjunto de clasificadores.

En la sección siguiente se muestran las acciones configuradas para realizarse cuando se cumplen las condiciones mostradas en las capturas de pantalla anteriores.

En la captura de pantalla siguiente se muestra que la directiva DLP está establecida para impedir que sus usuarios copien y peguen información confidencial, como información de identificación personal (PII) de las bases de datos internas de la organización en sus cuentas de correo electrónico personales, bots de chat y sitios de redes sociales en exploradores compatibles.

Por último, las notificaciones de usuario están configuradas para notificar y proporcionar instrucciones a los usuarios a medida que controlan los datos de ePHI.

En la captura de pantalla siguiente se muestra el panel de configuración para generar alertas cuando se produce un incidente.

Intención:

La intención de este subpunto es que una organización debe entrenar a su personal sobre cómo controlar la FI electrónica de forma segura y adecuada, y que deben aplicar directivas y procedimientos para garantizar el cumplimiento de la regla de seguridad.

Directrices:

Las pruebas proporcionadas deben demostrar que el entrenamiento hipaa se lleva a cabo sobre cómo controlar ePHI y que existen registros de asistencia y finalización del entrenamiento. Cuando corresponda, esto puede ser compatible con la documentación de directivas y los materiales de aprendizaje utilizados.

Evidencia de ejemplo:

En los ejemplos siguientes se muestran las posibles pruebas que se pueden enviar para demostrar que el entrenamiento de HIPAA adecuado se produce en consonancia con la directiva.

En la captura de pantalla siguiente se muestra una instantánea de la directiva HIPAA con una sección específica que describe el requisito de entrenamiento. Tenga en cuenta que esto es solo un ejemplo y no un documento o implementación completos, la expectativa es que el ISV tenga un proceso establecido que se aplique a su organización.

Ejemplo 1: Entrenamiento de usuarios hipaa mediante proceso administrativo

En la siguiente captura de pantalla, la diapositiva de información general del curso muestra un resumen de los objetivos del curso. Si el entrenamiento se construye en casa, los materiales de entrenamiento deben ser suministrados para su revisión, tenga en cuenta que el material completo debe ser enviado y no sólo una captura de pantalla del resumen.

En la captura de pantalla siguiente se muestra el registro de asistencia de los empleados que participaron en el entrenamiento. El registro también muestra la puntuación de pase, así como la siguiente fecha programada de entrenamiento.

En el segundo ejemplo se muestra cómo se puede usar Microsoft 365 Defender para establecer e iniciar campañas de entrenamiento.

Ejemplo 2: entrenamiento de usuarios hipaa a través de la Plataforma de simulación de ataques de Microsoft 365 Defender (todos los usuarios)

En la captura de pantalla anterior se muestra la campaña de entrenamiento de seguridad HIPAA, la duración total en minutos, así como el estado de finalización. En la captura de pantalla siguiente se proporciona información general sobre los usuarios a los que se asignó el entrenamiento y el estado del entrenamiento, que muestra la finalización correcta.

Ejemplo 3: Entrenamiento de usuarios hipaa a través de la Plataforma de simulación de ataques de Microsoft 365 Defender (usuario individual)

Aunque el ejemplo anterior se centró en demostrar que todos los usuarios completaron la campaña de entrenamiento anual, el ejemplo final muestra pruebas dirigidas que muestran la finalización de un empleado.

Puede observar en las dos capturas de pantalla anteriores que, en cuanto se inició la campaña de entrenamiento, cada empleado recibió un correo electrónico que confirma la asignación de entrenamiento y la fecha de vencimiento, así como los módulos asignados, la duración, etc.

Con el vínculo disponible en la notificación por correo electrónico, en la siguiente captura de pantalla se muestra la página Asignaciones de entrenamiento para el usuario y los dos módulos que ya se han completado.

Intención:

Según la Regla de seguridad hipaa, un plan de copia de seguridad de datos y un plan de recuperación ante desastres son obligatorios para cualquier "entidad cubierta" que controle la información de salud protegida electrónica (ePHI). Estos planes forman parte de la estrategia de contingencia que tiene como objetivo garantizar la disponibilidad y la seguridad de ePHI en caso de emergencia u otra ocurrencia que dañe los sistemas que contienen ePHI.

La intención del plan de copia de seguridad de datos es crear y mantener copias idénticas recuperables de ePHI; esto también debe incluir pruebas periódicas de las copias de seguridad para garantizar que la recuperación de datos sea posible. La intención del plan de recuperación ante desastres es restaurar los posibles datos perdidos en caso de desastre y esto debe especificar los pasos que se deben seguir para restaurar el acceso a los datos, incluido cómo se deben restaurar los archivos a partir de copias de seguridad.

Directrices:

Proporcione la versión completa del plan o procedimiento de recuperación ante desastres que debe cubrir el plan de copia de seguridad y el plan de recuperación. Proporcione el documento PDF/Word real si se encuentra en una versión digital, como alternativa, si el proceso se mantiene a través de una plataforma en línea proporciona una exportación PDF o si no se puede exportar debido a limitaciones de la plataforma, proporcione capturas de pantalla que cubran toda la política.

Evidencia de ejemplo:

En la siguiente captura de pantalla se muestran instantáneas de la directiva de seguridad HIPAA que contienen información general sobre el procedimiento de copia de seguridad general y de alto nivel y el plan de recuperación ante desastres.

Nota: Esta captura de pantalla muestra una instantánea del documento de directiva o proceso, esto es solo un ejemplo, y la expectativa es que los ISV compartan la documentación completa real de procedimientos o directivas auxiliares y no simplemente proporcionen una captura de pantalla.

Libros

Murdoch D. (2018) Blue Team Handbook: Incident Response Edition: A condensed field guide for the Cyber Security Incident Responding Responder. 2nd Edition, Publisher: CreateSpace Independent Publishing Platform.

Referencias

• Informes de ciberdelincuencia de fraudes de acción disponibles en: https://www.actionfraud.police.uk/ (Acceso: 12/10/2023).

• UE. (2021) Lista de comprobación del RGPD para los controladores de datos Disponible en: https://gdpr.eu/checklist/ (Accessed: 12/10/2023).

• Microsoft. (2018) Registro de eventos (Windows Installer) Disponible en: Registro de eventos (al que se accede: 03/05/2024).

• Tecnologías positivas. (2020) Enfoque del desarrollo seguro de software Disponible en: https://www.ptsecurity.com/ww-en/analytics/knowledge-base/how-to-approach-secure-software-development/(Accessed:12/10/2023).

• Reglamento (UE) 2016/679 del Parlamento Europeo y del Consejo, de 27 de abril de 2016, relativo a la protección de las personas físicas en lo que respecta al tratamiento de datos personales y a la libre circulación de dichos datos, y por la que se deroga la Directiva 95/46/CE (Reglamento General de Protección de Datos) (Texto pertinente para el EEE) (2016) disponible en: https://www.legislation.gov.uk/eur/2016/679/contents (Accessed: 12/10/2023).

• Métricas de seguridad. (2020) Guía de métricas de seguridad para el cumplimiento de PCI DSS. Disponible en: https://info.securitymetrics.com/pci-guide-2020(Accesible: 12/10/2023).

• Clasificación de riesgo de Williams J. OWASP disponible en: https://owasp.org/www-community/OWASP_Risk_Rating_Methodology (Accessed: 12/10/2023).

• Qualys. (2014) LABORATORIOS SSL: Nuevos grados de confianza (T) y problemas de discrepancia (M) disponibles en: https://blog.qualys.com/product-tech/2014/06/17/ssl-labs-new-grades-for-trust-t-and-no coincidente-m-issues (accessed: 12/10/2023).

• NIST SP800-61r2: Computer Security Incident Handling Guide Available at: https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final (Accessed: 12/10/2023).

• Creación de una canalización de CI/CD con Azure Pipelines y Google Kubernetes Engine | .NET

• Google Cloud (a la que se accede: 10/10/2023).

• El plan de recuperación ante desastres en: https://www.sans.org/white-papers/1164/ (Accesible: 10/10/2023).

• https://github.com/ (Acceso: 10/10/23).

• Plantillas de directiva de seguridad en: https://www.sans.org/information-security-policy/ (Acceso: 10/10/23).

• https://www.openedr.com/ (Acceso: 02/10/23).

• https://www.atlassian.com/software/confluence (Acceso: 10/10/23).

• https://www.atlassian.com/software/jira (Acceso el 28/09/23).

• Plantilla de ejercicio superior de tabla del plan de continuidad empresarial (BCP) en: https://www.pivotpointsecurity.com/services/business-continuity-management/table-top-exercise-template/ (Accessed: 10/10/23).

• Resumen de la regla de seguridad hipaa | HHS.gov (accedido: 18/10/2023).

• Leyes de privacidad de la información de salud en la era digital: HIPAA no se aplica - PMC (nih.gov) (a la que se accede: 18/10/2023).

• ¿Cuál es el propósito de HIPAA? Actualización 2023 (hipaajournal.com) (Acceso: 18/10/2023).

• ¿Qué se considera FI en HIPAA? Actualización de 2023 (hipaajournal.com) (Acceso: 18/10/2023).

• Directivas y procedimientos hipaa (hipaajournal.com) (acceso: 18/10/2023).

• Diseño de directivas HIPAA & directivas administrativas | Dash Solutions (dashsdk.com) (Accessed: 18/10/2023).

• 45 CFR § 164.304 - Definiciones. | Código electrónico de regulaciones federales (e-CFR) | Ley de EE. UU. | LII

• / Instituto de Información Legal (cornell.edu) (Acceso: 18/10/2023).

• ¿Qué es el cumplimiento de HIPAA? Leyes hipaa & reglas | Proofpoint UK (Acceso: 18/10/2023).

• Reglas, reglamentos y estándares de seguridad hipaa (training-hipaa.net) (acceso: 18/10/2023).

• Resumen de la regla de seguridad hipaa | HHS.gov (accedido: 18/10/2023).

• SP 800-66 Rev. 1, An Introductory Resource Guide for Implementing the Health InsurancePortability and Accountability Act (HIPAA) Security Rule | CSRC (nist.gov) (acceso: 18/10/2023).

• La regla de seguridad | HHS.gov (a la que se accede: 18/10/2023).

• https://www.hipaajournal.com/hipaa-encryption-requirements (Acceso: 19/10/2023).

• https://www.hipaajournal.com/hipaa-privacy-rule/ (Acceso: 19/10/2023).

• https://www.hhs.gov/hipaa/for-professionals/security/laws-regulations/index.html (Acceso: 19/10/2023).

• https://www.tausight.com/the-ultimate-guide-to-electronic-protected-health-information- ephi/ (Accedido: 19/10/2023).

• Configurar cifrado : manual de MongoDB (accesible: 19/10/2023).

• https://its.ucsc.edu/policies/docs/hipaa-risk-analysis.doc (Acceso: 19/10/2023).

• Prevención de pérdida de datos de Microsoft Purview: Anuncio de la disponibilidad general de varias funcionalidades

• Microsoft Community Hub (accesible: 10/24/2023).

• 45 CFR § 164.308 - Medidas de seguridad administrativas. | Código electrónico de regulaciones federales (e-CFR)

• | Ley de EE. UU. | LII /Legal Information Institute> (cornell.edu) (Acceso: 24/10/2023).

• ¿Cuándo debemos proporcionar información de privacidad? | ICO (Acceso: 11/08/2023).

• ¿Cómo debemos redactar nuestra información de privacidad? | ICO (Acceso: 11/08/2023).

• Marco de responsabilidad | ICO (a la que se accede: 11/08/2023).

• Requisito 5.1 de LA ISO 27001: Compromiso de liderazgo & | ISMS.online (acceso: 08/11/2023).

• Plataforma de navegación en línea (OBP) (iso.org) (a la que se accede: 11/08/2023).

• Cláusula 5.3 Roles organizativos, responsabilidades y autoridades - Formación iso (a la que se accede: 08/11/2023).

• 5.3 Roles, Responsabilidad y Autoridad (iso9001help.co.uk) (Acceso: 08/11/2023).

• Desidentificación y reidentificación de PII en conjuntos de datos a gran escala mediante la protección de datos confidenciales| Centro de arquitectura en la nube | Google Cloud (a la que se accede: 11/08/2023).

• Desidentición de datos confidenciales | Documentación de protección de datos confidenciales | Google Cloud (a la que se accede: 11/08/2023).

• Guía de seguridad de datos | ICO (a la que se accede: 11/08/2023).

• Transferencias de datos internacionales | ICO (a la que se accede: 11/08/2023).

• Administración y seguridad de registros | ICO (a la que se accede: 11/08/2023).

• ISO 27701 - Administración de la información de privacidad (a la que se accede: 08/11/2023).

• Iso 27701 Privacy Information Management System (PIMS) | ISMS.Online (accessed: 08/11/2023).

Imágenes o texto tomados de documentos de Microsoft

• https://www.sans.org/information-security-policy/ (Acceso: 18/02/21).

• Obtenga análisis de comportamiento y detección de anomalías (accessed:03/05/24).

• ¿Qué son las alertas de Azure Monitor? (A la que se accede:03/05/24).

• Obtención de análisis de comportamiento y detección de anomalías

• (A la que se accede:03/05/24).

• Administrar y responder a alertas de seguridad en Microsoft Defender for Cloud (accessed:03/05/24).

• Administrar y responder a alertas de seguridad en Microsoft Defender for Cloud (accessed:03/05/24).

• https://microsoft.github.io/AzureTipsAndTricks/blog/tip272.html (Acceso: 10/09/23).

• ¿Qué es Azure Information Protection?

• Cifrado de datos transparente para SQL Database, SQL Managed Instance y Azure Synapse Analytics (accessed:03/05/24).

• Inicio rápido: Creación de una asignación de directiva para identificar recursos no compatibles (Accessed:03/05/24).

• Configure Advanced Threat Protection para Azure SQL Database (accessed:03/05/24).

• Copia de seguridad y restauración en Azure Database for MySQL: servidor flexible (accesible:03/05/24).

• Inventario de certificados (accedido:03/05/24).

• Copia de seguridad y restauración en Azure Database for MySQL (accessed:03/05/24).

• https://github.com/microsoft/presidio/blob/main/docs/samples/deployments/data- factory/presidio-data-factory-template-gallery-http.md (accessed: 08/11/2023).

Más información

• Guía de pruebas de ejemplo: información general
• Guía de pruebas de ejemplo: Operaciones