5 Milyon Satır, Tek Sorgu: Veri İhlali Böyle Başlayabilir

SELECT * FROM CUSTOMER

Bir Sorgu Ne Zaman Veri İhlaline Dönüşür?

Bir veritabanı yöneticisi için aşağıdaki sorgu son derece sıradan görünebilir:

SELECT * FROM CUSTOMER;

Teknik olarak burada bir saldırı yoktur. SQL Injection yoktur. Exploit kullanılmamıştır. Zararlı yazılım yoktur. Kullanıcının yetkisi de vardır.

Ama CUSTOMER tablosunda 8 milyon müşteri kaydı bulunuyorsa ve sorguyu çalıştıran kişinin işini yapmak için yalnızca birkaç müşterinin kaydına ihtiyacı varsa, artık sormamız gereken soru değişir:

Bir kullanıcının veriye erişme yetkisinin olması, o verinin tamamını çekme hakkına sahip olduğu anlamına gelir mi?

Veri güvenliğinin en kritik konularından biri tam olarak burada başlar.

---

1. Tehlikeli Olan Her Zaman DELETE Değildir

Veritabanı güvenliğinde yıllarca aşağıdaki işlemler yüksek riskli kabul edildi:

DROP TABLE CUSTOMER;

DELETE FROM CUSTOMER;

UPDATE CUSTOMER

SET CREDIT_LIMIT = 999999;

Bunların tehlikeli olduğu açıktır.

Fakat veri ihlallerinde çok daha sessiz bir komut vardır:

SELECT

Çünkü saldırganın amacı her zaman sistemi bozmak değildir.

Bazen amaç yalnızca veriyi almaktır.

Örneğin:

SELECT *

FROM CUSTOMER;

Veya:

SELECT *

FROM CREDIT_CARD;

Ya da:

SELECT

    NAME,

    SURNAME,

    EMAIL,

    PHONE,

    NATIONAL_ID,

    ADDRESS

FROM CUSTOMER;

Bu sorgular veritabanında hiçbir şeyi değiştirmez.

Uygulama çalışmaya devam eder. Servis kesilmez. Tablo silinmez. Kullanıcı şikâyeti oluşmaz.

Ama milyonlarca kayıt sistem dışına çıkarılmış olabilir.

Bu nedenle modern veri güvenliğinde sadece “Kim veritabanına bağlandı?” sorusu yeterli değildir.

Asıl sorular şunlardır:

Kim, hangi veriye, ne zaman, hangi uygulamayla erişti ve ne kadar veri aldı?

---

2. SELECT * Neden Masum Göründüğü Kadar Masum Değildir?

SELECT * teknik olarak yanlış bir SQL komutu değildir.

Sorun, sorgunun bağlamıdır.

Bir DBA’nın sorun giderme (troubleshooting) sırasında küçük bir konfigürasyon tablosunda:

SELECT * FROM DB_CONFIG;

Çalıştırması son derece normal olabilir.

Fakat aynı DBA’nın gece 02:37’de:

SELECT *

FROM CUSTOMER;

Çalıştırması ve birkaç milyon satır okuması farklı değerlendirilmelidir.

Buradaki güvenlik modeli yalnızca sorguya değil şu değişkenlere bakmalıdır:

WHO → Kim?

WHAT → Hangi veri?

WHEN → Ne zaman?

WHERE → Nereden?

HOW → Hangi uygulama?

HOW MUCH → Ne kadar veri?

Örneğin:

Kullanıcı : DBA01

Kaynak IP : 10.10.20.45

Uygulama : SQL Developer

Saat : 02:37

SQL : SELECT * FROM CUSTOMER

Returned Rows : 4.850.000

Data : Customer / PII

Bu olay tek başına veri hırsızlığının kanıtı değildir.

Ancak kesinlikle araştırılması gereken bir anormal veri erişim davranışıdır.

---

3. Veri Çalmak İçin Hacker Olmak Gerekmeyebilir

Veri sızıntısı denildiğinde aklımıza genellikle dışarıdan gelen saldırgan gelir.

Oysa yüksek yetkili kullanıcıların bulunduğu ortamlarda çok daha basit bir senaryo mümkündür.

Bir DBA’nın aşağıdaki tabloya erişim yetkisi olduğunu düşünelim:

CRM.CUSTOMER

Tabloda:

CUSTOMER_ID

NAME

SURNAME

EMAIL

PHONE

NATIONAL_ID

ADDRESS

BIRTH_DATE

Alanları bulunuyor.

DBA operasyonel bir problem nedeniyle sisteme bağlanıyor.

Normalde ihtiyacı:

SELECT CUSTOMER_ID, STATUS

FROM CUSTOMER

