OneLake güvenliği veri erişimini nasıl kontrol eder?

OneLake güvenliği, OneLake'te kimlerin verilere erişebileceğini ve bu veriler üzerinde hangi işlemleri yapabileceklerini belirleyen rol tabanlı bir sistemdir. Veri erişim kontrol modelini anlamak, kullanıcılara sadece ihtiyaç duydukları erişimi sağlar, böylece hassas verileri koruyabilir ve doğru kişilerin onlarla çalışmasına izin verebilirsiniz.

Bu makale, OneLake güvenlik rollerinin nasıl yapılandırıldığını, çalışma alanı ve öğe izinleriyle nasıl entegre olduklarını, OneLake'in verilerinize erişimi nasıl uyguladığını ve çözdüğünü ve akılda tutulmanız gereken sınırları açıklar.

OneLake güvenlik rolleri

OneLake güvenliği, OneLake'te verilere erişimi yönetmek için rol tabanlı erişim kontrolü (RBAC) modeli kullanır. OneLake güvenlik deneyiminde, her rol aşağıdaki bileşenlere sahiptir:

  • İzinler: Rolün veriler üzerinde verdiği izinler; örneğin Okuma veya Okuma-Yazma.
  • Tip: Rol türü. OneLake güvenliği yalnızca Grant rollerini destekler; bu roller, üyelerine roldeki verilere erişim izni verir. Erişimi kaldıran Reddet rollerini desteklemiyor.
  • Rolde veri: Rolun erişim sağladığı tablolar, klasörler veya şemalar. Ayrıca veri erişimini tabelalarda satır seviyesinde ve sütun seviyesinde güvenlik ile tanımlayabilirsiniz.
  • Görevdeki üyeler: Göreve atanmış Microsoft Entra kimlikleri; örneğin kullanıcılar, gruplar veya kullanıcı dışı kimlikler. Bir Microsoft Entra grubu atarsanız, OneLake güvenliği bu rolü grubun tüm üyelerine verir.

OneLake güvenliği, varsayılan olarak reddetme modeli kullanır; bu nedenle kullanıcılar, OneLake güvenlik rolü açıkça erişim izni vermedikçe verilere erişimi olmadan başlar. Bazı Fabric öğeleri, kullanıcılara çalışma alanı izinlerine göre temel erişim sağlayan varsayılan rollerle başlar.

İzinler ve desteklenen öğeler

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

  • Okumak: Kullanıcıya tablodaki verileri okuma ve ilişkili tablo ile sütun meta verilerini görüntüleme olanağı verir. SQL terimlerinde, bu izin hem VIEW_DEFINITION de SELECTile eşdeğerdir. Daha fazla bilgi için bakınız: Metaveri güvenliği.
  • ReadWrite: Kullanıcıya bir tablo veya klasördeki verileri okuma ve yazma ile ilgili tablo ile sütun meta verilerini görüntüleme imkanı tanır. SQL terimlerinde, bu izin , DROP, UPDATE, ve INSERTile eşdeğerdirALTER. Daha fazla bilgi için ReadWrite iznine bakınız.

Aşağıdaki Fabric öğeleri için OneLake güvenlik rolleri oluşturabilirsiniz:

Kumaş parçası Desteklenen izinler
Göl kenarı evi Okuma, Okuma Yazma
Azure Databricks yansıtılmış katalog Okundu
Yansıtılmış veritabanları Okundu
Yansıtılmış kataloglar Okundu

Okuma/Yazma izni

ReadWrite izni, yalnızca okunan kullanıcılara bir öğedeki belirli verilere yazma erişimi vermek için kullanın.

ReadWrite yalnızca bir öğede okuma iznine sahip kullanıcılara, örneğin Viewer çalışma alanı rolüne sahip kullanıcılara uygulanır. ReadWrite'ı bir çalışma alanı yöneticisi, üyesi veya katkı sağlayıcısına atamak hiçbir etki yaratmaz çünkü bu çalışma alanı rolleri zaten yazma erişimine sahiptir.

ReadWrite, Okuma izniyle verilen tüm ayrıcalıkları içerir ve ayrıca seçilen nesne ve içeriğine yazma erişimi tanır. Örneğin, bir klasördeki ReadWrite izni, hem klasöre hem de içindeki verilere yazma hakkı tanır.

