Aracılığıyla paylaş

SQL analiz uç noktaları için OneLake güvenliği (Önizleme)

OneLake güvenliği sayesinde Microsoft Fabric, kuruluşların iş yükleri arasında veri erişimini yönetme ve zorunlu kılma ş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 analytics uç noktasında erişim modları

SQL analiz uç noktasını kullanırken, seçilen erişim modu veri güvenliğinin nasıl zorunlu kılındığını belirler. Doku, her birinin operasyonel ve uyumluluk gereksinimlerinize bağlı olarak farklı avantajlar sunan iki farklı erişim modeli destekler:

  • Kullanıcı kimliği modu: OneLake rollerini ve ilkelerini kullanarak güvenliği zorlar. Bu modda, SQL analytics uç noktası oturum açmış kullanıcının kimliğini OneLake'e geçirir ve okuma erişimi 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, Doku 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 erişim ilkelerine göre ayrılmış açık ve kısa bir karşılaştırma tablosu yer alır:

Güvenlik hedefi Kullanıcı kimliği modu Temsilci kimlik modu
Tables Erişim, OneLake güvenlik rolleri tarafından denetlenilir. SQL'e GRANT/REVOKE izin verilmez. SQL GRANT/REVOKEkullanarak tam denetim.
Views İzinleri atamak için SQL GRANT/REVOKE kullanın. İzinleri atamak için SQL GRANT/REVOKE kullanın.
Saklı yordamlar İ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.
Row-Level 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.
Column-Level Güvenliği (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. seçeneğiyle ALTER TABLE SQL MASKED 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 zorunlu kılmak için bir geçiş 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 mod 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 zorlama sağlar. Erişimin OneLake'te bir kez tanımlanması ve her yerde otomatik olarak dikkate alınması gereken idare modelleri için tasarlanmıştır.

Kullanıcı kimliği modunda:

  • Tablo erişimi tamamen OneLake güvenliğine tabidir. Tablolardaki SQL GRANT/REVOKE deyimleri yoksayılır.

  • RLS (Row-Level Güvenlik), CLS (Column-Level Güvenlik) ve Object-Level Güvenliği 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 Lakehouse kullanıcı arabirimi aracılığıyla 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. OneLake güvenlik rolüne kimlik erişimi verirseniz, aynı kimliğin göl evi için de Doku 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 yükseltilmiş ayrıcalıkları vardır ve RLS, CLS ve OLS ilkelerini 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 filtrelenmiştir.

Rol önceliği: İzin verilen en fazla erişim kazanır

Bir kullanıcı birden çok OneLake rolüne aitse, en uygun rol etkin erişimini tanımlar. Örneğin:

  • Bir rol tabloya tam erişim verirse ve başka bir rol satırları kısıtlamak için RLS uygularsa, RLS uygulanmaz.

  • Daha geniş erişim rolü önceliklidir. 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 denetimlerini zorunlu tutarken kısıtlayıcı ve izinli rollerin birbirini dışlamaması önerilir.

Daha fazla bilgi için bkz. OneLake güvenliği için veri erişim denetimi modeli .

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 yetkili kalmasını sağlayarak güvenlik davranışını çoğaltmak için el ile SQL düzeyinde müdahale gereksinimini ortadan kaldırır. Güvenlik merkezi olarak uygulandığından:

  • 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ği'nden 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 Desteği'ne başvurun. Mevcut Değil
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 gerçeğin kaynağında zorunlu kılındığından, güvenlik eşitlemesi 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 hem kısayol kaynağında (geçerli Lakehouse veya SQL analiz uç noktası) hem de verilerin fiziksel olarak bulunduğu hedefte geçerli erişimi olmalıdır.

  • Kullanıcının her iki tarafta da izni yoksa , sorgular bir erişim hatasıyla başarısız olur.

  • 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 Lakehouse'un çapraz rolleri uyumlu değilse erişim hatalarının ortaya çıkabileceği senaryolar sunar.

OneLake güvenliğinde temsilci modu

Temsilci Kimlik Modu'nda, SQL analiz uç noktası bugün Microsoft Fabric'te bulunan güvenlik modelini kullanır. Güvenlik ve izinler tamamen SQL katmanında yönetilir ve Tablo düzeyinde erişim için OneLake rolleri veya erişim ilkeleri zorunlu tutulmaz . Bir kullanıcı SQL analytics uç noktasına bağlandığında ve bir sorgu döndürdiğinde:

  • SQL, erişimi SQL izinlerine (GRANT, REVOKE, RLS, CLS, DDM, roller vb.) göre doğrular.

  • Sorgu yetkilendirilmişse, sistem OneLake'te depolanan verilere erişmeye devam eder.

  • Bu veri erişimi, Öğe hesabı olarak da bilinen Lakehouse veya SQL analytics uç noktası sahibinin kimliği 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 temsilci deseni olduğundan, SQL izinleri ile sahip için OneLake erişimi arasındaki tüm yanlış hizalamalar sorgu hatalarıyla sonuçlanır. 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ı üzerinden OneLake sorgulanırken veri erişiminin kimliğinin 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:

  1. 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.

  2. Üst gezinti bölmesinden Güvenlik sekmesine gidin ve aşağıdaki OneLake erişim modlarından birini seçin:

    • Kullanıcı kimliği – Oturum açmış kullanıcının kimliğini kullanır. OneLake rollerini zorlar.

    • Temsilci kimliği – Öğe sahibinin kimliğini kullanır; yalnızca SQL izinlerini zorlar.

  3. 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

Kullanıcı kimliği moduna geçme

  • SQL RLS, CLS ve tablo düzeyi izinleri yoksayılır.

  • Kullanıcıların erişimi koruması için OneLake rolleri 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üvenliği tarafından yönetilir.

  • 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 erişimi olmalıdır, aksi zaman tüm sorgular başarısız olabilir.

Sınırlamalar

  • Yalnızca okuyucular için geçerlidir: OneLake Security, verilere erişen kullanıcıları Görüntüleyiciler olarak yönetir. Diğer çalışma alanı rollerindeki kullanıcılar (Yönetici Üyesi veya Katkıda Bulunan) OneLake Güvenliği'ni atlar ve tam erişimi korur.

  • 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.

  • İzin verilen en fazla erişim geçerli olur: Kullanıcılar birden çok gruba veya role ait olduğunda, en izin veren etkin izin verilir Örnek: Bir kullanıcı hem BIR rol aracılığıyla REDDET hem de başka bir rol aracılığıyla GRANT'e sahipse, GRANT önceliklidir.

  • Temsilci modu sınırlamaları: Kaynak öğede öğe sahibine tam tablo erişimi verilmeyen OneLake Güvenlik ilkeleri varsa, Temsilci modunda, kısayol tablolarındaki meta veri eşitlemesi başarısız olabilir.

  • REDDETME davranışı: Tek bir kısayol tablosuna birden çok rol uygulandığında, izinlerin kesişimi SQL Server semantiği: 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 (Row-Level Güvenlik) yanlış yapılandırması

      • RLS filtrelemeye yönelik bazı ifadeler OneLake'te desteklenmez ve yetkisiz veri erişimine izin verebilir.

      • Filtre ifadesinde kullanılan sütunun bırakılması RLS'yi geçersiz kılır ve RLS OneLake Güvenlik Paneli'nde düzeltilinceye kadar Meta Veri Eşitleme eskir.

      • Genel Önizleme için yalnızca tek ifade tablolarını destekleriz. Dinamik RLS ve Çok Tablolu RLS şu anda desteklenmiyor.

    • Column-Level Güvenliği (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üvenliği (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.

  • OneLake güvenlik rolleri sql analiz uç noktasına OLS_ ön eki ile yayılır.

  • 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.

İlgili içerik

  • Last updated on