POWER APPS YETKİLENDİRME MANTIĞI

Bir Power Apps uygulamasında "Bu düğmeyi sadece yönetici görsün" demek bir satırlık iş gibi durur. If(User().Email = "yonetici@firma.com", true, false). Üç ay sonra yönetici değiştiğinde uygulamayı yeniden açıp formülü güncellemek gerekir. Ya da daha kötüsü, formülü atlayan biri ağ üzerinden veri kaynağına doğrudan ulaşıp yönetici düğmesinin yapması gereken işi başka yollardan yapar. Yetkilendirme tasarımı bu basit görünümün arkasındaki gerçek karmaşıklığı yönetmektir; kullanıcı arayüzünü gizlemek ile veriyi korumak iki ayrı katmandır.

Görünürlük ve Güvenlik Aynı Şey Değildir

Power Apps'te bir kontrolün Visible özelliğini false yapmak o kontrolü ekrandan kaldırır ama veriyi korumaz. Kullanıcı uygulamanın görsel akışını kullanmadan da veriye ulaşma yolları bulabilir; başka bir uygulama, mobil API, doğrudan veri kaynağına bağlantı gibi. Gerçek güvenlik veri kaynağı seviyesinde olur, uygulama seviyesinde değil. UI gizleme bir kullanıcı deneyimi seçimidir, güvenlik kararı değildir.

Bu ayrım Power Apps geliştiren ekiplerin ilk kavraması gereken kuraldır. "Görmesin" ile "yapamasın" iki ayrı tasarım sorusudur ve iki farklı yerde çözülür. Görmemesi UI'da yapılır, yapmaması veri kaynağında yapılır.

Veri Kaynağı Güvenliği

Dataverse kullanıyorsanız güvenlik rolleri (Security Roles) yetkilendirmenin gerçek katmanıdır. Her tabloya ve her satıra hangi rollerin erişebileceği tanımlanır. Bir kullanıcı yetkili olmadığı bir tabloya hangi yolla bakarsa baksın boş kayıt görür. Dataverse'in iş birimi (Business Unit) ve takım (Team) yapısı satır düzeyinde güvenlik için kullanılır; bir satış temsilcisi sadece kendi takımının kayıtlarını görsün gibi.

SharePoint listesi kullanıyorsanız liste seviyesinde ve madde seviyesinde izinler tanımlanır. Madde seviyesi izinleri performans olarak pahalıdır ve büyük listelerde kalıcı değildir; bu yüzden SharePoint genellikle liste seviyesinde gruplama mantığıyla kullanılır. Daha karmaşık satır düzeyinde güvenlik için Dataverse'e geçmek gerekir.

SQL Server kullanıldığında veritabanı kullanıcısı seviyesinde GRANT ve REVOKE ifadeleriyle güvenlik kurulur. Power Apps SQL'e bağlanırken belirli bir hizmet hesabı kullanır; bu hesabın izinleri tüm uygulamanın izinlerini belirler. Bu yüzden hizmet hesabı uygulama için gerekli minimum yetkiye sahip olacak şekilde tanımlanır.

Azure AD Grupları ile Rol Yönetimi

Power Apps'te rol yönetimi neredeyse her zaman Azure Active Directory grupları üzerinden yapılır. Tek tek kullanıcı isimlerini koda yazmak yerine "Pazarlama Yöneticileri" gibi bir AD grubu oluşturulur, kullanıcılar bu gruba eklenir veya çıkarılır. Power Apps formülünde Office365Groups connector ile kullanıcının üye olduğu gruplar çekilir ve buna göre davranış belirlenir.

Bu yaklaşımın temel kazancı kalıcılıktir. Yeni bir yönetici işe başladığında kod değişmez; AD grubuna eklenir, uygulamaya bir sonraki girdiğinde yönetici yetkilerini otomatik alır. Eski yönetici ayrıldığında gruptan çıkarılır, yetkisi kaybolur. Bu disiplin manuel listelerle kıyaslanamaz bir hız sağlar.

Rol Bazlı Görünüm Yönetimi

Uygulama içinde rol bazlı görünüm yönetimi için yaygın desen kullanıcının rolünü uygulama açılırken bir değişkene yüklemektir. Konunun resmi ve ayrıntılı anlatımı Power Apps resmi belgelerinde bulunur. App.OnStart içinde bir kez kontrol yapılır, sonrasında her kontrolün Visible özelliği bu değişkene bakar. Bu yaklaşım her ekranda tekrar tekrar grup üyelik kontrolünden çok daha hızlıdır çünkü kontrol bir kez yapılır, sonuç değişkende saklanır.

App.OnStart içinde rol değişkenlerinin kurulumu:

// Kullanıcının üye olduğu gruplar
Set(varGruplar, Office365Groups.ListOwnedGroupsV2().value);

// Rol bayrakları
Set(rolYonetici, "Pazarlama Yoneticileri" in varGruplar.displayName);
Set(rolOnaylayan, "Onay Komitesi" in varGruplar.displayName);
Set(rolKullanici, !rolYonetici And !rolOnaylayan);

// Örnek kullanım: btnSil.Visible = rolYonetici
// Örnek kullanım: btnOnayla.Visible = rolOnaylayan

Çoklu rol senaryolarında her rol için ayrı bir değişken tanımlanır. Bir kullanıcı hem yöneticisi hem onaylayıcı olabilir. Bu durumda iki değişken birden true olur ve farklı UI öğeleri buna göre açılır. Rol kontrolleri kullanılan değişkenlerin bir konvansiyonla isimlendirilmesi okumayı kolaylaştırır:

• rolYonetici: tam yetkili kullanıcılar; silme, düzenleme, raporlama erişimi.
• rolOnaylayan: onay listesinde olan kişiler; onay/red eylemleri.
• rolKullanici: standart kullanıcı; sadece kendi kayıtlarını görür ve düzenler.
• rolMisafir: dış kullanıcı; salt okunur, kısıtlı ekranlar.

Eylem Seviyesinde Kontrol

Bir düğmenin görünür olması o düğmenin işini yapabileceği anlamına gelmez. Düğmenin OnSelect formülü de rol kontrolü içerebilir. Eğer kullanıcı yanlışlıkla bu düğmeye ulaşırsa (mesela başka bir ekrandan navigasyonla) eylem yine engellenir. Bu iki katmanlı kontrol (Visible ve OnSelect) görünmeyen ama erişilebilir kalmış kontroller için güvenlik ağı oluşturur.

Eylem yapıldıktan sonra da kayıtta kim ne zaman yaptı bilgisinin tutulması iyi pratiktir. ModifiedBy ve ModifiedOn alanları kayıtlara otomatik olarak yazılır. Bu bilgi denetim sırasında "bu kaydı kim değiştirdi" sorusunun cevabını verir.

Test Disiplini

Yetkilendirme her zaman geliştiren kişinin kendi kullanıcısıyla test edilir; geliştiren ise zaten en yetkili kişidir. Sonuç olarak yetkisiz kullanıcının uygulamayı nasıl gördüğü test edilmez ve hatalar canlıda ortaya çıkar. Bu sorunun çözümü test kullanıcıları yaratmaktır: her rol için en az bir test hesabı tanımlanır, uygulama her sürümden sonra bu hesaplarla giriş yapılarak doğrulanır.

Power Apps'in "Run As" özelliği veya tarayıcının özel mod ile farklı kullanıcı oturumu açma seçeneği bu testi kolaylaştırır. Ayrıca Power Platform yöneticisi olarak kullanıcı analitiklerine bakarak hangi rolün hangi ekranlara eriştiğini izlemek anomalileri görünür kılar.

Konuk Kullanıcılar ve Dış Erişim

Konuk kullanıcılara (B2B Guest) Power Apps erişimi vermek mümkün ama dikkatli kurulması gerekir. Konuk kullanıcının Azure AD üzerinde davet edilmesi, gerekli lisanslara sahip olması ve uygulamayla paylaşılması gerekir. Veri kaynağı bağlantıları da konuk kullanıcı izinleriyle çalışır; SharePoint listesine erişimi olmayan konuk kullanıcı uygulamanın o listeye dokunan kısmını kullanamaz. Bu üç katmanlı kontrol erişim sorunlarının kaynağını bulmayı zorlaştırır.

Dış kullanıcı erişimi yaygın olarak Portal (Power Pages) çözümüyle yapılır; Power Apps Canvas uygulamaları öncelikle kurum içi kullanıma uygundur. Müşteri portalı veya tedarikçi portalı için Power Pages mimarisi tasarlanır.

Yetki Modeli Belgelendirme

Hangi rolün hangi ekranı görebileceği, hangi düğmeye basabileceği, hangi veriye erişebileceği bir matriste yazılı olarak tutulmalıdır. Bu matris yetkilendirme tasarımının dökümünü oluşturur. Yeni geliştiriciler uygulamaya katıldığında bu matristen okur; testler bu matrise göre yapılır; denetim sırasında bu matris kanıt belgesi olur.

Power Apps yetkilendirmesi göründüğünden daha katmanlı bir konudur. UI seviyesinde gizleme yeterli değildir; gerçek güvenlik veri kaynağında ve disiplinli rol yapısında inşa edilir. Power Apps eğitimi bu mimariyi gerçek senaryolar üzerinden öğretir.