Database Audit ve Log Yönetimi: Kim, Ne Zaman, Hangi Veriye Erişti?

Veritabanı güvenliğinde erişimi kontrol etmek çok önemlidir.

Ancak yalnızca erişimi sınırlandırmak yeterli değildir.

Bir kullanıcının database'e erişmesine izin verildikten sonra şu sorular da cevaplanabilmelidir:

Kim bağlandı?

Ne zaman bağlandı?

Hangi IP adresinden geldi?

Hangi database'e erişti?

Hangi tabloyu okudu?

Hangi veriyi değiştirdi?

Yeni kullanıcı oluşturdu mu?

Yetki verdi mi?

Toplu veri çekti mi?

Audit ayarlarını değiştirdi mi?

Bu soruların cevabı yoksa kurumun database üzerinde gerçek görünürlüğü sınırlıdır.

Bu nedenle modern database security yaklaşımının en önemli parçalarından biri:

Database Audit ve Log Management

süreçleridir.

Database audit, veritabanı üzerinde gerçekleşen güvenlik açısından önemli aktivitelerin kayıt altına alınmasını sağlar.

Log management ise bu kayıtların;

toplanması,

saklanması,

korunması,

analiz edilmesi

ve gerektiğinde araştırılmasını kapsar.

Temel prensip şudur:

Bir database üzerinde kritik işlem yapılıyorsa bu işlem iz bırakmalıdır.

Ancak güçlü bir audit sistemi yalnızca log üretmekle kalmaz.

Bu logların;

merkezi sisteme taşınması,

silinmeye karşı korunması,

doğru zaman bilgisine sahip olması,

yeterli süre tutulması

ve gerçekten analiz edilmesi gerekir.

Database Audit Nedir?

Database Audit, veritabanında gerçekleştirilen kullanıcı ve sistem aktivitelerinin güvenlik ve izlenebilirlik amacıyla kayıt altına alınmasıdır.

Audit kayıtları;

kullanıcı,

zaman,

işlem,

hedef obje,

sonuç

gibi bilgiler içerebilir.

Database Logging ile Database Audit Aynı Şey mi?

Tam olarak değil.

Database logging daha geniş bir kavramdır.

Örneğin;

startup,

shutdown,

performance,

error,

checkpoint

gibi teknik olayları içerebilir.

Audit ise daha çok:

Kim ne yaptı?

sorusuna odaklanır.

Operational Log Nedir?

Database'in teknik çalışmasına ilişkin kayıtlardır.

Örneğin:

Service started

Backup failed

Replication disconnected

Disk error

gibi olaylar operational log kapsamında olabilir.

Security Audit Log Nedir?

Kullanıcı ve güvenlik aktivitelerini kaydeder.

Örneğin:

Login successful

Login failed

User created

Privilege granted

Sensitive table accessed

Query Log Nedir?

Database üzerinde çalıştırılan sorguların kayıt altına alınmasıdır.

Her database için tüm query'lerin kaydedilmesi performans ve storage açısından uygun olmayabilir.

Bu nedenle risk bazlı logging kullanılmalıdır.

Database Audit Neden Kritiktir?

Bir güvenlik olayı gerçekleştiğinde kurum şu soruya cevap vermek zorundadır:

Ne oldu?

Bunu takip eden sorular:

Kim yaptı?

Hangi kullanıcıyla yapıldı?

Hangi sistemden geldi?

Hangi veri etkilendi?

Ne kadar sürdü?

Audit kayıtları bu soruların cevaplanmasını sağlar.

Audit Olmadan Incident Investigation Mümkün mü?

Çok zor olabilir.

Network veya application logları bazı ipuçları sağlayabilir.

Ancak database içerisindeki gerçek aktiviteler bilinmeyebilir.

Database Audit Hangi Amaçlarla Kullanılır?

Başlıca amaçlar:

Security Monitoring

Incident Response

Forensic Investigation

Compliance

Privileged User Monitoring

Data Access Tracking

Fraud Detection

Kimlerin Database Aktiviteleri Audit Edilmeli?

Risk bazlı olarak;

DBA,

privileged user,

application service account,

developer,

support user,

external consultant

aktiviteleri izlenebilir.

DBA Aktiviteleri Neden Özellikle İzlenmeli?

DBA yüksek yetkilere sahiptir.

Veri okuyabilir.

Yetki değiştirebilir.

Kullanıcı oluşturabilir.

Database objelerini değiştirebilir.

Bu nedenle DBA audit database security'nin temel kontrollerinden biridir.

“DBA Güvenilir, Loglamaya Gerek Yok” Yaklaşımı Doğru mu?

Hayır.

Audit yalnızca kötü niyetli çalışanı yakalamak için yapılmaz.

Human error, yanlış işlem ve incident investigation için de gereklidir.

Privileged User Monitoring Nedir?

Yüksek yetkili kullanıcıların database aktivitelerinin özel olarak izlenmesidir.

