Konfiguruj szyfrowanie w transporcie dla Azure Files

Ten artykuł wyjaśnia, jak wymagać i używać szyfrowania w tranzycie dla Azure Files. Każdy protokół ma własny mechanizm szyfrowania i ustawienia:

• SMB: szyfrowanie kanałów SMB 3.x. Zobacz SMB.
• NFS: szyfrowanie TLS przez pomocnika montowania AzNFS. Zobacz NFS.
• FileREST: HTTPS z TLS. Zobacz FileREST.

Przegląd szyfrowania w trakcie transmisji dla każdego protokołu można znaleźć w Azure Files — zagadnienia dotyczące sieci. W przypadku udziałów plików Microsoft.FileShares wymóg szyfrowania podczas przesyłania ustawiasz dla każdego udziału plików. Zobacz Utwórz udostępnienie plików oraz Zmodyfikuj udostępnienie plików. Microsoft. FileShares nie obsługuje FileREST.

Ustawienia szyfrowania podczas przesyłania

Klasyczne udostępnienia plików mają osobne ustawienie szyfrowania w transporcie dla każdego protokołu. Wymagany był bezpieczny transfer jako pierwotne ustawienie dla wszystkich trzech protokołów. Dla kompatybilności wstecznej nadal określa szyfrowanie SMB i NFS, dopóki nie skonfigurujesz ustawienia dla danego protokołu.

Ustawienia SMB i NFS zaczynają się od Niewybrane dla:

• Istniejące konta magazynu.
• Konta pamięci masowej utworzone za pomocą Azure PowerShell, Azure CLI lub API REST dostawcy zasobów Azure Storage.

Dla kont pamięci masowej utworzonych za pomocą portalu Azure oba ustawienia są domyślnie włączone.

Po skonfigurowaniu ustawień SMB lub NFS mają one pierwszeństwo przed opcją Secure transfer required dla danego protokołu. Możesz zmienić ustawienie z Włączone na Wyłączone, ale nie możesz przywrócić go do Nie wybrano.

SMB

Azure Files szyfruje ruch SMB za pomocą szyfrowania kanałowego SMB 3.x. Ustawienie Require Encryption in Transit for SMB reguluje, czy usługa Azure Files wymaga szyfrowania dla dostępu SMB do udziałów plików na koncie magazynu. Gdy to ustawienie jest włączone, Azure Files pozwala tylko na montowania SMB 3.x, które używają szyfrowania kanału. Azure Files odrzuca mounty od klientów, które nie obsługują SMB 3.x z szyfrowaniem kanałów. SMB 2.1 nie obsługuje szyfrowania, więc Azure Files odrzuca wszystkie mounty SMB 2.1. Aby poznać wartość domyślną i sposób działania tego ustawienia przy opcji Wymagany bezpieczny transfer, zobacz Ustawienia szyfrowania podczas przesyłania.

Aby poznać obsługiwane algorytmy szyfrowania kanałów SMB oraz inne ustawienia bezpieczeństwa SMB, zobacz ustawienia bezpieczeństwa SMB.

$params = @{
    ResourceGroupName = "<resource-group>"
    StorageAccountName = "<storage-account-name>"
    SmbEncryptionInTransitRequired = $true
}
Update-AzStorageFileServiceProperty @params

az storage account file-service-properties update \
    --resource-group <resource-group> \
    --account-name <storage-account-name> \
    --require-smb-encryption-in-transit true

NFS

Udziały plików Azure Files NFSv4.1 obsługują szyfrowanie podczas przesyłania przez tunel TLS. TLS chroni dane w trakcie przesyłania przed przechwyceniem, w tym przed atakami typu man-in-the-middle. Aby zainstalować pomocnika montowania AzNFS i zamontować udostępnienie plików z szyfrowaniem w trakcie transportu, zobacz Mount NFS Azure file shares na Linuksie.

Jak działa szyfrowanie podczas transportu

Azure Files używa stunnel, otwartoźródłowego wrappera TLS, do szyfrowania połączenia TCP między klientem NFS a Azure Files. Za pomocą pomocnika montowania AzNFS połączenie korzysta z protokołu TLS 1.2 lub TLS 1.3 z szyfrowaniem AES-256-GCM. Nie potrzebujesz Kerberosa ani zewnętrznego systemu uwierzytelniania, takiego jak Active Directory.

Pakiet pomocniczy do montowania AzNFS instaluje i konfiguruje stunnel na kliencie. AzNFS jest dostępny na packages.microsoft.com. Tworzy lokalny punkt końcowy, który przekazuje żądania klienta NFS przez zaszyfrowane połączenie. AzNFS składa się z następujących komponentów:

• Pomocnik montażu AzNFS: Montuje udziały plików NFSv4.1 przez tunel TLS.

• Proces stunnel: Jeden proces dla każdego konta magazynu. Nasłuchuje ruchu klienta NFS na lokalnym porcie i przekazuje go przez TLS do Azure Files.

• AzNFS watchdog: Usługa tła, która utrzymuje procesy stunnel działające, restartuje zakończone tunele i usuwa nieużywane procesy po odmontowaniu wszystkich powiązanych montów NFS.

Wymuszanie szyfrowania podczas przesyłania

Ustawienie Require Encryption in Transit for NFS decyduje, czy Azure Files wymaga szyfrowania dla dostępu NFS do udziałów plików w kontach magazynu. Aby umożliwić zarówno montaż TLS, jak i nie-TLS na tym samym koncie pamięci, wyłącz to ustawienie. Aby poznać wartość domyślną i sposób działania tego ustawienia przy opcji Wymagany bezpieczny transfer, zobacz Ustawienia szyfrowania podczas przesyłania.

$params = @{
    ResourceGroupName = "<resource-group>"
    StorageAccountName = "<storage-account-name>"
    NfsEncryptionInTransitRequired = $true
}
Update-AzStorageFileServiceProperty @params

az storage account file-service-properties update \
    --resource-group <resource-group> \
    --account-name <storage-account-name> \
    --require-nfs-encryption-in-transit true

FileREST

Żądania FileREST wykorzystują HTTPS do szyfrowania danych podczas transportu. Dwa ustawienia konta magazynu kontrolują szyfrowanie FileREST dla klasycznych udziałów plików:

• Wymagany bezpieczny transfer: Gdy to ustawienie jest włączone, konto pamięci masowej odrzuca żądania FileREST przesyłane przez HTTP. Nowe konta magazynu mają domyślnie włączone to ustawienie. Pozostaw włączone. Opcja wyłączenia tego istnieje ze względu na kompatybilność wsteczną ze starszymi aplikacjami, które używają protokołu HTTP do uzyskiwania dostępu do innych danych na koncie magazynu. Zanim pojawiły się ustawienia SMB i NFS, wyłączenie opcji Wymagaj bezpiecznego transferu było również jedynym sposobem na umożliwienie nieszyfrowanego dostępu SMB lub NFS. Aby teraz umożliwić nieszyfrowany dostęp SMB lub NFS, wyłącz ustawienie dla tego protokołu. Zobacz Ustawienia szyfrowania podczas przesyłania.
• Minimalna wersja TLS: Azure Files akceptuje TLS 1.2 i TLS 1.3 dla HTTPS. Azure Storage nie akceptuje już TLS 1.0 ani TLS 1.1 dla żądań HTTPS, więc TLS 1.2 to najniższa minimalna wersja, jaką możesz ustawić. Nie możesz ustawić TLS 1.3 jako minimum. Żądanie FileREST używające wcześniejszej wersji TLS niż minimum kończy się niepowodzeniem z kodem statusowym HTTP 400 (Bad Request). Klienci negocjują TLS 1.3, gdy go obsługują.

Azure Policy posiada wbudowane definicje polityk, które audytują lub wymagają tych ustawień dla kont pamięci masowej. Zobacz sekcję Storage w definicjach wbudowanych polityk Azure Policy.

Obecne wersje bibliotek klientów Azure Storage, Azure PowerShell i Azure CLI, korzystają z TLS 1.2 lub nowszego. Jeśli aplikacja celująca w starszą wersję .NET Framework nie może się połączyć, zobacz najlepsze praktyki Transport Layer Security (TLS) w .NET Framework.

Konfiguruj ustawienia szyfrowania FileREST

Poniższe kroki wymagają bezpiecznego transferu i ustawienia minimalnej wersji TLS na TLS 1.2 dla konta magazynowego.

$params = @{
    ResourceGroupName = "<resource-group>"
    Name = "<storage-account-name>"
    EnableHttpsTrafficOnly = $true
    MinimumTlsVersion = "TLS1_2"
}
Set-AzStorageAccount @params

az storage account update \
    --resource-group <resource-group> \
    --name <storage-account-name> \
    --https-only true \
    --min-tls-version TLS1_2

Treści powiązane

• Zagadnienia dotyczące sieci usługi Azure Files
• Szyfrowanie danych w spoczynku dla usługi Azure Files