Gunakan RBAC dengan ABAC

Important

RBAC dalam Pratinjau Publik. ABAC kini tersedia secara umum. Halaman ini menjelaskan cara keduanya bekerja sama.

Kontrol akses berbasis peran (RBAC) dan kontrol akses berbasis atribut (ABAC) di Unity Catalog adalah kontrol pelengkap yang dirancang untuk bekerja sama. Mereka menjawab pertanyaan yang berbeda:

• RBAC menentukan identitas mana yang digunakan pengguna dalam suatu sesi. Pengguna mengambil alih peran untuk bertindak dengan izin dari peran tersebut, alih-alih izin mereka sendiri. Gunakan RBAC untuk memberi seorang pengguna beberapa set izin berbeda yang dapat mereka alihkan secara eksplisit — misalnya, untuk memisahkan akses berdasarkan uji klinis, proyek, atau tingkat sensitivitas.
• ABAC mengontrol data apa yang dapat dilihat identitas aktif, baris menurut baris atau kolom menurut kolom. Kebijakan dilekatkan pada data melalui tag yang dikelola dan berlaku bagi identitas apa pun yang menjalankan kueri. Gunakan ABAC untuk pemfilteran atau masking yang konsisten di banyak tabel yang didorong oleh atribut data.

RBAC menetapkan identitas aktif untuk sesi tersebut, dan ABAC mengevaluasi kebijakannya terhadap identitas tersebut. Halaman ini membahas bagaimana interaksi itu dimainkan dalam praktiknya, perilaku fungsi SQL terkait identitas, dan pola penggunaan gabungan.

Bagaimana fungsi identitas berperilaku saat mengasumsikan peran

Fungsi SQL terkait identitas di Unity Catalog dievaluasi berdasarkan identitas aktif dalam sesi, bukan pengguna yang digunakan untuk autentikasi. Ketika pengguna mengasumsikan peran, identitas sesi aktif menjadi peran:

Function	Saat pengguna bertindak sebagai identitas pengguna mereka	Ketika pengguna mengasumsikan peran
current_user()	Mengembalikan nama pengguna milik pengguna	Mengembalikan nama peran yang diasumsikan
is_member(group)	Mengembalikan true jika pengguna adalah anggota grup (grup lokal ruang kerja, atau grup akun yang ditetapkan ke ruang kerja tersebut)	Mengembalikan true hanya apabila peran yang diambil alih itu sendiri merupakan anggota dari group. Mengembalikan false untuk grup yang penggunanya yang mendasari merupakan anggota, tetapi peran yang digunakan bukan.
is_account_group_member(group)	Mengembalikan true jika pengguna adalah anggota grup tingkat akun	Sama seperti is_member: hanya mengembalikan true berdasarkan keanggotaan grup dari peran yang digunakan, bukan berdasarkan keanggotaan grup pengguna aslinya.

Kebijakan ABAC yang mereferensikan fungsi-fungsi ini mengevaluasi terhadap peran yang diasumsikan, bukan pengguna. Peran yang diasumsikan adalah identitas aktif untuk evaluasi kebijakan ABAC, resolusi pemberian Katalog Unity, dan atribusi audit. Akibatnya, mengasumsikan suatu peran mengubah perilaku kebijakan dan tampilan yang ada, yang dibuat berdasarkan identitas masing-masing pengguna.

Note

Peran tidak secara otomatis menjadi anggota dirinya sendiri. Ketika pengguna mengambil peran G, current_user() mengembalikan G, tetapi is_member('G') dan is_account_group_member('G') mengembalikan false kecuali G secara eksplisit ditambahkan sebagai anggota dari dirinya sendiri. Untuk mencocokkan peran yang diasumsikan dalam kebijakan, bandingkan dengan current_user() daripada menguji keanggotaan dengan is_member atau is_account_group_member.

Kesalahan umum: tampilan keamanan tingkat baris yang dibuat berdasarkan current_user()

Pola umum pada ABAC dan filter baris tingkat tabel adalah memfilter baris dengan melakukan join ke tabel penyediaan (juga disebut tabel pemetaan atau daftar kontrol akses) yang berdasarkan nama pengguna yang dikembalikan oleh current_user(). Contohnya:

CREATE OR REPLACE FUNCTION facility_filter(facility_id STRING)
RETURN EXISTS (
  SELECT 1
  FROM governance.user_facility_provisioning p
  WHERE p.user = current_user()
    AND p.facility_id = facility_id
);

Ketika pengguna yang sama mengasumsikan peran, current_user() tidak lagi mengembalikan nama pengguna mereka. Ini mengembalikan nama peran. Karena peran tersebut tidak ada dalam tabel penyediaan, filter tidak mengembalikan baris apa pun dan pengguna seolah-olah kehilangan akses ke data yang sebelumnya telah diberikan kepadanya.

Tambahkan peran ke tabel provisioning