Privileged Kullanıcı İçin Hangi Olaylar İzlenmeli?

Örneğin:

Privileged login

Role change

User creation

Database configuration change

Sensitive data query

Audit disable

Backup/restore operation

Database Login Audit Nedir?

Kullanıcıların database'e başarılı veya başarısız bağlantılarının kaydedilmesidir.

Successful Login Neden Loglanmalı?

Kritik kullanıcıların hangi saatlerde ve hangi kaynaklardan bağlandığı görülebilir.

Failed Login Neden Daha Kritik Olabilir?

Birden fazla başarısız login;

brute-force,

credential stuffing,

yanlış password,

application configuration error

göstergesi olabilir.

Failed Login Threshold Nedir?

Belirli zaman aralığında oluşan başarısız login sayısına göre alarm üretilmesidir.

Örneğin normalde günde birkaç hata varken bir dakikada yüzlerce başarısız login oluşması anormaldir.

Dormant Account Login Neden Alarm Üretebilir?

Altı aydır kullanılmayan bir hesabın aniden login olması compromise göstergesi olabilir.

Break-Glass Account Kullanımı İzlenmeli mi?

Kesinlikle.

Break-glass hesabının kullanılması yüksek öncelikli security event olmalıdır.

DBA Mesai Dışı Login Alarmı Faydalı mı?

Evet.

Ancak tek başına malicious davranış anlamına gelmez.

On-call veya maintenance olabilir.

Bu nedenle context ile değerlendirilmelidir.

Source IP Loglanmalı mı?

Evet.

Kullanıcının hangi IP adresinden bağlandığını bilmek incident investigation için değerlidir.

Hostname Loglanmalı mı?

Mümkün olduğunda evet.

Kaynak cihazın belirlenmesine yardımcı olur.

Application Name Loglanabilir mi?

Bazı database platformları client application bilgisini kaydedebilir.

Bu normal ve anormal erişimin ayrıştırılmasına yardımcı olur.

Authentication Method Loglanmalı mı?

Mümkün olduğunda evet.

Örneğin;

password,

certificate,

SSO

gibi authentication türleri araştırma için faydalı olabilir.

Session ID Nedir?

Database bağlantısını benzersiz şekilde tanımlayan değerdir.

Bir oturum içerisindeki aktiviteleri ilişkilendirmeye yardımcı olabilir.

Session Start ve End Time Neden Önemlidir?

Kullanıcının database üzerinde ne kadar süre aktif kaldığını gösterir.

DDL Audit Nedir?

DDL:

Data Definition Language

database yapısını değiştiren işlemleri ifade eder.

Örneğin:

CREATE

ALTER

DROP

işlemleri.

DDL İşlemleri Neden Audit Edilmeli?

Çünkü schema değişiklikleri;

application outage,

data loss,

security change

oluşturabilir.

DROP TABLE Kritik Event midir?

Evet.

Production database'de DROP işlemleri yüksek öncelikli audit event olabilir.

CREATE USER Loglanmalı mı?

Kesinlikle.

Yeni kullanıcı oluşturulması database access yüzeyini değiştirir.

GRANT ve REVOKE Loglanmalı mı?

Evet.

Yetkilendirme değişiklikleri security açısından kritik olaylardır.

Role Assignment Neden İzlenmeli?

Bir kullanıcıya privileged role verilmesi privilege escalation olabilir.

DML Audit Nedir?

DML:

Data Manipulation Language

veri üzerinde yapılan işlemleri ifade eder.

Örneğin:

INSERT

UPDATE

DELETE

SELECT

gibi işlemler.

Tüm DML İşlemleri Loglanmalı mı?

Her zaman değil.

Yüksek transaction sistemlerinde devasa log hacmi oluşabilir.

Bu nedenle kritik tablo ve kullanıcılar için risk bazlı audit uygulanabilir.

SELECT Neden Audit Edilmelidir?

Çünkü veri ihlali yalnızca veri değiştirme değildir.

Bir saldırgan hiçbir kayıt değiştirmeden milyonlarca müşteri kaydını okuyabilir.

Sensitive Table Access Nedir?

Hassas veri içeren tablolara yapılan erişimlerdir.

Örneğin;

Customer_PII

Salary

Payment

Health_Data

tabloları.

Sensitive Table Access Nasıl Belirlenir?

Data classification ve discovery süreçleriyle hangi tabloların hassas olduğu belirlenebilir.

Bulk SELECT Nedir?

Normalden çok daha büyük miktarda veri okuyan sorgudur.

Bulk SELECT Neden Şüpheli Olabilir?

Normal kullanıcı 100 kayıt okurken bir anda 5 milyon kayıt çekiyorsa data exfiltration ihtimali değerlendirilebilir.

Her Büyük Sorgu Saldırı mıdır?

Hayır.

Reporting veya ETL işlemleri de büyük veri okuyabilir.

