On-Premise Projelerinde Veri Nerede Durmalı?

On-premise bir projede veri mimarisi yalnızca sunucunun fiziksel olarak nerede duracağıyla ilgili değildir. Asıl karar; verinin hangi sistemde üretileceği, nerede işleneceği, hangi katmanda saklanacağı, kimlerin erişeceği ve hangi risklere karşı korunacağı üzerinden verilmelidir. Yanlış konumlandırılmış veri; performans sorunları, yetki karmaşası, yedekleme açıkları ve denetimlerde açıklanması zor güvenlik boşlukları yaratabilir.

Verinin yeri neden stratejik bir karardır?

Kurumsal projelerde veri genellikle uygulama sunucusu, veritabanı sunucusu, dosya sistemi, yedekleme alanı, arşiv deposu ve entegrasyon katmanları arasında dağılır. Bu dağılım planlı yapılmadığında ekipler kısa vadede çalışan ancak uzun vadede yönetilmesi zor bir yapı kurar.

On-premise veri konumlandırma kararı; güvenlik, performans, mevzuat uyumu, felaket kurtarma ve operasyon maliyetiyle doğrudan ilişkilidir. Bu nedenle karar, yalnızca sistem yöneticisinin veya yazılım ekibinin teknik tercihi olarak görülmemeli; iş birimleri, bilgi güvenliği ve operasyon ekipleriyle birlikte değerlendirilmelidir.

Uygulama verisi ile dosya verisini ayırın

En sık yapılan hatalardan biri, uygulamanın ürettiği tüm verileri aynı yerde tutmaktır. Oysa işlem verisi, kullanıcı dosyaları, log kayıtları, rapor çıktıları ve geçici dosyalar farklı yaşam döngülerine sahiptir.

• İşlem verisi: Genellikle ilişkisel veya uygun bir veritabanında tutulmalı, bütünlük ve tutarlılık öncelikli olmalıdır.
• Dosya verisi: Belgeler, görseller, sözleşmeler veya ekler için merkezi dosya depolama alanı tercih edilmelidir.
• Log verisi: Uygulama sunucusunda dağınık bırakılmamalı, merkezi log yönetimiyle izlenebilir hale getirilmelidir.
• Geçici veri: Kalıcı veri gibi yedeklenmemeli; süre, boyut ve temizleme politikası net tanımlanmalıdır.

Bu ayrım, hem performansı iyileştirir hem de veri yedekleme politikalarının doğru kapsamla uygulanmasını sağlar.

Veritabanı nerede durmalı?

On-premise yapılarda veritabanı genellikle uygulama sunucusundan ayrı, güvenli bir ağ segmentinde konumlandırılmalıdır. Aynı sunucuda çalışan uygulama ve veritabanı, küçük test ortamlarında pratik görünse de canlı sistemlerde ölçekleme, güvenlik ve bakım açısından risklidir.

Veritabanı sunucusuna yalnızca gerekli uygulama servisleri erişmelidir. Kullanıcıların doğrudan veritabanına bağlanması, raporlama ihtiyaçları gerekçe gösterilerek kalıcı hale getirilmemelidir. Raporlama için ayrı bir replika, veri ambarı veya kontrollü servis katmanı tasarlamak daha sağlıklı bir yaklaşımdır.

Performans için konum kadar bağlantı kalitesi de önemlidir

Veritabanının güvenli bir segmentte olması tek başına yeterli değildir. Uygulama ile veritabanı arasındaki gecikme, disk I/O kapasitesi, ağ bant genişliği ve bağlantı havuzu ayarları birlikte değerlendirilmelidir. Özellikle yoğun yazma işlemi yapan sistemlerde depolama altyapısı, işlemci gücünden daha kritik hale gelebilir.

Yedek verisi canlı veriyle aynı kaderi paylaşmamalı

