Not
Bu sayfaya erişim yetkilendirme gerektiriyor. Oturum açmayı veya dizinleri değiştirmeyi deneyebilirsiniz.
Bu sayfaya erişim yetkilendirme gerektiriyor. Dizinleri değiştirmeyi deneyebilirsiniz.
OneLake güvenliği ile, Microsoft Fabric kuruluşların iş yükleri arasında veri erişimini yönetme ve uygulama şeklini genişletiyor. Bu yeni güvenlik çerçevesi, yöneticilere izinleri yapılandırma esnekliği sağlar. Yöneticiler , OneLake aracılığıyla merkezi idare veya SQL analiz uç noktası içindeki ayrıntılı SQL tabanlı denetim arasında seçim yapabilir.
SQL analiz uç noktası erişim modları
SQL analiz uç noktasını kullanırken, seçili access modu veri güvenliğinin nasıl zorunlu kılındığını belirler. Fabric, her birinin operasyonel ve uyumluluk gereksinimlerinize bağlı olarak farklı avantajlar sunduğu iki erişim modelini destekler.
Kullanıcı kimliği modu: OneLake rollerini ve politikalarını kullanarak güvenliği sağlar. Bu modda, SQL analytics uç noktası oturum açmış kullanıcının kimliğini OneLake'e geçirir ve read access tamamen OneLake içinde tanımlanan güvenlik kurallarına tabidir. Tablolarda SQL düzeyinde izinler desteklenir ve Power BI, not defterleri ve lakehouse gibi araçlar arasında tutarlı idare sağlar.
Temsilci kimlik modu: SQL aracılığıyla tam denetim sağlar. Bu modda SQL analytics uç noktası, çalışma alanı veya öğe sahibinin kimliğini kullanarak OneLake'e bağlanır ve güvenlik yalnızca veritabanında tanımlanan SQL izinleri tarafından yönetilir . Bu model GRANT, REVOKE, özel roller, Row-Level Güvenlik ve Dinamik Veri Maskeleme gibi geleneksel güvenlik yaklaşımlarını destekler.
Her mod farklı idare modellerini destekler. Bunların etkilerini anlamak, Ağ yapısı ortamınızda doğru yaklaşımı seçmek için gereklidir.
erişim modları arasındaki karşılaştırma
Aşağıda, kullanıcı kimliği modunda ve temsilci kimlik modunda güvenliği nasıl ve nerede ayarladığınıza odaklanan ve nesne türüne ve veri access ilkelerine göre ayrılmış açık ve kısa bir karşılaştırma tablosu aşağıdadır:
| Güvenlik hedefi | Kullanıcı kimliği modu | Temsilci kimlik modu |
|---|---|---|
| Tables | Erişim, OneLake güvenlik rolü tarafından kontrol edilir. SQL'e GRANT/REVOKE izin verilmez. |
SQL GRANT/REVOKEkullanarak tam denetim. |
| Görüntülenme Sayısı | İzinleri atamak için SQL GRANT/REVOKE kullanın. | İzinleri atamak için SQL GRANT/REVOKE kullanın. |
| Saklı prosedürler | İzinleri atamak için SQL GRANT EXECUTE kullanın. | İzinleri atamak için SQL GRANT EXECUTE kullanın. |
| Functions | İzinleri atamak için SQL GRANT EXECUTE kullanın. | İzinleri atamak için SQL GRANT EXECUTE kullanın. |
| Satır Düzeyi Güvenliği (RLS) | OneLake kullanıcı arabiriminde OneLake güvenlik rollerinin bir parçası olarak tanımlanır. | SQL CREATE SECURITY POLICY kullanılarak tanımlanır. |
| Kolon Seviyesi Güvenlik (CLS) | OneLake kullanıcı arabiriminde OneLake güvenlik rollerinin bir parçası olarak tanımlanır. | Sütun listesiyle SQL GRANT SELECT kullanılarak tanımlanır. |
| Dinamik Veri Maskeleme (DDM) | OneLake güvenliğinde desteklenmez. |
ALTER TABLE SQL, MASKED seçeneğiyle kullanılarak tanımlanır. |
OneLake güvenliğinde kullanıcı kimliği modu
Kullanıcı kimliği modunda SQL analytics uç noktası, veri erişimini zorlamak için passthrough kimlik doğrulama mekanizması kullanır. Bir kullanıcı SQL analiz uç noktasına bağlandığında, Entra Kimliği kimliği, izin denetimini gerçekleştiren OneLake'e geçirilir. Tablolara yönelik tüm okuma işlemleri, SQL düzeyi GRANT veya REVOKE deyimleri tarafından değil, OneLake Lakehouse içinde tanımlanan güvenlik kuralları kullanılarak değerlendirilir.
Bu kip, güvenliği merkezi olarak yönetmenize olanak tanır ve Power BI, not defterleri, lakehouse ve SQL analiz uç noktası dahil olmak üzere tüm Doku deneyimlerinde tutarlı bir uygulama sağlar. OneLake'te bir kez tanımlanması ve her yerde otomatik olarak uygulanması gereken yönetim modelleri için tasarlanmıştır.
Kullanıcı kimliği modunda:
Tablo erişimi tamamen OneLake güvenliği tarafından yönetilir. Tablolardaki SQL GRANT/REVOKE deyimleri yoksayılır.
RLS (Row-Level Güvenlik), CLS (Column-Level Güvenlik) ve OLS (Object-Level Güvenlik) OneLake deneyiminde tanımlanır.
Görünümler, saklı yordamlar ve işlevler gibi veri dışı nesneler için SQL izinlerine izin verilir ve verilere özel mantık veya kullanıcıya yönelik giriş noktaları tanımlama esnekliği sağlanır.
Yazma işlemleri SQL analiz uç noktasında desteklenmez. Tüm yazma işlemleri Doku portalındaki Lakehouse sayfasından gerçekleşmelidir ve çalışma alanı rolleri (Yönetici, Üye, Katkıda Bulunan) tarafından yönetilir.
Önemli
SQL Analytics Uç Noktası, öğe izinleri ile OneLake güvenlik rolündeki üyeler arasında doğru eşitleme yapmak için bire bir eşleme gerektirir. Bir kimliğe OneLake güvenlik rolüne erişim verirseniz, aynı kimliğin veri gölü evi için de Fabric Okuma iznine sahip olması gerekir. Örneğin, bir kullanıcı OneLake güvenlik rolüne "user123@microsoft.com" atarsa, "user123@microsoft.com" de bu lakehouse'a atanması gerekir.
Çalışma alanı rolü davranışı
Çalışma alanı düzeyinde Yönetici, Üye veya Katkıda Bulunan rolüne sahip kullanıcılar OneLake güvenlik uygulamasına tabi değildir. Bu rollerin artırılmış ayrıcalıkları vardır ve RLS, CLS ve OLS politikalarını tamamen atlar. OneLake güvenliğine uyulmasını sağlamak için şu gereksinimleri izleyin:
Kullanıcılara çalışma alanında Görüntüleyici rolünü atayın veya
Lakehouse veya SQL analytics uç noktasını salt okunur izinleri kullanarak kullanıcılarla paylaşın. Yalnızca salt okunur erişime sahip kullanıcıların sorguları, OneLake güvenlik rollerine göre filtrelenir.
Rol önceliği: En fazla izin verilen erişim kazanır
Bir kullanıcı birden fazla OneLake rolüne aitse, en geniş izinli rol etkili erişimini tanımlar. Örneğin:
Bir rol tabloya tam access verirse ve başka bir rol satırları kısıtlamak için RLS uygularsa, RLS uygulanmaz.
Erişim rolü daha geniş olan önce gelir. Bu davranış, kullanıcıların istemeden engellenmemesini sağlar, ancak çakışmaları önlemek için dikkatli bir rol tasarımı gerektirir. Satır veya sütun düzeyinde erişim kontrolleri uygulanırken kısıtlayıcı ve izinli rollerin birbirini dışlayan şekilde tutulması önerilir.
Daha fazla bilgi için OneLake güvenliği için veri erişim kontrol modeline bakın.
OneLake ile SQL analytics uç noktası arasında güvenlik eşitlemesi
Kullanıcı kimliği modunun kritik bileşenlerinden biri güvenlik eşitleme hizmetidir. Bu arka plan hizmeti OneLake'te güvenlik rollerinde yapılan değişiklikleri izler ve bu değişikliklerin SQL analiz uç noktasına yansıtılmasını sağlar.
Güvenlik eşitleme hizmeti aşağıdakilerden sorumludur:
Yeni roller, güncelleştirmeler, kullanıcı atamaları ve tablolardaki değişiklikler dahil olmak üzere OneLake rollerindeki değişiklikleri algılama.
OneLake tanımlı ilkeleri (RLS, CLS, OLS) eşdeğer SQL uyumlu veritabanı rol yapılarına çevirme.
Kısayol nesnelerinin (diğer lakehouse'lardan alınan tablolar) düzgün bir şekilde doğrulandığından emin olunması, uzaktan erişildiğinde bile özgün OneLake güvenlik ayarlarının yerine getirilmesini sağlar.
Bu eşitleme, OneLake güvenlik tanımlarının otoriter kalmasını sağlayarak güvenlik davranışını çoğaltmak için SQL düzeyinde manuel müdahaleye olan ihtiyacı ortadan kaldırır. Güvenlik merkezi olarak uygulandığı için:
Bu modda T-SQL kullanarak RLS, CLS veya OLS'yi doğrudan tanımlayamazsınız.
GRANT veya EXECUTE deyimlerini kullanarak görünümlere, işlevlere ve saklı yordamlara SQL izinleri uygulamaya devam edebilirsiniz.
Güvenlik eşitleme hataları ve çözümü
| Scenario | Kullanıcı kimliği modunda davranış | Temsilci modunda davranış | Düzeltici eylem | Notes |
|---|---|---|---|---|
| RLS ilkesi silinmiş veya yeniden adlandırılmış bir sütuna başvurur | Hata: *Satır düzeyi güvenlik ilkesi artık mevcut olmayan bir sütuna başvurur.*Veritabanı, ilke düzeltene kadar hata durumuna girer. | Hata: Geçersiz sütun adı <sütun adı> | Etkilenen bir veya daha fazla rolü güncelleştirin veya kaldırın ya da eksik sütunu geri yükleyin. | Güncelleştirmenin rolün oluşturulduğu göl evinde yapılması gerekir. |
| CLS ilkesi silinmiş veya yeniden adlandırılmış bir sütuna başvurur | Hata: *Sütun düzeyi güvenlik ilkesi artık mevcut olmayan bir sütuna başvurur.*Veritabanı, ilke düzeltene kadar hata durumunu girer. | Hata: Geçersiz sütun adı <sütun adı> | Etkilenen bir veya daha fazla rolü güncelleştirin veya kaldırın ya da eksik sütunu geri yükleyin. | Güncelleştirmenin rolün oluşturulduğu göl evinde yapılması gerekir. |
| RLS/CLS ilkesi silinmiş veya yeniden adlandırılmış bir tabloya başvurur | Hata: Güvenlik ilkesi artık var olmayan bir tabloya başvurur. | Hata oluşmadı; tablo eksikse sorgu sessizce başarısız olur. | Etkilenen bir veya daha fazla rolü güncelleştirin veya kaldırın ya da eksik tabloyu geri yükleyin. | Güncelleştirmenin rolün oluşturulduğu göl evinde yapılması gerekir. |
| DDM (Dinamik Veri Maskeleme) ilkesi silinmiş veya yeniden adlandırılmış bir sütuna başvuruyor | OneLake güvenliğinden desteklenmeyen DDM, SQL aracılığıyla uygulanmalıdır. | Hata: Geçersiz sütun adı <sütun adı> | Etkilenen bir veya daha fazla DDM kuralını güncelleştirin veya kaldırın ya da eksik sütunu geri yükleyin. | SQL Analytics Uç Noktası'nda DDM ilkesini güncelleştirin. |
| Sistem hatası (beklenmeyen hata) | Hata: Beklenmeyen bir sistem hatası oluştu. Yeniden deneyin veya desteğe başvurun. | Hata: SQL'e tablo değişiklikleri uygulanırken bir iç hata oluştu. | Yeniden deneme işlemi; sorun devam ederse Microsoft Support başvurun. | N/A |
| Kullanıcının yapıt üzerinde izni yok | Hata: Kullanıcının yapıt üzerinde izni yok | Hata: Kullanıcının yapıt üzerinde izni yok | Kullanıcıya yapıt için objectID {objectID} izni verin. | Nesne kimliği, OneLake güvenlik rolü üyesi ile Fabric öğesi izinleri arasında tam eşleşme olmalıdır. Rol üyeliğine bir grup eklenirse, aynı gruba Fabric Okuma izni verilmelidir. Bu gruptan öğeye üye eklemek doğrudan eşleşme olarak sayılmaz. |
| Kullanıcı sorumlusu desteklenmez. | Hata: Kullanıcı sorumlusu desteklenmiyor. | Hata: Kullanıcı sorumlusu desteklenmiyor. | Lütfen {username} kullanıcısını DefaultReader rolünden kaldırın | Bu hata, kullanıcı artık geçerli bir Entra Kimliği değilse (örneğin, kullanıcı kuruluşunuzdan ayrılmışsa veya silinmişse) oluşur. Bu hatayı çözmek için bunları rolden kaldırın. |
Güvenlik eşitleme ile kısayol davranışı
OneLake güvenliği asıl doğruluk kaynağında uygulanır; bu nedenle güvenlik senkronizasyonu, kısayolları içeren tablolar ve görünümler için sahiplik zincirini devre dışı bırakır. Bu, başka bir veritabanındaki sorgular için bile kaynak sistem izinlerinin her zaman değerlendirilmesini ve kabul edilmesini sağlar.
Sonuç olarak:
Kullanıcıların, verilerin fiziksel olarak bulunduğu varış yeri ve hem geçerli Lakehouse veya SQL analizi uç noktası olan kaynak kısayoluna geçerli erişime sahip olmaları gerekmektedir.
Kullanıcının herhangi bir tarafta izni yoksa sorgular başarısız olur erişim hatasıyla.
Uygulamalarınızı veya kısayollara başvuran görünümlerinizi tasarlarken, rol atamalarının kısayol ilişkisinin her iki ucunda da düzgün yapılandırıldığından emin olun.
Bu tasarım, Lakehouse sınırları genelinde güvenlik bütünlüğünü korur, ancak çapraz Lakehouse rolleri uyumlu değilse erişim hatalarının ortaya çıkabileceği senaryolar sunar.
OneLake güvenliğinde temsilci modu
SQL, erişimi SQL izinlerine (GRANT, REVOKE, RLS, CLS, DDM, roller vb.) göre kontrol eder.
Sorgu yetkili ise, sistem OneLake içinde depolanan verilere erişmeye devam eder.
Bu veri erişimi, Lakehouse veya SQL analiz uç noktası sahibinin kimliği—öğe hesabı olarak da bilinir—kullanılarak gerçekleştirilir.
Bu modelde:
Oturum açan kullanıcı OneLake'e geçirilmiyor.
Tüm erişim zorlamalarının SQL katmanında işlendiği varsayılır.
Öğe sahibi, iş yükü adına temel alınan dosyaları okumak için OneLake'te yeterli izinlere sahip olmaktan sorumludur.
Bu bir yetki devretme deseni olduğundan, sahip için SQL izinleri ile OneLake Erişimi arasındaki tüm uyuşmazlıklar sorgu hatalarına yol açar. Bu mod aşağıdakilerle tam uyumluluk sağlar:
Tüm nesne düzeylerinde SQL GRANT/REVOKE
SQL tanımlı Row-Level Güvenliği, Column-Level Güvenliği ve Dinamik Veri Maskeleme
DTA'lar veya uygulamalar tarafından kullanılan mevcut T-SQL araçları ve uygulamaları
OneLake erişim modunu değiştirme
Erişim modu, SQL analytics uç noktasıyla OneLake sorgulanırken veri erişiminin nasıl doğrulanıp zorunlu kılındığını belirler. Aşağıdaki adımları kullanarak kullanıcı kimliği modu ile temsilci kimlik modu arasında geçiş yapabilirsiniz:
Fabric çalışma alanınıza gidin ve lakehouse'unuzu açın. Sağ üst köşeden lakehouse'dan SQL analytics uç noktasına geçin.
Üst gezinti bölmesinden Güvenlik sekmesine gidin ve aşağıdaki OneLake access modlarından birini seçin:
Kullanıcı kimliği – Oturum açmış kullanıcının kimliğini kullanır. OneLake rolünü uygular.
Temsilci kimliği – Öğe sahibinin kimliğini kullanır; yalnızca SQL izinlerini zorlar.
Seçiminizi onaylamak için bir açılır pencere açılır. Değişikliği onaylamak için Evet'i seçin.
Modlar arasında geçiş yaparken dikkat edilmesi gerekenler
Önemli
Kullanıcı Kimliği ve Temsilcili modlar (her iki yönde) arasında geçiş yapmak şu anda TVF'ler ve Scalar-Valued İşlevleri gibi satır içi meta veri nesnelerini kaldırır. Bu davranış yalnızca meta veri tanımlarını etkiler; OneLake'te temel alınan veriler etkilenmez.
Kullanıcı kimliği moduna geçme
SQL RLS, CLS ve tablo düzeyi izinleri yoksayılır.
OneLake rolleri, kullanıcıların erişimi sürdürebilmesi için yapılandırılmalıdır.
Yalnızca Görüntüleyici izinlerine veya paylaşılan salt okunur erişime sahip kullanıcılar, OneLake güvenlik kuralları tarafından yönetilecektir.
Mevcut SQL Rolleri silinir ve kurtarılamaz.
Temsilci kimlik moduna geçme
OneLake rolleri ve güvenlik ilkeleri artık uygulanmaz.
SQL rolleri ve güvenlik ilkeleri etkin hale gelir.
Öğe sahibinin geçerli OneLake access olması gerekir, aksi zaman tüm sorgular başarısız olabilir.
Sorun giderme
Kullanıcının kimlik modunda güvenlik eşitleme sonuçları UX aracılığıyla doğrulanabilir. SQL Analytics uç noktasını açın, Gezgin'deGüvenlik klasörünü genişletin ve ardından DB Rolleri (özel)'i seçin. Eşitleme başarılı olursa, rollerin "ols_" ön ekiyle listelendiğini görürsünüz. Örneğin, "ols_TestRole". "ols_{alphanumericString}_rolename" olan rol adları, bir kısayol aracılığıyla yayılan diğer lakehouse'lardaki rollerden gelir.
Yaygın güvenlik eşitleme hataları için düzeltmeler
Rollerden herhangi biri bırakılan bir tabloya başvuruda bulunursa güvenlik eşitlemesi başarısız olur. Bu tabloları rollerden silin ve ardından güvenlik senkronizasyonunu yeniden deneyin.
SPN'ler göl evi sahibi olamaz. Ana lakehouse öğesinin bir kullanıcı hesabına ait olduğundan emin olun.
Güvenlik eşitlemesinin kullanıcıyı veya grubu tanıması için tüm OneLake güvenlik rolü üyelerine Lakehouse'da Fabric Okuma izni verilmesi gerekir.
Sınırlamalar
Yalnızca okuyucular için geçerlidir: OneLake güvenliği, verilere görüntüleyici olarak erişen kullanıcıları yönetir. Diğer çalışma alanı rollerindeki (Yönetici, Üye veya Katkıda Bulunan) kullanıcılar OneLake güvenliğini atlar ve tam erişime sahip olmaya devam eder.
SQL nesneleri sahipliği devralmıyor: Kısayollar SQL analiz uç noktasında tablo olarak gösterilir. Bu tablolara doğrudan veya görünümler aracılığıyla erişirken saklı yordamlar ve diğer türetilmiş SQL nesneleri nesne düzeyinde sahiplik taşımaz; tüm izinler, güvenlik atlamasını önlemek için çalışma zamanında denetlenmektedir.
Kısayol değişiklikleri doğrulama kapalı kalma süresini tetikler: Kısayol hedefi değiştiğinde (örneğin, yeniden adlandırma, URL güncelleştirmesi), sistem yeni hedefi doğrularken veritabanı kısa bir süre tek kullanıcı moduna girer. Bu süre boyunca sorgular engellenir, bu işlemler oldukça hızlıdır, ancak bazen farklı iç işleme bağlı olarak eşitleme 5 dakika kadar sürebilir.
- Şema kısayolları oluşturmak, doğrulamayı etkileyen ve meta veri eşitlemesini geciktiren bilinen bir hataya neden olabilir.
Gecikmeli izin yayma: İzin değişiklikleri anlık değildir. Güvenlik modları (Kullanıcı Kimliği ve Temsilci) arasında geçiş yapmak, etkin olmadan önce yayılmak için zaman gerektirebilir, ancak 1 dakikadan kısa sürer.
Denetim düzlemi bağımlılığı: İzinler, çalışma alanı denetim düzleminde mevcut olmayan kullanıcılara veya gruplara uygulanamaz. Kaynak öğeyi paylaşmanız veya kullanıcının Görüntüleyici çalışma alanı rolünün üyesi olması gerekir. Tam olarak aynı nesne kimliğinin her iki yerde de olması gerektiğini unutmayın. Bir grup ve bu grubun bir üyesi eşleşme olarak sayılmaz.
En izin verici erişim geçerlidir: Kullanıcılar birden çok gruba veya role ait olduğunda, en izin verici etkin izin geçerlidir. Örnek: Kullanıcının hem bir rol üzerinden REDDET hem de başka bir rol üzerinden İZİN VER varsa, İZİN VER öncelikli olur.
Delegated modu sınırlamaları: Eğer kaynak öğede, öğe sahibine tablonun tam erişimini vermeyen OneLake güvenlik ilkeleri varsa, kısayol tabloları üzerinde meta veri eşitlemesi başarısız olabilir.
DENY davranışı: Tek bir kısayol tablosuna birden çok rol uygulandığında, izinlerin kesişimi SQL Server semantiği izler: DENY GRANT'i geçersiz kılar. Bu, beklenmeyen erişim sonuçlarına neden olabilir.
Beklenen hata koşulları: Kullanıcılar aşağıdaki gibi senaryolarda hatalarla karşılaşabilir:
Kısayol hedefi yeniden adlandırıldı veya geçersiz
- Örnek: Tablonun kaynağı silinmişse.
RLS (Satır Düzeyi Güvenlik) yanlış yapılandırması
RLS filtreleme için bazı ifadeler OneLake'te desteklenmez ve bu durum yetkisiz veri erişimine izin verebilir.
Filtre ifadesinde kullanılan sütunun bırakılması, RLS'yi geçersiz kılar ve RLS OneLake güvenlik panelinde düzeltilene kadar Metaveri Eşitlemesi geçersiz kalır.
Genel Önizleme için yalnızca tek ifade tablolarını destekleriz. Dinamik RLS ve Çok Tablolu RLS şu anda desteklenmiyor.
Sütun Seviyesi Güvenlik (CLS) sınırlamaları
CLS, sütunların izin verilenler listesini koruyarak çalışır. İzin verilen bir sütun kaldırılır veya yeniden adlandırılırsa, CLS ilkesi geçersiz hale gelir.
CLS geçersiz olduğunda, OneLake güvenlik panelinde CLS kuralı sabitlenene kadar meta veri eşitlemesi engellenir.
Meta veriler veya izin eşitleme hatası
- Tabloda bir sütunu yeniden adlandırma gibi değişiklikler varsa, güvenlik yeni nesnede çoğaltılamaz ve sütunun mevcut olmadığını gösteren kullanıcı arabirimi hataları alırsınız.
Tablo yeniden adlandırmaları güvenlik ilkelerini korumaz: OneLake güvenlik (OLS) rolleri Şema düzeyinde tanımlanmışsa, bu roller yalnızca tablo adı değişmediği sürece etkin kalır. Tablonun yeniden adlandırılması ilişkilendirmeyi bozar ve güvenlik ilkeleri otomatik olarak geçirilmez. Bu, ilkeler yeniden uygulanana kadar istenmeyen verilerin açığa çıkarılmayla sonuçlanabilir.
OneLake güvenlik rollerinin adları 124 karakterden uzun olamaz; aksi takdirde, güvenlik eşitlemesi rolleri eşitleyemez.
OLS_ rollerindeki kullanıcı değişiklikleri desteklenmez ve beklenmeyen davranışlara neden olabilir.
Posta etkin güvenlik grupları ve dağıtım listeleri desteklenmez.
Göl evi sahibinin yönetici, üye veya katkıda bulunan çalışma alanı rollerinin üyesi olması gerekir; aksi takdirde sql analiz uç noktasına güvenlik uygulanmaz.
Lakehouse'un sahibi, güvenlik eşitlemesinin çalışması için hizmet sorumlusu olamaz.