SQL analiz uç noktaları için OneLake güvenliği

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 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 okuma erişimi tamamen OneLake içinde tanımlanan güvenlik kurallarına tabidir. Veri olmayan nesneler (görünümler, saklı yordamlar, işlevler) üzerinde 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.

Önemli

SQL analiz uç noktasını kullanmak için artifakt erişimi gerekir. SQL analytics uç noktası üzerinden verilere bağlanmak ve verileri sorgulamak için, kullanıcıların uç noktayla ilişkili yapıt üzerinde Okuma iznine sahip olması gerekir. Kullanıcının yapıta denetim düzlemi erişimi yoksa (örneğin, çalışma alanı rolü erişimi veya açık öğe izni), söz konusu kullanıcı için mevcut olabilecek SQL izinlerinden bağımsız olarak SQL analiz uç noktasına bağlantı reddedilir.

erişim modları arasındaki karşılaştırma

Aşağıdaki tabloda, kullanıcı kimliği modunda güvenliği nesne türüne ve veri erişim ilkelerine göre ayrılmış temsilci kimlik moduyla nasıl ve nerede ayarladığınız karşılaştırılı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'i GRANT/REVOKE kullanın. İzinleri atamak için SQL'i GRANT/REVOKE kullanın.
Saklı prosedürler İzinleri atamak için SQL'i GRANT EXECUTE kullanın. İzinleri atamak için SQL'i GRANT EXECUTE kullanın.
Functions İzinleri atamak için SQL'i GRANT EXECUTE kullanın. İzinleri atamak için SQL'i 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 POLICYkullanı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 listesi ile 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, herhangi bir SQL düzeyi GRANT veya REVOKE deyimi 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 göz ardı edilir.

  • 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

Üretici ve tüketici arasında bire bir kimlik eşlemesi (merkez-uç). OneLake güvenlik ilkeleri bir üreticiden (rolün tanımlandığı kaynak öğe) bir tüketiciye (verilere kısayol üzerinden erişen bir hedef öğe) taşındığında, üreticideki OneLake güvenlik rollerine atanan kimlikler tüketicide tam olarak 1:1 eşlenmelidir. Aynı ana öğeye—ister kullanıcı ister grup olsun—üreticinin güvenlik rolünde başvurulan tüketici yapıtı üzerinde Fabric Okuma izni verilmelidir. İç içe veya etkili grup üyeliği bu sınırın ötesinde çözümlenmez.

Örneğin, üreticideki OneLake güvenlik rolü user123@microsoft.com referans alıyorsa, user123@microsoft.com (aynı tam Nesne Kimliği) tüketici lakehouse'da Fabric Okuma iznine de sahip olmalıdır. Benzer şekilde, eğer üretici rolü Group A referans alıyorsa, Group A kendisine tüketici birim üzerinde Fabric Okuma izni verilmelidir; bu iznin yalnızca Grup A üyesine verilmesi eşleşme şartlarını karşılamaz.

Kullanıcının kimlik moduyla izin modeli hakkında 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 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.

  • Veya GRANT deyimlerini kullanarak EXECUTE görünümlere, işlevlere ve saklı yordamlara SQL izinleri uygulamaya devam edebilirsiniz.

Güvenlik eşitlemesi geri çekilmeyi yeniden deneme

