OneLake güvenlik erişim denetimi modeli (önizleme)

Bu belge, OneLake güvenlik erişim denetimi modelinin nasıl çalıştığına ilişkin ayrıntılı bir kılavuz sağlar. Rollerin nasıl yapılandırıldığına, verilere nasıl uygulandığına ve Microsoft Fabric içindeki diğer yapılarla tümleştirmenin ne olduğuna ilişkin ayrıntılar içerir.

OneLake güvenlik rolleri

OneLake güvenliği, OneLake'deki verilere erişimi yönetmek için rol tabanlı erişim denetimi (RBAC) modeli kullanır. Her rol birkaç önemli bileşenden oluşur.

Tür: Rolün erişim verip vermediği (GRANT) veya erişimi kaldırdığı (REDDET). Yalnızca GRANT türü rolleri desteklenir.
İzin: Verilen veya reddedilen belirli eylem veya eylemler.
Kapsam: İzni olan OneLake nesneleri. Nesneler tablolar, klasörler veya şemalardır.
Üyeler: Role atanan kullanıcılar, gruplar veya kullanıcısız kimlikler gibi herhangi bir Microsoft Entra kimliği. Rol, bir Microsoft Entra grubunun tüm üyelerine verilir.

Bir role üye atadığınızda, bu kullanıcı bu rolün kapsamında ilişkili izinlere tabi olur. OneLake güvenliği varsayılan olarak reddet modeli kullandığından, OneLake güvenlik rolü tarafından açıkça verilmediği sürece tüm kullanıcılar verilere erişim olmadan başlar.

İzinler ve desteklenen öğeler

OneLake güvenlik rolleri aşağıdaki izni destekler:

Okumak: Kullanıcıya tablodaki verileri okuma ve ilişkili tablo ile sütun meta verilerini görüntüleme olanağı verir. SQL açısından bu izin hem VIEW_DEFINITION hem de SELECT ile eşdeğerdir. Daha fazla bilgi için bkz. Meta veri güvenliği.
ReadWrite: Kullanıcıya tablo veya klasörden veri okuma ve yazma ve ilişkili tablo ve sütun meta verilerini görüntüleme olanağı verir. SQL açısından bu izin ALTER, DROP, UPDATE ve INSERT ile eşdeğerdir. Daha fazla bilgi için bkz . Okuma Yazma izni.

OneLake güvenliği, kullanıcıların yalnızca aşağıdaki Doku öğeleri için veri erişim rolleri tanımlamasını sağlar.

Kumaş parçası	Statü	Desteklenen izinler
Göl kenarı evi	Public Preview	Okuma, Okuma Yazma
Azure Databricks Yansıtılmış Kataloğu	Public Preview	Okundu
Yansıtılmış Veritabanları	Public Preview	Okundu

OneLake güvenlik ve çalışma alanı izinleri

Çalışma alanı izinleri, OneLake içindeki veriler için ilk güvenlik sınırıdır. Her çalışma alanı, ekiplerin veriler üzerinde işbirliği yapabilecekleri tek bir etki alanını veya proje alanını temsil eder. Fabric çalışma alanı rolleri aracılığıyla çalışma alanında güvenliği yönetirsiniz. Doku rol tabanlı erişim denetimi (RBAC) hakkında daha fazla bilgi edinin: Çalışma alanı rolleri

Doku çalışma alanı rolleri, çalışma alanı içindeki tüm öğelere uygulanan izinler verir. Aşağıdaki tabloda çalışma alanı rollerinin izin verdiği temel izinler özetlenmiştir.

İzin	Yönetici	Üye	Katkıda Bulunan	Görüntüleyici
OneLake'te dosyaları görüntüleme	Her Zaman* Evet	Her Zaman* Evet	Her Zaman* Evet	Varsayılan olarak hayır. Erişim vermek için OneLake güvenliğini kullanın.
OneLake'te dosya yazma	Her Zaman* Evet	Her Zaman* Evet	Her Zaman* Evet	Hayır
OneLake güvenlik rollerini düzenleyebilir	Her Zaman* Evet	Her Zaman* Evet	Hayır	Hayır

