Substituir um portal de arquivos VPN legado: manter os controles

O antigo portal sem cliente tinha um botão de excluir, uma estrela de favoritos e um caminho de compartilhamento colado em um e-mail. Apenas um desses é um controle. Substituir o portal significa decidir quais operações os usuários remotos ainda precisam e onde cada uma é aplicada, não reproduzir o layout de uma página que funcionava por acaso. Duas formas de substituição cobrem a maioria dos casos, e elas falham em pontos diferentes.

Um botão não é uma permissão

Comece pela lista de operações: leitura, envio, renomeação, exclusão. Decida quais papéis recebem cada uma e então aplique essa decisão no serviço de arquivos, não na interface. Esconder um controle de exclusão em um novo portal deixa a permissão de backend intacta, e qualquer pessoa com um cliente nativo e a mesma conta ainda pode remover o arquivo.

A exclusão merece uma decisão separada porque é a operação de que os usuários se arrependem. Pergunte de onde um item excluído realmente pode ser recuperado, e não presuma que a resposta é a lixeira do laptop ou a lixeira do próprio portal. Um compartilhamento de rede geralmente não encaminha exclusões pela lixeira local.

Em um compartilhamento baseado em Windows, o Volume Shadow Copy fornece o mecanismo de instantâneos e a coordenação que o software de backup usa, mas sua presença não diz nada sobre se esse compartilhamento retém versões que você pode restaurar. O proprietário do serviço de arquivos precisa confirmar a política de versões e demonstrar uma restauração antes que o portal seja desativado.

Opção A: um cliente de arquivos nativo pelo túnel

Uma unidade mapeada ou um cliente SMB mantém as operações que os usuários já conhecem, e as permissões são aplicadas pelo servidor de arquivos em cada solicitação. A identidade que importa é a do serviço de arquivos, então o acesso sobrevive a uma troca de produto VPN enquanto o túnel ainda transporta o tráfego e a conta ainda existe.

O custo é que o cliente precisa alcançar o serviço diretamente. Resolução de nomes, alcance de portas e método de autenticação passam todos a fazer parte do projeto de acesso remoto, e um portal que antes fazia proxy da conexão ocultava cada um desses requisitos. Usuários em dispositivos não gerenciados também ganham um compartilhamento montado no gerenciador de arquivos, o que é uma superfície mais ampla que uma aba do navegador. Orce essa carga de suporte antes da migração, porque ela chega no primeiro dia e não depois de um período de carência.

A recuperação é o argumento mais forte para essa forma: versões anteriores e permissões de restauração são nativas da plataforma, e o suporte pode usar o mesmo procedimento que usa no local.

Opção B: um proxy ou gateway de aplicação

Um portal que busca o arquivo e o transmite ao navegador mantém o serviço de arquivos fora do caminho de rede do usuário. Isso é útil quando o dispositivo não pode entrar no túnel ou quando a organização quer que cada solicitação seja registrada em um único ponto de estrangulamento. A troca é que o proxy passa a participar de cada operação, e precisa levar a identidade do usuário até o serviço de arquivos em vez de usar a própria conta de serviço para tudo.

O comportamento de exclusão e renomeação precisa ser implementado, não herdado. Se o proxy expõe uma ação de exclusão, essa ação chama o backend com alguma identidade, e a trilha de auditoria deve nomear o usuário e não o gateway. Se o proxy não puder renomear, diga isso antes que os usuários descubram no meio de um projeto.

A reescrita de links é onde essa forma muda de significado silenciosamente. Uma URL que o portal faz proxy não é o mesmo objeto que uma URL que o navegador abre diretamente, e converter uma na outra pode remover o contexto de autenticação que a fazia funcionar.

Nomes, identidades e os links entre eles

Distribua o servidor e o caminho de compartilhamento aprovados, não uma lista de navegação de domínio. A navegação depende de serviços de descoberta que podem não atravessar o túnel, e um caminho que funciona porque o laptop do usuário consegue enumerar um domínio é um caminho que quebra no próximo dispositivo não gerenciado.

Revise o logon único aplicação por aplicação. Um token emitido para o portal não deve ser reapresentado a um serviço de arquivos que nunca o validou, e parâmetros de consulta que carregam identificadores não devem ser copiados para um link público só porque apareceram no favorito antigo. Trate cada aplicação aprovada como sua própria fronteira de confiança.

Escolha com base na lista de requisitos

Nenhuma forma vence de imediato. Uma força de trabalho em laptops gerenciados com um túnel funcionando ganha mais com o cliente nativo, porque recuperação e permissões vêm da plataforma e não de uma reimplementação. Uma população mista de terceirizados e dispositivos pessoais pode justificar o proxy, desde que a encanação de identidade seja real e não uma conta de serviço compartilhada.

Escreva a comparação em relação às quatro operações e à resposta de recuperação, e só desative o portal antigo depois que uma restauração tiver sido executada pelo novo caminho. Esse teste exercita as partes do projeto que um login bem-sucedido nunca toca.