WHERE CUSTOMER_ID = 938271;

Olabilir.

Fakat bunun yerine:

SELECT *

FROM CUSTOMER;

Çalıştırıyor.

Sonra sonucu SQL istemcisinden:

Export → CSV

İle dışarı çıkarıyor.

Dosya artık veritabanında değildir.

İşte tam bu noktada Database Activity Monitoring ile Data Loss Prevention dünyaları birbirine bağlanır.

DAM verinin veritabanından nasıl çıktığını, DLP ise çıktıktan sonra nereye gittiğini anlamaya yardımcı olabilir.

---

4. Asıl Risk: Yetkili Kullanıcı

Dış saldırganın önce sisteme girmesi gerekir.

Yetkili kullanıcı ise zaten içeridedir.

Özellikle:

• DBA hesapları,
• Uygulama yöneticileri,
• Servis hesapları,
• Raporlama kullanıcıları,
• Veri analistleri,
• Destek ekipleri

Geniş veri kümelerine erişebiliyorsa risk daha da büyür.

Bu nedenle:

Authentication bize kullanıcının kim olduğunu söyler. Authorization ne yapabileceğini belirler. Monitoring ise gerçekte ne yaptığını gösterir.

Bir kullanıcının SELECT yetkisinin bulunması, milyonlarca müşteri kaydının çekilmesinin iş gereği olduğu anlamına gelmez.

OWASP da veritabanı hesaplarında Least Privilege (En Az Ayrıcalık) yaklaşımını önerir; hesapların yalnızca ihtiyaç duydukları veritabanı, tablo, kolon veya satırlara erişebilmesi gerektiğini belirtir.

---

5. Data Extraction Nasıl Tespit Edilebilir?

Tek bir SQL sorgusuna bakmak çoğu zaman yeterli değildir.

Davranışın bütününe bakmak gerekir.

Normal bir kullanıcının davranışı şöyle olabilir:

Şüpheli davranış ise şöyle görünebilir:

Burada sorguların her biri ayrı ayrı geçerli SQL komutlarıdır.

Fakat davranış zinciri alışılmışın dışındadır.

Bu nedenle veri güvenliği politikalarında sadece SQL komutuna değil;

returned rows, affected rows, hassas tablo, kullanıcı, kaynak uygulama, saat, kaynak IP, erişim sıklığı ve kullanıcının geçmiş davranışları gibi parametrelere bakılması önemlidir.

---

6. DBA Normalde 100 Satır Okuyorsa Neden Bugün 5 Milyon Satır Okudu?

İşte davranış analitiğinin kritik sorusu budur.

Örneğin bir DBA’nın son 30 günlük davranışı şöyle olsun:

Average Rows / Query : 85

Maximum : 4.200

Working Hours : 08:00–18:30

Typical Client : SQL Developer

Typical DB : CRMDB

Bir gece şu olay gerçekleşiyor:

Time : 02:14

Rows : 5.800.000

Table : CUSTOMER

Classification : Highly Sensitive

SQL : SELECT * FROM CUSTOMER

Burada klasik bir imza aramak yerine davranış sapması aranmalıdır.

Risk kabaca şöyle düşünülebilir:

Yüksek yetki + hassas veri + yüksek hacim + alışılmadık saat birleştiğinde olayın önceliği yükselmelidir.

---

7. Database Activity Monitoring Burada Neden Önemlidir?

Veritabanının kendi audit mekanizmaları önemlidir; ancak kurumsal ortamlarda bağımsız Database Activity Monitoring katmanı ayrıca görünürlük sağlar.

IBM’in Guardium mimarisine ilişkin dokümantasyonunda DAM; SELECT, INSERT, UPDATE, DELETE, DROP, CREATE ve ALTER gibi SQL aktivitelerinin izlenmesinin yanı sıra privileged-user ve yüksek riskli hesapların hassas verilere erişiminin incelenmesi bağlamında ele alınmaktadır.

Örneğin bir DAM politikası mantıksal olarak şöyle tasarlanabilir:

Daha yüksek riskli durumlarda:

IBM Guardium tarafında uygunsuz veri erişimi tespit edildiğinde database session’ını sonlandırmaya yönelik S-GATE kontrollerinin de uygulanabildiği IBM tarafından dokümante edilmektedir.

---

8. DAM Tek Başına Yeterli mi?

Hayır.

Çünkü DAM şu noktayı görebilir:

DATABASE

   ↓

SELECT *

   ↓

USER

Fakat veri artık endpoint’e ulaştığında başka bir güvenlik katmanı gerekir.

Örneğin:

Database

    ↓

SQL Developer

    ↓

Export CSV

    ↓

C:\Temp\customer.csv

    ↓

