Compartilhar via

Suporte ao SFTP (protocolo FTP SSH) para Armazenamento de Blobs do Azure

  • Artigo

O Armazenamento de blobs agora dá suporte ao SFTP (Protocolo FTP SSH). Esse suporte permite a conexão segura com o Armazenamento de Blobs usando um cliente SFTP, permitindo que você use o SFTP para acessar, transferir e gerenciar arquivos.

Assista a um vídeo que explica mais sobre isso.

O Azure permite a transferência segura de dados para contas de Armazenamento de Blobs usando a API REST do serviço Blob do Azure, os SDKs do Azure e ferramentas como o AzCopy. No entanto, as cargas de trabalho herdadas geralmente usam protocolos de transferência de arquivos tradicionais, como o SFTP. Você pode até atualizar aplicativos personalizados para usar a API REST e os SDKs do Azure, mas só se fizer alterações significativas no código.

Antes do lançamento desse recurso, se você quisesse usar o SFTP para transferir dados para o Armazenamento de Blobs do Azure, seria preciso comprar um produto de terceiros ou orquestrar sua própria solução. Para soluções personalizadas, você teria que criar VMs (máquinas virtuais) no Azure para hospedar um servidor SFTP e, em seguida, atualizar, corrigir, gerenciar, dimensionar e manter uma arquitetura complexa.

Agora, com o suporte do SFTP para o Armazenamento de Blobs do Azure, você pode habilitar o suporte do SFTP para contas de Armazenamento de Blobs com um único clique. Em seguida, você pode configurar identidades de usuário locais para autenticação para se conectar à sua conta de armazenamento com o SFTP por meio da porta 22.

Este artigo descreve o suporte do SFTP para o Armazenamento de Blobs do Azure. Saiba como habilitar o SFTP em sua conta de armazenamento em Conectar-se ao Armazenamento de Blobs do Azure usando o SFTP (protocolo FTP SSH).

Observação

O SFTP é um serviço de nível de plataforma, portanto, a porta 22 será aberta mesmo se a opção de conta estiver desabilitada. Se o acesso SFTP não estiver configurado, todas as solicitações receberão uma desconexão do serviço.

SFTP e o namespace hierárquico

O suporte ao SFTP requer que o namespace hierárquico seja habilitado. O namespace hierárquico organiza os objetos (arquivos) em uma hierarquia de diretórios e subdiretórios da mesma forma que o sistema de arquivos no seu computador é organizado. O namespace hierárquico dimensiona linearmente e não prejudica a capacidade ou o desempenho dos dados.

Protocolos diferentes têm suporte no namespace hierárquico. O SFTP é um desses protocolos disponíveis. A imagem a seguir mostra o acesso ao armazenamento por meio de vários protocolos e APIs REST. Para facilitar a leitura, essa imagem usa o termo REST para se referir à API REST do Azure Data Lake Storage.

namespace hierárquico

Modelo de permissão SFTP

Os clientes SFTP não podem ser autorizados usando identidades do Microsoft Entra. Em vez disso, o SFTP utiliza uma nova forma de gerenciamento de identidade chamada usuários locais.

Os usuários locais devem usar uma senha ou uma credencial de chave privada SSH (Secure Shell) para autenticação. Você pode ter no máximo 8.000 usuários locais para uma conta de armazenamento.

Para configurar permissões de acesso, crie um usuário local e escolha os métodos de autenticação. Em seguida, para cada contêiner em sua conta, você pode especificar o nível de acesso que deseja dar a esse usuário.

Cuidado

Os usuários locais não interoperam com outros modelos de permissão do Armazenamento do Azure como RBAC (controle de acesso baseado em função) e ABAC (controle de acesso baseado em atributo). As ACLs (listas de controle de acesso) têm suporte para usuários locais no nível de versão prévia.

Por exemplo, Jeff tem permissão somente leitura (pode ser controlada por meio de RBAC ou ABAC) por meio de sua identidade do Microsoft Entra para o arquivo foo.txt armazenado no contêiner con1. Se Jeff estiver acessando a conta de armazenamento por meio do NFS (quando não estiver montado como raiz/superusuário), o REST do Blob ou o REST do Data Lake Storage, essas permissões serão impostas. No entanto, se Jeff também tiver uma identidade de usuário local com permissão de exclusão para dados no contêiner con1, ele poderá excluir foo.txt via SFTP usando a identidade do usuário local.

Habilitar o suporte do SFTP não impede que outros tipos de cliente usem o Microsoft Entra ID. Para usuários que acessam o Armazenamento de Blobs usando o portal do Azure, a CLI do Azure e comandos do Azure PowerShell, AzCopy, bem como SDKs do Azure e APIs REST do Azure, você pode continuar a usar toda a gama da configuração de segurança do Armazenamento de Blobs do Azure para autorizar o acesso. Para saber mais, consulte Modelo de controle de acesso no Azure Data Lake Storage.

