Müşteri, çalışan ve yönetici rollerini siparişler, ekler, dışa aktarma ve yetki değişiklikleri için sınanabilir erişim kurallarına dönüştürün.
Çalışan bir giriş ekranı, müşteri hesaplarının özel kaldığını kanıtlamaz. Sunucu yalnızca oturumun varlığına bakıyorsa, kimliği doğrulanmış müşteri başka birinin siparişine ulaşabilir. Kullanıcının kim olduğunu belirledikten sonra, bu kişinin bu kayıt üzerinde bu işlemi şimdi yapıp yapamayacağını da sorgulamak gerekir. Ürün sorumlusu ve geliştirici, yetkiler düğmelere dağılmadan önce bu sorunun yanıtında anlaşmalıdır.
Rol isimlerinden önce işletme politikasını yazın
Varsayımsal bir tasarım hizmeti platformu düşünün. Müşteri, proje koordinatörü, faturalama çalışanı ve yönetici rolleri var. Müşteri kendi taleplerini okuyor ve ilgili dosyaları yüklüyor. Koordinatör kendisine atanmış projeleri takip edip taslak paylaşıyor. Faturalama çalışanı gerekli fatura bilgilerine erişiyor, ancak tasarım dosyalarını değiştirmiyor. Yönetici proje atıyor ve çalışan rollerini değiştiriyor. Bunlar her şirket için geçerli kurallar değil, bu örnek için önerilen politikadır.
İşletme, koordinatörün yalnızca ödemenin durumunu bilmesine; fatura adresini görmemesine karar verebilir. Her çalışana tam erişim vermek yerine bu ayrımı kaydedin. OWASP yetkilendirme rehberi en az ayrıcalık, varsayılan olarak reddetme ve her istekte kontrol ilkelerini önerir. Gerekçesi açıklanabilen dar yetkilerle başlayın; ihtiyaç doğrulandıkça genişletin.
Kullanıcıyı doğrudan ilgili kayda bağlayın
Bu platformda PR-204, A Şirketi içindeki Selma adlı müşteriye ait olsun. Yalnızca müşteri rolüne sahip olmak kaydı okumaya yetmez; başka bir müşteri olan Samir de aynı roldedir. Erişim, kullanıcıyla sipariş arasındaki güvenilir ilişkiye dayanmalıdır. Bu ilişkiyi yalnızca sipariş listesinde değil; ayrıntıda, dosya indirmede, mesajlarda ve PDF dışa aktarmada da denetleyin.
OWASP'ın IDOR rehberi, karmaşık kimliklerin kayıt düzeyinde yetki kontrolünün yerini alamadığını açıklar. İletişim için PR-204 gibi kısa referans, içeride rastgele kimlik kullanabilirsiniz; hiçbiri parola değildir. Sorguyu erişilebilen kayıtlarla sınırlandırın. Kullanıcı kimliğini tarayıcıdan gelen ownerId alanından değil, güvenilir oturum bağlamından alın.
Tek bir kararı somutlaştırın
Örneğimizde taslak indirmek için şu koşullar aranabilir: oturum etkin olmalı, dosya mevcut projeye bağlı olmalı, kullanıcı projenin müşterisi veya halen atanmış koordinatörü olmalı ve dosya o tarafla paylaşılabilir olarak işaretlenmeli. Ekip içi çalışma dosyası otomatik olarak müşteriye teslim edilecek dosya değildir. İlişki eksikse önce içeriği gönderip arayüzde gizlemek yerine indirmeyi durdurun.
Uygulamadan önce dört durumu ekiple değerlendirin: müşteri paylaşılan taslağı indirebilir; başka müşteri indiremez; ataması kaldırılmış koordinatör indiremez; faturalama çalışanı faturayı okur ama taslağı göremez. Bu kısa görüşme ürün anlaşmazlıklarını erkenden ortaya çıkarır. Müşteri bir meslektaşını davet etmek istiyorsa parola paylaşımını önermek veya herkesi hesap sahibi yapmak yerine üyelik kuralları tanımlayın.
Şirket sınırlarını ekranın dışına da taşıyın
Bir çalışan aynı platformda iki şirketle çalışabilir. Menüden şirket seçmek, o şirkette üyelik oluşturmaz. İsteğin güvenilir şirket bağlamı olmalı ve veri erişimi bununla sınırlandırılmalıdır. OWASP'ın çok kiracılı sistem rehberi, sayfa dışındaki önbellek ve arka plan işlerinde de yalıtımı ele alır.
Varsayımsal haftalık rapor görevi, bütün projeleri toplayıp tarayıcıya süzdürmek yerine hangi şirkete ait olduğunu kaydeder. Üretilen dosyanın erişim kuralı da belirli olmalıdır. Önbellek, A Şirketi raporunu B Şirketi çalışanına döndürmemelidir. Bu yolları veritabanı tasarımında belgeleyin; özellik eklenirken ilişkiler görünür kalsın.
İşlem kadar düzenlenebilir alanları da koruyun
Sipariş başlığını düzenleyebilmek; sahibini veya ödenmiş tutarını değiştirme yetkisi vermez. OWASP toplu alan atama rehberinde anlatıldığı gibi her işlem için açık düzenlenebilir alan listesi kullanın. Müşteri taslak açıklamasını güncelleyebilir; ödeme onayı ise farklı, yetkili bir akıştan gelir.
Oturum güvenliğini yetkilendirmeyle karıştırmayın. Mimariniz için oturum yönetimini ve CSRF korumasını inceleyin; bunlar kayıt erişim kontrolünün yerine geçmez. Çalışanın üyeliği kaldırılınca açık oturumların ve henüz başlamamış hassas görevlerin nasıl etkileneceğine karar verin. Yetki kaldırmak, yönetim ekranındaki etiketi değiştirmekten fazlasını gerektirir.
Küçük bir yetki test matrisi hazırlayın
Kontrolünüzdeki hesap ve verilerle, izin verilmiş test ortamında çalışın. İki müşteri, iki şirket, atanmış ve atanmamış çalışan oluşturun. Her hassas işlemde izin verilen ve reddedilen durumu, sonra da yetki kaldırıldıktan sonraki davranışı sınayın. Düğmenin kaybolması yeterli değildir: sunucu isteğini deneyin, yetkisiz değişiklik veya bilgi çıkışı olmadığını doğrulayın.
- Okuma: ayrıntılar, arama sonuçları, sayılar, ekler ve dışa aktarmalar.
- Yazma: içerik değişikliği, atama, silme ve onay durumları.
- Paylaşma: davet, üyelik kaldırma ve geçici indirme bağlantıları.
- Eşzamanlılık: korumalı işlem sırasında proje atamasının değişmesi.
- Hata: yetki verisi okunamadığında otomatik izin verilmemesi.
Bu senaryoları otomatik site testlerine ekleyin. Hassas yetki değişikliklerini kaydedin, ancak özel yazışmaları ve ekleri günlüklere kopyalamayın. Çalışan ayrıldığında veya proje kapsamı değiştiğinde erişimi kimin inceleyeceğini belirleyin ve bunu bakım sürecine dahil edin.
Tek yönetici rolü yeterli mi? Sorumlulukları bilinçli belirlenmiş çok küçük ekipte yeterli olabilir. Destek, faturalama ve içerik işleri ayrıldıkça belirsiz rol isimlerini çoğaltmak yerine gereken eylemleri ayırın. Her yeni iznin sahibi ve gerekçesi belli olsun. Bu liste, kullanılan çerçeve ve altyapı üzerinde yapılacak güvenlik değerlendirmesinin yerine geçmez; değerlendirmeye somut sorular taşır. Başarılı sonuç, işletmenin açıklayabildiği ve sunucunun tutarlı uyguladığı bir erişim modelidir.
Bu yazı yapay zekâ desteğiyle hazırlanmıştır; ayrıntıların doğrulanabilmesi için teknik kaynaklar eklenmiştir.