Levent–Maslak Kurumsal Portal: Rol, Veri ve Entegrasyon

Kurumsal portal projeleri çoğu zaman ekran listesiyle başlar: giriş, müşteri kartı, sipariş, belge, onay ve rapor. Oysa projenin gerçek karmaşıklığı ekranlarda değil; kimin hangi kaydı hangi durumda görebildiği, hangi sistemin veriye sahip olduğu, onayın nasıl ilerlediği ve entegrasyon kesildiğinde işlemin nasıl kurtarıldığıdır. Bu kararlar yazılmadan hazırlanan demo çalışabilir görünür, fakat gerçek operasyon istisnalarında dağılır.

Bu rehber Levent ve Maslak çevresindeki kurumsal ekipleri bir proje senaryosu olarak ele alır; fiziksel ofis veya yerel başarı iddiası taşımaz. Amaç müşteri, bayi, çalışan veya iş ortağı portalını rol, nesne, durum, entegrasyon ve denetim kanıtıyla kapsamlandırmaktır.

Portal kapsamına kullanıcı ekranından değil iş sürecinden başlayın

Önce portalın çözmesi gereken iş görevlerini yazın: teklif istemek, sipariş durumu görmek, belge yüklemek, masraf onaylamak, destek talebi açmak veya performans raporu almak. Her görev için başlangıç koşulu, zorunlu veri, karar sahibi, bitiş durumu ve istisna yolu tanımlanmalıdır. Aynı görev farklı kullanıcı gruplarında farklı yetki ve onay adımlarına sahip olabilir.

“Müşteri”, “bayi” veya “çalışan” tek başına rol değildir. Kurum, sözleşme, bölge, ürün grubu, görev veya işlem tutarı gibi bağlamsal özellikler yetkiyi değiştirebilir. Bu nedenle kapsam belgesi kullanıcı tipini, eriştiği nesneyi, gerçekleştirdiği işlemi ve geçerli koşulu birlikte kaydetmelidir.

Kurumsal portalın yedi kontrol katmanı

Kumsal Ajans’ın bu içerik için geliştirdiği yedi katmanlı model, portalın arayüzden işletime kadar gerekli kontrollerini aynı kapsam üzerinde gösterir. Bir katman tanımsızsa, sonraki katmanda görülen sorun çoğu zaman yanlış yerde çözülmeye çalışılır.

1. Kimlik: Kullanıcının hangi yöntemle doğrulandığı, hesabın nasıl açıldığı ve kapatıldığı.
2. Rol: Kullanıcının hangi nesne ve işlemlere hangi koşulda erişebildiği.
3. Görev: Kullanıcıya gösterilen iş, zorunlu adımlar ve tamamlanma kanıtı.
4. Onay: Karar sırası, ayrıştırılmış sorumluluk, ret ve geri çekme davranışı.
5. Veri: Ana kaynak, alan sahipliği, doğruluk, saklama ve dışa aktarma.
6. Entegrasyon: Veri yönü, eşleştirme, tekrar deneme ve mutabakat.
7. Denetim ve kurtarma: Log, uyarı, geri alma, yedek ve olay müdahalesi.

Rol–nesne–işlem matrisini oluşturun

Rol matrisinde yalnız menü erişimi bulunmamalıdır. Müşteri kaydı, sipariş, fiyat listesi, sözleşme, belge, kullanıcı hesabı ve rapor gibi her nesne için görme, ekleme, değiştirme, onaylama, dışa aktarma ve silme işlemlerini ayrı değerlendirin. Bir bayi kendi siparişini görebilirken başka bayinin kaydına erişememeli; yönetici onay verebilirken kendi oluşturduğu işlemi onaylaması engellenebilir.

OWASP, yetkilerin en az ayrıcalıkla verilmesini, varsayılan olarak reddedilmesini ve her istekte doğrulanmasını önerir (OWASP Authorization Cheat Sheet). Arayüzde buton gizlemek veya tahmin edilmesi zor kayıt numarası kullanmak yeterli değildir; sunucu kullanıcı–nesne–işlem ilişkisini her çağrıda kontrol etmelidir.

Onay akışını açık bir durum makinesi olarak yazın

Taslak, incelemede, düzeltme istendi, onaylandı, reddedildi, iptal edildi ve tamamlandı gibi durumlar ile geçerli geçişler belgelenmelidir. Kim hangi durumda hangi işlemi yapabilir? Onaycı izinliyse vekil kimdir? Tutar veya risk yükselince ikinci onay gerekir mi? Ret gerekçesi zorunlu mu? Onay geri çekilirse entegrasyona gönderilmiş işlem nasıl ele alınır?

OWASP iş mantığı rehberi çok adımlı süreçlerin sunucuda açık durumla tutulmasını ve her geçişin mevcut duruma göre doğrulanmasını önerir (OWASP Business Logic Security). Kullanıcı arayüzünün adımları sırayla göstermesi, doğrudan istekle geçişin atlanamayacağını kanıtlamaz. Yetkisiz sıra, tekrar onay, eş zamanlı işlem ve süresi dolmuş taslak senaryoları test edilmelidir.

