Power BI'da Satır Düzeyinde Güvenlik: Çok Kiracılı Veri Erişimi

Satır düzeyinde güvenlik (RLS), her kullanıcının yalnızca erişme yetkisine sahip olduğu verileri görmesini sağlayan mekanizmadır. Çok kiracılı veya çok departmanlı bir ortamda RLS isteğe bağlı değildir; yönetilen bir analiz platformu ile gerçekleşmeyi bekleyen bir veri ihlali arasındaki farktır. Ancak Microsoft'un kendi kullanım telemetrisi, Power BI Premium'a sahip kuruluşların yüzde 30'undan azının üretim veri kümelerinde RLS uyguladığını gösteriyor.

Bunun nedeni RLS'nin kavramsal olarak zor olması değildir. Bunun nedeni, uygulama ayrıntılarının incelikli olması, test sürecinin manuel olması ve RLS ile diğer Power BI özellikleri (DirectQuery, bileşik modeller, yerleştirme, toplamalar) arasındaki etkileşimin ekipleri hazırlıksız yakalayan uç durumlar oluşturmasıdır. Bu kılavuz, en basit statik rolden Azure Active Directory entegrasyonuyla karmaşık dinamik güvenliğe kadar RLS uygulamasının her yönünü kapsar.

---

Temel Çıkarımlar

• Power BI'daki satır düzeyinde güvenlik, DAX ifadelerini kullanarak verileri model düzeyinde filtreleyerek kullanıcıların raporları veya görselleri değiştirerek güvenliği atlamamasını sağlar
• Statik RLS sabit kodlar değerleri filtreler (küçük, kararlı kullanıcı grupları için uygundur), dinamik RLS ise oturum açmış kullanıcıya göre dinamik olarak filtrelemek için USERNAME() ve USERPRINCIPALNAME() gibi DAX işlevlerini kullanır
• RLS yalnızca İçe Aktarma ve DirectQuery modlarında çalışır --- Analiz Hizmetlerine (kendi RLS'leri olan) canlı bağlantılar için geçerli değildir.
• Nesne düzeyinde güvenlik (OLS), tabloların veya sütunların tamamını gizleyerek kullanıcıların belirli verilerin varlığından bile haberdar olmaması gereken senaryolar için RLS'yi tamamlar
• RLS'yi test etmek, Power BI Masaüstü ve Hizmetinde "Farklı görüntüle" özelliğini gerektirir; RLS'nin her rol için açık test yapılmadan çalıştığını asla varsaymayın
• Gömülü senaryolardaki (Power BI Embedded) RLS, uygulama hatalarının yaygın bir kaynağı olan yerleştirme belirtecinde etkili kimliğin iletilmesini gerektirir
• İyi tasarlanmış modeller için RLS'nin performans etkisi genellikle yüzde 5'ten azdır, ancak kötü yazılmış DAX filtreleri performansı yüzde 50 veya daha fazla düşürebilir

---

Satır Düzeyinde Güvenliği Anlamak

RLS Ne Yapar?

RLS, DAX filtre ifadelerini Power BI veri modelindeki bir veya daha fazla tabloya uygular. Bir kullanıcı bir raporu açtığında Power BI, RLS kurallarını değerlendirir ve kullanıcının görme yetkisinin olmadığı satırları sessizce filtreler. Kullanıcı normal bir raporla karşılaşır; kendi kapsamları dışındaki verileri göremezler.

Kritik olarak RLS, rapor katmanında değil, veri modeli katmanında çalışır. Bu şu anlama gelir:

• Kullanıcılar aynı veri kümesi üzerinde kendi raporlarını oluşturarak RLS'yi atlayamazlar
• RLS filtreleri ilişkiler aracılığıyla yayılır (Dim_Region'daki bir filtre, ilişki boyunca Fact_Sales'ı otomatik olarak filtreler)
• DAX ölçümleri RLS bağlamına uygundur (CALCULATE, SUMX ve diğer işlevler filtrelenmiş alt kümede çalışır)
• Excel, CSV veya PowerPoint'e aktarma yalnızca kullanıcının görme yetkisine sahip olduğu verileri dışa aktarır

RLS ve Diğer Güvenlik Mekanizmaları

RLS, bir kullanıcının hangi belirli veri satırlarına erişebileceğini kontrol eden tek mekanizmadır. Diğer mekanizmalar erişimi çalışma alanı, rapor veya nesne düzeyinde denetler.

---

Statik Satır Düzeyinde Güvenlik

Statik RLS, kullanıcıları sabit kodlanmış filtre değerlerine sahip rollere atar. Bu en basit uygulamadır ve az sayıda sabit bölge, departman veya iş birimi içeren senaryolarda iyi çalışır.

Statik Rol Oluşturma

Power BI Desktop'ta:

1. Modellemeye gidin, ardından Rolleri Yönetin
2. Yeni bir rol eklemek için Oluştur'a tıklayın
3. Rolü adlandırın (ör. "Kuzey Amerika Satışları")
4. Filtrelenecek tabloyu seçin (ör. Dim_Region)
5. DAX filtre ifadesini yazın:

[Region] = "North America"

Bu ifade şu anlama gelir: Bir kullanıcıya "Kuzey Amerika Satışları" rolü atandığında, Dim_Region ile ilgili her tablo yalnızca bölgenin Kuzey Amerika olduğu satırları gösterecektir. Bir satış raporunu görüntüleyen kullanıcı yalnızca Kuzey Amerika satışlarını görecektir. İK kontrol panelini görüntüleyen bir kullanıcı (bölgesel bir boyut aracılığıyla bağlanıyorsa) yalnızca Kuzey Amerikalı çalışanları görecektir.

Çoklu Roller

Farklı filtrelerle birden fazla rol oluşturabilirsiniz:

• EMEA Satışları: [Region] = "EMEA"
• APAC Satışları: [Region] = "APAC"
• Global Executive: Filtre yok (tüm verileri görür)

Bir kullanıcıya birden fazla rol atanabilir. Birden fazla role atandığında, filtreler VEYA mantığıyla birleşir; kullanıcı tüm rollerin verilerinin birleşimini görür. Örneğin, hem "Kuzey Amerika Satışları"na hem de "EMEA Satışları"na atanan bir kullanıcı, her iki bölgedeki verileri görür.

Statik RLS'nin Sınırlamaları

Aşağıdaki durumlarda statik RLS yönetilemez hale gelir:

• 10-15'ten fazla farklı filtre değeriniz var (15'ten fazla rol oluşturmak ve sürdürmek sıkıcıdır)
• Kullanıcıdan role atamalar sıklıkla değişir (her değişiklik bir Power BI yöneticisi gerektirir)
• Filtre mantığı basit eşitlikten daha karmaşıktır (örneğin, yöneticiler kendi ekiplerinin verileriyle birlikte kendi ekiplerinin verilerini de görmelidir)
• Düzinelerce iş biriminde yüzlerce kullanıcınız var

