Kontrolka ruchu przychodzącego oparta na kontekście

Ta strona przedstawia przegląd kontroli wejścia opartej na kontekście, w tym jej podstawowe koncepcje, tryby egzekwowania, audyt oraz sposób interakcji z innymi kontrolami sieciowymi. Aby skonfigurować polityki, zobacz Zarządzaj politykami wejściowymi opartymi na kontekstzie. Aby uzyskać informacje o kontrolce ruchu wychodzącego bezserwerowego, zobacz Co to jest kontrolka ruchu wychodzącego bezserwerowego?.

Omówienie kontroli dostępu opartej na kontekście

Kontrola ruchu przychodzącego oparta na kontekście działa wraz z listami dostępu IP i prywatną łącznością frontonu, umożliwiając administratorom kont definiowanie reguł zezwalania i blokowania, które łączą informacje o tym, kto nawiązuje połączenie, skąd je nawiązuje oraz do czego może uzyskać dostęp w usłudze Azure Databricks. Gwarantuje to, że tylko zaufane kombinacje tożsamości, typu żądania i źródła sieci mogą dotrzeć do obszaru roboczego. Kontrola dostępu oparta na kontekście jest konfigurowana na poziomie konta. Jedna zasada może zarządzać wieloma obszarami roboczymi.

Przy użyciu ruchu przychodzącego opartego na kontekście można wykonywać następujące czynności:

• Zatrzymaj dostęp z niezaufanych sieci, wymagając drugiego czynnika , zaufanego źródła sieci, oprócz poświadczeń.
• Umożliw dostęp klientom SaaS bez stałych adresów IP dla ruchu wychodzącego, opierając kontrolę dostępu na tożsamości zamiast na zakresach adresów IP.
• Ogranicz dostęp, zezwalając mniej zaufanym źródłom na używanie tylko niektórych zakresów, takich jak interfejsy API Azure Databricks lub interfejs użytkownika obszaru roboczego.
• Ochrona automatyzacji uprzywilejowanej: ograniczenie jednostek usługi o wysokiej wartości tylko do sieci o wysokim poziomie zaufania.
• Skuteczny audyt: rejestruj szczegółowe dzienniki odmów w tabelach systemowych Unity Catalog, aby monitorować zablokowane żądania.

Polityki na poziomie przestrzeni roboczej a polityki na poziomie konta

Kontrola wejścia oparta na kontekście wykorzystuje dwa rodzaje polityk. Polityki na poziomie przestrzeni roboczych regulują dostęp do przestrzeni roboczych. Polityki na poziomie konta określają dostęp do zasobów konta, takich jak konsola konta i usługa Genie One na poziomie konta.

Polityki na poziomie konta są w fazie beta. Aby zacząć, włącz Context-Based Ingress: Account Policy.

Podstawowe pojęcia kontroli dostępu kontekstowej

Źródła sieci

Źródło sieci definiuje źródło żądań. Obsługiwane typy obejmują:

Zasady dostępu publicznego:

• Wszystkie publiczne adresy IP: dowolne publiczne źródło internetowe.
• Wybrane adresy IP: określone adresy IPv4 lub zakresy CIDR.
• Platformy partnerskie (Beta): adresy IP, których aplikacje firm trzecich (Power BI, Tableau Cloud i dbt platforma) używają do łączenia się z Azure Databricks. Azure Databricks automatycznie zarządza tymi listami IP i aktualizuje je.

Zasady dostępu prywatnego:

• Wszystkie zarejestrowane prywatne punkty końcowe: każdy zarejestrowany prywatny punkt końcowy na koncie.
• Wybrane prywatne punkty końcowe: określone zarejestrowane prywatne punkty końcowe na koncie.

• Azure workspace Private Link: Tylko w regułach odmowy zasad obszaru roboczego. Odmawia dostępu do wszystkich databricks_ui_api punktów końcowych.
• Cały prywatny dostęp: W zasadach odmowy w Workspace tylko reguły. Odmawia dostępu do wszystkich databricks_ui_api i zarejestrowanych punktów końcowych.

Dostęp między obszarami roboczymi (Beta): Określa, które źródłowe obszary robocze mogą uzyskać dostęp do tego obszaru roboczego za pośrednictwem ruchu bezserwerowego, z użyciem tych samych tożsamości oraz reguł zezwalania i odmowy co inne źródła sieciowe.

• Wybrane przestrzenie robocze: Tylko przestrzenie robocze, których identyfikatory podasz na liście.