ReadWrite iznine sahip kullanıcılar aşağıdaki işlemleri gerçekleştirebilir:

  • Bir klasör veya tablo oluştur, sil veya yeniden adlandır.
  • Bir dosya yükleyin veya düzenleyin.
  • Bir kısayyolu oluşturun, silin veya yeniden adlandırın.

Kullanıcılar, Spark defterleri, OneLake dosya gezintisi veya OneLake API'leri aracılığıyla yazma işlemleri gerçekleştirebilirler. Fabric yalnızca tek motorlu veriye yazmayı desteklediği için, ReadWrite iznine sahip kullanıcılar bu veriye yalnızca OneLake üzerinden yazabilir. Tüm sorgulama motorları okuma işlemlerini tutarlı şekilde zorunlu kılmaya devam eder.

ReadWrite izni veren OneLake güvenlik rolleri, satır düzeyinde güvenlik (RLS) veya sütun düzeyinde güvenlik (CLS) kısıtlamaları içeremez.

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

Çalışma alanı rolleri, OneLake'te veri için ilk güvenlik sınırıdır. Kontrol düzlemini yönetiyorlar - Fabric öğeleri ve izinleri oluşturup yönetiyorlar - ve çalışma alanındaki tüm öğelere uygulanıyor. Her çalışma alanı rolünün sağladığı belirli OneLake izinleri için bkz. Çalışma alanı rolleriyle erişim verme. İş alanı rolleri hakkında daha fazla bilgi edinmek için Fabric'te Çalışma Alanlarında Roller bölümüne bakınız.

Kontrol düzlemi erişiminin ötesinde, çalışma alanı rolleri OneLake güvenlik varsayılan rolleri aracılığıyla veri öğelerine erişim sağlayabilir. (Varsayılan roller yalnızca İzleyiciler için geçerlidir, çünkü Yönetici, Üye ve Katkıda Bulunan roller Yazma izni üzerinden yükseltilmiş erişime sahiptir.) Varsayılan rol, Fabric'in her yeni öğeyle otomatik olarak oluşturduğu 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 varsayılan erişim, yeni oluşturulan bir öğeyle çalışan kullanıcıların temel bir erişim seviyesine sahip olmasını sağlar. Tüm varsayılan roller üye sanallaştırma özelliğini kullanır; bu sayede rolün üyeleri, ilgili çalışma alanında gerekli izne sahip tüm kullanıcılardır. Örneğin, lakehouse üzerinde ReadAll iznine sahip tüm kullanıcılar.

Aşağıdaki tablo standart varsayılan rolleri göstermektedir. Eşyaların yalnızca o eşya türüne uygulanan özel varsayılan rolleri olabilir.

Kumaş parçası Rol adı İzin verildi Atanan üyeler
Göl kenarı evi DefaultReader Okundu ReadAll izni olan tüm kullanıcılar
Azure Databricks yansıtılmış katalog DefaultReader Okundu Okuma izni olan tüm kullanıcılar
Aynalı katalog DefaultReader Okundu Okuma izni olan tüm kullanıcılar
Yansıtılmış veritabanı DefaultReader Okundu ReadAll izni olan tüm kullanıcılar

Bir Fabric öğesinden varsayılan rolü değiştirebilir veya kaldırarak o üye grubundaki kullanıcıların erişimini değiştirebilirsiniz.

Verilere altyapı ve kullanıcı erişimi

OneLake güvenliği varsayılan olarak en az ayrıcalıklı erişime geçer. Bazı depolama düzeyindeki işlemler RLS veya CLS’yi uygulayamaz; bu nedenle bir sorgu güvenli bir şekilde filtrelenemediğinde OneLake, kullanıcının görme iznine sahip olmadığı verilerin açığa çıkması riskini almak yerine sorguyu tamamen engeller. Bir sorgu filtrelenip engellenmediği erişim yoluna bağlıdır - desteklenen bir sorgu motoru veya doğrudan kullanıcı erişimi.

RLS ve CLS filtrelemeyi destekleyen motorlar ve her birine yönelik gereksinimler için bkz. OneLake güvenliğiyle korunan verileri okuma.

Kapsam ve uygulama

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üzeyinde güvenlik

