Cómo revisar el acceso de una aplicación SaaS a los datos del negocio

Empieza por una tarea y un dueño

Escribe para qué sirve la conexión, qué departamento la necesita y quién aprueba el acceso a los datos. Recoge identificador de aplicación, proveedor y tenant para no revisar otra integración de nombre parecido. Pide el flujo real: datos que lee, información que guarda, acciones que modifica y salidas hacia terceros. Si nadie puede justificar una capacidad, trátala como pendiente de autorización, aunque se concediera al instalar.

Lee los permisos efectivos

Contrasta lo solicitado con lo concedido y con los límites adicionales del recurso. En Microsoft Graph, el acceso delegado actúa en nombre de un usuario y el acceso de aplicación usa identidad propia sin usuario conectado. No interpretes ambos del mismo modo. Comprueba también grupos, roles y restricciones compatibles. Evita concluir que una cuenta de prueba sin privilegios demuestra el alcance de una credencial de aplicación diferente.

Prueba lectura y acción por separado

Con datos sintéticos, comprueba un recurso permitido y otro que deba quedar excluido. Después revisa cada capacidad de escritura, borrado o envío que figure en el consentimiento. En Graph, leer correo y enviar correo corresponden a permisos distintos; la lectura no otorga por sí sola autoridad de envío. Aunque el permiso exista, cada acción empresarial debe estar autorizada por la organización. No pruebes envíos reales a clientes para descubrir el alcance.

Deja preparada la retirada

Documenta quién revoca consentimiento o credenciales, qué integraciones dependen de ellas y qué datos retiene el SaaS tras desconectarlo. Revocar acceso futuro no borra automáticamente copias ya obtenidas. Programa una revisión tras cambios de función, propietario o permisos. Si falta evidencia del alcance, reduce la conexión o pausa las operaciones afectadas mediante el procedimiento aprobado. Conserva el resultado de las pruebas y el acuerdo de negocio junto a la ficha de aplicación.

Ejemplo: una integración que clasifica correo

Imagina una aplicación que etiqueta mensajes de una cuenta de prueba para preparar tareas internas. El dueño autoriza consultar mensajes y aplicar etiquetas, pero no enviar respuestas. La revisión debe comprobar si el conector tiene permiso de envío, si lo necesita y cómo retirarlo sin romper la función aprobada. Si el proveedor afirma que nunca lo utiliza, pide evidencia de la configuración efectiva: una restricción escrita en instrucciones no cambia necesariamente las capacidades de la credencial. Después prueba el acceso a otro buzón que deba quedar fuera, con autorización y sin extraer contenido. Guarda una conclusión por capacidad. La empresa puede aprobar una lectura limitada y rechazar el envío, aunque ambas funciones aparezcan agrupadas en la presentación comercial del SaaS.

Fuentes y documentación

• Microsoft · Graph permissions overview — Distingue acceso delegado y acceso con identidad propia de aplicación.
• Microsoft · Graph permissions reference — Mail.Read y Mail.Send son permisos distintos; comprobar tipo y alcance reales.