Power BI Satır Düzeyi Güvenlik (RLS): Kapsamlı Bir Eğitim

Power BI’deki Satır Düzeyi Güvenlik (RLS), filtrelere bağlı olarak kullanıcıların hangi veri satırlarını görebileceğini kontrol etmenizi sağlar. Bu işlev, birden fazla kullanıcının paylaşılan bir rapora erişmesi gerektiğinde, ancak rolleri veya departmanlarına göre kişiselleştirilmiş görünümlere ihtiyaç duyulduğunda özellikle değerlidir.

Bu eğitimde, statik ve dinamik yapılandırmalar, uygulamalı kurulum adımları, kurumsal düzeyde ileri teknikler ve kaçınmayı öğrendiğim yaygın tuzaklar dahil olmak üzere RLS’yi pratik ve derinlemesine bir anlayışla ele alacağım. Ayrıca en iyi uygulamaları paylaşacak ve RLS’yi diğer güvenlik modelleriyle karşılaştıracağım.

Power BI’ye yeni başlıyorsanız, ihtiyaç duyacağınız tüm temel becerileri edinmenize yardımcı olacak Power BI Fundamentals beceri yolumuzu incelemenizi öneririm.

Satır Düzeyi Güvenlik nedir?

Satır Düzeyi Güvenlik (RLS), bir raporu görüntüleyen kullanıcının kimliğine göre bir tablodaki satırlara erişimi kısıtlayan Power BI’deki bir güvenlik özelliğidir. Farklı kullanıcı grupları için raporları çoğaltmak yerine, RLS veriler düzeyinde filtreler uygulamanıza olanak tanır; böylece her kullanıcı yalnızca görmesine izin verilen verileri görür.

Bu, özellikle hassas veya mülkiyete tabi bilgiler içeren senaryolarda, veri gizliliğini ve bütünlüğünü korumak için kritik öneme sahiptir. RLS, Power BI veri modeli içinde çalışır ve yetkisiz kullanıcıların, dilimleyiciler veya ayrıntı düzeyi gezinmeleri gibi dolaylı yöntemlerle bile kısıtlı verilere erişememesini sağlar.

Roller ve filtreler

RLS uygulaması üç temel öğeye dayanır:

• Roller: Tanımlı erişim kurallarına sahip mantıksal gruplar.
• DAX filtreleri: Her rolün hangi verilere erişebileceğini belirleyen ifadeler.
• Kullanıcı atamaları: Hangi kullanıcı veya grupların hangi rollere ait olduğunun yapılandırılması.

Bu öğeler, sonuçlar döndürülmeden önce her sorguyu erişim koşullarına karşı birlikte değerlendirir.

Kullanım alanları

RLS pek çok sektör ve senaryoda oldukça uygulanabilirdir; örneğin:

• Satış bölgeleri: Satış yöneticileri yalnızca kendi bölgelerinin performans verilerini görür.
• Sağlık hizmetleri: Doktorlar yalnızca kendilerine atanmış hastaların kayıtlarına erişir.
• Çok kiracılı SaaS: Müşteriler, paylaşılan panolarda yalnızca kendi kurumlarının verilerini görür.

Bu güvenlik modeli, paylaşılan veri kümelerinin güvenli kalmasını sağlarken çoğaltmayı ve idari yükü de en aza indirir.

Statik ve Dinamik RLS Mimarileri

Satır düzeyi güvenlik iki türe ayrılabilir: statik ve dinamik.

Aralarındaki farkları aşağıdaki tabloda özetledim:

İpucu: Küçük, sabit kullanıcı grupları için statik RLS kullanın. Büyüyen veya büyük ölçekli ortamlar için dinamik RLS tercih edin.

Aşağıda hem statik hem de dinamik örneklerin bazı uygulamalarını inceleyeceğim.

Statik RLS uygulaması

Statik RLS, sabit kodlanmış DAX filtrelerine sahip roller oluşturmayı içerir. Her rol, coğrafi bir bölge veya departman gibi belirli bir gruba ya da segmente karşılık gelir.

