Udostępnij za pośrednictwem


Jak zabezpieczyć jezioro dla zespołów Magazyn danych

Wprowadzenie

W tym artykule przedstawiono omówienie sposobu konfigurowania zabezpieczeń dla usługi Lakehouse w usłudze Fabric do użytku z użytkownikami sql z zapytaniami języka T-SQL. Ci użytkownicy mogą być analitykami biznesowymi korzystającymi z danych za pośrednictwem języka SQL, konstruktorów raportów lub inżynierów danych tworzących nowe tabele i widoki.

Funkcje zabezpieczeń

Usługa Microsoft Fabric używa wielowarstwowego modelu zabezpieczeń z różnymi mechanizmami kontroli dostępnymi na różnych poziomach, aby zapewnić tylko minimalne wymagane uprawnienia. Aby uzyskać więcej informacji na temat różnych funkcji zabezpieczeń dostępnych w sieci szkieletowej, zobacz Model kontroli dostępu do danych w usłudze OneLake.

W obciążeniu usługi Synapse Data Warehouse elementy punktu końcowego magazynu i analizy SQL umożliwiają również definiowanie natywnych zabezpieczeń SQL. Zabezpieczenia SQL korzystają z pełnej biblioteki konstrukcji zabezpieczeń języka T-SQL, aby umożliwić szczegółową kontrolę dostępu do tabel, widoków, wierszy i kolumn w elemencie. Aby uzyskać więcej informacji na temat zabezpieczeń SQL, zobacz Szczegółowe uprawnienia sql.

Uprawnienia SQL skonfigurowane w magazynie lub punkcie końcowym analizy SQL dotyczą tylko zapytań wykonywanych względem magazynu lub punktu końcowego analizy SQL. Dane bazowe są przechowywane w usłudze OneLake, ale dostęp do danych OneLake jest kontrolowany oddzielnie za pomocą ról dostępu do danych usługi OneLake. Aby upewnić się, że użytkownicy z uprawnieniami specyficznymi dla języka SQL nie widzą danych, do których nie mają dostępu SQL, nie dołączają tych użytkowników do roli dostępu do danych usługi OneLake.

Zabezpieczanie według przypadku użycia

Zabezpieczenia w usłudze Microsoft Fabric są zoptymalizowane pod kątem zabezpieczania danych pod kątem określonych przypadków użycia. Przypadek użycia to zestaw użytkowników wymagających określonego dostępu i uzyskiwania dostępu do danych za pośrednictwem danego aparatu. W przypadku scenariuszy SQL niektóre typowe przypadki użycia to:

  • Autorzy sql: użytkownicy, którzy muszą tworzyć nowe tabele, wyświetlać lub zapisywać dane w istniejących tabelach.
  • Czytelnicy SQL: użytkownicy, którzy muszą odczytywać dane przy użyciu zapytań SQL. Mogą one uzyskiwać dostęp do połączenia SQL bezpośrednio lub za pośrednictwem innej usługi, takiej jak Power BI.

Następnie możemy wyrównać każdy przypadek użycia z niezbędnymi uprawnieniami w sieci szkieletowej.

Dostęp do zapisu SQL

Istnieją dwa sposoby udzielenia użytkownikowi dostępu do zapisu do magazynu lub punktu końcowego analizy SQL:

  • Za pomocą ról obszaru roboczego sieci szkieletowej możesz przyznać członkostwo w trzech rolach obszaru roboczego, które przyznają uprawnienia do zapisu. Każda rola automatycznie tłumaczy się na odpowiednią rolę w języku SQL, która udziela równoważnego dostępu do zapisu.
  • Udziel dostępu do odczytu aparatowi SQL i przyznaj niestandardowe uprawnienia SQL do zapisu w niektórych lub wszystkich danych.

Jeśli użytkownik potrzebuje dostępu do zapisu do wszystkich magazynów lub punktów końcowych analizy SQL w obszarze roboczym, przypisz je do roli obszaru roboczego. Jeśli użytkownik nie musi przypisywać innych użytkowników do ról obszaru roboczego, należy użyć roli Współautor.

Jeśli użytkownik musi zapisywać tylko w określonych magazynach lub w analizie SQL, przyznaj im bezpośredni dostęp za pośrednictwem uprawnień SQL.

Dostęp do odczytu SQL

Istnieją dwa sposoby udzielenia użytkownikowi dostępu do odczytu do magazynu lub punktu końcowego analizy SQL:

  • Udziel dostępu do odczytu za pośrednictwem uprawnienia ReadData przyznanego w ramach ról obszaru roboczego Sieć szkieletowa. Wszystkie cztery role obszaru roboczego przyznają uprawnienie ReadData.
  • Udziel dostępu do odczytu aparatowi SQL i przyznaj niestandardowe uprawnienia SQL do odczytu do niektórych lub wszystkich danych.

