Notatka
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Kontekstowe polityki sieciowe Azure Databricks zapewniają zunifikowane ramy bezpieczeństwa do zarządzania zarówno ruchem przychodzącym, jak i wychodzącym do Twoich przestrzeni roboczych i zasobów na poziomie konta (na przykład konsola kont i Genie One na poziomie konta).
Azure Databricks obsługuje dwa typy sterowania opartego na kontekście (CCS):
- Kontrola wejścia oparta na kontekście: Ogranicza, kto może dotrzeć do Twoich zasobów, skąd i do czego ma dostęp, na podstawie kombinacji tożsamości, źródła sieciowego i typu żądania.
- Kontrola ruchu wychodzącego w środowisku bezserwerowym: Ogranicza, dokąd bezserwerowe obciążenia robocze mogą wysyłać dane, ograniczając połączenia wychodzące do autoryzowanych miejsc docelowych.
Przegląd polityk sieciowych opartych na kontekście
Polityki sieciowe oparte na kontekście umożliwiają administratorom kont definiowanie reguł zezwalających i blokujących, które łączą informacje o tym, kto nawiązuje połączenie, skąd je nawiązuje i do czego może uzyskać dostęp, a także kontrolowanie, z którymi zewnętrznymi miejscami docelowymi mogą łączyć się obciążenia bezserwerowe. Pomaga to spełniać wymagania bezpieczeństwa i zgodności oraz zmniejsza ryzyko nieautoryzowanego dostępu i wydostania się danych.
Polityki na poziomie przestrzeni roboczej są konfigurowane według polityk na poziomie przestrzeni roboczej, z domyślną polityką na poziomie przestrzeni roboczej przypisaną wszystkim przestrzeniom roboczym bez wyraźnego przypisania. Zasady na poziomie konta są konfigurowane oddzielnie w obszarze Zasady na poziomie konta; jego identyfikator zasad to account-policy.
Dzięki politykom sieciowym opartym na kontekście możesz:
- Zatrzymaj dostęp z niezaufanych sieci, wymagając zaufanego źródła sieciowego oprócz danych uwierzytelniających.
- Umożliw dostęp klientom SaaS bez stabilnych wychodzących adresów IP, opierając się na tożsamości zamiast na zakresach adresów IP.
- Ogranicz dostęp, pozwalając mniej zaufanym źródłom korzystać tylko z określonych zakresów, takich jak API Azure Databricks czy interfejs workspace.
- Wymuś domyślnie blokującą politykę dla połączeń wychodzących z obciążeń bezserwerowych.
- Skutecznie przeprowadzaj audyt dzięki rejestrowaniu szczegółowych dzienników odmów w tabelach systemowych Unity Catalog.
Zasady sieciowe oparte na kontekście uzupełniają następujące istniejące funkcje zabezpieczeń:
- Kontrolka ruchu przychodzącego oparta na kontekście:
- Listy dostępu do adresów IP obszaru roboczego
- Listy dostępu do adresów IP konta
- Przychodzący Private Link (z użyciem ustawień dostępu prywatnego)
- Kontrola egresji bezserwerowej
- Wychodzące połączenie Private Link (z użyciem konfiguracji łączności sieciowej)
Porównywane typy zasad
Zasady sieciowe oparte na kontekście obejmują dwa typy: kontrolkę ruchu przychodzącego i kontrolę ruchu wychodzącego. Poniższa tabela zawiera podsumowanie kluczowych różnic:
| Atrybut | Kontrolka ruchu przychodzącego | Kontrola ruchu wychodzącego |
|---|---|---|
| Co kontroluje | Żądania przychodzące do obszaru roboczego Azure Databricks i punktów końcowych na poziomie konta. | Połączenia wychodzące z bezserwerowego środowiska obliczeniowego do zewnętrznych miejsc docelowych. |
| Podstawowy przypadek użycia | Ogranicz, kto może mieć dostęp do obszaru roboczego i zasobów na poziomie konta, skąd może uzyskiwać dostęp oraz do jakich zasobów może mieć dostęp. | Zapobiegaj eksfiltracji danych, kontrolując, z którymi zasobami zewnętrznymi mogą łączyć się zasoby bezserwerowe. |
| Kryteria zasad | Tożsamość (wielu użytkowników lub wielu podmiotów usługi) Źródło sieci (zakres CIDR, zarejestrowane prywatne punkty końcowe) Typ dostępu: dla obszarów roboczych (interfejs użytkownika obszaru roboczego, interfejs API, środowisko uruchomieniowe usługi Apps, środowisko uruchomieniowe usługi Lakebase); dla konta (interfejs użytkownika konta, interfejs API konta) |
Dozwolone lokalizacje Pełne nazwy domenowe (FQDN) Kontenery magazynu w chmurze |
| Rejestrowanie inspekcji |
system.access.inbound_network tabela systemowa |
system.access.outbound_network tabela systemowa |
Kontrola dostępu oparta na kontekście
Oparta na kontekście kontrola dostępu przychodzącego umożliwia administratorom kont ustawianie reguł zezwalających i blokujących, które łączą tożsamość, źródło sieci i typ żądania, dzięki czemu tylko zaufane kombinacje mogą uzyskać dostęp do Twoich zasobów.
Polityki na poziomie przestrzeni roboczej regulują dostęp do przestrzeni roboczych, a pojedyncza polityka na poziomie konta (account-policy) zarządza zasobami na poziomie konta, takimi jak konsola konta i Genie One na poziomie konta. Każde konto zawiera domyślną politykę na poziomie przestrzeni roboczej, która obowiązuje do wszystkich uprawnionych przestrzeni roboczych bez wyraźnego przypisania.
Aby uzyskać źródła sieci, typy dostępu, tożsamości, ocenę reguł, tryby egzekwowania, audyt oraz interakcje wejścia z innymi kontrolami sieciowymi, zobacz Kontrola wejścia oparta na kontekście.
Kontrolka ruchu wychodzącego bezserwerowego
Kontrola ruchu wychodzącego w środowisku serverless zarządza wychodzącymi połączeniami sieciowymi z Twoich bezserwerowych zasobów obliczeniowych, zmniejszając ryzyko wycieku danych. Polityka sieciowa to obiekt na poziomie konta, przypisany do jednego lub większej liczby obszarów roboczych, który określa tryb dostępu wychodzącego dla obciążeń bezserwerowych:
- Pełny dostęp: Obciążenia bezserwerowe mają nieograniczony dostęp wychodzący do internetu i innych zasobów sieciowych.
- Ograniczony dostęp: Dostęp wychodzący jest ograniczony do zewnętrznych lokalizacji Unity Catalog oraz FQDN i konta Azure, które wyraźnie wymieniasz w polityce.
Informacje o modelu zabezpieczeń z ograniczonym dostępem, obsługiwanych produktach bezserwerowych oraz etapach konfiguracji znajdziesz w artykule Czym jest kontrola ruchu wychodzącego w środowisku bezserwerowym?.
Tryby wymuszania
Zarówno zasady ruchu przychodzącego, jak i wychodzącego obsługują tryb wymuszania, w którym reguły są stosowane, a żądania naruszające reguły są blokowane, oraz tryb testowy, w którym naruszenia są rejestrowane, ale nie blokowane. Databricks zaleca rozpoczęcie w trybie próby na sucho, aby uniknąć niezamierzonych zakłóceń w dostępie.
Rejestrowanie inspekcji
Azure Databricks rejestruje oceny zasad na potrzeby zgodności i monitorowania: odrzucenia ruchu przychodzącego w system.access.inbound_network oraz zdarzenia ruchu wychodzącego w system.access.outbound_network. Wykonaj zapytanie dotyczące tych dzienników, aby zweryfikować skuteczność zasad i wykryć nieautoryzowane próby dostępu.
Jak zasady współdziałają z innymi kontrolkami
Polityki wejścia oparte na kontekście współpracują z listami dostępu IP i prywatną łącznością front-end, a kontrola wyjścia bez serwera działa równolegle z wychodzącą prywatną łącznością (wykorzystując konfiguracje łączności sieciowej). Aby dowiedzieć się, jak ingress współdziała z każdym z tych mechanizmów sterowania, w tym jak działa prywatna łączność w poszczególnych chmurach, zobacz Zależność od innych mechanizmów sterowania.
Wskazówka
Aby zmniejszyć złożoność, Databricks zaleca używanie zasad dostępu przychodzącego opartych na kontekście jako jedynego mechanizmu zasad zamiast dodatkowego utrzymywania list dostępu IP. Jeśli Twoje przestrzenie robocze mają już listy dostępu do IP, zobacz Migracja list dostępu do przestrzeni roboczej do wejścia opartego na kontekście.