Shadow IT: convierta el descubrimiento en responsabilidades asignadas

Un equipo adopta una herramienta porque resuelve un problema real. El problema de seguridad empieza cuando el inventario, los contratos y los procesos de acceso de la organización no reflejan ese uso. Una aplicación puede volverse esencial para un proceso de negocio antes de que nadie haya decidido quién la administra, qué datos puede contener o cómo retirarla.

La shadow IT, o TI en la sombra, incluye servicios, aplicaciones y dispositivos que se utilizan al margen de los procesos establecidos de aprobación o gestión. El descubrimiento debe conducir a una decisión proporcionada y a un responsable designado, no simplemente a una lista más larga de dominios sospechosos.

Para un CTO, el objetivo es operativo: comprender la dependencia, contener la exposición inaceptable y ofrecer al negocio una vía practicable hacia una tecnología gestionada.

Defina el perímetro antes de recopilar señales

La shadow IT es una situación de gestión, no una categoría de productos intrínsecamente inseguros. Un servicio de colaboración reputado puede quedar sin gestionar cuando los empleados crean espacios de trabajo personales. Un portátil personal puede ser legítimo en el marco de un régimen controlado de uso de dispositivos propios. A la inversa, un servicio contratado puede quedar fuera de una gestión eficaz si nadie controla sus administradores ni las bajas.

Mire más allá de los nombres de software desconocidos. Entre los ejemplos pertinentes figuran:

• Almacenamiento personal en la nube, cuentas de mensajería y gestores de contraseñas utilizados para información de la empresa.
• Extensiones del navegador, asistentes de reuniones con IA y servicios de transcripción con acceso a contenido corporativo.
• Aplicaciones de terceros conectadas al correo electrónico, los calendarios, los repositorios o el almacenamiento de archivos mediante OAuth.
• Portátiles no gestionados, almacenamiento extraíble, dispositivos de red y utilidades de acceso remoto.
• Cuentas en la nube propiedad de un equipo, aplicaciones low-code y scripts de automatización que dan soporte a flujos de trabajo de producción.

Las aplicaciones aprobadas también pueden dar lugar a usos no gestionados. Una nueva integración, un ajuste de uso compartido público o una función de IA pueden cambiar la evaluación de riesgos original sin que cambie el nombre del producto.

Empiece por un proceso de negocio o un departamento. Defina qué cuentas, dispositivos finales, redes, proveedores y flujos de datos forman parte de la primera revisión. Así, los hallazgos pueden convertirse en acciones y se ponen de manifiesto las lagunas del método antes de iniciar la recopilación en toda la organización.

Construya una imagen a partir de varias fuentes

Ninguna fuente de descubrimiento muestra por sí sola todas las herramientas. Los registros de identidad no recogen las cuentas locales; los registros de gasto no recogen los servicios gratuitos; los registros de red pueden mostrar un destino sin explicar qué información se envió allí.

Utilice fuentes complementarias y conserve la procedencia de cada hallazgo.

Explique por qué se realiza el descubrimiento, qué se recopilará, quién puede consultarlo y durante cuánto tiempo se conservará. Respete las normas de privacidad y laborales aplicables. Es preferible obtener metadatos suficientes para identificar el servicio y su acceso que recopilar el contenido de los mensajes, grabaciones o la navegación personal. Restrinja el acceso a los propios registros de descubrimiento.

Haga preguntas prácticas a los equipos: ¿dónde comparten archivos grandes, graban reuniones, traducen documentos, recogen las opiniones de los clientes o automatizan tareas repetitivas? Pregunte qué herramientas interrumpirían el trabajo si se eliminaran mañana. Estas preguntas revelan dependencias que una lista de dominios no puede mostrar.

Normalice los hallazgos antes de contarlos. Un proveedor puede tener varios dominios, productos, espacios de trabajo y entidades de facturación. Separe la identidad del producto de la identidad del tenant, y distinga entre las evidencias de instalación, autorización, inicio de sesión y uso de negocio confirmado. Registre los hallazgos inciertos como candidatos en lugar de declarar cada destino observado como una aplicación no autorizada.

Convierta cada hallazgo en un registro de responsabilidad

Un registro útil describe el uso, no solo el proveedor. Dos equipos que utilizan el mismo producto pueden tener datos, accesos, contratos y consecuencias distintos.

Para cada uso confirmado, recoja:

• El producto, el proveedor, el identificador del tenant o del espacio de trabajo y la fuente del descubrimiento.
• La finalidad de negocio, el proceso dependiente, la población de usuarios y la criticidad.
• Las categorías de datos, las fuentes de datos, los destinos, los ajustes de uso compartido y la conservación.
• Los tipos de cuenta, los administradores, la autenticación, las integraciones y los permisos concedidos.
• El titular del contrato, el plan de suscripción, los datos de renovación y los acuerdos de tratamiento pertinentes.
• El responsable de negocio, el custodio técnico, el revisor, el tratamiento propuesto y la fecha de revisión.

El responsable de negocio justifica la necesidad y coordina el uso aceptable. El custodio técnico gestiona la configuración, los accesos, las integraciones y la retirada. Seguridad evalúa el riesgo; los especialistas de compras y privacidad revisan los asuntos de su competencia. En una organización pequeña, estas responsabilidades pueden recaer en la misma persona, pero deben seguir siendo explícitas.

Si nadie va a responsabilizarse de un servicio, no lo clasifique como aprobado solo porque a los usuarios les guste. Asigne un patrocinador provisional que responda de él y un plazo para decidir. Registre lo que sigue sin conocerse y quién lo resolverá.

Siga los datos, no solo la aplicación. Una herramienta puede recibir archivos subidos, sincronizar carpetas enteras, crear transcripciones o enviar contenido a otro proveedor. Nuestra guía de descubrimiento de datos explica cómo trazar esas relaciones.

Examine los accesos OAuth por separado del uso de la aplicación

OAuth permite que una aplicación obtenga un acceso autorizado sin recibir la contraseña del usuario. Es útil, pero la autorización puede ser más amplia o más duradera de lo que requiere la tarea. Iniciar sesión en una aplicación y concederle acceso a recursos corporativos son eventos distintos.

Para cada aplicación conectada, examine, cuando esté disponible, la identidad del editor o del cliente, el usuario que concedió el acceso, el recurso, los ámbitos (scopes), el tipo de consentimiento y la fecha de concesión. Distinga el acceso delegado que se ejerce en nombre de un usuario de los permisos de aplicación que pueden operar sin un usuario interactivo. Examine el comportamiento de los tokens de actualización y si la autorización puede mantenerse después de que el usuario deje de utilizar activamente la herramienta.

Priorice las concesiones que permitan leer buzones de correo, modificar archivos, acceder al directorio, introducir cambios en repositorios o acceder de forma amplia a los datos de varios usuarios. Compruebe si los ámbitos solicitados se corresponden con la finalidad declarada. Una utilidad de planificación que solicita acceso al calendario plantea una cuestión distinta de una que solicita el contenido del buzón y acceso sin restricciones a los archivos.

Como control práctico, restrinja el consentimiento de alto impacto a los administradores o a un flujo de revisión cuando la plataforma lo permita. Revise los permisos recién concedidos y los cambios en las aplicaciones existentes, no solo los nuevos registros de aplicaciones.

Eliminar una extensión del navegador o desconectar una integración visible para el usuario puede no eliminar todas las concesiones, todos los tokens ni todas las copias externas de los datos. Verifique la revocación en la plataforma del recurso y en la cuenta del proveedor. El transporte cifrado no demuestra que una integración sea segura, ni hace imposible cualquier inspección; la visibilidad depende de los controles y la telemetría disponibles.

Priorice según la exposición y la dependencia del negocio

Utilice la clasificación inicial para decidir qué requiere atención primero. Evite tratar todas las herramientas no aprobadas como igual de urgentes.

Evalúe la sensibilidad y el volumen de la información implicada, la amplitud del acceso, el uso compartido externo, el estado de seguridad de los dispositivos, el control administrativo y los indicios de compromiso. Tenga en cuenta también la disponibilidad: una automatización no documentada podría ser la única vía para enviar pedidos a un proveedor.

Una herramienta pública de referencia de diseño utilizada sin subir archivos puede requerir solo un registro sencillo. Un asistente de reuniones con IA con acceso al calendario, grabaciones y conversaciones con clientes necesita una revisión más profunda de los permisos, el almacenamiento, la conservación y el tratamiento posterior. Un servicio de acceso remoto no gestionado en un sistema de producción justifica una contención y una investigación inmediatas.

