Extranet Nedir? Dış Paydaş Erişimi ve Güvenlik Rehberi

Extranet, bir kurumun seçili bilgi ve iş süreçlerini müşteri, bayi, tedarikçi, yüklenici veya proje ortağı gibi kurum dışındaki yetkili kullanıcılara kontrollü biçimde açtığı dijital çalışma ortamıdır. Yalnızca dosya paylaşılan bir alan ya da internete açılmış intranet değildir. Kim hangi kaynağı görebilir, hangi işlemi yapabilir, erişim hangi koşulda sona erer ve olaylar nasıl izlenir soruları birlikte cevaplanmalıdır.

Doğru planlandığında extranet; dağınık e-posta eklerini, güncelliği belirsiz belgeleri ve kişiye bağlı onay takibini daha kontrollü bir akışa taşıyabilir. Fakat bir kullanıcı adı ve parola eklemek sistemi kendiliğinden güvenli, kolay veya verimli yapmaz. Fayda; iş süreci, erişim modeli, veri sahipliği ve işletme sorumluluğu birlikte tasarlandığında ortaya çıkar.

Extranet ile İntranet ve Müşteri Portalı Arasındaki Fark Nedir?

İntranet esas olarak kurum içi kullanıcılara yöneliktir. Extranet ise kurum dışındaki belirli kullanıcılara, yalnızca tanımlanmış kaynak ve işlemler için erişim verir. Ayrımı belirleyen “internet var mı?” sorusu değil; kullanıcının kurumla ilişkisi, erişim yetkisi ve veri sınırıdır.

Müşteri veya bayi portalı, belirli bir kullanıcı grubuna odaklanan extranet uygulaması olarak kurgulanabilir. Ancak her extranet tek bir portal ekranından oluşmaz. Kimlik yönetimi, belge deposu, sipariş sistemi, destek kaydı, raporlama ve entegrasyonlar farklı bileşenlerde çalışabilir. Portal bu bileşenleri kullanıcı için tek bir deneyimde birleştirir.

Kapsamı portal türleri açısından karşılaştırmak için portal yazılım türleri ve proje planlama rehberini kullanabilirsiniz. Bu makalenin ana görevi ise dış paydaşa verilen erişimin sınırını ve yaşam döngüsünü belirlemektir.

Extranet Hangi İşlerde Kullanılabilir?

Extranet ihtiyacı sektör adından önce tekrarlanan dış paydaş görevleriyle anlaşılır. Yaygın örnekler şunlardır:

• Bayinin güncel fiyat, stok, kampanya ve sipariş durumuna ulaşması
• Tedarikçinin teklif, belge, teslimat ve kalite kaydı girmesi
• Müşterinin sözleşme, fatura, destek talebi ve proje dosyalarını izlemesi
• Yüklenicinin yalnızca sorumlu olduğu proje belgelerine erişmesi
• Yetkili servisin cihaz, garanti, parça ve iş emri bilgilerini yönetmesi
• Dernek veya meslek kuruluşu üyesinin aidat, duyuru, belge ve başvurularını takip etmesi
• Dağıtık ekiplerin onaylı doküman ve iş akışlarında birlikte çalışması

Bu senaryoların her biri farklı veri, yetki ve entegrasyon gerektirir. Örneğin “bayi fiyatı görür” ifadesi tek başına yeterli değildir. Hangi bayi grubunun hangi fiyat listesini, hangi para biriminde, hangi tarihler arasında göreceği ve fiyatı indirip indiremeyeceği ayrıca tanımlanmalıdır.

Kumsal Ajans Dış Paydaş Erişim Kartı

Extranet kapsamını ekran listesiyle değil, gerçek erişim kararlarıyla tanımlamak için her kritik senaryo aşağıdaki yedi alanla kaydedilebilir:

Kartın amacı kullanıcıya mümkün olan en geniş erişimi vermek değil, görevin tamamlanması için gereken erişimi açıklanabilir hâle getirmektir. Aynı rol farklı şirketlerde, projelerde veya bölgelerde farklı veri sınırına sahip olabilir.

Erişim Yaşam Döngüsü Nasıl Planlanır?

Extranet güvenliği yalnızca ilk oturum açma anında kurulmaz. Davet, aktivasyon, değişiklik, periyodik inceleme ve kapatma adımları tek bir yaşam döngüsü olarak tasarlanmalıdır.

1. Daveti doğru kuruma ve kişiye bağlayın