OneLake tüm tabloları klasör olarak temsil eder, ancak Fabric'teki OneLake güvenlik ve sorgu motorları açısından tüm klasörler tablo değildir. Geçerli bir tablo olmak için bir klasörün aşağıdaki koşulları karşılaması gerekir:

  • Klasör, bir öğenin dizininde bulunur Tables/ . Şema etkin öğeler için, klasörün de geçerli bir şema klasöründe olması gerekir.
  • Klasör, tablo meta verileri için karşılık gelen JSON dosyalarının bulunduğu bir _delta_log klasör içerir.
  • Klasörde herhangi bir çocuk kısayolu yok.

Bir tabloda RLS veya CLS yapılandırırsanız, OneLake tablonun klasörü bu kriterleri karşılamadığında erişimi reddeder. RLS veya CLS olmadan, OneLake bu kriterleri karşılamayan bir klasörü klasör olarak kabul eder ve klasör düzeyinde güvenlik uygular.

Satır düzeyi ve sütun düzeyi güvenlik

Bir rol içinde, satır düzeyinde güvenlik ve sütun düzeyinde güvenlik kullanarak bir tablonun belirli satır ve sütunlarına erişimi kısıtlayabilirsiniz. Her kontrolün ne yaptığı ve OneLake'in bunu nasıl uyguladığı hakkında daha fazla bilgi için OneLake'te tablo, sütun ve satır düzeyinde güvenlik sayfasına bakınız. Bir kullanıcı birden fazla role ait olduğunda RLS ve CLS'nin nasıl çözüldüğü hakkında bilgi için Birden fazla OneLake güvenlik rolünü değerlendirin bkz.

Meta veri güvenliği

OneLake güvenliğinin Okuma izni tablodaki verilere ve meta verilere tam erişim verir. Tabloya erişimi olmayan kullanıcılar için veriler hiçbir zaman gösterilmez. Bu kural ayrıca sütun düzeyindeki güvenlik ve kullanıcının o tablodaki bir sütunu görüp görmeme yeteneği için de geçerlidir. Ancak OneLake güvenliği, bir tablonun meta verilerine erişilemez olacağını garanti etmez. Bazı hata mesajları ve deneyimler sütun adlarını gösterebilir.

Klasör izinlerinin devralınması ve gezinme

Klasör izinleri, hiyerarşiyi iki yönde etkiler:

  • Miras: Bir klasöre verilen izinler, dosyalarına ve alt klasörlerine aşağıya doğru uygulanır.
  • Geçiş ve listeleme: Kullanıcıların bir çocuk öğe üzerinde izni olduğunda, OneLake güvenliği ana klasörlerini listelemeye ve gezinmesine olanak tanır, böylece erişebilecekleri verileri bulup gezilebilebilirler. Traversal, kardeş dosyalarına veya klasörlere erişim izni vermez.

OneLake'deki bir göl evinin aşağıdaki hiyerarşisini düşünün:

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

Role1 üzerinde subfolder11 izni veren bir rol oluşturursunuz. Devralma yoluyla, bu rolün üyeleri file111.txt öğesini ve subfolder111 içindeki her şeyi okuyabilir. Üyeler folder1 öğesini görüntüleyebilir ve onu geçerek file11.txt öğesine ulaşabilir, ancak subfolder11 öğesini göremezler çünkü Tables öğesinin kardeşidir; ayrıca Files öğesini de göremezler çünkü subfolder11 öğesinin kardeşidir.

Files/
│
└───folder1
│   │
│   └───subfolder11 <-- READ
│       │   file111.txt
│       │
│       └───subfolder111
│            │   file1111.txt

folder2 üzerinde Okuma izni veren başka bir rol, Role2, oluşturuyorsunuz. Kalıtım yoluyla üyeler file21.txt okuyabilir. Üyeler, ona ulaşmak için folder2 ve Files üzerinden geçebilir, ancak folder1’yi veya onun alt öğelerinden hiçbirini göremezler.

Files/
│
└───folder2 <-- READ
    │   file21.txt