Güvenlik eşitlemesi, sistem kararlılığını korumak ve gereksiz işlem tüketimini önlemek için yeniden deneme geri alma mekanizması içerir:

  • SQL analytics uç noktasına OneLake güvenlik rolleri uygulanırken yinelenen hatalar oluşursa, sistem otomatik eşitleme girişimlerini geçici olarak duraklatabilir.

  • Mevcut bir OneLake güvenlik rolü değiştirildiğinde veya yeni bir rol oluşturulduğunda eşitleme otomatik olarak sürdürülür.

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 var olmayan bir sütuna başvurur. İlke düzeltene kadar veritabanı 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ştirme, rolün oluşturulduğu göl evinde yapılmalıdır.
CLS ilkesi silinmiş veya yeniden adlandırılmış bir sütuna başvurur Hata: Sütun düzeyi güvenlik ilkesi artık var olmayan bir sütuna başvurur. İlke düzeltene kadar veritabanı 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ştirme, rolün oluşturulduğu göl evinde yapılmalıdır.
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ştirme, rolün oluşturulduğu göl evinde yapılmalıdır.
DDM (Dinamik Veri Maskeleme) ilkesi silinmiş veya yeniden adlandırılmış bir sütuna başvuruyor DDM, OneLake güvenliğinden desteklenmez; 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. İşlemi yeniden deneyin; sorun devam ederse Microsoft Desteği 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 objectID {objectID} yapıt için izin 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ı ilkesi desteklenmiyor Hata: Kullanıcı sorumlusu desteklenmiyor. Hata: Kullanıcı sorumlusu desteklenmiyor. kullanıcısını {username} rolünden DefaultReaderkaldırın. Kullanıcı artık geçerli bir Entra ID değilse (örneğin, kullanıcı kuruluşta ayrıldıysa veya silindiyse) bu hata oluşur. 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 iki tarafında da izni yoksa , sorgular bir erişim hatasıyla başarısız olur.

  • Kısayollara başvuran uygulamalar veya görünümler 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

Temsilci kimlik modunda, SQL analiz uç noktası geleneksel SQL güvenlik modeliyle geriye dönük uyumluluğu korur. SQL motoru katmanında güvenlik tanımlanır ve uygulanır ve OneLake güvenlik rolleri ve erişim ilkeleri tablo düzeyinde erişime aktarılmaz. Şemalara ve tablolara erişim, Row-Level Güvenliği (RLS), Column-Level Güvenliği (CLS) ve Dinamik Veri Maskeleme (DDM) dahil olmak üzere tüm filtreleme ve erişim denetimi SQL yapıları (GRANT/REVOKE, güvenlik ilkeleri vb.) kullanılarak tanımlanmalıdır.

Son kullanıcı için OneLake güvenlik rolleri doğrudan uygulanmadığından, Aynı veriler SQL analiz uç noktası üzerinden sorgulandığında OneLake'te tanımlanan güvenlik kuralları (örneğin, Spark tarafından uygulanan kurallar veya OneLake aracılığıyla okunan diğer altyapılar) uygulanmaz . İş yükü SQL yerel güvenlik semantiğine bağlı olduğunda veya mevcut T-SQL araçları tam uyumluluk gerektirdiğinde bu modu seçin.

Bir kullanıcı SQL analytics uç noktasına bağlandığında ve bir sorgu döndürdiğinde:

  • SQL, sorguyu SQL katmanında tanımlanan izinlere göre doğrular.

  • Sorgu yetkili ise, sistem OneLake içinde depolanan verilere erişmeye devam eder.

  • Bu veri erişimi, oturum açmış kullanıcının değil, öğe hesabı olarak da bilinen Lakehouse veya SQL analytics uç noktası sahibinin kimliği kullanılarak gerçekleştirilir.

Bu nedenle öğe sahibi , iş yükü adına temel alınan dosyaları okumak için OneLake'te yeterli izinlere sahip olmaktan sorumludur. Son kullanıcılara verilen SQL izinleri ile öğe sahibinin OneLake erişimi arasındaki tüm yanlış hizalamalar sorgu hatalarına neden olur.

Bu mod, TÜM nesne düzeylerinde SQL için tam uyumluluk ve SQL GRANT/REVOKE tanımlı RLS, CLS ve DDM ile DBA'lar veya uygulamalar tarafından kullanılan mevcut T-SQL araçlarını ve uygulamalarını destekler.

Temsilci modunda kısayol davranışı

Temsilci modu , öğe sahibinin kimliğini kullanarak OneLake'e bağlandığından, kısayollar yalnızca sahibin kaynak tablonun tamamına sınırsız erişimi olduğunda çalışır. Kaynak tabloda Row-Level Güvenliği (RLS), Column-Level Güvenliği (CLS) gibi OneLake düzeyinde bir güvenlik kuralı uygulanmışsa SQL analiz uç noktası bu kısayola erişimi engeller.

