En un artículo anterior vimos cómo funcionan los permisos en SharePoint y cómo se descontrolan — herencia rota, exceso de uso compartido, enlaces sin ninguna barrera de autenticación. Aquel artículo trataba los permisos como un problema de documentos y carpetas. Pero hay un fallo de gobernanza que se sitúa un nivel por encima, en el propio sitio, y que la higiene de permisos por sí sola no detecta: el sitio sin propietario.
Cómo un sitio se queda huérfano
Casi nunca ocurre a propósito. Alguien crea un sitio para un proyecto, o hereda la propiedad cuando un equipo se reorganiza. Pasa el tiempo. Esa persona deja la organización. Su cuenta se desaprovisiona como parte del proceso estándar de baja, pero nadie comprueba si era la única propietaria de un sitio de SharePoint.
El sitio no se rompe. No lanza ningún error. Sigue funcionando exactamente igual que antes. Los Miembros pueden seguir accediendo, seguir editando documentos, seguir compartiendo contenido con otras personas. Lo único que falta es alguien a quien se le pueda pedir cuentas, alguien que pueda aprobar solicitudes de acceso, revisar quién tiene acceso o revocar un enlace de uso compartido que nunca debería haberse creado.
Nadie se da cuenta, porque nada deja de funcionar visiblemente. Eso es lo que lo hace peligroso.
Por qué la propiedad única es una bomba de relojería
En el artículo anterior señalamos que solo los Propietarios pueden revocar el acceso que un Miembro ha compartido. Es un diseño sensato, pero tiene un punto débil. Si un sitio tiene exactamente un propietario, y ese propietario se va sin traspasar la responsabilidad, ya no queda nadie que pueda revocar ese acceso sin escalar a TI o a un Administrador Global para forzar el cambio.
Por eso "¿tiene el sitio un propietario?" es la pregunta equivocada. La pregunta correcta es "¿tiene el sitio más de un propietario activo?", porque un punto único de fallo en la propiedad sigue siendo un punto único de fallo, incluso antes de que nadie se haya marchado.
Qué comprobar realmente
El punto de partida es sencillo, y es la comprobación que la mayoría de las organizaciones todavía no hace: cuántas personas figuran como propietarias de cada sitio, en todo el tenant. Tanto los sitios sin propietarios como los que tienen un solo propietario merecen marcarse — sin propietarios porque genuinamente no hay nadie responsable, y con un solo propietario porque el sitio está a una baja de distancia de quedarse sin ninguno.
Vale la pena señalar que esta es una comprobación de primer nivel, no completa. Un sitio puede figurar con dos nombres como propietarios mientras una de esas cuentas ya ha dejado la organización — los procesos de baja suelen desaprovisionar la licencia y el buzón de un usuario, pero no siempre provocan una revisión de todos los sitios de SharePoint de los que esa persona era propietaria. Una auditoría más completa cruzaría las cuentas de propietarios con el estado actual del directorio, pero incluso la comprobación más simple del número de propietarios ya saca a la luz la mayor parte del riesgo y es un buen punto de partida.
Dónde esto agrava el problema del artículo anterior
Los sitios huérfanos son exactamente el lugar donde la dispersión descrita en nuestro artículo anterior sobre permisos tiende a acumularse sin que nadie se dé cuenta. Nadie ejecuta la revisión periódica de accesos. Nadie comprueba qué bibliotecas tienen la herencia rota. Enlaces de uso compartido externo concedidos hace dieciocho meses para un proyecto ya terminado siguen activos, porque revisarlos dejó de ser responsabilidad de nadie en cuanto el propietario original se marchó.
Una auditoría de permisos periódica solo funciona si hay alguien en posición de actuar sobre lo que encuentra. Un sitio huérfano tiene un rastro de auditoría que nadie lee.
La solución: un mínimo de dos propietarios activos, siempre
La norma de gobernanza aquí es sencilla de enunciar, y sorprendentemente a menudo se salta en la práctica: todo sitio debería tener al menos dos propietarios, y eso debería comprobarse periódicamente, no asumirse como cierto para siempre tras la creación del sitio.
Esto no es burocracia por burocracia. Es la misma lógica que cualquier riesgo de punto único de fallo: si la respuesta a "¿qué pasa si esta persona no está disponible?" es "nadie puede actuar", eso es una brecha que merece la pena cerrar antes de que importe, no después.
Un script para encontrar estos sitios
En lugar de depender de una revisión manual, esto es sencillo de auditar a escala de tenant con PnP PowerShell, comprobando el grupo de Propietarios de cada sitio y marcando:
- Sitios sin propietarios
- Sitios con exactamente un propietario
- Un recuento secundario de listas/bibliotecas con herencia rota en cada sitio, como indicador de dispersión
Los sitios gestionados por el sistema (App Catalog, Search Center y similares) se omiten automáticamente, ya que no siguen el modelo estándar de propietario/miembro/visitante y no son relevantes para este tipo de auditoría.
El script completo está disponible en la biblioteca de scripts — Get-SPOOrphanedSiteRisk.ps1. Genera un CSV ordenado por nivel de riesgo, para que los sitios que necesitan atención primero aparezcan arriba.
Por dónde seguir
La higiene de permisos y la higiene de propiedad son dos disciplinas de gobernanza distintas que tienen que trabajar juntas. Una herencia limpia no sirve de nada si no hay un propietario activo que la mantenga. El siguiente paso, si no lo has hecho recientemente, es sencillo: ejecuta la auditoría, encuentra tus sitios sin propietarios o con un solo propietario, y asigna un segundo propietario a cada uno antes de que se convierta en algo urgente.
¿Necesitas ayuda para auditar la propiedad de sitios en tu tenant?