Metodologia sukcesu implementacji usługi Synapse: Ocena projektu obszaru roboczego

Obszar roboczy usługi Synapse to ujednolicone graficzne środowisko użytkownika, które łączy aparaty analityczne i przetwarzania danych, magazyny danych, bazy danych, tabele, zestawy danych i artefakty raportowania wraz z orkiestracją kodu i procesu. Biorąc pod uwagę liczbę technologii i usług zintegrowanych z obszarem roboczym usługi Synapse, upewnij się, że kluczowe składniki są uwzględnione w projekcie.

Przegląd projektu obszaru roboczego usługi Synapse

Określ, czy projekt rozwiązania obejmuje jeden obszar roboczy usługi Synapse, czy wiele obszarów roboczych. Określ sterowniki tego projektu. Chociaż mogą istnieć różne przyczyny, w większości przypadków przyczyną wielu obszarów roboczych jest segregacja zabezpieczeń lub podział rozliczeń. Podczas określania liczby obszarów roboczych i granic bazy danych należy pamiętać, że istnieje limit 20 obszarów roboczych na subskrypcję.

Zidentyfikuj, które elementy lub usługi w każdym obszarze roboczym muszą być współużytkowane i z którymi zasobami. Zasoby mogą obejmować magazyny data lake, środowiska Integration Runtime (IRs), metadane lub konfiguracje oraz kod. Określ, dlaczego ten konkretny projekt został wybrany pod względem potencjalnych synergii. Zadaj sobie pytanie, czy te synergie uzasadniają dodatkowe koszty i koszty związane z zarządzaniem.

Przegląd projektu usługi Data Lake

Zalecamy, aby usługa Data Lake (jeśli część rozwiązania) została prawidłowo warstwowa. Magazyn data lake należy podzielić na trzy główne obszary, które odnoszą się do zestawów danych Bronze, Silver i Gold . Brązowy — lub nieprzetworzona warstwa — może znajdować się na własnym oddzielnym koncie magazynu, ponieważ ma bardziej rygorystyczne mechanizmy kontroli dostępu ze względu na niemaskowane poufne dane, które mogą być przechowywane.

Przegląd projektu zabezpieczeń

Przejrzyj projekt zabezpieczeń obszaru roboczego i porównaj go z informacjami zebranymi podczas oceny. Upewnij się, że zostały spełnione wszystkie wymagania, a wszystkie ograniczenia zostały uwzględnione. Aby ułatwić zarządzanie, zalecamy organizowanie użytkowników w grupy z odpowiednimi profilami uprawnień: możesz uprościć kontrolę dostępu przy użyciu grup zabezpieczeń, które są zgodne z rolami. Dzięki temu administratorzy sieci mogą dodawać lub usuwać użytkowników z odpowiednich grup zabezpieczeń w celu zarządzania dostępem.

Bezserwerowe pule SQL i tabele platformy Apache Spark przechowują dane w kontenerze usługi Azure Data Lake Gen2 (ADLS Gen2), który jest skojarzony z obszarem roboczym. Biblioteki platformy Apache Spark zainstalowane przez użytkownika są również zarządzane na tym samym koncie magazynu. Aby włączyć te przypadki użycia, zarówno użytkownicy, jak i tożsamość usługi zarządzanej obszaru roboczego (MSI) muszą zostać dodani do roli Współautor danych obiektu blob usługi Storage kontenera magazynu usługi ADLS Gen2. Zweryfikuj to wymaganie pod kątem wymagań dotyczących zabezpieczeń.

Dedykowane pule SQL udostępniają bogaty zestaw funkcji zabezpieczeń do szyfrowania i maskowania poufnych danych. Zarówno dedykowane, jak i bezserwerowe pule SQL umożliwiają pełny obszar uprawnień programu SQL Server, w tym wbudowane role, role zdefiniowane przez użytkownika, uwierzytelnianie SQL i uwierzytelnianie firmy Microsoft Entra. Zapoznaj się z projektem zabezpieczeń dedykowanej puli SQL rozwiązania i bezserwerowej puli SQL dostępu i danych.

