Scenariusz kompleksowego zabezpieczeń usługi Microsoft Fabric

Zabezpieczenia są kluczowym aspektem dowolnego rozwiązania do analizy danych, zwłaszcza gdy obejmuje poufne lub poufne dane. Z tego powodu usługa Microsoft Fabric udostępnia kompleksowy zestaw funkcji zabezpieczeń, które umożliwiają ochronę danych magazynowanych i przesyłanych, a także kontrolę dostępu i uprawnień dla użytkowników i aplikacji.

W tym artykule dowiesz się więcej o pojęciach i funkcjach zabezpieczeń sieci szkieletowej, które mogą ułatwić ci pewnie tworzenie własnego rozwiązania analitycznego za pomocą usługi Fabric.

Tło

W tym artykule przedstawiono scenariusz, w którym jesteś inżynierem danych, który pracuje w organizacji opieki zdrowotnej w Stany Zjednoczone. Organizacja zbiera i analizuje dane pacjentów, które pochodzą z różnych systemów, w tym elektronicznej dokumentacji zdrowia, wyników laboratorium, roszczeń ubezpieczeniowych i urządzeń do noszenia.

Planujesz zbudować jezioro przy użyciu architektury medalionu w fabric, która składa się z trzech warstw: brązu, srebra i złota.

• Warstwa z brązu przechowuje nieprzetworzone dane pochodzące ze źródeł danych.
• Warstwa srebrna stosuje kontrole jakości danych i przekształcenia w celu przygotowania danych do analizy.
• Warstwa złota udostępnia zagregowane i wzbogacone dane na potrzeby raportowania i wizualizacji.

Chociaż niektóre źródła danych znajdują się w sieci lokalnej, inne znajdują się za zaporami i wymagają bezpiecznego, uwierzytelnioowanego dostępu. Istnieją również niektóre źródła danych zarządzane na platformie Azure, takie jak Azure SQL Database i Azure Storage. Musisz połączyć się z tymi źródłami danych platformy Azure w sposób, który nie uwidacznia danych w publicznym Internecie.

Podjęto decyzję o użyciu usługi Fabric, ponieważ może bezpiecznie pozyskiwać, przechowywać, przetwarzać i analizować dane w chmurze. Co ważne, robi to przy zachowaniu zgodności z przepisami branżowymi i zasadami organizacji.

Ponieważ sieć szkieletowa to oprogramowanie jako usługa (SaaS), nie musisz aprowizować poszczególnych zasobów, takich jak zasoby magazynu lub zasobów obliczeniowych. Wystarczy pojemność sieci szkieletowej.

Musisz skonfigurować wymagania dotyczące dostępu do danych. W szczególności musisz mieć pewność, że tylko Ty i twoi inżynierowie danych mają dostęp do danych w warstwach brązu i srebra nad jeziorem. Te warstwy to miejsce, w którym planowane jest czyszczenie danych, walidacja, transformacja i wzbogacanie. Należy również ograniczyć dostęp do danych w warstwie złota. Tylko autoryzowani użytkownicy, w tym analitycy danych i użytkownicy biznesowi, powinni mieć dostęp do warstwy złota. Wymagają one dostępu do korzystania z danych w różnych celach analitycznych, takich jak raportowanie, uczenie maszynowe i analiza predykcyjna. Dostęp do danych musi być dodatkowo ograniczony przez rolę i dział użytkownika.

Połączenie do sieci szkieletowej (ochrona ruchu przychodzącego)

Najpierw skonfiguruj ochronę ruchu przychodzącego, która dotyczy sposobu logowania się i innych użytkowników oraz dostępu do sieci szkieletowej.

Ponieważ sieć szkieletowa jest wdrażana w dzierżawie firmy Microsoft Entra, uwierzytelnianie i autoryzacja są obsługiwane przez firmę Microsoft Entra. Zaloguj się przy użyciu konta organizacji Microsoft Entra (konta służbowego). Następnie zastanów się, jak inni użytkownicy będą łączyć się z siecią szkieletową.