Bu senaryolar için çözüm dinamik RLS'dir.

---

Dinamik Satır Düzeyinde Güvenlik

Dinamik RLS, oturum açmış kullanıcıyı belirlemek ve uygun filtreleri uygulamak için çalışma zamanında değerlendirme yapan DAX işlevlerini kullanır. İki temel işlev şunlardır:

• USERNAME() — Geçerli kullanıcının etki alanı\kullanıcı adını veya UPN'sini döndürür
• USERPRINCIPALNAME() — Geçerli kullanıcının e-postasını/UPN'sini döndürür (bulut dağıtımları için önerilir)

Dinamik RLS'yi Ayarlama

1. Adım: Güvenlik eşleme tablosu oluşturun

Bu tablo, kullanıcıları yetkili veri kapsamlarıyla eşleştirir. Veri kaynağında (veritabanı), SharePoint listesinde veya Excel dosyasında saklanabilir:

Bu tabloyu Power BI modelinize SecurityMapping olarak aktarın.

2. Adım: RLS rolünü oluşturun

Güvenlik eşleme tablosunda DAX filtresiyle tek bir rol (ör. "DynamicSecurity") oluşturun:

[UserEmail] = USERPRINCIPALNAME()
    || [UserEmail] = "ALL"

3. Adım: İlişkiler oluşturun

SecurityMapping'ten boyut tablolarınıza ilişkiler kurun:

• Dim_Region[Bölge] ile SecurityMapping[Bölge]
• Dim_Department[Departman] ile SecurityMapping[Departman]
• Dim_Company[CompanyId] ile SecurityMapping[CompanyId]