Kestirmelerde davranış biraz farklıdır. Dış veri kaynaklarına yapılan kısayollar, klasörler gibi davranır. Ancak, diğer OneLake konumlarına yönelik kısayollar özel bir davranış sergiler. Kısayolun hedef izinleri OneLake kısayolu erişimini belirler. Kısayolları listelerken, OneLake hedef erişimi kontrol etmek için arama yapmaz. Sonuç olarak, bir dizini listelediğinizde, OneLake hedefe erişiminiz ne olursa olsun tüm dahili kısayolları döndürür. Erişim kontrolü, kısayyolu açmayı denediğinizde değerlendirir ve sadece gerekli izinlere sahip olduğunuz verileri görürsünüz.

Kısayollar

OneLake güvenliği, OneLake içindeki ve dışındaki verilerin güvenliğini sağlamak için kısayollarla entegre çalışır. Kısayollar iki doğrulama modundan birini kullanır:

  • Geçiş: Kısayol, hedefe erişmek için sorgulayan kullanıcının kimliğini kullanır. Doğrudan geçiş, OneLake'ten OneLake'e kısayollar için varsayılan yöntemdir.
  • Devredilmiş: Kısayol, hedefe erişmek için yapılandırılmış bir bağlantı kimliği veya kimlik bilgisi kullanır. OneLake'den OneLake'e kısayollar devredilmiş kimlik doğrulama kullanabilir ve dış sistemlere yapılan kestirmeler her zaman devredilmiş kimlik doğrulamasını kullanır.

Bir kısayol oluşturmak, hem kısayolun oluşturulduğu yol hem de hedef yol üzerinde izinler gerektirir. Her kısayol türünü oluşturma ve bu türe erişim gereksinimleri için OneLake kısayol güvenliği sayfasına bakın.

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

Bir kullanıcı, OneLake'ten OneLake'e geçiş kestirmesi yoluyla veriye eriştiğinde, OneLake hedef yola erişimi yetkilendirmek için çağıran kullanıcının kimliğini kullanır. Kullanıcının etkili erişimi, hem kısayol yolu hem de hedef yol üzerindeki izinleriyle sınırlıdır.

Uyarı

Sorgu motoru kimliği ve kısayol doğrulama ayrı ayarlardır. Geçiş kestirmesi genellikle hedefe erişmek için çağıran kullanıcının kimliğini kullanır. Ancak, delege edilmiş kimlik modunda SQL üzerinde Direct Lake kullanan Power BI semantik modelleri ve SQL analitik uç noktaları, tüketici öğesinin veya veri kaynağının sahip kimliğini kullanır. Bu davranış, kısayyolun yapılandırılmış kimlik doğrulama modunu değiştirmez. Uçtan uca kullanıcı kimliği geçişi için, OneLake üzerinden Direct Lake kullanın veya SQL analitik uç noktasını kullanıcı kimliği erişim modunu kullanacak şekilde yapılandırın.

OneLake’ten OneLake’e bir kısayol üzerinde OneLake güvenlik izinlerini doğrudan tanımlayamazsınız. Kısayyolu içeren klasördeki izinler, hedef yol üzerindeki izinlerle birleşir. Hedef öğe OneLake güvenliğini destekliyorsa, kullanıcının OneLake güvenlik rolü üzerinden erişim sağlaması gerekir. Hedef öğe OneLake güvenliğini desteklemiyorsa, kullanıcı hedef öğe üzerinde Fabric ReadAll iznine ihtiyaç duyar. Kullanıcı, yalnızca hedef öğenin verisine kısayol üzerinden erişmek için Fabric Read iznine ihtiyaç duymaz.

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

Devredilen kısayollar, hedefe erişmek için çağrı yapan kullanıcının kimliği yerine yapılandırılmış bağlantı kimliği veya kimlik bilgilerini kullanır. OneLake güvenliği, arayan kullanıcının bu bağlantı üzerinden erişebileceği şeyleri sınırlar.

Yetkilendirilmiş OneLake kısayolları

Yetkilendirilmiş bir OneLake’ten OneLake’e kısayolda, isteği yapan kullanıcı, kısayol yolundaki kendi erişim hakları ile hedef yolda yapılandırılmış bağlantı kimliğinin erişim haklarının kesişimini görür. Her iki yolda da sütun düzeyinde güvenlik (CLS) desteklenir. Hedef yolda satır düzeyinde güvenlik (RLS) destekleniyor, ancak kısayol yolunda RLS tanımlanamaz.

Atanan dış kısayollar

