Ochrona dostępu wychodzącego obszaru roboczego dla obciążeń inżynieryjnych danych

Ochrona dostępu wychodzącego obszaru roboczego umożliwia precyzyjną kontrolę nad komunikacją zewnętrzną z obszarów roboczych usługi Microsoft Fabric. Po włączeniu tej funkcji elementy obszaru roboczego inżynierii danych, takie jak notesy, definicje zadań platformy Spark i magazyny typu lakehouse, są ograniczone do nawiązywania połączeń wychodzących z publicznymi punktami końcowymi, chyba że dostęp jest jawnie udzielany za pośrednictwem zatwierdzonych zarządzanych prywatnych punktów końcowych. Ta funkcja ma kluczowe znaczenie dla organizacji w bezpiecznych lub regulowanych środowiskach, ponieważ pomaga zapobiegać eksfiltracji danych i wymuszać granice sieci organizacji.

Omówienie ochrony dostępu wychodzącego za pomocą inżynierii danych

Po włączeniu ochrony dostępu wychodzącego wszystkie połączenia wychodzące z obszaru roboczego są domyślnie blokowane. Administratorzy obszaru roboczego mogą następnie tworzyć wyjątki w celu udzielenia dostępu tylko do zatwierdzonych miejsc docelowych, konfigurując zarządzane prywatne punkty końcowe:

Konfigurowanie ochrony dostępu wychodzącego na potrzeby inżynierii danych

Aby skonfigurować ochronę dostępu wychodzącego na potrzeby inżynierii danych:

1. Wykonaj kroki, aby włączyć ochronę dostępu wychodzącego.

2. Po włączeniu ochrony dostępu wychodzącego można skonfigurować zarządzane prywatne punkty końcowe , aby zezwolić na dostęp wychodzący do innych obszarów roboczych lub zasobów zewnętrznych zgodnie z potrzebami.

Po skonfigurowaniu elementy inżynierii danych mogą łączyć się tylko z zatwierdzonymi zarządzanymi prywatnymi punktami końcowymi, podczas gdy wszystkie inne połączenia wychodzące pozostają zablokowane.

Obsługiwane typy elementów inżynierii danych

Następujące typy elementów inżynierii danych są obsługiwane z ochroną dostępu wychodzącego:

• Domy nad jeziorem
• Notebooks
• Definicje zadań platformy Spark
• Środowiska

W poniższych sekcjach opisano, jak ochrona dostępu wychodzącego wpływa na określone typy elementów inżynierii danych w obszarze roboczym.

Notebooks

Gdy ochrona dostępu wychodzącego jest włączona w obszarze roboczym, notesy mogą odwoływać się do miejsca docelowego tylko wtedy, gdy zarządzany prywatny punkt końcowy jest skonfigurowany z obszaru roboczego do miejsca docelowego.

Zrozumienie zachowania ścieżki pliku w notesach Fabric

Podczas uzyskiwania dostępu do danych w usłudze Lakehouse z poziomu notesu usługi Fabric można odwoływać się do plików przy użyciu ścieżek względnych lub w pełni kwalifikowanych (bezwzględnych). Zrozumienie różnic jest ważne w przypadku pomyślnego dostępu do danych, zwłaszcza podczas pracy w różnych obszarach roboczych.

Ścieżki względne

Ścieżki względne to najprostszy i najbardziej typowy sposób odwołwania się do plików w bieżącej usłudze Lakehouse. Podczas przeciągania i upuszczania pliku z eksploratora Lakehouse do komórki notebooka automatycznie używana jest ścieżka względna.

Example:
Files/people.csv

Kod Spark:

df = spark.read.format("csv").option("header", "true").load("Files/people.csv")

Ścieżki względne działają od razu i nie wymagają dalszej konfiguracji.

Ścieżki w pełni kwalifikowane (absolutne)

W pełni kwalifikowane ścieżki określają pełną lokalizację pliku, w tym informacje o obszarze roboczym i usłudze Lakehouse. Jednak użycie nazw wyświetlanych w tych ścieżkach może spowodować błędy, takie jak przekroczenia limitu czasu gniazda, ponieważ sesja platformy Spark nie może ich rozpoznać domyślnie.

Niepoprawny przykład (zakończy się niepowodzeniem):
abfss://your_workspace@onelake.dfs.fabric.microsoft.com/your_lakehouse.Lakehouse/Files/people.csv

