Bu makalede7 bölüm
- Teknoloji
- Power BI, SharePoint Online, Microsoft Teams, DAX, On-premises data gateway, Microsoft Fabric
- Konu
- Power BI raporlarının intranette güvenli yayını
- Seviye
- Orta
- Ön koşullar
- Power BI Desktop ile rapor geliştirme
- Power BI çalışma alanı yönetimi
- SharePoint sayfa düzenleme yetkisi
“Raporu intranete gömdük” cümlesi, kimin hangi veriyi gördüğü sorusunu cevaplamaz. Yanlış gömme yöntemi tüm şirket verisini internete açabilir ya da her departmana diğer departmanların rakamlarını gösterebilir. İkisi de sessiz olur; kimse hata almaz. Aşağıda Power BI raporlarını SharePoint, Teams ve özel web uygulamalarına gömme yollarını, satır düzeyi güvenliği ve sahada en çok sorun çıkaran lisans ile veri yenileme kontrollerini sırayla ele alıyoruz.
Raporu intranete taşımanın yolları
Gömme yöntemini seçmeden önce tüketim senaryosunu netleştirin. Üç soru kararın büyük kısmını verir:
- Raporu kim görecek? Yalnız kurum içi Entra ID hesapları mı, hesabı olmayan dış kişiler de mi?
- Herkes aynı veriyi mi görecek? Yoksa bölge, departman veya şube bazında farklı satırlar mı?
- Rapor nerede yaşayacak? SharePoint iletişim sitesinde, Teams kanalında, yoksa özel geliştirilmiş bir web uygulamasında mı?
Kurum içi SharePoint intranet senaryolarında cevap neredeyse hep aynıdır: kullanıcı kendi kimliğiyle oturum açar, yetkisi neyse onu görür. Microsoft bu modeli “kuruluşunuz için gömme” (user owns data) diye adlandırır. Hesabı olmayan müşteri veya bayilere rapor sunmak ise başka bir mimari ister (uygulama sahipli veri, Power BI Embedded kapasitesi ve servis sorumlusu); burada o senaryoya girmiyoruz.
Gömme yöntemleri karşılaştırması
| Yöntem | Kimlik doğrulama | RLS | Uygun kullanım |
|---|---|---|---|
| SharePoint Power BI web bölümü | Kullanıcının M365 oturumu | Uygulanır | Intranet sayfaları |
| Teams Power BI sekmesi | Kullanıcının Teams oturumu | Uygulanır | Ekip/kanal raporları |
| Güvenli gömme (Web sitesi veya portal) | Power BI oturumu istenir | Uygulanır | İç web uygulamaları |
| Power BI Embedded (API ile) | Uygulamanın yönettiği kimlik | Uygulama tanımlar | Özel uygulamalar, dış kullanıcılar |
| Publish to web | Yok, herkese açık | Desteklenmez | Yalnız kamuya açık veri |
SharePoint web bölümü
Power BI hizmetinde rapor açıkken Dosya > Raporu ekle > SharePoint Online bir bağlantı üretir. SharePoint sayfasına Power BI web bölümü eklenir, bağlantı yapıştırılır; sayfa, boyut ve filtre bölmesinin görünürlüğü web bölümünde ayarlanır. Sahada en sık gelen soru şudur: “Sayfayı açabiliyorum, rapor neden gelmiyor?” Çünkü SharePoint sayfasını görmek raporu görmek demek değildir. Kullanıcının Power BI tarafında da görüntüleme izni olmalıdır. İki izin katmanını eşleştirmenin en temiz yolu, raporu bir Power BI uygulaması (app) üzerinden ilgili Entra ID grubuyla paylaşmak ve sayfa izinlerinde aynı grubu kullanmaktır. Tek grup, tek kaynak. SharePoint tarafındaki grup tasarımı için SharePoint izin modeli rehberine bakabilirsiniz.
Teams sekmesi ve güvenli gömme
Teams’te kanala veya sohbete Power BI sekmesi eklenince rapor ekip bağlamına taşınır; izin mantığı aynıdır. Özel bir iç web uygulamasında ise Raporu ekle > Web sitesi veya portal ile üretilen güvenli gömme kodu iframe olarak kullanılabilir. Bu yöntemde kullanıcıdan Power BI oturumu istenir, tüm izinler ve RLS uygulanır. Uygulamanın kendi kimlik doğrulamasıyla bütünleşik, filtreleri koddan yöneten bir deneyim gerekiyorsa Power BI JavaScript istemci kitaplığı ve REST API’leriyle tam gömme yapılır. Bu bir geliştirme işidir, yapıştır-geç değil.
Publish to web neden kurumsal veri için uygun değil
Publish to web (web’de yayımla), raporu oturum açmadan görüntülenen genel bir bağlantıya çevirir. Bağlantıyı bilen herkes raporu ve rapordaki tüm veriyi görür; bağlantı herkese açık bir sayfaya düşerse arama motorları da bulabilir. RLS uygulanmaz, erişim kimliğe göre sınırlanamaz. Kodun gömüldüğü intranet sayfası şifreli olsa bile iframe adresi kopyalanabilir. “Sayfa zaten iç ağda” varsayımı koruma sağlamaz. Bağlantı dışarı çıkar.
Kamuya açık bir istatistik paylaşımı gerçekten gerekiyorsa rapor yalnız açık veriyi içeren ayrı bir anlam modeline (semantic model) dayanmalı ve iç modelle aynı çalışma alanında tutulmamalıdır. Aynı modelden “yalnız birkaç sayfa” yayımlamak çözüm değildir; model içindeki tüm veri bağlantı üzerinden erişilebilir hâle gelir.
Satır düzeyi güvenlik ile veri ayrımı
Satır düzeyi güvenlik (RLS), aynı rapor ve aynı anlam modeli üzerinden her kullanıcıya yalnız yetkili olduğu satırları gösterir. Departman başına rapor kopyalamak ilk gün kolay görünür; altıncı ayda on iki kopyanın hangisinin güncel olduğunu kimse bilmez. RLS hem bakım hem tutarlılık için doğru yoldur.
Dinamik RLS deseni
Statik rollerde her departman için ayrı rol tanımlanır, üyeler elle atanır. Kullanıcı sayısı arttıkça bu yönetilemez. Dinamik RLS’te modele bir yetki eşleme tablosu (kullanıcı e-postası ve yetkili olduğu departman kodu) eklenir ve tek bir rol, oturum açan kullanıcının UPN’sine göre filtre uygular:
// Rol: Departman Erişimi, filtre uygulanan tablo: Departman
// YetkiEslesme tablosu modelde ilişkisiz (bağımsız) durur ve gizlenir.
[DepartmanKodu]
IN CALCULATETABLE(
VALUES(YetkiEslesme[DepartmanKodu]),
YetkiEslesme[KullaniciEposta] = USERPRINCIPALNAME()
)
// Model ilişkisi: Departman[DepartmanKodu] 1 → * Satislar[DepartmanKodu]
// Filtre, tek yönlü ilişki üzerinden Satislar tablosuna akar;
// çift yönlü çapraz filtreye gerek kalmaz.
Bu desen, bir kullanıcının birden fazla departmana yetkili olduğu çoka-çok durumunu da karşılar. Eşleme tablosunu ilişkiyle bağlayıp çift yönlü filtre ve “güvenlik filtresini her iki yönde uygula” ayarıyla çözmek de mümkündür; ancak çift yönlü ilişkiler modelde belirsizlik ve performans maliyeti yaratır. İlişkisiz tablo deseni daha öngörülebilirdir. Sorun çıktığında da daha kolay okunur.
Rol Power BI Desktop’ta Modelleme > Rolleri yönet ile tanımlanır, Rol olarak görüntüle ile test edilir. Model yayımlandıktan sonra Power BI hizmetinde anlam modelinin Güvenlik ayarından role üye (tercihen Entra ID grubu) atanır; hizmette Rol olarak test et ile belirli bir kullanıcının ne gördüğü kontrol edilir. Eşleme tablosunun kaynağı bir SharePoint listesi veya İK sistemi olabilir; yetki değişikliği rapor yeniden yayımlanmadan, veri yenilemesiyle yansır.
RLS’i etkisiz bırakan durumlar
- RLS, çalışma alanında Görüntüleyici rolündeki kullanıcılara uygulanır. Yönetici, Üye ve Katkıda Bulunan rollerindekiler ile anlam modelinde yazma izni olanlar tüm veriyi görür. Sahada en sık gördüğümüz hata budur: “kolay olsun” diye departman müdürlerini çalışma alanına üye yapmak. Tüketicilere Power BI uygulaması üzerinden yayın yapın.
- Anlam modeli üzerinde Derleme (Build) izni RLS’i kaldırmaz, ama kullanıcının kendi raporunu oluşturup modeldeki tüm yetkili verisini dışa aktarmasına imkân tanır. Bu izni bilinçli verin.
- Rol tanımında boş eşleme tablosu, filtresiz değil verisiz sonuç doğurur. Yeni katılan kullanıcının “rapor boş” şikâyetinde ilk bakılacak yer eşleme tablosudur.
Lisans ve çalışma alanı gereksinimleri
Gömülü raporu görüntüleme hakkı, çalışma alanının kapasitesine ve kullanıcının lisansına bağlıdır. Genel kural: paylaşılan kapasitedeki içerik için hem yayımlayan hem görüntüleyen kullanıcının Power BI Pro veya Premium Per User (PPU) lisansı olmalıdır. İçerik Power BI Premium veya yeterli büyüklükte bir Microsoft Fabric kapasitesindeyse (F64 ve üzeri) görüntüleyiciler ücretsiz lisansla erişebilir. PPU çalışma alanındaki içeriği görmek için görüntüleyicinin de PPU lisansı gerekir. Bu son madde pilot sonrası en çok sürpriz yaratan maddedir.
Lisans modelleri ve kapasite ürünleri Microsoft tarafından değiştirilebilir. Kesin kararı vermeden önce Microsoft’un güncel Power BI lisanslama sayfasından ve kiracınızın Microsoft 365 yönetim merkezindeki mevcut aboneliklerden doğrulayın. Hangi Microsoft 365 paketinin Power BI Pro içerdiğini Microsoft 365 lisans seçimi yazısında karşılaştırdık.
Çalışma alanı tasarımında geliştirme ile yayın ayrılmalıdır: raporların geliştirildiği çalışma alanı ile tüketicilere açılan uygulama ayrı yönetilir. Büyük ekiplerde Power BI dağıtım işlem hatları (deployment pipelines) geliştirme, test ve üretim aşamalarını ayırmayı kolaylaştırır. Üretimde rapor düzenlenmez.
Veri yenileme ve ağ geçidi kontrolleri
Gömülü rapor ancak verisi kadar günceldir. Şirket içindeki SQL Server, dosya sunucusu veya ERP veritabanına bağlanan modeller için şirket içi veri ağ geçidi (on-premises data gateway) gerekir. Kurumsal kullanımda kişisel mod değil standart mod kullanılır; kişisel mod tek kullanıcıya bağlıdır, paylaşılan raporlar için uygun değildir. O kullanıcı izne çıktığında rapor da durur.
Zamanlanmış yenileme sayısı lisansa göre sınırlıdır: Pro ile günde 8, Premium ve PPU ile günde 48 zamanlanmış yenileme yapılabilir. Daha sık güncellik gerekiyorsa DirectQuery veya artımlı yenileme gibi seçenekler kaynak sistemin yükü hesaba katılarak değerlendirilmelidir; mesai saatinde ERP’ye DirectQuery yüklemek başka bir sorun açar.
- Ağ geçidi, kaynak sistemlere düşük gecikmeli erişimi olan, sürekli açık bir sunucuya kuruldu; dizüstü bilgisayara kurulmadı.
- Yüksek erişilebilirlik için ağ geçidi kümesine ikinci bir üye eklendi.
- Veri kaynağı kimlik bilgileri kişisel hesapla değil, en az yetkili servis hesabıyla tanımlandı.
- Ağ geçidi sunucusunun Power BI hizmetine giden çıkış bağlantıları güvenlik duvarında doğrulandı.
- Yenileme hatası bildirimleri bir kişiye değil, bir dağıtım listesine veya ekip kanalına gidiyor.
- Ağ geçidi yazılımı düzenli güncelleniyor; güncelleme sırasında kümenin diğer üyesi hizmeti sürdürüyor.
- RLS eşleme tablosunun kaynağı da yenileme planına dahil edildi.
Raporları intranet ana sayfasında ve Teams’te tek giriş noktasından sunmak için Viva Connections kurulumu yazısındaki pano kartları yaklaşımı kullanılabilir. Yönetim panoları ve kurumsal raporlama altyapısı için yönetim dashboard ve kurumsal raporlama hizmetimize göz atabilirsiniz. Gömme seçenekleri ve RLS davranışının ayrıntılarında Power BI dokümantasyonu esas alınmalıdır.
Sık sorulan sorular
SharePoint sayfasına izni olan herkes gömülü raporu görür mü?
Hayır. Power BI web bölümü kullanıcının kendi kimliğiyle çalışır. Kullanıcının raporu Power BI tarafında görüntüleme izni ve uygun lisansı yoksa web bölümü rapor yerine erişim mesajı gösterir. Sayfa izni ile rapor iznini aynı grup üzerinden yönetin.
Publish to web ile oluşturulan bağlantıyı yalnız intranete koymak yeterli mi?
Hayır. Publish to web bağlantısı oturum açma gerektirmez; bağlantıyı ele geçiren herkes raporu görür ve bu yöntemde RLS uygulanmaz. Kurumsal veri için SharePoint web bölümü, Teams sekmesi veya güvenli gömme kullanın.
RLS uyguladım ama bazı kullanıcılar tüm veriyi görüyor, neden?
En olası neden bu kullanıcıların çalışma alanında Yönetici, Üye veya Katkıda Bulunan rolünde olması ya da anlam modelinde yazma izni taşımasıdır. RLS yalnız Görüntüleyici düzeyindeki erişimde uygulanır. Tüketicileri Power BI uygulaması üzerinden yetkilendirin.
Raporu görmek için her çalışana Pro lisansı gerekir mi?
İçerik paylaşılan kapasitedeyse görüntüleyicilerin Pro veya PPU lisansı gerekir. İçerik Premium kapasitede veya F64 ve üzeri bir Fabric kapasitesindeyse ücretsiz lisanslı kullanıcılar görüntüleyebilir. Lisans kuralları değişebildiği için kararı Microsoft’un güncel lisanslama sayfasıyla doğrulayın.
- Teknoloji
- Power BI, SharePoint Online, Microsoft Teams, DAX, On-premises data gateway, Microsoft Fabric
- Konu
- Power BI raporlarının intranette güvenli yayını
- Seviye
- Orta
- Ön koşullar
- Power BI Desktop ile rapor geliştirme
- Power BI çalışma alanı yönetimi
- SharePoint sayfa düzenleme yetkisi
Microsoft 365 ve Intranet