Dzierżawa firmy Microsoft Entra to granica zabezpieczeń tożsamości, która jest pod kontrolą działu IT. W ramach tej granicy zabezpieczeń administrowanie obiektami firmy Microsoft Entra (takimi jak konta użytkowników) i konfiguracją ustawień dotyczących całej dzierżawy są wykonywane przez administratorów IT. Podobnie jak każda usługa SaaS, sieć szkieletowa logicznie izoluje dzierżawy. Dane i zasoby w dzierżawie nigdy nie mogą być dostępne dla innych dzierżaw, chyba że jawnie je autoryzujesz.

Oto co się stanie, gdy użytkownik zaloguje się do sieci szkieletowej.

Produkt	Opis
	Użytkownik otwiera przeglądarkę (lub aplikację kliencką) i loguje się do portalu sieci szkieletowej.
	Użytkownik jest natychmiast przekierowywany do identyfikatora Entra firmy Microsoft i jest on wymagany do uwierzytelnienia. Uwierzytelnianie sprawdza, czy jest to prawidłowa osoba logując się.
	Po pomyślnym uwierzytelnieniu fronton internetowy odbiera żądanie użytkownika i dostarcza zawartość frontonu (HTML i CSS) z najbliższej lokalizacji. Kieruje również żądanie do platformy metadanych i platformy pojemności zaplecza.
	Platforma metadanych, która znajduje się w regionie głównym dzierżawy, przechowuje metadane dzierżawy, takie jak obszary robocze i mechanizmy kontroli dostępu. Ta platforma gwarantuje, że użytkownik ma autoryzację dostępu do odpowiednich obszarów roboczych i elementów sieci szkieletowej.
	Platforma pojemności zaplecza wykonuje operacje obliczeniowe i przechowuje dane. Znajduje się on w regionie pojemności. Po przypisaniu obszaru roboczego do pojemności sieci szkieletowej wszystkie dane znajdujące się w obszarze roboczym, w tym usługa Data Lake OneLake, są przechowywane i przetwarzane w regionie pojemności.

Platforma metadanych i platforma pojemności zaplecza są uruchamiane w zabezpieczonych sieciach wirtualnych. Te sieci uwidaczniają szereg bezpiecznych punktów końcowych w Internecie, dzięki czemu mogą odbierać żądania od użytkowników i innych usług. Oprócz tych punktów końcowych usługi są chronione przez reguły zabezpieczeń sieci, które blokują dostęp z publicznego Internetu.

Gdy użytkownicy logują się do sieci szkieletowej, możesz wymusić inne warstwy ochrony. W ten sposób dzierżawa jest dostępna tylko dla niektórych użytkowników , a inne warunki, takie jak lokalizacja sieciowa i zgodność urządzeń, są spełnione. Ta warstwa ochrony jest nazywana ochroną przychodzącą.

W tym scenariuszu odpowiadasz za poufne informacje o pacjentach w sieci szkieletowej. W związku z tym organizacja ma obowiązek, aby wszyscy użytkownicy uzyskujący dostęp do sieci szkieletowej musieli wykonywać uwierzytelnianie wieloskładnikowe (MFA) i że muszą znajdować się w sieci firmowej — po prostu zabezpieczanie tożsamości użytkownika nie wystarczy.

Twoja organizacja zapewnia również elastyczność użytkownikom, umożliwiając im pracę z dowolnego miejsca i korzystanie z urządzeń osobistych. Ponieważ usługa Microsoft Intune obsługuje funkcję "przynieś własne urządzenie" (BYOD), należy zarejestrować zatwierdzone urządzenia użytkowników w usłudze Intune.