*Çalışma Alanı Yöneticisi, Üye ve Katkıda Bulunan rolleri Otomatik olarak OneLake'e Yazma izinleri verdiğinden, tüm OneLake güvenlik Okuma izinlerini geçersiz kılar.

Çalışma alanı rolleri, denetim düzlemi veri erişimini yönetir, yani Doku yapıtlarını ve izinlerini oluşturma ve yönetme ile etkileşimler anlamına gelir. Ayrıca çalışma alanı rolleri, OneLake güvenlik varsayılan rollerini kullanarak veri öğelerine varsayılan erişim düzeyleri de sağlar. (Yönetici, Üye ve Katkıda Bulunan, Yazma izni aracılığıyla yükseltilmiş erişime sahip olduğundan, varsayılan rollerin yalnızca Görüntüleyiciler için geçerli olduğunu unutmayın) Varsayılan rol, her yeni öğeyle otomatik olarak oluşturulan normal bir OneLake güvenlik rolüdür. Belirli çalışma alanı veya öğe izinlerine sahip kullanıcılara bu öğedeki verilere varsayılan erişim düzeyi verir. Örneğin Lakehouse öğeleri, ReadAll iznine sahip kullanıcıların Lakehouse'daki verileri görmesine olanak tanıyan bir DefaultReader rolüne sahiptir. Bu, yeni oluşturulan bir öğeye erişen kullanıcıların temel erişim düzeyine sahip olmasını sağlar. Tüm varsayılan roller bir üye sanallaştırma özelliği kullanır, böylece rolün üyeleri bu çalışma alanında gerekli izne sahip herhangi bir kullanıcı olur. Örneğin, Lakehouse üzerinde ReadAll izni olan tüm kullanıcılar. Aşağıdaki tabloda standart varsayılan rollerin ne olduğu gösterilmektedir. Öğeler yalnızca bu öğe türüne uygulanan özelleştirilmiş varsayılan rollere sahip olabilir.

Kumaş parçası	Rol adı	İzin	Eklenen klasörler	Atanan üyeler
Göl kenarı evi	`DefaultReader`	Okundu	`Tables/` ve `Files/` altındaki tüm klasörler	ReadAll izni olan tüm kullanıcılar
Göl kenarı evi	`DefaultReadWriter`	Okundu	Tüm klasörler	Yazma izni olan tüm kullanıcılar

Uyarı

Erişimi belirli kullanıcılara veya belirli klasörlere kısıtlamak için varsayılan rolü değiştirin veya kaldırın ve yeni bir özel rol oluşturun.

OneLake güvenlik ve öğe izinleri

Çalışma alanı içinde, Fabric öğelerinin izinleri çalışma alanı rollerinden bağımsız olarak yapılandırılabilir. bir öğeyi paylaşarak veya öğenin izinlerini yöneterek izinleri yapılandırabilirsiniz. Aşağıdaki izinler, kullanıcının OneLake'deki veriler üzerinde eylem gerçekleştirebilmesini belirler. Öğe paylaşımı hakkında daha fazla bilgi için bkz. Lakehouse paylaşımı nasıl çalışır?

İzin	OneLake'te dosyaları görüntüleyebilir misiniz?	OneLake'te dosya yazabilir mi?	SQL analytics uç noktası üzerinden veri okuyabilir misiniz?
Okundu	Varsayılan olarak hayır. Erişim vermek için OneLake güvenliğini kullanın.	Hayır	Hayır
Tümünü Oku	DefaultReader rolü aracılığıyla evet. Erişimi kısıtlamak için OneLake güvenliğini kullanın.	Hayır	Hayır*
Yazmak	Evet	Evet	Evet
Yürütme, Yeniden Paylaşma, Çıktıyı Görüntüle, Günlükleri Görüntüle	Yok - kendi başına verilemiyor	Yok - kendi başına verilemiyor	Yok - kendi başına verilemiyor

* SQL analiz uç noktası moduna bağlıdır.

Rol oluşturma

Lakehouse veri erişim ayarlarınız aracılığıyla OneLake güvenlik rollerini tanımlayabilir ve yönetebilirsiniz.

