Oracle Database Audit mi, IBM Guardium mu?

Log Tutmak ile Veriyi Korumak Arasındaki Fark

Veritabanı güvenliği konuşulurken sık karşılaşılan sorulardan biri şudur:

“Oracle zaten audit log üretiyor. Neden ayrıca IBM Guardium kullanalım?”

İlk bakışta oldukça mantıklı bir soru.

Oracle Database kendi içerisinde son derece güçlü audit yeteneklerine sahiptir. Unified Auditing ile kullanıcıların, rollerin, yetkilerin, nesne erişimlerinin, başarısız işlemlerin ve yönetici aktivitelerinin izlenmesi mümkündür. Hatta koşullu audit politikaları oluşturarak hangi işlemlerin kaydedileceğini oldukça detaylı biçimde belirleyebilirsiniz.

O halde neden ayrı bir Database Activity Monitoring (DAM) çözümüne ihtiyaç duyalım?

Çünkü aslında Oracle Audit ile IBM Guardium aynı sorunun iki farklı katmanına bakıyor.

Bunu günlük hayattan basit bir örnekle açıklayalım.

Bir apartmanın girişinde ziyaretçi defteri olduğunu düşünün.

Gelen kişi adını, saatini ve kimi ziyaret ettiğini yazıyor.

Bu audit yaklaşımına oldukça benzer.

Şimdi aynı apartmanda güvenlik kameraları, kartlı geçiş sistemi, merkezi alarm sistemi ve güvenlik görevlisi olduğunu düşünün.

Birisi gece 03:00’te normalde girmemesi gereken bir bölüme girerse sistem bunu fark ediyor, kayıt altına alıyor ve güvenlik merkezine alarm gönderiyor.

Bu ise Database Activity Monitoring yaklaşımına daha yakın.

Her ikisi de güvenlik sağlar.

Ama aynı şeyi yapmazlar.

---

1. Önce Oracle’ın Hakkını Verelim

Oracle’ın native audit mekanizmalarını küçümsemek doğru olmaz.

Oracle Unified Auditing, veritabanında gerçekleşen aktivitelerin oldukça detaylı şekilde kaydedilmesini sağlar. Kullanıcı işlemleri, schema değişiklikleri, oturum açma aktiviteleri, administrative kullanıcı işlemleri, roller, sistem yetkileri ve object-level işlemler audit politikaları ile izlenebilir. Oracle ayrıca koşullu audit politikaları sayesinde gereksiz audit verisinin azaltılmasına olanak sağlar.

Örneğin kritik bir tablo için:

CREDIT_CARD

CUSTOMER

SALARY

PAYMENT

Gibi nesnelere yapılan erişimleri audit edebilirsiniz.

Bir DBA’nın:

DROP TABLE

ALTER USER

GRANT DBA

Gibi kritik işlemlerini de kayıt altına almak mümkündür.

Oracle’ın burada önemli bir avantajı vardır:

Audit mekanizması doğrudan veritabanının içerisindedir.

Oracle kendi dokümantasyonunda database auditing’in ağ üzerinden gerçekleşmeyen aktiviteleri de kapsadığını; doğrudan local login, recursive SQL, dynamic SQL ve stored procedure aktivitelerini de kayıt altına alabildiğini belirtmektedir.

Dolayısıyla Oracle Unified Auditing için:

“Guardium varsa Oracle Audit’e gerek yok.”

Demek de doğru değildir.

İki teknoloji birbirinin birebir alternatifi değildir.

---

2. Peki Bu İzlemenin Database’e Maliyeti Ne?

Güvenlik dünyasında sık karşılaştığımız küçük bir paradoks vardır:

Database’i korumaya çalışırken database’i yavaşlatmak istemeyiz.

Özellikle yoğun transaction alan production sistemlerinde audit politikaları tasarlanırken yalnızca “Neyi kaydetmeliyiz?” sorusu değil, “Bunun sisteme maliyeti ne olacak?” sorusu da sorulmalıdır.