Sonuç olarak:

  • Veri düzeyi güvenlik kuralı olmayan kaynak tabloları işaret eden kısayollar, temsilci modunda normal şekilde çalışır.

  • Üreticideki OneLake güvenliğinde RLS veya CLS ile kaynak tablolara işaret eden kısayollara, son kullanıcının kısayol nesnesi üzerinde SQL izinleri olsa bile yetkilendirilmiş modda SQL analiz uç noktası üzerinden erişilemez.

  • Kaynağında OneLake güvenlik ilkeleri bulunan kısayolları kullanmak için, tüketici uç noktasında kullanıcı kimliği modunu kullanarak son kullanıcının kimliğinin kaynağın OneLake güvenlik kurallarına göre değerlendirilmesini sağlayın.

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 analiz 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 rollerinin uygulanmasını sağlar.

    • Temsilci kimliği – Öğe sahibinin kimliğini kullanır. Yalnızca SQL izinlerini uygular.

  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.

Önemli

Güvenlik modunun geçici olarak değiştirilmesi, SQL analytics uç noktalarının çalışma alanının tamamında kullanılamaz duruma getirir. Bu eylem, söz konusu çalışma alanında tüm SQL analizi uç noktalarındaki tüm çalışan ve kuyruğa alınmış sorguları iptal eder. Kapalı kalma süresini önlemek için modları yalnızca gerektiğinde ve tercihen iş dışı saatlerde değiştirin.

Modlar arasında geçiş yaparken dikkat edilmesi gerekenler

Önemli

