ERETEK
BİLGİ SİSTEMLERİ

B2B Portalda Yetkilendirme Mimarisi

B2B portalda yetkilendirme mimarisi: kuruluş ve kullanıcı seviyesinde rol, kayıt bazlı veri ayrımı, SSO, API güvenliği ve denetim kayıtları.

Bu makalede7 bölüm
Teknik özet
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

  1. 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.
  2. 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.
  3. 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.

Teknik özet
Teknoloji
RBAC, OIDC/SSO, OWASP ASVS
Konu
Portal güvenliği
Seviye
Orta
Eretek uzman desteği

Bu konuyu projeniz için birlikte değerlendirelim.

Mevcut yapınızı inceleyip ihtiyacınıza uygun, sürdürülebilir bir çözüm planı öneriyoruz.