Oracle Native Audit, veritabanının kendi audit altyapısını kullanır. Audit politikalarının kapsamı büyüdükçe daha fazla aktivitenin değerlendirilmesi ve daha fazla audit kaydının oluşturulması gerekir. Oracle da audit politikalarının dikkatli tasarlanmasını, özellikle çok geniş kapsamlı audit politikalarının gereksiz audit verisi oluşturabileceğini belirtmektedir.

Basitçe şöyle düşünebiliriz:

Yani database hem kendi asli görevini yapar hem de audit sürecinin bir bölümünü üstlenir.

Az sayıda ve doğru tasarlanmış audit politikalarında bunun etkisi kabul edilebilir seviyelerde olabilir. Ancak yüksek transaction hacmi bulunan sistemlerde “her şeyi audit edelim” yaklaşımı performans, audit trail büyüklüğü, I/O ve depolama açısından ayrıca değerlendirilmelidir.

Burada IBM Guardium’un mimari yaklaşımı farklıdır.

Guardium S-TAP, database sunucusundaki aktiviteleri gözlemleyerek ilgili trafik ve aktivite bilgilerini Guardium Collector’a gönderir.

Böylece aktivitenin analiz edilmesi, policy değerlendirmesi, raporlama ve uzun dönemli audit verisinin yönetilmesi gibi işlerin önemli bölümü Guardium altyapısına taşınabilir.

IBM’in S-TAP dokümantasyonunda, S-TAP’in CPU kullanımının tipik olarak yaklaşık %2–5 seviyesinde olduğu ve çoğu kurulumda performans etkisinin ihmal edilebilir olduğu belirtilmektedir.

Burada küçük ama önemli bir ayrıntının altını çizmek gerekir:

Bu değer “S-TAP hiçbir koşulda %5’i geçmez” anlamına gelmez.

Gerçek yük;

• Database transaction hacmine,
• İzlenen trafik miktarına,
• Kullanılan inspection engine’e,
• S-TAP konfigürasyonuna,
• Kullanılan database teknolojisine,
• Sunucunun mevcut kaynaklarına

Göre değişebilir.

Bu nedenle doğru ifade:

“Guardium S-TAP, düşük performans etkisi hedeflenerek tasarlanmıştır ve IBM dokümantasyonunda tipik CPU kullanımı yaklaşık %2–5 olarak belirtilmektedir.”

Olmalıdır.

---

3. Aradaki Mimari Fark Neden Önemli?

Bir havaalanı düşünelim.

Pasaport kontrolünden geçen her yolcunun bilgilerini kontrol eden memurun aynı zamanda güvenlik kamerası görüntülerini analiz ettiğini, şüpheli davranışları araştırdığını ve bütün kayıtları arşivlediğini düşünün.

Bir noktadan sonra kuyruk oluşması şaşırtıcı olmazdı.

Daha mantıklı mimari şudur:

Pasaport görevlisi işini yapar, güvenlik sistemi ise gözlemleme ve analiz görevini mümkün olduğunca ayrı yürütür.

Database güvenliğinde de benzer bir yaklaşım değerlidir.

Oracle Native Audit

Guardium Yaklaşımı

Buradaki amaç “Oracle Native Audit database’i yavaşlatır, Guardium yavaşlatmaz” demek değildir.

Böyle bir genelleme teknik olarak doğru olmaz.

Asıl avantaj, Guardium’un izleme ve güvenlik işlemlerinin önemli bölümünü database’in kendisinden ayıran bir mimari sunmasıdır.

Özellikle yüzlerce database’in bulunduğu büyük yapılarda bu fark giderek daha önemli hale gelir.

Çünkü güvenlik sisteminin görevi database’i korumaktır.

Database’in yeni performans problemi olmak değil.

---

4. Problem Nerede Başlıyor?