Zapoznaj się z planem zabezpieczeń usługi Data Lake i wszystkimi kontami magazynu usługi ADLS Gen2 (i innymi), które będą stanowić część rozwiązania usługi Azure Synapse Analytics. Magazyn usługi ADLS Gen2 nie jest aparatem obliczeniowym i nie ma wbudowanej możliwości selektywnego maskowania atrybutów danych. Uprawnienia usługi ADLS Gen2 można zastosować na poziomie konta magazynu lub kontenera przy użyciu kontroli dostępu opartej na rolach (RBAC) i/lub na poziomie folderu lub pliku przy użyciu list kontroli dostępu (ACL). Uważnie przejrzyj projekt i staraj się unikać niepotrzebnej złożoności.

Poniżej przedstawiono kilka kwestii, które należy wziąć pod uwagę podczas projektowania zabezpieczeń.

• Upewnij się, że wymagania dotyczące konfiguracji identyfikatora Entra firmy Microsoft zostały uwzględnione w projekcie.
• Sprawdź scenariusze między dzierżawami. Takie problemy mogą wystąpić, ponieważ niektóre dane znajdują się w innej dzierżawie platformy Azure lub muszą przejść do innej dzierżawy lub muszą mieć do nich dostęp użytkownicy z innej dzierżawy. Upewnij się, że te scenariusze są brane pod uwagę w projekcie.
• Jakie są role dla każdego obszaru roboczego? Jak będą korzystać z obszaru roboczego?
• W jaki sposób zabezpieczenia są zaprojektowane w obszarze roboczym?
  • KtoTo może wyświetlać wszystkie skrypty, notesy i potoki?
  • KtoTo może wykonywać skrypty i potoki?
  • KtoTo można tworzyć/wstrzymywać/wznawiać pule SQL i Spark?
  • KtoTo może publikować zmiany w obszarze roboczym?
  • KtoTo może zatwierdzić zmiany kontroli źródła?
• Czy potoki będą uzyskiwać dostęp do danych przy użyciu przechowywanych poświadczeń lub tożsamości zarządzanej obszaru roboczego?
• Czy użytkownicy mają odpowiedni dostęp do usługi Data Lake, aby przeglądać dane w programie Synapse Studio?
• Czy usługa Data Lake jest prawidłowo zabezpieczona przy użyciu odpowiedniej kombinacji kontroli dostępu opartej na rolach i list ACL?
• Czy uprawnienia użytkownika puli SQL zostały poprawnie ustawione dla każdej roli (analityk danych, deweloper, administrator, użytkownik biznesowy i inne)?

Przegląd projektu sieci

Poniżej przedstawiono kilka kwestii, które należy wziąć pod uwagę podczas projektowania sieci.

• Czy łączność jest zaprojektowana między wszystkimi zasobami?
• Jaki mechanizm sieci ma być używany (Azure ExpressRoute, publiczny Internet lub prywatne punkty końcowe)?
• Czy musisz mieć możliwość bezpiecznego nawiązywania połączenia z programem Synapse Studio?
• Czy eksfiltracja danych została uwzględniona?
• Czy musisz nawiązać połączenie z lokalnymi źródłami danych?
• Czy musisz nawiązać połączenie z innymi źródłami danych w chmurze lub aparatami obliczeniowymi, takimi jak usługa Azure Machine Edukacja?
• Czy składniki sieciowe platformy Azure, takie jak sieciowe grupy zabezpieczeń, zostały przejrzyone pod kątem prawidłowej łączności i przenoszenia danych?
• Czy integracja z prywatnymi strefami DNS została uwzględniona?
• Czy musisz mieć możliwość przeglądania magazynu typu data lake z poziomu programu Synapse Studio lub po prostu wykonywania zapytań dotyczących danych w usłudze Data Lake przy użyciu bezserwerowego kodu SQL lub technologii PolyBase?

