POWER APPS’TE YETKİLENDİRME MANTIĞI: ROL BAZLI GÖRÜNÜRLÜK VE KONTROL

Power Apps ile hızlı uygulama geliştirmek kolay; zor olan, uygulama büyüdükçe kimin neyi görebileceğini ve hangi işlemleri yapabileceğini doğru modellemek. “Butonu gizledim, sorun çözüldü” yaklaşımı ise genellikle ilk denetimde ya da ilk yetkisiz veri güncellemede çöker. Çünkü Power Apps’te yetkilendirme, yalnızca arayüzle değil; veri kaynağı, iş akışı ve kimlik katmanlarıyla birlikte düşünülmesi gereken bir mimari karardır.

Bu makalede Power Apps’te yetkilendirme mantığını, rol bazlı görünürlük ve kontrol bakış açısıyla ele alacağız. Amacımız; kullanıcı deneyimini sade tutarken, veri güvenliğini sağlamlaştıran, bakımı kolay, denetlenebilir bir tasarım ortaya koymak. Örnekler Power Fx üzerinden gidecek; ayrıca Dataverse ve SharePoint gibi veri kaynaklarında “gerçek güvenlik” nasıl sağlanır onu da netleştireceğiz.

Eğer uygulamanızı kurumsal ölçekte yaygınlaştırmayı planlıyorsanız, hem geliştiriciler hem de karar vericiler için kritik olan şu sorunun cevabı burada: Yetkiyi UI ile mi, veri kaynağıyla mı, yoksa ikisinin dengeli bir kombinasyonuyla mı yöneteceğiz?

Power Apps’te “gizlemek” ile “yetkilendirmek” arasındaki fark

Power Apps arayüzünde bir kontrolü görünmez yapmak (Visible=false), kullanıcı deneyimi açısından faydalıdır; fakat tek başına güvenlik sağlamaz. Çünkü kullanıcı, farklı yollarla veri kaynağına erişmeye devam edebilir ya da uygulama içindeki başka bir akış üzerinden işlemi tetikleyebilir. Bu nedenle “görünürlük” bir UX katmanıdır, “yetkilendirme” ise güvenlik katmanı olmalıdır.

UI katmanı: Rol bazlı görünürlük ve etkileşim

UI tarafında hedef; yetkisiz kullanıcıların kafa karışıklığını azaltmak, yalnızca yetkili aksiyonları ön plana almak ve hatayı en başta engellemektir. Örneğin “Onayla” butonunu yalnızca yöneticilere göstermek mantıklıdır; ancak bu butonun arkasındaki veri güncellemesi de veri kaynağı seviyesinde yetkisiz çalışmamalıdır.

Veri katmanı: Gerçek güvenlik ve denetim izleri

Gerçek güvenlik; Dataverse security roles, SharePoint liste/öğe izinleri, SQL tarafında row-level security gibi mekanizmalarla uygulanır. Power Apps uygulaması “kapı” olsa da, kilit veri katmanında olmalıdır. Bu yaklaşım hem sızma senaryolarını azaltır hem de denetim ve uyumluluk gereksinimlerini destekler.

Rol modeli tasarlama: Basit rollerden yetki matrisine

Yetkilendirme tasarımına başlarken “kaç rolümüz var?” sorusu genellikle yanlış yerden başlar. Doğru başlangıç; uygulamanın kritik işlevlerini çıkarmak ve bu işlevleri hangi kullanıcı gruplarının hangi şartlarla yapabileceğini belirlemektir. Böylece rol tasarımı “unvan listesi” değil, bir yetki matrisi haline gelir.

İşlev bazlı yaklaşım: “Ne yapılabilir?”

Önce aksiyonları listeleyin: kayıt oluşturma, kayıt güncelleme, onay verme, rapor görme, hassas alanı görüntüleme, dışa aktarma, silme vb. Sonra her aksiyon için şu iki soruyu sorun: “Kim yapabilir?” ve “Hangi koşullarda yapabilir?” Bu koşullar; departman, lokasyon, sahiplik (owner), durum (status), bütçe limiti gibi iş kuralları olabilir.

