Güvenlik Açığı Yaratmadan Kurumsal Veritabanı Göçü

Veritabanı Göçü Riskinin Büyük Kısmı İstisnalarda Saklanır

Ekipler veritabanı geçişi (database migration) riskini değerlendirirken tartışma genellikle downtime pencereleri, veri kaybı önleme ve cutover zamanlaması etrafında döner. Bunlar meşru kaygılar; ama en önemli güvenlik maruziyetinin ortaya çıktığı yer nadiren burasıdır. Göçler sırasındaki güvenlik olayları çoğunlukla ekiplerin — genellikle deadline baskısıyla — göçü mümkün kılmak için açtıkları geçici istisnalardan gelişir: geniş kapsamlı erişim izinleri, normal secret yönetimi dışında dağıtılan kimlik bilgisi kopyaları, kontrolsüz staging exportları, yükseltilmiş ayrıcalıklara sahip uzun ömürlü migration servis hesapları ve öngörülen süreden çok sonra da açık kalan rollback yolları.

Geçiş Risk Matrisi

Her veritabanı geçişi öngörülebilir riskler taşıyor. Bunları çalışma başlamadan önce açıkça haritalandırmak, deadline baskısının teşvik ettiği dikkatsiz maruziyet kabulünü önler:

| Risk | Olasılık | Azaltma | Sahip |

|------|----------|---------|-------|

| Aşırı ayrıcalıklı migration hesabı | Yüksek | En az ayrıcalıklı servis hesabı; cutover sonrası otomatik sona erme | Güvenlik ekibi |

| Silinmeden bırakılan staging export | Yüksek | Otomatik silme işi; saklama politikası zorunlu | DevOps / DBA |

| Düz metin olarak dağıtılan kimlik bilgileri | Orta | Yalnızca secrets manager enjeksiyonu; e-posta/Slack paylaşımı yok | Güvenlik ekibi |

| Cutover sonrası açık kalan rollback yolu | Orta | Süreli rollback penceresi; kapatmak için açık onay | DBA / Proje lideri |

| Göç penceresindeki denetim log boşluğu | Orta | Göç öncesi log yapılandırması doğrulaması | DBA |

| Test ortamındaki üretim verisi | Düşük-Orta | Test için sentetik veri; üretim kopyası yalnızca izole ortamda | DBA / Güvenlik |

Geçiş Sonrası Temizlik Kontrol Listesi

Göç sonrası güvenlik olaylarının kök nedeni nadiren göçün kendisidir. Geride kalan istisnalardır. Aşağıdaki kontrol listesi başarılı cutover'dan sonraki 48 saat içinde tamamlanmalıdır:

Tüm geçici migration servis hesaplarını kaldır ve artık aktif oturumları olmadığını doğrula.

Tüm staging veri exportlarını sil veya arşivle — onaylı depolama konumları dışında kopya kalmadığını onayla.

Göç penceresi boyunca ortamlar arasında paylaşılan tüm kimlik bilgilerini döndür.

Rollback yollarını açıkça kapat — kaynak veri tabanına üretim sistemlerinden artık erişilemediğini doğrula.

Denetim loglama: göç penceresindeki tüm değişiklik olaylarının yakalandığını ve atfedilebildiğini onayla.

Göç için açılan geçici güvenlik duvarı kurallarını veya ağ erişim istisnalarını gözden geçir ve iptal et.

RLS politikalarının ve uygulama katmanı yetkilendirme mantığının geçirilen veriye doğru uygulandığını doğrula.

Hedef veri tabanında izin denetimi çalıştır — göç başlamadan önceki temel çizgiyle karşılaştır.

Göçü Güvenlik Açısından Hassas Yapan Şey Nedir?

Bir veritabanı geçişi, sistemdeki neredeyse tüm anlamlı güven sınırlarını aynı anda etkiler:

normal operasyonlarda bulunmayan yükseltilmiş sistemler arası izinler gerektiren kaynak ve hedef erişim kontrolü.

ekipler, ortamlar ve araçlar arasında dağıtılan secretlar ve bağlantı dizeleri.

canlı veya canlıya yakın veri üzerinde çalışmak zorunda kalan veri bütünlüğü doğrulama prosedürleri.

üretim verisinin tam kopyalarını geçici olarak barındıran yedekleme ve rollback durumu.

yüksek sistem aktivitesi döneminde de kesintisiz kalması gereken loglama ve değişiklik hesap verebilirliği zincirleri.