Şirketinizde yalnızca üç Oracle Database olduğunu düşünelim.

Üçünde de audit policy oluşturduk.

Gayet güzel.

Sonra şirket büyüyor.

Artık ortamda:

30 Oracle

20 Microsoft SQL Server

15 PostgreSQL

10 MySQL

5 MongoDB

Bulunuyor.

Bir de cloud database servisleri ekleniyor.

Artık güvenlik ekibinin sorusu değişiyor.

“Oracle’da ne oldu?”

Yerine:

“Şirketimizin verilerinde ne oluyor?”

Sorusunu sormaya başlıyoruz.

İşte DAM ihtiyacı esas olarak burada ortaya çıkıyor.

IBM Guardium Data Protection, farklı veri kaynaklarındaki aktiviteleri merkezi bir güvenlik katmanında toplamak üzere tasarlanmıştır. IBM çözümü; hassas veri keşfi ve sınıflandırması, aktivite izleme, politika yönetimi, gerçek zamanlı uyarılar, vulnerability assessment ve compliance süreçlerini merkezi bir yaklaşım altında ele alır.

Bu nedenle önemli fark şudur:

Oracle Audit, “database-centric” tir.

Guardium ise “data-security-centric” tir.

---

5. Kamera Kayıt Yapıyor, Peki Biri Kamerayı Kapatırsa?

Burada güvenlik dünyasının klasik problemlerinden biri ortaya çıkıyor:

Separation of Duties – Görevlerin Ayrılığı.

Bir sistemin yöneticisinin aynı zamanda kendi aktivitelerinin audit kayıtlarını tamamen kontrol edebilmesi güvenlik açısından tartışmalı bir durum oluşturabilir.

Bunu banka örneğiyle düşünelim.

Kasayı açabilen kişi ile güvenlik kamerasının kayıtlarını yöneten kişinin aynı kişi olması ne kadar doğru olur?

DBA’nın görevi database’i yönetmektir.

Security ekibinin görevi ise database üzerinde gerçekleşen aktiviteleri denetlemektir.

Bu nedenle ideal senaryoda:

DBA → Database’i yönetir

Security → Database aktivitesini izler

Audit → Bağımsız olarak saklanır

Yaklaşımı tercih edilir.

Guardium’un önemli avantajlarından biri tam olarak bu ayrımı güçlendirmesidir.

S-TAP database server üzerinde çalışan hafif bir monitoring agent’tır ve database ile client arasındaki aktiviteleri Guardium Collector’a iletir. IBM’e göre S-TAP’ın yaklaşık %2–5 olan CPU kullanımı çoğu kurulumda performans etkisi ihmal edilebilir seviyededir.

Böylece audit/security verisi yalnızca ilgili database’in içerisinde kalmak zorunda değildir.

---

6. “SELECT * FROM CUSTOMER” Her Zaman Tehlikeli midir?

Hayır.

Ve işin zor tarafı tam olarak burada başlıyor.

Bir DBA’nın mesai saatleri içerisinde CUSTOMER tablosunda sorgu çalıştırması normal olabilir.

Ama aynı DBA:

02:47 Saatinde bağlanıp:

SELECT *

FROM CUSTOMER;

Çalıştırıyorsa… Ve arkasından:

SELECT *

FROM CREDIT_CARD;

Geliyorsa…

Sonra birkaç milyon kayıt okunuyorsa…

Artık yalnızca “SELECT komutu çalıştırıldı” bilgisi yeterli değildir.

Bağlama ihtiyacımız vardır.

Kim yaptı?

Nereden bağlandı?

Hangi uygulamayı kullandı?

Hangi database’e erişti?

Hangi objeye erişti?

Ne zaman yaptı?

Bu davranış normal mi?

Daha önce bu kullanıcı bunu yaptı mı?

Ve belki en önemlisi:

Bunu gördüğümüzde ne yapacağız?

