Header Ads Widget

Ticker

6/recent/ticker-posts

Cree API compatibles con GDPR con OpenID Connect

 


GDPR , el Reglamento general de protección de datos de la Unión Europea, entró en vigor en marzo de 2018. Este nuevo reglamento establece las expectativas de privacidad y seguridad para el manejo de los datos de los usuarios y se aplica a todos los actores relacionados de manera uniforme y tangencial con el mercado europeo.

Como practicante de API, es absolutamente esencial que comprenda cómo crear productos que cumplan con GDPR. ¿Quién mejor para guiarte a través de los aspectos esenciales que el CEO de Curity y fundador de las API nórdicas, Travis Spencer ?

Según Travis, estas tres implementaciones , incluido el uso del consentimiento interactivo del usuario, identificadores seudónimos por pares y tokens fantasmas, son esenciales no solo para quienes presionan para cumplir con la regulación, sino también para aquellos que no están necesariamente sujetos a GDPR y, sin embargo, valoran la construcción. API seguras y privadas.

Este artículo se basa en la sesión "API que cumplen con el RGPD con OpenID Connect", que impartió Travis en nuestra Cumbre de plataformas de API nórdicas de 2018.

Consentimiento del usuario interactivo

En resumen, el consentimiento del usuario es obtener la aprobación del usuario para compartir datos con alguna aplicación de terceros. Este es ese paso tan crucial cuando una aplicación ha solicitado acceso a ciertos datos, el usuario ha iniciado sesión y ahora es el momento de que el usuario dé su consentimiento directamente para compartir datos; en OAuth , esto se conoce como autorización, llama Travis. es delegación , pero lo realmente importante es que está ahí.

Este podría ser el paso más importante en el cumplimiento de GDPR, ya que la regulación establece que los usuarios no solo deben saber cómo se usan o transmiten sus datos, sino que también deben tener la opción de optar por compartir ciertos datos o rechazarlos por completo. .

La anatomía de un formulario de consentimiento

Hay información imprescindible para incluir en cada formulario de consentimiento, que es un buen lugar para comenzar a crear el suyo. Esto incluye:

  • El nombre de la aplicación cliente con la que el usuario consiente compartir sus datos y, preferiblemente, la relación de ese cliente con la organización (¿es una aplicación propia o de terceros?)
  • Algún tipo de logo o imagen que represente al cliente, para agregar una representación gráfica del cliente con quien el usuario consiente compartir sus datos
  • Una descripción de la aplicación, para que el usuario pueda comprender, en términos sencillos, el propósito de la aplicación con la que da su consentimiento para compartir sus datos.
  • Cualquier otra información relevante del cliente o usuario (por ejemplo, el nombre o ID del usuario, para asegurarse de que haya iniciado sesión con la cuenta desde la que da su consentimiento para compartir sus datos)

Consentimiento para reclamos, no alcances

Los reclamos son atributos de clientes individuales, mientras que los alcances son grupos de reclamos modelados en torno a las necesidades de las aplicaciones del cliente. En sus formularios de consentimiento, asegúrese de hacer referencia directamente a las reclamaciones de datos que el usuario está dando su consentimiento para compartir; de esta manera, queda muy claro (en inglés normal) qué datos se comparten.

Permitir deselección de reclamos

Una vez que haya presentado todos los datos que solicita la aplicación cliente, debe darles a los usuarios la opción de anular la selección de reclamaciones individuales, aquellas que representan datos que no dan su consentimiento para compartir.

En algunos casos, es posible que descubra que ciertas afirmaciones son necesarias en la funcionalidad principal de la aplicación, por lo que el usuario que no consiente estas afirmaciones podría crear una situación de todo o nada en la que el usuario no pueda usar la aplicación por completo. En estos casos, debe etiquetar las declaraciones obligatorias como tales; desde un punto de vista técnico, puede hacerlo con el claimsparámetro de solicitud en OpenID Connect.

Como ejemplo del sitio web de OpenID Connect, el código "auth_time": {"essential": true}indica que el auth_timevalor es esencial.

Mostrar más reclamaciones a pedido

Si una aplicación cliente solicita acceso a una gran cantidad de reclamos, no hay necesidad de cumplir con mezquindad: en lugar de bombardear al usuario con docenas de reclamos en una sola pantalla de consentimiento (y por lo tanto sacrificar una cierta cantidad de experiencia del usuario), simplemente presente el reclamos más importantes y brinde a los usuarios la posibilidad de abrir una lista plegable para el resto.

Una solución alternativa es simplemente solicitar el consentimiento para las reclamaciones muy básicas por adelantado y, a medida que se necesitan más reclamaciones durante el ciclo de vida de la aplicación, volver a autorizar y solicitar un consentimiento adicional más adelante.

Agregar soporte para idiomas