Ponadto należy upewnić się, że te urządzenia są zgodne z zasadami organizacji. W szczególności te zasady wymagają, aby urządzenia mogły łączyć się tylko wtedy, gdy mają zainstalowany najnowszy system operacyjny i najnowsze poprawki zabezpieczeń. Te wymagania dotyczące zabezpieczeń są konfigurowane przy użyciu usługi Microsoft Entra Conditional Access.

Dostęp warunkowy oferuje kilka sposobów zabezpieczania dzierżawy. Masz następujące możliwości:

• Udzielanie lub blokowanie dostępu według lokalizacji sieciowej.
• Blokuj dostęp do urządzeń uruchomionych w nieobsługiwanych systemach operacyjnych.
• Wymagaj zgodnego urządzenia, urządzenia dołączonego do usługi Intune lub uwierzytelniania wieloskładnikowego dla wszystkich użytkowników.
• I więcej.

Jeśli chcesz zablokować całą dzierżawę sieci szkieletowej, możesz użyć sieci wirtualnej i zablokować publiczny dostęp do Internetu. Dostęp do sieci szkieletowej jest następnie dozwolony tylko z poziomu tej bezpiecznej sieci wirtualnej. To wymaganie jest konfigurowane przez włączenie linków prywatnych na poziomie dzierżawy dla sieci szkieletowej. Gwarantuje to, że wszystkie punkty końcowe sieci szkieletowej rozpoznają prywatny adres IP w sieci wirtualnej, w tym dostęp do wszystkich raportów usługi Power BI. (Włączenie prywatnych punktów końcowych ma wpływ na wiele elementów sieci szkieletowej, dlatego przed ich włączeniem należy dokładnie przeczytać ten artykuł ).

Bezpieczny dostęp do danych poza siecią Szkieletową (ochrona ruchu wychodzącego)

Następnie skonfigurujesz ochronę ruchu wychodzącego, która dotyczy bezpiecznego uzyskiwania dostępu do danych za zaporami lub prywatnymi punktami końcowymi.

Twoja organizacja ma niektóre źródła danych, które znajdują się w sieci lokalnej. Ponieważ te źródła danych znajdują się za zaporami, sieć szkieletowa wymaga bezpiecznego dostępu. Aby umożliwić usłudze Fabric bezpieczne łączenie się z lokalnym źródłem danych, należy zainstalować lokalną bramę danych.

Brama może służyć przez przepływy danych i potoki danych usługi Data Factory do pozyskiwania, przygotowywania i przekształcania danych lokalnych, a następnie ładowania ich do usługi OneLake za pomocą działania kopiowania. Usługa Data Factory obsługuje kompleksowy zestaw łączników, które umożliwiają łączenie się z ponad 100 różnymi magazynami danych.

Następnie utworzysz przepływy danych za pomocą dodatku Power Query, co zapewnia intuicyjne środowisko z interfejsem o niskim kodzie. Służy do pozyskiwania danych ze źródeł danych i przekształcania ich przy użyciu dowolnej z 300 przekształceń danych. Następnie utworzysz i zaaranżujesz złożony proces wyodrębniania, przekształcania i ładowania (ETL) za pomocą potoków danych. Procesy ETL mogą odświeżać przepływy danych i wykonywać wiele różnych zadań na dużą skalę, przetwarzać petabajty danych.

W tym scenariuszu masz już wiele procesów ETL. Najpierw masz kilka potoków w usłudze Azure Data Factory (ADF). Obecnie te potoki pozyskiwają dane lokalne i ładują je do magazynu typu data lake w usłudze Azure Storage przy użyciu własnego środowiska Integration Runtime. Po drugie, masz strukturę pozyskiwania danych w usłudze Azure Databricks napisaną na platformie Spark.

Teraz, gdy używasz usługi Fabric, po prostu przekierowujesz miejsce docelowe danych wyjściowych potoków usługi ADF, aby użyć łącznika usługi Lakehouse. Ponadto w przypadku struktury pozyskiwania w usłudze Azure Databricks należy użyć interfejsów API usługi OneLake, które obsługują sterownik Systemu plików w blogu platformy Azure (ABFS), aby zintegrować usługę OneLake z usługą Azure Databricks. (Można również użyć tej samej metody do zintegrowania Usługa OneLake z usługą Azure Synapse Analytics przy użyciu platformy Apache Spark).

