POWER BI GÜVENLİK ROLLERİ

Bir Power BI raporu üst yönetime sunulduğunda harika görünür. Aynı rapor bölge müdürüyle paylaşıldığında ise sorun doğar; o sadece kendi bölgesinin verisini görmek zorundadır. Çoğu organizasyon bu sorunu raporları bölgelere göre çoğaltarak çözer. On bölge varsa on rapor üretilir, her biri farklı filtreyle gönderilir. Bu yaklaşım kısa vadede çalışır, uzun vadede sürdürülemez. Power BI'ın rol bazlı güvenliği (RLS) bu sorunu kökten çözen yapıdır.

Rol Bazlı Güvenlik Nedir

Rol bazlı güvenlik (Row-Level Security) Power BI'da veri modeli üzerinde tanımlanan kurallarla kullanıcının hangi satırları göreceğini sınırlar. Bir rapor tek bir kopyada durur, ama Ali açtığında sadece Marmara bölgesinin verisini, Ayşe açtığında sadece Ege bölgesinin verisini görür. Bu yapı raporu çoğaltma zahmetini ortadan kaldırır ve veri güvenliğini sağlam bir temele oturtur.

RLS Power BI Desktop'ta tanımlanır. Manage Roles ekranından bir rol oluşturulur, o role bağlı DAX filtresi yazılır. Örneğin "Bölge Müdürü" rolü için [Bölge] = USERPRINCIPALNAME() ilişkisini kullanan bir filtre konulur; her kullanıcı sadece kendi bölgesini görür. Rol Power BI servise yayınlandıktan sonra kullanıcılar role atanır.

Statik ve Dinamik RLS

RLS iki şekilde uygulanır. Statik RLS'de filtre sabit yazılır; "Bölge = 'Marmara'" gibi. Her bölge için ayrı rol oluşturulur. Bu yapı az sayıda rol için pratiktir ama otuz bölgeli bir kurumda otuz rol bakımı zorlaşır. Dinamik RLS'de filtre kullanıcı kimliğine bağlı çalışır; USERPRINCIPALNAME() veya USERNAME() fonksiyonları o anki kullanıcının kim olduğunu döner ve buna göre filtre çalışır.

Dinamik RLS'in çalışması için bir "kullanıcı-bölge eşleme tablosu" gerekir. Hangi kullanıcının hangi bölgeleri görebileceği bu tabloda durur. Filtre DAX'ı bu tabloya bağlanır; LOOKUPVALUE veya RELATED fonksiyonlarıyla mevcut kullanıcının yetkili bölgeleri çekilir. Bu yapı yüzlerce kullanıcıya bile rahatlıkla ölçeklenir.

Dinamik RLS için tipik DAX filtre örneği (Manage Roles > Satış tablosu üzerinde):

// "Bolge Muduru" rolü — Satış tablosu filtresi
[Bolge] IN
 CALCULATETABLE (
 VALUES ( KullaniciBolge[Bolge] ),
 KullaniciBolge[Email] = USERPRINCIPALNAME ()
 )

// Eşleme tablosu (KullaniciBolge) örnek satırlar:
// Email | Bolge
// ali@firma.com | Marmara
// ayse@firma.com | Ege
// mehmet@firma.com | Marmara
// mehmet@firma.com | Ic Anadolu (iki bölge yetkili)

Yetki Hiyerarşisi

Gerçek kurumlarda yetkilendirme tek seviyeli değildir. Üst yönetim her şeyi görür, bölge müdürü kendi bölgesini görür, takım lideri kendi takımını görür, satış temsilcisi kendi portföyünü görür. Bu hiyerarşi RLS ile modellenir; aynı veri tablosuna birden çok rol farklı erişim verir. Üst yönetici rolünde filtre yoktur (her şeyi görür), bölge müdürü rolünde bölge filtresi vardır, satış temsilcisi rolünde temsilci filtresi vardır.

Bir kullanıcı birden çok role atanabilir; bu durumda erişimi en geniş olan rol geçerli olur. Bu yapı esnektir ama dikkat gerektirir; bir kullanıcı yanlışlıkla üst yönetici rolüne atanırsa kısıtlı verisi olması beklenirken her şeyi görebilir. Bu yüzden rol atamalarının düzenli denetimi yapılır.

Veri Setleri ve Raporlar

