Obsługa protokołu SSH File Transfer Protocol (SFTP) dla usługi Azure Blob Storage

Usługa Blob Storage obsługuje teraz protokół SSH File Transfer Protocol (SFTP). Ta obsługa umożliwia bezpieczne łączenie się z usługą Blob Storage przy użyciu klienta SFTP, co umożliwia korzystanie z protokołu SFTP na potrzeby dostępu do plików, transferu plików i zarządzania plikami.

Oto film wideo, który zawiera więcej informacji na ten temat.

Platforma Azure umożliwia bezpieczny transfer danych do kont usługi Blob Storage przy użyciu interfejsu API REST usługi Azure Blob Service, zestawów AZURE SDK i narzędzi, takich jak Narzędzie AzCopy. Jednak starsze obciążenia często używają tradycyjnych protokołów transferu plików, takich jak SFTP. Aplikacje niestandardowe można zaktualizować tak, aby korzystały z interfejsu API REST i zestawów SDK platformy Azure, ale tylko przez wprowadzenie znaczących zmian w kodzie.

Przed wydaniem tej funkcji, jeśli chcesz użyć sfTP do transferu danych do usługi Azure Blob Storage, musisz kupić produkt innej firmy lub zorganizować własne rozwiązanie. W przypadku rozwiązań niestandardowych należy utworzyć maszyny wirtualne na platformie Azure w celu hostowania serwera SFTP, a następnie zaktualizować, zastosować poprawki, zarządzać, skalować i obsługiwać złożoną architekturę.

Teraz dzięki obsłudze sfTP dla usługi Azure Blob Storage można włączyć obsługę sfTP dla kont usługi Blob Storage za pomocą jednego kliknięcia. Następnie można skonfigurować tożsamości użytkowników lokalnych na potrzeby uwierzytelniania w celu nawiązania połączenia z kontem magazynu przy użyciu protokołu SFTP za pośrednictwem portu 22.

W tym artykule opisano obsługę protokołu SFTP dla usługi Azure Blob Storage. Aby dowiedzieć się, jak włączyć protokół SFTP dla konta magazynu, zobacz Nawiązywanie połączenia z usługą Azure Blob Storage przy użyciu protokołu SSH File Transfer Protocol (SFTP).

Uwaga

SFTP to usługa na poziomie platformy, więc port 22 zostanie otwarty, nawet jeśli opcja konta jest wyłączona. Jeśli dostęp SFTP nie jest skonfigurowany, wszystkie żądania otrzymają rozłączenie z usługą.

SFTP i hierarchiczna przestrzeń nazw

Obsługa sfTP wymaga włączenia hierarchicznej przestrzeni nazw. Hierarchiczna przestrzeń nazw organizuje obiekty (pliki) w hierarchię katalogów i podkatalogów w taki sam sposób, w jaki system plików na komputerze jest zorganizowany. Hierarchiczna przestrzeń nazw jest skalowana liniowo i nie obniża wydajności ani pojemności danych.

Różne protokoły są obsługiwane przez hierarchiczną przestrzeń nazw. SFTP jest jednym z tych dostępnych protokołów. Na poniższej ilustracji przedstawiono dostęp do magazynu za pośrednictwem wielu protokołów i interfejsów API REST. Aby ułatwić czytanie, ten obraz używa terminu REST do odwoływania się do interfejsu API REST usługi Azure Data Lake Storage.

Model uprawnień SFTP

Nie można autoryzować klientów SFTP przy użyciu tożsamości firmy Microsoft Entra. Zamiast tego sfTP wykorzystuje nową formę zarządzania tożsamościami nazywaną użytkownikami lokalnymi.

Użytkownicy lokalni muszą użyć hasła lub poświadczenia klucza prywatnego protokołu Secure Shell (SSH) do uwierzytelniania. Dla konta magazynu można mieć maksymalnie 8000 lokalnych użytkowników.