Masz również niektóre źródła danych, które znajdują się w usłudze Azure SQL Database. Musisz połączyć się z tymi źródłami danych przy użyciu prywatnych punktów końcowych. W takim przypadku decydujesz się skonfigurować bramę danych sieci wirtualnej (VNet) i używać przepływów danych do bezpiecznego łączenia się z danymi platformy Azure i ładowania ich do sieci szkieletowej. W przypadku bram danych sieci wirtualnej nie trzeba aprowizować infrastruktury i zarządzać nią (ponieważ trzeba to zrobić w przypadku lokalnej bramy danych). Dzieje się tak, ponieważ sieć szkieletowa bezpiecznie i dynamicznie tworzy kontenery w usłudze Azure Virtual Network.

Jeśli tworzysz lub migrujesz strukturę pozyskiwania danych na platformie Spark, możesz bezpiecznie i prywatnie łączyć się ze źródłami danych na platformie Azure z poziomu notesów i zadań sieci szkieletowej za pomocą zarządzanych prywatnych punktów końcowych. Zarządzane prywatne punkty końcowe można utworzyć w obszarach roboczych usługi Fabric w celu nawiązania połączenia ze źródłami danych na platformie Azure, które zablokowały publiczny dostęp do Internetu. Obsługują prywatne punkty końcowe, takie jak Azure SQL Database i Azure Storage. Zarządzane prywatne punkty końcowe są aprowizowane i zarządzane w zarządzanej sieci wirtualnej dedykowanej obszarowi roboczemu sieci szkieletowej. W przeciwieństwie do typowych sieci wirtualnych platformy Azure zarządzane sieci wirtualne i zarządzane prywatne punkty końcowe nie zostaną znalezione w witrynie Azure Portal. Dzieje się tak, ponieważ są one w pełni zarządzane przez sieć szkieletową i znajdują się w ustawieniach obszaru roboczego.

Ponieważ masz już wiele danych przechowywanych na kontach usługi Azure Data Lake Storage (ADLS) Gen2 , musisz teraz łączyć tylko obciążenia sieci szkieletowej, takie jak Spark i Power BI. Ponadto dzięki skrótom usługi OneLake ADLS można łatwo nawiązać połączenie z istniejącymi danymi z dowolnego środowiska sieci szkieletowej, takich jak potoki integracji danych, notesy inżynierii danych i raporty usługi Power BI.

Obszary robocze sieci szkieletowej z tożsamością obszaru roboczego mogą bezpiecznie uzyskiwać dostęp do kont magazynu usługi ADLS Gen2, nawet jeśli sieć publiczna została wyłączona. Dzięki dostępowi do zaufanego obszaru roboczego jest to możliwe. Umożliwia sieci szkieletowej bezpieczne łączenie się z kontami magazynu przy użyciu sieci szkieletowej firmy Microsoft. Oznacza to, że komunikacja nie korzysta z publicznego Internetu, co pozwala wyłączyć dostęp do sieci publicznej do konta magazynu, ale nadal zezwalać niektórym obszarom roboczym sieci szkieletowej na łączenie się z nimi.

Zgodność

Chcesz używać sieci szkieletowej do bezpiecznego pozyskiwania, przechowywania, przetwarzania i analizowania danych w chmurze przy zachowaniu zgodności z przepisami branżowymi i zasadami organizacji.

