Güvenli Erişim Kontrolüyle Ortak Portal Web Uygulaması Oluşturun

Hedefleri, Kullanıcıları ve Kapsamı Tanımlayın

Bir ortak portal web uygulaması ancak net bir amacı olduğunda güvenli ve kullanımı kolay kalır. Araçları seçmeden veya ekran tasarlamaya başlamadan önce portalin aslında ne için ve kimler için olduğunu hizalayın. Bu ön çalışma izinlerin gereksiz yayılmasını, kafa karıştırıcı menüleri ve ortakların kullanmaktan kaçındığı bir portalı önler.

Portalın amacından başlayın

Portalin bir cümlelik misyonunu yazın. Yaygın hedefler şunlardır:

• Kaynak paylaşımı (fiyat tabloları, marka varlıkları, eğitim)
• Anlaşma yönetimi (leadler, fırsatlar, MDF talepleri)
• Destek taleplerinin yönetimi (durum güncellemeleri, ekler, yükseltme)
• Dosya alışverişi (sözleşmeler, uyumluluk belgeleri, faturalar)

Ortakların ekibinize e-posta atmadan neleri yapabileceği konusunda spesifik olun. Örneğin: “Ortaklar anlaşma kaydedebilir ve onaylı materyalleri indirebilir” ifadesi, “Ortaklar bizimle işbirliği yapabilir” ifadesinden daha nettir.

Ortak türlerini ve gerçek kullanıcıları belirleyin

“Ortak” tek bir kitle değildir. Desteklediğiniz ortak türlerini listeleyin (bayiler, distribütörler, ajanslar, müşteriler, tedarikçiler) ve sonra her partner organizasyon içindeki rolleri listeleyin (sahip, satış temsilcisi, finans, destek).

Bu adım, web uygulamaları için erişim kontrolü açısından önemlidir çünkü farklı ortak türleri genellikle farklı veri sınırlarına ihtiyaç duyar. Bir distribütör birden fazla alt bayiyi yönetebilir; bir tedarikçi yalnızca satır siparişlerini görebilir; bir müşteri yalnızca kendi ticketlarını görebilir.

İzleyebileceğiniz başarı metriklerini tanımlayın

Kapsam kararlarının somut kalması için birkaç ölçülebilir çıktı seçin:

• Yeni bir partner organizasyonunun onboard olma süresi
• Aylık erişim sorunları sayısı (kilitlenen kullanıcılar, yanlış izinler)
• Self-servis ile çözülen taleplerin payı (vs iç destek)

Hedefiniz “daha hızlı self-servis” ise, davetler, parola sıfırlama, ticket oluşturma, indirmeler gibi bunu mümkün kılan iş akışlarını planlayın.

Self-serve ile sadece iç kontrol arasındaki çizgiyi belirleyin

Ortakların portalda neler yapabileceği ile iç ekibinizin admin konsolunda neyi kontrol edeceği arasında bir çizgi çizin. Örneğin, ortaklar ekip arkadaşlarını davet edebilir ama hassas programlara erişim iç ekibiniz tarafından onaylanabilir.

Kısıtlamaları erken belgeleyin

Zaman çizelgenizi, bütçenizi, uyumluluk gereksinimlerinizi ve mevcut teknoloji yığını (SSO ve MFA için IdP, CRM, ticketing) yakalayın. Bu kısıtlamalar veri modelini, çok kiracılı ortak yönetimini, RBAC yetkilendirme karmaşıklığını ve entegrasyon seçeneklerini şekillendirecektir.

Roller ve İzin Gereksinimlerini Tasarlayın

Bir auth sağlayıcı seçmeden veya ekranlar geliştirmeye başlamadan önce kimin erişmesi gerektiğini ve ne yapmaları gerektiğini netleştirin. Basit, iyi belgelenmiş bir izin planı ileride “sadece admin verin” kararlarını engeller.

Temel rollerinizi eşleştirmekle başlayın

Çoğu ortak portal, organizasyonlar arasında tekrarlanan küçük bir rol seti ile çalışır:

• Internal admins: ortakları yapılandıran, erişimi gideren ve raporları çalıştıran çalışanlarınız.
• Partner admins: kendi ekiplerini ve ayarlarını yöneten partnerin güvenilir kullanıcıları.
• Partner users: günlük kayıtlar, talepler veya görevler üzerinde çalışan kullanıcılar.
• Read-only viewers: veriyi görebilen ama değiştiremeyen yöneticiler, denetçiler veya arada sırada giren kullanıcılar.

İlk sürümü bu rollerle sınırlı tutun. Gerçek ihtiyaçları doğrulayınca sonra genişletebilirsiniz (ör. “Fatura Yöneticisi”).