ADLS, Amazon S3 ve Dataverse gibi harici sistemlere yapılan kısayollar, dış kaynağa erişmek için yapılandırılmış bağlantı kimlik bilgisi kullanır. OneLake güvenliği, bu kimlik bilgileriyle sağlanan erişimin üzerine uygulanır.

Örneğin, user1 Amazon S3 kovasındaki bir klasöre bir göl evi kısayolu oluşturuyor ve user2 göl evinden kısayolaya erişiyor. User2, yalnızca yapılandırılmış S3 bağlantı kimlik bilgisi kaynağa erişebiliyorsa ve OneLake güvenliği User2’ye kısayol yoluna erişim yetkisi veriyorsa S3 verilerine erişebilir.

OneLake güvenlik sistemine tüm dış kısayollara veya seçilmiş alt yollara erişim verebilirsiniz. Bir klasördeki izinler, kısayol içindeki klasörler dahil olmak üzere tüm alt klasörlerine özyinelemeli olarak devralır. Başka bir OneLake kısayolu üzerinden harici bir kısayola erişen kullanıcının, orijinal harici kısayola uygulanan OneLake güvenliği kapsamında yine de yetkilendirilmesi gerekir.

Spark veya doğrudan OneLake API çağrısı üzerinden harici bir kısayole erişmek için de, harici kısayolası içeren öğe üzerinde Fabric Read izni gereklidir. Bu izin, harici sisteme olan bağlantıyı güvenli bir şekilde çözmek için gereklidir.

Birden fazla OneLake güvenlik rolünü değerlendirin

Bir kullanıcı, birden fazla OneLake güvenlik rolünde yer alabilir. OneLake, bu rollerin sağladığı erişimi etkili bir role dönüştürür ve kullanıcının erişebileceği verileri belirler. OneLake, etkin rolü aşamalı olarak değerlendirir.

Her rol içinde erişimi çöz

OneLake önce her rolü bağımsız olarak çözer. Bir rol içinde, bir kullanıcı yalnızca üç güvenlik bileşeninin izin verdiği verilere erişebilir:

  • Nesne düzeyindeki güvenlik (OLS), rolun hangi tablolara veya klasörlere erişebileceğini belirler.
  • Satır düzeyindeki güvenlik (RLS), rolun belirli bir tablonun hangi satırlarına erişebileceğini sınırlar.
  • Sütun düzeyinde güvenlik (CLS), rolun belirli bir tablonun hangi sütunlarına erişebileceğini sınırlar.

Üç bileşenin tümü uygulandığı için OneLake, bu üçünün kesişimini esas alır. Örneğin, Role1 Tablo1'e erişim izni verip satır ve sütunlarını kısıtlarsa, Role1 için çözülen erişim şudur:

Role1 = R1_OLS ∩ R1_RLS ∩ R1_CLS

Kesişim sembolü (∩), kullanıcının yalnızca OLS, RLS ve CLS tarafından bu rolde izin verilen erişimi aldığı anlamına gelir.

Roller arasında erişimi birleştirin

Her rol çözümlendikten sonra OneLake, rolleri birleşim yani en az kısıtlayıcı yaklaşımını kullanarak birleştirir. Birlik sembolü (∪), herhangi bir rolün sağladığı erişimin etkili rolün bir parçası haline geldiği anlamına gelir. Role1 TableA'ya erişim verirse ve Role2 TableB'ye erişim izni verirse, her iki role ait bir kullanıcı her iki tabloya da erişebilir.

İki rol için etkin rol şudur:

Effective role = Role1 ∪ Role2

Birden fazla rol aynı tabloya erişim izni verdiğinde, satır düzeyindeki güvenlik kuralları bir OR operatörle birleşir. Örneğin, city = 'New York' ve city = 'Redmond' izin veren predikatlar city = 'Redmond' OR city = 'New York' olarak birleştirilir.

Sütun düzeyindeki güvenlik kuralları da, SQL analiz uç noktası dışında, birleşim olarak uygulanır. SQL analitiği uç noktasında, CLS daha katı bir reddetme semantiği kullanır. Herhangi bir rol bir sütunu gizlerse, uç nokta o sütuna erişimi engeller. Sonuç olarak, uç nokta, tüm kullanıcı rolleri üzerindeki CLS izin listeleriyle kesişir, bunları bir birleşik olarak birleştirmek yerine.

Önemli