Jeśli użytkownik jest członkiem roli obszaru roboczego Sieć szkieletowa, otrzymuje uprawnienie ReadData. Uprawnienie ReadData mapuje użytkownika na rolę SQL, która daje uprawnienia SELECT do wszystkich tabel w magazynie lub lakehouse. To uprawnienie jest przydatne, jeśli użytkownik musi zobaczyć wszystkie lub większość danych w magazynie typu lakehouse lub warehouse. Wszystkie uprawnienia ODMOWY SQL ustawione w określonym magazynie typu lakehouse lub warehouse nadal mają zastosowanie i ograniczają dostęp do tabel. Ponadto zabezpieczenia na poziomie wierszy i kolumn można ustawić w tabelach, aby ograniczyć dostęp na poziomie szczegółowym.

Jeśli użytkownik potrzebuje tylko dostępu do określonego magazynu lub typu lakehouse, funkcja udostępniania zapewnia dostęp tylko do udostępnionego elementu. Podczas udostępniania użytkownicy mogą nadać uprawnienia tylko do odczytu lub Odczyt + ReadData. Udzielenie uprawnień do odczytu umożliwia użytkownikowi nawiązanie połączenia z punktem końcowym magazynu lub analizy SQL, ale nie daje dostępu do tabeli. Przyznawanie użytkownikom uprawnień ReadData zapewnia im pełny dostęp do odczytu do wszystkich tabel w magazynie lub punkcie końcowym analizy SQL. W obu przypadkach można skonfigurować dodatkowe zabezpieczenia SQL w celu udzielenia lub odmowy dostępu do określonych tabel. Te zabezpieczenia SQL mogą obejmować szczegółową kontrolę dostępu, taką jak zabezpieczenia na poziomie wiersza lub kolumny.

Używanie z skrótami

Skróty to funkcja OneLake, która umożliwia odwołowanie się do danych z jednej lokalizacji bez fizycznego kopiowania danych. Skróty to zaawansowane narzędzie, które umożliwia łatwe ponowne używanie danych z jednego magazynu typu lakehouse w innych lokalizacjach bez konieczności tworzenia zduplikowanych kopii danych.

Magazyny w sieci szkieletowej nie obsługują skrótów. Jednak istnieje specjalne zachowanie dotyczące sposobu interakcji punktu końcowego analizy SQL dla usługi Lakehouse ze skrótami.

Wszystkie skróty w usłudze Lakehouse są dostępne w trybie delegowanym podczas wykonywania zapytań za pośrednictwem punktu końcowego analizy SQL. Tożsamość delegowana to użytkownik sieci szkieletowej, który jest właścicielem usługi Lakehouse. Domyślnie właścicielem jest użytkownik, który utworzył punkt końcowy usługi Lakehouse i SQL Analytics. Właściciel można zmienić w wybranych przypadkach, a bieżący właściciel jest wyświetlany w kolumnie Właściciel w sieci szkieletowej podczas wyświetlania elementu na liście elementów obszaru roboczego. Zachowanie delegowane oznacza, że użytkownik wykonujący zapytanie może odczytywać dane z tabel skrótów, jeśli właściciel ma dostęp do danych bazowych, a nie użytkownik wykonujący zapytanie. Użytkownik, który wysyła zapytanie, musi mieć dostęp tylko do wybrania z tabeli skrótów.

Uwaga

Na przykład UserA jest właścicielem lakehouse, a użytkownikB uruchamia zapytanie w tabeli, która jest skrótem. UżytkownikB musi najpierw mieć dostęp do odczytu w tabeli, niezależnie od tego, czy za pośrednictwem funkcji ReadData, czy za pośrednictwem uprawnień SQL. Aby wyświetlić dane, zapytanie sprawdza, czy użytkownik ma dostęp do skrótu. Jeśli użytkownik ma dostęp, użytkownikB zobaczy wyniki zapytania. Jeśli użytkownikA nie ma dostępu, zapytanie zakończy się niepowodzeniem.

W przypadku usługi Lakehouse korzystających z funkcji ról dostępu do danych OneLake dostęp do skrótu jest określany przez to, czy właściciel punktu końcowego analizy SQL ma dostęp, aby wyświetlić docelowy magazyn typu lakehouse i odczytać tabelę za pomocą roli dostępu do danych Usługi OneLake.

W przypadku usług lakehouse, które nie korzystają jeszcze z funkcji ról dostępu do danych OneLake, dostęp do skrótów jest określany przez to, czy właściciel punktu końcowego analizy SQL ma uprawnienie Odczyt i OdczytWszystkie na ścieżce docelowej.