Chrome

    ↓

Personal Cloud Storage

Burada DAM ilk bölümü, Endpoint DLP/Web DLP gibi kontroller ise sonraki bölümü görebilir.

Bu nedenle ideal yapı:

DATA CLASSIFICATION

        ↓

DATABASE ACTIVITY MONITORING

        ↓

BEHAVIOR ANALYTICS

        ↓

ENDPOINT / NETWORK DLP

        ↓

SIEM / SOC

Şeklinde düşünülmelidir.

OWASP da güvenlik loglamasında hassas verilere erişimin, yönetici yetkilerinin kullanımının ve data import/export işlemlerinin izlenmesini önerir.

---

9. Hangi Kontroller Uygulanmalı?

İlk kontrol Least Privilege olmalıdır.

Kullanıcıya:

SELECT * FROM CUSTOMER;

Çalıştırabilecek yetki vermek yerine yalnızca ihtiyacı olan kolonlar bir VIEW üzerinden sunulabilir:

CREATE VIEW CUSTOMER_SUPPORT AS

SELECT

    CUSTOMER_ID,

    NAME,

    SURNAME,

    STATUS

FROM CUSTOMER;

Böylece örneğin:

NATIONAL_ID, CREDIT_CARD, BIRTH_DATE, ADDRESS gibi alanlara erişim baştan sınırlandırılabilir.

OWASP özellikle table-level, column-level ve row-level yetkilendirme ile restricted view kullanımını önerir.

İkinci kontrol ayrıcalıklı kullanıcıların sürekli izlenmesidir.

DBA olması nedeniyle bir kullanıcıyı monitoring kapsamından çıkarmak yerine tam tersine risk bazlı olarak daha yakından izlemek gerekir.

Üçüncü kontrol hassas verinin sınıflandırılmasıdır.

Çünkü:

SELECT * FROM COUNTRY_CODES;

İle:

SELECT * FROM CREDIT_CARD;

Aynı risk seviyesinde değildir.

Güvenlik sistemi verinin ne olduğunu bilmelidir.

Dördüncü kontrol hacim bazlı alarmdır.

Örneğin kurum kendi normal davranışına göre eşikler oluşturabilir:

> 10.000 rows → INFO

> 100.000 rows → WARNING

> 1.000.000 rows → CRITICAL

Ancak sabit eşikler tek başına yeterli değildir. 50.000 kayıt bazı uygulamalar için normal, bazı kullanıcılar için olağanüstü olabilir.

Beşinci kontrol ise DLP entegrasyonudur.

Veritabanından çıkan hassas verinin:

USB, Email, Browser Upload, Cloud Storage, Teams, Clipboard, Network Share üzerinden kurum dışına çıkması ayrıca kontrol edilmelidir.

---

10. “Ama DBA’in Zaten Yetkisi Var”

Veri güvenliğinde en tehlikeli cümlelerden biri budur.

Yetki ile ihtiyaç aynı şey değildir.

CAN ACCESS ≠ SHOULD ACCESS

Bir DBA’nın teknik olarak 50 milyon müşterinin kaydını okuyabilmesi gerekebilir.

Ama bu durum DBA’nın herhangi bir zamanda 50 milyon kaydı çekmesinin normal kabul edilmesi gerektiği anlamına gelmez.

IBM’in güncel Guardium Database Entitlement yaklaşımı da kullanıcıların görevleri için yalnızca gerekli ayrıcalıklara sahip olup olmadıklarının düzenli doğrulanmasına odaklanır.

Bu nedenle doğru soru:

“Bu kullanıcının yetkisi var mı?” değil;

“Bu kullanıcının yaptığı işlem, görevi ve normal davranışı ile uyumlu mu?” olmalıdır.

---

Sonuç: Bazen En Tehlikeli Sorgu En Basit Olandır

Bir veri ihlali her zaman şöyle başlamaz:

Bazen çok daha kısa olabilir:

Ortada exploit olmayabilir.

Şifre çalınmamış olabilir.

Firewall aşılmamış olabilir.

Hatta kullanıcının yaptığı her işlem teknik olarak yetkileri dahilinde olabilir.

Ama milyonlarca müşterinin verisi artık kurum dışında olabilir.

Bu nedenle modern veri güvenliğinin temel yaklaşımı yalnızca erişimi engellemek olmamalıdır.

Aynı zamanda: Erişimi anlamak, davranışı izlemek, anomalileri tespit etmek ve verinin hareketini takip etmek gerekir.

Çünkü bazen bir veri ihlalinin başlangıcı karmaşık bir hacker komutu değil, dünyanın en basit SQL sorgusudur:

SELECT * FROM CUSTOMER;

Seyhan Tekelioğlu