Perlakukan peran sebagai entitas utama lain dalam data penyediaan Anda: masukkan satu baris untuk setiap peran beserta fasilitas (atau atribut lain) yang seharusnya dapat dilihat oleh peran tersebut. Filter tersebut kemudian memeriksa apakah identitas aktif adalah pengguna atau role asumsi.

Pola penggunaan gabungan

Berikut ini adalah contoh bagaimana pelanggan menggunakan RBAC dan ABAC bersama-sama untuk menyelesaikan masalah kontrol akses nyata. Ini adalah titik awal, bukan resep lengkap.

Filter baris per proyek berdasarkan peran yang diasumsikan

Pemfilteran baris menurut proyek adalah kebutuhan umum dalam penelitian uji klinis, pemasaran kontrak, konsultasi klien, dan pengaturan lain di mana satu tim bekerja di beberapa proyek terisolasi. Contoh berikut menggunakan uji klinis, tetapi pola digeneralisasi ke isolasi data per proyek.

Sebuah organisasi riset klinis menjalankan beberapa uji klinis secara bersamaan, masing-masing dengan peran aksesnya sendiri. Tandai setiap tabel dengan pengidentifikasi proyek. Pengguna hanya melihat baris untuk proyek yang perannya saat ini telah mereka asumsikan.

Penyiapan:

• Tabel di bawah clinical_trials.* memiliki kolom project_id yang ditandai dengan kunci tag governedproject.
• Setiap proyek memiliki peran akses yang sesuai bernama role-<project> (misalnya, role-alpha, role-beta).
• Pengguna hanya memiliki izin Assume pada peran dalam proyek yang mereka kerjakan.

Filter baris UDF:

CREATE FUNCTION project_match(project_id STRING) RETURNS BOOLEAN
DETERMINISTIC
RETURN current_user() = CONCAT('role-', project_id);

Kebijakan:

CREATE POLICY per_project_row_filter
ON CATALOG clinical_trials
ROW FILTER project_match
TO `account users`
FOR TABLES
MATCH COLUMNS has_tag('project') AS project
USING COLUMNS (project);

UDF ini menghubungkan identitas aktif dengan nilai tag setiap baris project , sehingga klausul penargetan utama seperti TO / EXCEPT tidak dapat mengekspresikannya — prinsipal target tersebut, bukan konten baris. Seperti yang dijelaskan dalam panduan penargetan principal, gunakan TO / EXCEPT untuk cakupan principal sederhana dan cadangkan fungsi identitas di dalam UDF hanya untuk kasus seperti ini, ketika satu aturan bergantung pada identitas aktif dan isi baris.

Satu kebijakan mencakup setiap proyek: USING COLUMNS (project) meneruskan nilai tag setiap baris project ke dalam UDF, sehingga Anda tidak memerlukan kebijakan terpisah per proyek. Untuk bentuk umum teknik ini — mendorong akses baris dari tabel pencarian alih-alih pencocokan nama peran — lihat Menggunakan tabel pemetaan untuk kontrol akses dinamis.

Perilaku:

• Pengguna yang menggunakan identitas penggunanya sendiri tidak melihat baris apa pun di tabel mana pun clinical_trials. current_user() mengembalikan nama pengguna mereka, yang tidak pernah cocok dengan role-* pola penamaan. Ini adalah penolakan default yang dimaksudkan.
• Pengguna dengan asumsi role-alpha hanya melihat baris di mana project_id sama dengan alpha. Beralih ke role-beta akan mengganti data yang ditampilkan tanpa melakukan kueri ulang apa pun yang lain.

Pemaskingan PII dilonggarkan untuk pengguna yang menjalankan peran yang ditetapkan

Secara bawaan, kolom PII (SSN, email, telepon) ditampilkan dalam bentuk tersamarkan bagi semua orang. Untuk melihat nilai mentah, pengguna harus secara eksplisit menggunakan peran yang ditetapkan dan diizinkan untuk mengakses PII. Log audit merekam peristiwa pengambilalihan peran, sehingga "Saya perlu melihat PII yang sebenarnya" menjadi persetujuan eksplisit yang dapat diaudit, bukan izin implisit.

Penyiapan:

• Kolom sensitif ditandai dengan kunci tag terkelolapii (nilai yang diizinkan seperti ssn, email, phone).
• Peran akses bernama role-pii-cleared diberikan Asumsikan kepada pengguna yang dibersihkan untuk melihat PII mentah.

UDF penyamaran kolom (statis — kebijakan menentukan prinsipal mana yang akan disamarkan):

CREATE FUNCTION mask_pii(val STRING) RETURNS STRING
DETERMINISTIC
RETURN '***';

Kebijakan:

CREATE POLICY pii_default_mask
ON CATALOG customer_data
COLUMN MASK mask_pii
TO `account users`
EXCEPT `role-pii-cleared`
FOR TABLES
MATCH COLUMNS has_tag('pii') AS pii_col
ON COLUMN pii_col;

