Delegación y aplicaciones de terceros

5 tareas · 38 min · Principiante

Un cliente con delegación en todo el dominio puede acceder a los datos de todos los usuarios sin que cada uno lo apruebe, y lo hace con la llave de una cuenta de servicio. Es una herramienta legítima de migraciones y automatizaciones, y también el permiso que más tiempo se queda olvidado. En la Hilandería Cañaverales tienes la lista de clientes autorizados, el registro que los autorizó y la actividad de tokens de un par de noches. Aprendes a leer qué puede cada cliente, quién lo autorizó, cuánto datos se llevó y qué hacer con uno sin dueño, sin romper lo que depende de él.

0 de 5 · 0%

Objetivo de la sala

Una aplicación de terceros normal pide consentimiento a cada usuario y solo ve los datos de quien lo da. La delegación en todo el dominio funciona distinto: la configura un superadministrador una vez, con el identificador del cliente y sus alcances, y desde ese momento el cliente puede actuar sobre los datos de todos los usuarios del dominio sin pantalla de consentimiento. Por eso los alcances se piden lo más estrechos posibles y se revisan con regularidad.

Responde para continuar

¿Qué hace que un cliente con delegación en todo el dominio sea más delicado que una aplicación con consentimiento individual?

Pide al usuario cada vez que accede, de modo que el registro se llena de consentimientos que nadie lee Accede a los datos de todos los usuarios del dominio sin que cada uno lo apruebe, con los alcances dados Solo funciona mientras la persona que lo autorizó mantiene una sesión abierta en la consola de administración

delegacion_en_todo_el_dominio lista los clientes como los ve la consola: nombre, identificador, alcances, quién y cuándo los autorizó, y su dueño actual. El riesgo de un cliente depende de sus alcances y del dueño: un alcance estrecho con dueño es lo esperable; varios alcances amplios sin dueño, no.

Responde para continuar

Escribe el nombre del cliente con más alcances y sin dueño.

Ver pista de ayuda

Compara la columna `alcances` y la de `dueno_actual` de los tres clientes.

El evento AUTHORIZE_API_CLIENT_ACCESS del registro de administración trae el nombre del cliente (API_CLIENT_NAME) y los alcances (API_SCOPES), junto con quién lo hizo y desde dónde. Es el primer sitio al que ir para saber a quién preguntar por un cliente sin dueño.

Responde para continuar

Escribe la identidad que autorizó a ese cliente.

Ver pista de ayuda

Busca la fila de `registro_de_administracion` con el nombre del cliente anterior y copia la columna `actor`.

El evento de tokens activity guarda la aplicación (app_name), la API (api_name) y los bytes devueltos (num_response_bytes). Sumar los bytes que devolvió el cliente en una madrugada dice el volumen de datos al que accedió con la delegación, aunque no diga qué contenían.

Responde para continuar

Escribe la suma de bytes devueltos a ese cliente el 9 de septiembre.

Ver pista de ayuda

Filtra `uso_de_la_api` por el cliente y por la fecha `09-sep`; suma `num_response_bytes`.

Ya sabes quién es, quién lo autorizó, qué alcances tiene y cuánto devolvió. No sabes si algo todavía depende de él. Borrar un cliente de la delegación rompe de inmediato lo que dependa de él, y mantenerlo sin revisión deja el permiso abierto.

Responde para continuar

¿Qué recomendación se sostiene con estos datos?

Borrarlo hoy mismo de la consola, porque un cliente sin dueño no debe seguir autorizado ni un día más en el dominio Dejarlo como está, porque no hay registros de que haya hecho nada fuera de sus alcances Buscar quién lo usa, reducir sus alcances a los necesarios y retirarlo al confirmar que nada depende de él

Inicia sesión para registrar tus puntos y progreso en el ranking.

Entrar · Registrarse

1 Qué hace distinta a la delegación

2 El cliente que puede más Lab

3 Quién lo autorizó Lab

4 Cuánto se llevó Lab

5 Qué se recomienda

Whoami-Labs Pro utiliza cookies