Nuta
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować się zalogować lub zmienić katalog.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Usługa Azure Private Link tworzy prywatne, bezpieczne połączenie z obszarem roboczym usługi Azure Databricks, zapewniając, że ruch sieciowy nie jest narażony na publiczny Internet.
Istnieją trzy typy połączeń usługi Private Link:
- Front-end (użytkownik do obszaru roboczego): Zabezpiecza połączenie od użytkowników i ich narzędzi, takich jak aplikacja webowa, interfejsy API, czy narzędzia analityki biznesowej, do obszaru roboczego Azure Databricks.
- Zaplecze (płaszczyzna obliczeniowa do sterowania): Zabezpiecza połączenie z klastrów usługi Azure Databricks do podstawowych usług Azure Databricks, które muszą działać.
- Uwierzytelnianie sieci Web: Umożliwia logowanie użytkownika do aplikacji internetowej za pomocą logowania jednokrotnego w przypadku korzystania z sieci prywatnej. Tworzy specjalny prywatny punkt końcowy do obsługi wywołań zwrotnych uwierzytelniania z identyfikatora Entra firmy Microsoft, który w przeciwnym razie kończy się niepowodzeniem w środowisku prywatnym. Uwierzytelnianie sieciowe jest konieczne tylko w przypadku prywatnej łączności interfejsu użytkownika.
Uwaga
Aby zapewnić maksymalne bezpieczeństwo, zaimplementuj zarówno połączenia frontendowe, jak i backendowe, aby zablokować cały dostęp do sieci publicznej do obszaru roboczego.
Przegląd architektury
Architektura opisana w tym dokumencie reprezentuje standardowy wzorzec implementacji usługi Azure Private Link. Ma ona służyć jako podstawowa struktura, a nie uniwersalne rozwiązanie, ponieważ optymalna konfiguracja zależy całkowicie od topologii sieci. Kluczowe czynniki, które mogą wymagać dostosowania tego modelu, obejmują:
- Istniejące architektury typu hub-and-spoke oraz tranzytowej sieci wirtualnej (VNet).
- Niestandardowe polityki przekazywania i rozwiązywania DNS.
- Określone reguły zapory i grupy zabezpieczeń sieciowych (NSG).
- Wymagania dotyczące łączności między regionami lub wieloma chmurami.
Wymagane sieci wirtualne
Łączność prywatna używa dwóch odrębnych sieci wirtualnych.
- Transit VNet: ta sieć wirtualna pełni rolę centralnego węzła łączności dla użytkownika. Zawiera prywatne punkty końcowe interfejsu użytkownika niezbędne do dostępu klientów do obszarów roboczych oraz uwierzytelniania jednokrotnego SSO opartego na przeglądarce.
- Workspace VNet: jest to sieć wirtualna stworzona specjalnie w celu hostowania obszaru roboczego Azure Databricks oraz prywatnego punktu końcowego back-endu.
Alokacja i ustalanie rozmiaru podsieci
Planowanie podsieci w każdej sieci wirtualnej w celu obsługi łączności prywatnej i wdrożeń.
Tranzytowe podsieci sieci wirtualnej
- Podsieć prywatnego punktu końcowego: przydziela adresy IP dla wszystkich prywatnych punktów końcowych frontendowych.
- Podsieci obszaru roboczego uwierzytelniania przeglądarki: dwie dedykowane podsieci, host lub podsieć publiczna oraz kontener lub podsieć prywatna, są zalecane do wdrożenia obszaru roboczego uwierzytelniania przeglądarki.
Podsieci VNet obszaru roboczego:
- Podsieci obszaru roboczego: do wdrożenia obszaru roboczego usługi Azure Databricks wymagane są dwie podsieci, host lub podsieć publiczna oraz kontener lub podsieć prywatna. Aby uzyskać informacje o określaniu rozmiaru związane z podsieciami obszaru roboczego, zobacz Wskazówki dotyczące przestrzeni adresowej.
- Podsieć prywatnego punktu końcowego zaplecza: dodatkowa podsieć jest wymagana do hostowania prywatnego punktu końcowego na potrzeby łączności prywatnej zaplecza.
Ustalanie rozmiaru zależy od indywidualnych potrzeb implementacji, ale możesz użyć następującego przewodnika:
| sieć wirtualna | Cel podsieci | Zalecany zakres CIDR |
|---|---|---|
| Tranzyt | Podsieć prywatnych punktów końcowych | /26 to /25 |
| Tranzyt | Obszar roboczy uwierzytelniania przeglądarki |
/28 lub /27 |
| Workspace | Podsieć prywatnego punktu końcowego zaplecza serwerowego | /27 |
Prywatne punkty końcowe usługi Azure Databricks
Usługa Azure Databricks używa dwóch odrębnych typów prywatnych punktów końcowych do pełnego prywatyzacji ruchu. Zapoznaj się z różnymi rolami, aby zaimplementować je poprawnie.
-
Punkt końcowy obszaru roboczego (
databricks_ui_api): jest to podstawowy prywatny punkt końcowy do zabezpieczania ruchu podstawowego do i z obszaru roboczego. Obsługuje połączenia zarówno dla front-endu, jak i back-endu. -
Punkt końcowy uwierzytelniania sieci Web (
browser_authentication): jest to wyspecjalizowany, dodatkowy punkt końcowy wymagany tylko do działania jednokrotnego Sign-On (SSO) na potrzeby logowania w przeglądarce internetowej za pośrednictwem połączenia prywatnego. Jest to wymagane w przypadku łączności front-end'u i end-to-end.
W przypadku punktu końcowego uwierzytelniania internetowego zwróć uwagę na następujące kwestie:
- Wymaganie wywołania zwrotnego SSO: W przypadku korzystania z usługi Private Link na potrzeby dostępu klienta ten punkt końcowy jest obowiązkowy w przypadku logowania w sieci web użytkownika. Bezpiecznie obsługuje zwrotne wywołania uwierzytelniania SSO z Microsoft Entra ID, które w przeciwnym razie są blokowane w sieci prywatnej. Usługa Azure Databricks automatycznie konfiguruje niezbędne prywatne rekordy DNS podczas tworzenia tego punktu końcowego. Ten proces nie ma wpływu na uwierzytelnianie interfejsu API REST.
-
Reguła wdrażania: dla regionu platformy Azure i prywatnej strefy DNS może istnieć tylko jeden
browser_authenticationpunkt końcowy. Ten pojedynczy punkt końcowy obsługuje wszystkie obszary robocze w tym regionie, które współużytkują tę samą konfigurację DNS. - Najlepsze rozwiązanie produkcyjne: aby zapobiec awariom, utwórz dedykowany "prywatny obszar roboczy uwierzytelniania sieci Web" w każdym regionie produkcyjnym. Jedynym celem jest hostowanie tego krytycznego punktu końcowego. Wyłącz opcję "Dostęp do sieci publicznej" dla tego obszaru roboczego. Upewnij się, że nie zostały dla niego utworzone żadne inne prywatne punkty końcowe front-end. Jeśli ten obszar roboczy hosta zostanie usunięty, logowanie internetowe nie powiedzie się dla wszystkich innych obszarów roboczych w regionie.
- Alternatywna konfiguracja: w przypadku prostszych wdrożeń można hostować punkt końcowy w istniejącym obszarze roboczym zamiast tworzyć dedykowane. Jest to odpowiednie dla środowisk nieprodukcyjnych lub jeśli masz pewność, że masz tylko jeden obszar roboczy w regionie. Należy jednak pamiętać, że usunięcie obszaru roboczego hosta natychmiast przerywa uwierzytelnianie dla innych obszarów roboczych, które od niego zależą.
Prywatne połączenie front-endowe
Na poniższym diagramie przedstawiono przepływ sieci dla łącza prywatnego front-end. Łączność front-end używa prywatnego punktu końcowego databricks_ui_api i prywatnego punktu końcowego w tranzytowej sieci wirtualnej browser_authentication, aby zabezpieczyć połączenie użytkowników i ich narzędzi z obszarem roboczym Azure Databricks.
Zobacz Konfigurowanie frontowego łącza prywatnego.
Łączność prywatna zaplecza
Na poniższym diagramie przedstawiono przepływ sieci dla łączności prywatnej zaplecza. Prywatna łączność zaplecza używa prywatnego punktu końcowego databricks_ui_api za pośrednictwem VNet obszaru roboczego, aby zabezpieczyć połączenie między klastrami Azure Databricks a podstawowymi usługami Azure Databricks, które są niezbędne do działania.
Zobacz Konfigurowanie łączności prywatnej zaplecza z usługą Azure Databricks.
Kluczowe zagadnienia
Przed skonfigurowaniem łączności prywatnej należy pamiętać o następujących kwestiach:
- Jeśli w prywatnym punkcie końcowym są włączone zasady sieciowe grupy zabezpieczeń , należy zezwolić na porty 443, 6666, 3306 i 8443-8451 dla reguł zabezpieczeń dla ruchu przychodzącego w sieciowej grupie zabezpieczeń w podsieci, w której wdrożono prywatny punkt końcowy.
- Aby utworzyć połączenie między siecią a witryną Azure Portal i jej usługami, może być konieczne dodanie adresów URL witryny Azure Portal do listy dozwolonych. Zobacz Zezwalanie na adresy URL portalu Azure na zaporze ogniowej lub serwerze proxy.
Wybieranie odpowiedniej implementacji usługi Private Link
Skorzystaj z tego przewodnika, aby określić, która implementacja najlepiej odpowiada Twoim potrzebom.
| Kwestie wymagające rozważenia | Hybryda frontonu | Tylko zaplecze | Kompleksowa prywatna |
|---|---|---|---|
| Podstawowy cel zabezpieczeń | Zabezpieczanie dostępu użytkowników | Bezpieczny ruch klastra | Maksymalna izolacja (zabezpieczanie wszystkiego) |
| Łączność użytkownika | Publiczny lub prywatny | Publiczne (Internet) | Tylko dla prywatnego użytku |
| Łączność klastra z płaszczyzną sterowania | Publiczna (standardowa bezpieczna ścieżka) | Prywatny (wymagane) | Prywatny (wymagane) |
| Prerequisites | Plan Premium, iniekcja sieci wirtualnej, SCC | Plan Premium, iniekcja sieci wirtualnej, SCC | Plan Premium, iniekcja sieci wirtualnej, SCC |
| Ustawienie dostępu do sieci obszaru roboczego | Dostęp publiczny włączony | Dostęp publiczny włączony | Dostęp publiczny jest wyłączony |
| Wymagane reguły NSG | WszystkieZasady | NoAzureDatabricksRules | NoAzureDatabricksRules |
| Wymagane prywatne punkty końcowe | Front-end (databricks_ui_api), uwierzytelnianie przeglądarki | Zaplecze technologiczne (databricks_ui_api) | Wszystkie trzy (front-end, back-end, uwierzytelnianie przeglądarki) |
| Koszt względny | Koszt punktu końcowego i transferu danych | Koszt punktu końcowego i transferu danych | Najwyższy koszt (wiele punktów końcowych i transfer danych) |