Kontrolka ruchu przychodzącego oparta na kontekście

Ważne

Ta funkcja jest dostępna w publicznej wersji testowej.

Ta strona zapewnia ogólny przegląd kontroli dostępu na podstawie kontekstu. Aby uzyskać informacje o kontrolce ruchu wychodzącego bezserwerowego, zobacz Co to jest kontrolka ruchu wychodzącego bezserwerowego?.

Aby skonfigurować zasady ruchu przychodzącego, zobacz Zarządzanie zasadami ruchu przychodzącego opartego na kontekście.

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

Kontrola ruchu przychodzącego oparta na kontekście działa razem z listami kontroli dostępu IP i prywatnością połączeń frontonu, aby umożliwić administratorom kont ustalanie reguł zezwalania i odrzucania, które łączą kto dzwoni, skąd dzwonią i do czego mogą 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, zapewniając spójne wymuszanie w całej organizacji.

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ń.
• Zezwalaj na dostęp dla klientów SaaS bez stabilnych adresów IP ruchu wychodzącego, opierając się 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 dostępu, takich jak interfejsy API usługi 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: przechwytywanie szczegółowych dzienników odmowy w systemowych tabelach Unity Catalog w celu monitorowania zablokowanych żądań.

Podstawowe pojęcia kontroli dostępu kontekstowej

Źródła sieci

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

• Wszystkie publiczne adresy IP: dowolne publiczne źródło internetowe.
• Wybrane adresy IP: określone adresy IPv4 lub zakresy CIDR.

Typy dostępu

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

• Interfejs użytkownika obszaru roboczego: dostęp przeglądarki do obszaru roboczego.
• API: dostęp programowy za pośrednictwem interfejsów API usługi Databricks, w tym punktów końcowych SQL (JDBC / ODBC).
• Aplikacje: 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.

• Lakebase Compute: połączenia z instancjami bazy danych Lakebase. Zobacz instancje Lakebase. Dla tego typu dostępu jest wspierana tylko opcja tożsamości Wszyscy użytkownicy i jednostki usługi.

Tożsamości

Reguły mogą być przeznaczone dla różnych typów tożsamości. W przypadku typów dostępu Aplikacje i Lakebase Compute jedyną obsługiwaną opcją jest Wszyscy użytkownicy i główne jednostki usługowe.

• 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 wybrane przez administratora.

Ocena reguły

• Odmowa domyślna: w trybie ograniczonym dostęp jest zabroniony, chyba że jest świadomie dozwolony.
• Odmów przed zezwoleniem: jeśli istnieją oba typy reguł, reguły odmowy mają pierwszeństwo.
• Zasady domyślne: każde konto ma domyślne zasady ruchu przychodzącego stosowane do wszystkich kwalifikujących się obszarów roboczych bez jawnego przypisania zasad.

Tryby wymuszania

Zasady ruchu wejściowego zależne od kontekstu obsługują dwa tryby:

• Wymuszane dla wszystkich produktów: Reguły są aktywnie stosowane i żądania naruszające zasady są blokowane.
• Tryb uruchamiania suchego dla wszystkich produktów: naruszenia są rejestrowane, ale żądania nie są blokowane, co pozwala bezpiecznie ocenić wpływ zasad.

Auditing

Żądania odmowy lub uruchamiania próbnego są rejestrowane w tabeli systemowej system.access.inbound_network . Każdy wpis dziennika zawiera następujące elementy:

• Czas zdarzenia
• Identyfikator obszaru roboczego
• Typ żądania
• Tożsamość
• Źródło sieci
• Typ dostępu (ODMOWA lub DRY_RUN_DENIAL)

Możesz wykonać zapytanie dotyczące tych dzienników, aby sprawdzić, czy reguły są prawidłowo stosowane i wykrywać nieoczekiwane próby dostępu.

Relacja z innymi kontrolkami

• Listy dostępu do adresów IP przestrzeni roboczej: oceniane przed zezwoleniem na żądanie polityki wejścia opartej na kontekście. Oba muszą zezwalać na żądanie. 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.

• Łączność prywatna frontonu: wymuszane obok zasad ruchu przychodzącego, gdy opcja Zezwalaj na dostęp do sieci publicznej jest włączona. Jeśli opcja Zezwalaj na dostęp do sieci publicznej jest wyłączona, cały ruch przychodzący jest blokowany, a polityki ruchu przychodzącego nie są oceniane. Zobacz Konfigurowanie frontowego łącza prywatnego.

Najlepsze rozwiązania

• Zacznij od trybu symulacji, aby obserwować wpływy 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ć promień wybuchu.
• Utrzymuj jasne i spójne nazwy polityk dla lepszego utrzymania na dłuższą metę.

Uwaga / Notatka

Kontrolka ruchu przychodzącego oparta na kontekście nie jest dostępna w regionie Azure West India.