Aby skonfigurować uprawnienia dostępu, należy utworzyć użytkownika lokalnego i wybrać metody uwierzytelniania. Następnie dla każdego kontenera na koncie możesz określić poziom dostępu, który chcesz przyznać użytkownikowi.

Uwaga

Użytkownicy lokalni nie współdziałają z innymi modelami uprawnień usługi Azure Storage, takimi jak kontrola dostępu oparta na rolach (kontrola dostępu oparta na rolach) i ABAC (kontrola dostępu oparta na atrybutach). Listy kontroli dostępu (ACL) są obsługiwane dla użytkowników lokalnych na poziomie wersji zapoznawczej.

Na przykład Jeff ma uprawnienia tylko do odczytu (można kontrolować za pośrednictwem kontroli dostępu opartej na rolach lub kontroli dostępu opartej na rolach) za pośrednictwem tożsamości Microsoft Entra dla foo.txt plików przechowywanych w kontenerze con1. Jeśli Jeff uzyskuje dostęp do konta magazynu za pośrednictwem systemu plików NFS (jeśli nie jest zainstalowany jako główny/superużytkownik), rest obiektów blob lub rest usługi Data Lake Storage, te uprawnienia zostaną wymuszone. Jeśli jednak jeff ma również tożsamość użytkownika lokalnego z uprawnieniem do usuwania danych w kontenerze con1, może usunąć foo.txt za pośrednictwem sfTP przy użyciu tożsamości użytkownika lokalnego.

Włączenie obsługi SFTP nie uniemożliwia innym typom klientów korzystania z identyfikatora Entra firmy Microsoft. W przypadku użytkowników, którzy uzyskują dostęp do usługi Blob Storage przy użyciu witryny Azure Portal, interfejsu wiersza polecenia platformy Azure, poleceń programu Azure PowerShell, narzędzia AzCopy, a także zestawów SDK platformy Azure i interfejsów API REST platformy Azure, możesz nadal używać pełnego zakresu ustawień zabezpieczeń usługi Azure Blob Storage, aby autoryzować dostęp. Aby dowiedzieć się więcej, zobacz Model kontroli dostępu w usłudze Azure Data Lake Storage.

Metody uwierzytelniania

Możesz uwierzytelnić użytkowników lokalnych łączących się za pośrednictwem protokołu SFTP przy użyciu hasła lub publicznego klucza prywatnego protokołu SSH (Secure Shell). Możesz skonfigurować zarówno formy uwierzytelniania, jak i umożliwić łączenie użytkowników lokalnych z wybranymi do użycia. Jednak uwierzytelnianie wieloskładnikowe, w którym zarówno prawidłowe hasło, jak i prawidłowa para kluczy publicznych-prywatnych są wymagane do pomyślnego uwierzytelnienia, nie jest obsługiwana.

Passwords

Nie można ustawić haseł niestandardowych, a raczej platforma Azure generuje je dla Ciebie. Jeśli wybierzesz opcję uwierzytelniania za pomocą hasła, hasło zostanie podane po zakończeniu konfigurowania użytkownika lokalnego. Pamiętaj, aby skopiować to hasło i zapisać je w lokalizacji, w której można je znaleźć później. Nie będzie można ponownie pobrać tego hasła z platformy Azure. Jeśli utracisz hasło, musisz wygenerować nowe. Ze względów bezpieczeństwa nie można ustawić hasła samodzielnie.

Pary kluczy SSH

Para kluczy publiczny-prywatny jest najczęstszą formą uwierzytelniania dla protokołu Secure Shell (SSH). Klucz prywatny jest tajny i powinien być znany tylko użytkownikowi lokalnemu. Klucz publiczny jest przechowywany na platformie Azure. Gdy klient SSH łączy się z kontem magazynu przy użyciu tożsamości użytkownika lokalnego, wysyła komunikat z kluczem publicznym i podpisem. Platforma Azure weryfikuje komunikat i sprawdza, czy użytkownik i klucz są rozpoznawane przez konto magazynu. Aby dowiedzieć się więcej, zobacz Omówienie protokołu SSH i kluczy.