Registre un escenario de riesgo concreto, no un «riesgo de shadow IT». Por ejemplo: «Un antiguo empleado conserva la administración del espacio de trabajo y puede exportar propuestas a clientes». Esa afirmación apunta hacia un responsable, un cambio en los controles y una prueba.

El descubrimiento no es automáticamente una prueba de una brecha de seguridad. Si los hallazgos indican una divulgación no autorizada o un compromiso, pase al proceso de incidentes conservando los registros pertinentes. Cuando haya datos personales implicados, la evaluación de la notificación depende de las circunstancias y del papel de la organización conforme a los artículos 33 y 34 del RGPD, no simplemente de si la herramienta estaba aprobada.

Elija un tratamiento que preserve la necesidad del negocio

Cada decisión necesita un responsable, una justificación, unos criterios de finalización y un seguimiento. En la práctica, cuatro tratamientos resultan útiles.

Aprobar e incorporar a la gestión

La aprobación debe describir el uso permitido, no conceder un permiso ilimitado para el producto. Establezca una administración controlada por la empresa, una autenticación adecuada, accesos con mínimo privilegio, la gestión de altas, cambios y bajas, y una configuración con soporte. Compruebe los registros, las restricciones de uso compartido, las opciones de recuperación o exportación y la conservación en relación con el caso de uso.

Revise el proveedor y el contrato cuando proceda. Si el proveedor trata datos personales por cuenta de la organización, evalúe los acuerdos de encargo del tratamiento exigidos por el artículo 28 del RGPD. Los mecanismos de transferencia internacional requieren una evaluación independiente; elegir una región de alojamiento no resuelve todas las cuestiones. Las medidas de seguridad del artículo 32 se basan en el riesgo, no son una lista de comprobación universal que se cumpla con un solo ajuste.

Conserve las evidencias de la aprobación: exportaciones de configuración, asignaciones de administradores, pruebas de acceso, revisión contractual y el riesgo residual aceptado.

Sustituir por una alternativa adecuada

La sustitución solo funciona si la alternativa satisface la necesidad real. Pruebe los límites de tamaño de archivo, la colaboración externa, la accesibilidad, la automatización y las integraciones necesarias antes de imponer la migración.

Defina la secuencia de migración, concilie los registros y confirme que los usuarios pueden completar el flujo de trabajo. Conserve los registros exigidos y los metadatos pertinentes. Compruebe los enlaces compartidos y las integraciones después del cambio y cierre después el tenant antiguo, en lugar de limitarse a dejar de pagarlo.

Eliminar el uso injustificado

Para una herramienta sin una finalidad defendible o con una exposición inaceptable, detenga los nuevos usos y planifique su eliminación. Revoque las concesiones y los tokens, elimine las extensiones o el software, desactive las cuentas, cierre los enlaces compartidos y aborde los datos ya exportados. Rote las credenciales expuestas cuando los hallazgos lo justifiquen.

Eliminar una cuenta no demuestra que haya desaparecido toda la información en poder del proveedor. Obtenga las evidencias de eliminación disponibles y documente la conservación contractual, las copias de seguridad u otras limitaciones. Conserve la información sujeta a obligaciones de conservación o a retenciones por motivos legales.

Permitir una excepción temporal y controlada

Una herramienta crítica para el negocio puede necesitar un periodo de transición. Especifique los usuarios y los datos permitidos, los controles compensatorios, la persona que acepta y responde del riesgo, la caducidad y las condiciones de salida. Restrinja en lo posible la ampliación del uso. Una excepción «temporal» permanente sin revisión es una brecha de gestión sin resolver.

Ejemplo práctico: un asistente de reuniones con IA

Considere, a título ilustrativo, una organización que revisa su proceso comercial. Supongamos que ocho empleados utilizan un asistente de reuniones gratuito mediante cuentas individuales. Las entrevistas confirman que graba las llamadas con clientes; una exportación del sistema de identidades muestra concesiones de acceso al calendario. No existe ningún registro de compra, y un responsable comercial se apoya en las transcripciones para los traspasos.

La primera decisión es suspender nuevas grabaciones y nuevos usuarios mientras se determina qué se ha capturado. Seguridad registra las concesiones y las identidades de las cuentas. El responsable identifica las reuniones afectadas y la necesidad operativa. Privacidad y compras revisan los acuerdos de tratamiento, la información a los participantes, las condiciones del proveedor, la conservación y los mecanismos de transferencia pertinentes. El equipo comprueba también si las grabaciones o las transcripciones son accesibles públicamente y si el servicio utiliza el contenido para otras finalidades.