Klausul EXCEPT mengecualikan role-pii-cleared sepenuhnya dari kebijakan, sehingga UDF tidak pernah dipanggil ketika peran tersebut menjadi identitas aktif. Lihat Memilih TO/EXCEPT untuk penargetan utama untuk panduan umum tentang penargetan utama melalui TO / EXCEPT.

Perilaku:

• Pengguna yang menggunakan identitas penggunanya akan melihat *** di setiap kolom PII. Ini adalah status default untuk semua orang, termasuk pengguna yang memiliki izin Asumsikan pada role-pii-cleared.
• Setelah berasumsi role-pii-cleared, kebijakan tidak lagi berlaku untuk sesi, dan pengguna yang sama melihat nilai mentah.
• Entri log audit untuk rekaman sesi identity_metadata.run_as = role-pii-cleared, agar peninjau dapat melihat secara tepat kapan PII ditampilkan dan oleh siapa.

Kebijakan tingkat sensitivitas yang bervariasi menurut peran yang diasumsikan

Data diklasifikasikan ke dalam tingkat sensitivitas (internal, confidential, restricted). Setiap tingkatan memiliki peran akses yang sesuai, dengan restricted menyiratkan akses ke confidential dan internal juga. UDF filter satu baris mengontrol visibilitas baris dengan membandingkan tingkatan setiap baris dengan peran yang dianggap dimiliki pengguna.

Penyetelan:

• Tabel memiliki kolom sensitivity_level yang ditandai dengan kunci tag governed tagsensitivity (nilai yang diizinkan: internal, confidential, restricted).
• Tiga peran akses: role-sens-internal, , role-sens-confidentialrole-sens-restricted.

Filter baris UDF:

CREATE FUNCTION sensitivity_allowed(row_sensitivity STRING) RETURNS BOOLEAN
DETERMINISTIC
RETURN CASE
  WHEN current_user() = 'role-sens-restricted' THEN TRUE
  WHEN current_user() = 'role-sens-confidential' THEN row_sensitivity IN ('internal', 'confidential')
  WHEN current_user() = 'role-sens-internal' THEN row_sensitivity = 'internal'
  ELSE FALSE
END;

Kebijakan:

CREATE POLICY sensitivity_filter
ON CATALOG corp_data
ROW FILTER sensitivity_allowed
TO `account users`
FOR TABLES
MATCH COLUMNS has_tag('sensitivity') AS sens
USING COLUMNS (sens);

Karena sebuah peran bukan anggota dirinya sendiri, UDF ini membandingkan current_user() dengan setiap nama peran, alih-alih menguji keanggotaan dengan is_account_group_member(). Lihat catatan di atas mengapa pengujian keanggotaan tidak cocok dengan peran yang diasumsikan. Lihat Pertimbangan performa untuk filter baris dan kebijakan masker kolom untuk karakteristik performa fungsi identitas di UDF.

Perilaku:

• Pengguna yang saat menggunakan identitas penggunanya tidak melihat baris apa pun. Cabang ELSE FALSE cocok dengan apa pun yang bukan salah satu dari tiga peran. Seperti dalam contoh per proyek di atas, ini adalah penolakan default yang dimaksudkan.
• Dengan asumsi role-sens-internal hanya menampilkan internal baris.
• Dengan anggapan bahwa role-sens-confidential menampilkan baris internal dan confidential.
• Dengan mengasumsikan role-sens-restricted menampilkan semua baris.

Pengguna mengasumsikan tingkat tertinggi yang mereka butuhkan untuk sesi tersebut; filter secara otomatis mengecualikan semua yang di atas tingkat tersebut tanpa mengharuskan pengguna untuk mengetahui tabel mana yang menyimpan klasifikasi mana.

Atribusi audit

Baik evaluasi kebijakan ABAC maupun kueri yang mendasarinya menghormati atribusi RBAC run_as / run_by . Entri log audit mencatat identity_metadata.run_by sebagai pengguna autentikasi dan identity_metadata.run_as sebagai peran yang diasumsikan, terlepas dari kebijakan ABAC mana yang diterapkan selama evaluasi. Lihat Referensi tabel sistem log audit untuk skema log audit lengkap.

Langkah berikutnya

• Akses eksklusif model: Terapkan pola untuk menyiapkan akses eksklusif menggunakan grup lokal akun atau grup yang disinkronkan dari Microsoft Entra ID. Lihat akses eksklusif ke model.
• Beralih peran: Gunakan peran melalui pengalih peran, klaster mode akses khusus, CLI, API, atau alat BI pihak ketiga. Lihat Beralih peran.
• Kelola Izin Asumsikan: Berikan atau cabut Asumsikan pada grup sehingga pengguna dapat mengasumsikan peran yang sesuai. Lihat Mengelola izin pada grup.
• Tinjau konsep inti ABAC: Pelajari cara kerja tag, kebijakan, dan evaluasi kebijakan yang diatur. Lihat Kontrol akses berbasis atribut di Unity Catalog.