Compatibilidad del protocolo de transferencia de archivos SSH (SFTP) con Azure Blob Storage

Blob Storage es ahora compatible con el protocolo de transferencia de archivos SSH (SFTP). Esta compatibilidad proporciona la capacidad de conectarse de manera segura a Blob Storage a través de un punto de conexión de SFTP, lo que le permite usar SFTP para obtener acceso a los archivos, la transferencia de archivos y la administración de archivos.

En este vídeo se explica más sobre el tema.

Azure permite la transferencia de datos segura a cuentas de Blob Storage mediante la API de REST de Azure Blob service, los SDK de Azure y herramientas como AzCopy. Sin embargo, las cargas de trabajo heredadas suelen usar protocolos de transferencia de archivos tradicionales, como SFTP. Puede actualizar aplicaciones personalizadas para usar la API de REST y los SDK de Azure, pero solo realizando cambios significativos en el código.

Antes del lanzamiento de esta característica, si quería usar SFTP para transferir datos a Azure Blob Storage tenía que comprar un producto de terceros o crear su propia solución. En el caso de las soluciones personalizadas, tendría que crear máquinas virtuales (VM) en Azure para hospedar un servidor SFTP y, a continuación, actualizar, aplicar revisiones, administrar, escalar y mantener una arquitectura compleja.

Ahora, con la compatibilidad de SFTP para Azure Blob Storage, puede habilitar un punto de conexión SFTP para las cuentas de Blob Storage con un solo clic. Después, puede configurar identidades de usuario locales para la autenticación para conectarse a la cuenta de almacenamiento con SFTP a través del puerto 22.

En este artículo se describe la compatibilidad de SFTP con Azure Blob Storage. Para obtener información sobre cómo habilitar SFTP para su cuenta de almacenamiento, consulte Conexión a Azure Blob Storage mediante el protocolo de transferencia de archivos SSH (SFTP).

Nota

SFTP es un servicio de nivel de plataforma, por lo que el puerto 22 se abrirá incluso si la opción de la cuenta está deshabilitada. Si el acceso SFTP no está configurado, todas las solicitudes se desconectarán del servicio.

SFTP y el espacio de nombres jerárquico

La compatibilidad con SFTP requiere que se habilite el espacio de nombres jerárquico. El espacio de nombres jerárquico organiza objetos (archivos) en una jerarquía de directorios y subdirectorios de la misma manera en que se organiza el sistema de archivos en el equipo. El espacio de nombres jerárquico se escala linealmente y no degrada el rendimiento ni la capacidad de datos.

El espacio de nombres jerárquico admite distintos protocolos. SFTP es uno de estos protocolos disponibles. En la imagen siguiente se muestra el acceso al almacenamiento a través de varios protocolos y API de REST. Para facilitar la lectura, esta imagen usa el término REST gen2 para hacer referencia a la API de REST de Azure Data Lake Storage Gen2.

espacio de nombres jerárquico

Modelo de permisos SFTP

Azure Blob Storage no admite la autenticación o autorización de Microsoft Entra a través de SFTP. En su lugar, SFTP usa una nueva forma de administración de la identidad denominada usuarios locales.

Los usuarios locales deben utilizar una contraseña o una credencial de clave privada de Secure Shell (SSH) para la autenticación. Puedes tener un máximo de 2000 usuarios locales para una cuenta de almacenamiento.

Para configurar los permisos de acceso, debe crear un usuario local y elegir los métodos de autenticación. A continuación, para cada contenedor de la cuenta, puede especificar el nivel de acceso que quiere proporcionar a ese usuario.

Precaución

Los usuarios locales no interoperan con otros modelos de permisos de Azure Storage, como RBAC (control de acceso basado en rol) y ABAC (control de acceso basado en atributos). Las ACL (listas de control de acceso) se admiten para los usuarios locales en el nivel de versión preliminar.