Eylemleri düz dilde listeleyin (sonra izinlere eşleyin)

Sık yapılan eylemleri UI ve API ile eşleşen fiiller olarak yazın:

• Ortak verisini görüntüleme (panolar, kayıtlar, dosyalar)
• Kayıt oluştur/düzenle
• Veri dışa aktar
• Talepleri onayla/red et
• Kullanıcıları yönet (davet et, devre dışı bırak, MFA sıfırla)
• Organizasyon ayarlarını güncelle

Bu liste izin envanteriniz olur. Her buton ve API uç noktası bu eylemlerden biriyle uyumlu olmalı.

Bir izin modeli seçin: önce roller, sonra ince taneli erişim

Çoğu ekip için başlangıç noktası olarak Rol Tabanlı Erişim Kontrolü (RBAC) en uygunudur: her kullanıcıya bir rol atayın ve her rol bir dizi izin verir.

İstisnalar bekliyorsanız (örn. “Alice yalnızca Proje X için dışa aktarabilir”), ikinci aşamada ince taneli izinler planlayın (genellikle ABAC ya da özel geçersiz kılmalar). Anahtar nokta, gerçekten esneklik gerektiğini görmeden karmaşık kurallar inşa etmemektir.

En az ayrıcalık ve güvenli yükseltmeyi varsayarak ilerleyin

Varsayılan olarak en güvenli seçeneği yapın:

• Yeni kullanıcılar Partner user veya Read-only ile başlamalı.
• “Kullanıcı yönet” ve “Dışa aktar” yetkilerini güvenilir rollere sınırlayın.
• Rol yükseltmeleri için açık onay veya iç iş akışı gerektirin (ilk etapta elle bile olsa).

Örnek izin matrisleri (tipik senaryolar)

Aşağıda gereksinim inceleme sırasında uyarlayabileceğiniz hafif bir matris var:

Bu kararları bir sayfada belgeleyin ve versiyonlayın. Uygulamayı yönlendirecek ve onboarding ile erişim incelemeleri sırasında kafa karışıklığını azaltacaktır.

Ortakları, Tenantı ve Veri Sınırlarını Modelleyin

Ekranları veya izin matrislerini tasarlamadan önce veri modelinizde “ortak”ın ne olduğunu kararlaştırın. Bu seçim her şeyi etkiler: onboarding akışları, raporlama, entegrasyonlar ve verinin ne kadar güvenli izole edildiği.

Ortak kapsayıcınızı seçin

Çoğu ortak portal net bir şekilde şu kapsayıcılardan birine uyar:

• Organization (Partner Org): ortakların çok sayıda kullanıcısı, paylaşılan kaynakları ve açık bir tüzel kişiliği varsa en uygun olan.
• Workspace/Account: ortakların birden çok proje veya ortamda işbirliği yapması gerektiğinde uygun.
• Tenant: default olarak sıkı ayrım gerektiğinde en uygun (B2B SaaS’ta yaygın).

Bir birincil kapsayıcı seçin ve adlandırma ve API’lerde ona sadık kalın. Daha sonra alt hesapları destekleyebilirsiniz, ama bir ana parent olması erişim kurallarını anlaşılır tutar.

İzolasyon kurallarını önceden tanımlayın

Aşağıdakileri yazılı hale getirin:

• Kesin ayrılmış (ör. partner belgeleri, ticketlar, faturalar)
• Paylaşılan (ör. ürün şablonları, herkese açık bilgi bankası makaleleri)
• Koşullu paylaşılan (ör. yalnızca belirli partner seviyelerine görünen kıyaslama raporları)

Ardından ayrımı veri katmanında zorlayın (kayıtlarda tenant/org ID’leri, kapsamlı sorgular), yalnızca UI’da değil.

Neredeyse her zaman gereken temel varlıklar

Pratik başlangıç seti:

• User (giriş yapan kişi)
• PartnerOrg/Tenant (kapsayıcı)
• Membership (User ↔ PartnerOrg ilişkisi, rol ve durum bilgisi tutar)
• Role (partner admin, faturalama, salt-okuma vb.)
• Resource (projeler, vakalar, dosyalar—ortakların eriştiği şeyler)

İzinleri Membership üzerinde saklamak (User üzerinde değil) bir kullanıcının güvenle birden fazla partner orga ait olmasını sağlar.

Gerçek dünya köşe durumlarını ele alın

Şunları planlayın:

• Bir kullanıcının birden fazla partner orgda olması: açık org değişimi gerektirin ve aktif orgu net gösterin.
• Birleşmeler veya yeniden yapılanmalar: kaynakları orglar arasında taşımayı destekleyin ve bir denetim izi tutun.
• Offboarding: üyelikleri devre dışı bırakın, sahipliği devredin ve veri saklama kurallarını belirleyin.

Adlandırma kuralları ve stabil ID’ler

Org, kullanıcı ve membership için stabil, opak ID’ler (UUID vb.) kullanın. İnsan okunabilir slug’ları opsiyonel ve değiştirilebilir tutun. Stabil ID’ler, isimler, e-postalar veya domainler değişse bile entegrasyonları güvenilir ve denetim günlüklerini net tutar.

Kimlik Doğrulamayı Seçin: Parola, SSO ve MFA

Kimlik doğrulama, kullanılabilirlik ile güvenliğin kesiştiği yerdir. Bir ortak portalında, partnerler küçük tedarikçilerden kurumsal müşterilere kadar değiştiği için genellikle birden fazla oturum açma yöntemi desteklenir.

Oturum açma seçeneklerini karşılaştırın

E-posta + parola en evrensel seçenektir. Tanıdıktır, her partner için çalışır ve uygulaması kolaydır—ancak iyi parola hijyeni ve sağlam bir kurtarma akışı gerektirir.

Magic linkler parola sorunlarını ve destek taleplerini azaltır. Seyrek kullanıcılar için iyidir, fakat paylaşılan cihazlar veya katı oturum kontrolleri gereken ekipleri sinirlendirebilir.

OAuth (Google/Microsoft ile oturum açma) KOBİ partnerler için iyi bir ara seçenektir. Zayıf parolalara göre güvenliği iyileştirir ve sürtünmeyi azaltır, ama her şirket tüketici OAuth’una izin vermez.

SAML SSO kurumsal gereksinimdir. Büyük partnerlere satıyorsanız SAML’i erken planlayın—uygulamadan sonra geri eklemek kullanıcı kimliğini, rolleri ve onboarding’i etkileyebilir.

MFA'nin nereye uyduğuna karar verin

Yaygın bir politika:

• Internal admins için zorunlu MFA (en yüksek etki hesapları)
• Partner kullanıcılar için isteğe bağlı MFA (hassas eylemler için tetikleyici)
• Riskli olaylar için step-up kimlik doğrulama: banka bilgisi değiştirme, veri dışa aktarma, fatura görüntüleme, kullanıcı ekleme veya erişim değiştirme

Parola politikaları ve destek yükü olmadan kurtarma

Parola kurallarını basit tutun (uzunluk + ihlal kontrolü), sık sık zorunlu sıfırlamalardan kaçının ve kusursuz bir self-serve sıfırlama deneyimi önceliklendirin. SSO destekliyorsanız, bir IdP yanlış yapılandırıldığında erişim kurtarma için admin destekli bir yedek yol olduğundan emin olun.

Oturumlar: sona erme, cihazlar ve “beni hatırla”

Açık oturum kuralları tanımlayın: boşta kalma zaman aşımı, mutlak maksimum oturum süresi ve “beni hatırla”nın ne anlama geldiği. Özellikle adminler için oturumları iptal edebilecekleri bir cihaz listesi düşünün.

Kullanıcı yaşam döngüsü temelleri

Aktivasyon (e-posta doğrulaması), devre dışı bırakma (anında erişim kaldırma), kilitlenme (oran sınırlamaları) ve yeniden etkinleştirme (denetlenmiş, kontrollü) için plan yapın. Bu durumlar yöneticiler tarafından portal ayarlarında ve /admin konsolunda görünür olmalı.

Yetkilendirmeyi (RBAC/ABAC) Doğru Uygulayın

Yetkilendirme sorar: “Bu oturum açmış kullanıcı ne yapabilir ve hangi partner verilerine?” Erken doğru yapmak istenmeyen veri sızıntılarını, kırık partner güvenini ve sonsuz bireysel istisnaları önler.

RBAC vs ABAC seçimi (veya ikisini birleştirme)

Pratik kural: açıklık için RBAC ile başlayın, sonra gerçekten esneklik gerektiğinde ABAC ekleyin.

• RBAC: Partner Admin, Partner Member, Read-only, Internal Support gibi basit roller. Açıklaması ve denetimi kolay.
• ABAC: partner_id, bölge, takım, sözleşme seviyesi, kaynak sahibi gibi özniteliklere dayalı kurallar. “Sadece EMEA hesapları için görüntüleme” gibi senaryolar için ideal.

Birçok portal hibrit kullanır: roller geniş yetenekler verir, öznitelikler veri kapsamını daraltır.

Yetki kontrollerini merkezileştirin

