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

Artículo
05/03/2024

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 mediante un cliente 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 la compatibilidad de 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 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

Los clientes SFTP no se pueden autorizar mediante identidades de Microsoft Entra. 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. Puede 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 listas de control de acceso (ACL) 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.

La habilitación de la compatibilidad con SFTP no impide que otros tipos de clientes usen Microsoft Entra ID. Para los usuarios que acceden a Blob Storage mediante Azure Portal, la CLI de Azure, los comandos de Azure PowerShell, AzCopy, así como los SDK de Azure y las API de REST de Azure, puede seguir usando la amplia configuración de seguridad de Azure Blob Storage para autorizar el acceso. 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 de un archivo o directorio
Modificar permisos	p	Cambiar la ACL de un 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.

Listas de control de acceso (ACL)

Importante

Esta funcionalidad actualmente se encuentra en VERSIÓN PRELIMINAR. Consulte Términos de uso complementarios para las versiones preliminares de Microsoft Azure para conocer los términos legales que se aplican a las características de Azure que se encuentran en la versión beta, en versión preliminar o que todavía no se han publicado para que estén disponibles con carácter general.

Las listas de control de acceso (ACL) permiten conceder acceso "específico", como el acceso de escritura a un directorio o archivo concretos. Para más información sobre ACL, consulte Listas de control de acceso en Azure Data Lake Storage Gen2.

Para autorizar a un usuario local mediante ACL, primero debe habilitar la autorización de ACL para ese usuario local. Consulte la sección sobre cómo conceder permiso a los contenedores.

Nota:

Aunque una ACL puede definir el nivel de permiso para muchos tipos diferentes de identidades, solo el usuario propietario, el grupo propietario y todas las demás identidades de usuarios se pueden usar para autorizar a un usuario local. Los usuarios con nombre y los grupos con nombre aún no se admiten para la autorización del usuario local.

En la tabla siguiente se describen las propiedades de un usuario local que se usan para la autorización de ACL.

Propiedad	Descripción
UserId	Identificador único del usuario local dentro de 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 usuarios locales 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

Cómo se evalúan los permisos de ACL

Las ACL solo se evalúan si el usuario local no tiene los permisos de contenedor necesarios para realizar una operación. Debido a la forma en que el sistema evalúa los permisos de acceso, no puede usar una ACL para restringir el acceso que ya han concedido los permisos de nivel de contenedor. Esto se debe a que el sistema evalúa primero los permisos de contenedor y, si esos permisos conceden permisos de acceso suficientes, se omiten las ACL.

Importante

Para conceder a un usuario local acceso de lectura o escritura a un archivo, deberá conceder a ese usuario local permisos de ejecución a la carpeta raíz del contenedor y a cada carpeta de la jerarquía de carpetas que conducen al archivo. Si el usuario local es el usuario propietario o el grupo propietario, puede aplicar permisos de ejecución al usuario propietario o al grupo propietario. De lo contrario, tendrá que aplicar el permiso de ejecución a todos los demás usuarios.

Modificación de ACL con un cliente SFTP

Aunque los permisos de ACL se pueden modificar mediante cualquier herramienta o SDK de Azure compatible, los usuarios locales también pueden modificarlos. Para permitir que un usuario local modifique los permisos de ACL, primero debe conceder el permiso de usuario local Modify Permissions. Consulte la sección sobre cómo conceder permiso a los contenedores.

Los usuarios locales pueden cambiar el nivel de permiso de solo el usuario propietario, el grupo propietario y todos los demás usuarios de una ACL. Todavía no se admite la adición o modificación de entradas de ACL para usuarios con nombre, grupos con nombre y entidades de seguridad con nombre.

Los usuarios locales también pueden cambiar el identificador del usuario propietario y el grupo propietario. De hecho, solo los usuarios locales pueden cambiar el identificador del usuario propietario o del grupo propietario a un identificador de usuario local. Todavía no puede hacer referencia a un identificador de usuario local en una ACL mediante una herramienta o un SDK de Azure. Para cambiar el usuario propietario o el grupo propietario de un directorio o blob, se debe conceder el permiso Modify Ownership al usuario local.

Para ver ejemplos, consulte Modificación de la ACL de un archivo o directorio.

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 ¹	rsa-sha2-256 ² rsa-sha2-512 ² 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 ² rsa-sha2-256 rsa-sha2-512 ecdsa-sha2-nistp256 ecdsa-sha2-nistp384 ecdsa-sha2-nistp521

¹Las claves de host se publican aquí. ² 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).

Consideraciones sobre redes

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. Si usa SFTP, es posible que quiera limitar el acceso público mediante la configuración de un firewall, una red virtual o un punto de conexión privado. Esta configuración se aplica en la capa de aplicación, lo que significa que no es específica de SFTP y afectará a la conectividad con todos los puntos de conexión de Azure Storage. Para más información sobre la configuración de firewalls y de la red, consulte Configuración de redes virtuales y firewalls de Azure Storage.

Nota

Herramientas de auditoría que intentan determinar la compatibilidad de TLS en la capa de protocolo pueden devolver versiones de TLS además de la versión mínima necesaria cuando se ejecutan directamente en el punto de conexión de la cuenta de almacenamiento. Para obtener más información, consulte Aplicación de una versión mínima necesaria de Seguridad de la capa de transporte (TLS) para las solicitudes a una cuenta de almacenamiento.

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+
AIX¹
MobaXterm v21.3

¹ 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 de 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.