Por ejemplo, Jeff tiene permiso de solo lectura (se puede controlar mediante RBAC o ABAC) por medio de su identidad de Microsoft Entra para el archivo foo.txt almacenado en el contenedor con1. Si Jeff accede a la cuenta de almacenamiento a través de NFS (cuando no se monta como raíz o superusuario), REST de blobs o Data Lake Storage Gen2 REST, se aplicarán estos permisos. Sin embargo, si Jeff también tiene una identidad de usuario local con permiso de eliminación para los datos del contenedor con1, puede eliminar foo.txt a través de SFTP mediante la identidad de usuario local.

En el caso de las cuentas de almacenamiento habilitadas para SFTP, puede usar toda la gama de opciones de seguridad de Azure Blob Storage para autenticar y autorizar a los usuarios que acceden a Blob Storage a través de Azure Portal, la CLI de Azure, los comandos de Azure PowerShell, AzCopy, así como los SDK y las API REST de Azure. Para más información, consulte Modelo de control de acceso de Azure Data Lake Storage Gen2.

Métodos de autenticación

Puede autenticar a los usuarios locales que se conecten a través de SFTP usando una contraseña o un par de claves pública-privada de Secure Shell (SSH). Puede configurar ambas formas de autenticación y dejar que los usuarios locales que se conectan elijan cuál usar. Sin embargo, no se admite la autenticación multifactor, por lo que se necesitan una contraseña válida y un par de claves pública-privada válidas para que la autenticación sea correcta.

Contraseñas

No puede establecer contraseñas personalizadas, sino que Azure le genera una. Si elige la autenticación de contraseña, la contraseña se proporciona una vez que termine de configurar un usuario local. Asegúrese de copiar esa contraseña y guárdela en una ubicación donde pueda encontrarla más adelante. Recuerde que no podrá recuperar esa contraseña de Azure de nuevo. Si pierde la contraseña, tendrá que generar una nueva. Por motivos de seguridad, no puede establecer la contraseña usted mismo.

Par de claves SSH

Un par de claves pública y privada es la forma más común de autenticación para Secure Shell (SSH). La clave privada es secreta y solo la debe conocer el usuario local. La primera se almacena en Azure. Cuando un cliente SSH se conecta a la cuenta de almacenamiento usando una identidad de usuario local, envía un mensaje con la clave pública y la firma. Azure valida el mensaje y comprueba que la cuenta de almacenamiento reconoce el usuario y la clave. Para obtener más información, consulte Información general de SSH y las claves.

Si decide autenticarse con un par de claves pública y privada, puede generar una, usar una ya almacenada en Azure o proporcionar a Azure la clave pública de un par de claves pública-privada existente. Puede tener un máximo de 10 claves públicas por usuario local.

Permisos del contenedor

En el caso de los permisos de nivel de contenedor, puedes elegir a qué contenedores quieres conceder acceso y qué nivel de acceso quieres proporcionar (lectura, escritura, lista, eliminación, creación, modificación de propiedad y modificación de permisos). Estos permisos se aplican a todos los directorios y subdirectorios del contenedor. Puede conceder a cada usuario local acceso a hasta 100 contenedores. Los permisos de contenedor también se pueden actualizar después de crear un usuario local. En la tabla siguiente se describe cada permiso con más detalle.