Bu nedenle kullanıcı ve workload baseline'ı önemlidir.

Query Baseline Nedir?

Database'deki normal query davranışının profili oluşturulur.

Örneğin;

hangi account,

hangi saat,

hangi tablolar,

ortalama satır sayısı

bilinir.

Anomaly Detection Database Audit'te Nasıl Kullanılır?

Normal davranıştan önemli sapmalar tespit edilir.

Örneğin:

DBA ilk kez müşteri tablosunu sorguladı.

Service account farklı IP'den bağlandı.

Rapor kullanıcısı DELETE işlemi yaptı.

Database Audit ile DAM Aynı mı?

Hayır.

Database audit genellikle DBMS'nin kendi logging mekanizmasıdır.

DAM ise aktiviteleri merkezi olarak izleyen ve analiz eden ayrı bir güvenlik katmanıdır.

DAM Database Audit'i Tamamlar mı?

Evet.

Özellikle çok sayıda database'in merkezi izlenmesi için güçlü avantaj sağlar.

Database Audit ile SIEM Arasındaki İlişki

Database audit event'leri SIEM'e gönderilebilir.

SIEM farklı güvenlik kaynaklarıyla korelasyon yapabilir.

Örnek SIEM Korelasyonu

EDR:

Credential theft detected.

↓

Firewall:

Application server'dan unusual database connection.

↓

Database Audit:

Privileged login.

↓

DAM:

Bulk customer table read.

↓

SIEM:

Critical incident.

Bu yapı tek bir log kaynağından çok daha güçlü görünürlük sağlar.

Log Correlation Nedir?

Farklı sistemlerden gelen olayların zaman ve context üzerinden ilişkilendirilmesidir.

Database Audit Logları Nerede Saklanmalı?

Sadece database server üzerinde tutulmamalıdır.

Kritik loglar merkezi log server veya SIEM sistemine aktarılabilir.

Audit Log Neden Database Server Dışına Gönderilmeli?

Database compromise olursa saldırgan local logları silebilir.

Merkezi sistemdeki kopyayı değiştirmesi daha zor olur.

Log Tampering Nedir?

Audit kayıtlarının kötü niyetli şekilde değiştirilmesi veya silinmesidir.

Audit Log Integrity Nasıl Korunur?

Örneğin;

append-only storage,

immutable storage,

restricted access,

hashing

kullanılabilir.

Immutable Audit Log Nedir?

Belirli süre boyunca değiştirilemeyen veya silinemeyen audit kayıtlarıdır.

WORM Storage Audit İçin Kullanılabilir mi?

Evet.

Write Once Read Many yaklaşımı log bütünlüğünü destekleyebilir.

Audit Loglara DBA Erişmeli mi?

Okuma ihtiyacı olabilir.

Ancak logları değiştirme veya silme yetkisi mümkün olduğunca sınırlandırılmalıdır.

DBA Audit'i Kapatabilmeli mi?

Bu kritik bir security control'dür.

Mümkün olduğunda audit configuration değişiklikleri ayrıca loglanmalı ve alert üretmelidir.

Audit Disabled Alarmı Neden Önemlidir?

Saldırgan veya insider iz bırakmamak amacıyla audit'i kapatabilir.

Bu nedenle audit disable yüksek severity olay olabilir.

Audit Policy Change Loglanmalı mı?

Evet.

Audit kapsamının daraltılması da güvenlik olayı olabilir.

Database Log Retention Nedir?

Logların ne kadar süre saklanacağını belirleyen politikadır.

Audit Log Ne Kadar Süre Tutulmalı?

Tek bir süre yoktur.

Kurumun;

risk,

regülasyon,

forensic ihtiyacı,

storage kapasitesi

göz önünde bulundurulmalıdır.

Çok Kısa Retention Neden Risklidir?

Saldırı aylar sonra fark edilirse gerekli loglar silinmiş olabilir.

Çok Uzun Retention Sorun Oluşturabilir mi?

Evet.

Storage maliyeti ve privacy gereksinimleri oluşabilir.

Hot, Warm ve Cold Log Storage Nedir?

Hot

Hızlı sorgulanabilen yakın dönem log.

Warm

Daha düşük maliyetli ancak erişilebilir log.

Cold

Uzun dönem arşiv.

Bu model log maliyetini optimize edebilir.

Database Audit Log Boyutu Neden Büyür?

Her query veya her row loglanırsa çok yüksek hacim oluşabilir.

Audit Flood Nedir?

Çok fazla audit event üretilerek log sisteminin aşırı yüklenmesidir.

Audit Performance'ı Etkiler mi?

Evet.

Yoğun audit işlemleri CPU, IO ve storage tüketebilir.

Audit Performance Problemi Nasıl Çözülür?

Audit'i kapatmak yerine;

risk bazlı event selection,

asynchronous logging,

centralized processing

kullanılabilir.

Risk-Based Logging Nedir?

