İzin matrisi tasarımı, ekranlar ve API'ları inşa etmeden önce roller, kapsamlar ve istisnaları eşleyerek yeniden çalışmayı azaltır ve erişim hatalarını önler.
İç araç, ekibinizin işi günlük olarak yürütmek için kullandığı yazılımdır. Yönetici panelleri, operasyon panoları, destek konsolları, finans inceleme ekranları ve insanların işleri onaylamasına, veriyi düzeltmesine veya müşterilere yanıt vermesine yardımcı olan küçük uygulamalar aklınıza gelsin.
Bu araçlar hassas verilere ve güçlü eylemlere dokunur. Bir destek temsilcisi bir müşteri profilini görüntülemek zorunda olabilir ama tam ödeme detaylarını asla görmemeli. Bir finans kullanıcısı faturaları dışa aktarabilir ama hesap ayarlarını değiştirmemeli. Bir operasyon lideri her ikisini de yapabilir, ama yalnızca kendi bölgesi için.
İzinler hızla karışır çünkü iç araçlar katmanlar halinde büyür. Yeni roller ortaya çıkar, eski roller bölünür ve tek seferlik istisnalar birikir: “Maria’ya iade yapma yetkisi ver”, “Müteahhitleri notlardan engelle”, “Takım liderlerine sadece 500$'a kadar onay ver.” Kurallar yalnızca insanların kafasında (veya dağınık biletlerde) yaşadığında, ekranlar ve API uç noktaları birbirinden kopar ve güvenlik açıkları ortaya çıkar.
İzin matrisi tasarımı bunu herkesin üzerinde anlaştığı tek bir harita oluşturarak çözer: kimin ne yapabileceği, hangi verilere ve hangi sınırlar altında. Bu hem UI kararları (hangi ekranlar, butonlar ve alanlar görünecek) hem de backend kararları (sunucunun gerçekten neye izin verdiği, birisi UI'yi atlamaya çalışsa bile) için doğruluk kaynağı olur.
Bu sadece geliştiriciler için değildir. İyi bir matris, ürün, operasyon ve geliştiricilerin birlikte uzlaşabileceği çalışan bir belgedir. AppMaster gibi no-code bir platformla inşa ediyorsanız da matris önemlidir: rollerin nasıl ayarlanacağını, kaynakların nasıl tanımlanacağını ve görsel ekranlar ile üretilen uç noktaların nasıl tutarlı kalacağını yönlendirir.
Basit bir matris size yardımcı olur:
İyi bir izin matrisi tasarımı ortak kelimelerle başlar. Ekibiniz bu terimleri aynı şekilde kullanırsa, ileride karışık kurallardan kaçınırsınız.
Bir rol, genellikle aynı erişime ihtiyaç duyan iş temelli bir insan grubudur. Support, Finance, Ops veya Manager gibi düşünün. Roller, birinin günlük olarak ne yaptığıyla tanımlanmalı, kıdemle değil. Bir kişi birden fazla role sahip olabilir, ama nadiren tutmaya çalışın.
Bir kaynak, koruduğunuz şeydir. İç araçlarda yaygın kaynaklar müşteriler, ticket'lar, faturalar, raporlar, entegrasyonlar ve ayarlardır. Kaynakları isimlendirirken isim (isim) kullanın. Bu, kuralları daha sonra ekranlara ve API uç noktalarına çevirirken yardımcı olur.
Bir eylem, birinin bir kaynağa ne yapabileceğidir. Fiilleri tutarlı tutun ki matris okunabilir kalsın. Tipik eylemler şunlardır:
Bir kapsam, “hangi kayıtlar?” sorusuna yanıt verir; daha fazla rol yaratmadan farklılıkları belirtir. Kapsamlar genellikle güvenli ve güvensiz erişim arasındaki farktır. Yaygın kapsamlar:
Bir istisna, normal rol ve kapsam kurallarını bozacak bir geçersiz kılmadır. İstisnalar geçici (bir vardiyayı kapsayan), kullanıcıya özgü (bir uzmanın ekstra bir eyleme ihtiyacı var) veya kayda özgü (tek bir VIP müşteri kaydı kilitli) olabilir. İstisnaları kontrol altındaki borç olarak ele alın: kim onayladı, neden var ve ne zaman sona ereceğini takip edin.
Örnek: Bir Support temsilcisi view tickets eylemini team kapsamıyla yapabilir, ama tek seferlik bir olay incelemesi için kısa süreli olarak export tickets izni verilebilir. AppMaster ile oluşturulan bir araçta bu tür bir kural, roller, kaynaklar, eylemler ve kapsamları baştan tutarlı isimlendirirseniz çok daha kolay yönetilir.
Koruduğunuz şeyin ne olduğuna önce karar verin. İç aracın alanlarını ekranlar değil kaynaklar olarak listeleyin. Bir ekranda “Orders”, “Refunds” ve “Customers” birlikte görünebilir, ama bunlar farklı risklere sahip farklı kaynaklardır.
Tek bir izni yazmadan önce eylem fiillerinizi standartlaştırın. Küçük kelime farklılıkları daha sonra kopya kurallara yol açar (edit vs update, remove vs delete, view vs read). Kısa, ortak bir set seçin ve her kaynakta buna bağlı kalın. Çoğu iç araç için basit bir set: view, create, update, delete, approve, export yeterlidir.
Kapsamlar sonraki karardır ve bunlar şirketinizin halihazırda nasıl düşündüğüyle uyuşmalı. Çok fazla kapsam matrisi okunamaz hale getirir; çok az kapsam sürekli istisna yaratır. Örgüt yapınıza uyan küçük bir set hedefleyin, örneğin:
Ayrıca “hayır” için açık bir kurala ihtiyacınız var. Ne açıkça yasaklanmış, ne de örtük reddedilmiş kararını verin. Örtük reddetme (listelenmeyen her şey reddedilir) daha güvenli ve daha basittir. Geniş erişiminiz olduğunda belirli bir eylemi engellemek için açık yasak faydalıdır; örneğin “Finance tüm faturalara erişebilir ama delete yapamaz.”
Son olarak, uyumluluk gerektiren eylemleri erken işaretleyin, ızgarada gömülmeden önce. Exportlar, silmeler, ödemeler, rollerin değiştirilmesi ve kişisel verilere erişim ekstra dikkat, kayıt ve genellikle bir onay adımı gerektirir. Örneğin, bir destek liderinin müşteri profilini güncellemesine izin verebilirsiniz, ama bir ödeme oluşturulmadan önce finans onayı gerektirebilirsiniz.
AppMaster ile inşa ediyorsanız, bu kararlar daha sonra backend uç noktalarına ve Business Process mantığına temizce eşlenir, ama matris önce net olmalı.
İnsanların yaptığı işlemlerle başlayın, planladığınız ekranlarla değil. Ekranlarla başlarsanız, bugünkü UI'ı kopyalarsınız ve gerçek kuralları kaçırırsınız (kim iadeyi onaylayabilir, bir müşteri kaydını kilitlendiğinde kim düzenleyebilir gibi).
İzin matrisi tasarımını basitçe, görevlerden erişime bir harita olarak ele alıp sonra bunu uygulamaya çevirmek gibi yapın.
İş görevlerini sade dilde listeleyin. Örnek: “Bir iade işlemi yapmak”, “Bir müşterinin e-postasını değiştirmek”, “Geçen ayın faturalarını dışa aktarmak”. Kısa ve gerçek tutun.
Görevleri kaynaklara ve eylemlere çevirin. Kaynaklar isimdir (Invoice, Ticket, Customer), eylemler fiildir (view, create, edit, approve, export). Her kaynağa bir sahibi atayın: kenar durumlarını açıklayabilecek ve “evet, bu doğru” diyebilecek tek bir kişi.
Rolleri kararlı takımlara dayalı tanımlayın. Support, Finance, Operations, Team Lead gibi gruplar kullanın. Sık değişen unvanlardan kaçının (Senior, Junior) — erişimi gerçekten değiştirmiyorlar ise.
Matrise her rolün görevleri tamamlamak için en az erişimini doldurun. Support faturaları sadece soru cevaplamak için görüntülemesi gerekiyorsa, varsayılan olarak “export” vermeyin. Daha sonra erişim ekleyebilirsiniz; ama kaldırmak alışkanlıkları bozar.
Kapsamları yalnızca önemli olduğunda ekleyin. Tek bir “edit” izni yerine “edit own”, “edit assigned” veya “edit all” gibi kapsamları not edin. Bu, 50 rol oluşturmadan kuralları net tutar.
İstisnaları matriste dağınık notlar olarak değil ayrı bir tabloda yakalayın. Her istisnanın bir gerekçe alanı (uyumluluk, dolandırıcılık riski, görev ayrımı) ve onaylayan tek bir sahibi olmalı.
Bunlar tamamlandığında, AppMaster gibi araçlar matrisi korunan uç noktalara ve yönetici ekranlarına tahmin etmeksizin çevirmeyi kolaylaştırır.
Bir izin matrisi, insanlar hızlı okuyabiliyorsa yararlıdır. Devasa bir hücre duvarına dönüşürse ekipler kullanmayı bırakır ve izinler amaçladığınızdan sapar.
Matrisi alanlara göre bölerek başlayın. Her şey için tek bir sayfa yerine iş alanı başına bir sekme kullanın: Customers, Billing, Content gibi. Çoğu rol yalnızca birkaç alanla uğraşır, bu da incelemeleri hızlandırır ve yanlışlıkla değişiklikleri azaltır.
Sekmeler arasında tutarlı kalan bir adlandırma deseni kullanın. Resource.Action.Scope gibi basit bir format her iznin ne anlama geldiğini belli eder ve aynı işe yarayan ama farklı görünen çoğaltmaları engeller. Örneğin Invoice.Approve.Department, Customer.Edit.Own gibi okunması kolay olur.
Kenar duruma geldiğinizde yeni bir rol oluşturma dürtüsüne direnin. Hücrenin yanına ne zaman uygulandığını ve ne zaman geçerli olduğunu belirten kısa bir not ekleyin. Örnek: Support faturaları sadece müşteri kimliğini doğruladıktan sonra görüntüleyebilir. Not ayrıca gerekli ekstra UI adımına işaret edebilir, rol modelini değiştirmeden.
Yüksek riskli izinleri gözden geçirme sırasında öne çıkacak şekilde işaretleyin. Bunlar iadeler, onaylar, dışa aktarımlar ve veri silmeleri gibi eylemlerdir. Hücreleri işaretleyin ve gereken ek kontrolü yazın; örneğin iki kişilik onay veya sadece yönetici onayı.
İzin matrisinin zaman içinde sürdürülebilir kalması için sürümlendirin:
Matris kararlı olduktan sonra, AppMaster gibi bir araçla ekranlar ve uç noktalar oluşturmak çok daha kolaydır çünkü her buton ve API eylemi açık bir izin adına eşlenir.
İzin matrisi tasarımı yalnızca iki yerde gerçek kurallara dönüştüğünde fayda sağlar: API'nız ve UI'nız. Her kaynağı (Tickets, Invoices, Users gibi) bir uç nokta grubu olarak ele alın. Eylemleri matris fiilleriyle hizalayın: view, create, edit, approve, export, delete.
API tarafında, her istekte izinleri zorlayın. UI kontrolleri açıklık için faydalıdır, ama güvenlik değillerdir. Gizli bir buton doğrudan bir API çağrısını durdurmaz.
Matrisi API izinlerine çevirmek için izinleri tutarlı adlandırıp eylemin gerçekleştiği sınırda ilişkilendirmek basit bir yoldur:
Aynı izin isimlerini UI'da da menüler, sayfa erişimi, butonlar ve hatta alanlar için kullanın. Örneğin, bir Support temsilcisi Ticket listesini görüp bir ticket açabilir, ama “Refund” alanı sadece invoices:approve izni varsa düzenlenebilir.
Liste ve detay erişimi konusunda dikkatli olun. Ekipler çoğu zaman “bir şeyin var olduğunu görmek” ister ama kaydın kendisini görmek istemez. Bu, liste sonuçlarına sınırlı sütunlarla izin verip detay görünümü açmayı engellemek anlamına gelebilir; yoksa hassas veri sızabilir. Bunu erken karar verin ki liste ekranı hassas veri sızdırmasın.
Son olarak, önemli eylemler için denetim (audit) kaydını eylemlerle eşleyin. Export, delete, approve, rol değişiklikleri ve veri indirmeleri gibi eylemler kim, ne, ne zaman ve hedef kayıt bilgileriyle denetlenebilir olaylar yaratmalı. AppMaster ile inşa ediyorsanız, aynı kural hem eylemi hem de onun denetim kaydını tetikleyecek şekilde uç nokta mantığına ve iş akışına yansıtılabilir.
İzin matrisini bozmanın en hızlı yolu UI'ı iş modelinin yerine koymaktır. Bir ekran birkaç şeyi gösterebilir ve aynı şey birden fazla ekranda görünebilir. Her ekranı ayrı bir kaynak gibi modellerseniz, kuralları çoğaltır, kenar durumları kaçırır ve adlandırma yerine erişim konusunda tartışırsınız.
Diğer bir tuzak rol fazlalığıdır. Ekipler yeni roller eklemeye devam eder (Support Level 1, Support Level 2, Support Manager vb.) oysa daha küçük bir rol seti ve net kapsamlar işi görebilir. “Own team”, “assigned region” veya “accounts you manage” gibi kapsamlar genellikle yeni rolden daha iyi açıklar.
Gerçek araçlarda görülen bazı hatalar:
İstisnalar özel dikkat gerektirir. Geçici durumlar için faydalıdırlar, ama sona ermelidir veya gözden geçirilmelidir. İstisnalar artıyorsa, rolleriniz veya kapsamlarınız net şekilde eşlenmemiş demektir.
Kısa bir örnek: bir destek ve finans aracıda Support müşteri profillerini görüntüleyebilir ve ticket oluşturabilir, ama Finance faturaları dışa aktarır ve iadeleri gerçekleştirir. Sayfaları yalnızca güvence altına alırsanız, Support temsilcisi yine de doğrudan bir export uç noktasını çağırabilir. İster özel kodla inşa edin ister AppMaster gibi bir platformda aracı üretin, kural sunucu tarafında yaşamalıdır, sadece UI'da değil.
İzin matrisi ancak net, uygulanabilir kurallara dönüştüğünde faydalıdır. İlk ekranınızı veya uç noktanızı oluşturmadan önce bu kontrol listesinden geçin. Bu, yeni bir rol veya kenar durum ortaya çıktığında “neredeyse güvenli” kurulumları engeller.
Varsayılan reddetme zihniyetiyle başlayın: açıkça izin verilmeyen her şey engellenir. Bu en güvenli temel olup yeni özellikler eklediğinizde beklenmedik erişimi engeller.
İzinler için tek bir doğruluk kaynağı olduğundan emin olun. İster bir belgede, veritabanında bir tabloda, ister no-code konfigürasyonunda tutun; ekipte herkes güncel kuralların nerede olduğunu bilmeli. Elektronik tablo bir şey söylüyorsa ve uygulama başka bir şey yapıyorsa, hata ile gönderirsiniz.
Kullanabileceğiniz kapsatıcı ön-yapı kontrol listesi:
Bunlardan sonra, kuralları tek bir gerçekçi senaryoyla mantık testi yapın. Örnek: “Bir destek temsilcisi bir siparişi görüntüleyip bölgesi için not ekleyebilir, ama fiyatları düzenleyemez veya iade yapamaz. Finance iadeleri gerçekleştirebilir, ama sadece bir yönetici onayından sonra ve her iade loglanır.” Bunu bir veya iki cümlede söyleyemiyorsanız, kapsamlar ve istisnalar henüz net değil demektir.
AppMaster kullanıyorsanız, bu maddeleri hem ekranlar hem de iş mantığı için gereksinim olarak ele alın. Butonlar eylemleri gizleyebilir, ama gerçekten zorlayan kurallar backend'te olmalıdır.
Orta ölçekli bir şirketi ve Support ile Finance tarafından kullanılan bir iç aracı düşünün. Aynı veritabanı Customers, Tickets, Refunds, Payouts ve küçük bir Settings alanı (şablonlar ve entegrasyonlar gibi) tutuyor. Bu tür bir uygulamada basit bir giriş kontrolü yeterli değildir.
Başlangıç için belirledikleri roller:
Pratik bir matris tasarımı önce kaynak başına eylemleri yazar, sonra kapsamlarla sıkılaştırır.
Tickets için Support Agent'lar yalnızca atandıkları kuyruktaki ticket'ları görüntüler ve durumunu günceller. Not ekleyebilirler ama ticket sahibini değiştiremezler. Support Lead'ler Support Agent'ın yaptığı her şeyi yapabilir ve ayrıca kendi bölgeleri içinde ticket'ları yeniden atayabilirler.
Refunds için Finance iadeleri oluşturup onaylayabilir, ama sadece belirlenmiş bir miktara kadar. Support iadeyi talep edebilir ama onaylayamaz. İade onayı, iade oluşturmayla ayrı bir eylemdir; bu yüzden matris içinde görünür ve yanlışlıkla verilemez.
Payouts ve Settings için araç sıkı tutulur: yalnızca Finance payout'ları görüntüler ve yalnızca Ops Admin Settings'i değiştirebilir. Support bu ekranları görmez; bu, hata ve cazibeyi azaltır.
Bir istisna ekleyin: Support Lead iki hafta boyunca başka bir bölgeyi kapsıyor. Geniş bir rol vermek yerine (Ops Admin gibi), matris geçici bir kapsam genişlemesi içerebilir (Support Lead + Bölge B, sona erme tarihiyle). Bu tek istisna roller arasında kopyalama yapmaktan daha güvenlidir.
AppMaster ile inşa ederseniz, aynı matris UI'da hangi sayfaların görüneceğini ve backend'in neye izin vereceğini yönlendirir, böylece biri Payouts veya Settings'e ulaşmak için API çağrısını tahmin edemez.
İzinler genellikle küçük, sıkıcı şekillerde başarısız olur: bir ekran bir butonu gizlemeyi unutur, bir uç nokta kontrolü atlar, bir kapsam kuralı çok geniş eşleşir. İyi bir izin matrisi, tekrarlanabilir testlere ve basit bir bakım rutinine dönüştüğünde çok daha kullanışlı olur.
Küçük bir test kullanıcı setiyle başlayın. Düzine hesap gerekmez. Her rol için bir kullanıcı ve her yaygın istisna için bir “kenar” kullanıcı oluşturun (ör. “iade onayı olan Support agent”). Bu hesapları sabit tutun ki ekip sprintten spreinte onları yeniden kullanabilsin.
Sonra matrisi test vakalarına çevirin. Her kural için bir “izinli” yol ve bir “reddedilen” yol yazın. Reddedilen yolu spesifik yapın (ne olmalı) ki insanlar göz ardı etmesin.
Aynı kuralı iki kere test edin: UI'da ve API'da. UI bir eylemi engelliyorsa ama API hala izin veriyorsa, birisi ekranı atlayabilir. AppMaster ile inşa ediyorsanız, UI mantığınızla backend uç noktalarınızın her ikisinin de kuralı zorladığını doğrulayın.
Kapsamlar gerçek veriye ihtiyaç duyar. Sahiplik, takım ve bölgeye göre farklı test kayıtları oluşturun. Başkasına ait bir ID tahmin edip ona erişemediğinizi doğrulayın.
Son olarak, hangi hassas eylemler için ne kaydedileceğine karar verin (iadeler, dışa aktarımlar, rol değişiklikleri). Kim yaptı, neyi değiştirdi, ne zaman ve nereden bilgilerini loglayın. Logları düzenli gözden geçirin ve nadir olması gereken eylemler (izin düzenlemeleri veya toplu dışa aktarımlar) için uyarı kuralları ekleyin.
İzin matrisinizi bir dosya dolabına koyup unutmayın; onu bir inşa planı olarak ele alın. Değer elde etmenin en hızlı yolu, verinin ve sürecin sahipleriyle temel konuları doğrulamaktır.
Kısa bir atölye ile başlayın (30 dakika yeterli) — her rolden bir temsilci ve kaynak sahipleri (müşteriler, faturalar, ödeme işlemleri, ticket'lar vb. sorumluları). Roller, kaynaklar, eylemler ve kapsamları gözden geçirin ve “özel durum” gibi görünenleri not edin. Eğer bir istisna sık geliyorsa, muhtemelen eksik bir kapsam vardır.
Sonra v1 matrisini taslak haline getirip kaynak sahipleriyle odaklı bir inceleme yapın. Pratik olun: “Support faturaları görüntüleyebilir mi?” “Finance müşteri detaylarını düzenleyebilir mi?” Birisi tereddüt ederse, önce kuralı basit dilde yakalayın; daha sonra resmileştirin.
v1 üzerinde anlaşmaya varıldıktan sonra, bir alanı uçtan uca inşa ederek devam edin. Veri, mantık ve UI'ı kapsayan ince bir dilim seçin (örneğin: Ticketing veya Fatura onayları). Cevap verebilmelisiniz: kim görebilir, kim değiştirebilir ve denendiğinde ne olur.
AppMaster kullanıyorsanız, matrisi ürün parçalarına eşleyin:
Basit bir örnek: iki rol ile bir “İade talebi” akışı kurun (Support oluşturur, Finance onaylar). Bu temiz çalıştığında, “Support sadece 30 dakika içinde iptal edebilir” gibi kenar durumları ekleyin.
Küçük bir iç aracı AppMaster'da deneyin; rolleri ve akışları erken doğrulayın, sonra matristen iterate edin. Amaç, 20 ekran ve bir yığın izin düzeltmesinden önce yanlış anlamaları yakalamaktır.
21 Oca 2026
8 dk
20 Oca 20268 dk
20 Oca 20268 dkÜcretsiz planla AppMaster ile denemeler yapın.
Hazır olduğunuzda uygun aboneliği seçebilirsiniz.