Daha fazla bilgi için veri erişim rollerini kullanmaya başlama rehberine göz atın.

Verilere altyapı ve kullanıcı erişimi

OneLake'e veri erişimi iki yoldan biriyle gerçekleşir:

Doku sorgu altyapısı aracılığıyla veya
Kullanıcı erişimi aracılığıyla (Doku dışı altyapılardan gelen sorgular kullanıcı erişimi olarak kabul edilir)

OneLake güvenliği, verilerin her zaman güvenli kalmasını sağlar. Satır ve sütun düzeyi güvenlik gibi bazı OneLake güvenlik özellikleri depolama düzeyi işlemleri tarafından desteklenmediğinden, satır veya sütun düzeyinde güvenli verilere her tür erişime izin verilmez. Bu, kullanıcıların izin verilmedikleri satırları veya sütunları göremeyeceklerini garanti eder. Microsoft Fabric altyapıları, veri sorgularına satır ve sütun düzeyinde güvenlik filtrelemesi uygulamak için etkinleştirilir. Başka bir deyişle, bir kullanıcı üzerinde OneLake güvenlik RLS veya CLS bulunan bir lakehouse veya başka bir öğedeki verileri sorguladığında, kullanıcının gördüğü sonuçlarda gizli satırlar ve sütunlar kaldırılır. OneLake'te RLS veya CLS bulunan verilere kullanıcı erişimi için, erişim isteyen kullanıcının bu tablodaki tüm satır veya sütunları görmesine izin verilmiyorsa sorgu engellenir.

Aşağıdaki tabloda hangi Microsoft Fabric altyapılarının RLS ve CLS filtrelemesini desteklediği özetlenmiştir.

Motor	RLS/CLS filtreleme	Statü
Göl kenarı evi	Evet	Genel önizleme
Spark not defterleri	Evet	Genel önizleme
"Kullanıcının kimlik modunda" SQL Analytics Uç Noktası	Evet	Genel önizleme
OneLake modunda DirectLake kullanan anlamsal modeller	Evet	Genel önizleme
Eventhouse	Hayır	Planned
Veri ambarı dış tabloları	Hayır	Planned

OneLake güvenlik erişim denetimi modeli ayrıntıları

Bu bölümde OneLake güvenlik rollerinin belirli kapsamlara nasıl erişim sağladığı, bu erişimin nasıl çalıştığı ve erişimin birden çok rol ve erişim türü arasında nasıl çözümlendiğinin ayrıntıları sağlanır.

Tablo düzeyi güvenlik

Tüm OneLake tabloları göldeki klasörlerle temsil edilir, ancak göldeki tüm klasörler Doku'daki OneLake güvenlik ve sorgu altyapıları açısından tablolar değildir. Geçerli bir tablo olarak kabul edilmesi için aşağıdaki koşulların karşılanması gerekir:

Klasör, bir öğenin Tablolar/ dizininde bulunur.
klasör, tablo meta verileri için karşılık gelen JSON dosyalarını içeren bir _delta_log klasörü içerir.
Klasör herhangi bir alt kısayol içermiyor.

Bu ölçütleri karşılamayan tablolar üzerinde tablo düzeyi güvenlik yapılandırılırsa erişim reddedilir.

Meta veri güvenliği

OneLake güvenliğinin verilere Okuma erişimi, tablodaki verilere ve meta verilere tam erişim sağlar. Tabloya erişimi olmayan kullanıcılar için veriler hiçbir zaman gösterilmez. Bu, sütun düzeyi güvenliği ve kullanıcının bu tablodaki bir sütunu görme veya görmeme özelliği için de geçerlidir. Ancak OneLake güvenliği, bir tablonun meta verilerine erişilmeyeceğini garanti etmez.

İzin devralma

Belirli bir klasör için OneLake güvenlik izinleri her zaman klasörün dosyalarının ve alt klasörlerinin hiyerarşisinin tamamına devralır.

Örneğin, OneLake'de aşağıdaki bir göl evi hiyerarşisini göz önünde bulundurun:

Tables/
──── (empty folder)
Files/
────folder1
│   │   file11.txt
│   │
│   └───subfolder11
│       │   file1111.txt
|       │
│       └───subfolder111
|            │   file1111.txt
│   
└───folder2
    │   file21.txt

Bu göl evi için iki rol oluşturacaksınız. Role1 klasör1 için okuma izni verir ve Role2 klasör2 için okuma izni verir.

Verilen hiyerarşi için OneLake güvenlik izinleri Role1 aşağıdaki şekilde devralır Role2 :

Rol1: Klasörü okuma1

│   │   file11.txt
│   │
│   └───subfolder11
│       │   file1111.txt
|       │
│       └───subfolder111
|            │   file1111.txt

Rol2: Klasörü okuma2
```
    │   file21.txt
```

OneLake güvenliği kapsamında dolaşım ve listeleme

OneLake güvenliği, verilerin kolayca bulunabilmesi için üst öğeler arasında otomatik geçiş sağlar. Kullanıcıya alt klasör11'e Okuma izinleri vermek, kullanıcıya üst dizin klasörünü listeleme ve çapraz geçiş yapma olanağı verir1. Bu işlev, bir alt klasöre erişim vermenin üst dizinler için bulma ve çapraz geçiş sağladığı Windows klasör izinlerine benzer. Ebeveyne verilen liste ve erişim, doğrudan ebeveynlerin dışındaki diğer öğelere/klasörlere genişletilmez, bu da diğer klasörlerin güvenli kalmasını sağlar.

Örneğin, OneLake'de aşağıdaki bir göl evi hiyerarşisini göz önünde bulundurun.

Tables/
──── (empty folder)
Files/
────folder1
│   │   file11.txt
│   │
│   └───subfolder11
│       │   file111.txt
|       │
│       └───subfolder111
|            │   file1111.txt
│   
└───folder2
    │   file21.txt

Verilen hiyerarşi için , 'Role1' için OneLake güvenlik izinleri aşağıdaki erişimi sağlar. file11.txt erişimi, alt klasörün üst klasörü olmadığından görünür değildir11. Role2 için de benzer şekilde file111.txt de görünmez.

Rol1: Alt klasörü okuma11

Files/
────folder1
│   │
│   └───subfolder11
│       │   file111.txt
|       │
│       └───subfolder111
|            │   file1111.txt

Rol2: Alt klasörü okuma111

Files/
────folder1
│   │
│   └───subfolder11
|       │
│       └───subfolder111
|            │   file1111.txt

Kısayollar için listeleme davranışı biraz farklıdır. Dış veri kaynaklarına yönelik kısayollar klasörlerle aynı şekilde davranır, ancak diğer OneLake konumlarına yönelik kısayolların özel davranışları vardır. Kısayolun hedef izinleri OneLake kısayolu erişimini belirler. Kısayolları listelerken, hedef erişimi denetlemek için çağrı yapılmaz. Sonuç olarak, bir dizin listelenirken, kullanıcının hedefe erişimi ne olursa olsun tüm iç kısayollar döndürülür. Kullanıcı kısayolu açmaya çalıştığında erişim denetimi değerlendirilir ve kullanıcı yalnızca görmek için gerekli izinlere sahip olduğu verileri görür. Kısayollar hakkında daha fazla bilgi için kısayollar güvenlik bölümüne bakın.

Kısayolları içeren aşağıdaki klasör hiyerarşisini göz önünde bulundurun.

Files/
────folder1
│   
└───shortcut2
|
└───shortcut3

Rol1: Klasörü okuma1

Files/
────folder1
│   
└───shortcut2
|
└───shortcut3

Rol2: Tanımlı izin yok

Files/
│   
└───shortcut2
|
└───shortcut3

Satır düzeyi güvenlik

OneLake güvenliği, kullanıcıların kullanıcıya gösterilen verileri sınırlamak için SQL önkoşulları yazarak satır düzeyi güvenlik belirtmesine olanak tanır. RLS, koşulun true olarak değerlendirildiği satırları göstererek çalışır. Daha fazla bilgi için satır düzeyi güvenliğine bakın.