Hesabı kimin talep ettiği, hangi kurum adına kullanacağı ve onayı kimin verdiği kaydedilmelidir. Herkese açık kayıt yerine iş modeline uygun davet veya onay akışı gerekebilir. Ortak hesaplar, işlemi gerçekleştiren kişinin belirlenmesini zorlaştırdığı için dikkatle değerlendirilmelidir.

2. Yetkiyi göreve göre verin

OWASP Yetkilendirme Rehberi, en az yetki, varsayılan olarak reddetme ve her istekte izin kontrolü ilkelerini önerir. Bu yaklaşımda bir kullanıcı sisteme giriş yaptığı için bütün kayıtlara ulaşamaz. Her kaynak ve işlem için rol, ilişki veya bağlam kontrol edilir.

3. Değişikliği gecikmeden yansıtın

Kullanıcının görevi, şirketi, bölgesi veya proje ilişkisi değiştiğinde eski izinler kendiliğinden doğru kalmaz. Değişikliği bildirecek iş sahibi, uygulayacak ekip ve hedef süre önceden belirlenmelidir.

4. Yetkileri periyodik olarak gözden geçirin

Aktif görünen ancak uzun süredir kullanılmayan hesaplar, süresi dolmuş projeler ve gereğinden genişleyen izinler raporlanabilmelidir. İnceleme sıklığı veri hassasiyetine ve iş riskine göre belirlenir; her proje için tek bir evrensel aralık yoktur.

5. Ayrılışı bir kapatma kontrol listesiyle yönetin

Sözleşme, proje veya iş ilişkisi bittiğinde hesap kapatılmalı; aktif oturumlar, API anahtarları, paylaşım bağlantıları ve temsil yetkileri de gözden geçirilmelidir. Verinin saklanması, dışa aktarılması veya silinmesi ayrı bir iş ve hukuk kararıdır; hesabı kapatmak bu kararları otomatik olarak çözmez.

Kimlik Doğrulama Neden Tek Başına Yeterli Değildir?

Kimlik doğrulama kullanıcının kim olduğunu anlamaya, yetkilendirme ise o kullanıcının belirli bir kaynakta ne yapabileceğine odaklanır. Çok faktörlü kimlik doğrulama, riskli oturumlarda ek doğrulama ve güvenli parola yönetimi yararlı kontrollerdir; ancak yanlış yetki modelini düzeltmez.

NIST SP 800-207, ağ konumunun veya cihaz sahipliğinin tek başına güven nedeni sayılmamasını; kullanıcı, varlık ve kaynak odaklı erişim kararlarını vurgular. Extranet açısından bunun pratik karşılığı, “iç ağa bağlandı, artık her şeyi görebilir” varsayımından kaçınmaktır.

Güvenlik planında en az şu başlıklar bulunmalıdır:

• Kimlik kaynağı, MFA ve hesap kurtarma süreci
• Rol, şirket, proje ve veri sahipliğine dayalı yetkilendirme
• Her istekte sunucu tarafı izin kontrolü
• Hassas indirme, dışa aktarma, onay ve yönetim işlemleri
• Oturum süresi, cihaz ve riskli erişim kuralları
• İşlem logları, uyarılar ve olay inceleme sorumluluğu
• Yedekleme, geri yükleme ve iş sürekliliği
• Zafiyet, güncelleme ve bağımlılık yönetimi

SSL/TLS aktarım sırasındaki iletişimi korumaya yardımcı olur; fakat hatalı yetkiyi, fazla geniş veri sorgusunu veya açık kalan hesabı tek başına önlemez. Bu nedenle aktarım şifrelemesini tek başına yeterli gören mutlak bir sonuç yerine katmanlı kontrol modeli kullanılmalıdır.

Veri ve Entegrasyon Sınırları Nasıl Belirlenir?

Extranet genellikle ERP, CRM, doküman yönetimi, destek sistemi, e-imza, bildirim veya ödeme altyapısıyla veri alışverişi yapar. Her entegrasyon için kaynak sistem, veri sahibi, aktarım yönü, güncelleme sıklığı, hata davranışı ve tekrar deneme kuralı yazılmalıdır.

Kullanıcının yalnızca arayüzde görmemesi, verinin teknik olarak erişilemez olduğunu kanıtlamaz. API, dışa aktarma, arama, dosya adresi ve bildirim içerikleri de aynı veri sınırına uymalıdır. Teknik teklifleri bu açıdan karşılaştırmak için web yazılım firması teknik yeterlilik kontrolünü inceleyebilirsiniz.

Kullanılabilirlik ve Erişilebilirlik Neden Kapsamın Parçasıdır?