Her olayı eşit seviyede loglamak yerine kritik aktivitelerin önceliklendirilmesidir.

Hangi Database Olayları Genellikle Yüksek Risklidir?

Örneğin:

Privileged Login

User Creation

Role Grant

Audit Disabled

Sensitive Data Export

Mass Delete

Backup Restore

Configuration Change

Database Configuration Change Audit Edilmeli mi?

Evet.

Authentication veya logging configuration değişiklikleri özellikle kritik olabilir.

Database Restart Audit Edilmeli mi?

Evet.

Beklenmeyen restart availability ve security olayının göstergesi olabilir.

Database Shutdown Kim Tarafından Yapıldı Bilinmeli mi?

Kritik production sistemlerde evet.

Backup Operation Audit Edilmeli mi?

Evet.

Çünkü backup production verisinin tam kopyasını oluşturabilir.

Database Backup Download Audit Edilmeli mi?

Kesinlikle.

Backup dosyasının dışarı çıkarılması data exfiltration yolu olabilir.

Restore Operation Audit Edilmeli mi?

Evet.

Özellikle farklı server veya environment'a yapılan restore işlemleri izlenmelidir.

Production Database Test Ortamına Restore Edilirse Alarm Gerekir mi?

Kritik ortamlarda bu işlem kontrollü ve onaylı olmalıdır.

Database Export Operation İzlenmeli mi?

Evet.

CSV, dump veya bulk export hassas veriyi tek dosyada dışarı çıkarabilir.

Stored Procedure Creation Loglanmalı mı?

Evet.

Yeni code database içerisinde çalışmaya başlayabilir.

Trigger Creation Neden Audit Edilmeli?

Trigger veri değişikliklerini otomatik gerçekleştirebilir.

Kötü veya yanlış trigger ciddi etki yaratabilir.

Scheduled Job Audit Edilmeli mi?

Evet.

Database job veya scheduler üzerinden çalışan kodlar kritik olabilir.

Database Link Creation Neden İzlenmeli?

Başka database'e bağlantı oluşturabilir ve saldırı yüzeyini genişletebilir.

Linked Server Neden Audit Edilmeli?

Bir database compromise olduğunda başka server'a pivot riski oluşabilir.

Extension veya Plugin Installation Audit Edilmeli mi?

Evet.

Database'in yeteneklerini ve attack surface'ini değiştirebilir.

Superuser Creation Alarm Üretmeli mi?

Kesinlikle.

Yeni yüksek yetkili user kritik olaydır.

Password Change Loglanmalı mı?

Özellikle privileged account password değişiklikleri audit edilebilir.

Credential Kendisi Loglanmalı mı?

Hayır.

Password ve secret hiçbir zaman loglara plaintext olarak yazılmamalıdır.

SQL Query Loglarında Hassas Veri Bulunabilir mi?

Evet.

Query parametreleri;

TCKN,

password,

token,

credit card

gibi hassas değerler içerebilir.

Log Masking Nedir?

Audit veya application loglarında hassas alanların gizlenmesidir.

Database Query Logging Privacy Riski Taşır mı?

Evet.

Aşırı detaylı logging yeni bir hassas veri deposu oluşturabilir.

Logging ile Data Minimization Birlikte Düşünülmeli mi?

Evet.

Güvenlik için gerekli bilgiler tutulmalı ancak gereksiz kişisel veri loglanmamalıdır.

Parameter Logging Her Zaman Gerekli mi?

Hayır.

Bazı hassas query parametreleri maskelenebilir.

Database Audit Logunda Ne Olmalı?

Örnek alanlar:

Timestamp

User

Source IP

Database

Schema

Object

Action

Result

Session ID

Application Name

Timestamp Neden Kritik?

Farklı sistemlerdeki olayların ilişkilendirilebilmesi için doğru zaman bilgisi gerekir.

Time Synchronization Nedir?

Sunucuların ortak ve doğru zaman kaynağına göre saatlerini senkronize etmesidir.

NTP Nedir?

Network Time Protocol, sistem saatlerinin senkronize edilmesinde kullanılan yaygın protokoldür.

Database ve SIEM Saatleri Farklıysa Ne Olur?

Incident timeline oluşturmak zorlaşır.

UTC Log Kullanmak Faydalı mı?

Büyük ve çok lokasyonlu yapılarda UTC standardizasyon sağlayabilir.

Log Timezone Belirtilmeli mi?

Evet.

Timestamp'ın hangi timezone'a ait olduğu bilinmelidir.

Forensic Timeline Nedir?

Bir incident sırasında olayların kronolojik sıraya dizilmesidir.

Database Forensic Investigation Nedir?

Database üzerindeki olayların audit, log ve diğer deliller üzerinden araştırılmasıdır.

Forensic Investigation'da Hangi Kaynaklar Kullanılır?

Örneğin:

Database Audit

Transaction Logs

Operating System Logs

Application Logs

WAF Logs

EDR Logs

Firewall Logs

