İnternete Açık Veritabanı Yüzeyinin Kurumsal Denetimi: Yedi Adımlı Çerçeve

Veritabanı maruziyeti, bir veritabanı örneğinin internetten doğrudan erişilebilir olması durumudur. Kurumsal denetimi yedi adımdan oluşur: envanter, dışarıdan yüzey ölçümü, uygulama ile veritabanı arasındaki katman ayrımı, kimlik ve parola politikası, başarısız giriş kaydı, her açık kural için sahiplik, ve AI araç sunucularının kapsama alınması. Denetimin çıktısı bir tarama raporu değil, sahibi belli bir karar listesidir.

Sınır: Bu içerik hukuki danışmanlık değildir ve komut düzeyinde bir uygulama rehberi de değildir. Denetim çerçevesini kurar; teknik uygulama ve ham veri analizi için yazının sonundaki yönlendirmelere bakılmalıdır.

Ağustos 2026’da MySQL 3306 taraması hangi ölçüde arttı?

SiberKale’nin honeypot ağında 2 Ağustos 2026 ile 9 Ağustos 2026 arasında ölçülen port dağılımında MySQL’in 3306 portu 5.161.194 olayla birinci sıraya oturdu. Onu SSH (4.333.038), HTTP (4.300.515) ve HTTPS (4.299.655) izledi. Kıyas noktası şu: Temmuz ayında 80 ve 443 portları toplam trafiğin %96’sını oluşturuyordu, 3306 ise yaklaşık 90 bin olayda kalıyordu. Aylardır birinci olan web portları, tek bir hafta içinde ikinci sıraya düştü.

Aynı işaret IDS tarafında da görünür. ET SCAN Suspicious inbound to mySQL port 3306 imzası bu pencerede 945.724 kez tetiklendi; Temmuz ayındaki karşılığı 807’ydi.

8 Ağustos’un tepe noktası olmadığı sonradan ölçüldü. O gün kaydedilen 10 milyon olay bir zirve değil eşik çıktı: 10 Ağustos’tan itibaren günlük hacim 20,4 milyonda sabitlendi ve üç gün üst üste yüzde yarımdan az değişti. Dört hedef port da aynı 2,03 katsayısıyla büyüdü. Kurumsal karar açısından kritik olan ayrıntı ise benzersiz kaynak sayısının artmaması: hacim ikiye katlanırken kaynak IP sayısı 12 bin civarında kaldı ve dört günde tehdit veritabanına yalnız 195 yeni gösterge girdi.

Bunun iki pratik sonucu var. Birincisi, engelleme listesinin tazeliği bu tür kampanyalarda belirleyici değil; aynı adresler günlerce döndüğü için bir hafta önceki liste büyük ölçüde geçerli kalıyor, önemli olan listenin doğru ASN’leri kapsayıp kapsamadığı. İkincisi, tek tek IP engellemek ölçek olarak anlamsız: yük IP sayısından değil IP başına yoğunluktan geliyor, dolayısıyla skorlama en az ASN düzeyine taşınmalı.

Taramanın baskın kaynağı, Türk barındırma sağlayıcılarında saatlik kiralanan düğümlerdi. Bu, Türkiye’nin hedef olduğu anlamına gelmez; ucuz ve hızlı kurulan altyapının tarama için kullanıldığı anlamına gelir. Verinin ham hâli ve saldırgan davranışının analizi Tellal’daki 9 Ağustos bülteninde, taramanın sonraki günlerdeki seyri ise 9-13 Ağustos bülteninde yayımlandı. Honeypot verisinin savunmaya nasıl çevrildiğini daha önce ayrı bir yazıda ele almıştık.

Bu trafik istismar mı, envanter çıkarma mı?

Envanter çıkarma. MySQL emülasyonu yapan potta kaydedilen 7.351 etkileşimin tamamı boş parolayla geldi. Denenen kullanıcı adları root (2.431), admin (2.308) ve sa (2.299) oldu. Belirleyici bulgu şu: bu etkileşimlerde tek bir SQL komutu çalıştırılmadı ve tek bir dosya yüklenmedi.

Davranışın anlamı nettir. Saldırgan veri çalmaya, tablo silmeye veya kod çalıştırmaya çalışmıyor; el sıkışmayı tamamlıyor, sunucunun parolasız erişime izin verip vermediğini öğreniyor, sonucu kaydediyor ve bağlantıyı kapatıyor. Bu, istismar değil haritalama aşamasıdır.

Kurum açısından üç sonuç doğar:

1. Görünmeme lüksü yok. Public IP’niz üzerinde açık bir veritabanı portu varsa, o port bu hafta içinde denenmiş olma ihtimali yüksektir.
2. Zararsız görünen kayıt en tehlikeli olandır. Hiçbir sorgu çalıştırmayan bir oturum, çoğu izleme kurulumunda alarm üretmez ve kimse fark etmez.
3. İkinci tur ayrı bir aktör olabilir. Envanter listesi paylaşılabilir veya satılabilir; ilk temas ile gerçek istismar arasında haftalar geçebilir.

Veritabanı maruziyeti neden bir “sunucu ayarı” değil, envanter sorunudur?

Çünkü maruziyetin kökeni çoğu zaman yanlış yazılmış tek bir parametre değil, sahibi olmayan bir kuraldır. Sahada tekrarlayan zincir şudur: bir geliştirici yıllar önce evden bağlanmak için “geçici” bir kural açtı, iş bitti, kural kaldı. Kuralı açan kişi bugün kurumda olmayabilir, kuralın gerekçesi hiçbir yere yazılmamıştır ve kimse onu kaldırma sorumluluğunu almaz.

Bu yüzden denetimin ilk sorusu “port açık mı” değildir. İlk soru şudur: bu kuralı kim açtı, hangi ihtiyaç için ve ne zamana kadar geçerli? Cevabı olmayan her kural, kalıcı bir kuraldır.

Aynı mantık ağ tarafındaki genel saldırı yüzeyi için de geçerlidir; kurumsal ağ yüzeyinin nasıl daraltıldığını network altyapı hizmetimiz kapsamında ele alıyoruz.

Denetim adımı 1: hangi veritabanı örnekleri var ve hangi arayüzü dinliyor?

Envanter, denetimin zeminidir ve eksik envanter üzerine kurulan hiçbir sonuç geçerli değildir. Çıkarılması gereken liste her örnek için şu alanları içerir: veritabanı türü ve sürümü, çalıştığı sunucu, dinlediği arayüz (yalnızca yerel, yalnızca iç ağ, tüm arayüzler), erişen uygulamalar, içindeki verinin kişisel veri barındırıp barındırmadığı ve teknik sahibi.

Envanterde en sık kaçan üç kalem: test ve geliştirme kopyaları (içinde gerçek veri olur), bir uygulama kurulumuyla birlikte gelen gömülü veritabanları ve konteyner içinde çalışan örnekler. Üçü de “bizim veritabanı sunucumuz” listesinde görünmez.

Denetim adımı 2: dışarıdan gerçekten neye erişilebiliyor?

Kural setini okumak yüzey ölçümü değildir. Yüzey, kurum ağının dışındaki bir noktadan ölçülür: public IP aralığına karşı veritabanı portları denenir ve bağlantının el sıkışmayı tamamlayıp sürüm bilgisi döndürüp döndürmediğine bakılır.

Bu ayrım pazarlığa kapalı, çünkü kural ile gerçek davranış arasında sessiz bir fark olabilir. Konteyner çalışma zamanlarının kendi yönlendirme kuralları, host üzerinde elle yazılmış filtre kurallarının önüne geçebilir; sonuçta “kapalı” sanılan bir port dışarıdan açık olur. Bu mekanizmanın komut düzeyindeki ayrıntısı ayrı bir teknik yazıda ele alındı.

Denetim kuralı: erişimi kullanacağın protokolle ölç. Yapılandırma dosyasında yazan değer bir iddiadır, dışarıdan alınan cevap kanıttır.

Denetim adımı 3: uygulama ile veritabanı arasındaki erişim internet erişimiyle aynı kural setinde yönetilebilir mi?

Hayır. Uygulama sunucusunun veritabanına erişmesi ile internetteki herhangi bir adresin veritabanına erişmesi, aynı türde iki erişim değildir ve tek bir kural setiyle yönetilirse birinin gevşemesi diğerini de gevşetir.

Doğru kurgu üç katmanlıdır:

• Katman 1, internet ile uygulama arasında: yalnızca uygulamanın hizmet verdiği portlar açık.
• Katman 2, uygulama ile veritabanı arasında: veritabanı portu yalnızca uygulama sunucusunun adresine açık, tercihen ayrı bir ağ segmentinde.
• Katman 3, yönetim erişimi: veritabanına yönetsel bağlantı doğrudan internetten değil, VPN veya atlama noktası üzerinden.

Segmentasyon burada kozmetik bir tercih değil, hasarı sınırlayan tek mekanizmadır. Düz bir ağda ele geçen tek bir uygulama sunucusu, tüm veritabanlarına açılan kapıdır. Kurum tarafındaki uygulaması için siber güvenlik hizmetimizin kapsamına ve KVKK teknik tedbirler checklist’ine bakılabilir.

