Açıkta Kalan Veritabanları ve Bulut Yanlış Yapılandırması: Veri İhlallerinin Sessiz Sebebi
Veri ihlallerinin en sık sebebi karmaşık bir saldırı değil, açıkta kalan bir veritabanı ya da yanlış yapılandırılmış bir bulut deposudur. Kimlik doğrulamasız MongoDB, herkese açık depo, web kökündeki yedek, aşırı geniş bulut izni. Shodan ile dakikalar içinde bulunur. Sizinki açıkta mı, ilk 24 saat, adli bilişim, KVKK 72 saat ve önleme. Ankara DSET.
Hızlı cevap: Açıkta kalan veritabanı, internete kimlik doğrulaması olmadan bağlı bir MongoDB, Elasticsearch, Redis ya da yanlış yapılandırılmış bir bulut deposudur. Herkes tarayıcıyla ya da basit bir araçla içindeki veriye ulaşabilir. Böyle bir açık fark ettiyseniz, önce erişimi hemen kapatın, güvenlik grubunu ya da güvenlik duvarını yalnız gerekli IP'lere daraltın, kimlik doğrulamayı zorunlu hale getirin. Sonra erişim kayıtlarını inceleyip verinin gerçekten çekilip çekilmediğini belirleyin. İçinde kişisel veri varsa bu bir veri ihlalidir ve Kişisel Verileri Koruma Kurulu'na en geç 72 saat içinde bildirim gerekebilir. Hiçbir logu silmeyin. DSET, sızıntının kapsamını adli bilişim standardında ölçer. Acil hat: +90 536 662 38 09.
Açıkta kalan veritabanı ve bulut yanlış yapılandırması nedir
Veri ihlallerinin büyük kısmı karmaşık bir saldırıyla değil, basit bir yapılandırma hatasıyla başlar. Bir veritabanı ya da depo yanlışlıkla internete açık bırakılır, kimlik doğrulama kapatılır ve içindeki her şey isteyen herkese görünür hale gelir. Saldırganın hiçbir şeyi kırmasına gerek kalmaz, çünkü kapı zaten açıktır.
Bu, dünya genelinde en sık rastlanan sızıntı sebebidir. Bir sistem yöneticisi geliştirme sırasında bir veritabanını herkese açar ve sonra kapatmayı unutur. Bir bulut deposu yanlışlıkla herkese okunur işaretlenir. Bir yedek dosyası web sunucusunun erişilebilir bir klasörüne konur. Bunların her biri, milyonlarca kişisel kaydın tek bir bağlantıyla dışarı sızmasına yol açabilir.
En sık görülen biçimler
- Kimlik doğrulaması olmayan veritabanı. MongoDB, Elasticsearch, Redis ya da PostgreSQL, varsayılan ayarla ve parolasız olarak internete açık portta çalışır.
- Herkese açık bulut deposu. Bir nesne deposu ya da blob konteyneri yanlışlıkla herkese okunur yapılır, içindeki dosyalar dizin gibi listelenir.
- Açıkta unutulan test ortamı. Geliştirme ya da hazırlık ortamı gerçek veriyle doldurulur ve internete açık bırakılır.
- Web sunucusundaki yedek dosyaları. Veritabanı dökümü ya da sıkıştırılmış yedek, sitenin erişilebilir bir yolunda durur.
- Yanlış yapılandırılmış bulut kimlik ve erişim. Aşırı geniş izinler, varsayılan parolalar, açık yönetim portları.
Bu açıklar nasıl ortaya çıkar
Kök neden neredeyse her zaman aynıdır: güvenli olmayan bir varsayılan artı bir gözden kaçırma. Birçok veritabanı, ilk kurulduğunda kimlik doğrulamayı zorunlu tutmaz ve dinlemeyi tüm ağ arayüzlerine açar. Bir sunucuyu hızlıca ayağa kaldıran ekip, güvenlik duvarını daraltmayı ya da parolayı ayarlamayı sonraya bırakır ve o an hiç gelmez.
Bulut tarafında ise varsayılanlar genelde güvenlidir, ama tek bir yanlış tıklama her şeyi açar. Bir depoyu herkese açık yapmak, bir güvenlik grubuna geniş bir kural eklemek ya da bir kimliğe fazla yetki vermek saniyeler sürer ve kalıcı bir açık bırakır. Karmaşıklık arttıkça, hangi kaynağın gerçekte kime açık olduğunu takip etmek zorlaşır.
Saldırgan sizi nasıl bulur
Yanılgı, açık bir sistemin fark edilmeyeceğidir. Gerçekte internet sürekli taranır. Shodan ve Censys gibi servisler tüm interneti haritalar, açık portları ve servisleri saniyeler içinde listeler. Otomatik botlar açık bir veritabanını çevrimiçi olduktan dakikalar sonra bulur. Kötü niyetli kampanyalar, korumasız veritabanlarını bulup içeriğini kopyalar, sonra veriyi silip yerine bir fidye notu bırakır. Yani açık bir veritabanı keşfedilmez değildir, yalnızca henüz keşfedilmemiştir.
Sizinki açıkta mı, nasıl kontrol edilir
İlk adım kendi dış yüzeyinizi bir saldırgan gibi görmektir. Genel IP adreslerinizi ve alan adlarınızı dış bir bakışla tarayın, hangi portların ve servislerin dışarıdan erişilebilir olduğunu çıkarın. Veritabanı portlarının (ör. MongoDB, Elasticsearch, Redis, veritabanı sunucuları) internete açık olmaması gerekir. Bulut tarafında depo erişim izinlerini, güvenlik gruplarını ve kimlik yetkilerini gözden geçirin. Dış saldırı yüzeyi taramasını sürekli bir alışkanlık haline getirmek, açığı saldırgandan önce yakalamanın tek güvenilir yoludur. Kimlik ve erişim tarafını sağlamlaştırmak için IAM kimlik ve erişim yönetimi rehberimize göz atabilirsiniz.
Açıkta kalan yapılandırma türleri ve sonuçları
| Yanlış yapılandırma | Tipik açık | Sonuç |
|---|---|---|
| Kimlik doğrulamasız veritabanı | Parolasız, tüm arayüzlere açık port | Tüm kayıtlar okunur, silinir ya da fidyeye alınır |
| Herkese açık bulut deposu | Public okuma izni, dizin listeleme | Dosyalar ve yedekler kitlesel indirilir |
| Açıktaki test ortamı | Gerçek veriyle dolu, korumasız kopya | Üretim verisi test üzerinden sızar |
| Web kökündeki yedek | Erişilebilir yolda veritabanı dökümü | Tek bağlantıyla tam veritabanı iner |
| Aşırı geniş bulut izni | Fazla yetkili kimlik, açık yönetim portu | Bir kimlik ele geçince tüm hesap açılır |
Açıkta kaldığını fark edince ilk 24 saat
Zaman en değerli kaynağınızdır. Sırayla ve hızlı hareket edin.
- Erişimi hemen kapatın. Güvenlik grubunu ya da güvenlik duvarını yalnız gerekli IP'lere daraltın, kimlik doğrulamayı zorunlu yapın, herkese açık depo iznini kaldırın.
- Delilleri dondurun. Erişim kayıtlarını, veritabanı loglarını, güvenlik duvarı ve bulut denetim kayıtlarını koruyun. Hiçbir logu silmeyin, sistemi sıfırdan kurmaya çalışmayın.
- Kapsamı belirleyin. Hangi IP'ler, ne zaman, ne kadar veri çekti. Bir fidye notu bırakıldıysa verinin kopyalandığını varsayın.
- Sızmış kimlikleri değiştirin. Açık sistemdeki tüm parolaları ve anahtarları döndürün, üçüncü taraf entegrasyon anahtarlarını yenileyin.
- KVKK yükümlülüğünü değerlendirin. İçinde kişisel veri varsa bildirim süreci hemen başlamalıdır.
Bu adımların birkaçını aynı anda yürütmek gerekir. Teknik ekip açığı kapatırken, adli bilişim ekibi neyin sızdığını ve KVKK yükümlülüğünü belirler. Genel çerçeve için siber olay müdahale playbook rehberimize bakabilirsiniz.
Adli bilişim: gerçekte ne sızdı
Asıl soru şudur: veri sadece açıkta mıydı, yoksa gerçekten çekildi mi. Bu ayrım hem hukuki sorumluluğu hem de KVKK bildiriminin kapsamını belirler. DSET adli bilişim ekibi, sunucu ve bulut erişim kayıtlarını inceleyerek hangi IP'lerin hangi veriye, ne zaman ulaştığını ortaya koyar. Erişim kayıtları eksikse, ihlalin en kötü senaryosu üzerinden değerlendirme yapılır. Süreç boyunca delil zinciri titizlikle korunur, çünkü mahkemede ve Kurul önünde kabul görmesi buna bağlıdır. Delil zinciri ve rapor standardı için adli bilişim süreci rehberimizi inceleyebilirsiniz.
KVKK boyutu: bu bir veri ihlalidir
Açıkta kalan bir veritabanı kişisel veri içeriyorsa, sızıntı gerçekleşmese bile ciddi bir risk vardır, çünkü verinin kime ulaştığını çoğu zaman bilemezsiniz. Erişim kanıtlanırsa ya da makul bir ihtimal varsa, veri sorumlusunun ihlali öğrendiği andan itibaren en geç 72 saat içinde Kişisel Verileri Koruma Kurulu'na bildirim yapması gerekir. Bildirimi atlamak, sızıntının üstüne idari para cezası riskini ekler. Doğru yaklaşım, kapsamı adli bilişim bulgularıyla netleştirmek ve bildirimi bu bulgulara dayandırmaktır. Bildirim süreci için KVKK 72 saat veri ihlali bildirimi rehberimize göz atın.
Önleme: kapıyı baştan kapalı tutmak
Açıkta kalan veritabanı bir teknik açık değil, bir süreç açığıdır. En etkili savunma, güvenli varsayılanları zorunlu kılmaktır.
Her veritabanında kimlik doğrulama zorunlu olmalı, dinleme yalnız iç ağa ya da belirli IP'lere sınırlanmalıdır. Bulut kaynakları varsayılan olarak özel olmalı, herkese açık erişim yalnız bilinçli ve belgelenmiş bir kararla verilmelidir. Kimliklere en az yetki ilkesiyle sadece gereken izin tanımlanmalıdır. Yedek dosyaları hiçbir zaman web sunucusunun erişilebilir bir yolunda tutulmamalıdır.
Bunların tümünü sürekli denetlemek için düzenli bir yapılandırma taraması ve dış saldırı yüzeyi izlemesi gerekir. Yeni bir kaynak açıldığında ya da bir izin değiştiğinde, bunun dışarıya ne açtığını görmek şarttır. Dış yüzeyinizin gerçek durumunu bir saldırgan gözüyle görmek için sızma testi hizmetimiz açık portları, korumasız servisleri ve yanlış yapılandırmaları da kapsar.
Sık sorulan sorular
Veritabanımın internete açık olup olmadığını nasıl anlarım? Genel IP adreslerinizi ve alan adlarınızı dış bir bakışla tarayın, veritabanı portlarının dışarıdan erişilebilir olup olmadığını kontrol edin. Bir dış saldırı yüzeyi taraması bunu net gösterir. Veritabanı portları asla doğrudan internete açık olmamalıdır.
Açık bir veritabanını gerçekten kimse bulur mu? Evet, hem de hızla. İnternet sürekli taranır ve otomatik botlar açık bir veritabanını çevrimiçi olduktan dakikalar sonra bulur. Keşfedilmemiş olması, güvende olduğunuz anlamına gelmez.
Veritabanıma bir fidye notu bırakılmış, ne yapmalıyım? Verinin kopyalandığını ve silinmiş olabileceğini varsayın. Ödeme yapmayın, ödeme verinin geri geleceğini garanti etmez. Notu ve tüm logları silmeden saklayın, erişimi kapatın ve bir adli bilişim uzmanıyla kapsamı belirleyin.
Bu olay için KVKK bildirimi yapmam gerekir mi? Açık veritabanı kişisel veri içeriyorsa ve erişim kanıtlanır ya da makul bir ihtimalse, 72 saat içinde Kurula bildirim yükümlülüğü doğar. Kapsamı adli bilişim bulgularıyla netleştirmek en doğru yaklaşımdır.
Adli inceleme için hangi kayıtları saklamalıyım? Sunucu ve veritabanı erişim kayıtlarını, güvenlik duvarı ve bulut denetim kayıtlarını, yük dengeleyici loglarını ve varsa fidye notunu saklayın. Silme ya da yeniden kurulum yapmadan önce uzmana danışın.
Kaynaklar
- Shodan, internete açık servis ve cihaz arama motoru: https://www.shodan.io
- Kişisel Verileri Koruma Kurumu, veri ihlali bildirimi: https://www.kvkk.gov.tr
- OWASP, Security Misconfiguration: https://owasp.org
- CIS Benchmarks, güvenli yapılandırma standartları: https://www.cisecurity.org
- Türkiye USOM, Ulusal Siber Olaylara Müdahale Merkezi: https://www.usom.gov.tr
Bir veritabanınızın ya da bulut kaynağınızın açıkta kaldığından şüpheleniyorsanız, delil kaybetmeden hareket etmek kritiktir. DSET ile iletişime geçin, Ankara Hacettepe Teknokent laboratuvarımızdan olay müdahale ve adli bilişim desteği verelim.
Kimliğinizi doğrulayın
Yetkilendirilmiş erişim alanı. Tüm giriş denemeleri kayıt altına alınır.