Uzyskiwanie dostępu do danych między obszarami roboczymi

Aby uzyskać dostęp do plików w usłudze Lakehouse znajdującej się w innym obszarze roboczym, użyj w pełni kwalifikowanej ścieżki zawierającej identyfikator obszaru roboczego i identyfikator usługi Lakehouse (a nie ich nazwy wyświetlane). Dzięki temu platforma Spark może rozpoznać ścieżkę i uzyskać dostęp do danych.

Poprawny format identyfikatora URI:
abfss://<workspace_id>@onelake.dfs.fabric.microsoft.com/<lakehouse_id>/Files/people.csv

Przykładowy kod platformy Spark:

df = spark.read.format("csv").option("header", "true").load("abfss://4c8efb42-7d2a-4a87-b1b1-e7e98bea053d@onelake.dfs.fabric.microsoft.com/5a0ffa3d-80b9-49ce-acd2-2c9302cce6b8/Files/people.csv")

Jak znaleźć identyfikatory obszarów roboczych i Lakehouse

• Identyfikator obszaru roboczego: Identyfikator GUID po /groups/ w adresie URL obszaru roboczego usługi Fabric.
• Identyfikator usługi Lakehouse: Identyfikator GUID po /lakehouses/ w adresie URL.

Przykładowy adres URL:
https://app.fabric.microsoft.com/groups/4c8efb42-7d2a-4a87-b1b1-e7e98bea053d/lakehouses/5a0ffa3d-80b9-49ce-acd2-2c9302cce6b8/...

Zadania platformy Spark

Przy włączeniu ochrony dostępu wychodzącego dla przestrzeni roboczej, klastry Spark są chronione przed nawiązywaniem połączeń wychodzących do publicznego Internetu. Obejmuje to:

• Instalowanie pakietów języka Python bezpośrednio z interfejsu PyPI przy użyciu polecenia pip install
• Uzyskiwanie dostępu do domen publicznych, takich jak https://login.microsoftonline.com
• Nawiązywanie połączenia z dowolnymi zewnętrznymi interfejsami API lub witrynami internetowymi

Usługa Microsoft Fabric wymusza to ograniczenie za pomocą Managed Virtual Networks (zarządzanych sieci wirtualnych), które odizolowują klastry Spark od sieci zewnętrznych, o ile nie udzielono uprzednio jawnego dostępu.

Zabezpieczanie łączności za pomocą zarządzanych prywatnych punktów końcowych

Aby umożliwić klastrom Spark łączenie się z zasobami zewnętrznymi przy zachowaniu zabezpieczeń, należy użyć zarządzanych prywatnych punktów końcowych. Te punkty końcowe umożliwiają bezpieczne, zatwierdzone połączenia z:

• Usługi zewnętrzne (na przykład Azure SQL Database, Azure Blob Storage)
• Inne obszary robocze sieci szkieletowej w ramach tej samej dzierżawy

Dozwolone są tylko połączenia ustanowione za pośrednictwem zatwierdzonych zarządzanych prywatnych punktów końcowych. Wszystkie inne próby dostępu wychodzącego są domyślnie blokowane.

Bezpieczne instalowanie bibliotek w obszarach roboczych chronionych dostępem wychodzącym

Ponieważ sieć szkieletowa blokuje publiczny ruch internetowy, klastry Spark nie mogą bezpośrednio instalować pakietów z interfejsu PyPI przy użyciu polecenia pip install.

Dostępne są dwie bezpieczne opcje instalowania bibliotek w obszarze roboczym z włączoną ochroną dostępu wychodzącego:

1. Przekazywanie i używanie plików wheel: Ręcznie przygotuj wymagane pliki koła pakietów języka Python w zaufanym zasobie obliczeniowym, a następnie przekaż je do środowiska sieci szkieletowej. Ta metoda zapewnia zainstalowanie tylko zatwierdzonych pakietów i uniknięcie publicznego dostępu do Internetu.

2. Hostowanie prywatnego dublowania PyPI: Skonfiguruj prywatne repozytorium PyPI w usłudze Azure Storage i zsynchronizuj je z wybranymi pakietami z publicznego indeksu PyPI. Skonfiguruj środowisko sieci szkieletowej, aby instalować pakiety z tego prywatnego dublowania przy użyciu zarządzanych prywatnych punktów końcowych, zachowując zgodność z zasadami zabezpieczeń sieci.

