Cómo auditar aplicaciones OAuth de terceros en Google Workspace

Pregunte a la mayoría de los administradores de TI cuántas aplicaciones de terceros tienen acceso a los datos de su Google Workspace y obtendrá una estimación, no una cifra exacta. Esa incertidumbre es el problema. Cada vez que un usuario hace clic en "Iniciar sesión con Google" o instala un complemento de Marketplace, otorga a una aplicación OAuth una porción duradera de acceso a los datos de la organización, y esa concesión sobrevive al interés del usuario, a la relevancia del proveedor y, con frecuencia, al conocimiento del administrador.

Este artículo es un método práctico para auditar esas concesiones: dónde encontrarlas, cómo determinar cuáles son riesgosas y cómo depurarlas de forma segura.

Qué es realmente una concesión OAuth

Cuando un usuario autoriza una aplicación "con Google", no está entregando su contraseña. Está otorgando a la aplicación un token con permisos específicos —*scopes*— que le permiten llamar a las API de Google en nombre del usuario (o de la organización). Un scope puede ser tan limitado como "ver su dirección de correo electrónico" o tan amplio como "ver, editar, crear y eliminar todos sus archivos de Google Drive".

Dos propiedades hacen que estas concesiones merezcan una auditoría:

• Persisten. Un token sigue funcionando hasta que se revoca explícitamente, se elimina la aplicación o se deshabilita la cuenta. "Dejé de usar esa herramienta hace un año" no revoca nada.
• Las inicia el usuario. El acceso lo concede la persona que hizo clic en "Permitir", no lo aprovisiona TI. Esa es la definición de manual de shadow IT, y significa que su inventario de accesos está incompleto por defecto.

Dónde encontrar el inventario

Hay dos puntos de vista.

La vista del usuario se encuentra en la Cuenta de Google de cada persona, en *Seguridad → Aplicaciones y servicios de terceros* (anteriormente "Aplicaciones con acceso a tu cuenta"). Muestra lo que un usuario en particular ha autorizado. Útil para verificaciones puntuales, poco práctico a escala.

La vista del administrador se encuentra en la consola de administración de Google, en *Seguridad → Controles de API → Control de acceso de aplicaciones* (junto con los informes de aplicaciones conectadas). Esta es la imagen a nivel organizacional: qué aplicaciones están conectadas, qué scopes tienen y cuántos usuarios autorizaron cada una. Para una auditoría, aquí es donde se trabaja.

Si cuenta con los privilegios de administrador adecuados, los informes de tokens del Admin SDK pueden enumerar los mismos datos de forma programática, lo que hace posible una revisión continua y automatizada en lugar de una tarea manual anual y tediosa.

Cómo evaluar el riesgo

No toda aplicación conectada es un problema. Una herramienta de programación de calendario que puede leer horarios libres/ocupados representa un riesgo bajo; una aplicación de notas con acceso completo a Drive utilizada por una sola persona es otra historia. Puntúe cada aplicación según algunas dimensiones:

• Amplitud del scope. El acceso completo a Drive, la lectura/envío de Gmail y el acceso al directorio de administración son los scopes de mayor riesgo. Una aplicación que puede leer y exfiltrar cada archivo es su máxima prioridad, sin importar cuán confiable parezca.
• Sensibilidad de lo que puede alcanzar. El acceso al contenido de Drive y al buzón de correo supera en importancia a los metadatos de perfil o calendario.
• Cantidad y alcance de usuarios. Una aplicación que usa una sola persona pero que tiene un acceso amplio es un riesgo silencioso y concentrado. Una aplicación que usa toda la empresa merece escrutinio porque su radio de impacto es grande.
• Confianza en el editor. Los editores verificados y los proveedores conocidos son apuestas más seguras que las aplicaciones no verificadas o anónimas. El estado de verificación de aplicaciones de Google es una señal útil, no una garantía.
• Actividad. Una aplicación que nadie ha usado en meses es pura desventaja: todo el riesgo, ningún valor.

Una forma sencilla de combinar estos factores: cualquier aplicación con un scope de alto riesgo *y* baja confianza *o* sin uso reciente pasa al primer lugar de la lista de depuración.

Una auditoría repetible, paso a paso

1. Enumerar. Extraiga la lista completa de aplicaciones conectadas y sus scopes desde la consola de administración (o mediante la API).
2. Clasificar los scopes. Marque los peligrosos: Drive completo, envío/lectura de Gmail, directorio y cualquier scope de administración.
3. Cruzar con el uso. Identifique aplicaciones sin actividad reciente y aplicaciones que tienen muy pocos usuarios.
4. Verificar el editor. Anote los editores no verificados o desconocidos.
5. Decidir. Para cada aplicación: mantener, restringir o revocar. Documente el motivo: el registro de decisiones es lo que agiliza la próxima auditoría.
6. Revocar de forma segura. Elimine el acceso de las aplicaciones que decidió retirar y comuníquese con el puñado de usuarios que dependían de una herramienta que está eliminando.
7. Establecer barreras de protección. Pase de la depuración a la prevención: restrinja las instalaciones de Marketplace a aplicaciones aprobadas por el administrador y bloquee o incluya en listas de permitidos el acceso a scopes de alto riesgo para que la proliferación no vuelva a crecer.