Możesz także pozostawić tę politykę w trybie kompatybilności, w takim przypadku nie reguluje ona wejścia między przestrzeniami roboczymi i istniejące wcześniej kontrole sieciowe w przestrzeni roboczej są obowiązywały. Aby skonfigurować dostęp między przestrzeniami roboczymi zarówno po stronie wejściowej, jak i wyjściowej oraz przeanalizować jego ograniczenia, zobacz dostęp między przestrzeniami roboczymi.

Typy dostępu

Reguły mają zastosowanie do różnych zakresów żądań przychodzących. Każdy zakres reprezentuje kategorię żądań przychodzących, które można zezwolić lub odrzucić:

Typy dostępu do zasad na poziomie obszaru roboczego:

• Interfejs użytkownika obszaru roboczego: dostęp przeglądarki do obszaru roboczego.
• API: Dostęp programowy za pośrednictwem interfejsów API Azure Databricks, w tym punktów końcowych SQL (JDBC/ODBC). Możesz celować w jedną z następujących kategorii:
  • Wszystkie API.
  • Konkretny zakres interfejsu API z użyciem IN. Na przykład możesz określić aplikacje, dashboard lub obsługę modelu.
  • Wszystkie zakresy API poza wybranymi, przy użyciu NOT IN.
• Środowisko uruchomieniowe aplikacji: zezwalanie na dostęp do wdrożeń usługi Databricks Apps lub odmawianie dostępu do tych wdrożeń. Zobacz Aplikacje usługi Databricks. Dla tego typu dostępu jest wspierana tylko opcja tożsamości Wszyscy użytkownicy i jednostki usługi.
• Środowisko wykonawcze Lakebase: połączenia z instancjami bazy danych Lakebase. Zobacz Lakebase. Dla tego typu dostępu jest wspierana tylko opcja tożsamości Wszyscy użytkownicy i jednostki usługi.

Typy dostępu do polityk na poziomie konta (Beta):

• Interfejs użytkownika konta: dostęp przez przeglądarkę do zasobów na poziomie konta (na przykład konsoli konta i Genie One na poziomie konta).
• Interfejs API konta: dostęp programistyczny za pośrednictwem interfejsów API konta usługi Azure Databricks.

Tożsamości

Reguły mogą być przeznaczone dla różnych typów tożsamości. Dla typów dostępu środowiska uruchomieniowego Apps i środowiska uruchomieniowego Lakebase jedyną obsługiwaną opcją jest Wszyscy użytkownicy i jednostki usługi głównej.

W zasadach na poziomie konta jedyną obsługiwaną opcją jest Wszyscy użytkownicy i jednostki usługi.

• Wszyscy użytkownicy i pryncypały usług: zarówno użytkownicy, jak i systemy automatyzacyjne.
• Wszyscy użytkownicy: tylko użytkownicy ludzki.
• Wszystkie jednostki usługi: tylko tożsamości automatyzacji.
• Wybrane tożsamości: konkretni użytkownicy lub jednostki usługi.

Ocena reguły

• Odmowa domyślna: w trybie ograniczonym dostęp jest zabroniony, chyba że jest świadomie dozwolony.
• Odmów przed zezwoleniem: Reguły odmowy umożliwiają definiowanie wyjątków dla reguł zezwalania.
• Domyślne zasady na poziomie obszaru roboczego: każde konto ma domyślne zasady ruchu przychodzącego na poziomie obszaru roboczego stosowane do wszystkich kwalifikujących się obszarów roboczych bez jawnego przypisania zasad.

Tryby wymuszania

Zasady ruchu przychodzącego opartego na kontekście umożliwiają korzystanie z dwóch trybów:

• Wymuszane dla wszystkich produktów: Azure Databricks aktywnie egzekwuje zasady i blokuje żądania naruszające te zasady.
• Tryb próbny dla wszystkich produktów: Azure Databricks rejestruje naruszenia, ale nie blokuje żądań. Użyj tego trybu, aby ocenić wpływ zasad przed wymusiniem.

Databricks zaleca rozpoczęcie w trybie testowym, aby zaobserwować wpływ zasad, zanim zostanie włączone ich egzekwowanie.

Auditing

Żądania odmowy lub uruchamiania próbnego są rejestrowane w tabeli systemowej system.access.inbound_network . Jeśli nie masz dostępu do tabel systemowych, administrator magazynu metadanych może udzielić Ci uprawnień. Zobacz Udzielanie dostępu do tabel systemowych.

