Suporte SFTP no Armazenamento de Blobs do Azure versus um servidor SFTP self-hosted

O suporte ao SSH File Transfer Protocol (SFTP) para Armazenamento de Blobs do Azure permite que uma conta de armazenamento responda diretamente na porta 22, por isso obtém o mesmo protocolo ao qual os utilizadores já se ligam sem correr um servidor por trás. Se hoje alojares um servidor SFTP numa máquina virtual (VM), isso significa que não há sistema operativo para corrigir, não há capacidade para dimensionar, e não há trabalho de cópia a mover ficheiros de um disco de aterragem, porque os dados que carregas tornam-se automaticamente o blob.

Este artigo compara um servidor SFTP auto-hospedado com o Armazenamento de Blobs do Azure SFTP em termos de custo, desempenho, operações e segurança. Também explica como verificar a compatibilidade antes de migrar e como validar a alteração com uma única carga de trabalho.

Como os ficheiros chegam à conta de armazenamento

Com um servidor autoalojado, uma transferência passa por vários componentes que lhe pertencem e que gere. A imagem seguinte mostra o padrão de uma transferência típica.

O ficheiro chega a um disco, e depois um processo que criaste move-o para onde é necessário. És responsável por cada etapa: a VM, o sistema operativo, o daemon SSH, o disco e a respetiva política de retenção, a tarefa de cópia e toda a monitorização associada. Enquanto a cópia não estiver concluída, os dados estão em dois locais e nenhum deles constitui o sistema de registo.

Com o Armazenamento de Blobs do Azure SFTP, a conta de armazenamento termina o protocolo em si. A imagem seguinte mostra este padrão de transferência.

O upload é o blob. Não há disco de aterragem nem trabalho de cópia, porque não há nada para copiar. Assim que a transferência termina, o ficheiro está disponível para a Blob REST API, Azure Data Lake Storage, Network File System (NFS) 3.0, Azure Event Grid e qualquer processamento que já aponte para essa conta.

Só o nome do host muda. Para os utilizadores que se ligam e transferem dados, tudo o resto permanece igual. Usam o mesmo protocolo, as mesmas ferramentas para clientes e o mesmo modelo de credenciais, se quiseres.

Se o seu objetivo é transferir ficheiros para a cloud, mantendo o custo e a segurança em consideração, esta abordagem é um ponto de partida prático. Não está a adotar um novo padrão de transferência; está a remover a infraestrutura subjacente àquela que já utiliza.

Custo

Ativar o SFTP adiciona uma cobrança horária que se aplica sempre que o SFTP está ativado, independentemente de alguém estar ligado ou não. Tudo o resto é faturado de acordo com as tarifas padrão da conta, incluindo capacidade armazenada, transações e tráfego de saída. Todos os comandos SFTP correspondem a transações de leitura, de escrita ou de outro tipo na conta. Não existe uma cobrança separada por gigabyte para os dados transferidos através do SFTP.

Se as tuas transferências decorrerem numa janela definida, podes ativar o SFTP apenas enquanto precisares e evitar a cobrança intermédia.

A tabela seguinte descreve o resultado que pode esperar, com base no que executa atualmente:

Para comparar cada opção de forma justa, inclua o custo de computação, o sistema operativo e os discos de aterragem, e o backup nas suas estimativas. Inclua um balanceador de carga, endereços IP públicos ou uma segunda região apenas se os tiver implementado, porque muitos servidores SFTP funcionam como uma única VM sem nenhum deles.

Dois custos são fáceis de ignorar. Primeiro, os dados normalmente ficam no disco de aterragem e no seu destino durante toda a janela de retenção, por isso pagas por ambos. Em segundo lugar, o tempo de engenharia necessário para a aplicação de patches, a rotação de chaves e a manutenção da tarefa de cópia não aparece de todo em nenhuma fatura.

Utilize a análise de custos no grupo de recursos existente, em vez de uma calculadora de preços, para que trabalhe com base no que é efetivamente faturado. Para as taxas atuais, consulte preços do Armazenamento de Blobs do Azure e Planear e gerir custos para Armazenamento de Blobs do Azure.

Performance

O limite máximo de uma VM é definido pelo seu próprio SKU: a largura de banda da rede, o débito do disco e a capacidade de CPU restante para encriptação SSH. O teto de uma conta de armazenamento corresponde aos limites de taxa de entrada e pedido da conta, que são consideravelmente mais altos e não exigem qualquer esforço da sua parte para serem alcançados.

A taxa de transferência escala com o número de ligações concorrentes, e uma conta blob de bloco premium atinge aproximadamente 2,3 vezes a largura de banda de uma conta v2 de uso geral padrão com um único cliente. Para orientações de afinação, consulte considerações sobre desempenho do SFTP.