Jeśli zdecydujesz się na uwierzytelnianie za pomocą pary kluczy prywatnych, możesz go wygenerować, użyć tej, która jest już przechowywana na platformie Azure, lub podać klucz publiczny istniejącej pary kluczy publicznych-prywatnych. Możesz mieć maksymalnie 10 kluczy publicznych na użytkownika lokalnego.

Uprawnienia kontenera

W przypadku uprawnień na poziomie kontenera możesz wybrać kontenery, do których chcesz udzielić dostępu, oraz jaki poziom dostępu chcesz podać (odczyt, zapis, lista, usuwanie, tworzenie, modyfikowanie własności i modyfikowanie uprawnień). Te uprawnienia dotyczą wszystkich katalogów i podkatalogów w kontenerze. Każdy użytkownik lokalny może uzyskać dostęp do 100 kontenerów. Uprawnienia kontenera można również zaktualizować po utworzeniu użytkownika lokalnego. W poniższej tabeli opisano bardziej szczegółowo każde uprawnienie.

Uprawnienie	Symbol	opis
Przeczytaj	r	Odczytywanie zawartości pliku
Write	w	Przekaż plik Tworzenie katalogu Przekazywanie katalogu
List	l	Wyświetlanie listy zawartości w kontenerze Wyświetlanie listy zawartości w katalogu
Delete	d	Usuwanie pliku/katalogu
Utworzenie	c	Przekaż plik, jeśli plik nie istnieje Utwórz katalog, jeśli katalog nie istnieje
Modyfikowanie własności	o	Zmienianie użytkownika lub grupy właścicieli pliku lub katalogu
Modyfikuj uprawnienia	p	Zmienianie listy ACL pliku lub katalogu

Podczas wykonywania operacji zapisu na obiektach blob w podkatalogach uprawnienia do odczytu są wymagane do otwierania katalogu i uzyskiwania dostępu do właściwości obiektu blob.

Listy kontroli dostępu (ACL)

Ważne

Ta funkcja jest obecnie dostępna w wersji zapoznawczej. Zobacz Dodatkowe warunki użytkowania wersji zapoznawczych platformy Microsoft Azure, aby zapoznać się z postanowieniami prawnymi dotyczącymi funkcji platformy Azure, które są w wersji beta lub wersji zapoznawczej albo w inny sposób nie zostały jeszcze wydane jako ogólnie dostępne.

Listy ACL umożliwiają udzielanie dostępu „szczegółowego”, takiego jak dostęp do zapisu do określonego katalogu lub pliku. Aby dowiedzieć się więcej na temat list ACL, zobacz Listy kontroli dostępu (ACL) w usłudze Azure Data Lake Storage.

Aby autoryzować użytkownika lokalnego przy użyciu list ACL, należy najpierw włączyć autoryzację listy ACL dla tego użytkownika lokalnego. Zobacz Przyznawanie uprawnień do kontenerów.

Uwaga

Lista ACL może definiować poziom uprawnień dla wielu różnych typów tożsamości, ale tylko użytkownik będąc właścicielem, grupa będąca właścicielem i wszystkie inne tożsamości użytkowników mogą służyć do autoryzowania użytkownika lokalnego. Nazwani użytkownicy i nazwane grupy nie są jeszcze obsługiwane w przypadku autoryzacji użytkowników lokalnych.

W poniższej tabeli opisano właściwości użytkownika lokalnego używanego do autoryzacji listy ACL.

Właściwości	opis
Identyfikator użytkownika	Unikatowy identyfikator użytkownika lokalnego na koncie magazynu Generowane domyślnie po utworzeniu użytkownika lokalnego Służy do ustawiania użytkownika będącego właścicielem pliku/katalogu
Identyfikator grupy	Identifer dla grupy użytkowników lokalnych Służy do ustawiania grupy właścicieli w pliku/katalogu
AllowAclAuthorization	Zezwalaj na autoryzowanie żądań tego użytkownika lokalnego przy użyciu list ACL