Önerilen yapı: Rol + kapsam + işlem

Kurumsal senaryolarda sadece rol yetmez; kapsam (scope) kavramı gerekir. Örneğin “Satış Müdürü” rolü, sadece kendi ekibinin kayıtlarına onay verebiliyor olabilir. Bu kapsam; Dataverse owner/team temelli ya da SharePoint item-level izinleriyle temsil edilebilir. İşlem ise UI’da DisplayMode ve veri katmanında CRUD izinleriyle birleşir.

• Rol: Kullanıcının genel yetenek kümesi (örn. Yönetici, Operatör, Denetçi)
• Kapsam: Hangi kayıtlara/alanlara erişebilir (örn. kendi kayıtları, ekip kayıtları, tüm kayıtlar)
• İşlem: Ne yapabilir (örn. görüntüleme, düzenleme, onay, dışa aktarım)

Bu yaklaşım, küçük uygulamalarda bile sizi ilerideki büyümeye hazırlar. Ayrıca hem geliştirme hem test aşamalarında “hangi kullanıcı hangi akışı görmeli” sorusu netleşir.

Kimlik ve grup yönetimi: Azure AD gruplarıyla sürdürülebilir yetki

Power Apps’te kullanıcıyı e-posta ile tek tek kontrol etmek, ilk gün çalışır ama üçüncü ayda yönetilemez hale gelir. Kurumsal ölçekte en sağlıklı model; rollerin Azure AD (Entra ID) grupları üzerinden yönetilmesi ve uygulama içinde bu grupların okunmasıdır. Böylece personel değişimlerinde uygulama güncellemeden yetki devri yapılabilir.

Grup tabanlı rol eşlemesi

En pratik desen; “UygulamaRolleri” isimli bir Dataverse tablosu veya SharePoint listesi tutmak ve kullanıcıyı gruplar üzerinden rol etiketleriyle eşleştirmektir. Bu liste; rol adını, grup kimliğini ve opsiyonel kapsam bilgisini içerir. Böylece rol yönetimi konfigürasyon olur, kod değişikliği olmaktan çıkar.

Kritik not: Kullanıcı bilgisini performanslı kullanın

Uygulama açılırken kullanıcıya ait rol bilgilerini bir kez toplayıp bir koleksiyonda saklamak (ör. colRoles), ekranlar arası performansı artırır. Aynı hesaplamayı her kontrolün Visible özelliğinde tekrar tekrar yapmak uygulamayı ağırlaştırabilir. Bu nedenle rol verilerini erken yükleyin, UI formüllerini basitleştirin.

Power Fx ile rol bazlı görünürlük ve kontrol örnekleri

UI katmanında iki temel kontrol noktası vardır: görünürlük (Visible) ve etkileşim (DisplayMode). Görünürlük; kullanıcıyı doğru aksiyona yönlendirir. DisplayMode ise kontrolü pasif hale getirerek yanlışlıkla işlem yapılmasını engeller. Ancak tekrar vurgulayalım: UI kontrolü, veri katmanındaki güvenliği tamamlar; onun yerine geçmez.

Örnek 1: Buton görünürlüğü ve DisplayMode

Aşağıdaki örnekte, kullanıcının rol koleksiyonuna göre “Onayla” butonu yalnızca yetkililere görünür. Ayrıca kayıt durumu “Beklemede” değilse buton pasif olur. Bu sayede hem rol hem iş kuralı aynı noktada uygulanır.

// App.OnStart veya Screen.OnVisible içinde:
// colRoles: ["Admin","Approver","Viewer"] gibi değerler içerir.

// btnApprove.Visible
"Approver" in colRoles || "Admin" in colRoles

// btnApprove.DisplayMode
If(
  ThisItem.Status = "Beklemede" && ("Approver" in colRoles || "Admin" in colRoles),
  DisplayMode.Edit,
  DisplayMode.Disabled
)