Permiso Símbolo Descripción
Leer r
  • Leer el contenido de archivos
  • Escritura w
  • Carga de archivo
  • Creación del directorio
  • Directorio de carga
  • List l
  • Enumeración del contenido del contenedor
  • Enumerar contenido dentro del directorio
  • Eliminar d
  • Eliminar archivo o directorio
  • Crear c
  • Carga de un archivo si este no existe
  • Creación del directorio si aún no existe
  • Modificación de propiedad o
  • Cambiar el usuario propietario o el grupo propietario para el archivo o directorio
  • Modificar permisos p
  • Cambio de permisos para el archivo o directorio
  • Cuando se realizan operaciones de escritura en blobs en subdirectorios, se requiere permiso de lectura para abrir el directorio y acceder a las propiedades de los blobs.

    ACL

    En el caso de los permisos de nivel de directorio o blob, puede cambiar el usuario propietario, el grupo propietario y el modo que usan las ACL de ADLS Gen2. La mayoría de los clientes SFTP exponen comandos para cambiar estas propiedades. En la tabla siguiente, se describen los comandos comunes con más detalle.

    Get-Help Permiso de contenedor necesario Descripción
    chown o
  • Cambio del usuario propietario para el archivo o directorio
  • Se debe especificar el id. numérico
  • chgrp o
  • Cambio del grupo propietario para el archivo o directorio
  • Se debe especificar el id. numérico
  • chmod p
  • Cambiar los permisos o modo para el archivo o directorio
  • Se deben especificar permisos octales de estilo POSIX
  • Los identificadores necesarios para cambiar el usuario propietario y el grupo propietario forman parte de las nuevas propiedades para los usuarios locales. En la tabla siguiente se describe cada nueva propiedad Local User con más detalle.

    Propiedad Descripción
    UserId
  • Identificador único de Local User en la cuenta de almacenamiento
  • Generado de manera predeterminada cuando se crea el usuario local
  • Se usa para establecer el usuario propietario en el archivo o directorio
  • GroupId
  • Identificador para un grupo de propiedades Local User
  • Se usa para establecer un grupo propietario en el archivo o directorio
  • AllowAclAuthorization
  • Permitir la autorización de las solicitudes de este usuario local con ACL
  • Una vez configuradas las ACL deseadas y el usuario local habilita AllowAclAuthorization, puede usar ACL para autorizar sus solicitudes. De forma similar a RBAC, los permisos de contenedor pueden interoperar con ACL. Solo si el usuario local no tiene permisos de contenedor suficientes, se evaluarán las ACL. Para más información, consulte Modelo de control de acceso de Azure Data Lake Storage Gen2.

    Directorio principal

    A medida que configura los permisos, tiene la opción de establecer un directorio principal para el usuario local. Si no se especifica ningún otro contenedor en una solicitud de conexión SFTP, el directorio de inicio es el directorio al que se conecta el usuario de manera predeterminada. Por ejemplo, considere la siguiente solicitud realizada mediante Open SSH. Esta solicitud no especifica un nombre de contenedor o directorio como parte del comando sftp.

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

    Si establece el directorio principal de un usuario en mycontainer/mydirectory, se conectará a ese directorio. A continuación, el archivo logfile.txt se carga en mycontainer/mydirectory. Si no estableció el directorio principal, se producirá un error en el intento de conexión. Los usuarios que se conecten tendrán que especificar un contenedor junto con la solicitud y, después, usar comandos de SFTP para ir al directorio de destino antes de cargar un archivo. Esto se muestra en el ejemplo siguiente:

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

    Nota:

    El directorio principal es solo el directorio inicial que se muestra al usuario local que se conecta. Los usuarios locales pueden ir a cualquier otra ruta de acceso del contenedor al que estén conectados si tienen los permisos adecuados.

    Algoritmos admitidos

    Puede usar muchos clientes SFTP diferentes para conectarse y transferir archivos de forma segura. Los clientes que se conectan deben usar los algoritmos que se especifican en la siguiente tabla.

    Tipo Algoritmo
    Clave de host 1 rsa-sha2-256 2
    rsa-sha2-512 2
    ecdsa-sha2-nistp256
    ecdsa-sha2-nistp384
    Intercambio de claves ecdh-sha2-nistp384
    ecdh-sha2-nistp256
    diffie-hellman-group14-sha256
    diffie-hellman-group16-sha512
    diffie-hellman-group-exchange-sha256
    Cifras/cifrado aes128-gcm@openssh.com
    aes256-gcm@openssh.com
    aes128-ctr
    aes192-ctr
    aes256-ctr
    Integridad/MAC hmac-sha2-256
    hmac-sha2-512
    hmac-sha2-256-etm@openssh.com
    hmac-sha2-512-etm@openssh.com
    Clave pública ssh-rsa 2
    rsa-sha2-256
    rsa-sha2-512
    ecdsa-sha2-nistp256
    ecdsa-sha2-nistp384
    ecdsa-sha2-nistp521

    1Las claves de host se publican aquí. 2 Las claves de RSA deben tener una longitud mínima de 2048 bits.

    La compatibilidad de SFTP con Azure Blob Storage limita actualmente su compatibilidad con algoritmos criptográficos por motivos de seguridad. Se recomienda encarecidamente que los clientes utilicen algoritmos aprobados del Ciclo de vida de desarrollo de seguridad (SDL) de Microsoft para acceder de forma segura a sus datos.

    En este momento, de acuerdo con el SDL de seguridad de Microsoft, no está previsto admitir lo siguiente: ssh-dss, diffie-hellman-group14-sha1, diffie-hellman-group1-sha1, diffie-hellman-group-exchange-sha1, hmac-sha1 nihmac-sha1-96. La compatibilidad con algoritmos está sujeta a cambios en el futuro.

    Conexión con SFTP

    Para empezar, habilite la compatibilidad con SFTP, cree un usuario local y asígnele permisos. A continuación, puede usar cualquier cliente SFTP para conectarse y transferir archivos de forma segura. Para obtener instrucciones paso a paso, consulte Conexión a Azure Blob Storage mediante el protocolo de transferencia de archivos SSH (SFTP).

    Clientes compatibles conocidos

    Los siguientes clientes tienen compatibilidad con algoritmos compatibles com SFTP para Azure Blob Storage. Consulte Limitaciones y problemas de compatibilidad con el protocolo de transferencia de archivos SSH (SFTP) para Azure Blob Storage si tiene problemas de conexión. Esta lista no es exhaustiva y puede cambiar con el tiempo.

    • AsyncSSH 2.1.0+
    • Axway
    • Cyberduck 7.8.2+
    • edtFTPjPRO 7.0.0+
    • FileZilla 3.53.0+
    • libssh 0.9.5+
    • Maverick Legacy 1.7.15+
    • Moveit 12.7
    • OpenSSH 7.4+
    • paramiko 2.8.1+
    • phpseclib 1.0.13 y versiones posteriores
    • 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.Gateway
    • JSCH 0.1.54+
    • curl 7.85.0+
    • AIX1
    • MobaXterm v21.3

    1 Debe establecerse la opción AllowPKCS12KeystoreAutoOpen en no.

    Limitaciones y problemas conocidos

    Consulte el artículo limitaciones y problemas conocidos para obtener una lista completa de limitaciones y problemas relacionados con la compatibilidad de SFTP en Azure Blob Storage.

    Precios y facturación

    La habilitación del punto de conexión SFTP tiene un costo por hora, Para obtener la información de precios más reciente, consulte Precios de Azure Blob Storage.

    Sugerencia

    Para evitar cargos pasivos, considere la posibilidad de habilitar SFTP solo cuando se use activamente para transferir datos. Para obtener instrucciones sobre cómo habilitar y deshabilitar la compatibilidad con SFTP, consulte Conexión a Azure Blob Storage mediante el protocolo de transferencia de archivos SSH (SFTP).

    Se aplican los precios de transacción, almacenamiento y redes de la cuenta de almacenamiento subyacente. Todas las transacciones SFTP se convierten en lectura, escritura u otras transacciones en las cuentas de almacenamiento. Esto incluye todos los comandos SFTP y las llamadas API. Para obtener más información, consulte Descripción del modelo de facturación completo de Azure Blob Storage.

    Vea también