Veri sahipliğini entegrasyon diyagramından önce belirleyin

Müşteri adı CRM’den, limit ERP’den, sözleşme belge sisteminden, portal tercihi ise web uygulamasından gelebilir. Her alanın ana kaynağını, değiştirme yetkisini ve güncelleme yönünü yazın. Çift yönlü senkronizasyon varsayılan tercih olmamalıdır; çakışmada hangi kaydın kazanacağı açık değilse veri sessizce bozulabilir.

KVKK’nın resmi ilkeleri kişisel verilerin belirli, açık ve meşru amaçlarla; amaçla bağlantılı, sınırlı ve ölçülü işlenmesini ve gerekli süre kadar saklanmasını öngörür (KVKK temel ilkeler). Portal alanları, dış sistem eşleşmeleri, rol erişimleri, loglar ve dışa aktarmalar aynı veri envanterine bağlanmalıdır. Hukuki dayanak ve saklama kararları yetkili uzmanlarla doğrulanmalıdır.

Entegrasyon için başarı kadar başarısızlığı da kapsamlandırın

Her bağlantıda tetikleyici, veri şeması, kimlik doğrulama sorumlusu, zaman aşımı, tekrar deneme, mükerrer işlem önleme ve hata kuyruğu tanımlanmalıdır. “API mevcut” ifadesi kapasite, sürüm, ortam, kota, destek ve değişiklik yönetimini açıklamaz. Test ve canlı ortamların veri ayrımı ile gizli anahtar yönetimi de teklifin parçasıdır.

Bağlantı kesildiğinde portal işlemi beklemede mi tutacak, kullanıcıya hata mı gösterecek, yoksa manuel iş listesi mi oluşturacak? Sistem geri geldiğinde eski olayın yeni durumu ezmemesi ve aynı işlemin iki kez uygulanmaması gerekir. Günlük mutabakat raporu, iki sistem arasındaki eksik veya farklı kayıtları görünür kılabilir.

Log ve raporu aynı şey saymayın

İş raporu sipariş sayısını veya onay süresini gösterir; denetim izi ise kimin hangi kaydı ne zaman, hangi önceki ve sonraki değerle değiştirdiğini açıklamalıdır. Güvenlik logu ayrıca başarısız giriş, yetki ihlali ve şüpheli davranışları izler. Bu veri kümelerinin amacı, erişimi ve saklama süresi farklıdır.

OWASP uygulama loglarının “ne zaman, nerede, kim ve ne” bağlamını taşımasını ve logların yetkisiz erişim ya da değiştirmeye karşı korunmasını önerir (OWASP Logging Cheat Sheet). Parola, tam erişim anahtarı veya gereksiz kişisel veri loga yazılmamalıdır. Uyarı eşiği, sorumlu ekip ve müdahale süresi yayından önce belirlenmelidir.

Portal deneyimini istisnalarla test edin

Boş görev listesi, yetkisiz kayıt, süresi dolmuş bağlantı, büyük dosya, hatalı belge türü, aynı anda iki onay, bağlantı kesintisi, hesap devri ve çalışan ayrılığı gibi durumlar prototip ve kabul testinde yer almalıdır. Mobil kullanım, klavye erişimi, uzun tablolar, filtreler ve hata mesajları gerçek veri hacmiyle sınanmalıdır.

Kabul testi ekranın açılmasıyla bitmemelidir. İşlemin doğru veriyle ana sisteme ulaşması, doğru kişiye görev üretmesi, loga kaydolması, raporda görünmesi ve geri alma politikasına uyması birlikte doğrulanmalıdır.

Teklif ve devir teslim kontrol listesi

• İş görevleri, durumlar ve geçiş kuralları
• Rol–nesne–işlem–koşul yetki matrisi
• Veri sözlüğü, ana kaynaklar ve saklama kararları
• Entegrasyon sözleşmeleri, hata kuyruğu ve mutabakat
• Onay, vekalet, ret, geri çekme ve eş zamanlı işlem senaryoları
• Log, uyarı, raporlama ve destek sorumlulukları
• Kaynak kod, hesap, ortam, dokümantasyon, yedek ve veri dışa aktarma planı

Hazır ürün ile projeye özel geliştirme kararını hazır altyapı ve projeye özel web yazılım rehberiyle değerlendirebilir; uygulama kapsamını Kumsal Ajans web yazılım hizmeti üzerinden inceleyebilirsiniz.

Kurumsal portalın başarısı ekran sayısıyla değil, görevlerin doğru yetki ve veriyle tamamlanması, istisnaların izlenebilmesi ve kurumun sistemi başka bir ekibe devredebilmesiyle ölçülür.