Como parte del RGPD, es esencial que los usuarios puedan tomar una decisión informada sobre si dar su consentimiento, según los datos que comparten. Dicho esto, debe localizar los nombres y las descripciones de las reclamaciones para asegurarse de que los usuarios puedan leer estos elementos en los idiomas que les resulten más cómodos.

Una forma de hacerlo es mediante el uso del parámetro de cadena de consulta de configuraciones regionales de la interfaz de usuario en OpenID Connect, que permite que la aplicación comunique directamente datos de idioma a OpenID para una experiencia de usuario perfecta. Otras ideas incluyen almacenar una cookie de configuración regional en el servidor OpenID o la configuración del navegador o incluir un cuadro de selección de idioma desplegable en la página de consentimiento.

Permitir que los usuarios cancelen

Una característica rápida pero muy importante para incluir en cualquier formulario de consentimiento es la opción de cancelar el proceso. Esto está ahí en caso de que el usuario decida que no le gusta el aspecto del cliente o las afirmaciones a las que solicita acceso. Desde la perspectiva de la experiencia del usuario, probablemente debería silenciar o restar importancia a esta opción, solo asegúrese de que esté allí.

Forzar el consentimiento y el reconsentimiento

En algunos casos, es posible que deba obligar al usuario a dar su consentimiento, o volver a dar su consentimiento, para usar o continuar usando la aplicación de un cliente. Un gran ejemplo de cuándo esto sería útil es si usted o el cliente que creó la aplicación deciden hacer un cambio en la política de privacidad relevante; aquí, querrá obligar a los usuarios a volver a dar su consentimiento. Puede lograr esto con OpenID Connect agregando el prompt=consentparámetro a una solicitud de autorización.

Tratamiento especial para clientes dinámicos

Los clientes que se registran de forma dinámica, es decir, que primero se registran directamente en el servidor OpenID Connect, suponen un mayor riesgo de seguridad y, por lo tanto, requieren un tratamiento especial. En el proceso de registro, es esencial validar las URL, las políticas de privacidad, los términos de servicio y más; la validación de URL, por ejemplo, evita que el cliente se haga pasar por otra persona u organización en la pantalla de consentimiento. Hablando de pantallas de consentimiento, puede mostrar el mayor riesgo de seguridad a los usuarios de esta manera. Como ejemplo, Travis sugiere usar un ícono amarillo en el formulario en lugar de uno verde,

Identificadores seudónimos por pares

La segunda sugerencia de Travis para mejorar la seguridad y privacidad de su API, y al hacerlo, cumplir con GDPR, es crear implementaciones de identidad conscientes de la privacidad mediante identificadores seudónimos por pares.

Los identificadores seudónimos por pares, también conocidos como PPID, son ID de usuario que no se pueden adivinar y que se generan aleatoriamente. Los PPID no tienen ningún vínculo con los ID proporcionados por los usuarios, lo que evita que los clientes rastreen a los usuarios y potencialmente creen un perfil más grande del cliente.

A veces, varias aplicaciones pueden necesitar acceso a los mismos datos del usuario. Si es así, es posible agrupar a los clientes en sectores en los que reciben el mismo PPID.

Es importante evitar que los clientes dinámicos accedan a otros sectores a los que intentan atacar o de los que de otro modo obtienen información privada. Durante la validación de estos clientes, puede ver una lista completa de sus URI para determinar si el sector que eligieron es aplicable.

Fichas fantasma

La sugerencia final para cumplir con el RGPD es utilizar tokens fantasmas. Los tokens fantasmas son un patrón que preserva la privacidad para la emisión y uso de tokens de acceso. La premisa básica para esto es que un proxy de API o una puerta de enlace cambiará el token de acceso de un cliente a un token separado que actúa en la red interna.

El uso de tokens fantasmas lo deja con un espacio más pequeño sujeto a la información personal de los usuarios, lo que significa menos regulaciones de las que preocuparse. Además, evita que los clientes obtengan datos que no deberían, sin importar cuánto lo intenten, a diferencia de los tokens cifrados.

Conclusiones para el cumplimiento de API GDPR

Y así lo tiene: tres simples precauciones para garantizar que su API cumpla con las reglas de información personal establecidas en el GDPR de la Unión Europea. Como menciona Travis, incluso para aquellos que no se ven afectados por la nueva regulación, estas tres implementaciones siguen siendo fantásticas medidas de privacidad y seguridad para su API.

En resumen, debes:

  • Pida a los usuarios su consentimiento explícito para compartir sus datos, explicando quién los usará y cómo (y dándoles la opción de optar por no participar).
  • Ocultar los ID de usuario con identificadores seudónimos por pares (PPID), y
  • Utilice los llamados tokens fantasmas en su red interna.

Publicar un comentario

0 Comentarios