ERP Veritabanı Tasarımında Şirketler Arası Veri İzolasyonu ve Tenant Mimarisi

Birden fazla tüzel kişiliği barındıran holding yapılarında veya grup şirketlerinde özel kurumsal yazılım geliştirirken, en kritik mimari kararların başında veri güvenliği ve izolasyon stratejileri gelir. Kurumsal Yazılım & ERP süreçlerinde, şirketler arası veri sızıntısını önlemek ve yasal uyumluluğu sağlamak için doğru bir model seçilmelidir.

ERP Mimarisi ve Çoklu Şirket Yapısı

Grup şirketleri için ERP mimarisi kurgularken, temel amaç farklı tüzel kişilerin operasyonlarını aynı dijital çatı altında toplarken operasyonel bağımsızlığı korumaktır. Bu noktada karşımıza çıkan en temel kavramlardan biri tenant yapısıdır. Çoklu şirket (multi-company veya multi-tenant) senaryolarında, veritabanı tasarımı aşamasında izlenebilecek üç ana yaklaşım bulunur: ayrı veritabanları, şema tabanlı izolasyon ve satır bazlı güvenlik (Row-Level Security - RLS).

1. Ayrı Veritabanı Yaklaşımı

Bu yöntemde her bir şirket için fiziksel veya mantıksal olarak tamamen bağımsız bir veritabanı oluşturulur.

• Avantajları: En yüksek düzeyde veri izolasyonu sağlar. Bir şirketin veritabanında oluşabilecek bir hata veya güvenlik ihlali diğerlerini doğrudan etkilemez.
• Dezavantajları: Şirketler arası veri transferleri ve ortak konsolide raporlamalar maliyetlidir ve ek entegrasyon katmanları gerektirir.

2. Şema Tabanlı İzolasyon

Aynı veritabanı sunucusu üzerinde, her şirket için ayrı bir veritabanı şeması (schema) tanımlanır. Tablo yapıları aynıdır ancak şemalar izoledir.

• Avantajları: Ortak bakım maliyetlerini düşürürken, şemalar arası sorgulama esnekliği sunar.
• Dezavantajları: Veritabanı tasarımı aşamasında dinamik şema yönetiminin karmaşıklığı, geliştirme ekipleri için ek bir yük oluşturabilir.

3. Satır Bazlı Güvenlik (RLS)

Tüm şirketlerin verileri aynı tablolar içinde tutulur ancak her satıra bir şirket kimliği (tenant id) eklenir. Veritabanı seviyesindeki kurallar sayesinde kullanıcılar yalnızca yetkili oldukları satırları görebilir.

• Avantajları: Depolama maliyetini minimuma indirir ve konsolide raporlamaları tek bir sorgu ile yapmayı mümkün kılar.
• Dezavantajları: Güvenlik açıklarının önlenmesi için uygulama ve veritabanı katmanında çok sıkı yetkilendirme testleri yapılması şarttır.

Ortak Master Veri Yönetimi ve Karar Süreçleri

Kurumsal yazılım projelerinde hangi izolasyon modelinin seçileceği; şirketlerin iş süreçlerindeki bağımlılık derecesine, denetim gereksinimlerine ve BT altyapı bütçesine bağlıdır. Malzeme kartları, cari hesaplar gibi ortak master verilerin nasıl paylaşılacağı, mimari tasarımın ilk aşamalarında netleştirilmelidir.

Varsayımsal Senaryo: Üç Şirketli Holding Yapısı ve RLS Uygulaması

Bu senaryoda, üretim, lojistik ve perakende alan faaliyet gösteren üç farklı tüzel kişiliğe sahip bir holding için satır bazlı güvenlik (RLS) modelinin nasıl kurgulandığını ele alıyoruz. Holding yönetimi, tüm operasyonel maliyetleri düşürmek ve anlık konsolide kârlılık raporları alabilmek amacıyla tek bir veritabanı ve ortak tablolar üzerinde karar kılmıştır. Geliştirme ekibi, faturalar, siparişler ve stok hareketleri tablolarına 'tenant_id' kolonu ekleyerek işe başlamıştır. Üretim şirketi (Tenant A) sisteme giriş yaptığında, veritabanı seviyesindeki güvenlik politikaları devreye girer ve uygulama katmanından bağımsız olarak yalnızca Tenant A ID değerine sahip satırlar filtrelenir. Bu sayede perakende şirketi çalışanları, üretim verilerine hiçbir şekilde erişemez.

Ancak bu mimari ciddi ticaret ve performans takaslarını beraberinde getirir. Milyonlarca satırlık stok hareketleri tablosunda doğru indeksleme yapılmadığı takdirde, her sorguya otomatik olarak eklenen 'WHERE tenant_id = X' koşulu veritabanı motorunu zorlar ve execution plan maliyetlerini artırır. Hata yönetimi açısından, uygulama katmanından gönderilen tenant bağlamının (context) unutulması veya yanlış set edilmesi durumunda felaket senaryoları yaşanabilir; çünkü RLS kuralları atlandığında tüm şirketlerin verileri birbirine karışabilir. Bu riskleri bertaraf etmek için veritabanı bağlantı havuzu (connection pooling) yönetimi sıkı bir şekilde denetlenmeli ve her sprint döneminde otomatik penetrasyon testleri çalıştırılmalıdır.

ERP Veritabanı İzolasyonu Uygulama Kontrol Listesi

Kurumsal yazılım projelerinde tenant mimarisinin kusursuz çalışması ve veri sızıntılarının önlenmesi adına aşağıdaki adımların eksiksiz uygulanması kritik önem taşır:

1. Yasal ve Finansal Gereksinim Analizi: Şirketlerin faaliyet gösterdiği ülkelerin yerel veri saklama kanunları, ayrı veritabanı zorunluluğu getirip getirmediği önceden raporlanmalıdır.
2. Tenant Kimliği Standardizasyonu: Tüm tablolarda birincil anahtar yapılarına uyumlu, optimize edilmiş veri tipinde (örn. UUID veya Integer) tenant kolonları tanımlanmalıdır.
3. Veritabanı Politikalarının Kodlanması: Satır bazlı güvenlik (RLS) veya şema tabanlı yetkiler, uygulama koduna bırakılmadan doğrudan veritabanı seviyesinde (stored procedures ve security policies) güvenceye alınmalıdır.
4. Bağlantı Havuzu ve Bağlam Yönetimi: Multi-tenant mimarilerde session state veya connection context sızıntılarını önlemek için her istek sonrasında veritabanı oturumları sıfırlanmalıdır.
5. Kapsamlı Entegrasyon ve Yük Testleri: Farklı tenant'lardan eşzamanlı gelen yüksek hacimli veri taleplerinde, izolasyon mekanizmalarının performansı düşürüp düşürmediği test edilmelidir.

Bu kontrol listesi, Kurumsal Yazılım & ERP projelerinde karşılaşılabilecek mimari riskleri minimize etmek ve denetim süreçlerini sorunsuz tamamlamak için yol haritası sunar.

Kaynaklar

• Kurumsal Yazılım & ERP — Cy Logic Software