Supongamos que la revisión concluye que el plan gratuito no permite una administración controlada por la empresa ni los ajustes de conservación exigidos. La decisión es la sustitución, no el abandono del proceso de traspaso. El equipo comercial prueba una alternativa aprobada con controles adecuados de acceso y grabación, mientras el custodio técnico revoca las antiguas concesiones de acceso al calendario y migra los registros permitidos.

Las evidencias de cierre incluyen la lista de cuentas afectadas, la configuración de la herramienta sustituta, los resultados de la revocación de concesiones, las comprobaciones de los antiguos enlaces compartidos y las confirmaciones de eliminación disponibles. Cualquier limitación sin resolver relativa a la conservación en copias de seguridad sigue registrada. El responsable comercial responde del uso aceptable; TI, de la configuración y las bajas. La revisión termina con un proceso gestionado, no simplemente con una aplicación bloqueada.

Evite el próximo punto ciego con un proceso de solicitud utilizable

Los equipos suelen adoptar herramientas para sortear aprobaciones lentas, funciones que faltan o fricciones en los sistemas existentes. El descubrimiento debe identificar esas causas. De lo contrario, la eliminación simplemente desplaza la misma actividad a un lugar menos visible.

Facilite la presentación de solicitudes. Pregunte por la finalidad, los usuarios, las categorías de datos, las integraciones, la urgencia y un responsable de negocio. Publique los criterios que desencadenan una revisión más profunda y ofrezca una vía práctica para las pruebas de bajo riesgo. Informe a los solicitantes del estado y del momento previsto para la decisión; no deje las solicitudes en una cola sin explicación.

Enseñe comportamientos concretos: preguntar antes de conectar un servicio al correo corporativo, no subir información de clientes a una herramienta sin revisar y comunicar la existencia de un espacio de trabajo antes de renovarlo. Ofrezca a los equipos una vía de comunicación orientada a corregir las brechas, no a sancionar a quien informa de buena fe.

Siga vigilando los cambios después de la aprobación. Revise las nuevas concesiones OAuth, los cambios administrativos, el uso compartido externo, las funciones de IA recién activadas y la ampliación a datos más sensibles. Como recomendación práctica, combine comprobaciones basadas en eventos con confirmaciones periódicas de los responsables. La frecuencia de revisión debe reflejar la exposición y la criticidad para el negocio, no un intervalo universal.

Haga que las evidencias sean útiles para el SGSI

ISO/IEC 27001 se refiere a un sistema de gestión de la seguridad de la información con un alcance definido. Los hallazgos de shadow IT pueden alimentar la gestión de activos, la revisión de proveedores, los controles de acceso, la evaluación de riesgos y su tratamiento. La selección de controles sigue basándose en el riesgo; una lista de aplicaciones no es un SGSI ni demuestra que los controles funcionen.

Mantenga diferenciados el alcance del descubrimiento, la evaluación, la decisión de tratamiento, las evidencias de implantación y la comprobación de la eficacia. Un ticket cerrado con la indicación «eliminado» es una evidencia más débil que un acceso revocado junto con un resultado probado. La aceptación del riesgo debe identificar quién tenía autoridad para aceptarlo y cuándo debe revisarse. La certificación no acredita por sí misma el cumplimiento del RGPD.

Secani ofrece un espacio de trabajo conectado para modelar sistemas y servicios, relacionar las evidencias con los requisitos y las decisiones, y asignar responsables y tareas de revisión. Mantenga el descubrimiento y la aplicación de medidas en los sistemas operativos adecuados y lleve después las exportaciones, revisiones y aprobaciones pertinentes a ese contexto de cumplimiento. Trate las sugerencias asistidas por IA como borradores que requieren revisión humana, preservando la trazabilidad de las fuentes.

Para la próxima revisión, elija un proceso de negocio y concilie sus hallazgos de identidad, gasto, dispositivos finales y entrevistas. Cierre cada hallazgo confirmado con un responsable designado, un tratamiento, un plazo y una prueba de cierre. Entre los indicadores útiles figuran la cobertura de responsables, las decisiones vencidas, las excepciones próximas a caducar y las comprobaciones de retirada de accesos completadas, no solo el número de herramientas descubiertas.