Suporte do SSH File Transfer Protocol (SFTP) para o Armazenamento de Blobs do Azure

  • Artigo

O armazenamento de Blob agora suporta o SSH File Transfer Protocol (SFTP). Esse suporte permite que você se conecte com segurança ao Armazenamento de Blob usando um cliente SFTP, permitindo que você use o SFTP para acesso a arquivos, transferência de arquivos e gerenciamento de arquivos.

Aqui está um vídeo que fala mais sobre isso.

O Azure permite a transferência segura de dados para contas de Armazenamento de Blob usando a API REST do serviço de Blob do Azure, SDKs do Azure e ferramentas como AzCopy. No entanto, cargas de trabalho herdadas geralmente usam protocolos tradicionais de transferência de arquivos, como SFTP. Você pode atualizar aplicativos personalizados para usar a API REST e os SDKs do Azure, mas apenas fazendo 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, teria que comprar um produto de terceiros ou orquestrar sua própria solução. Para soluções personalizadas, você teria que criar máquinas virtuais (VMs) no Azure para hospedar um servidor SFTP e, em seguida, atualizar, corrigir, gerenciar, dimensionar e manter uma arquitetura complexa.

Agora, com o suporte SFTP para o Armazenamento de Blobs do Azure, você pode habilitar o suporte SFTP para contas de Armazenamento de Blob 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 SFTP via porta 22.

Este artigo descreve o suporte SFTP para o Armazenamento de Blobs do Azure. Para saber como habilitar o SFTP para sua conta de armazenamento, consulte Conectar-se ao Armazenamento de Blobs do Azure usando o Protocolo de Transferência de Arquivos SSH (SFTP).

Nota

O SFTP é um serviço de nível de plataforma, portanto, a porta 22 estará aberta mesmo se a opção de conta estiver desativada. 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 a SFTP requer namespace hierárquico para ser habilitado. O namespace hierárquico organiza objetos (arquivos) em uma hierarquia de diretórios e subdiretórios da mesma forma que o sistema de arquivos do seu computador está organizado. O namespace hierárquico é dimensionado linearmente e não degrada a capacidade ou o desempenho dos dados.

Diferentes protocolos são suportados pelo namespace hierárquico. 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, esta imagem usa o termo Gen2 REST para se referir à API REST do Azure Data Lake Storage Gen2.

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 identidades chamada usuários locais.

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

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

Atenção

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 listas de controle de acesso (ACLs) são suportadas para usuários locais no nível de visualização.

Por exemplo, Jeff tem permissão somente leitura (pode ser controlada via RBAC ou ABAC) por meio de sua identidade Microsoft Entra para foo.txt de arquivos armazenados no contêiner con1. Se Jeff estiver acessando a conta de armazenamento via NFS (quando não estiver montado como root/superusuário), Blob REST ou Data Lake Storage Gen2 REST, 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, eles poderão excluir foo.txt via SFTP usando a identidade de usuário local.

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

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-privado Secure Shell (SSH). Você pode configurar ambas as formas de autenticação e permitir que os usuários locais que se conectam escolham qual usar. No entanto, a autenticação multifator, em que uma senha válida e um par de chaves público-privado válido são necessários para uma autenticação bem-sucedida, não é suportada.

Palavras-chave

Você não pode 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 que você concluir a configuração de um usuário local. Certifique-se de copiar essa senha e salvá-la em um local onde você possa encontrá-la mais tarde. Você não poderá recuperar essa senha do Azure novamente. Se você perder a senha, você tem que gerar uma nova. Por razões de segurança, não pode definir a palavra-passe por conta própria.

Pares de chaves SSH

Um par de chaves público-privado é a forma mais comum de autenticação para Secure Shell (SSH). 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. Para saber mais, consulte Visão geral de SSH e chaves.

Se optar por autenticar com o par de chaves público-privado, pode gerar uma, utilizar uma já armazenada no Azure ou fornecer ao Azure a chave pública de um par de chaves público-privado existente. Você pode ter um máximo de 10 chaves públicas por usuário local.

Permissões de contêiner