Sieć szkieletowa jest częścią usług Microsoft Azure Core Services i podlega warunkom usług online firmy Microsoft i zasadom zachowania poufności informacji w przedsiębiorstwie firmy Microsoft. Certyfikaty zwykle występują po uruchomieniu produktu (ogólnie dostępne lub ogólnie dostępne), ale firma Microsoft integruje najlepsze rozwiązania dotyczące zgodności od samego początku i w całym cyklu projektowania. Takie proaktywne podejście zapewnia silną podstawę przyszłych certyfikatów, mimo że są one zgodne z ustalonymi cyklami inspekcji. Mówiąc prościej, ustalamy priorytety zgodności budynku od samego początku, nawet jeśli nastąpi później formalna certyfikacja.

Sieć szkieletowa jest zgodna z wieloma standardami branżowymi, takimi jak ISO 27001, 27017, 27018 i 27701. Sieć szkieletowa jest również zgodna ze standardem HIPAA , co ma kluczowe znaczenie dla ochrony prywatności i bezpieczeństwa danych opieki zdrowotnej. Możesz sprawdzić dodatek A i B w ofertach zgodności platformy Microsoft Azure, aby uzyskać szczegółowe informacje o tym, które usługi w chmurze znajdują się w zakresie certyfikacji. Dostęp do dokumentacji inspekcji można również uzyskać z poziomu portalu zaufania usług (STP).

Zgodność jest wspólną odpowiedzialnością. Aby zapewnić zgodność z przepisami i przepisami, dostawcy usług w chmurze i ich klienci wprowadzają wspólną odpowiedzialność w celu zapewnienia, że każdy z nich wykonuje swoją część. Rozważanie i ocenianie usług w chmurze publicznej ma kluczowe znaczenie dla zrozumienia modelu wspólnej odpowiedzialności oraz zadań związanych z zabezpieczeniami obsługiwanych przez dostawcę usług w chmurze oraz zadań, które obsługujesz.

Obsługa danych

Ponieważ masz do czynienia z poufnymi informacjami o pacjentach, musisz upewnić się, że wszystkie dane są wystarczająco chronione zarówno w spoczynku, jak i podczas przesyłania.

Szyfrowanie magazynowane zapewnia ochronę danych przechowywanych danych (magazynowanych). Ataki na dane magazynowane obejmują próby uzyskania fizycznego dostępu do sprzętu, na którym są przechowywane dane, a następnie naruszenie bezpieczeństwa danych na tym sprzęcie. Szyfrowanie magazynowane jest przeznaczone do zapobiegania osobie atakującej dostępu do niezaszyfrowanych danych przez zapewnienie, że dane są szyfrowane podczas pracy na dysku. Szyfrowanie w spoczynku jest obowiązkowym środkiem wymaganym do zapewnienia zgodności z niektórymi branżowymi standardami i przepisami, takimi jak International Organization for Standardization (ISO) i Health Insurance Portability and Accountability Act (HIPAA).

Wszystkie magazyny danych sieci Szkieletowej są szyfrowane w spoczynku przy użyciu kluczy zarządzanych przez firmę Microsoft, co zapewnia ochronę danych klienta, a także danych systemowych i metadanych. Dane nigdy nie są utrwalane w magazynie trwałym w stanie niezaszyfrowanym. Dzięki kluczom zarządzanym przez firmę Microsoft możesz korzystać z szyfrowania danych magazynowanych bez ryzyka lub kosztów niestandardowego rozwiązania do zarządzania kluczami.

Dane są również szyfrowane podczas przesyłania. Cały ruch przychodzący do punktów końcowych sieci szkieletowej z systemów klienckich wymusza co najmniej protokół Transport Layer Security (TLS) 1.2. Negocjuje również protokół TLS 1.3, jeśli jest to możliwe. Protokół TLS zapewnia silne uwierzytelnianie, prywatność wiadomości i integralność (umożliwia wykrywanie naruszenia, przechwytywania i fałszowania komunikatów), współdziałanie, elastyczność algorytmu oraz łatwość wdrażania i używania.

Oprócz szyfrowania ruch sieciowy między usługi firmy Microsoft zawsze kieruje się przez globalną sieć firmy Microsoft, która jest jedną z największych sieci szkieletowych na świecie.