Métodos de autenticação

Você pode autenticar usuários locais que se conectam via SFTP usando uma senha ou um par de chaves público-privadas SSH (Secure Shell). É possível configurar ambas as formas de autenticação e permitir que os usuários locais conectados escolham qual usar. No entanto, não há suporte para a autenticação multifator, em que uma senha válida e um par de chaves públicas/privadas válido são necessários para uma autenticação bem-sucedida.

Senhas

Não é possível definir senhas personalizadas. Em vez disso, o Azure gera uma para você. Se você escolher a autenticação de senha, sua senha será fornecida depois de concluir a configuração de um usuário local. Copie essa senha e salve-a em um local em que você possa encontrá-la posteriormente. Não será possível recuperar essa senha do Azure novamente. Se você perder a senha, terá que gerar uma nova. Por motivos de segurança, você não pode definir a senha por conta própria.

Pares de chaves SSH

Um par de chaves públicas/privadas é a forma de autenticação SSH (Secure Shell) mais comum. A chave privada é secreta e deve ser conhecida apenas pelo usuário local. A chave pública é armazenada no Azure. Quando um cliente SSH se conecta à conta de armazenamento usando uma identidade de usuário local, ele envia uma mensagem com a chave pública e a assinatura. O Azure valida a mensagem e verifica se o usuário e a chave são reconhecidos pela conta de armazenamento. Saiba mais em Visão geral sobre SSH e chaves.

Se você optar pela autenticação com um par de chaves públicas/privadas, poderá gerar uma, usar uma já armazenada no Azure ou fornecer a chave pública ao Azure de um par de chaves públicas/privadas existente. Você pode ter no máximo 10 chaves públicas por usuário local.

Permissões do contêiner

Para permissões de nível de contêiner, você pode escolher a quais contêineres deseja conceder acesso e a qual nível de acesso deseja fornecer (Ler, Gravar, Listar, Excluir, Criar, Modificar Propriedade e Modificar Permissões). Essas permissões se aplicam a todos os diretórios e subdiretórios no contêiner. Você pode conceder acesso a até 100 contêineres para cada usuário local. As permissões de contêiner também podem ser atualizadas após a criação de um usuário local. A tabela a seguir descreve cada permissão mais detalhadamente.