Revocar sin romper nada

El temor que detiene la mayoría de las depuraciones es "¿y si revoco algo que la gente necesita?". Para mitigarlo:

• Comience por las victorias inequívocas: aplicaciones no verificadas con scopes amplios y sin uso reciente.
• Para aplicaciones con una base de usuarios pequeña, envíe un aviso previo antes de revocar; si nadie objeta, proceda.
• Mantenga un registro de qué revocó y cuándo, de modo que, si algo se rompe, pueda restaurarlo rápida y deliberadamente.

La revocación en las herramientas de Google es inmediata y reversible: un usuario siempre puede volver a autorizar una aplicación que realmente necesite, esta vez con sus barreras de protección implementadas.

Hágalo continuo

Una auditoría única se siente genial y se degrada de inmediato. Al día siguiente de terminarla se conectan nuevas aplicaciones. La respuesta duradera es el descubrimiento continuo: enumerar automáticamente las aplicaciones conectadas y sus scopes, puntuar cada una y alertar cuando aparezca una nueva concesión de alto riesgo o una aplicación inactiva mantenga un acceso amplio.

Ese cambio —de una hoja de cálculo periódica a un inventario siempre actualizado— es la diferencia entre conocer su exposición OAuth hoy y solo suponerla. También es uno de los pilares de la seguridad más amplia de Google Workspace, junto con la identidad, el uso compartido y la configuración.

Los scopes que deberían hacerle detenerse

Dado que la amplitud del scope es el factor de riesgo más determinante, conviene saber qué scopes de OAuth tienen un peso real. Algunos patrones que vale la pena reconocer al leer la lista de permisos de una aplicación:

• `drive` (Drive completo) — leer, crear, modificar y eliminar *todos* los archivos de Drive de un usuario. Este es el scope de datos más amplio que puede tener una aplicación, y es mucho más común de lo que debería; muchas aplicaciones lo solicitan cuando bastaría un scope más limitado por archivo.
• `gmail.send` / `gmail.modify` / `mail.google.com` — la capacidad de enviar correo como el usuario, o leer y modificar el buzón. Una aplicación con acceso al buzón puede tanto exfiltrar correspondencia como suplantar al usuario ante terceros.
• **admin.directory.*** — leer o gestionar su directorio de usuarios y grupos. Una aplicación con este scope alcanza a toda la organización, no solo a un usuario.
• `spreadsheets` / `documents` — acceso al contenido de Sheets y Docs, que con frecuencia contiene precisamente los datos sensibles (datos financieros, planes, credenciales pegadas "temporalmente") que más desea proteger.

Los scopes limitados y de solo lectura —userinfo.email, calendar.readonly, drive.file (acceso solo a los archivos que la propia aplicación creó)— son los que se deben fomentar. Al evaluar una nueva herramienta, prefiera la versión que solicite lo mínimo.

Convertir la auditoría en una política

Una auditoría bien hecha vale mucho más si termina en una política permanente en lugar de una purga puntual. Tres políticas evitan que la mayor parte de la proliferación vuelva a crecer:

• Instalaciones de Marketplace aprobadas por el administrador. Exija la aprobación del administrador antes de que los usuarios puedan instalar aplicaciones de Marketplace, de modo que las nuevas conexiones sean una decisión y no algo predeterminado.
• Control de acceso basado en scopes. Bloquee o incluya explícitamente en listas de permitidos los scopes de alto riesgo (Drive completo, Gmail, directorio). Una aplicación que quiere acceso completo a Drive debería superar un umbral; una aplicación que solo quiere una dirección de correo no debería tener que hacerlo.
• Un responsable de revisión recurrente. Asigne a alguien la tarea permanente de revisar las concesiones nuevas y de alto riesgo con una periodicidad definida. Las revisiones sin responsable no se llevan a cabo.

Estas barreras de protección cambian el valor predeterminado de "cualquier usuario puede conceder a cualquier aplicación cualquier acceso" a "el acceso amplio es una decisión deliberada y revisada", sin bloquear las herramientas legítimas que las personas realmente necesitan.

8200.dev descubre las aplicaciones de terceros conectadas a su Workspace, las puntúa según el scope, la confianza en el editor y el uso, y muestra primero las riesgosas, de forma continua y solo de lectura. Consulte lo que verificamos para conocer el panorama completo.

¿Quiere ver qué aplicaciones pueden acceder a sus datos ahora mismo? Inicie su auditoría de seguridad gratuita y obtenga un inventario de las aplicaciones OAuth conectadas, clasificadas por riesgo, en todo su Google Workspace.