Wybierz podejście, które najlepiej odpowiada wymaganiom organizacji w zakresie zarządzania pakietami i zabezpieczeń.

Opcja 1. Przekazywanie i używanie plików wheel

1. Zidentyfikuj brakujące pakiety nieuwzględnione w środowisku uruchomieniowym spark sieci szkieletowej.

2. Uruchom następujący skrypt na zasobie obliczeniowym, aby skonfigurować lokalne środowisko języka Python, które jest takie samo jak środowisko uruchomieniowe platformy Microsoft Fabric Spark 1.3. Ten skrypt wymaga pliku YAML zawierającego listę wszystkich bibliotek zawartych w środowisku prebaked.

3. Upewnij się, że biblioteki prywatne hostowane przez firmę Microsoft zostały usunięte z tego kodu YAML.

   wget https://repo.anaconda.com/miniconda/Miniconda3-py310_24.1.2-0-Linux-x86_64.sh 
   bash Miniconda3-py310_24.1.2-0-Linux-x86_64.sh 
   chmod 755 -R /usr/lib/miniforge3/ 
   export PATH="/usr/lib/miniforge3/bin:$PATH" 
   sudo apt-get update 
   sudo apt-get -yq install gcc g++ 
   conda env create -n <custom-env-name> -f Python<version>-CPU.yml 
   source activate <custom-env-name> 
   

4. Skrypt może służyć do przekazywania pliku requirements.txt zawierającego wszystkie pakiety i wersje, które mają zostać zainstalowane w środowisku uruchomieniowym platformy Spark. Drukuje nazwy nowych plików/zależności koła dla wymagań dotyczących biblioteki wejściowej.

   pip install -r <input-user-req.txt> > pip_output.txt 
   cat pip_output.txt | grep "Using cached *" 
   

5. Ręczne pobieranie .whl plików.

6. Użyj artefaktu środowiska, aby przekazać wszystkie wymagane koła.

7. Dołączanie środowiska do notesów lub zadań.

Opcja 2. Hostowanie prywatnego dublowania PyPI w usłudze Azure Storage

Wymagania wstępne

• Zasoby obliczeniowe, takie jak maszyna dewelopercza z systemem Linux, podsystem Windows dla systemu Linux (WSL) lub maszyna wirtualna platformy Azure.
  • Przykład: Szybki start — tworzenie maszyny wirtualnej z systemem Linux w witrynie Azure Portal — Azure Virtual Machines.
• Konto usługi Azure Storage do przechowywania dublowanych pakietów.
  • Tworzenie konta magazynu — Azure Storage.
• Narzędzia:
  • Bandersnatch: narzędzie do dublowania PyPI na potrzeby synchronizacji repozytorium. Zobacz dokumentację Bandersnatch.
  • Interfejs wiersza polecenia platformy Azure, Blobfuse2 lub AzCopy: narzędzia do przekazywania i synchronizowania plików z usługą Azure Storage.

Początkowa synchronizacja repozytorium PyPI

W ramach początkowego kroku należy przeprowadzić synchronizację repozytorium PyPI. Pełne repozytorium PyPI zawiera dużą liczbę pakietów i stale rozwija się, więc początkowe pobieranie może potrwać od 8 do 48 godzin, w zależności od sprzętu i sieci. Aby uzyskać informacje o bieżącym rozmiarze repozytorium i liczbie pakietów, zobacz Statystyki · PyPI.

Maintenance

Okresowe monitorowanie i aktualizacje są wymagane do zachowania synchronizacji dublowania. Następujące czynniki wpływają na szybkość synchronizacji:

• Szybkość sieci.
• Zasoby serwera, takie jak procesor CPU, pamięć i we/wy dysku na zasobie obliczeniowym z systemem Bandersnatch.
• Szybkość dysku (SSD a HDD) wpływa na szybkość zapisywania danych przez Bandersnatch.
• Początkowa konfiguracja i synchronizacja konserwacji: początkowa synchronizacja pobiera całe repozytorium i może potrwać od 8 do 48 godzin, ale kolejne synchronizacje są szybsze, ponieważ aktualizują tylko nowe lub zmienione pakiety.