Denetim adımı 4: boş veya varsayılan parola bir denetimi geçmiş sayılır mı?

Sayılmaz. Boş parola, zayıf parola değildir; kimlik doğrulamanın hiç olmadığı durumdur. Ağustos verisinde denenen kullanıcı adlarının root, admin ve sa olması tesadüf değil: bunlar veritabanı kurulumlarının varsayılan yönetici hesaplarıdır ve tarama bu üçünü öncelikli dener.

Denetimin bu adımda sorduğu sorular:

• Boş parolayla oturum açabilen bir hesap var mı?
• Kurulumdan gelen varsayılan yönetici hesabı hâlâ etkin ve varsayılan adıyla mı duruyor?
• Uygulamanın kullandığı hesap yönetici yetkisiyle mi bağlanıyor, yoksa yalnızca ihtiyacı olan yetkiyle mi?
• Aynı parola birden fazla ortamda (üretim, test, geliştirme) kullanılıyor mu?

Son madde en çok ısıran maddedir: test ortamının parolası sızdığında üretim veritabanı da sızmış olur.

Denetim adımı 5: başarısız kimlik doğrulama denemeleri loglanmıyorsa ne kaybedilir?

Envanter taramasının kendisi kaybedilir. Boş parolayla gelip hiçbir sorgu çalıştırmadan kapanan bir oturum, yalnızca başarısız kimlik doğrulama kaydı bırakır. Bu kayıt tutulmuyorsa kurum, kendisinin haritalandığını hiç öğrenmez ve ikinci tur geldiğinde ilk temasın ne zaman olduğunu söyleyemez.

Denetim beklentisi üç maddedir: başarısız kimlik doğrulama denemeleri veritabanı tarafında kayda alınıyor, kayıtlar merkezi ve üzerinde oynanamayacak bir yerde tutuluyor, belirli bir eşiği aşan deneme yoğunluğu uyarı üretiyor. Toplanıp bakılmayan log, olmayan logla aynı değere sahiptir. Merkezi izleme tarafını Zabbix ile ağ izleme kurulumu yazısında ve network izleme hizmetinde ele aldık.

Denetim adımı 6: her açık kuralın sahibi ve bitiş tarihi var mı?

Bu adım, denetimi bir kerelik temizlikten kalıcı bir düzene çeviren adımdır. Kural şudur: dışarıya açılan her erişim için bir teknik sahip, bir iş gerekçesi ve bir bitiş tarihi kaydedilir. Bitiş tarihi geldiğinde kural, gerekçesi yeniden onaylanmadıkça kapanır.

Bu kayıt olmadan her açık kural varsayılan olarak kalıcıdır ve bir yıl sonra kimse neden açıldığını bilmez. Sahiplik ataması, veritabanı maruziyetinin tekrar etmesini engelleyen tek yapısal önlemdir.

Denetim adımı 7: AI araç sunucuları veri erişim envanterinde mi?

Bu adım çerçeveye 2026 Ağustos’unda eklendi ve sebebi ölçülmüş bir ilk: honeypot ağımıza gelen taramalarda ilk kez bir MCP (Model Context Protocol) sunucusu araması kaydedildi. Gelen istek, açıkta bırakılmış bir MCP sunucusunun yetenek listesini isteyen bir protokol el sıkışmasıydı.

Bu adımın veritabanı maruziyeti çerçevesine girmesinin nedeni şu: bir MCP sunucusu tanımı gereği bir veri erişim köprüsüdür. Arkasına dosya sistemi, veritabanı bağlantısı veya iç API’ler bağlanır ve bunu yaparken kendi kimlik doğrulaması genellikle varsayılan olarak kapalıdır. Yani kimlik doğrulaması olmadan internete açılmış bir MCP sunucusu, arkasındaki her veri kaynağına açılmış bir kapıdır ve klasik port envanterinde görünmez, çünkü kurum onu bir “veritabanı” olarak sınıflandırmaz.

Denetim soruları:

• Kurumda hangi AI araç sunucuları çalışıyor, hangi ekip kurdu ve envanterde kayıtlı mı?
• Bu sunucular hangi veri kaynaklarına erişiyor ve erişim en az yetki ilkesine göre mi tanımlı?
• Dışarıdan erişilebilir durumda mı? Ölçüm yine varsayımla değil, kurum ağı dışından denenerek yapılır.
• Kimlik doğrulaması var mı ve istekleri loglanıyor mu?