Birden fazla güven sınırına yayılan bu eş zamanlı maruziyet, göç dönemlerini gizli güvenlik borcunun fark edilmeden birikmesi açısından en riskli pencereler arasına koyar.

Daha Sağlam Göç Disiplini

Güvenlik odaklı bir geçiş planı, ilk değişiklik yapılmadan önce şu soruları açıkça sorar:

hangi geçici hesaplar ve kimlik bilgileri oluşturulacak, tam kapsamları ne ve ne zaman sona erecek?

veriler geçiş sürecinde nerede tutulacak, bu konumlara kimlerin erişimi var ve depolanırken ile aktarılırken nasıl korunacak?

cutover başarılı ilan edildikten sonra rollback yolları nasıl yönetilecek ve rollback'i kim yetkili kılabilecek?

hangi denetim logları neyin değiştiğini, hangi sırayla ve her adımı kimin onayladığını kanıtlayacak?

MyVuln Yaklaşımı

MyVuln, geçici maruziyet pencerelerini, yükseltilmiş kimlik kararlarını ve veri taşıma yollarını proje lojistiği dipnotu olarak geçiştirmek yerine açık risk sinyalleri olarak görünür kılıp izlediğinde geçiş yoğun ortamlarda gerçek değer üretir. Platform, beklenen sona erme süresini aşmış migration servis hesaplarını, cutover penceresinin ötesinde erişilebilir kalan staging konumlarını ve kimlik bilgisi rotasyon boşluklarını işaretliyor — tam olarak geçiş sonrası olaylara yol açan geride kalan istisnaları ortaya koyuyor. Göç sonrası güvenlik olaylarının kök nedeni nadiren göçün kendisidir. Geride kalan istisnalardır: hiç kaldırılmamış servis hesapları, hiç silinmemiş staging kopyaları, hiç döndürülmemiş rollback kimlik bilgileri.

Kurumsal veritabanı göçlerinde herkes veri tutarlılığına, performansa ve kesinti penceresine odaklanırken güvenlik varsayımları sessizce zayıflayabilir. Migration için geçici olarak sağlanan geniş erişim yetkileri iptal edilmez ve kalıcı hale gelir. Migration servis hesapları unutulur. Cutover süresi boyunca eski ve yeni ortam arasında çift yönlü güven ilişkisi oluşur. Denetim zinciri kopukluğa uğrar. Proje teknik açıdan başarıyla tamamlanmış görünür; ancak yeni platform, yerini aldığı kaynak sistemden daha gevşek bir güvenlik duruşuyla ayağa kalkmış olur.

Bu nedenle kapsamlı bir göç planı güvenlik çıktılarını da birincil çıktılar olarak ele alır — her birinin sahibi ve tamamlanma kriteri net olmalıdır:

| Güvenlik çıktısı | Sahip | Tamamlanma kriteri |

|---|---|---|

| Yetki daraltma denetimi | Güvenlik ekibi | Kaynak ile hedef rol farkı incelendi ve onaylandı |

| Migration hesap devre dışı bırakma | Altyapı | Cutover'dan 24 saat içinde tüm migration hesapları silindi |

| Uygulama secret rotasyonu | Uygulama ekibi | Tüm secret'lar döndürüldü, kaynak ortamdan kopyalanmadı |

| Denetim günlüğü sürekliliği | Uyum | Cutover penceresi boyunca log kesintisi yok |

| Rollback credential seti | Altyapı | Belgelenmiş, test edilmiş, kaynak ortama erişim olmadan ulaşılabilir |

| RLS politika doğrulaması | Veritabanı ekibi | Hedef ortamda adversarial sorgularla row-level security test edildi |

Güvenlik perspektifinden bir göçün mümkün olan en iyi çıktısı, yeni platformun kaynak sistemden daha dar erişim yetkileri, daha iyi denetim görünürlüğü ve daha temiz secret yönetimiyle ayağa kalkmasıdır. Bunu başarmak için göç anını tek seferlik veri taşıma operasyonu olarak değil, güvenlik modelini kasıtlı biçimde yeniden inşa etme fırsatı olarak görmek gerekir. Göç sonunda uygulama daha geniş servis hesabı yetkileriyle çalışıyor, kimin hangi veriye ne zaman dokunduğu daha az görünür hale gelmiş ve kaynak ortamdan kalan geçici köprüler hâlâ açıksa proje en değerli çıktısını kaçırmış demektir. Veri taşınmış olabilir; güven taşınmamıştır.