İzin kontrollerini controllerlara, sayfalara ve DB sorgularına saçmayın. Onları politika sınıflarında, middleware’da veya özel bir yetkilendirme servisinde merkezileştirin ki her istek tutarlı şekilde değerlendirilsin.

Bu, yeni bir API uç noktası eklendiğinde veya UI bir butonu gizlediğinde API’nin hala eylemi engellememesini sağlar.

Sahiplik ve veri sınırlarını tanımlayın

Sahiplik kuralları konusunda açık olun:

• Kullanıcılar bir partner org'a aittir ve yalnızca aynı org sınırına sahip kaynaklara erişebilir.
• Birden fazla partneri içeren paylaşılan nesneler (ör. bir anlaşma veya ticket) için ne olacağını kararlaştırın.
• Partner org içinde kimlerin kullanıcıları, faturalamayı ve entegrasyonları yönetebileceğini belirleyin.

Yüksek riskli eylemler için ekstra koruma ekleyin

Hassas eylemler yeniden kimlik doğrulama, step-up MFA veya onay gerektirmeli. Örnekler: SSO ayarlarını değiştirme, veri dışa aktarma, banka bilgilerini değiştirme, admin rolleri verme.

API + UI için izinleri belgeleyin

Basit bir matris tutun:

• Roller/öznitelikler → API uç noktaları (neye izin var)
• Roller/öznitelikler → UI öğeleri (ne görünüyor)

Bu mühendislik, QA ve uyumluluk için ortak gerçek kaynağı olur ve ileride erişim incelemelerini kolaylaştırır.

Ortak Onboarding, Davetler ve Offboarding İnşa Edin

Onboarding, ortak ilişkilerinin ya sorunsuz başlamasını ya da sürekli destek yükü haline gelmesini belirler. İyi bir akış hız ile güvenliği dengeler (doğru kişilerin doğru erişimi alması).

Davet ve katılma akışları

Farklı partner organizasyonlarının portala özel işlem yapmadan adapte olabilmesi için birkaç davet yolu destekleyin:

• E-posta ile davet: bir yönetici e-posta girer, partner orgu seçer ve başlangıç rolü atar.
• Alan tabanlı otomatik katılım: bir partner doğrulanmış bir domaine sahipse (ör. @partner.com), bu domaine sahip kullanıcılar ilgili orga erişim isteyebilirler.
• Yönetici tarafından oluşturulan kullanıcılar: düzenlemeli partnerler için iç yöneticiler hesapları önceden oluşturur; ilk girişte parola sıfırlama veya SSO gerektirilir.

Her daveti organizasyona özgü yapın ve açık bir son kullanma tarihi ekleyin.

Yüksek riskli erişimler için onay adımları

Tüm erişimler anında verilmemelidir. Hassas izinler için isteğe bağlı onaylar ekleyin—finans sayfaları, veri dışa aktarmalar veya API anahtarı oluşturma gibi.

Pratik bir desen: kullanıcı düşük riskli varsayılan rol ile katılır, sonra yükseltilmiş erişim talep eder; bu bir partner admininin (ve isteğe bağlı olarak iç ekibinizin) onay görevini tetikler. Kim neyi ne zaman onayladı kaydı saklanmalıdır.

Destek yükünü azaltan onboarding kontrol listeleri

İlk girişten sonra basit bir kontrol listesi gösterin: profil bilgilerini tamamla, ekibi kur (meslektaşları davet et), belgeler veya destek sayfası gibi temel kaynaklara göz at (/help).

Açık, eyleme dönüştürülebilir hata durumları

Bir şey başarısız olduğunda açık olun:

• Davet süresi dolmuş ("yeni davet isteyin" seçeneği sunun)
• Yanlış organizasyon (davetin hedeflediği org adını gösterin)
• Eksik izin (gereken rolü ve nasıl talep edileceğini açıklayın)

Geçmişi kaybetmeden offboarding

Offboarding hızlı ve kesin olmalı: aktif oturumları iptal edin, org üyeliklerini kaldırın ve token/anahtarları devre dışı bırakın. Ancak denetim geçmişini koruyun ki erişim kaldırıldıktan sonra bile yapılan işlemler izlenebilir olsun.

Ortağı Dostu Bir Portal UX Oluşturun

Bir ortak portal; ortakların sık yapılan görevlerini hızlı ve emin şekilde tamamlayabildiğinde başarılı olur. En önemli 5–10 ortak eylemini (örn. anlaşma kaydetme, varlık indirme, ticket durumunu kontrol etme, fatura iletişim bilgilerini güncelleme) listeleyin. Ana sayfayı bu eylemler etrafında tasarlayın ve her birinin 1–2 tıkta ulaşılabilir olmasını sağlayın.