Guardium’un güvenlik politikaları SQL aktivitelerinin merkezi politikalar üzerinden değerlendirilmesine olanak sağlar. IBM’in güncel Guardium sürümlerindeki hazır güvenlik politikaları SQL injection, OS command injection ve çeşitli şüpheli erişim modellerini tespit etmeye yönelik kurallar da içermektedir.

Dolayısıyla olay yalnızca:

Log → Rapor

Olmaktan çıkar.

Şuna dönüşür:

Aktivite → Politika → Risk → Alarm → Müdahale

---

7. Audit ile Monitoring Arasındaki Kritik Fark

Bence konunun en önemli noktalarından biri burada.

Audit genellikle şu soruya cevap verir:

“Ne oldu?”

Database Activity Monitoring ise bunun yanına başka sorular ekler:

“Şu anda ne oluyor?”

Ve daha önemlisi:

“Bu normal mi?”

Bir güvenlik olayında üç ay sonra mükemmel bir audit raporu hazırlayabiliyor olmak değerlidir.

Ama saldırı devam ederken alarm üretebilmek daha değerlidir.

Guardium database erişimlerini, kullanıcı aktivitelerini ve policy değişikliklerini takip ederek gerçek zamanlı uyarılar üretebilir. IBM ayrıca ürün içerisinde aggregation/archive hatalarından production database’e ilk kez erişen admin kullanıcılarına kadar farklı senaryolar için predefined alert mekanizmaları sunmaktadır.

Bu da bizi klasik güvenlik prensibine getiriyor:

“Detection” ne kadar erken gerçekleşirse müdahale şansı o kadar artar.

---

8. Oracle Audit’in Güçlü Olduğu Yerler

Karşılaştırmayı adil yapmak gerekiyor.

Oracle native audit’in Guardium karşısında önemli avantajları vardır.

Birincisi: Database’i Oracle’dan daha iyi kimse tanıyamaz.

Audit engine database’in içerisindedir.

Bu nedenle database internal aktiviteleri konusunda son derece güçlü “visibility” sağlayabilir.

İkincisi: Ek altyapı ihtiyacı daha düşüktür.

Guardium tarafında Collector, Aggregator, Central Manager, S-TAP, policy, archive ve retention gibi bileşenlerin tasarlanması ve yönetilmesi gerekir.

Oracle Audit zaten database’in bir parçasıdır.

Üçüncüsü: Küçük ortamlar için oldukça pratiktir.

Üç Oracle Database’iniz varsa Guardium altyapısı kurmak her organizasyon için ekonomik veya operasyonel açıdan anlamlı olmayabilir.

Dördüncüsü: Oracle’a özel detaylarda native çözüm avantajlıdır.

Oracle Unified Auditing; RMAN, Data Pump, SQL*Loader, Database Vault ve Oracle’a özgü diğer birçok aktiviteyi audit edebilir.

Dolayısıyla:

Oracle Audit kötü olduğu için Guardium kullanılmaz.

Guardium başka bir ihtiyacı çözdüğü için kullanılır.

---

9. Guardium’un Dezavantajları Yok mu?

Elbette var.

Öncelikle Guardium ayrı bir üründür.

Lisans maliyeti vardır.

Altyapı maliyeti vardır.

Operasyon maliyeti vardır.

S-TAP agent’larının kurulması, güncellenmesi ve izlenmesi gerekir.

Collector ve Aggregator kapasitesi doğru hesaplanmalıdır.

Archive ve retention stratejisi oluşturulmalıdır.

Policy’lerin doğru tasarlanması gerekir.

IBM’in kendi monitoring stratejisi dokümanı da gereksiz miktarda aktivitenin toplanmasının disk, işlem gücü ve network tüketimini artırabileceğini açıkça belirtmektedir.

Başka bir ifadeyle:

“Her şeyi toplayalım, sonra bakarız.”

İyi bir Guardium mimarisi değildir.

Doğru yaklaşım:

“Riskimize göre neyi izlememiz gerekiyor?”

