RBAC’yi ABAC ile kullan

Important

RBAC , Genel Önizleme aşamasındadır. ABAC genel olarak kullanılabilir. Bu sayfada, ikisinin birlikte nasıl çalıştığı açıklanmaktadır.

Unity Kataloğu'nda rol tabanlı erişim denetimi (RBAC) ve öznitelik tabanlı erişim denetimi (ABAC), birlikte çalışmak üzere tasarlanmış tamamlayıcı denetimlerdir. Farklı soruları yanıtlarlar:

• RBAC , bir kullanıcının oturum için hangi kimliği kullandığını denetler. Kullanıcı, kendi izinleri yerine o rolün izinleriyle işlem yapmak için bir rolü üstlenir. RBAC kullanarak bir kullanıcıya açıkça geçiş yaptıkları birkaç farklı izin kümesi (örneğin, klinik denemeler, projeler veya duyarlılık katmanları arasında erişimi ayırma) sağlayın.
• ABAC , etkin kimliğin hangi verileri görebileceğini, satıra göre satıra veya sütuna göre sütuna göre denetler. İlkeler , yönetilen etiketler aracılığıyla verilere eklenir ve sorguyu çalıştıran kimliğe uygulanır. Veri öznitelikleri tarafından yönetilen birçok tabloda tutarlı filtreleme veya maskeleme için ABAC kullanın.

RBAC, oturum için etkin kimliği ayarlar ve ABAC, ilkelerini bu kimliğe göre değerlendirir. Bu sayfa bu etkileşimin pratikte nasıl yürütüldüğünü, kimlikle ilgili SQL işlevlerinin davranışını ve birleştirilmiş kullanım desenlerini kapsar.

Rol varsayılırken kimlik işlevleri nasıl davranır?

Unity Kataloğu kimlik ile ilgili SQL işlevleri, altta yatan kimliği doğrulayan kullanıcıya değil, oturumun etkin kimliğine göre çözümlenir. Bir kullanıcı bir rolü üstlendiğinde, etkin oturum kimliği rol kimliği haline gelir:

Function	Kullanıcı kendi kullanıcı kimliğiyle işlem yaptığında	Kullanıcı bir rol varsaydığında
current_user()	Kullanıcının kullanıcı adını döndürür	Varsayılan rolün adını verir
is_member(group)	Kullanıcı grubun bir üyesiyse (çalışma alanına özgü bir grup veya çalışma alanına atanmış bir hesap grubu) true döndürür.	true yalnızca üstlenilen rolün kendisi de group üyesiyse döndürür. Temeldeki kullanıcının üyesi olduğu, ancak üstlenilen rolün üyesi olmadığı gruplar için false döndürür.
is_account_group_member(group)	Kullanıcı hesap düzeyi grubunun üyesiyse döndürür true	is_member ile aynı: true yalnızca altta yatan kullanıcının değil, üstlenilen rolün grup üyeliklerine göre döndürür.

Bu işlevlere atıfta bulunan ABAC ilkeleri, kullanıcıya göre değil, üstlenilen role göre değerlendirilir. Varsayılan rol, ABAC ilkesi değerlendirmesi, Unity Kataloğu verme çözümlemesi ve denetim ilişkilendirmesi için etkin kimliktir. Sonuç olarak, bir rol üstlenmek, kullanıcı kimliği temelinde oluşturulmuş mevcut ilkelerin ve görünümlerin davranışını değiştirir.

Note

Bir rol, otomatik olarak kendisinin üyesi değildir. Bir kullanıcı G rolünü üstlendiğinde, current_user()G döndürür; ancak G açıkça kendisinin bir üyesi olarak eklenmedikçe is_member('G') ve is_account_group_member('G')false döndürür. Bir ilkedeki üstlenilen rolle eşleşmek için, üyeliği is_member veya is_account_group_member ile test etmek yerine current_user() ile karşılaştırın.

Yaygın tuzak: yerleşik satır düzeyi güvenlik görünümleri current_user()

ABAC ve tablo düzeyindeki satır filtrelerinde ortak olan yaygın bir örüntü, current_user() tarafından döndürülen kullanıcı adına göre anahtarlanmış bir provizyon tablosuyla (eşleme tablosu veya erişim denetim listesi olarak da adlandırılır) birleştirerek satırları filtrelemektir. Örneğin:

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
);

Aynı kullanıcı bir rol varsaydığında, current_user() artık kullanıcı adını döndürmez. Rolün adını döndürür. Rol sağlama tablosunda olmadığından, filtre hiçbir satır döndürmez ve kullanıcı kendilerine verilen verilere erişimi kaybetmiş gibi görünür.

Rolü provisioning tablosuna ekleyin