Ortakların düşündüğü gibi gezinme

Gezinmeyi dahaya anlaşılır kılmak için bölüm tabanlı, iç takım isimleri yerine alan odaklı net gezinme kullanın. Basit bir yapı: Deals, Assets, Tickets, Billing, Users ortakların oryantasyonunu kolaylaştırır, özellikle nadiren giriş yapıyorlarsa.

Tereddüt ettiğinizde açıklık tercih edin:

• Etiketleri açık tutun (örn. “Tickets” yerine “Destek Talepleri”)
• Yardımcı olduğunda sayaçlar gösterin (açık ticketlar, bekleyen onaylar)
• Listeler uzuyorsa arama sağlayın (deals, assets, kontaklar)

Erişimi görünür ve eyleme geçirilebilir yapın

Bir sayfa eksik izin nedeniyle sessizce başarısız olduğunda ortaklar sinirlenir. Erişim durumunu görünür yapın:

• Profil menüsünde kullanıcının mevcut rolünü ve ana izinlerini gösterin
• Bir sayfa veya eylem kısıtlıysa nedenini ve kullanılabilir alternatifleri açıklayın
• Açık bir Erişim isteği yolu sunun (basitçe bir form bile olsa yöneticiyi bilgilendirsin)

Bu, destek taleplerini azaltır ve kullanıcıların denemeye devam edip bir şey olana kadar rastgele denemesini engeller.

Tutarlılık güven oluşturur

UI durumlarını birinci sınıf özellikler olarak ele alın:

• Ne yapılacağını anlatan boş durumlar
• Dizini sabit tutan yüklenme durumları (sayfa zıplamalarını önleyin)
• Bir sonraki adımı gösteren hata mesajları
• Yıkıcı işlemler için onaylar (kullanıcı kaldırma, davet iptali)

Küçük bir stil rehberi (butonlar, tablolar, formlar, uyarılar) portal büyüdükçe tutarlılığı korur.

Erken uygulanacak erişilebilirlik temelleri

Temelleri erken karşılayın: tam klavye navigasyonu, yeterli renk kontrastı, okunaklı form etiketleri ve net odak durumları. Bu iyileştirmeler mobil kullanıcıları ve hızlı hareket eden herkesi de destekler.

Eğer bir iç yönetici alanınız varsa, UI desenlerini partner portal ile uyumlu tutun ki destek ekipleri arayüzü çevirme gereği duymasınlar.

Bir İç Yönetici Konsolu Ekleyin

Bir ortak portal, arkasındaki iç ekibin sahip olduğu araçlar kadar yönetilebilir olur. İç yönetici konsolu günlük desteği hızlı hale getirmeli, aynı zamanda yöneticilerin istemeden yetkiyi aşmasını engelleyecek sıkı sınırlar uygulamalıdır.

Dahil edilecek temel admin özellikleri

Aramaya uygun bir partner dizini ile başlayın: partner adı, tenant ID, durum, plan/seviye ve ana iletişimler. Partner profilinden yöneticiler kullanıcıları, atanmış rolleri, son girişleri ve bekleyen davetleri görebilmeli.

Kullanıcı yönetimi genellikle şunları gerektirir: kullanıcıları devre dışı/etkinleştir, davetleri yeniden gönder, kurtarma kodlarını döndür, başarısız girişlerden sonra hesapları aç. Bu eylemleri açık (onay diyalogları, gerekirse neden girilmesi) ve mümkün olduğunca geri alınabilir şekilde tasarlayın.

Taklit etme (impersonation) — güvenlik önlemleriyle

Taklit etme güçlü bir destek aracıdır ama sıkı kontrol edilmelidir. Yükseltilmiş izinler, step-up kimlik doğrulama (örn. MFA yeniden doğrulama) ve zaman sınırlı oturum gerektirin.

Taklit etme belirgin olmalı: kalıcı bir banner (“Şu kullanıcı olarak görüntülüyorsunuz…”) ve kısıtlı yetenekler (örn. fatura değişiklikleri veya rol atamaları engellensin). Ayrıca her denetim kaydında “taklit eden” ve “taklit edilen kullanıcı” bilgisi yer almalı.

Manuel işi azaltan yapılandırma sayfaları

Rol şablonları, izin paketleri ve partner düzeyinde ayarlar (izinli SSO yöntemleri, MFA gereksinimleri, IP izin listeleri, özellik bayrakları) için yapılandırma sayfaları ekleyin. Şablonlar istisnaları desteklerken erişimi standartlaştırmanıza yardımcı olur.

Operasyonel görünürlük ve sert sınırlar