Bu ilişkilerin boyuttan güvenlik eşleme tablosuna kadar bire çok olması gerekir veya çift yönlü bir çapraz filtre kullanabilirsiniz. Bununla birlikte, çift yönlü filtrelerin performans etkileri vardır; daha iyi bir yaklaşım, DAX ifadesinde CROSSFILTER veya TREATAS'ı kullanır.

Adım 4: İlişkisiz alternatif (TREATAS yaklaşımı)

Güvenlik eşleme tablosundan ilişkiler oluşturmak yerine, doğrudan olgu tablosundaki RLS ifadesinde TREATAS'ı kullanabilirsiniz:

VAR CurrentUser = USERPRINCIPALNAME()
VAR UserRegions =
    CALCULATETABLE(
        VALUES(SecurityMapping[Region]),
        SecurityMapping[UserEmail] = CurrentUser
            || SecurityMapping[UserEmail] = "ALL"
    )
RETURN
    [Region] IN UserRegions

Bu yaklaşım, ek ilişkilerin karmaşıklığını ortadan kaldırır ve güvenlik mantığını bağımsız tutar.

Yönetici Hiyerarşisine sahip Dinamik RLS

Ortak bir gereksinim, yöneticilerin tüm raporlama zincirlerine ait verileri görmesidir. Bu, çalışan veya kullanıcı tablosunda bir ebeveyn-çocuk hiyerarşisini gerektirir.

Yaklaşım 1: YOL işlevi

Kullanıcı tablonuzda ManagerId sütunu varsa DAX'ın PATH işlevini kullanın:

UserPath = PATH(Users[UserId], Users[ManagerId])

Daha sonra RLS ifadesinde:

VAR CurrentUserId =
    LOOKUPVALUE(Users[UserId], Users[Email], USERPRINCIPALNAME())
RETURN
    PATHCONTAINS([UserPath], CurrentUserId)

Bu ifade, mevcut kullanıcının kendi verileri ve doğrudan ve dolaylı raporlarına ait tüm veriler için TRUE değerini döndürür.

Yaklaşım 2: Düzleştirilmiş güvenlik masası

ETL sürecinizdeki hiyerarşiyi önceden hesaplayın ve her yöneticinin tüm raporlarının veri kapsamlarıyla birlikte listelendiği düz bir güvenlik eşlemesi oluşturun. Bu, PATH değerlendirmesinin yükünü ortadan kaldırdığı için sorgu zamanında daha performanslıdır.

---

Nesne Düzeyinde Güvenlik (OLS)

Nesne düzeyinde güvenlik, tabloların veya sütunların tamamını kullanıcılardan gizler. Satırları filtreleyen RLS'den farklı olarak OLS, tabloları veya sütunları tamamen görünmez hale getirir; bunlar alan listesinde görünmez ve gizli bir alana atıfta bulunan görseller bir hata gösterir.

OLS Ne Zaman Kullanılmalı

• İK veri kümelerindeki maaş sütunlarının İK dışı kullanıcılardan gizlenmesi
• Maliyetle ilgili tabloların yalnızca geliri görmesi gereken satış ekiplerinden gizlenmesi
• Yalnızca toplu verilere ihtiyaç duyan analistlerden müşteri kişisel bilgilerini (e-posta, telefon, adres) gizlemek
• Stratejik fiyatlandırma sütunlarının genel kullanıcılardan gizlenmesi

OLS'yi yapılandırma

OLS, Power BI Masaüstü Kullanıcı Arayüzü aracılığıyla değil, Tablo Düzenleyicisi (harici bir araç) veya XMLA uç noktaları aracılığıyla yapılandırılır.

Tablo Düzenleyicide:

1. Modeli harici araçlar şeridi aracılığıyla açın
2. Kısıtlamak istediğiniz tabloya veya sütuna gidin
3. Özellikler bölmesinde her rolün altında Tablo İzinlerini veya Sütun İzinlerini bulun
4. İzni "Yok" olarak ayarlayın (varsayılan "Okuma"dır)

Örneğin, Çalışanlar tablosundaki Maaş sütununu "Satış" rolünden gizlemek için:

• Rol: Satış
• Tablo: Çalışanlar
• Sütun: Maaş
• İzin: Yok