Sorusuyla başlamaktır.

Guardium güçlü bir araçtır ama yanlış policy tasarımı güçlü bir aracı çok pahalı bir log deposuna dönüştürebilir.

Özellikle uygulama üzerinden gelen logların Guardium ile takip edilmesi, çok fazla log akışına dolayısıyla çok fazla işlem yükü ve disk doluluğuna yol açar.

Guardium’da bir motto vardır. “Uygulama, uygulamada loglanır!”

---

10. Kısa Bir Karşılaştırma

Bu tablo “hangi ürün daha iyi?” sorusundan ziyade hangi problemin çözülmek istendiğini göstermektedir.

---

11. Peki Hangisini Kullanmalıyız?

Aslında cevap:

İkisini de.

Doğru enterprise mimarisinde Oracle Audit ile Guardium birbirinin rakibi olmak zorunda değildir.

Şöyle düşünebiliriz:

Oracle Audit bize database’in kendi perspektifinden güçlü bir audit izi sağlar.

Guardium ise bu resmi organizasyon seviyesine taşır.

---

12. Asıl Soru: “Logumuz Var mı?” Değil

Birçok organizasyonda database güvenliği şu cümleyle başlar:

“Loglarımız zaten var.”

Ama güvenlik açısından daha doğru sorular şunlardır:

• Kim bakıyor?
• Ne kadar sürede fark ediyoruz?
• DBA kendi aktivitesini değiştirebilir mi?
• Oracle dışındaki database’leri nasıl izliyoruz?
• Kritik tabloya erişildiğinde güvenlik ekibi ne kadar sürede haberdar oluyor?
• Bir kullanıcı normal davranışının dışına çıktığında bunu görebiliyor muyuz?
• Denetçi altı ay önceki kayıtları istediğinde ne kadar sürede sunabiliyoruz?

Bu soruların cevapları yalnızca database audit mekanizmasına bırakıldığında yönetim giderek zorlaşır.

Guardium’un değeri burada ortaya çıkar:

Database loglarını toplamak değil, database aktivitelerini kurumsal bir güvenlik sürecine dönüştürmek.

IBM bugün Guardium Data Protection’ı yalnızca activity monitoring ürünü olarak değil; discovery, classification, vulnerability assessment, monitoring, threat detection ve compliance süreçlerini kapsayan daha geniş bir data security yaklaşımının parçası olarak konumlandırmaktadır.

---

Sonuç: Güvenlik Kamerası mı, Alarm Sistemi mi?

Oracle Unified Auditing güçlü bir audit mekanizmasıdır.

IBM Guardium güçlü bir Database Activity Monitoring ve Data Security platformudur.

Bu nedenle seçim ihtiyaçlar, yönetim ve maliyete göre yapılmalıdır.

Oracle bize database’in kendi içerisindeki gerçeği anlatırken Guardium farklı database’lerde gerçekleşen aktiviteleri merkezi bir güvenlik perspektifinden değerlendirmemize yardımcı olur.

Ve belki konuyu tek cümlede şöyle özetleyebiliriz:

Audit, dün gece kasayı kimin açtığını söyler.

İyi tasarlanmış bir DAM sistemi ise kasa açılırken güvenlik ekibinin haberdar olmasını hedefler.

Veri güvenliğinde ihtiyacımız olan şey yalnızca geçmişi kaydetmek değil, olan biteni zamanında fark edebilmektir.

Seyhan Tekelioğlu

#IBＭGuardium #OracleDatabase #DatabaseSecurity #DataSecurity #DatabaseActivityMonitoring #DAM #DataProtection #CyberSecurity #InformationSecurity #DataGovernance #DataPrivacy #Audit #Compliance #SIEM #SOC #SiberGüvenlik #VeriGüvenliği #BilgiGüvenliği #VeriKoruma #VeritabanıGüvenliği #SiberGüvenlikFarkındalığı