Power BI'da güvenlik veri seti seviyesinde uygulanır; rapor seviyesinde değil. Aynı veri seti farklı raporlara temel olabilir; tüm raporlar RLS kurallarından otomatik etkilenir. Bu yapı tek bir veri setinin doğru güvenlikle korunması anlamına gelir; her rapor için ayrı güvenlik düşünmek gerekmez.

Veri seti paylaşımı dikkatli yönetilir. Bir kullanıcıya veri setini düzenleme yetkisi verilirse o kullanıcı RLS kurallarını değiştirebilir ve güvenliği bypass edebilir. Bu konunun güncel ayrıntıları Power BI resmi belgelerinde yer alır. Bu yüzden veri seti üzerinde edit yetkisi sadece güvenilir geliştiricilere verilir; raporu kullananlara sadece okuma (read) yetkisi yeterlidir.

Workspace ve Lisans

Power BI'da workspace seviyesinde de yetkilendirme vardır. Bir workspace'in dört rolü vardır:

• Admin: Her şeyi yapar — workspace ayarları, üyelik, içerik yönetimi.
• Member: Rapor ve veri seti ekleyebilir, paylaşabilir.
• Contributor: Sadece içerik ekleyebilir, paylaşamaz.
• Viewer: Sadece raporları görüntüler.

Bu hiyerarşi RLS ile birlikte çalışır; workspace seviyesi kabaca yetkiyi belirler, RLS detaylı veri filtresini uygular.

Lisans modeli de güvenliği etkiler. Power BI Pro lisansı içerik paylaşımı için zorunludur; her okuyucu için Pro lisansı veya Premium kapasite gerekir. Premium kapasite kullanılan bir workspace'te okuyucular Free lisansla da raporlara erişebilir. Lisans tasarımı yapılırken kullanıcı sayısı ve bütçe birlikte düşünülür.

RLS Testi

RLS kuralları geliştirme sırasında test edilir. Power BI Desktop'ta Manage Roles ekranından "View As Role" özelliği kullanılır; geliştirici belirli bir rolde nasıl gözükeceğini simüle eder. Bu adım RLS'i canlıya almadan önce zorunludur; yanlış kural yazılmış olabilir, beklenen kayıt gözükmüyor olabilir.

Power BI servisinde de "Test as role" özelliği vardır. Yayınlandıktan sonra rol bazında raporun nasıl gözüktüğü doğrulanır. Gerçek kullanıcılarla pilot test yapmak ek bir güvence sağlar; gerçek senaryoları yansıtır.

Object Level Security

Satır seviyesi güvenlik (RLS) yanında nesne seviyesi güvenlik (OLS) de mevcuttur. RLS satırları filtrelerken OLS tablo veya sütunlara erişimi sınırlar. Mesela maaş sütununu sadece İK kullanıcıları görsün, diğerleri görmesin. OLS Power BI Desktop'ta XMLA endpoint üzerinden veya Tabular Editor gibi araçlarla tanımlanır.

OLS, RLS'den daha az kullanılır ama hassas kolonlar (maaş, kişisel sağlık verisi gibi) içeren veri setlerinde kritik bir katmandır. Bu kolonu olmayanlara rapor sayfası ya kısaltılır ya da erişim engellenir.

Denetim ve Loglama

Power BI tüm erişimleri loglar. Kim hangi raporu açtı, hangi veriyi indirdi, hangi paylaşımı yaptı bilgisi Audit Log'da saklanır. Bu loglar Microsoft 365 yönetici merkezinden erişilir ve denetim için gerekli kanıt zincirini oluşturur. Yüksek düzenleyici denetim altında olan kurumlar için bu özellik kritiktir.

Düzenli denetim önerilir; ayda bir kez kim hangi rolde, son üç ayda kim hangi paylaşımı yaptı gibi raporlar üretilir. Anormal erişim kalıpları (gece geç saatte indirme, normal dışı veri hacmi) güvenlik ekibine bildirilir.

Standart ve Dokümantasyon

RLS kuralları ve rol yapısı dokümante edilir; aksi halde altı ay sonra hangi rolün hangi yetkiye sahip olduğu unutulur. Bu doküman her yeni rapor yapılırken referans olur ve standartlaşmayı destekler. Doküman bir Excel matrisinde veya intranet sayfasında tutulur; her rol için açıklama, filtre formülü, kapsanan kullanıcılar yazar.

Power BI güvenliği doğru kurulduğunda raporlama platformu kurum geneline güvenle açılır. Power BI eğitimi bu yapının teknik ve kurumsal yönlerini birlikte ele alır.