Statik RLS uygulamanın genel adımları şunlardır:

1. Örneğin "Region_East" adlı bir rol oluşturun.
2. Bu role [Region] = "East" gibi bir filtre uygulayın.
3. Kullanıcıları Power BI Service’te bu role atayın.

Dinamik RLS uygulaması

Dinamik RLS, USERNAME() veya USERPRINCIPALNAME() gibi işlevleri eşleme tablolarıyla birleştirerek verileri kullanıcı kimliğine göre dinamik olarak filtreler.

Dinamik RLS uygulamanın genel adımları şunlardır:

1. Kullanıcıları erişim düzeylerine bağlayan bir eşleme tablosu oluşturun. Bu, güvenlik tablonuz olacaktır. Bu tabloda kullanıcı e-postaları, erişim bölgeleri ve adları gibi sütunlar bulunmalıdır.
2. Şu şekilde bir DAX filtresi yazın: [Region] = RELATED(UserRegion[Region])
3. Bu tabloyu şu ifadeyle filtreleyin: UserRegion[Email] = USERPRINCIPALNAME()

Power BI Desktop’ta Satır Düzeyi Güvenlik Kurulumu

Şimdi basit bir satış veri kümesi kullanarak statik satır düzeyi güvenliğin nasıl kurulacağına dair kısa bir kılavuza bakalım.

1. Python kullanarak örnek veri kümesi oluşturma

RLS’yi test etmek için Python ile örnek bir veri kümesi oluşturun:

import pandas as pd

data = {
    'Salesperson': ['Alice', 'Bob', 'Charlie', 'Alice', 'Bob', 'Charlie'],
    'Region': ['East', 'West', 'South', 'East', 'West', 'South'],
    'SalesAmount': [15000, 20000, 18000, 17000, 21000, 16000],
    'Email': ['alice@company.com', 'bob@company.com', 'charlie@company.com'] * 2,
    'Date': pd.date_range(start='2025-01-01', periods=6, freq='M')
}

sales_df = pd.DataFrame(data)
sales_df.to_csv('sample_sales_data.csv', index=False)

2. Power BI’a içe aktarma ve Referans Görselleştirme oluşturma

1. Power BI Desktop’ı açın.
2. Şuraya gidin: Home > Get Data > Text/CSV.
3. sample_sales_data.csv dosyasını seçin.

4. Verileri modele yükleyin.

Uygun veri türlerini doğrulayın ve Email sütununun oturum açma kimliği biçimleriyle (genellikle e-posta) uyuştuğundan emin olun.

5. Power BI’da temel bir Yığılmış Sütun Grafiği oluşturun. Date alanını X eksenine, SalesAmount’ı Y eksenine sürükleyin.

Grafiğinizin şöyle görünmesi gerekir:

Power BI kullanımı hakkında daha fazlasını, aşağıda gösterildiği gibi ipuçları sayfamızda bulabilirsiniz.

3. Roller oluşturma

Şimdi, hangi rollerin hangi izinlere sahip olacağını tanımlamak için bazı roller oluşturalım.

1. Şuraya gidin: Modeling > Manage Roles.

2. Create öğesine tıklayın ve rolünüze örneğin SalesRegionStatic adını verin.
3. İlgili tabloyu seçin.
4. Bir filtre DAX ifadesi girin:

[Email] = “charlie@company.com”

Arayüzünüz şöyle görünmelidir:

5. Kaydedin ve iletişim kutusunu kapatın.

Değişiklikler başarıyla kaydedilirse, aşağıda gösterildiği gibi yeşil bir çubuk bildirimi görünecektir.

4. Rolleri test etme

1. Şuraya gidin: Modeling > View as Roles.

2. Önceden oluşturduğumuz SalesRegionStatic rolünü seçin.

3. Rapor görsellerini bu kimliğe göre filtrelenmiş olarak görüntüleyin.