SIEM

Transaction Log Forensic Amaçlı Kullanılabilir mi?

Bazı durumlarda transaction değişiklikleri hakkında bilgi sağlayabilir.

Ancak bunun için uygun araçlar ve süreç gerekir.

Database Audit ile Transaction Log Aynı mı?

Hayır.

Transaction log database consistency ve recovery için oluşturulur.

Audit ise security ve accountability amacıyla tasarlanır.

Database Audit Incident Response'ta Nasıl Kullanılır?

Olay sırasında;

compromised account,

accessed tables,

changed data,

event timeline

belirlenebilir.

Incident Sonrası İlk Soru Ne Olmalı?

Hangi account kullanıldı?

Ardından:

Hangi IP'den geldi?

Ne kadar süre aktif kaldı?

Hangi objelere erişti?

Data Breach Scope Nedir?

Yetkisiz erişimin ne kadar veri ve kaç kullanıcıyı etkilediğinin belirlenmesidir.

Audit Log Scope Belirlemeye Yardımcı Olur mu?

Evet.

Özellikle sensitive table ve query activity kayıtları çok değerlidir.

Database Audit Olmadan KVKK İhlal Analizi Zorlaşır mı?

Kişisel veri içeren sistemlerde kimlerin hangi verilere eriştiğinin belirlenmesi zorlaşabilir.

Bu nedenle izlenebilirlik önemli teknik kontroldür.

Database Audit ve KVKK

Database içerisinde kişisel veri bulunuyorsa erişimlerin ve güvenlik olaylarının izlenebilir olması veri güvenliği sürecini destekler.

Audit tek başına uyum sağlamaz ancak teknik güvenlik tedbirlerinin önemli bir parçasıdır.

Database Audit ve ISO/IEC 27001

ISO/IEC 27001 yaklaşımında logging, monitoring, privileged access ve security event management önemli kontrol alanlarıdır.

Database audit bu süreçlerin teknik temelini destekler.

Database Audit ve PCI DSS

Kart verisi bulunan ortamlarda user activity ve privileged access logging özellikle önemlidir.

Database Audit ile Non-Repudiation İlişkisi

Audit kullanıcının yaptığı işlemin sonradan inkâr edilmesini zorlaştırabilir.

Ancak güçlü kimlik doğrulama ve log integrity de gerekir.

Shared Account Non-Repudiation'ı Bozar mı?

Evet.

Aynı account'u birden fazla kişi kullanıyorsa işlemi tek kişiye bağlamak zorlaşır.

Audit ve Kişiye Özel Hesaplar Birlikte Kullanılmalı mı?

Kesinlikle.

Audit'in anlamlı olabilmesi için identity doğru olmalıdır.

Database Audit Architecture Nasıl Kurulabilir?

Örnek:

Database

↓

Native Audit / Activity Logs

↓

Log Collector

↓

SIEM

↓

Correlation & Detection

↓

SOC Investigation

↓

Immutable Archive

Bu mimaride log hem gerçek zamanlı izleme hem uzun dönem forensic amaçla kullanılabilir.

Log Collector Nedir?

Farklı sistemlerden logları toplayıp merkezi platforma gönderen bileşendir.

Log Collector High Availability Olmalı mı?

Kritik ortamlarda evet.

Collector down olursa log kaybı oluşabilir.

Log Buffering Nedir?

SIEM erişilemediğinde logların geçici olarak tutulup bağlantı geri geldiğinde gönderilmesidir.

Log Loss Nasıl Tespit Edilir?

Heartbeat, event count veya sequence kontrolü kullanılabilir.

Audit Pipeline Monitoring Nedir?

Sadece database'in değil log aktarım zincirinin de izlenmesidir.

“Log Gelmiyor” Alarmı Neden Önemlidir?

Hiç security event olmaması ile log kaynağının bozulması aynı görünmemelidir.

Database Log Source Health İzlenmeli mi?

Evet.

SIEM database kaynağından uzun süre event almıyorsa alarm üretebilir.

Audit Configuration Backup Alınmalı mı?

Evet.

Audit policy ve SIEM integration configuration'ları dokümante edilmelidir.

Database Upgrade Sonrası Audit Kontrol Edilmeli mi?

Kesinlikle.

Upgrade sonrası audit configuration değişmiş olabilir.

Failover Sonrası Audit Çalışıyor mu Kontrol Edilmeli mi?

Evet.

Secondary node üzerinde aynı logging seviyesinin aktif olması gerekir.

DR Database Audit Unutulmamalı mı?

Hayır.

DR ortamı aktive edildiğinde aynı audit politikası uygulanmalıdır.

Cloud Database Audit Nasıl Yapılır?

Managed cloud database servisleri;

native audit,

activity log,

cloud monitoring

özellikleri sunabilir.

Bunlar merkezi SIEM'e aktarılabilir.

Cloud Control Plane Log Nedir?