Başarısız girişler, olağandışı etkinlik bayrakları (yeni ülke/cihaz, hızlı rol değişimleri) ve sistem durum sayfalarına (/status) ve runbooklara (/docs/support) bağlantılar içeren görünümler ekleyin.

Son olarak, hangi admin eylemlerinin izinli olduğunu, kimlerin bunları yapabileceğini açıkça belirleyin ve her admin eyleminin günlüklenmiş, aranabilir ve dışa aktarılabilir olmasını sağlayın.

Denetim Günlükleri, Raporlama ve Erişim İncelemeleri

Denetim günlükleri kara kutu kaydedicinizdir. Bir partner “o dosyayı ben indirmedim” dediğinde veya bir admin “bu ayarı kim değiştirdi?” diye sorduğunda, açık ve aranabilir bir iz tahmini hızlıca yanıt getirir.

Neler kaydedilmeli (ve nelere dikkat edilmeli)

“Kim ne yaptı, ne zaman ve nereden” sorusunu cevaplayan güvenlik açısından önemli olaylarla başlayın. Tipik gerekliler:

• Girişler ve başarısız giriş denemeleri (SSO olayları dahil)
• İzin, rol ve grup değişiklikleri
• Kullanıcı yaşam döngüsü eylemleri (davetler, kabul, devre dışı bırakma)
• Hassas veri eylemleri (dışa aktarmalar, toplu indirmeler, silme işlemleri)
• API anahtarı olayları (oluşturma, döndürme, kullanım, iptal)
• Yönetici konsolu eylemleri ve konfigürasyon değişiklikleri

Günlükleri faydalı ama gizliliğe duyarlı tutun. Sırları (parolalar, API tokenları) veya tam veri yüklerini kaydetmeyin. Bunun yerine kullanıcı ID, partner org ID, nesne ID gibi tanımlayıcılar ve gerekli minimal meta veriyi (zaman damgası, IP, user agent) saklayın.

Partner organizasyon ve kullanıcı bazlı denetim izleri

Çok kiracılı bir portalda denetim izleri kolay filtrelenebilir olmalı:

• Partner organizasyon bazında: destek ekiplerinin olayları diğer tenantları görmeden incelemesini sağlar
• Kullanıcı bazında: bir kişinin portal üzerindeki etkinliklerini hızlıca incelemeyi mümkün kılar

“Niçin”i görünür kılmak için aktörü (işlemi başlatan) ve hedefi (ne değişti) dahil edin. Örnek: “Admin A, Partner Org C’de Kullanıcı B’ye ‘Fatura Admini’ verdi.”

Erişim incelemeleri (izinler kendiliğinden yönetilmez)

Yükseltilmiş roller için periyodik erişim incelemeleri planlayın. Hafif bir yaklaşım çeyreklik bir kontrol listesi olabilir: kim admin ayrıcalığına sahip, kim 60–90 gündür giriş yapmamış ve hangi hesaplar eski çalışanlara ait.

Mümkünse hatırlatmaları otomatikleştirin ve onay akışı sağlayın: yöneticiler erişimi doğrular, doğrulanmayanlar süresi dolsun.

Yeni risk yaratmadan raporlama ve dışa aktarmalar

Partnerler genellikle CSV olarak raporlara ihtiyaç duyar (kullanım, faturalar, etkinlik). Dışa aktarmayı ayrıcalıklı bir eylem olarak ele alın:

• Kimlerin dışa aktarabileceğini rol bazlı kontrol edin
• Oran sınırlamaları ve dışa aktarma boyutu limitleri uygulayın
• Her dışa aktarmayı denetim günlüğünde kaydedin (kim, ne, kapsam, zaman)

Saklama, kırpma ve gizlilik kuralları

Günlükleri ve raporları ne kadar süre saklayacağınızı ve hangi alanların kırpılacağını tanımlayın. Saklama sürelerini iş ve düzenleyici ihtiyaçlarla hizalayın ve silme takvimleri uygulayın. Günlüklerde kişisel veri varsa, araştırmalar için yine de aranabilir olmak üzere hashlenmiş tanımlayıcılar veya kırpılmış alanlar kullanmayı düşünün.

Güvenlik Sertleştirme ve Gizlilik Temelleri

Güvenlik sertleştirme, yanlış yapılandırılmış bir rol, hatalı bir entegrasyon veya sızan bir token gibi dışsal hatalar olsa bile ortak portalınızı güvenli tutan küçük, tutarlı kararlardır. Gizlilik temelleri her partnerin yalnızca yetkili olduğu şeyi görmesini sağlar—sürpriz yok, kazara dışa aktarma yok.

