Поддержка протокола передачи файлов SSH (SFTP) хранилища BLOB-объектов Azure

  • Статья

Хранилище BLOB-объектов теперь поддерживает протокол передачи файлов SSH (SFTP). Эта поддержка позволяет безопасно подключаться к BLOB-объектам служба хранилища через конечную точку SFTP, позволяя использовать SFTP для доступа к файлам, передачи файлов и управления файлами.

Вот видео, которое рассказывает вам больше об этом.

Azure обеспечивает безопасную передачу учетных записей хранилища BLOB-объектов с помощью REST API службы BLOB-объектов Azure, пакетов SDK Azure и таких инструментов, как AzCopy. Однако в устаревших рабочих нагрузках часто используются традиционные протоколы передачи файлов, такие как SFTP. Вы можете обновить пользовательские приложения, чтобы использовать API REST и пакеты SDK Azure, но только путем внесения существенных изменений в код.

Перед выпуском этой функции, если вы хотите использовать SFTP для передачи данных в хранилище BLOB-объектов Azure, вам придется приобрести сторонний продукт или разработать собственное решение. Для пользовательских решений вам нужно будет создать виртуальные машины (ВМ) в Azure для размещения протокола SFTP-сервера, а затем обновлять, исправлять, управлять, масштабировать и поддерживать сложную архитектуру.

Теперь, благодаря поддержке SFTP для хранилища BLOB-объектов Azure, вы можете включить конечную точку SFTP для учетных записей хранилища BLOB-объектов одним щелчком мыши. Затем вы можете настроить локальные удостоверения пользователей для проверки подлинности для подключения к учетной записи хранения с помощью SFTP через порт 22.

В этой статье описана поддержка SFTP для хранилища BLOB-объектов Azure. Чтобы узнать, как включить SFTP для учетной записи хранения, см. Подключение Хранилище BLOB-объектов Azure с помощью протокола SFTP.

Примечание.

SFTP — это служба уровня платформы, поэтому порт 22 будет открыт, даже если параметр учетной записи отключен. Если доступ по SFTP не настроен, для всех запросов будет получено сообщение об отключении от службы.

SFTP и иерархическое пространство имен

Для поддержки SFTP необходимо включить иерархическое пространство имен. Иерархическое пространство имен организует объекты (файлы) в иерархию каталогов и подкаталогов таким же образом, как организована файловая система на вашем компьютере. Иерархическое пространство имен масштабируется линейно и не снижает объем данных и производительность.

Различные протоколы поддерживаются иерархическим пространством имен. SFTP — один из этих доступных протоколов. На следующем рисунке показан доступ к хранилищу с помощью нескольких протоколов и REST API. Для упрощения чтения в этом изображении используется термин REST 2-го поколения для ссылки на Azure Data Lake Storage 2-го поколения REST API.

Иерархическое пространство имен

Модель разрешений SFTP

Хранилище BLOB-объектов Azure не поддерживает проверку подлинности или авторизацию Microsoft Entra через SFTP. Вместо этого SFTP использует новую форму управления удостоверениями — локальные пользователи.

Локальные пользователи должны использовать пароль или учетные данные закрытого ключа Secure Shell (SSH) для аутентификации. Для учетной записи хранения можно использовать не более 2000 локальных пользователей.

Чтобы настроить права доступа, создайте локального пользователя и выберите способы проверки подлинности. Затем для каждого контейнера в учетной записи можно указать уровень доступа, который вы хотите предоставить этому пользователю.

Внимание

Локальные пользователи не взаимодействуют с другими моделями разрешений служба хранилища Azure, такими как RBAC (управление доступом на основе ролей) и ABAC (управление доступом на основе атрибутов). Списки ACL (списки управления доступом) поддерживаются для локальных пользователей на уровне предварительной версии.

Например, Джефф имеет разрешение только на чтение (можно управлять с помощью RBAC или ABAC) с помощью удостоверения Microsoft Entra для файлов foo.txt , хранящихся в контейнере con1. Если Джефф получает доступ к учетной записи хранения через NFS (если он не подключен как коренной или суперпользователь), REST BLOB-объектов или REST Data Lake Storage 2-го поколения, эти разрешения будут применяться принудительно. Однако если у Джеффа также есть локальный идентификатор пользователя с разрешением на удаление данных в контейнере con1, он может удалить foo.txt через SFTP, используя локальный идентификатор пользователя.

Для учетных записей хранения с поддержкой SFTP вы можете использовать все параметры безопасности хранилища BLOB-объектов Azure для проверки подлинности и авторизации пользователей, получающих доступ к хранилищу BLOB-объектов через портал Azure, Azure CLI, команды Azure PowerShell, AzCopy, а также пакеты Azure SDK и API Azure REST. Чтобы узнать больше, ознакомьтесь с разделом Модель управления доступом в Azure Data Lake Storage 2-го поколения.

методы проверки подлинности;