Na koniec zidentyfikuj wszystkich użytkowników danych i sprawdź, czy ich łączność jest uwzględniana w projekcie. Sprawdź, czy placówki sieciowe i posterunki zabezpieczeń umożliwiają usłudze dostęp do wymaganych źródeł lokalnych oraz czy są obsługiwane jego protokoły i mechanizmy uwierzytelniania. W niektórych scenariuszach może być konieczne posiadanie więcej niż jednego własnego środowiska IR lub bramy danych dla rozwiązań SaaS, takich jak Microsoft Power BI.

Przegląd projektu monitorowania

Zapoznaj się z projektem monitorowania składników usługi Azure Synapse, aby upewnić się, że spełniają one wymagania i oczekiwania określone podczas oceny. Sprawdź, czy zaprojektowano monitorowanie zasobów i dostępu do danych oraz czy identyfikuje każde wymaganie dotyczące monitorowania. Należy wprowadzić niezawodne rozwiązanie do monitorowania w ramach pierwszego wdrożenia w środowisku produkcyjnym. Dzięki temu błędy można zidentyfikować, zdiagnozować i rozwiązać w odpowiednim czasie. Oprócz podstawowych przebiegów infrastruktury i potoków należy również monitorować dane. W zależności od używanych składników usługi Azure Synapse zidentyfikuj wymagania dotyczące monitorowania dla każdego składnika. Jeśli na przykład pule platformy Spark stanowią część rozwiązania, monitoruj nieprawidłowo sformułowany magazyn rekordów. 

Poniżej przedstawiono kilka kwestii, które należy wziąć pod uwagę podczas projektowania monitorowania.

• KtoTo może monitorować każdy typ zasobu (potoki, pule i inne)?
• Jak długo należy przechowywać dzienniki aktywności bazy danych?
• Czy przechowywanie dzienników obszaru roboczego i bazy danych będzie używać usługi Log Analytics lub Azure Storage?
• Czy alerty będą wyzwalane w przypadku błędu potoku? Jeśli tak, kto powinien zostać powiadomiony?
• Jaki poziom progu puli SQL powinien wyzwolić alert? KtoTo należy otrzymywać powiadomienia?

Przegląd projektu kontroli źródła

Domyślnie obszar roboczy usługi Synapse stosuje zmiany bezpośrednio do usługi Synapse przy użyciu wbudowanych funkcji publikowania. Możesz włączyć integrację kontroli źródła, która zapewnia wiele zalet. Zalety obejmują lepszą współpracę, przechowywanie wersji, zatwierdzenia i potoki wydania w celu promowania zmian w środowiskach deweloperskich, testowych i produkcyjnych. Usługa Azure Synapse umożliwia pojedyncze repozytorium kontroli źródła dla każdego obszaru roboczego, które może być usługą Azure DevOps Git lub GitHub.

Oto kilka kwestii, które należy wziąć pod uwagę w projekcie kontroli źródła.

• Czy w przypadku korzystania z usługi Azure DevOps Git obszar roboczy usługi Synapse i jego repozytorium są w tej samej dzierżawie?
• KtoTo będzie można uzyskać dostęp do kontroli źródła?
• Jakie uprawnienia zostaną przyznane każdemu użytkownikowi w kontroli źródła?
• Czy opracowano strategię rozgałęziania i scalania?
• Czy potoki wydania zostaną opracowane na potrzeby wdrażania w różnych środowiskach?
• Czy proces zatwierdzania będzie używany do scalania i potoków wydania?

Następne kroki

W następnym artykule z serii sukcesów usługi Azure Synapse według projektu dowiesz się, jak ocenić projekt integracji danych i sprawdzić, czy spełnia ona wytyczne i wymagania.