Jak są oceniane uprawnienia listy ACL

Listy ACL są oceniane tylko wtedy, gdy użytkownik lokalny nie ma niezbędnych uprawnień kontenera do wykonania operacji. Ze względu na sposób, w jaki uprawnienia dostępu są oceniane przez system, nie można użyć listy ACL, aby ograniczyć dostęp, który został już udzielony przez uprawnienia na poziomie kontenera. Dzieje się tak, ponieważ system najpierw ocenia uprawnienia kontenera, a jeśli te uprawnienia przyznają wystarczające uprawnienia dostępu, listy ACL są ignorowane.

Ważne

Aby udzielić użytkownikowi lokalnemu dostępu do odczytu lub zapisu do pliku, musisz przyznać temu użytkownikowi lokalnemu uprawnienia Wykonywanie do folderu głównego kontenera oraz do każdego folderu w hierarchii folderów, które prowadzą do pliku. Jeśli użytkownik lokalny jest właścicielem lub jest właścicielem grupy, możesz zastosować uprawnienia Wykonywanie do użytkownika lub grupy właściciela. W przeciwnym razie musisz zastosować uprawnienie Wykonywanie do wszystkich innych użytkowników.

Modyfikowanie list ACL przy użyciu klienta SFTP

Chociaż uprawnienia listy ACL można modyfikować przy użyciu dowolnego obsługiwanego narzędzia platformy Azure lub zestawu SDK, użytkownicy lokalni mogą je również modyfikować. Aby umożliwić użytkownikowi lokalnemu modyfikowanie uprawnień listy ACL, musisz najpierw nadać użytkownikowi lokalnemu Modify Permissions uprawnienia. Zobacz Przyznawanie uprawnień do kontenerów.

Użytkownicy lokalni mogą zmieniać poziom uprawnień tylko użytkownika, właściciela grupy i wszystkich innych użytkowników listy ACL. Dodawanie lub modyfikowanie wpisów listy ACL dla nazwanych użytkowników, nazwanych grup i nazwanych podmiotów zabezpieczeń nie są jeszcze obsługiwane.

Użytkownicy lokalni mogą również zmienić identyfikator użytkownika będącego właścicielem i grupę będącą właścicielem. W rzeczywistości tylko użytkownicy lokalni mogą zmienić identyfikator użytkownika będącego właścicielem lub grupę będącą właścicielem na identyfikator użytkownika lokalnego. Nie można jeszcze odwołać się do identyfikatora użytkownika lokalnego w liście ACL przy użyciu narzędzia platformy Azure lub zestawu SDK. Aby zmienić użytkownika lub grupę będącą właścicielem katalogu lub obiektu blob, użytkownik lokalny musi mieć Modify Ownership uprawnienia.

Aby wyświetlić przykłady, zobacz Modyfikowanie listy ACL pliku lub katalogu.

Katalog główny

Podczas konfigurowania uprawnień masz możliwość ustawienia katalogu macierzystego dla użytkownika lokalnego. Jeśli w żądaniu połączenia SFTP nie określono żadnego innego kontenera, katalog główny jest katalogiem, z którego użytkownik domyślnie nawiązuje połączenie. Rozważmy na przykład następujące żądanie wykonane przy użyciu protokołu Open SSH. To żądanie nie określa nazwy kontenera ani katalogu w ramach sftp polecenia .

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

Jeśli ustawisz katalog główny użytkownika na mycontainer/mydirectory, będzie on łączyć się z tym katalogiem. logfile.txt Następnie plik zostanie przekazany do mycontainer/mydirectorypliku . Jeśli nie ustawiono katalogu macierzystego, próba połączenia zakończy się niepowodzeniem. Zamiast tego połączenie użytkowników musiałoby określić kontener wraz z żądaniem, a następnie użyć poleceń SFTP, aby przejść do katalogu docelowego przed przekazaniem pliku. W poniższym przykładzie pokazano następujące kwestie:

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