Örnek 2: Alan düzeyi kontrol ve hassas veri maskeleme

Bazı alanları herkes görebilir, bazı alanlar sadece belirli roller için açılmalıdır. Bu durumda yalnızca kontrolü gizlemek yerine, metin içeriğini maskelemek daha güvenli bir UX sağlayabilir. Örneğin bütçe veya kimlik numarası gibi hassas bir alanı, izinsiz kullanıcı için kısmi göstermek mümkündür.

// lblSensitive.Text
If(
  "Admin" in colRoles || "Auditor" in colRoles,
  ThisItem.SensitiveValue,
  "•••••"
)

// txtSensitive.DisplayMode
If(
  "Admin" in colRoles,
  DisplayMode.Edit,
  DisplayMode.View
)

Bu tür desenler; kullanıcı deneyimini iyileştirirken veri sızıntısı riskini azaltır. Yine de hassas alanların asıl korunması veri kaynağı katmanında olmalıdır; özellikle raporlama veya dışa aktarma senaryolarında UI maskelemesi tek başına yeterli değildir.

Dataverse ve SharePoint’te güvenlik: UI ile sınırlı kalmayın

Power Apps’in en sık yanlış anlaşılan noktası şudur: Uygulamayı “güvenli” yapan, sadece formüller değil; veri kaynağı güvenliğidir. Dataverse tarafında security role, business unit, team ve field security profilleri ile kapsamlı bir model kurabilirsiniz. SharePoint tarafında ise liste izinleri, öğe bazlı izinler ve ayrı listelerle veri ayrıştırma gibi yöntemler öne çıkar.

Dataverse: Security roles + iş birimi/kapsam tasarımı

Dataverse kullanıyorsanız, rol bazlı yetkilendirme genellikle daha kontrollüdür. Bir role; tablo bazında Create/Read/Write/Delete izinleri verilir ve bu izinlerin kapsamı “User”, “Business Unit”, “Parent-Child BU” veya “Organization” olarak belirlenir. Ayrıca hassas alanlar için field security ayrı bir katman olarak eklenebilir. Bu yapı, denetim ve uyumluluk açısından güçlü bir zemindir.

SharePoint: Liste, görünüm ve öğe izinleri

SharePoint veri kaynağı kullanırken dikkat edilmesi gereken şey; izinlerin genellikle “liste” seviyesinde başlayıp gerektiğinde “öğe” seviyesine inmesidir. Öğe bazlı izinler esneklik sağlar; ancak bakım ve performans maliyetini artırabilir. Bu nedenle kayıt sayısı büyüyen uygulamalarda; farklı departmanlar için ayrı listeler veya arşivleme stratejileri gibi alternatifleri değerlendirmek gerekir.

Ayrıca SharePoint görünümleri, güvenlik aracı değildir; sadece filtreleme sağlar. Kullanıcı, başka bir yolla veriye erişebiliyorsa görünüm kısıtlaması tek başına yeterli olmaz. Bu nedenle SharePoint izinlerini, Power Apps tarafındaki rol kurgusuyla tutarlı hale getirmek kritik önem taşır.

Yetkilendirme mimarisi: Uygulama katmanları ve güvenli entegrasyon

Kurumsal uygulamalar genellikle Power Automate akışları, e-posta bildirimleri ve harici servis entegrasyonları içerir. Yetkilendirme yalnızca Power Apps ekranında değil, bu entegrasyonların içinde de düşünülmelidir. Aksi halde kullanıcı arayüzünde engellediğiniz bir işlem, bir akış üzerinden dolaylı olarak çalışabilir.

Power Automate: Bağlantı sahibi ve çalışma kimliği riski

Akışların “kim olarak” çalıştığı, yetkilendirme tasarımının en kritik noktalarından biridir. Eğer akış, bir servis hesabı veya oluşturucu bağlantısıyla çalışıyorsa, kullanıcı UI’da yetkisiz olsa bile akış üzerinden veri güncellenebilir. Bu nedenle; akış tetikleyicilerini, koşullarını ve veri güncelleme adımlarını yetki kontrolüyle güçlendirin. Uygun durumlarda “Run-only users” ve bağlantı yönetimi politikalarıyla risk azaltılabilir.