Para permissões no nível de contêiner, você pode escolher a quais contêineres deseja conceder acesso e qual nível de acesso deseja fornecer (Leitura, Gravação, Lista, 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 a cada usuário local acesso a até 100 contêineres. 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 com mais detalhes.

Permissão Símbolo Description
Lida r
  • Ler conteúdo do ficheiro
    		•
    Escrita w
  • Carregar ficheiro
  • Criar um diretório
  • Carregar diretório
    		•
    Listagem l
  • Listar conteúdo dentro do contêiner
  • Listar conteúdo dentro do diretório
    		•
    Delete d
  • Excluir arquivo/diretório
    		•
    Criar c
  • Carregar ficheiro se o ficheiro não existir
  • Criar diretório se o diretório não existir
    		•
    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, permissão de Ler é necessário para abrir o diretório e acessar as propriedades do blob.

    Listas de controlo de acesso (ACL)

    Importante

    Esse recurso está atualmente em visualização. Veja Termos de Utilização Complementares da Pré-visualizações do Microsoft Azure para obter os termos legais que se aplicam às funcionalidades do Azure que estão na versão beta, na pré-visualização ou que ainda não foram lançadas para disponibilidade geral.

    As ACLs permitem-lhe conceder acesso "refinado", tais como o acesso de escrita a um diretório ou ficheiro específico. Para saber mais sobre ACLs, consulte Listas de controle de acesso (ACLs) no Azure Data Lake Storage Gen2.

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

    Nota

    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 são suportados para autorização de usuário local.

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

    Property Description
    UserId
  • 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
    		•
    Id do Grupo
  • Identificar para um grupo de usuários locais
  • Usado para definir o grupo proprietário no arquivo/diretório
    		•
    AllowAclAuthorization
  • Permitir autorizar as solicitações deste Usuário Local com ACLs
    		•

    Como as permissões de ACL são avaliadas

    As ACLs sã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 no nível do contêiner. Isso ocorre porque o sistema avalia as permissões de contêiner primeiro 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á conceder a esse 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 as permissões Executar ao usuário proprietário ou ao grupo proprietário. Caso contrário, você terá que aplicar a permissão Executar a todos os outros usuários.

    Modificando ACLs com um cliente SFTP

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

    Os usuários locais podem alterar o nível de permissão apenas 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, apenas os usuários locais podem alterar o ID do usuário proprietário ou do grupo proprietário para um ID de usuário local. Ainda não é possível fazer referência a 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 Modify Ownership permissão.

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

    Diretório inicial

    Ao configurar as 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 conecta por padrão. Por exemplo, considere a seguinte solicitação feita usando Open SSH. Essa solicitação não especifica um nome de contêiner ou diretório como parte do sftp comando.

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

    Se você definir o diretório base de um usuário como mycontainer/mydirectory, ele se conectará a esse diretório. Em seguida, o logfile.txt arquivo seria enviado para mycontainer/mydirectory. Se você não definiu 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, em seguida, usar comandos SFTP para navegar até o diretório de destino antes de carregar um arquivo. O exemplo a seguir mostra isso:

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

    Nota

    O diretório base é apenas o diretório inicial no qual o usuário local de conexão é 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 suportados

    Pode utilizar vários clientes SFTP diferentes para se ligar e transferir ficheiros de forma segura. Os clientes que estabelecem ligação têm de utilizar os algoritmos especificados na tabela abaixo.

    Type Algoritmo
    Chave de anfitrião 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
    Cifras/encriptação 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

    1 As chaves de anfitrião estão publicadas aqui. 2 As chaves RSA devem ter, no mínimo, 2.048 bits de comprimento.

    Atualmente, o suporte de SFTP para o Armazenamento de Blobs do Azure limita o suporte do algoritmo criptográfico com base em considerações de segurança. Recomendamos vivamente que os clientes utilizem algoritmos aprovados pelo Ciclo de Vida de Desenvolvimento Centrado na Segurança (CVDCS) da Microsoft para aceder em segurança aos dados.

    No momento, de acordo com o Microsoft Security SDL, não planejamos oferecer 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 de algoritmos está sujeito a alterações no futuro.

    Conectando-se com SFTP

    Para começar, habilite o suporte a SFTP, crie um usuário local e atribua permissões para esse usuário local. Em seguida, você pode usar qualquer cliente SFTP para se conectar com segurança e, em seguida, transferir arquivos. Para obter orientação passo a passo, consulte Conectar-se ao Armazenamento de Blobs do Azure usando o protocolo de transferência de arquivos SSH (SFTP).

    Considerações sobre a rede

    O SFTP é um serviço de nível de plataforma, portanto, a porta 22 estará aberta mesmo se a opção de conta estiver desativada. 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 por meio da configuração de um firewall, rede virtual ou ponto de extremidade privado. Essas configurações são impostas na camada de aplicativo, o que significa que elas não são específicas do SFTP e afetarão a conectividade com todos os Pontos de Extremidade de Armazenamento do Azure. Para obter mais informações sobre firewalls e configuração de rede, consulte Configurar firewalls de armazenamento do Azure e redes virtuais.

    Nota

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

    Clientes suportados conhecidos

    Os seguintes clientes têm suporte a algoritmos compatíveis com SFTP para Armazenamento de Blobs do Azure. Consulte Limitações e problemas conhecidos com o suporte do SSH File Transfer Protocol (SFTP) para o Armazenamento de Blobs do Azure se você estiver tendo problemas para se conectar. Esta lista não é exaustiva e pode mudar ao longo do tempo.

    • AsyncSSH 2.1.0+
    • Axway
    • Cyberduck 7.8.2+
    • edtFTPjPRO 7.0.0+
    • FileZilla 3.53.0+
    • libssh 0.9.5+
    • Maverick Legado 1.7.15+
    • Moveit 12,7
    • OpenSSH 7.4+
    • Paramiko 2.8.1+
    • phpseclib 1.0.13+
    • PuTTY 0,74+
    • QualysML 12.3.41.1+
    • RebexSSH 5.0.7119.0+
    • Salesforce
    • SSH2JS 0.1.20+
    • SSHJ 0.27.0+
    • SSH.NET 2020.0.0+
    • WinSCP 5,10+
    • Workday
    • XFB. Porta de entrada
    • JSCH 0.1.54+
    • ondulação 7.85.0+
    • AIX1
    • MobaXterm v21,3

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

    Problemas conhecidos e de limitações

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

    Preços e faturação

    Ativar o SFTP tem um custo horário. Para obter as informações de preços mais recentes, consulte Preços do Armazenamento de Blobs do Azure.

    Gorjeta

    Para evitar cobranças passivas, considere ativar o SFTP somente quando você estiver usando ativamente para transferir dados. Para obter orientação sobre como habilitar e desabilitar o suporte a SFTP, consulte Conectar-se ao Armazenamento de Blobs do Azure usando o Protocolo de Transferência de Arquivos SSH (SFTP).

    Aplicam-se os preços de transação, armazenamento e rede para a conta de armazenamento subjacente. 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 de API. Para saber mais, consulte Compreender o modelo de cobrança completo do Armazenamento de Blobs do Azure.

    Conteúdos relacionados