API’larınızı varsayılan olarak güvenli hale getirin

Her uç noktayı herkese açıkmış gibi ele alın.

Girdi doğrulama ve normalizasyonu yapın (tipler, uzunluk, izin verilen değerler) ve iç bilgileri açığa çıkarmayan güvenli hatalar döndürün. Kimlik doğrulama ve kötüye kullanım için kullanıcı, IP ve token bazlı oran sınırlaması ekleyin. Cookie tabanlı oturumlarda CSRF koruması uygulayın; bearer token kullanıyorsanız token depolama ve CORS’a odaklanın.

Tenantlar arası veri sızıntılarını önleyin

Çok kiracılı portallar en sık sorgu katmanında başarısız olur.

Her yerde tenant-kapsamlı sorguları zorlayın—tercihen zorunlu bir sorgu filtresi olarak uygulanmalı. Dosya gibi nesneler için tenant+nesne izinlerine bağlı kısa ömürlü URL’ler kullanın ve doğrudan genel nesne depolama URL’lerinden kaçının.

Gizli bilgileri ve servis erişimini koruyun

Gizli bilgileri koddan ve CI loglarından uzak tutun. Yönetilen bir gizli depo veya vault kullanın, anahtarları döndürün ve kısa ömürlü kimlik bilgilerini tercih edin. Servis hesaplarına en az ayrıcalık verin (çevre başına ayrılmış hesaplar ve entegrasyon başına ayrı hesaplar) ve kullanımını denetleyin.

Tarayıcı ve taşıma güvenliği

Güvenlik başlıklarını etkinleştirin (CSP, HSTS, X-Content-Type-Options) ve güvenli çerezleri ayarlayın (HttpOnly, Secure, SameSite). CORS’u sıkı tutun: yalnızca kontrol ettiğiniz originlere izin verin ve kimlik bilgileri için joker karakter kullanmaktan kaçının.

Olay müdahalesi temelleri (ihtiyacınız olana kadar değil önce)

İzleme nerede olur, hangi olayların uyarı tetikleyeceği (auth pikleri, izin reddi artışları, dışa aktarma hacmi) ve güvenli geri alma yöntemleriniz (özellik bayrakları, dağıtım geri alma, kimlik bilgisi iptali) dokümante edin. Basit bir runbook panikten daha iyi çalışır.

Entegrasyonlar ve Veri Senkronizasyonunu Planlayın

Bir ortak portal nadiren tek başına durur. Portal, CRM, ticketing, dosya depolama, analitik ve faturalama gibi sistemlerle bütünleştiğinde çok daha faydalı olur.

Öncelikli iş akışlarıyla başlayın

En önemli partner eylemlerini listeleyin ve her birini bir sisteme eşleyin:

• Anlaşma kaydı veya hesap durumu → CRM
• Destek talepleri, SLA’lar ve vaka geçmişi → ticketing
• Eğitim içerikleri, sözleşmeler, fiyat listeleri → dosya depolama
• Kullanım metrikleri ve partner performansı → analitik
• Faturalar, abonelikler ve haklar → faturalama

Bu, entegrasyonları “her şeyi entegre et” yerine sonuç odaklı tutar.

Veriye uygun entegrasyon modelini seçin

Farklı veri farklı altyapı gerektirir:

• Gerçek zamanlı aramalar için doğrudan API çağrıları (örn. mevcut ticket durumu)
• Değişikliklere anında yanıt için webhooklar (örn. CRM fırsat aşaması güncellendi)
• Toplu güncellemeler için zamanlanmış senkronizasyon (örn. gece katalog yenilemesi)
• Yüksek hacim veya çok tüketici bekliyorsanız event streaming

Ne seçerseniz seçin, yeniden denemeler, oran limitleri, idempotentlik ve açık hata raporlaması tasarlayın ki portal sessizce uyumsuz hale gelmesin.

Kimlik ve erişim senkronizasyonunu yönetin

SSO ve MFA destekliyorsanız kullanıcıların nasıl sağlanacağını kararlaştırın. Büyük partnerler için IT ekiplerinin kullanıcıları otomatik oluşturup devre dışı bırakması ve grupları yönetmesi için SCIM düşünün. Partner rollerini RBAC modelinizle senkronize tutun ki erişim kontrolü tutarlı kalsın.

Doğru bilgi kaynağını tanımlayın

Her alan (şirket adı, seviye, hak, bölge) için tanımlayın:

• Yetkili sistem (kaynak of truth)
• Alan eşlemesi ve izin verilen değerler
• Sistemler çeliştiğinde hangi verinin üstün geleceği

Partnerlar için belgeleyin

