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

Статья
05/02/2024

Хранилище 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

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

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

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

Внимание

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

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

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

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

Внимание

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

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

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

Тип	Алгоритм
Ключ узла ¹	rsa-sha2-256 ² rsa-sha2-512 ² 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 ² rsa-sha2-256 rsa-sha2-512 ecdsa-sha2-nistp256 ecdsa-sha2-nistp384 ecdsa-sha2-nistp521

¹ Ключи узла сервера опубликованы здесь. ² ключа 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 для Хранилища больших двоичных объектов Azure, см. в этой статье.

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

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

Совет

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

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

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

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

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

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

Passwords

Пара ключей SSH

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

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

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

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

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

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

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

Рекомендации по работе с сетями

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

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

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

Дополнительные ресурсы

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

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

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

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

Passwords

Пара ключей SSH

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

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

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

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

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

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

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

Рекомендации по работе с сетями

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

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

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

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

Дополнительные ресурсы