Przechowywanie danych

Ponieważ masz do czynienia z danymi pacjentów, ze względów zgodności organizacja nakazała, aby dane nigdy nie opuszczały Stany Zjednoczone granic geograficznych. Główne operacje organizacji odbywają się w Nowym Jorku i siedzibie głównej w Seattle. Podczas konfigurowania usługi Power BI organizacja wybrała region Wschodnie stany USA jako region macierzysty dzierżawy. W przypadku operacji utworzono pojemność sieci szkieletowej w regionie Zachodnie stany USA, który znajduje się bliżej źródeł danych. Ponieważ usługa OneLake jest dostępna na całym świecie, obawiasz się, czy możesz spełnić zasady przechowywania danych organizacji podczas korzystania z usługi Fabric.

W usłudze Fabric dowiesz się, że możesz tworzyć pojemności multi-geo, które są pojemnościami znajdującymi się w lokalizacjach geograficznych (geograficznych) innych niż w regionie macierzysnym dzierżawy. Obszary robocze usługi Fabric są przypisywane do tych pojemności. W takim przypadku zasoby obliczeniowe i magazyn (w tym usługa OneLake i magazyn specyficzny dla środowiska) dla wszystkich elementów w obszarze roboczym znajdują się w regionie obejmującym wiele obszarów geograficznych, podczas gdy metadane dzierżawy pozostają w regionie macierzysty. Dane będą przechowywane i przetwarzane tylko w tych dwóch lokalizacjach geograficznych, co zapewnia spełnienie wymagań dotyczących przechowywania danych w organizacji.

Kontrola dostępu

Musisz mieć pewność, że tylko Ty i Twoi koledzy inżynierowie danych mają pełny dostęp do danych w warstwach brązu i srebra nad jeziorem. Te warstwy umożliwiają czyszczenie, walidację, przekształcanie i wzbogacanie danych. Musisz ograniczyć dostęp do danych w warstwie złota tylko autoryzowanym użytkownikom, takim jak analitycy danych i użytkownicy biznesowi, którzy mogą używać danych do różnych celów analitycznych, takich jak raportowanie i analiza.

Sieć szkieletowa udostępnia elastyczny model uprawnień, który umożliwia kontrolowanie dostępu do elementów i danych w obszarach roboczych. Obszar roboczy to zabezpieczana jednostka logiczna do grupowania elementów w sieci szkieletowej. Role obszaru roboczego służą do kontrolowania dostępu do elementów w obszarach roboczych. Cztery podstawowe role obszaru roboczego to:

• Administracja: Może wyświetlać, modyfikować, udostępniać i zarządzać całą zawartością w obszarze roboczym, w tym zarządzać uprawnieniami.
• Członek: może wyświetlać, modyfikować i udostępniać całą zawartość w obszarze roboczym.
• Współautor: może wyświetlać i modyfikować całą zawartość w obszarze roboczym.
• Osoba przeglądająca: może wyświetlać całą zawartość w obszarze roboczym, ale nie może jej modyfikować.

W tym scenariuszu utworzysz trzy obszary robocze, po jednym dla każdej warstwy medalonu (brązowy, srebrny i złoty). Ponieważ obszar roboczy został utworzony, użytkownik jest automatycznie przypisywany do roli Administracja.

Następnie należy dodać grupę zabezpieczeń do roli Współautor tych trzech obszarów roboczych. Ponieważ grupa zabezpieczeń obejmuje innych inżynierów jako członków, mogą tworzyć i modyfikować elementy sieci szkieletowej w tych obszarach roboczych — nie mogą jednak udostępniać żadnych elementów innym osobom. Nie mogą też udzielać dostępu innym użytkownikom.