Aynı rolde birlikte uygulanması gereken RLS ve CLS kurallarını koruyun. OneLake, iki rolün bir tablo için farklı sütun setine izin verdiği ve her iki rolün de o tabloya RLS uyguladığı bir rol kombinasyonunu desteklemez. Örneğin, bir kullanıcı c1 ve c2 sütunlarına ve satırların bir alt kümesine izin veren Role1'e ve c2 ile c3 sütunlarına izin veren Role2'ye ait olamaz.

Kısayolu ve hedef erişimini birleştir

Bir kısayolda OneLake, kısayol konumundaki ve kısayol hedefindeki rolleri ayrı ayrı değerlendirir. Hedef roller, kısayol konumunda çıkarımsanan roller haline gelir. OneLake daha sonra kısayol rollerinden gelen birleşik erişimi ve çıkarılan hedef rollerden gelen birleşik erişimi kesiştirir. Bu adım, kısayol konumundan devralınan erişimin hedef üzerindeki kısıtlamaları geçersiz kılmasını engeller.

İki kısayol rolü ve iki çıkarımsanan hedef rol için geçerli erişim şudur:

Effective shortcut access = (ShortcutRole1 ∪ ShortcutRole2) ∩ (InferredRole1 ∪ InferredRole2)

Bu ifadede ShortcutRole1 ve ShortcutRole2 kısa yol konumundaki rollerdir. InferredRole1 ve InferredRole2, kısayol hedefinden çıkarımı yapılan karşılık gelen rollerdir. OneLake rolleri birleştirmeden önce, her rol OLS, RLS ve CLS bileşenlerine göre belirlenir.

OneLake güvenlik sınırlamaları

  • Bir B2B konuk kullanıcısına OneLake güvenlik rolü atarsanız, Microsoft Entra Dış Kimliği'nde B2B için dış işbirliği ayarlarınızı yapılandırmanız gerekir. Misafir kullanıcı erişim ayarını Misafirler üyelerle aynı erişime sahip (en kapsayıcı) olarak ayarlayın.

  • OneLake güvenliğindeki bir role dağıtım listesi eklerseniz, SQL analytics uç noktası erişimi zorlamak için listenin üyelerini çözümleyemez. Sonuç olarak, kullanıcılar SQL analitik uç noktasına eriştiklerinde rolün üyesi gibi görünmemektedir. SQL anlamsal modellerdeki Direct Lake de bu sınırlamaya tabidir.

  • Spark not defterleri, ortam sürümünün 3.5 veya üzeri olmasını ve Fabric çalışma zamanı 1.3'ün kullanılmasını gerektirir.

  • Şemasız lakehouse’lar, RLS ve CLS ile güvenliği sağlanan tablolarda veri önizlemeyi desteklemez. OneLake güvenliğiyle şema özellikli lakehouse’lar kullanın.

  • OneLake güvenliği, Azure Veri Paylaşımı veya Purview Veri Paylaşımı ile çalışmaz. Daha fazla bilgi için bkz. Azure Veri Paylaşımı.

  • Aşağıdaki tablo OneLake güvenlik rollerinin sınırlamalarını listelemektedir.

    Senaryo Sınır
    Kumaş Öğesi başına maksimum OneLake güvenlik rolü sayısı Her öğe için 250 rol (nota bakınız)
    OneLake güvenlik rolü başına en fazla üye sayısı Rol başına 500 kullanıcı veya kullanıcı grubu
    OneLake güvenlik rolü başına en fazla izin sayısı Rol başına 500 izin

    Uyarı

    Her öğe başına rol sayısını 1.000'e çıkarma talep edebilirsiniz. Artış istemek için Azure Desteği'ne başvurun.

Gecikme süreleri

Rol tanımlarında yapılan değişikliklerin uygulanması yaklaşık 5 dakika sürer.

OneLake güvenlik rolündeki bir kullanıcı grubunda değişiklik yapmanın ve güncellenmiş kullanıcı grubuna rolün izinlerinin uygulanmasının OneLake için yaklaşık bir saat sürdüğünü unutmayın. Bazı Fabric altyapılarının kendi önbellekleme katmanı vardır, bu yüzden tüm sistemlerde erişimi güncellemenin bir saat daha alabileceğini dikkate almak gerekebilir.

İlgili içerik

  • Last updated on