Aşağıdaki görselden de gördüğünüz gibi, grafik yalnızca e-postanın “charlie@company.com” olduğu verileri gösterecek şekilde filtrelendi.

Bu, dağıtımdan önce yerel doğrulama yapmanızı sağlar.

Power BI Service’te Kullanıcı Atama ve Rolleri Yönetme

RLS rolleri Power BI Desktop’ta kurup test ettikten sonra bir sonraki adım raporu Power BI Service’e yayımlamaktır. Bu, her role belirli kullanıcıları veya güvenlik gruplarını atamanıza ve rapor paylaşıldığında erişim kontrolünün uygulanmasını sağlamanıza olanak tanır.

1. Raporu Power BI Service’e yayımlama

1. Power BI Desktop’ta Home > Publish > To Power BI seçeneğine tıklayın.
2. Power BI Service’te hedef çalışma alanını seçin.

3. Yayımladıktan sonra https://app.powerbi.com adresinden Power BI Service’e giriş yapın.

İnternette Power BI hizmetindeki görünümüm şu şekilde:

Yayımlama, RLS rol atamalarını yapılandırmanın ön koşuludur; çünkü Power BI Desktop’ta tanımlanan roller veri kümesiyle birlikte aktarılır.

2. Güvenlik ayarlarına erişim

1. İlgili anlamsal modeliniz için Diğer seçenekler menüsünü seçin. Veri kümesinin yanındaki üç noktaya (...) tıklayın ve Security öğesini seçin.
2. Power BI Desktop’ta tanımlanan rollerin bir listesini göreceksiniz.

Kullanıcıları veya Azure Active Directory (AAD) gruplarını her role burada atarsınız.

3. Bireysel kullanıcıları ve güvenlik gruplarını atama

Kullanıcı atamak için, istenen rolün altındaki metin kutusuna kullanıcıların tam e-posta adreslerini girin, Enter’a basın ve Add düğmesine tıklayın.

AAD grupları atamak için grup adını kullanın (ör. Sales_Region_East veya Finance_Team). Grubun Azure Active Directory’de önceden tanımlanmış ve yönetiliyor olduğundan emin olun.

4. Atanan erişimi doğrulama

Kullanıcıları veya grupları atadıktan sonra, doğru verilerin doğru gruba sunulduğunu doğrulamak için biraz zaman ayırın.

Her kişi yalnızca rolüne bağlı DAX ifadesiyle filtrelenen verileri görür. Rol ataması doğrudan bildirilmez; bu nedenle doğrulamayı yaptıktan sonra erişim talimatlarını ayrıca iletmek isteyebilirsiniz.

5. Power BI Service’te rol atamalarını test etme

1. Aynı sayfada, daha önce tanımladığınız RLS adınıza tıklayın, üç noktaya (...) ve ardından Test as role seçeneğine tıklayın.

2. Power BI, yalnızca seçilen rolün izin verdiği verileri gösteren salt okunur bir rapor sürümü açacaktır.

Dinamik RLS için, belirli bir kullanıcının ne göreceğini de simüle edebilirsiniz:

• Test as role öğesine tıklayın.
• Deneyimini simüle etmek için bir kullanıcının e-postasını girin.

Bu, dinamik filtrelerinizin (ör. USERPRINCIPALNAME() tabanlı) doğru çalıştığından emin olmak için kullanışlıdır.

İleri Düzey Uygulama Teknikleri

RLS, bazı ileri teknikler aracılığıyla Power BI iş akışınıza daha da entegre edilebilir. Dikkat etmeniz gerekenler şunlardır:

1. Güvenlik grubu entegrasyonu

Azure Active Directory (AAD) güvenlik gruplarını kullanmak, erişim izinlerini tek tek kullanıcılara değil, tüm gruplara atamanıza olanak tanır. 

Bu uygulama, çalışanların ekiplere sık sık katıldığı veya ayrıldığı kurumsal ortamlarda özellikle faydalıdır; çünkü Power BI’da erişim izinlerini manuel olarak güncelleme ihtiyacını ortadan kaldırır.