Ortak desen: Sunucu tarafı doğrulama mantığı

Power Apps’te “Patch” veya “SubmitForm” öncesi kullanıcı rolünü kontrol etmek iyi bir ilk katmandır. Ancak kritik süreçlerde, yetkinin tekrar kontrol edildiği merkezi bir doğrulama yaklaşımı daha güvenlidir. Dataverse tarafında plug-in / business rules, SharePoint tarafında akışta ek kontroller veya API katmanında kural doğrulaması gibi seçenekler; güvenliği UI bağımlılığından çıkarır.

Bu noktada yetkilendirme tasarımını eğitimle standardize etmek ekip içinde ciddi hız kazandırır. İsterseniz uygulamalarınızı kurumsal yönetişim ve güvenlik perspektifiyle ele alan Power Apps eğitimi içeriğine göz atabilirsiniz.

Test stratejisi: Rollerle senaryo testleri ve “negatif” denemeler

Yetkilendirme kurgusunun hataları çoğu zaman “mutlu senaryo” testlerinde görünmez. Asıl değer; negatif testlerde ve sınır durumlarında ortaya çıkar. Bu nedenle rol bazlı test planı hazırlamak, hem kaliteyi yükseltir hem de canlıda sürprizleri azaltır.

Minimum test seti: Kim, neyi, hangi koşulda yapamamalı?

Her rol için en az üç test türü önerilir: (1) doğru ekranda doğru kontrollerin görünmesi, (2) doğru aksiyonun doğru koşulda çalışması, (3) yetkisiz aksiyonların hiçbir şekilde çalışmaması. Üçüncü madde için, sadece UI’dan değil; filtre atlatma, kayıt URL’si, akış tetikleme gibi yolları da düşünün.

Loglama ve izlenebilirlik

Yetkilendirme ihlali girişimlerini ve kritik işlemleri izlemek; hem operasyonel güvenlik hem de denetim açısından önemlidir. Dataverse audit, Power Platform yönetim merkezi raporları ve akış çalıştırma geçmişi gibi kaynaklar, olay analizi için değerli ipuçları sunar. Ayrıca uygulama içine “işlem kaydı” tablosu eklemek, kritik süreçlerde geri izleme sağlar.

Pratik yol haritası: Kurumsal ölçekte yetkilendirme için uygulanabilir adımlar

Yetkilendirmeyi “bir kerelik ayar” olarak değil, yaşayan bir model olarak kurgulayın. Organizasyon büyüdükçe roller değişir, süreçler evrilir, yeni veri alanları eklenir. Bu nedenle sürdürülebilir bir planla ilerlemek gerekir.

1. İşlevleri çıkarın ve yetki matrisini oluşturun.
2. Rolleri Azure AD gruplarıyla yönetin; e-posta bazlı kontrollerden kaçının.
3. UI’da Visible/DisplayMode ile deneyimi sadeleştirin, ama veri güvenliğini veri katmanına taşıyın.
4. Dataverse/SharePoint izinlerini rol modeliyle tutarlı kurun; kapsam ve sahiplik kurallarını netleştirin.
5. Power Automate ve entegrasyonlarda çalışma kimliğini ve yetki kontrollerini denetleyin.
6. Negatif testleri standartlaştırın ve kritik işlemleri loglayın.

Sonuç olarak; Power Apps’te yetkilendirme, yalnızca “kim butonu görüyor” meselesi değildir. Güvenli, denetlenebilir ve ölçeklenebilir bir yapı için rol, kapsam ve işlem katmanlarını birlikte ele almak gerekir. Bu yaklaşımı benimsediğinizde, uygulamanız büyüse bile kontrol sizde kalır; kullanıcı deneyimi iyileşir ve güvenlik riskleri belirgin biçimde azalır.