Rolü sağlama verilerinizde başka bir sorumlu olarak değerlendirin: Rolün görmesi gereken olanaklarla (veya diğer özniteliklerle) rol başına bir satır ekleyin. Filtre daha sonra etkin kimliğin kullanıcı mı yoksa varsayılan rol mü olduğuyla eşleşir.

Karma kullanım desenleri

Aşağıda, müşterilerin gerçek erişim denetimi sorunlarını çözmek için RBAC ve ABAC'yi nasıl birlikte kullandığına ilişkin örnekler verilmiştir. Bunlar başlangıç noktaları, kapsamlı tarifler değil.

Üstlenilen role göre proje başına satır filtreleri

Satırları projeye göre filtrelemek klinik deneme araştırmalarında, sözleşme pazarlamasında, müşteri danışmanlığında ve bir ekibin birkaç yalıtılmış projede çalıştığı diğer ayarlarda yaygın bir ihtiyaçtır. Aşağıdaki örnek klinik araştırmaları temel alır, ancak bu yaklaşım proje bazında veri yalıtımının her türü için genellenebilir.

Bir klinik araştırma kuruluşu, her biri kendi erişim rolünde çeşitli eşzamanlı denemeler çalıştırır. Her tabloyu proje tanımlayıcısıyla etiketleyin. Kullanıcılar yalnızca şu anda üstlendikleri role ait projenin satırlarını görür.

Kurulum:

• clinical_trials.* altındaki tablolar, governed etiketiproject anahtarıyla etiketlenmiş bir project_id sütununa sahiptir.
• Her projenin adlı role-<project> karşılık gelen bir erişim rolü vardır (örneğin, , role-alpharole-beta).
• Kullanıcılar, yalnızca üzerinde çalıştıkları projelerin rolleri için Assume iznine sahiptir.

Satır filtresi UDF:

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

İlke:

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);

Bu UDF, etkin kimliği her satırın project etiket değeriyle ilişkilendirir; bu nedenle TO / EXCEPT gibi principal hedefleyen koşullar bunu ifade edemez — çünkü bunlar satır içeriğini değil, principal’ları hedefler. Asıl hedefleme kılavuzunda açıklandığı gibi, tek bir kuralın hem etkin kimliğe hem de satırın içeriğine bağlı olduğu bu gibi durumlar için bir UDF'de basit asıl kapsam belirleme ve kimlik işlevlerini ayırmayı tercih edinTO / EXCEPT.

Tek bir ilke her projeyi kapsar: USING COLUMNS (project) Her satırın etiket değerini UDF'ye project geçirir, bu nedenle proje başına ayrı bir ilkeye ihtiyacınız olmaz. Bu tekniğin genel biçimi (rol adı eşleştirmesi yerine arama tablosundan satır erişimi sağlama) için bkz. Dinamik erişim denetimi için eşleme tablolarını kullanma.

Davranış:

• Kendi kullanıcı kimliğiyle işlem yapan bir kullanıcı, herhangi bir clinical_trials tabloda hiç satır görmez. current_user(), role-* adlandırma düzeniyle hiçbir zaman eşleşmeyen kullanıcı adını döndürür. Bu, hedeflenen varsayılan reddetmedir.
• role-alpha rolünü üstlenen bir kullanıcı yalnızca project_id'in alpha olduğu satırları görür. role-beta öğesine geçmek, başka hiçbir şeyi yeniden sorgulamadan görünür verileri değiştirir.

Belirlenmiş bir rolde hareket eden kullanıcılar için PII maskelemesi esnetilir

Varsayılan olarak, PII sütunları (SSN, e-posta, telefon) herkes için maskelenmiş olarak görünür. Ham değerleri görebilmek için kullanıcının açıkça belirlenmiş, PII erişim yetkisine sahip bir rolü üstlenmesi gerekir. Denetim günlükleri rol üstlenme olayını kaydeder; böylece “gerçek PII’ye bakmam gerekiyordu” ifadesi, örtük bir izin olmak yerine denetlenebilir, açıkça seçilen bir işlem hâline gelir.

Kurulum:

• Hassas sütunlar, governed etiketi anahtarı pii ile etiketlenir (örneğin ssn, email, phone gibi izin verilen değerlerle).
• Adı role-pii-cleared olan bir erişim rolü, ham PII’yi görüntüleme yetkisi verilen kullanıcılara Assume izniyle verilir.

Sütun maskeleme UDF’si (statik — ilke, hangi güvenlik öznelerinin maskeleneceğini hedefler):

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

İlke:

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;