2. Karmaşık veri modeli hususları

Büyük ölçekli veri modelleri oluştururken, RLS’nin ilişkiler ve filtre yayılımıyla çakışmamasını sağlayın. 

İşte bazı ipuçları:

• Karmaşık birleştirmelerden kaçınmak için yıldız şema tasarımını kullanın.
• Gerekmedikçe çift yönlü ilişkilerin kullanımını sınırlayın.
• Yanlış filtrelemeye yol açabilecek belirsiz ilişkilerden kaçının.
• Ağır filtrelenen tablolarda hesaplanan sütunları en aza indirerek performansı iyileştirin.

3. Hibrit yaklaşımlar

RLS’ye hibrit bir yaklaşım, statik ve dinamik tekniklerin bir kombinasyonudur. 

Örneğin, belirli bir iş birimine erişim vermek için statik bir rol tanımlayabilir ve bu rol içinde bireysel e-posta adreslerine veya kullanıcı adlarına dayalı dinamik filtreleme uygulayabilirsiniz. Bu yöntem, katmanlı ve esnek güvenlik mantığı sağlar.

4. Nesne düzeyi güvenlik (OLS)

Nesne Düzeyi Güvenlik, belirli rollerden tüm tabloları veya sütunları gizlemenizi sağlar. RLS’yi ek bir veri koruma katmanı ekleyerek tamamlar. OLS, maaş veya tıbbi bilgiler gibi hassas alanlar için kullanılabilir.

Test ve Doğrulama Stratejileri

1. Desktop testleri

Power BI Desktop, “View as” rol özelliğiyle farklı kullanıcı görünümlerini simüle etmek için yararlı bir yöntem sağlar. Bu özellik, rapor geliştiricilerinin raporu yayımlamadan önce Satır Düzeyi Güvenlik mantığının doğru çalıştığını doğrulamasına yardımcı olur.

Power BI Desktop’ta RLS nasıl test edilir:

1. Modeling sekmesine tıklayın.
2. View as öğesini şeritten seçin.
3. Yapılandırdığınız rolleri seçin (ör. SalesRegionStatic).
4. Dinamik RLS kullanıyorsanız isteğe bağlı olarak bir test kullanıcı adı/e-postası girin.
5. OK düğmesine tıklayın ve görsellerin nasıl filtrelendiğini inceleyin.

Bu, sanki o role atanmış bir kullanıcı raporu görüntülüyormuş gibi raporu simüle eder. USERPRINCIPALNAME() gibi DAX işlevlerine bağlı dinamik RLS filtrelerini test ederken özellikle faydalıdır.

2. Service testleri

Power BI Service’e yayımlandıktan sonra, doğruluğu sağlamak için RLS’nin bulut ortamında tekrar test edilmesi gerekir.

Power BI Service’te RLS nasıl test edilir:

1. Çalışma alanınızdaki veri kümesine gidin.
2. ... simgesine tıklayın > Security.
3. Bir rol seçin > Test as role öğesine tıklayın.
4. Dinamik RLS filtrelerini simüle etmek için “Test as specific user” seçeneğini kullanın.

Bu, filtrelerin gerçek kullanıcılar için beklendiği gibi davrandığını garanti eder.

3. Temel doğrulama ipuçları

Doğrulama için, test hesapları veya hizmet kimlikleri kullanarak gerçek kullanımı taklit edebilirsiniz. Tablolar ve grafikler gibi kilit görsellerdeki tüm filtreler periyodik olarak gözden geçirilmelidir.

Yetkisiz veri sızıntısı olmadığından emin olmak için dilimleyicileri, ayrıntı düzeyi geçişlerini ve yer imlerini de kapsamlı biçimde kontrol etmelisiniz.

Yaygın Tuzaklar ve Çözümler

RLS uygulamak bazı sorunları beraberinde getirebilir; işte yaygın olanlar ve nasıl çözülecekleri.

1. Yayımlama sonrası sorunlar

