Sustituir un portal de archivos VPN antiguo: conserve los controles

El antiguo portal sin cliente tenía un botón de borrar, una estrella de favoritos y una ruta compartida pegada en un correo. Solo uno de esos elementos es un control. Sustituir el portal significa decidir qué operaciones siguen necesitando los usuarios remotos y dónde se aplica cada una, no reproducir el diseño de una página que funcionaba por casualidad. Dos formas de sustitución cubren la mayoría de los casos, y fallan en puntos distintos.

Un botón no es un permiso

Empiece por la lista de operaciones: leer, subir, renombrar, borrar. Decida qué roles reciben cada una y después aplique esa decisión en el servicio de archivos, no en la interfaz. Ocultar un control de borrado en un portal nuevo deja intacto el permiso del servidor de fondo, y cualquiera con un cliente nativo y la misma cuenta todavía puede eliminar el archivo.

El borrado merece una decisión aparte porque es la operación de la que se arrepienten los usuarios. Pregunte de dónde se puede recuperar realmente un elemento borrado y no suponga que la respuesta es la papelera del portátil o la papelera propia del portal. Un recurso compartido de red normalmente no dirige los borrados por la papelera local.

En un recurso compartido con soporte de Windows, Volume Shadow Copy proporciona el mecanismo de instantáneas y la coordinación que utiliza el software de copia de seguridad, pero su presencia no dice nada sobre si este recurso conserva versiones que pueda restaurar. El propietario del servicio de archivos debe confirmar la política de versiones y demostrar una restauración antes de retirar el portal.

Opción A: un cliente de archivos nativo por el túnel

Una unidad asignada o un cliente SMB conserva las operaciones que los usuarios ya conocen, y el servidor de archivos aplica los permisos en cada solicitud. La identidad que importa es la del servicio de archivos, así que el acceso sobrevive a un cambio de producto VPN mientras el túnel siga llevando el tráfico y la cuenta siga existiendo.

El coste es que el cliente debe llegar al servicio directamente. La resolución de nombres, la accesibilidad de los puertos y el método de autenticación pasan a formar parte del diseño de acceso remoto, y un portal que antes hacía de proxy de la conexión ocultaba cada uno de esos requisitos. Los usuarios de dispositivos no gestionados también obtienen un recurso compartido montado en su gestor de archivos, lo que es una superficie más amplia que una pestaña del navegador. Presupueste esa carga de soporte antes de la migración, porque llega el primer día y no después de un periodo de gracia.

La recuperación es el argumento más fuerte para esta forma: las versiones anteriores y los permisos de restauración son nativos de la plataforma, y el servicio de asistencia puede usar el mismo procedimiento que utiliza in situ.

Opción B: un proxy o una pasarela de aplicaciones

Un portal que obtiene el archivo y lo transmite al navegador mantiene el servicio de archivos fuera de la ruta de red del usuario. Eso resulta útil cuando el dispositivo no puede unirse al túnel o cuando la organización quiere que cada solicitud quede registrada en un único cuello de botella. La contrapartida es que el proxy pasa a participar en cada operación y debe llevar la identidad del usuario hasta el servicio de archivos en lugar de usar su propia cuenta de servicio para todo.

El comportamiento de borrado y renombrado debe implementarse, no heredarse. Si el proxy expone una acción de borrado, esa acción llama al servidor de fondo con alguna identidad, y el registro de auditoría debería nombrar al usuario, no a la pasarela. Si el proxy no puede renombrar, dígalo antes de que los usuarios lo descubran a mitad de un proyecto.

La reescritura de enlaces es donde esta forma cambia el significado en silencio. Una URL que el portal sirve como proxy no es el mismo objeto que una URL que el navegador abre directamente, y convertir una en otra puede eliminar el contexto de autenticación que la hacía funcionar.

Nombres, identidades y los enlaces entre ellos

Distribuya el servidor y la ruta compartida aprobados, no una lista de exploración de dominio. La exploración depende de servicios de detección que pueden no cruzar el túnel, y una ruta que funciona porque el portátil del usuario puede enumerar un dominio es una ruta que se rompe en el siguiente dispositivo no gestionado.

Revise el inicio de sesión único aplicación por aplicación. Un token emitido para el portal no debería reproducirse en un servicio de archivos que nunca lo validó, y los parámetros de consulta que llevan identificadores no deberían copiarse en un enlace público solo porque aparecían en el marcador antiguo. Trate cada aplicación aprobada como su propia frontera de confianza.

Elija según la lista de requisitos

Ninguna de las dos formas gana por completo. Una plantilla con portátiles gestionados y un túnel que funciona obtiene más del cliente nativo, porque la restauración y los permisos vienen de la plataforma y no de una reimplementación. Una población mixta de contratistas y dispositivos personales puede justificar el proxy, siempre que la infraestructura de identidad sea real y no una cuenta de servicio compartida.

Escriba la comparación frente a las cuatro operaciones y la respuesta de recuperación, y después retire el portal antiguo solo cuando se haya realizado una restauración por la ruta nueva. Esa prueba ejercita las partes del diseño que un inicio de sesión correcto nunca toca.