W obszarach roboczych z brązu i srebra ty i twoi współpracownicy tworzą elementy sieci szkieletowej w celu pozyskiwania danych, przechowywania danych i przetwarzania danych. Elementy sieci szkieletowej składają się z lakehouse, potoków i notesów. W złotym obszarze roboczym utworzysz dwa magazyny typu lakehouse, wiele potoków i notesów oraz model semantyczny usługi Direct Lake, który zapewnia szybką wydajność zapytań dotyczących danych przechowywanych w jednym z magazynów typu lakehouse.

Następnie należy wziąć pod uwagę sposób, w jaki analitycy danych i użytkownicy biznesowi mogą uzyskiwać dostęp do danych, do których mogą uzyskiwać dostęp. W szczególności mogą uzyskiwać dostęp tylko do danych istotnych dla ich roli i działu.

Pierwszy magazyn lakehouse zawiera rzeczywiste dane i nie wymusza żadnych uprawnień do danych w punkcie końcowym analizy SQL. Drugi magazyn lakehouse zawiera skróty do pierwszego magazynu lakehouse i wymusza szczegółowe uprawnienia do danych w punkcie końcowym analizy SQL. Model semantyczny łączy się z pierwszym magazynem typu lakehouse. Aby wymusić odpowiednie uprawnienia danych dla użytkowników (dzięki czemu mogą uzyskiwać dostęp tylko do danych odpowiednich dla ich roli i działu), nie udostępniasz pierwszej usługi lakehouse użytkownikom. Zamiast tego udostępniasz tylko model semantyczny usługi Direct Lake i drugi magazyn typu lakehouse, który wymusza uprawnienia danych w punkcie końcowym analizy SQL.

Skonfigurowano model semantyczny tak, aby używał stałej tożsamości, a następnie zaimplementowano zabezpieczenia na poziomie wiersza w modelu semantycznym w celu wymuszania reguł modelu w celu zarządzania danymi, do których użytkownicy mogą uzyskiwać dostęp. Następnie udostępniasz tylko semantyczny model analitykom danych i użytkownikom biznesowym, ponieważ nie powinni oni uzyskiwać dostępu do innych elementów w obszarze roboczym, takich jak potoki i notesy. Na koniec udzielasz uprawnień do tworzenia modelu semantycznego, aby użytkownicy mogli tworzyć raporty usługi Power BI. W ten sposób semantyczny model staje się udostępnionym modelem semantycznym i źródłem raportów usługi Power BI.

Analitycy danych potrzebują dostępu do drugiej bazy danych w złotym obszarze roboczym. Nawiążą one połączenie z punktem końcowym analizy SQL w usłudze Lakehouse, aby napisać zapytania SQL i przeprowadzić analizę. Dlatego udostępniasz je lakehouse i zapewniasz dostęp tylko do potrzebnych obiektów (takich jak tabele, wiersze i kolumny z regułami maskowania) w punkcie końcowym analizy SQL usługi Lakehouse przy użyciu modelu zabezpieczeń SQL. Analitycy danych mogą teraz uzyskiwać dostęp tylko do danych istotnych dla ich roli i działu i nie mogą uzyskać dostępu do innych elementów w obszarze roboczym, takich jak potoki i notesy.

Typowe scenariusze zabezpieczeń

W poniższej tabeli wymieniono typowe scenariusze zabezpieczeń i narzędzia, których można użyć do ich wykonania.