Satır düzeyi güvenlik, sıralama ve karşılaştırmalar için aşağıdaki harmanlamayı kullanarak dize verilerini büyük/küçük harfe duyarsız olarak değerlendirir: Latin1_General_100_CI_AS_KS_WS_SC_UTF8

Satır düzeyi güvenliği kullanırken, RLS deyimlerinin temiz ve anlaşılması kolay olduğundan emin olun. Sıralama için tamsayı sütunlarını kullanın ve işlemlerden büyük veya küçüktür. Giriş verilerinin biçimini bilmiyorsanız, özellikle unicode karakterleri veya vurgu duyarlılığıyla ilgili olarak dize denkliklerinden kaçının.

Sütun düzeyi güvenlik

OneLake güvenliği, kullanıcının bir sütuna erişimini kaldırarak (gizleyerek) sütunlara erişimi sınırlamayı destekler. Gizli bir sütun, kendisine atanmış izinlere sahip değil olarak değerlendirilir ve bu da erişim yok varsayılan ilkesiyle sonuçlanır. Gizli sütunlar kullanıcılara görünmez ve gizli sütunları içeren verilerde yapılan sorgular bu sütun için veri döndürmez. Meta veri güvenliğinde belirtildiği gibi, bir sütunun meta verilerinin bazı hata iletilerinde görünmeye devam ettiği bazı durumlar vardır.

Sütun düzeyi güvenlik ayrıca reddetme semantiği aracılığıyla çalışarak SQL Uç Noktası'nda daha katı bir davranış izler. SQL Uç Noktası'ndaki bir sütunda reddetme, birden çok rol bir araya gelerek erişim vermek için bir araya gelse bile sütuna tüm erişimin engellenmesini sağlar. Sonuç olarak, SQL Uç Noktası'ndaki CLS, diğer tüm izin türleri için geçerli birleşim davranışı yerine bir kullanıcının parçası olduğu tüm roller arasında bir kesişim kullanarak çalışır. Rollerin nasıl bir araya getirildiği hakkında daha fazla bilgi için Birden çok OneLake güvenlik rolünü değerlendirme bölümüne bakın.

Okuma/Yazma izni

ReadWrite izni, salt okunur kullanıcılara belirli öğelere yazma işlemleri gerçekleştirme olanağı sağlar. Okuma Yazma izni yalnızca Görüntüleyiciler veya bir öğe üzerinde Okuma izni olan kullanıcılar için geçerlidir. Yönetici, Üye veya Katkıda Bulunana ReadWrite erişimi atamanın herhangi bir etkisi yoktur, çünkü bu roller bu izne zaten örtük olarak sahiptir.

ReadWrite erişimi kullanıcıların Spark not defterleri, OneLake dosya gezgini veya OneLake API'leri aracılığıyla yazma işlemleri gerçekleştirmesini sağlar. İzleyiciler için Lakehouse UX üzerinden yazma işlemleri desteklenmez.

ReadWrite izni aşağıdaki yollarla çalışır:

ReadWrite izni, Okuma izni tarafından verilen tüm ayrıcalıkları içerir.
Nesne üzerinde ReadWrite izinlerine sahip kullanıcılar bu nesne üzerinde yazma işlemleri (dahil) gerçekleştirebilir. Başka bir ifadeyle, herhangi bir işlem nesnenin kendisinde de gerçekleştirilebilir.
ReadWrite aşağıdaki eylemlere izin verir:
- Yeni klasör veya tablo oluşturma
- Klasör veya tablo silme
- Klasörü veya tabloyu yeniden adlandırma
- Dosya yükle veya düzenle
- Kısayol oluşturma
- Kısayolu silme
- Kısayolu yeniden adlandırma
ReadWrite erişimine sahip OneLake güvenlik rolleri RLS veya CLS kısıtlamaları içeremez.
Fabric, verilere yalnızca tek motorlu veri yazmalarını desteklediğinden, bir nesne üzerinde ReadWrite iznine sahip kullanıcılar sadece OneLake aracılığıyla verilere yazabilir. Ancak Okuma işlemleri, tüm sorgulama motorları aracılığıyla tutarlı bir şekilde uygulanır.

