Roller ve izinler net örneklerle açıklandı; böylece sahiplerin, yöneticilerin, personelin ve müşterilerin neleri görebileceğine karar verip veri sızıntılarını engelleyebilirsiniz.
İş yerinde bir “veri sızıntısı” genellikle sıkıcı görünür. Bir destek temsilcisi müşteri profiline bakar ve tüm ödeme geçmişini görür. Bir müşteri giriş yapar ve “Şikayet ederse %20 teklif et” gibi dahili notları ya da bir faturadaki gerçek maliyet ve kâr marjını fark eder. Kimse bir şifre çalmadı. Uygulama yanlış şeyi gösterdi.
Çoğu sızıntı kazara olur. İzinler geç eklenir, yeni bir ekran hızlıca yayınlanır veya biri test için “yeterince iyi” olan eski bir rolü kopyalar. Sonra küçük bir değişiklik, mesela bir tabloya yeni bir alan eklemek, sessizce herkesin görebildiği bir şey haline gelir.
Bu yüzden roller ve izinler uygulamanın son dakikada işaretlenen bir kutucuk değil, birinci sınıf bir parçası olmalı. Çoğu küçük işletme aynı dört rol tipine ulaşır: Owner, Manager, Staff ve Client.
Amaç basit: her kişi işini yapmak için gerekeni görmeli, başka hiçbir şeyi değil. Bu sadece beklediğiniz ekranlar değil, sahnedeki veriler için de geçerlidir.
Eğer hızlıca kod yazmadan bir platformda (ör. AppMaster) inşa ediyorsanız, bu daha da önem kazanır. Hız iyi ama aynı zamanda özel notları, fiyatlandırma kurallarını veya diğer müşterilerin kayıtlarını yanlışlıkla açığa çıkarmayı kolaylaştırır eğer erişim baştan tasarlanmamışsa.
Roller ve izinler, bir uygulama içinde kimin ne yapabileceğini belirleyen kurallardır.
Bir erişim seviyesi ise bu kuralların pratik sonucudur. İki kişi aynı “Staff” rolünde olabilir, ama biri iade onaylayabildiği için daha yüksek bir erişim seviyesine sahip olabilir.
Hataları önlemenin güvenilir bir yolu, en düşük erişimle başlamak ve yalnızca kişinin günlük işini yapması için gerekenleri eklemektir. Birisi faturaları hiç düzenlemiyorsa, onlara düzenleme hakkı vermeyin “her ihtimale karşı”. Sonradan erişim eklemek, bir veri sızıntısını geri almandan daha kolaydır.
Çoğu izin birkaç eyleme indirgenir: görüntüle, oluştur, düzenle, sil ve dışa aktarma veya onay gibi birkaç daha yüksek riskli işlem.
Kapsam farklı bir soruyu yanıtlar: “Bunları hangi kayıtlarda yapabilirler?” Bir kişi faturaları görüntüleyebilir ama sadece kendi faturalarını, herkesin faturalarını değil.
Tipik kapsam desenleri:
Bir satış temsilcisi kendi tekliflerini oluşturup görebilir ama tam müşteri listesini dışa aktaramaz. Bir satış yöneticisi tüm ekibin tekliflerini görebilir ve indirimleri onaylayabilir. Owner her şeyi görebilir ve muhasebe için raporları dışa aktarabilir.
Çoğu uygulama aynı dört insan grubuna ulaşır. Detaylar değişir ama desen aynı kalır. Net roller ve izinlerle başlarsanız, “neden bunu görüyorlar?” gibi utandırıcı durumların çoğundan kaçınırsınız.
Owners genellikle işletme genelinde tam görünürlük ister. Bu sıklıkla faturalama, güvenlik ayarları (şifre kuralları ve MFA gibi) ve kim neyi ne zaman değiştirdiğini inceleyebilecekleri denetim geçmişini içerir.
Managers tam yönetici olmadan bir ekibi yönetebilmeli. Genelde denetim (kendi departmanlarında her şeyi görme), işlemleri onaylama (indirimler, iadeler, izin onayları, içerik değişiklikleri) ve rapor okuma ihtiyaçları vardır. Personel davet etme veya şifre sıfırlama gibi sınırlı yönetim eylemlerine ihtiyaç duyabilirler, ama faturalama veya küresel güvenlik kontrollerine erişimleri olmamalıdır.
Staff günlük işleri hızlıca yapabilmeli, risk minimumda olmalı. Güvenli bir varsayılan “sadece bana atanmış olanlar”dır. Bir destek temsilcisi sadece kendi biletlerini görür, bir sevk sorumlusu sadece bugünkü rotaları görür, bir satış elemanı sadece kendi potansiyel müşterilerini görür. Dışa aktarmalar ve toplu indirmeler varsayılan olarak kapalı olmalı ve gerçekten ihtiyaç varsa açılmalıdır.
Clients yalnızca kendi verilerini görmeli, hatta birden fazla kişi aynı hesabı paylaşıyorsa bile. Onlara sınırlı işlemler verin (talep oluşturmak, faturayı ödemek, profili güncellemek) ama dahili notlar, personel yorumları ve dahili statüler gizli kalsın.
Birçok iş için işe yarayan varsayılan set:
Birçok ekip roller ve izinleri ekranlara göre ayarlar: “Staff Siparişler sayfasını açabilir, müşteriler açamaz.” Bu yardımcı olur fakat gerçek riski kaçırır. Aynı veri aramada, yorumlarda, bildirimlerde, dışa aktarmalarda ve eklerde de görünür.
Menüleriniz yerine veri alanlarınızı listeleyerek başlayın. Yüksek etki alanları genelde müşteri iletişimleri, sipariş ve teslimat durumu, faturalar ve ödeme durumu, maaşlar ve İK notları, ve dahili notlar veya analizlerdir.
Sonra her rolün her veri türüyle ne yapabileceğine karar verin: görüntüle, oluştur, düzenle, sil, onayla ve paylaş. İşte alan düzeyinde kurallar önem kazanır. Aynı nesne genellikle bir genel görünüm ve bir dahili görünüm gerektirir.
Örnek: Bir Sipariş müşteri adı, teslimat adresi, fiyat, dahili marj ve “Müşteri çok şikâyet ediyor, indirim ver” gibi dahili bir not içerebilir. Bir müşteri adresi ve durumu görmeli ama marjı veya dahili notu asla görmemeli. Bir yönetici tüm alanları görüp indirimleri onaylama yetisine sahip olabilir. Personel teslimatı gerçekleştirmek için gereken alanları görmeli ama finans detaylarını görmemelidir.
Dosyalar ve ekler ekstra dikkat ister. Sözleşmeler, kimlikler, makbuzlar ve ekran görüntüleri genellikle form alanlarından daha hassas bilgi içerir. Bunları ayrı bir izin olarak ele alın: kim yükleyebilir, kim indirebilir, kim önizleyebilir. Ayrıca eklerin üst kayıttan (ör. fatura) mı miras aldığı yoksa kendi kurallarının mı olduğu kararını verin.
Son olarak, bir listeyi görüntüleyebildiğiniz için dışa aktarmaların veya toplu işlemlerin “dahil” olduğunu varsayıp geçmeyin. Bunları açık yapın: CSV/PDF dışa aktarma, toplu ek indirme, toplu durum değişiklikleri (onayla, iptal et, iade et), toplu mesajlaşma (e-posta/SMS/Telegram) ve kayıt yeniden atama gibi yönetim eylemleri.
Küçük bir hizmet işletmesini düşünün: sahibi projeler satar, yöneticiler işleri denetler, personel işi yapar, müşteriler teklifleri onaylar ve faturaları öder. En hızlı yol, kimse ilk kez giriş yapmadan önce roller ve izinlerde anlaşmaktır.
Paradan başlayın. Fiyatlandırma, görüntülenebilir ama kar bilgisi daha sınırlı olmalı. Yaygın bir kural: personele ne kadar alınacağını gösterin ama neden o fiyatın verildiğini göstermeyin. Bir teknisyenin faturayı açıklamak için satır öğelerine ihtiyacı olabilir ama dahili marjı, tedarikçi maliyetini veya anlaşmayı kazanmak için verilen özel indirimi görmesine gerek yok.
Müşteri verileri başka bir risk alanıdır. Birçok ekip birkaç kişinin iletişim bilgilerini görmesini ister (doğru kişiyi arayabilmek için) ama düzenleme hakkını sınırlı tutmak önemlidir. Aksi takdirde fatura e-postası kişisel bir e-posta ile yanlışlıkla değiştirilir ve faturalar muhasebeye ulaşmaz.
Birçok ekip için işe yarayan basit kurulum:
Yüksek riskli eylemleri kilitleyin. Bir faturayı ödenmiş olarak işaretleme, iade etme veya ödeme yöntemini değiştirme işlemleri owner veya güvenilir bir finans rolüyle sınırlı olmalı.
Destek masası basit görünür: müşteriler mesaj atar, ekibiniz cevaplar ve biletler kapanır. Sorunlar aynı bilet görünümünün herkes için yeniden kullanıldığında başlar. Bir yanlış ayar, müşterilerin dahili notları, etiketleri veya hatta personel performans istatistiklerini görmesine neden olabilir.
Küçük bir e-ticaret işletmesindeki paylaşılan destek gelen kutusunu hayal edin. Bir bilet müşteri mesajını, sipariş detaylarını, gönderi durumunu ve “olası dolandırıcılık, kimliği doğrulayın” veya “VIP, öncelik ver” gibi dahili notları içerir. Bu dahili bağlam ekip için faydalıdır ama müşteriye asla görünmemelidir.
Duyarlı verileri güvenli tutacak temiz bir ayrım:
Müşteri kişisel verileri (PII) bir sonraki tuzaktır. Destek genellikle telefon numarası veya adres gibi bilgilere ihtiyaç duyar, ama her bilet için değil. İyi bir kural: hassas alanları sadece iş akışı gerektiğinde gösterin. Örneğin, ajan “gönderi sorunu” seçeneğini seçtikten sonra adresi gösterin ve bilet kapandığında tekrar gizleyin.
Dahili metrikleri müşteri deneyiminden ayrı tutun. “İlk yanıta kadar geçen süre”, “ajan puanı” veya “hukuka devredildi” gibi şeyler sadece personel ve yönetici görünümlerinde olmalı.
Bir depo ve saha ekibini düşünün: biri rotaları planlar, bir diğeri ürünleri toplar, sürücüler durakları tamamlar. Uygulamanız yanlış kişilere yanlış detayları gösterirse, bu sadece rahatsız edici olmaz—müşteri adreslerini, fiyatları veya dahili notları açığa çıkarabilir.
Her grubun günlük olarak neye ihtiyacı olduğunu ayırarak başlayın.
Personel (toplayıcılar ve sürücüler) genellikle sıkı, görev odaklı bir görünüm ister. Bir sürücü uygulamayı açıp sadece o güne atanmış işleri, durak sırasını, o durak için iletişim bilgilerini ve teslim talimatlarını görmeli. Tüm müşteri listesini gezme veya diğer sürücülere atanmış işleri görme yetkisi olmamalı. Vardiya devri yapılıyorsa, bir yönetici işi yeniden atamalı; geniş erişim vermeyin.
Yöneticiler daha geniş operasyonel resmi görmelidir. Tüm ekiplerin programlarını, envanter sayılarını ve şu anda nelerin yanlış gittiğini (geç teslimatlar, başarısız teslimler, hasarlı ürünler, imza eksiklikleri) görmelidirler. İstisnaları çözmek için araçlara ihtiyaç duyarlar: bir durağı yeniden atamak, bir rotayı bölmek veya envanter ayarlamasını onaylamak gibi.
Müşteriler en küçük görünümü almalı: sadece kendi teslimat durumları. ETA'yı takip edebilmeli, teslim kanıtını görebilmeli ve “dağıtıma çıktı” veya “gecikme” gibi güncellemeler alabilmeli. Diğer müşterileri, tüm günün rota haritalarını veya dahili istisna notlarını asla görmemeli.
Burada rolleri ve izinleri uygulamanın basit bir yolu, veriyi atama ve müşteri hesabına göre kapsamlamaktır. Örneğin, bir Delivery Job kaydı yalnızca (1) atanan personel tarafından, (2) yöneticiler tarafından ve (3) o siparişle ilişkili müşteri tarafından okunabilir olsun.
Kullanıcı gruplarınızı sade dille adlandırarak başlayın. “Owner”, “Manager”, “Staff” ve “Client” iyi bir başlangıçtır, ama yalnızca bunlar işinizle uyuşuyorsa. Her grup için başarıyı bir cümleyle yazın: örneğin “Yöneticiler bordro görmeden ekip görev atayıp performansı görebilmeli.”
Sonra eylemleri veri alanlarına eşleyin. Önce ekranları düşünmeyin. Hangi veriler var ve insanlar bunlarla ne yapabilir düşünün. Kağıt üzerinde basit bir tablo yeterlidir:
Sonra taslağınızı gerçek görevlerle test edin, tahminlerle değil. “Bir sipariş oluştur”, “bir bileti çöz”, “bir rapor indir” gibi yaygın akışları adım adım geçin. Eğer bir görev geniş erişim vermenizi zorluyorsa, muhtemelen eksik bir izin vardır (ör. “dışa aktarmadan toplamları görme” gibi).
Para ya da hassas değişiklikler söz konusuysa onaylar ekleyin. Personel bir faturayı taslak hazırlayabilir, ama yalnızca bir yönetici onaylayıp gönderebilmeli. Personel teslimat adreslerini düzenleyebilir, ama banka bilgilerini değiştirmek owner onayı gerektirsin.
Çoğu veri sızıntısı küçük ekiplerde hack değil, hatadır. Uygulama birine işinin gerektirdiklerinden daha fazla erişim verdiğinde olur. Roller ve izinler bir kez ayarlanıp hiç gözden geçirilmediğinde başarısız olur.
Yaygın bir desen, birine “kurulum için” tam yönetici erişimi vermektir. Acele geçer ama erişim kalır. Haftalar sonra o kişi “bir rapora yardımcı olmak” için tüm müşteri listesini dışa aktarır ve özel veriler bir tabloda oturur.
Tekrarlanan hatalar:
Yan kapılar en sinsi olanlardır. Personelin bir sözleşme ekranını görmesini engelleyebilirsiniz, ama yine de PDF'yi e-posta eki olarak göndermiş olabilirsiniz. Ya da mobil düzen masaüstünde gizlenmiş alanları gösterebilir.
Pratik bir düzeltme, dışa aktarma ve indirmeyi ayrı izinler olarak ele almak, bunları normal “görme” hakkının parçası saymamak. Bir role bir liste vermeniz gerekiyorsa, onlara filtrelenmiş bir görünüm verin, tam dışa aktarmayı değil.
Gerçek kullanıcıları davet etmeden önce birinin yanlış tıklayacağını, ekran paylaşacağını veya indirilmemesi gereken bir dosya indireceğini varsayın. Şimdi yapılacak birkaç kontrol daha sonra acılı bir temizliği önler.
Varsayılanlarla başlayın. Yeni bir kullanıcı oluşturulduğunda en düşük role otomatik konulmalı, para, dışa aktarma veya yönetici ayarlarına erişimi olmamalıdır. Birine daha fazla gerekiyorsa, bu kasıtlı bir değişiklik olsun.
Sonra müşteri deneyimini yabancı gibi test edin. Müşteriler URL'leri değiştirseler, arama yapsalar veya filtre kullansalar bile sadece kendi kayıtlarını görmelidir. Hızlı bir test: Müşteri A olarak giriş yapıp Müşteri B'yi isim, fatura numarası veya destek bileti kimliğiyle bulmaya çalışın.
Sızıntıların çoğunu yakalayan beş hızlı kontrol:
Bir “kaza testi” yapın. Bir ekip arkadaşından bir personel hesabıyla gerçek bir görev tamamlamasını isteyin, sonra aynı görevi müşteri hesabıyla deneyin. Eğer müşteri dahili fiyatlandırmayı görebiliyorsa, tam müşteri listelerini indirebiliyorsa veya iade başlatabiliyorsa, izinleriniz çok geniş demektir.
Yaygın bir istek şöyle başlar: bir müşteri portali istenir, fakat personel zaten aynı sistemi işi yürütmek için kullanıyor. Net roller ve izinler yoksa, portal dahili notları, diğer müşterilerin siparişlerini veya personel fiyatlandırma bilgilerini açığa çıkarabilir.
Bir baskı işi şirketini düşünün. Bir sipariş tekliften üretime, üretimden teslimata, ardından faturaya gider; hepsi aynı uygulamada.
Her rolün bu iş akışında görmesi gerekenler:
İki uç durum genelde modeli bozar.
İlki, bir yönetici geçici olarak başka bir ekibi devralır. Onu Owner yapmayın. Bunun yerine Team B siparişlerine 7 gün süreli bir erişim gibi zaman sınırlı bir kapsam ekleyin. Kapsam bitince erişim sona ersin.
İkincisi, bir VIP müşteri “daha fazla görünürlük” ister. Daha fazla ham veri vermek yerine daha fazla bağlam verin. Genişletilmiş bir zaman çizelgesi veya özel bir mesaj dizisi gösterin, ama “müşteri ödemeleri gecikmeli” veya “yeniden baskı bizim hatamız” gibi dahili notları sadece personele bırakın.
Sorumluluklar değişir, bu yüzden erişimi bir kez ayarlayıp unutmayın; düzenli gözden geçirin. Birinin rolü değiştiğinde, eski yetkileri biriktirmeyin. Yeni iş için gereken en küçük seti ekleyin ve artık gerekli olmayanları kaldırın.
Küçük başlayın. En önemli tek iş akışını seçin, örneğin “fatura oluştur ve ödeme al” veya “destek bileti kaydet ve cevapla”. Önce o tek akış için roller ve izinleri tanımlayın, sonra genişletin.
Kuralları tek bir basit tabloda tutun ve onu canlı bir doküman gibi yönetin: rol, ne yapabilir, ne yapamaz ve herhangi bir sınırlama (ör. “sadece kendi kayıtları” veya “sadece kendi lokasyonu”). Biri “Personel müşteri telefon numaralarını görebilir mi?” diye sorduğunda tablo saniyeler içinde cevap vermeli.
Pratik bir yayılma planı:
Eğer AppMaster (appmaster.io) üzerinde inşa ediyorsanız, rollerinizi veri modeli ve iş mantığı ile paralel planlamak faydalıdır; böylece aynı kurallar web uygulamaları, mobil uygulamalar ve API uç noktaları arasında tutarlı uygulanır.
Eğer isterseniz, bugün ilk erişim tablonuzu yazın ve bir akışta deneyin. Bu tek adım çoğu kazara veri sızıntısını önler.
Rolleri ve izinleri tanımlamaya başlamak için en basit yol nedir?Önce sakladığınız verileri listeleyerek başlayın (müşteriler, siparişler, faturalar, dahili notlar, dosyalar), sonra her birine görme, oluşturma, düzenleme, silme, onaylama ve dışa aktarma gibi hangi rollerin hangi işlemleri yapması gerektiğini belirleyin. Minimum erişimle başlayın ve günlük iş için gerçekten gerekli olanı ekleyin.
İzinler ile kapsam arasındaki fark nedir?İzinler bir kişinin hangi işlemleri yapabileceğini (ör. düzenleme, onaylama) belirler; kapsam ise bu işlemlerin hangi kayıtlara uygulandığını belirler. Örneğin, bir personel faturaları görebilir ama sadece kendine atanmış veya kendi lokasyonuna ait faturaları görür.
Gerçekten dört role (Owner, Manager, Staff, Client) ihtiyacım var mı?“Owner, Manager, Staff, Client” çoğu küçük işletme için işleri ve riskleri bölüştürdüğü için uygundur. Ekip daha karmaşıksa, herkesi yönetici yapmaktansa Finance veya Contractor gibi birkaç özel rolleri eklemek daha iyidir.
Müşteri portalında müşteriler neleri görebilmeli?Güvenli varsayılan: müşteriler yalnızca kendi kayıtlarını görüp üzerinde işlem yapabilmeli; dahili notlar, dahili durumlar, marjlar veya personel etiketleri görünmemeli. Müşteri daha fazla görünürlük isterse, ham alanları açmak yerine zaman çizelgesi gibi daha fazla bağlam gösterin.
Personelin marjı veya hassas fiyatlandırma detaylarını görmesini nasıl engellerim?“Ne kadar alınacağı” ile “neden bu fiyatın verildiği” bilgisini ayırın. Personel genellikle fatura satırlarını ve statüyü görmeli, ancak marjı, tedarikçi maliyetini, indirim geçmişini veya ödeme işlemlerini (faturayı ödemeye alma gibi) görmemelidir.
Dışa aktarmalar ve toplu indirmeler neden bu kadar büyük bir izin riski oluşturuyor?Dışa aktarmaları görüntüleme hakkının otomatik bir parçası saymayın; bunlar daha yüksek risklidir. Birisi tüm müşteri listesini veya fatura geçmişini tabloya indirdiğinde kazara ciddi veri sızıntıları olur.
Neden sadece ekranı kısıtlamak veri sızıntılarını önlemeye yetmiyor?Ekranı kısıtlamak tek başına yeterli değildir çünkü veri arama sonuçlarında, bildirimlerde, PDF'lerde, mobil düzenlerde, eklerde ve API yanıtlarında da görünebilir. Önce veri katmanını ve alan görünürlüğünü güvenli hale getirin, sonra ekranları bunun üzerine inşa edin.
Dosyalar ve ekler için izinleri nasıl yönetmeliyim?Ekler genellikle form alanlarından daha hassas bilgi içerir; bu yüzden kendi kurallarına sahip olmalıdır. Kim yükleyebilir, kim önizleyebilir, kim indirebilir ve eklerin üst kayıtla aynı erişimi mi miras aldığı yoksa ayrı izin mi gerektirdiği kararını verin.
Destek masasında müşterilerin dahili notları görmesini nasıl engellerim?Aynı biletin iki görünümünü oluşturun: müşteri için güvenli bir görünüm (dahili notlar, etiketler ve personel metrikleri yok) ve iç görünüm (tam bağlam). Ayrıca hassas müşteri alanlarını sadece iş akışı gerektiğinde gösterin, böylece ajanlar her bilette adres veya kimlik görmez.
Gerçek kullanıcıları davet etmeden önce çalıştırmam gereken hızlı izin testleri nelerdir?Her rol için demo hesaplar oluşturun ve uçtan uca gerçek görevleri çalıştırın; arama, filtreleme, ek açma ve belge oluşturma dahil kenar durumları test edin. Ayrıca “Müşteri A, Müşteri B'yi bulmaya çalışıyor” senaryosunu isim, ID ve URL ile deneyin.
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.