Kroki konfiguracji

1. Konfigurowanie maszyny deweloperskiej z systemem Linux lub podsystemu Windows dla systemu Linux (WSL).

   wget https://repo.anaconda.com/miniconda/Miniconda3-py310_24.1.2-0-Linux-x86_64.sh 
   bash Miniconda3-py310_24.1.2-0-Linux-x86_64.sh 
   chmod 755 -R /usr/lib/miniforge3/ 
   
   # Add Python executable to PATH 
   export PATH="/usr/lib/miniforge3/bin:$PATH" 
   

2. Zainstaluj aplikację Bandersnatch w celu dublowania interfejsu PyPI. Bandersnatch to narzędzie do dublowania PyPI, które pobiera całe repozytorium PyPI i skojarzone pliki indeksów w lokalnym systemie plików.

   # Install Bandersnatch 
   pip install bandersnatch
   

3. Konfigurowanie bandersnatch: utwórz plik bandersnatch.conf z konfiguracjami określonymi w przykładzie w witrynie GitHub pod adresem bandersnatch/src/bandersnatch/example.conf.

4. Wykonaj polecenie dublowania, aby wykonać jednorazową synchronizację z serwerem podstawowym PyPI.

   bandersnatch --config <path-to-bandersnatch.conf> mirror

   To polecenie tworzy następujące podkatalogi w katalogu dublowania w lokalnym systemie plików.

   Uwaga / Notatka

   Początkowa synchronizacja zajmuje trochę czasu (zobacz Statystyki · PyPI). Bandersnatch obsługuje również selektywne dublowanie przy użyciu wtyczek listy dozwolonych i zablokowanych, co umożliwia bardziej wydajne zarządzanie zależnościami. Filtrując niepotrzebne pakiety, można zmniejszyć rozmiar dublowania, minimalizując zarówno koszty, jak i konserwację. Jeśli na przykład dublowanie jest przeznaczone wyłącznie dla sieci szkieletowej, można wykluczyć pliki binarne systemu Windows w celu zoptymalizowania magazynu. Zalecamy ocenę tych opcji filtrowania na podstawie twojego przypadku użycia.

   Zobacz też dokumentację Filtrowanie lustrzane — Bandersnatch.

5. Aby zweryfikować konfigurację dublowania, możesz użyć serwera HTTP do obsługi lokalnego dublowania PyPI. To polecenie uruchamia prosty serwer HTTP na porcie 8000, który obsługuje zawartość katalogu dublowanego:

   cd <directory-to-mirror>
   python -m http.server 8000
   

6. Skonfiguruj narzędzie do korzystania z lokalnego dublowania PyPI:

   pip install <package> -index-url http://localhost:8000/simple 
   

7. Przekaż dublowanie na konto magazynu i wybierz pozycję Włącz statyczną witrynę internetową na koncie usługi Azure Storage. To ustawienie umożliwia hostowanie zawartości statycznej, takiej jak PyPI, strona indeksu. Włączenie tego ustawienia powoduje automatyczne wygenerowanie kontenera o nazwie $web.

   Możesz użyć interfejsu wiersza polecenia platformy Azure lub narzędzia AzCopy programu blobfuse2, aby przekazać lokalne dublowanie z maszyny deweloperów do konta usługi Azure Storage.

   • Przekaż folder packages do wybranego kontenera w kontenerze konta magazynu.
   • Przekaż proste foldery PyPI, local-stats i JSON, aby $web kontener konta magazynu.

8. Aby użyć tego dublowania w elemencie środowiska sieci Szkieletowej, utwórz dwa zarządzane prywatne punkty końcowe w sieci szkieletowej:

   • Jeden dla kontenera obiektów blob (pakietów)
   • Jedna dla statycznej witryny internetowej (indeks)

9. Użyj artefaktu środowiska, aby określić plik yml do zainstalowania zarządzania biblioteką w środowiskach sieci szkieletowej.

   dependencies: 
     - pip 
     - pip: 
       - pytest==8.2.2 
       - --index-url https://<storage-account-name>.z5.web.core.windows.net/simple 
   

10. Możesz też zainstalować pakiety bezpośrednio w notesie %pip install przy użyciu polecenia :

   %pip install pytest --index-url https://<storage-account-name>.z5.web.core.windows.net/simple