Kısayollar

Kısayollara genel bakış

OneLake güvenliği, OneLake içindeki ve dışındaki verilerin kolayca güvenli hale getirilebilmesini sağlamak için OneLake'deki kısayollarla tümleşir. Kısayollar için iki ana kimlik doğrulama modu vardır:

Geçiş kısayolları (SSO): Hangi verilerin görülmesine izin verileceğini belirlemek için sorgulayan kullanıcının kimlik bilgileri kısayol hedefine göre değerlendirilir.
Temsilcili kısayollar: Kısayol, hedefe erişmek için sabit bir kimlik bilgisi kullanır ve sorgulayan kullanıcı, temsilci kimlik bilgilerinin kaynağa erişimini denetlemeden önce OneLake güvenliğine karşı değerlendirilir.

Ayrıca, OneLake'te herhangi bir kısayol oluşturulurken OneLake güvenlik izinleri değerlendirilir. Kısayol güvenlik belgesindeki kısayol izinleri hakkında bilgi edinin.

Geçiş kısayollarında OneLake güvenliği

OneLake klasöründeki güvenlik kümesi, kısayol kaynak yoluna erişimi kısıtlamak için her zaman iç kısayollar arasında akar. Kullanıcı başka bir OneLake konumuna giden bir kısayol aracılığıyla verilere eriştiğinde, kısayolun hedef yolundaki verilere erişimi yetkilendirmek için çağıran kullanıcının kimliği kullanılır. Sonuç olarak, bu kullanıcının verileri okuyabilmesi için hedef konumda OneLake güvenlik izinlerine sahip olması gerekir.

Önemli

DirectLake kullanarak SQL veya T-SQL altyapıları üzerinden Power BI anlam modelleri aracılığıyla kısayollara erişirken, Temsilci kimlik modunda çağıran kullanıcının kimliği kısayol hedefine iletilmez. Bunun yerine çağıran öğe sahibinin kimliği geçirilir ve arayan kullanıcıya erişim yetkisi velanır. Bu sorunu çözmek için OneLake modu üzerinden DirectLake'te Power BI anlam modellerini veya Kullanıcının kimlik modunda T-SQL'i kullanın.

İç kısayol için OneLake güvenlik izinlerinin tanımlanmasına izin verilmez ve hedef öğede bulunan hedef klasörde tanımlanmalıdır. Hedef öğe, OneLake güvenlik rollerini destekleyen bir öğe türü olmalıdır. Hedef öğe OneLake güvenliğini desteklemiyorsa, kullanıcının erişimi hedef öğe üzerinde DokuTüm Okuma iznine sahip olup olmadığına göre değerlendirilir. Kullanıcıların bir öğeye kısayol aracılığıyla erişebilmesi için Doku Okuma iznine sahip olması gerekmez.

Temsilci kısayollarında OneLake güvenliği

OneLake, ADLS, S3 ve Dataverse kısayolları gibi kısayollar için izin tanımlamayı destekler. Bu durumda izinler, bu tür bir kısayol için etkinleştirilen temsilci yetkilendirme modelinin üzerine uygulanır.

Kullanıcı1'in bir lakehouse'ta AWS S3 bucket'ında bir klasöre işaret eden bir S3 kısayolu oluşturduğunu varsayalım. Ardından user2 bu kısayoldaki verilere erişmeye çalışır.

S3 bağlantısı, temsilci olarak atanan kullanıcı1 için erişim yetkisi veriyor mu?	OneLake güvenliği, istekte bulunan kullanıcı2 için erişim yetkisi verir mi?	Sonuç: Kullanıcı2, S3 Kısayolu'nda verilere erişebilir mi?
Evet	Evet	Evet
Hayır	Hayır	Hayır
Hayır	Evet	Hayır
Evet	Hayır	Hayır