Вы можете выполнить аутентификацию локальных пользователей, подключающихся через SFTP, используя пароль или пару ключей Secure Shell (SSH). Вы можете настроить обе формы аутентификации и разрешить подключающимся локальным пользователям выбирать, какую из них использовать. Многофакторная проверка подлинности, при которой для успешной аутентификации требуются действительный пароль и действительная пара с открытым и закрытым ключами, не поддерживается.

Passwords

Вы не можете задать пользовательские пароли, а Azure создает один для вас. Если выбрать проверку подлинности паролем, пароль будет предоставлен после завершения настройки локального пользователя. Обязательно скопируйте пароль и сохраните его там, где его можно будет найти. Вы не сможете восстановить этот пароль из Azure еще раз. Если вы потеряете пароль, вам придется создать новый. В целях безопасности вы не можете самостоятельно установить пароль.

Пара ключей SSH

Пара с открытым и закрытым ключами является наиболее распространенной формой проверки подлинности для Secure Shell (SSH). Закрытый ключ является секретным и должен быть известен только локальному пользователю. Открытый ключ хранится в сети Azure. Когда клиент SSH подключается к учетной записи хранения с помощью удостоверения локального пользователя, он отправляет сообщение с открытым ключом и подписью. Azure проверяет сообщение и проверяет, распознаются ли пользователь и ключ в учетной записи хранилища. Дополнительные сведения см. в разделе Обзор SSH и ключей.

Если вы выберете проверку подлинности с помощью пары с открытым и закрытым ключами, вы можете создать ее, использовать уже сохраненную в Azure или предоставить Azure открытый ключ для существующей пары с открытым и закрытым ключами. Для локального пользователя может быть не более 10 открытых ключей.

Разрешения контейнера

Для разрешений на уровне контейнера можно выбрать контейнеры, к которым требуется предоставить доступ, и какой уровень доступа требуется предоставить (чтение, запись, список, удаление, создание, изменение владения и изменение разрешений). Эти разрешения применяются для всех каталогов и подкаталогов в контейнере. Вы можете предоставить каждому локальному пользователю доступ к 100 контейнерам. Разрешения контейнера также можно обновлять после создания локального пользователя. В таблице ниже подробно описаны все разрешения.