Kullanıcı kimliği ve yetkilendirilmiş modlar (her iki yönde) arasında geçiş yapmak hali hazırda tablo değerli işlevler (TVF'ler) ve skaler değerli işlevler de dahil olmak üzere satır içi meta veri nesnelerini kaldırmaktadı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üvenliğine tabidir.

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

Açıklamalar

  • SQL nesneleri sahipliği devralmaz: Kısayollar, SQL analiz uç noktasında tablo işlevi görür, ancak birleşik bir güvenlik duruşunu korumak için standart SQL sahipliği zincirlemesinden kasıtlı olarak sapma gösterir.

    • Devralmama kuralı: Türetilmiş SQL nesneleri (görünümler, saklı yordamlar veya işlevler) nesne sahibinden izinleri devralmaz.

    • Çalışma zamanı doğrulaması: İzinler, yürütme sırasında çağıranın kimliğine göre doğrulanır ve SQL soyutlamalarının OneLake düzeyi ilkeleri aşmamasını sağlar.

    • Güvenlik tasarımına göre: Verilere SQL, Spark veya Power BI üzerinden erişildiğinde güvenlik ilkeleri tutarlı kalır.

  • Denetim düzlemi bağımlılığı (katı kimlik eşleştirme): OneLake güvenliği, üreticide erişim verilen kimliğin tüketici veri düzleminde erişim değerlendirmesi sırasında tanınan kimlikle aynı kimlik olmasını gerektirir. Sistem, kaynakta erişim verilen belirli kimliği doğrular ve iç içe grup üyeliğini genişletmez veya dolaylı üyelik yollarıyla etkin erişimi belirlemez.

  • İzin değerlendirme davranışı: İzin değerlendirmesi, geçerli zorlama modeline bağlı olarak tablo türüne göre değişir.

    • Kısayol tabloları: Gereken yetkilendirme koşulları karşılanmadığında erişim engellenebilir. Bu, OneLake güvenliğinde rol tabanlı bir DENY özelliği değil, kısıtlayıcı bir zorlama sonucudur.

    • Genel kural: Zorlama erişimi açıkça doğrulayamazsa, sistem en kısıtlayıcı sonucu uygular.

  • Column-Level Güvenliği (CLS) tasarımı: CLS, sütunların katı bir izin listesini tutar.

    • İzin verilen bir sütunu yeniden adlandırmak veya kaldırmak güvenlik kuralını geçersiz kılıyor. Kural sistemde kalıcı olsa da, özgün sütun adlandırması geri yüklenene kadar etkin değildir ve kaynağa tüm erişimi reddeder.

    • Eşitleme koruması: İlke geçersiz olduğunda, kural OneLake güvenlik panelinde düzeltilene kadar meta veri eşitlemesi tasarım gereği engellenir.

    • Şema doğrulaması: Güvenlik ilkelerini güncelleştirmeden sütunları yeniden adlandırmak, yapılandırma eşitlenene kadar sütunun "mevcut olmadığını" belirten kullanıcı arabirimi hatalarını tetikler.

  • Rol yayma ve eşitleme (SLA):

    • OneLake güvenlik eşitlemesi: OneLake güvenlik rolü kullanıcı kimliği modunda değiştiğinde güncelleştirme hemen yapılmaz. Genellikle hızlı olsa da SQL analytics uç noktasıyla eşitleme 5 dakika kadar sürebilir.

    • Otomatik ön ek oluşturma: OneLake güvenlik rolleri, önek ile OLS_ SQL analytics uç noktasına yayılır.

    • Eşitleme önceliği: Güvenlik eşitleme işlemi rollerin durumunu OLS_ düzenli aralıklarla yeniler. Bu rollerde yapılan el ile değişiklikler desteklenmez ve bir sonraki eşitleme döngüsünde geçersiz kılınır. Eşitlemede değişiklik yoksa, güvenlik eşitlemesi el ile yapılan değişiklikleri geçersiz kılmaz.

  • Ambar SQL güvenliği ve kısayolları: Row-Level Güvenliği (RLS), Column-Level Güvenliği (CLS) veya Object-Level Güvenliği (OLS) gibi bir Ambardaki SQL yapıları kullanılarak tanımlanan güvenlik ilkeleri yalnızca ambarın SQL yürütme bağlamında (TDS uç noktası) uygulanır.

Önemli

Bir Ambar'dan verilere OneLake kısayolları aracılığıyla erişildiğinde, bu SQL güvenlik semantiği OneLake güvenlik ilkelerine çevrilmiyor. Sonuç olarak, verilere bir kısayol üzerinden erişen kullanıcılar, kaynak ambarda yapılandırılmış SQL güvenlik ilkelerine bakılmaksızın veri kümesinin tamamını görebilir.

Sınırlamalar

  • Yalnızca okuyucular için geçerlidir: OneLake güvenliği, görüntüleyici düzeyinde çalışma alanı veya öğe erişimi aracılığıyla verilere erişen kullanıcılar için öncelikli olarak uygulanır. Yönetici, Üye veya Katkıda Bulunan gibi daha geniş çalışma alanı rollerine sahip kullanıcılar yükseltilmiş erişimi korur ve OneLake güvenlik zorlamasının birincil hedefi değildir.

    • Özel durumlar:

      • Kısayol reddetme davranışı: Kısayola dayalı tablolar için zorlayıcı önlemler, belirli durumlarda Yöneticilere, Üyelere veya Katkıda Bulunanlara erişimi yine de reddedebilir.

      • Güvenlik eşitleme hatası durumları: Güvenlik eşitlemesi belirli tablolar veya roller için güvenliği doğru uygulayamazsa, bu etkilenen rollerin üyesi olan Yönetici, Üye veya Katkıda Bulunan rollerindeki kullanıcılar da kısıtlı erişimle karşılaşabilir.

      • Kullanıcı kimliği modunda RLS: Row-Level Güvenliği (RLS) kullanıcı kimliği modunda yapılandırıldığında, Yönetici, Üye ve Katkıda Bulunan rolleri dahil olmak üzere tüm kullanıcılar için tanımlı güvenlik kuralları uygulanır.

  • Güvenlik eşitleme bağımlılığı: Kullanıcı kimliği modunda OneLake güvenlik rolleri, güvenlik eşitleme işlemi aracılığıyla SQL analytics uç noktasına eşitlenir. Eşitleme tamamlanana kadar SQL, mevcut SQL izin durumunu kullanarak erişimi geçici olarak değerlendirebilir. Eşitleme tamamlandıktan sonra SQL uç noktası OneLake güvenlik yapılandırmasını yansıtır.

  • Kısayol sınırı tanıma: SQL analiz uç noktası başlangıçta standart SQL nesne semantiği kullanarak kısayol destekli tabloları değerlendirebilir. Güvenlik eşitlemesi gerçekleştikten sonra, erişim zorlamanın yapıt ve çalışma alanı sınırlarıyla uyumlu olduğundan emin olmak için OneLake güvenlik ilkeleri uygulanır.

  • Yapıtlar Arası Erişim Uygulama Zamanlaması: Diğer yapıtlara ait verileri referans alan OneLake kısayollarıyla desteklenen tablolara erişim, senkronize edilmiş OneLake güvenlik rolleri aracılığıyla sağlanır. Eşitleme gerçekleşene kadar SQL yetkilendirmesi geçici olarak önceki izin durumunu yansıtabilir.

  • Kısayol destekli tablolardaki sahiplik değişiklikleri: Kısayol destekli tablolar, SQL analizi uç noktasında SQL nesneleri olarak temsil edilir ve bu nedenle standart SQL sahiplik işlemlerini destekler. gibi ALTER AUTHORIZATION yönetim komutları, kısayol destekli tablonun sahibini değiştirebilir. Bazı senaryolarda bu, OneLake güvenlik ilkelerini atlayan ve temel alınan verilere istenmeyen erişim sağlayan sahiplik zincirleme davranışına izin verebilir. Ek zorlama mekanizmaları kullanıma sunulana kadar, yöneticiler kısayol destekli tablolarda sahipliği değiştirmekten kaçınmalıdır.

  • Hedef doğrulama kapalı kalma süresi: Kısayol hedefi değiştiğinde (örneğin, yeniden adlandırma veya 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şlemlerin genellikle hızlı olması ancak iç işlemlere bağlı olarak eşitlenmesi 5 dakika kadar sürebilir.

    • Şema kısayolları oluşturmak, doğrulamayı etkileyen ve meta veri eşitlemesini geciktiren bilinen bir hataya neden olabilir.

  • Temsilcili mod belirteci önbelleğe alma: Temsilci modunda SQL analytics uç noktası, sahip kimliği adına OneLake'ten veri almak için kullanılan depolama erişim belirtecini önbelleğe alır. Sahibin izinleri değişirse, daha önce verilen bir belirteç süresi dolana kadar geçerli kalabilir. Sonuç olarak, sahip kimliğine bağlı erişim değişiklikleri hemen geçerli olmayabilir ve genellikle 30-60 dakikaya kadar belirteç süresi dolana kadar kalıcı olabilir.

  • OneLake güvenlik GRANT/DENY ilkelerindeki değişiklikler hemen uygulanır ve depolama belirteci önbelleğe alma işlemi gecikmez.

  • Etkin sorgu iptali: Veri bütünlüğünü ve güvenliği korumak için, yürütme sırasında bir kısayol yapılandırması değişirse etkin sorgular otomatik olarak iptal edilebilir.

  • Satır Düzeyi Güvenlik (RLS) kısıtları:

    • Genel Önizleme için yalnızca tek ifadeli tablolar desteklenir. Dinamik RLS ve Çok Tablolu RLS kullanılamaz.

    • Filtre ifadesinde kullanılan bir sütunun kaldırılması, OneLake güvenlik panelinde RLS düzeltilene kadar meta veri eşitlemesini durduruyor.

  • Rol karmaşıklığı ve meta veri eşitlemesi: Özellikle RLS kullanan çok sayıda kesişim ve birleşim semantiği içeren güvenlik rollerindeki yüksek karmaşıklık, güvenlik eşitlemesinin başarısız olmasına neden olabilir. Başarısız bir güvenlik eşitlemesi, güvenlik ilkelerinin uygulanmasını engeller ve meta verileri eşitleme özelliğini engeller.

  • Şema ve rol kısıtlamaları:

    • Yeniden Adlandırmalar: OneLake güvenlik rolleri tablo adına bağlıdır. Bir tablonun yeniden adlandırılması ilişkilendirmeyi bozar ve ilkeler otomatik olarak geçirilmez. Bu, ilkeler yeniden uygulanana kadar istenmeyen verilerin açığa çıkarılmayla sonuçlanabilir.

    • Karakter sınırları: OneLake güvenlik rolü adları 124 karakteri aşamaz; aksi takdirde, rol oluşturma veya eşitleme SQL analytics uç noktasında başarısız olur.

    • OLS_ rol değişiklikleri: Rollerdeki OLS_ kullanıcı değişiklikleri desteklenmez ve beklenmeyen davranışlara neden olabilir.

  • Desteklenmeyen kimlikler: Posta özellikli güvenlik grupları ve dağıtım listeleri şu anda desteklenmemektedir.

  • Lakehouse sahibi gereksinimleri:

    • Lakehouse'un sahibi Yönetici, Üye veya Katkıda Bulunan çalışma alanı rollerinin üyesi olmalıdır; 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