Permissão Símbolo Descrição
Ler r
  • Ler conteúdo do arquivo
    		•
    Gravar w
  • Carregar arquivo
  • Criar diretório
  • Diretório de carregamento
    		•
    Lista l
  • Listar conteúdo dentro do contêiner
  • Listar conteúdo dentro do diretório
    		•
    Excluir d
  • Excluir arquivo/diretório
    		•
    Criar c
  • Carregar arquivo se este não existir
  • Criar diretório, caso não exista um diretório
    		•
    Modificar Propriedade o
  • Alterar o usuário proprietário ou o grupo proprietário de um arquivo ou diretório
    		•
    Modificar Permissões p
  • Alterar a ACL de um arquivo ou diretório
    		•

    Ao executar operações de gravação em blobs em subdiretórios, a permissão de leitura é necessária para abrir o diretório e acessar as propriedades do blob.

    ACLs (listas de controle de acesso)

    Importante

    Este recurso está na VERSÃO PRÉVIA no momento. Veja os Termos de Uso Complementares para Versões Prévias do Microsoft Azure para obter termos legais que se aplicam aos recursos do Azure que estão em versão beta, versão prévia ou que, de outra forma, ainda não foram lançados em disponibilidade geral.

    As ACLs permitem que você dê acesso "refinado", como acesso de gravação a um diretório ou arquivo específico. Para saber mais sobre ACLs, consulte ACLs (listas de controle de acesso) no Azure Data Lake Storage.

    Para autorizar um usuário local usando ACLs, primeiro habilite a autorização de ACL para esse usuário local. Consulte Conceder permissão a contêineres.

    Observação

    Embora uma ACL possa definir o nível de permissão para muitos tipos diferentes de identidades, somente o usuário proprietário, o grupo proprietário e todas as outras identidades de usuários podem ser usadas para autorizar um usuário local. Usuários nomeados e grupos nomeados ainda não têm suporte para autorização do usuário local.

    A tabela a seguir descreve as propriedades de um usuário local que são usadas para autorização de ACL.

    Propriedade Descrição
    ID do Usuário
  • Identificador exclusivo para o usuário local dentro da conta de armazenamento
  • Gerado por padrão quando o Usuário Local é criado
  • Usado para definir o usuário proprietário no arquivo/diretório
    		•
    GroupId
  • Identificador para um grupo de usuários locais
  • Usado para definir o grupo proprietário no arquivo/diretório
    		•
    AllowAclAuthorization
  • Permitir a autorização de solicitações desse Usuário Local com ACLs
    		•

    Como as permissões de ACL são avaliadas

    As ACLs serão avaliadas somente se o usuário local não tiver as permissões de contêiner necessárias para executar uma operação. Devido à maneira como as permissões de acesso são avaliadas pelo sistema, você não pode usar uma ACL para restringir o acesso que já foi concedido por permissões de nível de contêiner. Isso ocorre porque o sistema avalia primeiro as permissões de contêiner e, se essas permissões concederem permissão de acesso suficiente, as ACLs serão ignoradas.

    Importante

    Para conceder a um usuário local acesso de leitura ou gravação a um arquivo, você precisará fornecer ao usuário local permissões Executar para a pasta raiz do contêiner e para cada pasta na hierarquia de pastas que levam ao arquivo. Se o usuário local for o usuário proprietário ou o grupo proprietário, você poderá aplicar permissões Executar ao usuário proprietário ou ao grupo proprietário. Caso contrário, você precisará aplicar a permissão Executar a todos os outros usuários.

    Modificar ACLs com um cliente SFTP

    Embora as permissões de ACL possam ser modificadas usando qualquer ferramenta ou SDK do Azure, os usuários locais também podem modificá-las. Para permitir que um usuário local modifique as permissões de ACL, primeiro você deve conceder a permissão Modify Permissions ao usuário local. Consulte Conceder permissão a contêineres.

    Os usuários locais podem alterar o nível de permissão somente do usuário proprietário, do grupo proprietário e de todos os outros usuários de uma ACL. Ainda não há suporte para adicionar ou modificar entradas de ACL para usuários nomeados, grupos nomeados e entidades de segurança nomeadas.

    Os usuários locais também podem alterar a ID do usuário proprietário e do grupo proprietário. Na verdade, somente os usuários locais podem alterar a ID do usuário proprietário ou do grupo proprietário para uma ID de usuário local. Você ainda não pode referenciar uma ID de usuário local em uma ACL usando uma ferramenta ou SDK do Azure. Para alterar o usuário proprietário ou o grupo proprietário de um diretório ou blob, o usuário local deve receber a permissão Modify Ownership.

    Para exibir exemplos, consulte Modificar a ACL de um arquivo ou diretório.

    Diretório base

    Ao configurar permissões, você tem a opção de definir um diretório base para o usuário local. Se nenhum outro contêiner for especificado em uma solicitação de conexão SFTP, o diretório base será o diretório ao qual o usuário se conectará por padrão. Por exemplo, considere a solicitação a seguir feita usando o Open SSH. Essa solicitação não especifica um nome de contêiner ou diretório como parte do comando sftp.

    sftp myaccount.myusername@myaccount.blob.core.windows.net
put logfile.txt

    Se você definir o diretório inicial de um usuário como mycontainer/mydirectory, ele se conectará a esse diretório. Em seguida, o arquivo logfile.txt seria carregado em mycontainer/mydirectory. Se você não tiver definido o diretório base, a tentativa de conexão falhará. Em vez disso, os usuários conectados teriam que especificar um contêiner junto com a solicitação e usar comandos SFTP para navegar até o diretório de destino antes de carregar um arquivo. O seguinte exemplo mostra isso:

    sftp myaccount.mycontainer.myusername@myaccount.blob.core.windows.net