Satış rolüne atanan kullanıcılar alan listesinde Maaş sütununu görmez ve DAX hesaplamalarında bu sütuna başvuruda bulunamaz.

OLS Sınırlamaları

• OLS, XMLA uç noktalarının etkin olduğu Power BI Premium veya Pro'yu gerektirir
• OLS, Power BI Desktop'ın yerel kullanıcı arayüzünde yapılandırılamaz
• OLS yalnızca meta veri düzeyindedir --- satırları filtrelemez
• Bir hesaplama gizli bir sütuna başvuruyorsa, hesaplamanın kendisi kısıtlı kullanıcılar için hata verecektir

---

DirectQuery ile RLS

RLS, DirectQuery ile çalışır ancak davranış, İçe Aktarma modundan önemli açılardan farklıdır.

Nasıl Çalışır?

DirectQuery modunda Power BI, RLS DAX filtresini bir SQL WHERE yan tümcesine çevirir ve veri kaynağına gönderir. Veri kaynağı filtrelemeyi gerçekleştirir ve yalnızca yetkili satırlar döndürülür.

Tek Oturum Açma (SSO) Geçişi

DirectQuery'yi Azure SQL veya Azure Synapse gibi bir veritabanına SSO ile kullanırken Power BI, kullanıcının kimliğini veritabanına aktarır. Veritabanının kendi satır düzeyinde güvenliği varsa (örneğin, SQL Server'ın CREATE SECURITY POLICY), bu güvenlik Power BI'ın RLS'sine ek olarak geçerlidir.

Önemli: SSO geçişini etkinleştirirseniz Power BI'ın RLS'si atlanır çünkü veritabanı güvenliği yönetir. Birini veya diğerini seçmelisiniz:

• Power BI RLS (DAX'ta tanımlıdır, Power BI'da yönetilir)
• Veritabanı düzeyinde RLS (SQL'de tanımlı, veritabanında yönetilen)
• Her ikisi de (Power BI RLS VE veritabanı RLS uygulanır --- kullanıcı kesişimi görür)

Performansla İlgili Hususlar

DirectQuery'deki RLS filtreleri her sorguya WHERE yan tümceleri ekler. Filtre sütunları veritabanında indekslenmezse performans önemli ölçüde düşebilir. Şunlardan emin olun:

• RLS filtre sütunlarının veritabanı dizinleri vardır
• DAX filtre ifadesi verimli SQL'e çevrilecek kadar basittir
• Sorgu performansını Power BI Desktop'taki "Performans Analizcisi" ile test edersiniz

---

Power BI Embedded'de RLS

Power BI Embedded'in (raporları özel uygulamalara yerleştirme) benzersiz RLS gereksinimleri vardır çünkü son kullanıcılar Power BI veya Azure AD hesaplarına sahip olmayabilir.

Uygulama Veri Senaryosunun Sahibi

"Uygulama Verilere Sahiptir" ekleme modelinde, bir hizmet sorumlusu veya ana hesap Power BI'da kimlik doğrulaması yapar ve uygulama, kullanıcının kimliğini ekleme belirtecine aktarır.

RLS ile yerleştirme jetonu oluşturma:

Ekleme belirteci oluşturmak için Power BI REST API'yi çağırırken identities parametresini ekleyin:

{
  "datasets": [
    {
      "id": "dataset-guid-here"
    }
  ],
  "reports": [
    {
      "id": "report-guid-here"
    }
  ],
  "identities": [
    {
      "username": "[email protected]",
      "roles": ["DynamicSecurity"],
      "datasets": ["dataset-guid-here"]
    }
  ]
}

username değeri, USERPRINCIPALNAME() işlevinin DAX ifadesinde döndürdüğü değerdir. roles dizisi hangi RLS rollerinin uygulanacağını belirtir. Kullanıcı adı olarak herhangi bir dizeyi iletebilirsiniz; bunun gerçek bir Azure AD hesabı olması gerekmez.

Yaygın Yerleştirme Hataları

Hata 1: Etkin kimliğin aktarılmaması. identities parametresi olmadan bir yerleştirme jetonu oluşturursanız, yerleştirilmiş rapor tüm verileri gösterir. Bu en yaygın RLS yerleştirme hatasıdır.

Hata 2: Rollerin aktarılması ancak kullanıcı adının aktarılmaması. Dinamik RLS için kullanıcı adı gereklidir. Bu olmadan, USERPRINCIPALNAME() boş döndürür ve DAX filtresi hiçbir satırla eşleşmez; rapor boş görünür.

Hata 3: Hizmet sorumlusunun kimliğini kullanma. Hizmet sorumlusu bir çalışma alanı yöneticisidir ve RLS'yi atlar. Son kullanıcının kimliğini açıkça iletmelisiniz.

4. Hata: Dinamik RLS için yerleştirme belirtecindeki rolleri sabit kodlama. Dinamik RLS'yi tek bir rolle (ör. "DynamicSecurity") kullanıyorsanız, her zaman bu rol adını iletin. Her kullanıcı için ayrı roller oluşturmayın; bu, dinamik RLS'nin amacını boşa çıkarır.

---

Satır Düzeyinde Güvenliği Test Etme

Rol Olarak Görüntüle (Power BI Desktop)

Power BI Desktop'ta Modelleme'ye ve ardından Farklı Görüntüle'ye gidin:

1. Test edilecek rolleri seçin
2. İsteğe bağlı olarak dinamik RLS'yi test etmek için bir kullanıcı adı girin (bu, USERPRINCIPALNAME() değerini simüle eder)
3. Tamam'a tıklayın

Rapor artık verileri, belirtilen role sahip belirtilen kullanıcı sizmişsiniz gibi görüntülüyor. Doğrulayın:

• KPI kartları doğru filtrelenmiş toplamları gösterir
• Tablolar yalnızca kullanıcının kapsamı içindeki satırları görüntüler
• Grafikler filtrelenen verileri yansıtır
• Görseller arasındaki çapraz filtreleme, RLS sınırlarına saygı gösterir
• Detaylandırma sayfaları RLS bağlamını korur

Farklı Görüntüle (Power BI Hizmeti)

Power BI Hizmetinde veri kümesi ayarlarını açın ve Güvenlik'i seçin. "Rol olarak test et"i seçip bir kullanıcı adı girerek rolleri doğrudan test edebilirsiniz.

Otomatik Test Kontrol Listesi

Aşağıdaki senaryolarla bir test matrisi oluşturun:

---

RLS için Performans Optimizasyonu

Etkiyi Ölçün

RLS'yi uygulamadan önce ve uyguladıktan sonra sorgu sürelerini ölçmek için Power BI Desktop'taki Performans Analizörü'nü kullanın. Performans Analizörü bölmesini açın, kaydetmeye başlayın, raporla etkileşimde bulunun ve RLS ile ve RLS olmadan DAX sorgu sürelerini karşılaştırın.

İyi tasarlanmış bir RLS uygulaması yüzde 5'ten daha az ek yük ekler. Yüzde 10'dan fazla bozulma görüyorsanız DAX filtre ifadelerini inceleyin.

Optimizasyon Teknikleri

Filtre ifadelerini basit tutun. İdeal RLS ifadesi, tek sütunlu bir karşılaştırmadır:

[Region] = USERPRINCIPALNAME()

RLS filtresinin kendisinde birden fazla CALCULATE, FILTER veya LOOKUPVALUE çağrısı içeren karmaşık ifadelerden kaçının.

Metin karşılaştırmaları yerine tamsayı tuşlarını kullanın. [CompanyId] = 1 üzerinde filtreleme, [CompanyName] = "ECOSIRE Private Limited"'den daha hızlıdır. Kullanıcı e-postalarını güvenlik eşleme tablosundaki tam sayı anahtarlarıyla eşleyin.

RLS filtreleriyle tablo sayısını en aza indirin. RLS'yi boyut tablolarına uygulayın ve ilişki yayılımının olgu tablolarını yönetmesine izin verin. RLS'yi doğrudan büyük olgu tablolarına uygulamak, Power BI'ı olgu tablosunun her satırındaki filtreyi değerlendirmeye zorlar.

Mümkün olduğunda önceden toplayın. Kullanıcının yalnızca özet düzeyindeki verilere ihtiyacı varsa, ETL sırasında uygulanan güvenlik filtresiyle önceden toplanmış bir tablo oluşturmayı düşünün. Bu, Power BI'ın sorgu zamanında filtrelemesi gereken veri hacmini azaltır.

Çift yönlü çapraz filtrelerden kaçının. Çift yönlü ilişkiler sorgu karmaşıklığını artırır ve RLS ile çakışabilir. Tek yönlü ilişkileri kullanın (boyuttan gerçeğe) ve boyut tarafında RLS'yi uygulayın.

---

Yaygın Tuzaklar ve Çözümler

Tuzak 1: RLS, Çalışma Alanı Yöneticilerine Uygulanmıyor

Düzenleme iznine sahip çalışma alanı yöneticileri ve üyeleri RLS'yi atlar. Her zaman tüm verileri görürler. Bu tasarım gereğidir; yöneticilerin çalışma alanını yönetmek için tam erişime ihtiyacı vardır.

Çözüm: RLS'ye tabi olması gereken iş kullanıcıları için "Görüntüleyici" rolünü kullanın. BI ekibine yalnızca Yönetici/Üye/Katkıda Bulunan rollerini verin.

Tuzak 2: ALL() RLS Filtrelerini Kaldırma

DAX ALL() işlevi, RLS filtreleri de dahil olmak üzere tablodaki tüm filtreleri kaldırır. Bir ölçü, RLS filtreli bir tabloda ALL() kullanıyorsa, kullanıcının görmemesi gereken verileri açığa çıkarabilir.

-- DANGEROUS: This measure ignores RLS on Dim_Region
Total Global Sales =
CALCULATE(SUM(Fact_Sales[Revenue]), ALL(Dim_Region))

Çözüm: Dilimleyici/görsel filtreleri kaldırıp RLS filtrelerini korumak istediğinizde ALL() yerine ALLSELECTED() öğesini kullanın:

-- SAFE: This measure preserves RLS filters
Total Sales for Context =
CALCULATE(SUM(Fact_Sales[Revenue]), ALLSELECTED(Dim_Region))

Tuzak 3: RLS'yi Geçersiz Kılmanın HESAPLANMASI

Açık filtre bağımsız değişkenleriyle CALCULATE, belirli senaryolarda, özellikle REMOVEFILTERS ile RLS'yi geçersiz kılabilir:

-- DANGEROUS: REMOVEFILTERS is equivalent to ALL
Total Revenue All Regions =
CALCULATE(SUM(Fact_Sales[Revenue]), REMOVEFILTERS(Dim_Region[Region]))

Çözüm: ALL, REMOVEFILTERS ve ALLEXCEPT kullanımı için tüm DAX önlemlerini denetleyin. RLS filtreli sütunlara referans vermediklerinden emin olun.

Tuzak 4: Bileşik Modeller ve RLS

Bileşik modellerde (İçe Aktarma ve DirectQuery'nin karıştırıldığı), RLS'nin İçe Aktarma tabloları ve DirectQuery tabloları için ayrı olarak tanımlanması gerekir. Tek bir RLS rolü her ikisi için de filtreler içerebilir ancak davranış farklıdır:

• Tabloları içe aktarma: RLS filtresi Power BI motoru tarafından değerlendirilir
• DirectQuery tabloları: RLS filtresi SQL'e çevrilir ve kaynağa gönderilir

DirectQuery kaynağı RLS filtresinde kullanılan DAX işlevini desteklemiyorsa sorgu başarısız olur.

Tuzak 5: RLS'yi Göz Ardı Eden Sayfalandırılmış Raporlar

Power BI sayfalandırılmış raporları (Rapor Oluşturucu'da oluşturulur), doğrudan veri kaynağına bağlanırlarsa veri kümesi RLS'yi atlayabilir. RLS'yi zorunlu kılmak için sayfalandırılmış raporların Power BI veri kümesi üzerinden bağlanması (doğrudan veritabanına değil) ve kullanıcıya atanmış bir RLS rolüne sahip olması gerekir.

---

Kurumsal RLS Mimari Modeli

Büyük kuruluşlar için, ECOSIRE şunu önerir: standartlaştırılmış bir RLS mimarisi:

Güvenlik Katmanı Tasarımı

1. Merkezi bir veritabanında (Azure SQL veya SharePoint listesi) depolanan güvenlik eşleme tablosu
2. USERPRINCIPALNAME() kullanılarak "DynamicSecurity" adlı tek RLS rolü
3. Güvenlik eşleme tablosunu grup üyeliğine göre otomatik olarak dolduran Azure AD grup senkronizasyonu
4. Önceden düzleştirilmiş bir ebeveyn-çocuk tablosu kullanarak hiyerarşi desteği
5. Denetim takibi hangi kullanıcıların hangi verilere eriştiğini günlüğe kaydetme (Power BI etkinlik günlükleri ve REST API aracılığıyla)

Yönetişim Süreci

1. Veri sorumluları güvenlik eşleme tablosunu tutar
2. Değişiklikler, değişiklik yönetimi süreci aracılığıyla incelenir ve onaylanır
3. Aylık denetimler Power BI RLS atamalarını İK kayıt sistemiyle karşılaştırır
4. Üç aylık penetrasyon testi RLS'nin etkinliğini doğruluyor

Bu mimari, tek bir güvenlik yönetimi noktasını korurken yüzlerce veri kümesinde binlerce kullanıcıya ölçeklenir.

---

SSS

RLS, Power BI ücretsiz lisanslarıyla çalışır mı?

Hayır. RLS, RLS korumalı raporları kullanan tüm kullanıcılar için Power BI Pro veya Kullanıcı Başına Premium lisansları gerektirir. Ücretsiz lisans kullanıcıları yalnızca Premium kapasiteli çalışma alanındaki içeriğe erişebilir ve bu durumda bile RLS rollerinin atanabilmesi için bir Pro veya PPU lisansına ihtiyaçları vardır. Power BI Embedded senaryolarında son kullanıcıların Power BI lisanslarına ihtiyacı yoktur; RLS, ekleme belirteci aracılığıyla zorunlu kılınır.

Bireysel kullanıcılar yerine Azure AD gruplarına dayalı RLS uygulayabilir miyim?

Doğrudan değil. Power BI'ın RLS'si, DAX ifadelerini bireysel kullanıcının e-postasını döndüren USERPRINCIPALNAME() yöntemine göre değerlendirir. Ancak Azure AD gruplarını veri kapsamlarıyla eşleyen bir güvenlik eşleme tablosu oluşturabilir ve bunu Microsoft Graph API veya Azure AD grup üyeliği eşitlemesini kullanarak doldurabilirsiniz. DAX ifadesi hâlâ kullanıcının e-postasına göre filtreleme yapar ancak güvenlik eşleme tablosu, grup-veri eşlemesini sağlar.

Bir kullanıcı herhangi bir RLS rolüne atanmazsa ne olur?

Bir veri kümesinde RLS tanımlanmışsa ve kullanıcı herhangi bir role atanmamışsa kullanıcı hiçbir veri görmez. Rapor yükleniyor ancak tüm görseller boş veya sıfır gösteriyor. Bu, varsayılan güvenli ayardır --- Power BI, açıkça verilmediği sürece erişim olmadığını varsayar. Ancak Düzenleme iznine sahip çalışma alanı yöneticileri ve üyeler RLS'yi atlar ve rol atamalarından bağımsız olarak her zaman tüm verileri görür.

RLS, gerçek zamanlı kontrol panellerindeki verileri filtreleyebilir mi?

Evet. RLS, hem İçe Aktarma hem de DirectQuery modlarıyla çalışır. DirectQuery modunda, RLS filtresi bir SQL WHERE yan tümcesine çevrilir ve her sorguyla birlikte veritabanına gönderilir, böylece filtreleme gerçek zamanlı olarak gerçekleşir. İçe aktarma modunda, kullanıcı raporu açtığında filtreleme bellek içinde uygulanır. Her iki mod da aynı güvenlik garantisini sağlar; kullanıcı yalnızca yetkili verileri görür.

RLS aracılığıyla kimin hangi verilere eriştiğini nasıl denetlerim?

Power BI, Microsoft 365 yönetim merkezi ve Power BI REST API aracılığıyla etkinlik günlükleri sağlar. Bu günlükler, kullanıcının kimliği de dahil olmak üzere rapor görünümlerini, veri kümesi yenilemelerini ve dışa aktarma işlemlerini kaydeder. Ancak günlükler, kullanıcının hangi belirli satırları görüntülediğini kaydetmez. Ayrıntılı veri erişimi denetimi için, DirectQuery tarafından oluşturulan gerçek sorguları RLS filtreleri uygulanarak günlüğe kaydetmek üzere veritabanı düzeyinde denetimi (ör. PostgreSQL pgaudit veya Azure SQL denetimi) etkinleştirin.