Разрешение Символ Description
Читать r
  • Чтение содержимого файла
    		•
    Write w
  • Отправить файл
  • Создать каталог
  • Каталог для отправки
    		•
    List l
  • Вывод списка содержимого внутри контейнера
  • Вывод списка содержимого в каталоге
    		•
    Удаление d
  • Удаление файла или каталога
    		•
    Создание c
  • Передача файла, если он не существует
  • Создание каталога, если он не существует
    		•
    Изменение владения o
  • Изменение пользователя или группы владельцев для файла или каталога
    		•
    Изменить разрешения п
  • Изменение разрешений для файла или каталога
    		•

    При выполнении операций записи с BLOB-объектами во вложенных каталогах требуется разрешение на чтение, позволяющее открыть каталог и получить доступ к свойствам BLOB-объектов.

    списки управления доступом;

    Для разрешений на уровне каталога или большого двоичного объекта можно изменить собственный пользователь, группу владения и режим, используемый списками управления доступом ADLS 2-го поколения. Большинство клиентов SFTP предоставляют команды для изменения этих свойств. В следующей таблице более подробно описаны распространенные команды.

    Команда Требуемое разрешение контейнера Description
    chown o
  • Изменение владения пользователем для файла или каталога
  • Должен указать числовые идентификаторы
    		•
    chgrp o
  • Изменение группы владения для файла или каталога
  • Должен указать числовые идентификаторы
    		•
    chmod п
  • Изменение разрешений/режима для файла или каталога
  • Необходимо указать восьмеричное разрешение стиля POSIX
    		•

    Идентификаторы, необходимые для изменения владеть пользователем и группой владения, являются частью новых свойств для локальных пользователей. В следующей таблице подробно описано каждое новое свойство локального пользователя.

    Свойство Description
    UserId
  • Уникальный идентификатор локального пользователя в учетной записи хранения
  • Создается по умолчанию при создании локального пользователя
  • Используется для задания хладеющего пользователя в файле или каталоге
    		•
    GroupId
  • Identifer для группы локальных пользователей
  • Используется для задания группы владения в файле или каталоге
    		•
    AllowAclAuthorization
  • Разрешить авторизацию запросов локального пользователя с помощью списков управления доступом
    		•

    После настройки требуемых списков управления доступом и локального пользователя AllowAclAuthorizationони могут использовать списки управления доступом для авторизации запросов. Как и RBAC, разрешения контейнеров могут взаимодействовать с списками управления доступом. Только если локальный пользователь не имеет достаточных разрешений контейнера, будут оцениваться списки управления доступом. Чтобы узнать больше, ознакомьтесь с разделом Модель управления доступом в Azure Data Lake Storage 2-го поколения.

    Домашний каталог

    При настройке разрешений вы можете установить для локального пользователя корневой каталог. Если другой контейнер не указан в запросе на подключение SFTP, то домашний каталог — это каталог, к которому пользователь подключается по умолчанию. Например, рассмотрим следующий запрос, сделанный с помощью Open SSH. В этом запросе не указывается имя контейнера или каталога в составе sftp команды.

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

    Если для корневого каталога пользователя установлено значение mycontainer/mydirectory, он будет подключаться к этому каталогу. Затем файл logfile.txt будет передан в mycontainer/mydirectory. Если вы не установили корневой каталог, попытка подключения завершится сбоем. Вместо этого подключающиеся пользователи должны будут указать контейнер вместе с запросом, а затем использовать команды SFTP для перехода к целевому каталогу перед загрузкой файла. Это иллюстрируется в примере ниже.

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

    Примечание.

    Корневая папка — это только начальный каталог, в который помещается подключающийся локальный пользователь. Локальные пользователи могут перейти к любому другому пути в контейнере, к которому они подключены, если у них есть соответствующие разрешения контейнера.

    Поддерживаемые алгоритмы

    Вы можете использовать много разных SFTP-клиентов для безопасного подключения и последующей передачи файлов. При подключении клиентов необходимо использовать алгоритмы, указанные в таблице ниже.

    Тип Алгоритм
    Ключ узла 1 rsa-sha2-256 2
    rsa-sha2-512 2
    ecdsa-sha2-nistp256
    ecdsa-sha2-nistp384
    обмена ключами; ecdh-sha2-nistp384
    ecdh-sha2-nistp256.
    diffie-hellman-group14-sha256;
    diffie-hellman-group16-sha512;
    diffie-hellman-group-exchange-sha256;
    Шифры и шифрование aes128-gcm@openssh.com
    aes256-gcm@openssh.com
    aes128-ctr
    aes192-ctr
    aes256-ctr
    Целостность/MAC hmac-sha2-256
    hmac-sha2-512
    hmac-sha2-256-etm@openssh.com
    hmac-sha2-512-etm@openssh.com
    Открытый ключ ssh-rsa 2
    rsa-sha2-256
    rsa-sha2-512
    ecdsa-sha2-nistp256
    ecdsa-sha2-nistp384
    ecdsa-sha2-nistp521

    1 Ключи узла сервера опубликованы здесь. 2 Ключи RSA должны иметь длину не менее 2048 бит.

    Поддержка SFTP для Хранилища BLOB-объектов Azure сейчас не распространяется на криптографические алгоритмы по соображениям безопасности. Мы настоятельно рекомендуем клиентам использовать утвержденные алгоритмы жизненного цикла разработки защищенных приложений (Майкрософт) (SDL) для безопасного доступа к своим данным.

    В настоящее время в соответствии с SDL безопасности Майкрософт мы не планируем поддерживать следующие функции: ssh-dss, , diffie-hellman-group14-sha1, diffie-hellman-group1-sha1diffie-hellman-group-exchange-sha1, . hmac-sha1-96hmac-sha1 Поддержка алгоритмов может измениться в будущем.

    Подключение с помощью SFTP

    Чтобы начать работу, включите поддержку SFTP, создайте локального пользователя и назначьте разрешения для этого локального пользователя. Затем для безопасного подключения и передачи файлов можно использовать любой клиент SFTP. Пошаговые инструкции см. в статье Подключение к службе хранилища BLOB-объектов Azure с помощью протокола SFTP.

    Известные поддерживаемые клиенты

    Следующие клиенты поддерживают совместимый алгоритм с SFTP для Хранилище BLOB-объектов Azure. Если у вас возникают проблемы с подключением, см. раздел Ограничения и известные проблемы с поддержкой протокола SFTP в Хранилище BLOB-объектов Azure. Этот список не является исчерпывающим и может измениться с течением времени.

    • 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+
    • 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
    • 0.1.54+
    • curl 7.85.0+
    • AIX1
    • MobaXterm версии 21.3

    1 Должен задать AllowPKCS12KeystoreAutoOpen для параметра noзначение .

    Известные проблемы и ограничения

    Полный список ограничений и проблем, связанных с поддержкой SFTP для Хранилища больших двоичных объектов Azure, см. в этой статье.

    Цены и выставление счетов

    Включение конечной точки SFTP имеет почасовую стоимость. Последние сведения о ценах см. в Хранилище BLOB-объектов Azure ценах.

    Совет

    Чтобы избежать пассивных расходов, рекомендуется включить SFTP только в том случае, если вы активно используете его для передачи данных. Инструкции по включению и отключению поддержки SFTP см. в Подключение Хранилище BLOB-объектов Azure с помощью протокола SFTP.

    Применяются цены на транзакции, хранилище и сеть для базовой учетной записи хранения. Все транзакции SFTP преобразуются в транзакции чтения, записи или других транзакций в учетных записях хранения. Сюда входят все команды SFTP и вызовы API. Для получения дополнительной информации см. раздел Сведения о полной модели выставления счетов для Хранилища BLOB-объектов Azure.

    См. также