cd mydirectory
put logfile.txt

    Observação

    O diretório inicial é apenas o diretório inicial em que o usuário local conectado é colocado. Os usuários locais podem navegar para qualquer outro caminho no contêiner ao qual estão conectados se tiverem as permissões de contêiner apropriadas.

    Algoritmos compatíveis

    É possível usar muitos clientes SFTP diferentes para conectar e transferir arquivos com segurança. Os clientes de conexão devem usar algoritmos especificados na tabela abaixo.

    Tipo Algoritmo
    Chave de host 1 rsa-sha2-256 2
    rsa-sha2-512 2
    ecdsa-sha2-nistp256
    ecdsa-sha2-nistp384
    Troca de chaves ecdh-sha2-nistp384
    ecdh-sha2-nistp256
    diffie-hellman-group14-sha256
    diffie-hellman-group16-sha512
    diffie-hellman-group-exchange-sha256
    Criptografias/criptografia aes128-gcm@openssh.com
    aes256-gcm@openssh.com
    aes128-ctr
    aes192-ctr
    aes256-ctr
    Integridade/MAC hmac-sha2-256
    hmac-sha2-512
    hmac-sha2-256-etm@openssh.com
    hmac-sha2-512-etm@openssh.com
    Chave pública ssh-rsa 2
    rsa-sha2-256
    rsa-sha2-512
    ecdsa-sha2-nistp256
    ecdsa-sha2-nistp384
    ecdsa-sha2-nistp521

    As chaves de host 1 são publicadas aqui. 2 As chaves RSA devem ter pelo menos 2.048 bits.

    Atualmente, o suporte SFTP para o Armazenamento de Blobs do Azure limita o suporte a algoritmos criptográficos com base em considerações de segurança. É altamente recomendável que os clientes utilizem algoritmos aprovados pelo SDL (Microsoft Security Development Lifecycle) para acessar seus dados com segurança.

    Neste momento, de acordo com o Microsoft Security Development Lifecycle, não planejamos dar suporte ao seguinte: ssh-dss, diffie-hellman-group14-sha1, diffie-hellman-group1-sha1, diffie-hellman-group-exchange-sha1, hmac-sha1, hmac-sha1-96. O suporte a algoritmos está sujeito a alterações no futuro.

    Conectar-se ao SFTP

    Para começar, habilite o suporte a SFTP, crie um usuário local e atribua permissões a esse usuário local. Em seguida, é possível usar qualquer cliente SFTP para se conectar e transferir arquivos com segurança. Para diretrizes passo a passo, consulte Conectar-se ao Armazenamento de Blobs do Azure usando o SFTP (protocolo FTP SSH)

    Considerações de rede

    O SFTP é um serviço de nível de plataforma, portanto, a porta 22 será aberta mesmo se a opção de conta estiver desabilitada. Se o acesso SFTP não estiver configurado, todas as solicitações receberão uma desconexão do serviço. Ao usar o SFTP, convém limitar o acesso público configurando um firewall, uma rede virtual ou um ponto de extremidade privado. Essas configurações são impostas na camada do aplicativo, o que significa que não são específicas do SFTP e afetarão a conectividade com todos os Pontos de Extremidade do Armazenamento do Microsoft Azure. Para mais informações sobre firewalls e configuração de rede, consulte Configurar Redes Virtuais e Firewalls de Armazenamento do Azure.

    Observação

    As ferramentas de auditoria que tentam determinar o suporte a TLS na camada de protocolo podem retornar versões do TLS além da versão mínima necessária quando são executadas diretamente no ponto de extremidade da conta de armazenamento. Para mais informações, consulte Impor uma versão mínima necessária de Segurança da Camada de Transporte (TLS) para solicitações a uma conta de armazenamento.

    Clientes conhecidos com suporte

    Os clientes a seguir têm suporte a algoritmos compatíveis com o SFTP para Armazenamento de Blobs do Azure. Consulte Limitações e problemas conhecidos com o suporte para protocolo SFTP (protocolo FTP SSH) no Armazenamento de Blobs do Azure (versão prévia) se estiver com problemas de conexão. Essa lista não é completa e pode mudar ao longo do tempo.

    • AsyncSSH 2.1.0 ou superior
    • Axway
    • Cyberduck 7.8.2 ou superior
    • edtFTPjPRO 7.0.0 ou superior
    • FileZilla 3.53.0 ou superior
    • Five9
    • libssh 0.9.5 ou superior
    • Maverick Legacy 1.7.15 ou superior
    • Moveit 12.7
    • Mule 2.1.2+
    • OpenSSH 7.4 ou superior
    • paramiko 2.8.1 ou superior
    • phpseclib 1.0.13+
    • PuTTY 0.74 ou superior
    • QualysML 12.3.41.1 ou superior
    • RebexSSH 5.0.7119.0 ou superior
    • Salesforce
    • ssh2js 0.1.20 ou superior
    • sshj 0.27.0 ou superior
    • SSH.NET 2020.0.0 ou superior
    • WinSCP 5.10 ou superior
    • Workday
    • XFB.Gateway
    • JSCH 0.1.54+
    • curl 7.85.0+
    • AIX1
    • MobaXterm v21.3

    1 Deve definir a opção AllowPKCS12KeystoreAutoOpen como no.

    Limitações e problemas conhecidos

    Confira o artigo de limitações e problemas conhecidos para ver uma lista completa de limitações e problemas com o suporte do SFTP para o Armazenamento de Blobs do Azure.

    Preços e cobrança

    Habilitar o SFTP tem um custo por hora. Para obter as informações de preços mais recentes, confira preços do Armazenamento de Blobs do Azure.

    Dica

    Para evitar encargos passivos, considere habilitar o SFTP apenas quando você o estiver usando ativamente para transferir dados. Para obter orientações sobre como habilitar e desabilitar o suporte ao SFTP, confira Conectar-se ao Armazenamento de Blobs do Azure usando o Protocolo FTP SSH (SFTP).

    Os preços de transação, armazenamento e rede da conta de armazenamento subjacente se aplicam. Todas as transações SFTP são convertidas em Transações de Leitura, Gravação ou Outras em suas contas de armazenamento. Isso inclui todos os comandos SFTP e chamadas à API. Saiba mais em Entender o modelo de cobrança completo do Armazenamento de Blobs do Azure.

    Conteúdo relacionado