Scenariusz	Narzędzia	Kierunek
Jestem deweloperem ETL i chcę załadować duże ilości danych do sieci szkieletowej na dużą skalę z wielu systemów źródłowych i tabel. Dane źródłowe są lokalne (lub inne chmury) i znajduje się za zaporami i/lub źródłami danych platformy Azure z prywatnymi punktami końcowymi.	Użyj lokalnej bramy danych z potokami danych (działanie kopiowania).	Wychodzący
Jestem użytkownikiem zasilania i chcę załadować dane do sieci szkieletowej z systemów źródłowych, do których mam dostęp. Ponieważ nie jestem deweloperem, muszę przekształcić dane przy użyciu interfejsu z małą ilością kodu. Dane źródłowe są lokalne (lub w innej chmurze) i są za zaporami.	Użyj lokalnej bramy danych z usługą Dataflow Gen 2.	Wychodzący
Jestem użytkownikiem zasilania i chcę załadować dane w sieci szkieletowej z systemów źródłowych, do których mam dostęp. Dane źródłowe są na platformie Azure za prywatnymi punktami końcowymi i nie chcę instalować i obsługiwać lokalnej infrastruktury bramy danych.	Użyj bramy danych sieci wirtualnej z przepływem danych Gen 2.	Wychodzący
Jestem deweloperem, który może pisać kod pozyskiwania danych przy użyciu notesów platformy Spark. Chcę załadować dane w sieci szkieletowej z systemów źródłowych, do których mam dostęp. Dane źródłowe są na platformie Azure za prywatnymi punktami końcowymi i nie chcę instalować i obsługiwać lokalnej infrastruktury bramy danych.	Użyj notesów sieci szkieletowej z prywatnymi punktami końcowymi platformy Azure.	Wychodzący
Mam wiele istniejących potoków w potokach usługi Azure Data Factory (ADF) i Synapse, które łączą się ze źródłami danych i ładują dane na platformę Azure. Teraz chcę zmodyfikować te potoki, aby załadować dane do sieci szkieletowej.	Użyj łącznika Lakehouse w istniejących potokach.	Wychodzący
Mam strukturę pozyskiwania danych opracowaną na platformie Spark, która łączy się z moimi źródłami danych bezpiecznie i ładuje je na platformę Azure. Korzystam z niego w usłudze Azure Databricks i/lub usłudze Synapse Spark. Chcę nadal używać usługi Azure Databricks i/lub usługi Synapse Spark, aby załadować dane do sieci szkieletowej.	Używanie interfejsu API usługi OneLake i usługi Azure Data Lake Storage (ADLS) Gen2 (sterownik systemu plików obiektów blob platformy Azure)	Wychodzący
Chcę zapewnić ochronę punktów końcowych sieci Szkieletowej przed publicznym Internetem.	Jako usługa SaaS zaplecze sieci szkieletowej jest już chronione z publicznego Internetu. Aby uzyskać większą ochronę, należy użyć zasad dostępu warunkowego firmy Microsoft dla sieci szkieletowej i/lub włączyć łącza prywatne na poziomie dzierżawy dla sieci szkieletowej i zablokować publiczny dostęp do Internetu.	Przychodzący
Chcę mieć pewność, że dostęp do sieci szkieletowej można uzyskać tylko z sieci firmowej i/lub z zgodnych urządzeń.	Użyj zasad dostępu warunkowego firmy Microsoft Entra dla sieci szkieletowej.	Przychodzący
Chcę mieć pewność, że każda osoba, która uzyskuje dostęp do sieci szkieletowej, musi wykonywać uwierzytelnianie wieloskładnikowe.	Użyj zasad dostępu warunkowego firmy Microsoft Entra dla sieci szkieletowej.	Przychodzący
Chcę zablokować całą dzierżawę sieci Szkieletowej z publicznego Internetu i zezwolić na dostęp tylko z moich sieci wirtualnych.	Włącz łącza prywatne na poziomie dzierżawy dla sieci szkieletowej i zablokuj publiczny dostęp do Internetu.	Przychodzący

Powiązana zawartość

Aby uzyskać więcej informacji na temat zabezpieczeń sieci szkieletowej, zobacz następujące zasoby.

• Zabezpieczenia w usłudze Microsoft Fabric
• Omówienie zabezpieczeń usługi OneLake
• Pojęcia i licencje usługi Microsoft Fabric
• Pytania? Spróbuj poprosić społeczność usługi Microsoft Fabric.
• Sugestie? Współtworzenie pomysłów w celu ulepszania usługi Microsoft Fabric.