Uwaga

Katalog główny jest tylko katalogiem początkowym, do którego jest umieszczony łączący się użytkownik lokalny. Użytkownicy lokalni mogą przejść do dowolnej innej ścieżki w kontenerze, z którą są połączeni, jeśli mają odpowiednie uprawnienia kontenera.

Obsługiwane algorytmy

Do bezpiecznego nawiązywania połączenia i transferu plików można używać wielu różnych klientów SFTP. Do łączenia klientów muszą być używane algorytmy określone w poniższej tabeli.

Typ	Algorytm
Klucz hosta 1	rsa-sha2-256 2 rsa-sha2-512 2 ecdsa-sha2-nistp256 ecdsa-sha2-nistp384
Wymiana kluczy	ecdh-sha2-nistp384 ecdh-sha2-nistp256 diffie-hellman-group14-sha256 diffie-hellman-group16-sha512 diffie-hellman-group-exchange-sha256
Szyfry/szyfrowanie	aes128-gcm@openssh.com aes256-gcm@openssh.com aes128-ctr aes192-ctr aes256-ctr
Integralność/MAC	hmac-sha2-256 hmac-sha2-512 hmac-sha2-256-etm@openssh.com hmac-sha2-512-etm@openssh.com
Klucz publiczny	ssh-rsa 2 rsa-sha2-256 rsa-sha2-512 ecdsa-sha2-nistp256 ecdsa-sha2-nistp384 ecdsa-sha2-nistp521

¹ Klucze hosta są publikowane tutaj. ² klucze RSA muszą mieć minimalną długość 2048 bitów.

Obsługa protokołu SFTP dla usługi Azure Blob Storage obecnie ogranicza obsługę jej algorytmów kryptograficznych na podstawie zagadnień dotyczących zabezpieczeń. Zdecydowanie zalecamy, aby klienci używali zatwierdzonych algorytmów Microsoft Security Development Lifecycle (SDL) do bezpiecznego uzyskiwania dostępu do swoich danych.

Obecnie, zgodnie z SDL zabezpieczeń firmy Microsoft, nie planujemy obsługi następujących elementów: ssh-dss, , diffie-hellman-group14-sha1diffie-hellman-group1-sha1, diffie-hellman-group-exchange-sha1, hmac-sha1, . hmac-sha1-96 Obsługa algorytmów może ulec zmianie w przyszłości.

Nawiązywanie połączenia za pomocą protokołu SFTP

Aby rozpocząć, włącz obsługę sfTP, utwórz użytkownika lokalnego i przypisz uprawnienia dla tego użytkownika lokalnego. Następnie możesz użyć dowolnego klienta SFTP, aby bezpiecznie nawiązać połączenie, a następnie przenieść pliki. Aby uzyskać szczegółowe wskazówki, zobacz Nawiązywanie połączenia z usługą Azure Blob Storage przy użyciu protokołu SSH File Transfer Protocol (SFTP).

Zagadnienia dotyczące pracy w sieci

SFTP to usługa na poziomie platformy, więc port 22 zostanie otwarty, nawet jeśli opcja konta jest wyłączona. Jeśli dostęp SFTP nie jest skonfigurowany, wszystkie żądania otrzymają rozłączenie z usługą. W przypadku korzystania z protokołu SFTP możesz ograniczyć dostęp publiczny za pośrednictwem konfiguracji zapory, sieci wirtualnej lub prywatnego punktu końcowego. Te ustawienia są wymuszane w warstwie aplikacji, co oznacza, że nie są specyficzne dla protokołu SFTP i będą miały wpływ na łączność ze wszystkimi punktami końcowymi usługi Azure Storage. Aby uzyskać więcej informacji na temat zapór i konfiguracji sieci, zobacz Konfigurowanie zapór i sieci wirtualnych usługi Azure Storage.