Database servisinin cloud yönetim katmanındaki aktiviteleri gösterir.

Örneğin;

database created,

public access enabled,

backup policy changed

gibi olayları gösterebilir.

Data Plane ile Control Plane Log Farkı Nedir?

Control Plane:

Servisin yönetim işlemleri.

Data Plane:

Database içerisindeki veri erişimleri.

Her ikisi de izlenmelidir.

Cloud IAM Change Database Audit'e Dahil mi?

Evet.

IAM değişikliği database erişim yetkisini değiştirebilir.

Public Access Enabled Olayı Alarm Olmalı mı?

Kritik database için kesinlikle değerlendirilebilir.

Cloud Snapshot Shared Olayı Neden Kritik?

Snapshot başka account ile paylaşılırsa veri sızıntısı riski oluşabilir.

Database Audit ve UEBA

UEBA:

User and Entity Behavior Analytics

kullanıcıların normal davranışını analiz eder.

UEBA Database İçin Ne Yapabilir?

Örneğin;

normal login saatleri,

query hacmi,

erişilen tablolar

üzerinden anomali tespiti yapabilir.

Database User Risk Score Oluşturulabilir mi?

Evet.

Örneğin;

privileged account,

mesai dışı login,

bulk query,

new source IP

gibi event'ler risk skorunu artırabilir.

Detection Rule Nedir?

Belirli davranış gerçekleştiğinde security alert üreten mantıktır.

Örnek Database Detection Senaryoları

• 10 dakikada 100 başarısız DBA login
• Yeni superuser oluşturulması
• Audit policy'nin kapatılması
• İlk kez görülen IP'den privileged login
• Sensitive tabloda olağan dışı bulk SELECT
• Mesai dışı database dump
• Dormant account login
• Production database'in farklı ortamda restore edilmesi

Alert Severity Nasıl Belirlenmeli?

Olay;

account privilege,

database criticality,

data sensitivity,

time,

source

gibi context bilgileriyle değerlendirilmelidir.

Yeni User Creation Her Zaman Critical mı?

Hayır.

Onaylı change olabilir.

Ancak privileged user creation yüksek severity olabilir.

False Positive Nasıl Azaltılır?

Maintenance window, approved service account ve normal workload bilgileri detection rule'lara dahil edilebilir.

Alert Suppression Nedir?

Bilinen ve onaylı aktivitelerde gereksiz alarmın engellenmesidir.

Alert Suppression Riskli mi?

Fazla geniş uygulanırsa gerçek saldırıları gizleyebilir.

Maintenance Window Context Neden Önemlidir?

Gece 03:00'te DBA login normalde şüpheli olabilir.

Ancak planlı patch penceresinde beklenen davranıştır.

Ticket Entegrasyonu Faydalı mı?

Evet.

Audit event'in planlı change ticket ile ilişkili olup olmadığı görülebilir.

Database Audit ile Change Management Birlikte Kullanılmalı mı?

Evet.

Örneğin production schema değişikliği varsa audit kaydı ilgili change kaydıyla eşleşebilmelidir.

“No Ticket, No Change” Yaklaşımı Nedir?

Planlı kritik değişikliklerin resmi change kaydı olmadan yapılmaması yaklaşımıdır.

Audit Event Change Kaydıyla Eşleşmiyorsa Ne Olur?

Yetkisiz değişiklik olasılığı araştırılabilir.

Audit Review Nedir?

Audit logların sadece saklanması değil düzenli olarak analiz edilmesidir.

Audit Log Kim Tarafından Review Edilmeli?

DBA'dan bağımsız security veya SOC ekibi kritik event'leri inceleyebilir.

Daily Audit Review Gerekli mi?

Kritik sistemlerde gerçek zamanlı monitoring daha uygundur.

Düşük riskli sistemlerde periyodik review olabilir.

Real-Time Alerting Hangi Olaylarda Kullanılmalı?

Örneğin:

Audit disabled

New privileged account

Mass deletion

Sensitive database export

Break-glass account usage

Database Audit Report Nedir?

Belirli dönemdeki önemli aktivitelerin özetidir.

Audit Report Neleri İçerebilir?

Successful privileged login

Failed login trend

Permission changes

Sensitive data access

Database configuration changes

Critical alerts

Yönetim Audit Raporunda Ne Görmeli?

Teknik SQL satırlarından ziyade;

risk,

trend,

critical event,

unresolved incident

görmelidir.

Database Audit KPI'ları Nelerdir?

Örneğin:

Audit Coverage

SIEM Integration Coverage

Privileged Activity Coverage

Sensitive Database Coverage

Log Retention Compliance

Critical Alert Response Time

Log Source Availability

Audit Coverage Nedir?

Database'lerin ne kadarında audit mekanizmasının aktif olduğunu gösterir.

Sensitive Database Audit Coverage Nedir?

Kritik ve hassas veri tutan database'lerin yüzde kaçının detaylı audit altında olduğunu gösterir.