Power BI Service’e yayımlandıktan sonra, bazı kullanıcılar Power BI Desktop’ta çalışmasına rağmen RLS’nin beklendiği gibi davranmadığını görebilir.

Çözümler:

• Rol veya filtre değişiklikleri sonrasında raporu yeniden yayımladığınızdan emin olun.
• USERPRINCIPALNAME() içinde kullanılan e-postanın, veri kümesindeki oturum açma alan adı biçimiyle eşleştiğini doğrulayın.

2. Çalışma alanı rolü çakışmaları

Belirli çalışma alanı rollerine (Yönetici, Üye) sahip kullanıcılar farkında olmadan RLS’yi atlayabilir.

Çözümler:

• Kullanıcıları RLS kurallarını zorlamak için çalışma alanında Görüntüleyici (Viewer) olarak atayın.
• İçerik geliştirme için gerekli olmadıkça Katkıda Bulunan/Yönetici yetkileri vermekten kaçının.

3. DAX işlevi sınırlamaları

USERNAME() ve USERPRINCIPALNAME() gibi DAX işlevlerinin yanlış kullanımından kaynaklanan yaygın tuzaklar şunlardır:

• USERNAME(), Desktop’ta test edilirken e-posta yerine yerel hesap adını döndürebilir.
• Bulut kimliği davranışıyla tutarlılık için USERPRINCIPALNAME() kullanın.

İpuçları:

• Yerel testleri kolaylaştırmak için örnek e-postalara sahip bir başvuru tablosu ekleyin.
• Filtre hatalarını önlemek için DAX içinde koşullu mantık veya varsayılan değerler kullanın.

4. DirectQuery ve SSO zorlukları

DirectQuery kaynaklarıyla dinamik RLS, özellikle Tek Oturum Açma (SSO) ile kullanıldığında ekstra dikkat gerektirir.

Yaygın sorunlar:

• Hatalı ağ geçidi yapılandırması, kullanıcı vekâleti (impersonation) işlemini engelleyebilir.
• Kerberos ile SSO kurulumu, SPN’ler yanlış yapılandırılmışsa başarısız olabilir.

Çözümler:

• Power BI ağ geçitleriyle SSO hakkında Microsoft belgelerine başvurun.
• Kerberos yetkilendirmesini etkinleştirmek için BT ve altyapı ekipleriyle yakın çalışın.

Genel Erişim için RLS’yi Kaldırma veya Devre Dışı Bırakma

Bazı durumlarda RLS’nin geçici olarak (ör. demolar veya açık panolar için) ya da kalıcı olarak (ör. dış paydaşlarla veri paylaşırken) kaldırılması gerekebilir. Bu gibi durumlarda, beklenmedik sızıntıları önlemek için görünürlük ayarlarında dikkatli olmanız gerekir.

Power BI Desktop’ta RLS’yi devre dışı bırakma

RLS’yi devre dışı bırakmak için:

1. Raporunuzu Power BI Desktop’ta açın.
2. Modeling > Manage Roles yoluna gidin.
3. Tüm rolleri seçip silin veya filtrelerini devre dışı bırakın.
4. Kaydedin ve veri kümesini Power BI Service’e yeniden yayımlayın.

Kaldırıldıktan sonra, başka güvenlik önlemleri yoksa tüm kullanıcılar tam veri kümesine erişebilecektir.

RLS olmadan güvenli paylaşım

RLS mümkün veya gerekli değilse, veri güvenliğini korumak için şu uygulamaları göz önünde bulundurun:

• Veri kümesi düzeyinde izinler kullanın: Veri kümesini veya raporu yalnızca güvenilir kullanıcılarla paylaşın ve çalışma alanı izinlerini (Viewer, Contributor) uygun şekilde kullanın.
• Web’de yayımlamaktan kaçının: “Publish to Web” tüm güvenlik kontrollerini kaldırır. Bunun yerine “Embed for organization” veya güvenli, herkese açık tarzda paylaşım için Power BI Embedded kullanın.

