Udostępnij przez


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

Uwaga

Ten artykuł stanowi część serii artykułów Sukces implementacji usługi Azure Synapse zaplanowany z rozmysłem. Aby zapoznać się z omówieniem serii, zobacz Sukces implementacji usługi Azure Synapse zgodnie z projektem.

Synapse workspace is a unified graphical user experience that stitches together your analytical and data processing engines, data lakes, databases, tables, datasets, and reporting artifacts along with code and process orchestration. 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. Resources can include data lakes, integration runtimes (IRs), metadata or configurations, and code. 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

We recommended that the data lake (if part of your solution) be properly tiered. Powinieneś podzielić jezioro danych na trzy główne obszary, które odnoszą się do zbiorów danych Bronze, Silver i Gold. Brąz — lub warstwa surowa — może być przechowywana na osobnym koncie magazynu, ponieważ ma bardziej rygorystyczne mechanizmy kontroli dostępu ze względu na niemaskowane poufne dane, które może przechowywać.

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 Apache Spark zainstalowane przez użytkownika są również zarządzane w tym samym koncie przechowywania. To enable these use cases, both users and the workspace managed service identity (MSI) must be added to the Storage Blob Data Contributor role of the ADLS Gen2 storage container. 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. Review the security design for your solution's dedicated SQL pool and serverless SQL pool access and data.

Review the security plan for your data lake and all the ADLS Gen2 storage accounts (and others) that will form part of your Azure Synapse Analytics solution. Magazyn danych ADLS Gen2 sam w sobie 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.
  • Check for cross-tenant scenarios. 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?
    • Who can view all scripts, notebooks, and pipelines?
    • Who can execute scripts and pipelines?
    • Who can create/pause/resume SQL and Spark pools?
    • Kto może publikować zmiany w obszarze roboczym?
    • Kto może zatwierdzać zmiany kontroli źródła?
  • Will pipelines access data by using stored credentials or the workspace managed identity?
  • Czy użytkownicy mają odpowiedni dostęp do usługi Data Lake, aby przeglądać dane w programie Synapse Studio?
  • Is the data lake properly secured by using the appropriate combination of RBAC and ACLs?
  • 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 Learning?
  • 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 data lake z poziomu Synapse Studio, czy po prostu wykonywać zapytania dotyczące danych w data lake przy użyciu serverless SQL lub 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 podstawowej infrastruktury oraz przebiegów 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. For example, if Spark pools form part of the solution, monitor the malformed record store. 

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

  • Who can monitor each resource type (pipelines, pools, and others)?
  • Jak długo należy przechowywać dzienniki aktywności bazy danych?
  • Will workspace and database log retention use Log Analytics or Azure Storage?
  • Czy alerty będą wyzwalane w przypadku błędu przesyłu danych? Jeśli tak, kto powinien zostać powiadomiony?
  • Jaki poziom progu puli SQL powinien wyzwolić alert? Kto powinien zostać powiadomiony?

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. Advantages include better collaboration, versioning, approvals, and release pipelines to promote changes through to development, test, and production environments. 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?
  • Kto będzie mógł 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?
  • Will release pipelines be developed for deployment to different environments?
  • Will an approval process be used for merging and for release pipelines?

Uwaga

Projekt środowiska projektowego ma kluczowe znaczenie dla sukcesu projektu. Jeśli środowisko programistyczne zostało zaprojektowane, zostanie ono ocenione na osobnym etapie tej metodologii.

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.