SIEM Integration Coverage Nedir?

Database log kaynaklarının yüzde kaçının merkezi SIEM'e aktarıldığını ölçer.

Log Source Availability Nedir?

Audit kaynaklarının ne kadar süre kesintisiz log gönderdiğini gösterir.

Mean Time to Detect – MTTD Database İçin Kullanılır mı?

Evet.

Bir database security olayının oluşması ile tespit edilmesi arasındaki süreyi ölçebilir.

Mean Time to Respond – MTTR Nedir?

Olay tespit edildikten sonra müdahale edilmesine kadar geçen süreyi ölçebilir.

Database Audit Checklist

Kurumsal checklist şu başlıkları içerebilir:

• Login audit aktif mi?
• Failed login izleniyor mu?
• Privileged user aktiviteleri loglanıyor mu?
• User/role değişiklikleri kaydediliyor mu?
• DDL işlemleri izleniyor mu?
• Sensitive table access loglanıyor mu?
• Backup/restore aktiviteleri izleniyor mu?
• Audit disable alert var mı?
• Loglar SIEM'e gönderiliyor mu?
• Loglar değiştirilmeye karşı korunuyor mu?
• Time synchronization doğru mu?
• Log retention tanımlı mı?
• Hassas veriler loglarda maskeleniyor mu?
• DR ortamı da audit altında mı?
• Audit pipeline health izleniyor mu?

DBA Audit Checklist

DBA açısından:

Audit service aktif mi?

Logging disk kapasitesi yeterli mi?

Audit configuration baseline'a uygun mu?

Critical tables tanımlı mı?

Failover node'larında audit açık mı?

SOC Database Audit Checklist

SOC açısından:

Database log source healthy mi?

Privileged login alarmı var mı?

New admin rule aktif mi?

Bulk query detection var mı?

Audit disabled alarmı var mı?

Database alerts incident process'e bağlı mı?

Database Audit için Yönetimin Sorması Gereken Sorular

Yönetim şu sorulara cevap alabilmelidir:

Kritik database'lerimizin kaçı audit altında?

DBA işlemleri izleniyor mu?

Database logları merkezi SIEM'e gidiyor mu?

Audit loglarını DBA silebilir mi?

Hangi kullanıcı hangi müşteri verisini görüntülediğini belirleyebilir miyiz?

Bir database export edilirse alarm alıyor muyuz?

Loglarımız ne kadar süre saklanıyor?

Son database audit incelemesi ne zaman yapıldı?

Database Audit'te En Sık Yapılan Hatalar

Kurumlarda sık görülen hatalar şunlardır:

• Audit'i tamamen kapalı tutmak
• Sadece error log toplamak
• Successful login'leri izlememek
• DBA aktivitelerini loglamamak
• Shared DBA account kullanmak
• Sensitive SELECT sorgularını izlememek
• Audit logları aynı server'da tutmak
• DBA'ya log silme yetkisi vermek
• Audit disable işlemini alarm haline getirmemek
• Log retention'ı çok kısa tutmak
• Tüm query'leri kontrolsüz loglayarak performansı bozmak
• Hassas veriyi loglara plaintext yazmak
• Server saatlerini senkronize etmemek
• SIEM entegrasyonu sonrası log source health'i izlememek
• DR ve secondary database'lerde audit'i unutmak

PostgreSQL Audit Yaklaşımı

PostgreSQL tarafında;

connection logging,

disconnection logging,

statement logging,

role activity

gibi kayıtlar değerlendirilebilir.

Daha detaylı auditing için uygun audit mekanizmaları kullanılabilir.

Ancak production ortamında logging seviyesi performans ve privacy etkisi düşünülerek ayarlanmalıdır.

PostgreSQL log_statement Her Zaman Açılmalı mı?

Her ortam için aynı şekilde uygulanmamalıdır.

Yoğun sistemlerde büyük log hacmi oluşturabilir.

Risk bazlı configuration gerekir.

MSSQL Audit Yaklaşımı

Microsoft SQL Server ortamlarında;

SQL Server Audit,

login auditing,

Extended Events

gibi mekanizmalar kullanılabilir.

MSSQL Login Failure Logları Neden Önemlidir?

Brute-force veya yanlış application credential sorunlarını gösterebilir.

Oracle Audit Yaklaşımı

Oracle Database ortamlarında audit mekanizmaları;

login,

privileged operation,

object access

gibi aktivitelerin izlenmesini sağlayabilir.

Unified Auditing Nedir?

Bazı Oracle ortamlarında audit politikalarının merkezi biçimde yönetilmesine yardımcı olan yaklaşımdır.

Vendor Farklı Olsa da Audit Mantığı Aynı mı?

Evet.

Platform değişse de temel sorular değişmez:

Kim?

Ne zaman?

Nereden?

Ne yaptı?

Hangi veri üzerinde?

Başarılı oldu mu?

Örnek Database Security Event Akışı

