Substituír un portal de ficheiros VPN antigo: conserve os controis

O antigo portal sen cliente tiña un botón de borrar, unha estrela de favoritos e unha ruta compartida pegada nun correo. Só un deses elementos é un control. Substituír o portal significa decidir que operacións seguen necesitando os usuarios remotos e onde se aplica cada unha, non reproducir o deseño dunha páxina que funcionaba por casualidade. Dúas formas de substitución cobren a maioría dos casos, e fallan en puntos distintos.

Un botón non é un permiso

Comece pola lista de operacións: ler, subir, renomear, borrar. Decida que roles reciben cada unha e despois aplique esa decisión no servizo de ficheiros, non na interface. Ocultar un control de borrado nun portal novo deixa intacto o permiso do servidor de fondo, e calquera con un cliente nativo e a mesma conta aínda pode eliminar o ficheiro.

O borrado merece unha decisión aparte porque é a operación da que se arrepinten os usuarios. Pregunte de onde se pode recuperar realmente un elemento borrado e non supoña que a resposta é a papeleira do portátil ou a papeleira propia do portal. Un recurso compartido de rede normalmente non dirixe os borrados pola papeleira local.

Nun recurso compartido con soporte de Windows, Volume Shadow Copy proporciona o mecanismo de instantáneas e a coordinación que usa o software de copia de seguridade, pero a súa presenza non di nada sobre se este recurso conserva versións que poida restaurar. O propietario do servizo de ficheiros debe confirmar a política de versións e demostrar unha restauración antes de retirar o portal.

Opción A: un cliente de ficheiros nativo polo túnel

Unha unidade asignada ou un cliente SMB conserva as operacións que os usuarios xa coñecen, e o servidor de ficheiros aplica os permisos en cada solicitude. A identidade que importa é a do servizo de ficheiros, así que o acceso sobrevive a un cambio de produto VPN mentres o túnel siga levando o tráfico e a conta siga existindo.

O custo é que o cliente debe chegar ao servizo directamente. A resolución de nomes, a accesibilidade dos portos e o método de autenticación pasan a formar parte do deseño de acceso remoto, e un portal que antes facía de proxy da conexión ocultaba cada un deses requisitos. Os usuarios de dispositivos non xestionados tamén obteñen un recurso compartido montado no seu xestor de ficheiros, o que é unha superficie máis ampla que unha pestana do navegador. Presuposte esa carga de soporte antes da migración, porque chega o primeiro día e non despois dun período de graza.

A recuperación é o argumento máis forte para esta forma: as versións anteriores e os permisos de restauración son nativos da plataforma, e o servizo de asistencia pode usar o mesmo procedemento que utiliza in situ.

Opción B: un proxy ou unha pasarela de aplicacións

Un portal que obtén o ficheiro e o transmite ao navegador mantén o servizo de ficheiros fóra da ruta de rede do usuario. Iso resulta útil cando o dispositivo non pode unirse ao túnel ou cando a organización quere que cada solicitude quede rexistrada nun único colo de botella. A contrapartida é que o proxy pasa a participar en cada operación e debe levar a identidade do usuario ata o servizo de ficheiros en lugar de usar a súa propia conta de servizo para todo.

O comportamento de borrado e renomeado debe implementarse, non herdarse. Se o proxy expón unha acción de borrado, esa acción chama o servidor de fondo con algunha identidade, e o rexistro de auditoría debería nomear o usuario, non a pasarela. Se o proxy non pode renomear, dígao antes de que os usuarios o descubran a metade dun proxecto.

A reescritura de ligazóns é onde esta forma cambia o significado en silencio. Unha URL que o portal serve como proxy non é o mesmo obxecto que unha URL que o navegador abre directamente, e converter unha na outra pode eliminar o contexto de autenticación que a facía funcionar.

Nomes, identidades e as ligazóns entre eles

Distribúa o servidor e a ruta compartida aprobados, non unha lista de exploración de dominio. A exploración depende de servizos de descuberta que poden non cruzar o túnel, e unha ruta que funciona porque o portátil do usuario pode enumerar un dominio é unha ruta que se rompe no seguinte dispositivo non xestionado.

Revise o inicio de sesión único aplicación por aplicación. Un token emitido para o portal non debería reproducirse nun servizo de ficheiros que nunca o validou, e os parámetros de consulta que levan identificadores non deberían copiarse nunha ligazón pública só porque aparecían no marcador antigo. Trate cada aplicación aprobada como a súa propia fronteira de confianza.

Escolla segundo a lista de requisitos

Ningunha das dúas formas gaña por completo. Unha plantilla con portátiles xestionados e un túnel que funciona obtén máis do cliente nativo, porque a restauración e os permisos veñen da plataforma e non dunha reimplementación. Unha poboación mixta de contratistas e dispositivos persoais pode xustificar o proxy, sempre que a infraestrutura de identidade sexa real e non unha conta de servizo compartida.

Escriba a comparación fronte ás catro operacións e a resposta de recuperación, e despois retire o portal antigo só cando se realizase unha restauración pola ruta nova. Esa proba exercita as partes do deseño que un inicio de sesión correcto nunca toca.