Operations

Armazenamento de Blobs do Azure SFTP proporciona maior eficiência operacional.

Como a conta de armazenamento termina o SFTP, a VM, o disco de aterragem e o trabalho de cópia desaparecem, juntamente com o trabalho de os manter a funcionar. Já não precisa de aplicar correções a um sistema operativo, endurecer um daemon SSH, planear a capacidade, criar e testar a sua própria estratégia de alta disponibilidade e recuperação após desastre, nem dar suporte ao processo que transfere ficheiros para o armazenamento.

A gestão de chaves de host é um exemplo. Reconstruir uma VM altera a sua chave de host SSH, a menos que a preserve deliberadamente, e as ferramentas do cliente tratam uma alteração inesperada da chave do host como um possível ataque machine-in-the-middle. A manutenção de rotina torna-se, portanto, um exercício de coordenação com todos os que estabelecem ligação. Em contraste, o Azure publica as suas chaves de host SFTP, para que as ferramentas do cliente possam verificá-las contra uma fonte documentada. Consulte as chaves do anfitrião para SFTP.

Segurança

Um servidor OpenSSH auto-hospedado suporta autenticação por palavra-passe e chave pública. Tu és dono das contas, da sshd configuração e da distribuição e rotação das chaves.

O Armazenamento de Blobs do Azure SFTP suporta ambos os métodos e adiciona o Microsoft Entra ID. Pode escolher o método apropriado para cada utilizador:

O Microsoft Entra ID é a diferença mais significativa entre as duas abordagens. Com qualquer credencial local, seja numa VM ou numa conta de armazenamento, o segredo é duradouro e fica fora dos controlos de identidade que aplica ao resto do seu espólio.

Um certificado Entra ID expira após 65 minutos, por isso uma credencial mal gerida deixa de funcionar por si só. A autenticação multifator e o Acesso Condicional aplicam-se à transferência de ficheiros da mesma forma que se aplicam a tudo o resto. Quando uma conta é desativada, o acesso ao SFTP termina ao mesmo tempo. Ao usar Identidades Externas, as organizações com quem troca ficheiros podem autenticar-se a partir do seu próprio tenant, pelo que deixa de emitir ou armazenar credenciais em nome delas.

Os utilizadores locais mantêm-se totalmente suportados, por isso pode adotar o Entra ID ao ritmo que preferir.

Para além da identidade, uma conta de armazenamento fornece controlos que de outra forma construiria e manteria por si próprio:

• Apenas algoritmos aprovados no Ciclo de Vida de Desenvolvimento Centrado na Segurança da Microsoft são aceites, pelo que opções fracas como ssh-dss trocas de chaves baseadas em SHA-1 não estão disponíveis.

• Os endpoints privados mantêm o tráfego na sua rede virtual.

• O Microsoft Defender for Storage analisa os carregamentos à procura de malware, sem instalar ou manter um scanner.

• A encriptação em repouso, as chaves geridas pelo cliente, as políticas de imutabilidade e o registo de diagnóstico aplicam-se a ficheiros carregados através do SFTP da mesma forma que se aplicam a qualquer outro blob.

Para mais informações, consulte modelo de permissões SFTP e Autorizar acesso ao Armazenamento de Blobs sobre SFTP usando o Microsoft Entra ID.

Verifique a compatibilidade antes de migrar

A maioria das cargas de trabalho migra sem alterações, e o Armazenamento de Blobs do Azure suporta uma vasta gama de ferramentas cliente SFTP. Para confirmar o teu próprio cenário, vê clientes suportados conhecidos e Limitações e problemas conhecidos com SFTP.

Verifique estes itens desde cedo, porque são os motivos mais comuns pelos quais uma carga de trabalho não pode ser movida tal como está:

• Uma configuração ACL existente no caminho de acesso.

• Um endereço IP de saída estático que outra organização inclui numa lista de permissões.

• Um requisito para um fluxo de trabalho gerido de transferência de ficheiros ou para AS2.

Experimenta com uma carga de trabalho

Ativa o SFTP numa conta de armazenamento não produtiva e executa um feed de baixo risco juntamente com o teu servidor existente durante duas semanas. Obtém rendimento, compatibilidade e custos através da sua própria carga de trabalho, que são mais úteis do que uma estimativa.

Conteúdo relacionado

• Ativar o suporte SFTP para Armazenamento de Blobs do Azure
• Ligue-se ao Armazenamento de Blobs do Azure usando SFTP
• Autorize o acesso ao Armazenamento de Blobs através do SFTP usando o Microsoft Entra ID
• Considerações de desempenho do SFTP
• Limitações e problemas conhecidos com o SFTP