Bir kullanıcı gece 03:12'de production database'e bağlandı.

Database audit:

Privileged Login

SIEM bunu gördü.

Ardından kullanıcı sensitive customer tablosunda yüksek hacimli SELECT sorgusu çalıştırdı.

DAM normalden 50 kat fazla row erişimi tespit etti.

Sonrasında database export işlemi gerçekleşti.

SIEM bu üç olayı ilişkilendirerek:

Potential Data Exfiltration

alarmı üretti.

SOC incident başlattı.

Bu senaryoda tek başına login logu yeterli olmazdı.

Asıl değer olayların birbirine bağlanabilmesidir.

Bir Milyon Müşteri Kaydı Gece 03:00'te Okunursa Ne Olmalı?

İyi tasarlanmış bir database security mimarisinde şu zincir çalışabilir:

Sensitive Table Access

↓

Bulk Query Detection

↓

User Behavior Deviation

↓

DAM Alert

↓

SIEM Correlation

↓

SOC Investigation

↓

Incident Response

Bu sayede olay saatler veya günler sonra değil, mümkün olduğunca gerçek zamanlı tespit edilebilir.

Sık Sorulan Sorular

Database audit nedir?

Database üzerinde kullanıcıların ve sistemlerin gerçekleştirdiği güvenlik açısından önemli aktivitelerin kayıt altına alınmasıdır.

Database log ile audit arasındaki fark nedir?

Log teknik olayları da kapsar. Audit daha çok kullanıcı aktivitesi ve accountability üzerine odaklanır.

DBA aktiviteleri izlenmeli mi?

Evet. DBA yüksek yetkili kullanıcıdır ve kritik işlemleri audit edilmelidir.

SELECT sorguları audit edilmeli mi?

Hassas veri içeren kritik tablolar için risk bazlı olarak izlenebilir.

Database logları SIEM'e gönderilmeli mi?

Kritik sistemlerde merkezi SIEM entegrasyonu güçlü şekilde önerilir.

Audit logları database server'da tutulabilir mi?

Local kopya bulunabilir ancak kritik logların bağımsız merkezi sisteme gönderilmesi daha güvenlidir.

Audit log retention ne kadar olmalı?

Kurumun risk, operasyon, regulatory ve forensic ihtiyaçlarına göre belirlenmelidir.

Database audit performansı etkiler mi?

Çok yoğun logging etkileyebilir. Bu nedenle risk bazlı ve optimize edilmiş audit policy kullanılmalıdır.

Audit log değiştirilemez olmalı mı?

Kritik ortamlarda log bütünlüğünün korunması ve yetkisiz silmenin engellenmesi önemlidir.

Database Activity Monitoring ile audit aynı mı?

Hayır. Native audit database'in kendi kayıt mekanizmasıdır. DAM ise aktiviteleri merkezi olarak analiz eden güvenlik katmanıdır.

Sonuç: Görmediğiniz Database Aktivitesini Koruyamazsınız

Database güvenliğinde sık yapılan hata yalnızca erişimi kontrol etmeye odaklanmaktır.

Erişim kontrolü elbette kritiktir.

Ancak erişim verildikten sonra kullanıcının ne yaptığını bilmiyorsanız görünürlüğünüz eksiktir.

Bu nedenle database security'nin temel prensiplerinden biri şudur:

Authentication tells you who logged in.

Authorization tells you what they are allowed to do.

Audit tells you what they actually did.

Gerçek güvenlik bu üç katmanın birlikte çalışmasıyla oluşur.

Kurumların özellikle;

Privileged Login,

Failed Login,

User Creation,

Role Changes,

DDL Operations,

Sensitive Data Access,

Bulk Queries,

Backup/Restore,

Database Export

ve Audit Configuration Changes

gibi olayları izleyebilmesi gerekir.

Aynı zamanda audit kayıtları sadece üretilmemeli;

merkezi olarak toplanmalı,

SIEM ile analiz edilmeli,

değiştirilmeye karşı korunmalı,

yeterli süre saklanmalı

ve incident response süreçlerinde kullanılmalıdır.

Veritabanı güvenliğinin gerçek testi şu sorudur:

“Bir kullanıcı gece 03:00'te production database'e bağlanıp bir milyon müşteri kaydını sorgularsa bunu fark eder miyiz?”

Eğer cevap:

“Bilmiyoruz.”

ise sorun yalnızca monitoring eksikliği değildir.

Bu aynı zamanda kurumsal database security görünürlüğünün eksik olduğu anlamına gelir.

İyi bir audit mimarisinde cevap:

“Evet; hangi kullanıcı olduğunu, hangi IP'den geldiğini, hangi sorguyu çalıştırdığını, hangi veriye eriştiğini ve olayın diğer güvenlik sistemlerindeki izlerini görebiliriz.”

olmalıdır.

Gerçek Database Audit'in amacı tam olarak budur:

Accountability + Visibility + Detection + Investigation