Dış paydaşlar kurum içi eğitimlere, yönetilen cihazlara veya aynı teknik destek kanalına sahip olmayabilir. Bu nedenle sade navigasyon, açık durum mesajları, görev odaklı ana ekran, mobil kullanım, klavye erişimi ve anlaşılır hata yönetimi tasarımın başında ele alınmalıdır.

“Eğitim gerektirmez” vaadi yerine, temel görevlerin ne kadar kolay tamamlandığı test edilmelidir. Bayinin sipariş vermesi, tedarikçinin belge yüklemesi ve servis kullanıcısının iş emrini kapatması gibi gerçek senaryolar masaüstü ve mobilde denenebilir. Yardım içeriği, hata mesajı ve destek kanalı da kabul kriterine dönüştürülmelidir.

Hazır Platform mu, Özel Geliştirme mi?

Standart belge paylaşımı, basit onaylar ve sınırlı kullanıcı grupları için yapılandırılabilir hazır bir platform yeterli olabilir. Şirkete, projeye veya sözleşmeye göre değişen veri sınırları; kritik ERP/CRM entegrasyonları; farklı onay zincirleri ve özel raporlama arttıkça özel geliştirme ihtimali güçlenir.

Kararı yalnızca ilk lisans veya geliştirme bedeliyle vermeyin. Kimlik altyapısı, entegrasyon, veri taşıma, test, eğitim, destek, güncelleme, log saklama ve sistemden ayrılma maliyetlerini birlikte karşılaştırın. Hazır ve özel yaklaşımları ayrıntılı değerlendirmek için hazır altyapı ve projeye özel web yazılım rehberine bakabilirsiniz.

Extranet Teklifinde Sorulacak 12 Soru

1. Sistemi hangi dış paydaş grupları kullanacak?
2. Her grup hangi veri ve işlemlere erişecek?
3. Veri sınırı şirket, proje, bölge veya sözleşmeye göre nasıl uygulanacak?
4. Hesap talebi, kimlik doğrulama ve onay akışı nasıl işleyecek?
5. MFA hangi kullanıcı ve işlemler için zorunlu olacak?
6. Yetki değişikliği ve kullanıcı ayrılışını kim bildirecek?
7. Erişimler ne zaman ve kim tarafından gözden geçirilecek?
8. Hangi işlemler loglanacak ve kayıtları kim inceleyebilecek?
9. ERP, CRM ve belge sistemlerinde veri sahibi hangi uygulama olacak?
10. Entegrasyon kesildiğinde kullanıcı ne görecek ve veri nasıl uzlaştırılacak?
11. Mobil, erişilebilirlik, tarayıcı ve performans kabul kriterleri nelerdir?
12. Veri dışa aktarma, teknik devir, bakım ve sistemden çıkış koşulları nelerdir?

Sık Yapılan Kapsam Hataları

En yaygın hata, modül listesi hazırlayıp erişim kararlarını sonraya bırakmaktır. “Belge yönetimi” yazmak; kimin hangi belgeyi yükleyeceğini, onaylayacağını, indireceğini veya sileceğini açıklamaz. Diğer riskli yaklaşımlar şunlardır:

• Bütün dış kullanıcılara tek rol vermek
• Şirketler arası veri ayrımını yalnızca ekranda gizlemeye bırakmak
• Hesap kapatma sorumluluğunu tanımlamamak
• Ortak hesapları denetim izi olmadan kullanmak
• İndirme ve dışa aktarma işlemlerini normal görüntülemeyle aynı saymak
• Entegrasyon hatasında sessizce eski veri göstermek
• Her projeye uyan sabit bir güvenlik veya teslim süresi vaat etmek

Sonuç: Extranet Projesine Ekranlardan Değil, Erişim Kararlarından Başlayın

Extranet, kurum dışı kullanıcılara kontrolsüz bir iç sistem kapısı açmak değil; belirli görevleri, belirli kaynak ve koşullarla tamamlayabilecekleri yönetilebilir bir çalışma alanı kurmaktır. Başarılı bir kapsam; paydaşı, kaynağı, işlemi, koşulu, süreyi, sahibi ve kanıtı birlikte tanımlar.

İlk adım olarak en kritik üç dış paydaş görevini seçin ve her biri için Dış Paydaş Erişim Kartını doldurun. Bu çalışma, hazır platform ile özel geliştirme kararını, entegrasyon kapsamını ve teklif karşılaştırmasını somutlaştırır. Kumsal Ajans ile rol, veri, entegrasyon ve işletme kapsamını değerlendirmek için web yazılım hizmetimizi inceleyebilirsiniz.