Ortakların yaygın iş akışlarını, veri yenilenme zamanlamasını ve bir şey yanlış görünüyorsa ne yapacaklarını açıklayan hafif bir yardım merkezi dokümanı yayınlayın (örn. /help/integrations).

Test, Dağıtım ve Sürekli Bakım

Bir ortak portal yalnızca kenar durumları kadar güvenlidir. Çoğu olay eksik özellikten değil—bir rol değişikliğinden sonra bir kullanıcının fazla yetki kazanmasından, bir davetin yeniden kullanılmasından veya tenant sınırlarının tutarlı uygulanmamasından kaynaklanır.

Yetkilendirmeyi ürün özelliği gibi test edin

Birkaç mutlu yol kontrolüne güvenmeyin. Bir rol-izin matris oluşturarak bunu otomatik testlere dönüştürün.

• Rol matrisi testleri: her rol için izin verilen eylemleri ve beklenen UI görünürlüğünü doğrulayın.
• Negatif testler: yasak eylemlerin başarısız olduğunu teyit edin (doğru HTTP statüsü, hata mesajlarında veri sızıntısı yok).
• Tenant izolasyon testleri: Partner A’dan bir kullanıcının Partner B’nin verilerini listeleyemediğini, görüntüleyemediğini, dışa aktaramadığını veya güncelleyemediğini doğrulayın—tahmin edilen ID’lerle bile.

Sadece UI değil, API seviyesinde de testler dahil edin. UI butonları gizleyebilir; API’ler politikayı uygulamalıdır.

Gerçek partner iş akışları için QA senaryoları

Aşağıdaki gibi uçtan uca senaryolar ekleyin:

• Davet gönderildi → kabul edildi → kullanıcı temel rolü kazanır.
• Davet süresi dolmuş veya iptal edilmiş → tekrar kullanılamaz.
• Kullanıcı rolü değişti → erişim hemen güncellenir (önbelleğe alınmış izinler kalıcı olmamalı).
• Offboarding (devre dışı/sil) → oturumlar iptal edilir; API tokenları geçersiz kılınır.
• Aktif oturumlar sırasında izin değişiklikleri → ne olduğu doğrulanmalı (zorunlu yeniden giriş mi yoksa her istekte yeniden değerlendirme mi uygulanacak).

Dağıtım planı: değişiklikleri geri alabilen yapın

Dağıtımı güvenliğin parçası olarak ele alın. Ortamları (dev/stage/prod) tanımlayın ve konfigürasyonu ayrı tutun (özellikle SSO, MFA ve e-posta ayarları).

Kullanın:

• İleri/geri uyumlu veritabanı migrationları
• Özellik bayrakları yüksek riskli değişiklikler için (yeni izin modelleri, onboarding akışı güncellemeleri)
• Geri alma adımları dokümante edilmiş ve prova edilmiş olsun (şema değişikliklerini güvenli geri alma dahil)

Geliştirmeyi hızlandırırken bu kontrolleri açık tutmak istiyorsanız, Koder.ai gibi bir platform ekiplerin React tabanlı bir portal ve Go + PostgreSQL backend iskeletini hızlıca hazırlamasına yardımcı olabilir; sonra RBAC, onboarding akışları, denetim kaydı ve admin-konsol özelliklerini sohbet odaklı iş akışı ile yineleyebilirsiniz. Anahtar yine aynı: erişim kontrolünü bir ürün gereksinimi olarak ele alın ve testler, incelemeler ile operasyonel güvenlik tedbirleriyle doğrulayın.

Erken sorun yakalayan operasyonel kontroller

Lansman öncesi temel operasyonel izlemeleri kurun:

• Giriş, davet kabulü ve bir ana portal sayfası için uptime ve sentetik kontroller
• Auth başarısızlıkları, izin reddi artışları ve beklenmedik 5xx için hata takibi ve uyarılar
• Kilit uç noktalar için performans taban çizgileri (p95 gecikme; yavaş sorgu uyarıları)

Bakım rutini (vazgeçilemez)

Tekrarlayan görevleri zamanlayın:

• Bağımlılıkları ve frameworkleri düzenli yamalama (güvenlik güncellemelerini hızlı uygulama)
• Olağandışı erişim kalıpları için denetim günlüklerini gözden geçirme
• Partnerlerle periyodik erişim incelemeleri (aktif kullanıcıları, rolleri ve en az ayrıcalık ilkesini doğrulayın)

Eğer zaten bir iç yönetici konsolunuz varsa, bakım eylemleri (kullanıcıyı devre dışı bırak, oturumları iptal et, anahtarları döndür) orada erişilebilir olmalı ki bir olay sırasında destek engellenmesin.