Uwaga

Narzędzia inspekcji, które próbują określić obsługę protokołu TLS w warstwie protokołu, mogą zwracać wersje protokołu TLS oprócz minimalnej wymaganej wersji podczas uruchamiania bezpośrednio względem punktu końcowego konta magazynu. Aby uzyskać więcej informacji, zobacz Wymuszanie minimalnej wymaganej wersji protokołu Transport Layer Security (TLS) dla żądań do konta magazynu.

Znani obsługiwani klienci

Następujący klienci mają zgodną obsługę algorytmów z protokołem SFTP dla usługi Azure Blob Storage. Zobacz Ograniczenia i znane problemy z obsługą protokołu SSH File Transfer Protocol (SFTP) dla usługi Azure Blob Storage , jeśli masz problemy z nawiązywaniem połączenia. Ta lista nie jest wyczerpująca i może ulec zmianie w czasie.

• AIX¹
• AsyncSSH 2.1.0+
• Axway
• curl 7.85.0+
• Cyberduck 7.8.2+
• edtFTPjPRO 7.0.0+
• FileZilla 3.53.0+
• Five9
• JSCH 0.1.54+
• libssh 0.9.5+
• MobaXterm v21.3
• Maverick Legacy 1.7.15+
• Moveit 12.7
• 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+
• Ruckus 6.1.2+
• Salesforce
• ssh2js 0.1.20+
• sshj 0.27.0+
• SSH.NET 2020.0.0+
• WinSCP 5.10+
• Dzień roboczy
• XFB. Brama

¹ Musi ustawić AllowPKCS12KeystoreAutoOpen opcję na no.

Ograniczenia i znane problemy

Zapoznaj się z artykułem dotyczącym ograniczeń i znanych problemów, aby uzyskać pełną listę ograniczeń i problemów z obsługą protokołu SFTP dla usługi Azure Blob Storage.

Ceny i rozliczenia

Włączenie protokołu SFTP ma koszt godzinowy. Aby uzyskać najnowsze informacje o cenach, zobacz Cennik usługi Azure Blob Storage.

Napiwek

Aby uniknąć opłat pasywnych, rozważ włączenie protokołu SFTP tylko wtedy, gdy aktywnie używasz go do transferu danych. Aby uzyskać wskazówki dotyczące włączania i wyłączania obsługi protokołu SFTP, zobacz Nawiązywanie połączenia z usługą Azure Blob Storage przy użyciu protokołu SSH File Transfer Protocol (SFTP).

Mają zastosowanie ceny transakcji, magazynu i sieci dla bazowego konta magazynu. Wszystkie transakcje SFTP są konwertowane na odczyt, zapis lub inne transakcje na kontach magazynu. Obejmuje to wszystkie polecenia SFTP i wywołania interfejsu API. Aby dowiedzieć się więcej, zobacz Omówienie pełnego modelu rozliczeń dla usługi Azure Blob Storage.

Powiązana zawartość

• Obsługa protokołu SSH File Transfer Protocol (SFTP) dla usługi Azure Blob Storage
• Włączanie lub wyłączanie obsługi protokołu SSH File Transfer Protocol (SFTP) w usłudze Azure Blob Storage
• Autoryzowanie dostępu do usługi Azure Blob Storage z poziomu klienta protokołu SSH File Transfer Protocol (SFTP)
• Nawiązywanie połączenia z usługą Azure Blob Storage przy użyciu protokołu SSH File Transfer Protocol (SFTP)
• Ograniczenia i znane problemy z obsługą protokołu SSH File Transfer Protocol (SFTP) dla usługi Azure Blob Storage
• Obsługa kluczy hosta dla protokołu SSH File Transfer Protocol (SFTP) dla usługi Azure Blob Storage
• Zagadnienia dotyczące wydajności protokołu SSH File Transfer Protocol (SFTP) w usłudze Azure Blob Storage