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 za pośrednictwem punktu końcowego 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 protokołu SFTP dla usługi Azure Blob Storage możesz włączyć punkt końcowy 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 Połączenie do usługi 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 Gen2 REST, aby zapoznać się z interfejsem API REST usługi Azure Data Lake Storage Gen2.

Model uprawnień SFTP

Usługa Azure Blob Storage nie obsługuje uwierzytelniania ani autoryzacji firmy Microsoft za pośrednictwem protokołu SFTP. 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. Możesz mieć maksymalnie 2000 lokalnych użytkowników dla konta magazynu.

Aby skonfigurować uprawnienia dostępu, utworzysz użytkownika lokalnego i wybierzesz 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 ACL (listy kontroli dostępu) 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 Gen2, 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 przypadku kont magazynu z obsługą protokołu SFTP można użyć pełnego zakresu ustawień zabezpieczeń usługi Azure Blob Storage, aby uwierzytelnić i autoryzować użytkowników, którzy uzyskują dostęp do usługi Blob Storage za pośrednictwem witryny Azure Portal, interfejsu wiersza polecenia platformy Azure, poleceń programu Azure PowerShell, narzędzia AzCopy, a także zestawów AZURE SDK i interfejsów API REST platformy Azure. Aby dowiedzieć się więcej, zobacz Model kontroli dostępu w usłudze Azure Data Lake Storage Gen2.

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 będącą właścicielem dla pliku/katalogu
Modyfikuj uprawnienia	p	Zmienianie uprawnień dla pliku/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

W przypadku uprawnień na poziomie katalogu lub obiektu blob można zmienić właściciela użytkownika, grupę będącą właścicielem i tryb, który jest używany przez listy ACL usługi ADLS Gen2. Większość klientów SFTP uwidacznia polecenia umożliwiające zmianę tych właściwości. W poniższej tabeli opisano bardziej szczegółowo typowe polecenia.

Polecenie	Wymagane uprawnienie kontenera	opis
Chown	o	Zmiana użytkownika będącego właścicielem pliku/katalogu Musi określać identyfikator liczbowy
Chgrp	o	Zmień grupę będącą właścicielem dla pliku/katalogu Musi określać identyfikator liczbowy
chmod	p	Zmienianie uprawnień/trybu dla pliku/katalogu Musi określać uprawnienia ósemkowe stylu POSIX

Identyfikatory wymagane do zmiany użytkownika i grupy właścicieli są częścią nowych właściwości dla użytkowników lokalnych. W poniższej tabeli opisano bardziej szczegółowo każdą nową właściwość Użytkownika lokalnego.

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
Groupid	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

Po skonfigurowaniu żądanych list ACL i włączeniu AllowAclAuthorizationprzez użytkownika lokalnego listy ACL mogą używać list ACL do autoryzowania żądań. Podobnie jak w przypadku kontroli dostępu opartej na rolach, uprawnienia kontenera mogą współdziałać z listami ACL. Tylko wtedy, gdy użytkownik lokalny nie ma wystarczających uprawnień kontenera, zostaną ocenione listy ACL. Aby dowiedzieć się więcej, zobacz Model kontroli dostępu w usłudze Azure Data Lake Storage Gen2.

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.

Połączenie z 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 Połączenie do usługi Azure Blob Storage przy użyciu protokołu SFTP (SSH File Transfer Protocol).

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.

• 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+
• Dzień roboczy
• XFB. Bramy
• JSCH 0.1.54+
• curl 7.85.0+
• AIX¹
• MobaXterm v21.3

¹ 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 punktu końcowego 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 Połączenie do usługi 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.

Zobacz też

• Połączenie do usługi 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