OneLake güvenlik izinleri, kısayolun tüm kapsamı veya seçili alt klasörler için tanımlanabilir. Bir klasörde ayarlanan izinler, kısayol içinde olsa bile alt klasörlere art arda uygulanır. Dış kısayolda ayarlanan güvenlik, tüm kısayola veya kısayol içindeki herhangi bir alt yola erişim izni vermek için belirlenebilir. Dış kısayola işaret eden başka bir iç kısayol, kullanıcının özgün dış kısayola erişmesini gerektirir.

OneLake güvenliğindeki diğer erişim türlerinden farklı olarak, dış kısayola erişen bir kullanıcı, dış kısayolun bulunduğu veri öğesinde Doku Okuma izni gerektirir. Bu, dış sisteme bağlantıyı güvenli bir şekilde çözümlemek için gereklidir.

OneLake kısayolları S3, ADLS ve Dataverse kısayolları hakkında daha fazla bilgi edinin.

Birden çok OneLake güvenlik rolünü değerlendirme

Kullanıcılar, her biri verilere kendi erişimini sağlayan birden çok farklı OneLake güvenlik rolünün üyesi olabilir. Bu rollerin birlikte birleşimi "etkili rol" olarak adlandırılır ve kullanıcının OneLake'teki verilere erişirken göreceği şey budur. Roller, UNION veya en az kısıtlayıcı model kullanarak OneLake güvenliğinde birleştirilir. Bu, Rol1'in TableA'ya ve Role2'nin TabloB'ye erişim vermesi durumunda kullanıcının hem TableA hem de TableB'yi görebileceği anlamına gelir.

OneLake güvenlik rolleri, bir tablonun satır ve sütunlarına erişimi sınırlayan satır ve sütun düzeyi güvenlik de içerir. Her RLS ve CLS ilkesi bir rol içinde bulunur ve bu rol içindeki tüm kullanıcılar için verilere erişimi sınırlar. Örneğin, Rol1 Tablo1'e erişim veriyorsa, ancak Tablo1'de RLS varsa ve tablo1'in yalnızca bazı sütunlarını gösteriyorsa, Rol1 için geçerli rol Tablo1'in RLS ve CLS alt kümeleri olacaktır. Bu durum (R1ols n R1cls n R1rls) olarak ifade edilebilir; burada n, roldeki her bileşenin KESIŞIM noktasıdır.

Birden çok rolle ilgilenirken, RLS ve CLS ilgili tablolarda UNION semantiğiyle birleştirilir. CLS, her rolde görünen tabloların doğrudan ayarlanmış BIR UNION'dır. RLS, or işleci kullanılarak koşullarda birleştirilir. Örneğin WHERE city = 'Redmond' OR city = 'New York'.

Her biri RLS veya CLS olan birden çok rolü değerlendirmek için, her rol önce rolün kendisi tarafından verilen erişime göre çözümlenir. Bu, tüm nesne, satır ve sütun düzeyi güvenliğinin KESIŞimini değerlendirmek anlamına gelir. Daha sonra değerlendirilen her rol, UNION işlemi aracılığıyla bir kullanıcının üyesi olduğu diğer tüm rollerle birleştirilir. Çıkış, bu kullanıcı için etkili bir roldür. Bu, şu şekilde ifade edilebilir:

( (R1ols n R1cls n R1rls) u (R2ols n R2cls n R2rls) )

Son olarak, bir göl evindeki her kısayol, kısayol hedefinin izinlerini sorgulanan öğeye yaymak için kullanılan bir dizi çıkarılmış rol oluşturur. Çıkarsanan roller, kısayol göl evindeki rollerle birleştirilmeden önce kısayol hedefinde ilk olarak çözümlenmeleri dışında, çıkarılmış rollere benzer şekilde çalışır. Bu, shortcut lakehouse üzerindeki izin devralma işleminin bozulmasını ve çıkarsanan rollerin doğru şekilde değerlendirilmesini sağlar. Daha sonra tam birleşim mantığı şu şekilde ifade edilebilir:

( (R1ols n R1cls n R1rls) u (R2ols n R2cls n R2rls) ) n ( (R1'ols n R1'cls n R1'rls) u (R2'ols n R2'cls n R2'rls)) )

Burada R1' ve R2' çıkarsanan roller, R1 ve R2 ise lakehouse kısayolu rolleridir.