EXCEPT koşulu, role-pii-cleared öğesini politikadan tamamen hariç tutar; bu nedenle, etkin kimlik bu rol olduğunda UDF hiçbir zaman çağrılmaz. Güvenlik sorumlusu hedeflemesi için TO/EXCEPT kullanmayı tercih etme başlıklı bölüme, TO / EXCEPT aracılığıyla güvenlik sorumlusu hedeflemesine ilişkin genel yönergeler için bakın.

Davranış:

• Kendi kullanıcı kimliğiyle işlem yapan bir kullanıcı, her PII sütununda *** ifadesini görür. Bu, role-pii-cleared üzerinde Assume iznine sahip olan kullanıcılar da dahil olmak üzere herkes için varsayılan durumdur.
• varsaydıktan role-pii-clearedsonra ilke artık oturum için geçerli değildir ve aynı kullanıcı ham değerleri görür.
• Oturum kaydı identity_metadata.run_as = role-pii-clearediçin denetim günlüğü girdileri, böylece gözden geçirenler PII'nin maskesinin ne zaman ve kim tarafından kaldırıldığını tam olarak görebilir.

Varsayılan role göre değişen duyarlılık katmanı ilkeleri

Veriler duyarlılık katmanlarına (internal, confidential, restricted) sınıflandırılır. Her katmanın karşılık gelen bir erişim rolü vardır; restricted, aynı zamanda confidential ve internal erişimini de kapsar. Tek satırlık filtre UDF’si, her satırın katmanını kullanıcının varsayılan rolüyle karşılaştırarak satır görünürlüğünü denetler.

Kurulum:

• Tablolarda, sensitivity_levelgoverned etiketi anahtarıyla etiketlenmiş bir sensitivity sütun bulunur (izin verilen değerler: internal, confidential, restricted).
• Üç erişim rolü: role-sens-internal, role-sens-confidential, role-sens-restricted.

Satır filtresi 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;

İlke:

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);

Bir rol kendisinin üyesi olmadığından, bu UDF is_account_group_member() ile üyeliği test etmek yerine current_user() öğesini her rol adıyla karşılaştırır. Üyelik testlerinin kabul edilen rolle neden eşleşmediğini öğrenmek için yukarıdaki nota bakın. UDF'lerdeki kimlik işlevlerinin performans özellikleri için bkz. Satır filtresi ve sütun maskesi ilkeleri için performansla ilgili dikkat edilmesi gerekenler .

Davranış:

• Kendi kullanıcı kimliğiyle işlem yapan bir kullanıcı hiçbir satır görmez. ELSE FALSE dalı, bu üç rolden hiçbiri olmayan her şeyle eşleşir. Yukarıdaki proje başına örnekte olduğu gibi, hedeflenen varsayılan reddetme budur.
• role-sens-internal öğesinin yalnızca internal satır gösterdiği varsayıldığında.
• role-sens-confidential ögesinin internal ve confidential satırlarını ortaya çıkardığını varsayalım.
• role-sens-restricted öğesinin tüm satırları gösterdiği varsayıldığında.

Kullanıcılar oturum için ihtiyaç duydukları en yüksek katmanı varsayar; filtre, kullanıcının hangi tabloların hangi sınıflandırmaları barındırdığını bilmesine gerek kalmadan bu katmanın üzerindeki her şeyi otomatik olarak dışlar.

Denetim ilişkilendirmesi

Hem ABAC ilke değerlendirmeleri hem de altta yatan sorgular, RBAC run_as / run_by atfına uyar. Denetim günlüğü girişleri, değerlendirme sırasında hangi ABAC ilkelerinin uygulandığından bağımsız olarak kimlik doğrulaması yapan kullanıcı ve identity_metadata.run_by varsayılan rol olarak kaydediliridentity_metadata.run_as. Denetim günlüğünün tam şeması için Denetim günlüğü sistem tablosu başvurusuna bakın.

Sonraki Adımlar

• Modele özel erişim: Hesaba yerel bir grup veya Microsoft Entra ID’den eşitlenen bir grup kullanarak özel erişim ayarlamaya yönelik düzenleri kullanın. Bkz. Modele özel erişim.
• Anahtar rolleri: Rol değiştiriciyi, ayrılmış erişim modu kümelerini, CLI'yı, API'yi veya üçüncü taraf BI araçlarını kullanarak rol varsayın. Bkz . Rolleri değiştirme.
• Varsayma izinlerini yönetme: Kullanıcıların ilgili rolü üstlenebilmesi için bir grupta Varsay'a izin verin veya iptal edin. Bkz. Bir gruptaki izinleri yönetme.
• ABAC temel kavramlarını gözden geçirin: yönetilen etiketlerin, ilkelerin ve ilke değerlendirmenin nasıl çalıştığını öğrenin. Bkz. Unity Kataloğu'nda öznitelik tabanlı erişim denetimi.