Bu makalede7 bölüm
- Teknoloji
- RBAC, OIDC/SSO, OWASP ASVS
- Konu
- Portal güvenliği
- Seviye
- Orta
B2B portallarda en ciddi güvenlik riski, bir müşterinin başka bir müşterinin verisini görebilmesidir. OWASP Top 10 listesinde “bozuk erişim kontrolü” (A01) birinci sıradadır ve portallarda genellikle tam olarak bu biçimde ortaya çıkar: URL’deki sipariş numarası değiştirildiğinde başka bayinin siparişi açılır. Bu rehber kuruluş, kullanıcı ve kayıt seviyesinde yetkilendirme mimarisinin nasıl kurulacağını anlatır.
Üç katmanlı model: kuruluş, rol, kayıt
- Kuruluş (tenant) ayrımı: Her kullanıcı bir kuruluşa (bayi, müşteri, tedarikçi) bağlıdır. Sipariş, fatura, teklif gibi her kayıt da bir kuruluşa aittir. Tüm sorgular sunucu tarafında oturumdaki kuruluş kimliğiyle filtrelenir.
- Rol bazlı yetki (RBAC): Kuruluş içinde kullanıcı ne yapabilir? Yönetici, satın almacı, muhasebe, görüntüleyici gibi roller işlem izinlerini belirler.
- Kayıt veya nitelik bazlı kurallar: Gerekirse daha ince kurallar: “satın almacı yalnızca kendi açtığı siparişleri düzenleyebilir”, “belirli tutar üstü sipariş yönetici onayı ister”.
Örnek rol–izin matrisi
| İzin | Kuruluş yöneticisi | Satın almacı | Muhasebe | Görüntüleyici |
|---|---|---|---|---|
| Sipariş oluşturma | Evet | Evet | Hayır | Hayır |
| Sipariş onaylama (eşik üstü) | Evet | Hayır | Hayır | Hayır |
| Fiyat listesi görme | Evet | Evet | Evet | Hayır |
| Fatura ve cari hesap | Evet | Hayır | Evet | Hayır |
| Kullanıcı davet etme | Evet (kendi kuruluşu) | Hayır | Hayır | Hayır |
Firma tarafındaki kullanıcılar (satış temsilcisi, müşteri hizmetleri) için ayrıca “atanmış kuruluşlar” kavramı gerekir: temsilci yalnızca sorumlu olduğu bayilerin verisini görür.
Uygulamada dikkat edilecek kurallar
- Yetki kontrolü her zaman sunucuda: Arayüzde butonu gizlemek yetki değildir. Her API uç noktası, istenen kaydın oturumdaki kuruluşa ait olduğunu ve kullanıcının rolünün işleme izin verdiğini kontrol etmelidir.
- Tahmin edilebilir kimliklerden kaçının: Sıralı sipariş numaraları URL’de kullanılabilir, ancak yetki kontrolü olmadan asla tek başına yeterli değildir; mümkünse dışa açık kimliklerde UUID kullanın.
- Varsayılan ret: Yeni bir uç nokta eklendiğinde yetki tanımı yoksa erişim reddedilmelidir.
- Toplu işlemler ve dışa aktarma: Excel dışa aktarma, raporlar ve arama uç noktaları da aynı kuruluş filtresinden geçmelidir; sızıntılar çoğunlukla burada olur.
- Dosya erişimi: Fatura PDF’leri gibi dosyalar herkese açık bir klasörden değil, yetki kontrolü yapan bir uç noktadan veya süreli imzalı bağlantılarla sunulmalıdır.
Kimlik doğrulama: yerel hesap, MFA ve SSO
Küçük bayiler için e-posta ve parolalı hesaplar, çok faktörlü doğrulama (MFA) ile birlikte kullanılabilir. Büyük kurumsal müşteriler ise kendi kimlik sağlayıcılarıyla giriş yapmak ister; portalın OpenID Connect (OIDC) desteğiyle tasarlanması, kuruluş bazında SSO açılmasını kolaylaştırır. Kullanıcı müşteri şirketten ayrıldığında hesabı da müşterinin kimlik sağlayıcısında kapanır.
Denetim kaydı
Kim, hangi kuruluş adına, hangi kaydı, ne zaman görüntüledi veya değiştirdi? Giriş denemeleri, rol değişiklikleri, kullanıcı davetleri, fiyat ve sipariş değişiklikleri değiştirilemez biçimde kaydedilmelidir. Bu kayıtlar hem güvenlik olaylarının incelenmesi hem de müşterinin “bu siparişi kim verdi?” sorusunun cevabı için gereklidir.
Test etmeden canlıya almayın
Yetki testleri otomatik test paketinin parçası olmalıdır: iki farklı kuruluşa ait test kullanıcılarıyla, her uç noktada karşı kuruluşun kaydına erişim denenmeli ve reddedildiği doğrulanmalıdır. OWASP ASVS’nin erişim kontrolü bölümleri bu testler için iyi bir kontrol listesi sunar. Canlıya alma öncesinde bağımsız bir güvenlik değerlendirmesi yapılması önerilir.
Sık sorulan sorular
Rol sayısı ne kadar olmalı?
Mümkün olduğunca az. Her kuruluş içinde 3–5 rol çoğu senaryoyu karşılar; istisnalar rol yerine izin bayraklarıyla yönetilir. Rol sayısı kontrolsüz arttığında yetki gözden geçirme imkânsız hale gelir.
Bayiler kendi kullanıcılarını ekleyebilmeli mi?
Evet, kuruluş yöneticisi rolüyle ve yalnızca kendi kuruluşu için. Bu, destek yükünü azaltır; ancak eklenen kullanıcıların rolü yöneticinin rolünden yüksek olamamalı ve işlemler kaydedilmelidir.
SSO zorunlu mu?
Değil; büyük müşteriler kendi kimlik sağlayıcılarıyla (Entra ID, Okta vb.) giriş yapmak isteyebilir. Portal OIDC desteğiyle tasarlanırsa SSO sonradan kuruluş bazında açılabilir; diğerleri için MFA’lı yerel hesap kullanılır.
Bayi, müşteri veya tedarikçi portalınızın yetki modelini birlikte tasarlamak için B2B bayi ve müşteri portalları hizmetimizi inceleyebilirsiniz.
- Teknoloji
- RBAC, OIDC/SSO, OWASP ASVS
- Konu
- Portal güvenliği
- Seviye
- Orta
Kurumsal Web ve E-Ticaret
- B2B Bayi ve Müşteri PortallarıBayi, müşteri ve tedarikçiler için rol bazlı yetkili portal: özel fiyat, sipariş, doküman, servis talebi, SSO ve denetim…
- Özel Web Uygulaması ve İş Süreci YazılımıExcel ve e-posta ile yürüyen süreçleri; veri modeli, rol bazlı yetki, API, test, sürümleme ve bakım planıyla kurumsal…
- Web Uygulama Güvenliği ve WAFOWASP Top 10 odaklı geliştirme, Cloudflare WAF, rate limiting, bot yönetimi, CSP ve güvenlik başlıklarıyla web uygulamalarının saldırı…