Kontrol ingress berbasis konteks

Penting

Nota

Halaman ini menyediakan gambaran umum kontrol ingress berbasis konteks. Untuk kontrol keluar tanpa server, lihat Apa itu kontrol keluar tanpa server?.

Untuk mengonfigurasi kebijakan masuk, lihat Mengelola kebijakan masuk berbasis konteks.

Gambaran umum kontrol ingress berbasis konteks

Kontrol ingress berbasis konteks bekerja bersama daftar akses IP dan konektivitas privat front-end untuk memungkinkan administrator akun menetapkan aturan izin dan penolakan yang menggabungkan siapa yang menelepon, dari mana mereka menelepon, dan apa yang dapat mereka capai di Azure Databricks. Ini memastikan bahwa hanya kombinasi identitas tepercaya, jenis permintaan, dan sumber jaringan yang dapat menjangkau ruang kerja Anda. Kontrol ingress berbasis konteks dikonfigurasi di tingkat akun. Satu kebijakan dapat mengatur beberapa ruang kerja, memastikan penegakan yang konsisten di seluruh organisasi Anda.

Dengan menggunakan ingress berbasis konteks, Anda dapat:

Hentikan akses dari jaringan yang tidak tepercaya dengan memerlukan faktor kedua, sumber jaringan tepercaya, selain kredensial.
Izinkan akses untuk klien SaaS tanpa IP keluar yang stabil dengan memasukkan identitas alih-alih rentang IP.
Batasi akses dengan mengizinkan sumber yang kurang tepercaya hanya menggunakan cakupan tertentu seperti API Databricks atau UI ruang kerja.
Amankan otomatisasi yang memiliki hak istimewa: Batasi perwakilan layanan bernilai tinggi ke jaringan dengan tingkat kepercayaan tinggi saja.
Audit secara efektif: Rekam log penolakan secara terperinci dalam tabel sistem dari Unity Catalog untuk memantau permintaan yang diblokir.

Konsep inti pengendalian akses masuk berbasis konteks

Sumber jaringan

Sumber jaringan menentukan asal permintaan. Jenis yang didukung meliputi:

Semua IP publik: Sumber internet publik apa pun.
IP yang dipilih: Alamat IPv4 tertentu atau rentang CIDR.

Jenis akses

Aturan berlaku untuk cakupan permintaan masuk yang berbeda. Setiap cakupan mewakili kategori permintaan masuk yang dapat Anda izinkan atau tolak:

UI Ruang Kerja: Akses browser ke ruang kerja.
API: Akses terprogram melalui API Databricks, termasuk titik akhir SQL (JDBC / ODBC).
Aplikasi: Mengizinkan atau menolak akses ke penyebaran Aplikasi Databricks. Lihat Aplikasi Databricks. Hanya opsi Identitas semua pengguna dan perwakilan layanan didukung untuk jenis akses ini.

Lakebase Compute: Koneksi ke instans database Lakebase. Lihat Lakebase instance. Hanya opsi Identitas semua pengguna dan perwakilan layanan didukung untuk jenis akses ini.

Identitas

Aturan dapat menargetkan berbagai jenis identitas. Untuk jenis akses Aplikasi dan Lakebase Compute , satu-satunya opsi yang didukung adalah Semua pengguna dan perwakilan layanan.

Semua pengguna dan perwakilan layanan: Pengguna manusia dan otomatisasi.
Semua pengguna: Pengguna manusia saja.
Semua perwakilan layanan: Identitas otomatisasi saja.
Identitas yang dipilih: Pengguna atau perwakilan layanan tertentu yang dipilih oleh admin.

Evaluasi aturan

Penolakan default: Dalam mode terbatas, akses ditolak kecuali diizinkan secara eksplisit.
Tolak sebelum mengizinkan: Aturan tolak memungkinkan Anda menentukan pengecualian untuk aturan yang diizinkan.
Kebijakan default: Setiap akun memiliki kebijakan masuk default yang diterapkan ke semua ruang kerja yang memenuhi syarat tanpa penetapan kebijakan eksplisit.

Mode penegakan

Kebijakan masuk berbasis konteks mendukung dua mode:

Diberlakukan untuk semua produk: Aturan diterapkan secara aktif dan melanggar permintaan diblokir.
Mode uji coba untuk semua produk: Pelanggaran dicatat, namun permintaan tidak diblokir, memungkinkan Anda mengevaluasi dampak kebijakan dengan aman.

Auditing

Permintaan yang ditolak atau dijalankan secara kering dicatat dalam system.access.inbound_network tabel sistem. Setiap entri log meliputi:

Waktu kejadian
ID Ruang Kerja
Jenis permintaan
Identitas
Sumber jaringan
Jenis akses (DITOLAK atau DRY_RUN_DENIAL)

Anda dapat mengkueri log ini untuk memvalidasi bahwa aturan Anda diterapkan dengan benar dan untuk mendeteksi upaya akses yang tidak terduga.

Hubungan dengan kontrol lain

Daftar akses IP ruang kerja: Dievaluasi sebelum kebijakan masuk berbasis konteks memungkinkan permintaan. Keduanya harus mengizinkan permintaan. Daftar akses IP ruang kerja dapat lebih mempersempit akses tetapi tidak dapat memperlebarnya.
Kontrol keluar tanpa server: Melengkapi kebijakan masuk dengan mengontrol lalu lintas jaringan keluar dari komputasi tanpa server. Lihat Mengelola kebijakan jaringan.

Konektivitas privat front-end: Diterapkan bersama dengan kebijakan masuk saat Izinkan Akses Jaringan PublikDiaktifkan. Jika Izinkan Akses Jaringan PublikDinonaktifkan, semua ingress publik diblokir dan kebijakan ingress tidak dievaluasi. Lihat Konfigurasi Tautan Privat Inbound.

Praktik terbaik

Mulailah dengan mode uji coba kering untuk mengamati dampak tanpa mengganggu akses.
Gunakan aturan berbasis identitas jika memungkinkan untuk klien SaaS yang memutar IP.
Terapkan aturan tolak ke perwakilan layanan istimewa terlebih dahulu untuk membatasi radius ledakan.
Menjaga nama kebijakan tetap jelas dan konsisten untuk pemeliharaan jangka panjang.