Поделиться через

Поддержка протокола передачи файлов 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).

Примечание.

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

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

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

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

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

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

Клиенты SFTP не могут быть авторизованы с помощью удостоверений Microsoft Entra. Вместо этого SFTP использует новую форму управления удостоверениями — локальные пользователи.

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

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

Внимание

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

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

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

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

Вы можете выполнить аутентификацию локальных пользователей, подключающихся через 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
  • Изменение пользователя или группы владельцев файла или каталога
    		•
    Изменить разрешения п
  • Изменение ACL файла или каталога
    		•

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

    Списки управления доступом (ACL)

    Внимание

    Сейчас эта функция доступна в виде ПРЕДВАРИТЕЛЬНОЙ ВЕРСИИ. Юридические условия, применимые к функциям Azure, которые находятся в состоянии бета-версии, предварительной версии или иным образом еще не выпущены в общедоступной версии, см. на странице Дополнительные условия использования предварительных версий в Microsoft Azure.

    Списки управления доступом позволяют предоставить детализированный доступ, например, доступ для записи, к определенному каталогу или файлу. Дополнительные сведения о списках управления доступом см. в списках управления доступом в Azure Data Lake Storage.

    Чтобы авторизовать локального пользователя с помощью списков управления доступом, необходимо сначала включить авторизацию ACL для этого локального пользователя. См. раздел "Предоставление разрешений контейнерам".

    Примечание.

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

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

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

    Как вычисляются разрешения ACL

    Списки управления доступом оцениваются только в том случае, если у локального пользователя нет необходимых разрешений контейнера для выполнения операции. Из-за того, как разрешения доступа оцениваются системой, нельзя использовать ACL для ограничения доступа, который уже предоставлен разрешениями на уровне контейнера. Это связано с тем, что система сначала оценивает разрешения контейнера, и если эти разрешения предоставляют достаточное разрешение на доступ, списки управления доступом игнорируются.

    Внимание

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

    Изменение списков управления доступом с помощью клиента SFTP

    Хотя разрешения ACL можно изменить с помощью любого поддерживаемого средства Azure или пакета SDK, локальные пользователи также могут изменять их. Чтобы разрешить локальному пользователю изменять разрешения ACL, необходимо сначала предоставить локальному пользователю Modify Permissions разрешение. См. раздел "Предоставление разрешений контейнерам".

    Локальные пользователи могут изменить уровень разрешений только для владельцев, группы владельцев и всех других пользователей ACL. Добавление или изменение записей ACL для именованных пользователей, именованных групп и именованных субъектов безопасности пока не поддерживается.

    Локальные пользователи также могут изменить идентификатор владельцев и группы владельцев. Фактически только локальные пользователи могут изменить идентификатор владельцев или группы на локальный идентификатор пользователя. Вы еще не можете ссылаться на идентификатор локального пользователя в ACL с помощью средства или пакета SDK Azure. Чтобы изменить владение пользователем или группой владельцев каталога или большого двоичного объекта, локальный пользователь должен иметь Modify Ownership разрешение.

    Сведения о просмотре примеров см. в разделе "Изменение ACL" файла или каталога.

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

    При настройке разрешений вы можете установить для локального пользователя корневой каталог. Если другой контейнер не указан в запросе на подключение 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 — это служба уровня платформы, поэтому порт 22 будет открыт, даже если параметр учетной записи отключен. Если доступ SFTP не настроен, все запросы получают отключение от службы. При использовании SFTP, возможно, вы захотите ограничить общий доступ с помощью настройки брандмауэра, виртуальной сети или частной конечной точки. Эти параметры применяются на уровне приложения, что означает, что они не относятся к SFTP и повлияют на подключение ко всем служба хранилища Azure конечным точкам. Дополнительные сведения о настройке брандмауэров и сети см. в статье Настройка брандмауэров службы хранилища Azure и виртуальных сетей.

    Примечание.

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

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

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

    • AsyncSSH 2.1.0+
    • Axway
    • Cyberduck 7.8.2+
    • edtFTPjPRO 7.0.0+
    • FileZilla 3.53.0+
    • Five9
    • libssh 0.9.5+
    • Maverick Legacy 1.7.15+
    • Moveit 12.7
    • Mule 2.1.2+
    • 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.

    Связанный контент