Schematy usługi Lakehouse i ochrona dostępu wychodzącego

Usługi Lakehouse korzystające ze schematów są w pełni obsługiwane w przypadku uzyskiwania dostępu z elementów w tym samym obszarze roboczym, w tym w przypadku włączenia ochrony dostępu wychodzącego.

W scenariuszach dostępu między obszarami roboczymi zachowanie różni się w zależności od sposobu uzyskiwania dostępu do usługi Lakehouse w przypadku włączenia ochrony dostępu wychodzącego w obszarze roboczym zużywanym.

Obsługiwane scenariusze

• Elementy producenta i konsumenta znajdują się w tym samym obszarze roboczym
• Usługa Lakehouse używa schematów
• Dostęp jest wykonywany przy użyciu interfejsów API opartych na ramce danych platformy Spark

W tych scenariuszach operacje schematu Lakehouse funkcjonują zgodnie z oczekiwaniami.

Zachowanie między obszarami roboczymi z włączoną ochroną dostępu wychodzącego

Gdy w obszarze roboczym zostanie włączona ochrona dostępu wychodzącego, a dostęp do Lakehouse z obsługą schematu jest realizowany z innego obszaru roboczego, stosują się następujące zasady:

• ✅ Dostęp przy użyciu interfejsów API DataFrame platformy Spark (na przykład czytanie tabel do DataFrame) nadal funkcjonuje
• ❌ Dostęp przy użyciu instrukcji Spark SQL może zakończyć się niepowodzeniem.

Na przykład spark.read.table() działa poprawnie, podczas gdy SELECT * FROM table może nie działać w scenariuszach między obszarami roboczymi, gdy zabezpieczenie dostępu wychodzącego jest włączone.

Opis zachowania ścieżek plików

Podczas pracy z danymi w usłudze Lakehouse przy użyciu notesu usługi Fabric można odwoływać się do plików na dwa podstawowe sposoby:

• Jeśli obszar roboczy ma włączoną ochronę dostępu wychodzącego, używa zarządzanych sieci wirtualnych (VNETs) dla platformy Spark. W takim przypadku pule startowe są wyłączone i należy oczekiwać, że rozpoczęcie sesji platformy Spark potrwa od 3 do 5 minut.

• W przypadku ochrony dostępu wychodzącego cały dostęp publiczny z platformy Spark jest zablokowany. To ograniczenie uniemożliwia użytkownikom pobieranie bibliotek bezpośrednio z publicznych kanałów, takich jak PyPI przy użyciu narzędzia. Aby zainstalować biblioteki dla zadań inżynierii danych, użytkownicy mają dwie opcje (aby uzyskać szczegółowe informacje, zobacz Instalowanie bibliotek bezpiecznie w obszarach roboczych chronionych dostępem wychodzącym):

  • Pakiety bibliotek referencyjnych ze źródła danych połączone z obszarem roboczym Fabric za pośrednictwem zarządzanego prywatnego punktu końcowego.

  • Przekaż pliki wheel dla wymaganych bibliotek i zależności (które nie są jeszcze uwzględnione w środowisku uruchomieniowym prebaked).

• Włączenie ochrony dostępu wychodzącego blokuje cały dostęp publiczny z obszaru roboczego. W związku z tym, aby wykonać zapytanie względem usługi Lakehouse z innego obszaru roboczego, należy utworzyć prywatny prywatny punkt końcowy zarządzany przez wiele obszarów roboczych, aby umożliwić zadań platformy Spark nawiązanie połączenia.

• Użycie w pełni kwalifikowanych ścieżek z nazwami obszarów roboczych i lakehouse może spowodować wyjątek "socket timeout". Aby uzyskać dostęp do plików, użyj ścieżek względnych dla bieżącego Lakehouse lub użyj w pełni kwalifikowanej ścieżki zawierającej identyfikator obszaru roboczego i identyfikator Lakehouse (a nie ich nazwy wyświetlane). Takie podejście gwarantuje, że sesja Spark może poprawnie rozpoznać ścieżkę i uniknąć błędów przekroczenia limitu czasu połączenia. Dowiedz się więcej.

Treści powiązane

• Omówienie ochrony dostępu wychodzącego obszaru roboczego
• Konfigurowanie ochrony dostępu wychodzącego obszaru roboczego