Aynı pencerede bir AI platformu zafiyetinin (IBM Langflow kimlik doğrulama atlatma) da tarandığı görüldü. İkisi birlikte tek bir şeyi söylüyor: AI altyapısı artık ayrı bir kategori değil, saldırı yüzeyinin sıradan bir parçası. Bir kurum veri envanterini AI araçlarını kapsamayacak biçimde tutuyorsa, envanteri eksiktir.

Denetim bulguları hangi karar tablosuna dönüşür?

Denetimin çıktısı liste değil karardır. Her bulgu aşağıdaki forma çekilir; kanıt kolonu boş kalan satır bulgu sayılmaz.

Bulgu	Kanıt	Karar	Sahip	Süre
Veritabanı portu dışarıdan erişilebiliyor	Kurum ağı dışından alınan bağlantı yanıtı	Erişimi kaynak bazında kapat, yalnızca uygulama sunucusuna aç	Sistem yöneticisi	Aynı gün
Örnek tüm ağ arayüzlerini dinliyor	Sunucu yapılandırma değişkeni + dışarıdan doğrulama	Dinlenen arayüzü iç arayüzle sınırla, sonucu tekrar ölç	Sistem yöneticisi	1 hafta
Boş veya varsayılan parolalı hesap var	Kimlik doğrulama denemesi sonucu	Hesabı devre dışı bırak, uygulama hesabını en az yetkiyle yeniden tanımla	Veritabanı sahibi	Aynı gün
Başarısız giriş denemesi loglanmıyor	Log kaynağında kayıt yokluğu	Kaydı aç, merkezi toplamaya bağla, eşik uyarısı tanımla	İzleme sorumlusu	2 hafta
Açık kuralın sahibi ve gerekçesi bilinmiyor	Kural kaydında boş alan	Sahip ata, gerekçeyi yaz, bitiş tarihi tanımla; sahipsizse kaldır	Ağ yöneticisi	2 hafta
Test/geliştirme kopyası gerçek veri içeriyor	Envanter kaydı	Veriyi maskele veya kopyayı kaldır	Uygulama sahibi	1 ay
AI araç sunucusu (MCP) envanterde yok veya dışarıdan erişilebiliyor	Kurum ağı dışından alınan protokol yanıtı	Erişimi iç ağa kapat, kimlik doğrulaması zorunlu kıl, eriştiği veri kaynaklarını envantere yaz	Uygulama sahibi	1 hafta

Bir bulgunun kapatılması, kapatma işleminin aynı yöntemle yeniden ölçülmesiyle tamamlanır. Kuralı değiştirmek karar değildir; dışarıdan yapılan ikinci denemenin cevabı karardır.

Kişisel veri barındıran veritabanı için KVKK tarafında tablo nedir?

Kişisel veri barındıran bir veritabanının internetten doğrudan erişilebilir olması, KVKK’nın 12. maddesindeki teknik tedbir yükümlülüğü açısından doğrudan risktir. Kurumun Kişisel Veri Güvenliği Rehberi ağ güvenliğini, segmentasyonu ve gereksiz servislerin dışarıya kapatılmasını teknik tedbir olarak sayar. Bir ihlal yaşanmamış olsa dahi, gerekli tedbirin alınmadığı yönünde bir değerlendirme mümkündür.

Buna eşlik eden ikinci nokta: veri kaybı da bir ihlaldir. İnternete açık bir veritabanına yönelen ikinci turun tipik sonucu, verinin şifrelenmesi veya silinmesidir; bu yüzden maruziyet denetimi, kurtarma tarafıyla birlikte değerlendirilir. Değiştirilemez yedek konusunu fidye yazılımına karşı immutable backup yazısında ayrıntılandırdık. Teknik tedbirlerin bütününü ise KVKK teknik tedbirler checklist’i kapsıyor.

Komut düzeyindeki uygulama ve ham veri nerede?

Bu yazı denetim çerçevesini kurar ve iki noktada bilinçli olarak durur. Sunucu yapılandırması, konteyner yönlendirme kuralları ve doğrulama komutları düzeyindeki uygulama erdemozyurt.com’daki teknik yazıda ele alındı. Saldırgan davranışının ham verisi ve analizi Tellal’daki 9 Ağustos bülteninde ve 9-13 Ağustos bülteninde yayımlandı.

Kurum tarafında kalan iş, envanteri çıkarmak ve yüzeyi dışarıdan ölçmektir. Kendi ağınızın dışarıdan ne kadar görünür olduğunu sorgulamak için saldırı yüzeyi değerlendirmesine ve zafiyetlerin nasıl önceliklendirildiğini görmek için zafiyet analizi sürecine bakabilirsiniz. SiberKale’nin honeypot ağından çıkan verinin nasıl bir istihbarat akışına dönüştüğünü Tellal platformunu anlattığımız yazıda açıkladık.