Każdy wpis dziennika zawiera następujące elementy:

• Czas zdarzenia
• Identyfikator obszaru roboczego
• Etykieta reguły (reguły, która zaprzeczyła żądaniu)
• Typ żądania
• Tożsamość
• Źródło sieci
• Typ dostępu (ODMOWA lub DRY_RUN_DENIAL)

Odmowy z polityki na poziomie konta są rejestrowane z ustawieniem workspace_id na 0.

Przeszukaj te dzienniki, aby sprawdzić, czy reguły działają zgodnie z oczekiwaniami, i wykryć nieoczekiwane próby dostępu.

Relacja z innymi sterowaniami

• Listy dostępu IP obszaru roboczego: są oceniane razem z opartą na kontekście zasadą ruchu przychodzącego za pomocą operatora logicznego AND, bez ustalonej ścisłej kolejności między nimi. Żądanie jest dozwolone tylko wtedy, gdy zezwalają na nie zarówno lista dostępu IP, jak i polityka ruchu przychodzącego. Listy dostępu do adresów IP obszaru roboczego mogą jeszcze bardziej zawęzić dostęp, ale nie mogą go poszerzyć.
• Kontrola ruchu wychodzącego bezserwerowego: uzupełnia zasady ruchu przychodzącego, kontrolując ruch sieciowy wychodzący z bezserwerowych obliczeń. Zobacz Zarządzanie zasadami sieciowymi.
• Dostęp między obszarami roboczymi: Określa, które źródłowe obszary robocze mogą uzyskiwać dostęp do obszaru roboczego za pośrednictwem ruchu bezserwerowego, oprócz ustawień źródeł sieciowych i tożsamości na tej stronie. Zobacz Dostęp między przestrzeniami roboczymi.
• Listy dostępu odbiorców do OpenSharing: Wejście oparte na kontekście nie dotyczy list dostępu odbiorców OpenSharing. Są to oddzielne kontrolki dla otwartych odbiorców, które dostawcy konfigurują dla każdego odbiorcy. Zobacz Ograniczanie dostępu odbiorców Open Sharing przy użyciu list dostępu IP (udostępnianie z Databricks do Open Sharing).

• Prywatna łączność front-end: Dla polityk przestrzeni roboczej i danego zarejestrowanego punktu końcowego dozwolone są punkty końcowe dozwolone zarówno w kontekście wejściowym, jak i w prywatnym databricks_ui_api punkcie końcowym. Jeśli jednak zasady ruchu przychodzącego oparte na kontekście w obszarze roboczym zawierają regułę blokowania, która blokuje wszystkie punkty końcowe databricks_ui_api, żaden punkt końcowy databricks_ui_api nie może mieć dostępu do usługi Azure Databricks. Zobacz Konfigurowanie przychodzącego łącza prywatnego dla obszarów roboczych.
• Przełącznik „Zezwalaj na dostęp do sieci publicznej”: Gdy Zezwalaj na dostęp do sieci publicznej jest Włączona, listy dostępu IP obszaru roboczego są sprawdzane. W przeciwnym razie cały publiczny ruch przychodzący jest blokowany, a zasady publicznego ruchu przychodzącego dla obszaru roboczego nie są sprawdzane.

Zarządzaj opartymi na kontekście zasadami ruchu przychodzącego

Konfiguruj i dołączaj polityki na poziomie odpowiadającym zasobu, który chcesz chronić:

Aby skonfigurować reguły publiczne i prywatne na polityce na poziomie konta, która chroni zasoby na poziomie konta, zobacz Zarządzaj politykami wejścia opartymi na koncie kontekstowym.

API i Terraform

Oprócz konsoli kont, możesz programowo zarządzać kontekstowymi politykami wejścia:

• REST API: Użyj Azure Databricks REST API do zarządzania politykami sieciowymi.
• Terraform: Użyj dostawcy Azure Databricks Terraform do zarządzania politykami wejściowymi jako infrastrukturą i kodem.

Najlepsze rozwiązania

• Zacznij od trybu próbnego, aby obserwować skutki bez zakłócania dostępu.
• Używaj reguł opartych na tożsamościach, jeśli jest to możliwe dla klientów SaaS, którzy obracają adresy IP.
• Najpierw zastosuj reguły odmowy do uprzywilejowanych jednostek usługi, aby ograniczyć obszar, którego dotyczy problem.
• Zachowaj jasne i spójne nazwy zasad.

Availability