Yedeklerin aynı fiziksel sunucuda veya aynı depolama havuzunda tutulması ciddi bir tasarım hatasıdır. Donanım arızası, fidye yazılımı, yanlış silme veya yetkisiz erişim gibi durumlarda canlı veriyle birlikte yedeklerin de etkilenmesi mümkündür.

Kurumsal bir on-premise projede yedekleme stratejisi en az üç katmanda düşünülmelidir: hızlı geri dönüş için yakın yedek, felaket senaryosu için ayrı lokasyon, kritik veriler için değiştirilemez veya erişimi sıkı kontrol edilen yedek alanı. Yedekleme kadar geri dönüş testleri de planlanmalıdır; test edilmemiş yedek, operasyonel güvence sağlamaz.

Yetkilendirme verinin bulunduğu yere göre tasarlanmalı

Veri nerede duruyorsa erişim modeli de o katmana göre kurulmalıdır. Dosya paylaşım izinleriyle uygulama izinleri birbirine karıştırıldığında, kullanıcılar uygulama arayüzünde görmemesi gereken dosyalara ağ paylaşımı üzerinden erişebilir.

Bu nedenle yetki yönetimi uygulama, veritabanı, dosya sistemi ve yedekleme ortamı için ayrı ayrı tanımlanmalıdır. Servis hesapları kişisel hesaplarla kullanılmamalı; parola, sertifika ve anahtar yönetimi merkezi bir prosedüre bağlanmalıdır.

Mevzuat ve denetim gereksinimlerini baştan netleştirin

Verinin fiziksel olarak kurum içinde durması, otomatik olarak uyumlu bir yapı anlamına gelmez. Kişisel veri, finansal kayıt, sağlık verisi veya sözleşme dokümanı gibi farklı veri türleri farklı saklama süreleri, erişim kayıtları ve imha süreçleri gerektirebilir.

Bu noktada veri sınıflandırması yapılmadan depolama kararı verilmemelidir. Hangi veri kritik, hangisi hassas, hangisi arşiv niteliğinde, hangisi belirli süre sonunda silinmeli sorularının yanıtı mimarinin temelini oluşturur.

Domain, kimlik ve erişim sınırları

On-premise projelerde domain yapısı, veriye erişimin omurgasını oluşturur. Kullanıcı grupları, servis hesapları, sunucu rolleri ve yönetici yetkileri domain politikalarıyla tutarlı olmalıdır. Her uygulama için geniş yetkili tek bir hesap kullanmak kısa vadede kurulumu kolaylaştırır ancak denetim ve olay incelemesini zorlaştırır.

İyi tasarlanmış bir domain yapısında veri erişimi iş rolüne göre verilir, yönetici erişimleri ayrıştırılır ve kritik sistemlere bağlantı çok faktörlü kimlik doğrulama veya ek güvenlik katmanlarıyla desteklenir.

Karar verirken kullanılabilecek pratik kontrol listesi

• Veri türleri sınıflandırıldı mı: işlem, dosya, log, arşiv, geçici veri?
• Veritabanı uygulama sunucusundan ayrıldı mı?
• Yedekler canlı sistemden fiziksel veya mantıksal olarak izole mi?
• Dosya erişimleri uygulama yetkileriyle tutarlı mı?
• Loglar merkezi olarak toplanıyor ve değiştirilmeye karşı korunuyor mu?
• Veri saklama ve imha süreleri tanımlı mı?
• Geri dönüş testleri düzenli olarak yapılıyor mu?
• Servis hesapları minimum yetkiyle çalışıyor mu?

Bu sorulara verilen yanıtlar, on-premise projelerde verinin yalnızca nerede duracağını değil, nasıl korunacağını ve operasyon içinde nasıl yönetileceğini de belirler. Sağlıklı bir on-premise veri konumlandırma yaklaşımı, sunucu yerleşiminden önce veri türünü, erişim ihtiyacını ve risk seviyesini doğru okumakla başlar.