RLS’yi kaldırmak, tüm güvenliği kaldırmak anlamına gelmez. Sorumlu veri paylaşımını sağlamak için Power BI Service’teki diğer erişim kontrol katmanlarını ve paylaşım özelliklerini kullanın.

Kurumsal Dağıtım için En İyi Uygulamalar

Kurumsal çapta Satır Düzeyi Güvenliğin başarılı bir şekilde dağıtılması, düşünceli planlama, ölçeklenebilir mimari ve uygun yönetişim gerektirir. Bu bölüm, RLS uygulamasının farklı boyutlarında kanıtlanmış en iyi uygulamaları özetler.

1. Veri modelleme

İyi tasarlanmış bir veri modeli, verimli ve sürdürülebilir RLS yapılandırmalarını destekler.

Öneriler:

• Olgu ve boyut tabloları arasında net ilişkilerle yıldız şemasını izleyin.
• Filtrelemede belirsizliğe yol açabilecek gereksiz çift yönlü ilişkilerden kaçının.

2. Rol yönetimi

RLS rollerini merkezi ve tutarlı bir şekilde yönetmek, hataları azaltır ve işbirliğini geliştirir.

Öneriler:

• RLS mantığını ve DAX ifadelerini takip etmek için bir rol tanım dokümanı tutun.
• Karışıklığı önlemek için açıklayıcı rol adları kullanın (ör. “Region_East_Sales”).

3. Performans optimizasyonu

RLS, özellikle karmaşık filtreler veya büyük veri kümeleri söz konusu olduğunda rapor performansını etkileyebilir.

Öneriler:

• Mümkün olduğunda özet tablolar kullanarak verileri önceden birleştirin.
• RLS mantığında hesaplanan sütun kullanımını en aza indirin.
• DirectQuery senaryolarını desteklemek için kaynak sistemlerde indeksleme ve optimize sorgular kullanın.

RLS ve Alternatif Güvenlik Modelleri

Şimdi Satır Düzeyi Güvenliği (RLS) ile özellikle Nesne Düzeyi Güvenlik (OLS) gibi diğer güvenlik özellikleri arasındaki farkları karşılaştıralım.

1. Ayrıntı düzeyi ve kullanım alanı

RLS, kullanıcı kimliği, coğrafya, departman veya iş birimine göre veri filtrelemek için ideal olan, verinin tek tek satırlarına erişim kontrolü sağlar. OLS ise tüm tablolara veya sütunlara erişimi kontrol eder; bu da hassas finans veya İK bilgilerini (ör. maaş sütunu) gizlemek için kullanışlıdır. 

2. Uygulama ve dinamik uyarlama

RLS, Power BI Desktop içinde roller üzerinde DAX filtreleriyle kolayca uygulanabilir. Bu kurallar statik (sabit kodlu filtreler) veya dinamik (kullanıcı odaklı mantık) olabilir. OLS ise Tabular Editor veya XMLA uç noktası üzerinden yapılandırılır. Ayrıca premium bir çalışma alanı veya Analysis Services’ta barındırılan bir Power BI veri kümesi gerektirir.

Aşağıdaki tabloda bir karşılaştırma özeti hazırladım:

Sonuç

Özetle, Power BI’de satır düzeyi güvenlik (RLS), platform içinde veri yönetişimini sağlamanın kilit bir yöntemidir. Kuruluşların, alttaki verilerin gizliliğini veya bütünlüğünü zedelemeden, tek bir rapor veya panoda kişiselleştirilmiş ve güvenli analitik deneyimleri sunmasına olanak tanır.

Güvenlik, Power BI ile çalışırken önemli bir yön olan veri yönetimi ve yönetişimde giderek daha önemli bir faktördür. Power BI hakkında daha derinlemesine bilgi için Deploying and Maintaining Assets in Power BI kursumuza ya da Reports in Power BI kursumuza göz atın. Daha fazla okuma için Power BI Hiyerarşileri ve Power BI Panoları rehberlerimiz faydalı olabilir.