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 Włączanie lub wyłączanie obsługi protokołu SSH File Transfer Protocol (SFTP) w usłudze Azure Blob Storage.

Uwaga / Notatka

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że być maksymalnie 25 000 użytkowników lokalnych.

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.

Ważne

Jeśli masz jakiekolwiek opinie na temat scenariuszy wymagających autoryzacji opartej na tożsamościach Entra, skontaktuj się z nami pod adresem BlobSFTP@microsoft.com.

Ostrzeżenie

Użytkownicy lokalni nie współdziałają z innymi modelami uprawnień usługi Azure Storage, takimi jak RBAC (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 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 atrybutach) za pośrednictwem tożsamości w Microsoft Entra dla pliku foo.txt przechowywanego w kontenerze con1. Jeśli Jeff uzyskuje dostęp do konta magazynu za pośrednictwem systemu plików NFS (jeśli nie jest zamontowany jako root/superużytkownik), Blob REST lub Data Lake Storage REST, 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ć obie formy uwierzytelniania i pozwolić lokalnym użytkownikom na wybór, której chcą użyć. 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.

Hasła

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.

Pozwolenie	Symbol	Opis
Przeczytaj	r	Odczytywanie zawartości pliku
Napisz	w	Przekaż plik Tworzenie katalogu Przekazywanie katalogu
Lista	l	Wyświetlanie listy zawartości w kontenerze Wyświetlanie listy zawartości w katalogu
Usuń	d	Usuwanie pliku/katalogu
Utwórz	Bez kontekstu nie można zapewnić adekwatnego tłumaczenia litery "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)

Listy ACL pozwalają na przyznanie drobiazgowego dostępu, takiego jak dostęp do zapisu do konkretnego katalogu lub pliku. Typowym przypadkiem użycia listy ACL jest ograniczenie dostępu użytkownika do określonego katalogu bez zezwalania użytkownikowi na dostęp do innych katalogów w tym samym kontenerze. Można to powtórzyć dla wielu użytkowników, aby każdy z nich miał szczegółowy dostęp do własnego katalogu. Bez list ACL wymagałoby to kontenera dla każdego użytkownika lokalnego. Listy ACL ułatwiają również administratorom zarządzanie dostępem dla wielu użytkowników lokalnych za pomocą grup. 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 ACL, należy najpierw włączyć autoryzację ACL dla tego użytkownika lokalnego. Zobacz Udostępnij uprawnienia dla kontenerów.

Uwaga / Notatka

Chociaż lista ACL może definiować poziom uprawnień dla wielu różnych typów tożsamości, tylko użytkownik będący właścicielem, grupa będąca właścicielem oraz wszystkie inne tożsamości użytkowników mogą być użyte do autoryzacji 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, które są używane do uprawnień ACL.

Majątek	Opis
Identyfikator użytkownika	Unikatowy identyfikator użytkownika lokalnego na koncie przechowywania 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	Identyfikator 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ń do kontenera, aby wykonać operację. 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 należy do grupy właściciela, możesz zastosować uprawnienia Wykonywanie do właściciela lub grupy właściciela. W przeciwnym razie musisz zastosować uprawnienie Wykonywanie do wszystkich innych użytkowników.

Modyfikowanie list kontroli dostępu (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ń ACL, musisz najpierw nadać mu odpowiednie uprawnienia Modify Permissions. Zobacz Udostępnij uprawnienia dla kontenerów.

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

Użytkownicy lokalni mogą również zmienić identyfikator właściciela użytkownika oraz identyfikator właściciela grupy. W rzeczywistości tylko użytkownicy lokalni mogą zmienić identyfikator użytkownika lub grupy właściciela na identyfikator lokalnego użytkownika. 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ę właścicielską katalogu lub obiektu blob, użytkownik lokalny musi otrzymać 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. Następnie plik logfile.txt zostanie przekazany do mycontainer/mydirectory. Jeśli nie ustawiono katalogu macierzystego, próba połączenia zakończy się niepowodzeniem. Zamiast tego użytkownicy musieliby określić kontener wraz z żądaniem, a następnie użyć poleceń SFTP, aby przejść do katalogu docelowego i przekazać plik. 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 / Notatka

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

Aby bezpiecznie nawiązać połączenie, a następnie przesłać pliki, można użyć wielu różnych klientów SFTP. Klienci łączący się muszą używać algorytmów określonych 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ę algorytmów kryptograficznych w oparciu o zagadnienia dotyczące zabezpieczeń. Zdecydowanie zalecamy, aby klienci korzystali z zatwierdzonych algorytmów cyklu projektowania zabezpieczeń firmy Microsoft (SDL), aby bezpiecznie uzyskiwać dostęp 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 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 / Notatka

Narzędzia inspekcji, które próbują analizować obsługę protokołu TLS na poziomie warstwy protokołu, mogą zwracać wersje TLS oprócz minimalnej wymaganej wersji TLS podczas uruchamiania bezpośrednio względem punktu końcowego konta przechowywania. 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+
• Osia
• curl 7.85.0+
• Cyberduck 7.8.2+
• edtFTPjPRO 7.0.0+
• FileZilla 3.53.0+
• Pięć9
• 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.Bramka
• Apache NiFi

¹ 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.

Wskazówka

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, przechowywania i sieci dla bazowego konta przechowywania. Wszystkie transakcje SFTP są konwertowane na operacje odczytu, zapisu lub inne operacje na kontach pamięci masowej. 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.

Treści powiązane

• 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
• Włączenie kluczy hosta dla protokołu SSH File Transfer Protocol (SFTP) w usłudze Azure Blob Storage
• Zagadnienia dotyczące wydajności protokołu SSH File Transfer Protocol (SFTP) w usłudze Azure Blob Storage