Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
El soporte del Protocolo de Transferencia de Archivos SSH (SFTP) para Azure Blob Storage permite que una cuenta de almacenamiento responda directamente en el puerto 22, así que obtienes el mismo protocolo al que tus usuarios ya se conectan sin tener un servidor detrás. Si hoy alojas un servidor SFTP en una máquina virtual (VM), eso significa que no hay sistema operativo que parchear, ni capacidad que dimensionar, ni trabajo de copia moviendo archivos de un disco de aterrizaje, porque los datos que subes se convierten automáticamente en el blob.
Este artículo compara un servidor SFTP autoalojado con Azure Blob Storage SFTP en términos de coste, rendimiento, operaciones y seguridad. También explica cómo comprobar la compatibilidad antes de migrar y cómo validar el cambio con una sola carga de trabajo.
Cómo llegan los archivos a la cuenta de almacenamiento
Con un servidor autoalojado, una transferencia pasa por varios componentes que posees y gestionas. La siguiente imagen muestra el patrón de una transferencia típica.
El archivo llega a un disco, y luego un proceso que has creado lo mueve a donde se necesita. Eres dueño de cada salto: la máquina virtual, el sistema operativo, el demonio SSH, el disco y su retención, el trabajo de copia y la monitorización alrededor de todo ello. Hasta que se complete la copia, los datos existen en dos lugares, y ninguno de ellos es el sistema de registro.
Con Azure Blob Storage SFTP, la cuenta de almacenamiento termina el protocolo en sí. La siguiente imagen muestra este patrón de transferencia.
La carga es el blob. No hay disco de aterrizaje ni trabajo de copia, porque no hay nada que copiar. En cuanto se completa la transferencia, el archivo estará disponible para la API REST de Blob, Azure Data Lake Storage, Network File System (NFS) 3.0, Azure Event Grid y cualquier procesamiento que ya apunte a esa cuenta.
Solo cambia el nombre de host. Para los usuarios que se conectan y transfieren datos, todo lo demás sigue igual. Usan el mismo protocolo, las mismas herramientas para clientes y el mismo modelo de credenciales si lo quieres.
Si tu objetivo es trasladar la transferencia de archivos a la nube teniendo en cuenta el coste y la seguridad, este enfoque es un punto de partida práctico. No estás adoptando un nuevo patrón de transferencia; estás eliminando la infraestructura subyacente a la que ya utilizas.
Cost
Activar SFTP añade un cargo por hora que se aplica siempre que SFTP esté activado, independientemente de si alguien está conectado o no. Todo lo demás se factura según las tarifas estándar de la cuenta, incluidas la capacidad en reposo, las transacciones y el tráfico de salida. Todos los comandos SFTP se contabilizan como transacciones de lectura, escritura o de otro tipo en la cuenta. No hay un cargo separado por gigabyte por los datos transferidos a través de SFTP.
Si tus transferencias se realizan dentro de una ventana definida, puedes activar SFTP solo mientras lo necesites y evitar el cargo intermedio.
Nota:
Para encontrar la tarifa horaria actual, consulta la página de precios de Azure Blob Storage. La carga solo es visible en esa página si seleccionas Espacio de Nombres Jerárquico (NFS v3.0, Protocolo SFTP) en la lista desplegable de Estructura de Archivos .
La siguiente tabla describe el resultado que puede esperar, en función de lo que ejecute hoy:
| Lo que ejecutas hoy | Blob Storage SFTP probablemente será | Por qué |
|---|---|---|
| Una sola máquina virtual con una o dos vCPUs | Más caro | El coste horario del endpoint supera el coste de cálculo de una máquina virtual pequeña. Si eso es toda tu huella, el coste no es la razón para mudarte. Sin embargo, la eficiencia operativa podría ser una razón para mudarse. Puedes obtener más información sobre esas eficiencias en la sección de Operaciones de este artículo. |
| Una máquina virtual dimensionada para un rendimiento sostenido, con un disco gestionado y copia de seguridad | Más o menos lo mismo | El cargo del endpoint compensa el procesamiento, los discos y la copia de seguridad. |
| Más de una instancia para garantizar la disponibilidad, o una segunda región para la recuperación ante desastres | Significativamente menos | Dejas de pagar por computación redundante y la segunda región. |
| Cualquiera de las filas anteriores, una vez incluido el tiempo de ingeniería | Menos | La aplicación de parches, la rotación de claves y el tiempo de guardia no figuran en ninguna de las dos facturas. |
Para comparar cada opción de forma justa, incluye el coste de cálculo, el sistema operativo y los discos de aterrizaje, y la copia de seguridad en tus estimaciones. Incluye un balanceador de carga, direcciones IP públicas o una segunda región solo si las has desplegado, porque muchos servidores SFTP funcionan como una única máquina virtual sin ninguno de ellos.
Dos costes son fáciles de pasar por alto. Primero, los datos suelen permanecer en el disco de llegada and en su destino durante toda la ventana de retención, así que pagas por ambos. Segundo, el tiempo del equipo de ingeniería dedicado a aplicar parches, la rotación de claves y el mantenimiento de la tarea de copia no aparece en ninguna factura.
Utiliza el análisis de costes del grupo de recursos existente en lugar de una calculadora de precios, para que trabajes con lo que realmente se factura. Para las tarifas actuales, consulte Azure Blob Storage pricing and Plan and manage costs for Azure Blob Storage.
Performance
El límite de una máquina virtual lo establece su propio SKU: su ancho de banda de red, su rendimiento de disco y la CPU que queda para el cifrado SSH. El límite de una cuenta de almacenamiento son los límites de acceso y tasa de solicitud, que son considerablemente más altos y no requieren ningún esfuerzo por tu parte para alcanzarlos.
El rendimiento se escala con el número de conexiones simultáneas, y una cuenta de blobs en bloque premium alcanza aproximadamente 2,3 veces el ancho de banda de una cuenta v2 estándar de uso general con un único cliente. Para orientaciones sobre la afinación, véase consideraciones sobre el rendimiento del SFTP.
Operations
Azure Blob Storage SFTP ofrece una mayor eficiencia operativa.
Como la cuenta de almacenamiento termina SFTP, la máquina virtual, el disco de aterrizaje y el trabajo de copia desaparecen, junto con el trabajo de mantenerlos en funcionamiento. Ya no necesitas parchear un sistema operativo, reforzar un daemon SSH, planificar la capacidad, construir y probar tu propia alta disponibilidad y recuperación ante desastres, ni soportar la pipeline que mueve archivos al almacenamiento.
La gestión de claves de host es un ejemplo. Reconstruir una VM cambia su clave SSH de host a menos que la conserves deliberadamente, y las herramientas del cliente tratan un cambio inesperado de clave de host como un posible ataque de máquina en el centro. Por tanto, el mantenimiento rutinario se convierte en un ejercicio de coordinación con todos los que se conectan. En cambio, Azure publica sus claves de host SFTP, para que las herramientas cliente puedan verificarlas frente a una fuente documentada. Consulta las claves de host para SFTP.
Security
Un servidor OpenSSH autoalojado soporta tanto la autenticación por contraseña como por clave pública. Tú eres el propietario de las cuentas, la sshd configuración y la distribución y rotación de las claves.
Azure Blob Storage SFTP soporta ambos métodos y añade Microsoft Entra ID. Puedes elegir el método adecuado para cada usuario:
| Method | Cómo funciona | Más adecuado para |
|---|---|---|
| Password | Azure genera la contraseña y la muestra una vez. No puedes poner contraseñas personalizadas, así que no es posible usar contraseñas débiles o reutilizadas. | Primeros pasos rápidos |
| Par de claves SSH | Suministras o generas una clave pública, hasta 10 por usuario local. | Traslados automatizados y sin supervisión |
| Microsoft Entra ID | Los usuarios se autentican en Entra ID y reciben un certificado válido durante 65 minutos, autorizado por Azure role-based access control (RBAC), Azure attribute-based access control (ABAC) y listas POSIX access control (ACLs). | Recomendado donde la gobernanza de identidad sea importante |
Microsoft Entra ID es la diferencia más significativa entre ambos enfoques. Con cualquier credencial local, ya sea en una VM o en una cuenta de almacenamiento, el secreto es duradero y queda fuera de los controles de identidad que aplicas al resto de tu patrimonio.
Un certificado Entra ID caduca tras 65 minutos, por lo que una credencial mal gestionada deja de funcionar por sí sola. La autenticación multifactor y el acceso condicional se aplican a la transferencia de archivos de la misma manera que a todo lo demás. Cuando una cuenta está desactivada, el acceso a SFTP termina al mismo tiempo. Al usar Identidades Externas, las organizaciones con las que intercambias archivos pueden autenticarse desde su propio tenant, por lo que ya no emites ni almacenas credenciales en su nombre.
Los usuarios locales siguen recibiendo compatibilidad total, por lo que puedes adoptar Entra ID al ritmo que mejor se adapte a tus necesidades.
Más allá de la identidad, una cuenta de almacenamiento proporciona controles que de otro modo construirías y mantendrías tú mismo:
Solo se aceptan algoritmos aprobados bajo el Ciclo de vida de desarrollo de seguridad de Microsoft, por lo que no están disponibles opciones débiles como
ssh-dssintercambios de claves basados en SHA-1.Los puntos finales privados mantienen el tráfico en tu red virtual.
Microsoft Defender for Storage escanea las subidas en busca de malware, sin un escáner que instalar o mantener.
El cifrado en reposo, las claves gestionadas por el cliente, las políticas de inmutabilidad y el registro de diagnóstico se aplican a los archivos subidos a través de SFTP de la misma manera que a cualquier otro blob.
Para más información, consulte modelo de permisos SFTP y Autorizar acceso a Blob Storage sobre SFTP usando Microsoft Entra ID.
Comprueba la compatibilidad antes de migrar
La mayoría de las cargas de trabajo migran sin cambios, y Azure Blob Storage soporta una amplia gama de herramientas cliente SFTP. Para confirmar tu propio escenario, consulta clientes soportados conocidos y Limitaciones y problemas conocidos con SFTP.
Revisa estos elementos con antelación, porque son las razones más comunes por las que una carga de trabajo no puede moverse as-is:
Una configuración ACL existente en la ruta de acceso.
Una dirección IP saliente estática que otra organización incluye en una lista de permitidos.
Un requisito para un flujo de trabajo gestionado de transferencia de archivos o para AS2.
Pruébalo con una sola carga de trabajo
Activa SFTP en una cuenta de almacenamiento no productiva y ejecuta una sola señal de bajo riesgo junto a tu servidor existente durante dos semanas. Obtienes cifras de rendimiento, compatibilidad y coste de tu propia carga de trabajo, que son más útiles que una estimación.