PRINCIPAL DATA SECURITY CONSULTANT

IBM Guardium’u Sıfırdan Anlamak

22 min read

Veritabanı güvenliği, mimarisi, çalışma mantığı ve operasyonları

Hazırlayan: Seyhan Tekelioğlu


1. Guardium nedir?

Bir bankada çalıştığınızı düşünün.

Bankanın binlerce müşterisi, yüzlerce çalışanı ve milyonlarca finansal işlemi var. Bu işlemlerin büyük bölümü veritabanlarında gerçekleşiyor.

Bir müşteri hesabındaki bakiyeyi öğrenmek istiyor. Bir banka çalışanı müşteri bilgilerini görüntülüyor. Bir uygulama para transferi yapıyor. Bir raporlama sistemi binlerce müşterinin bilgilerini sorguluyor.

Peki banka şu soruların cevaplarını biliyor mu?

  • Hangi kullanıcı hangi veritabanına bağlandı?
  • Hangi müşteri bilgilerini görüntüledi?
  • Hangi tabloda işlem yaptı?
  • Ne zaman yaptı?
  • Hangi bilgisayardan bağlandı?
  • Normalde erişmemesi gereken bir veriye erişti mi?
  • Bir kullanıcı gece saat 03.00’te binlerce müşterinin bilgilerini sorguladı mı?

İşte IBM Guardium bu sorulara cevap verebilmek için kullanılan güvenlik çözümlerinden biridir.

IBM Guardium, veritabanlarında gerçekleşen aktiviteleri izleyen, analiz eden, kayıt altına alan ve şüpheli davranışları tespit etmeye yardımcı olan bir veritabanı güvenlik platformudur.

Guardium’un temel görevi veritabanında kimin ne yaptığını görebilmektir.

Örneğin:

Bir kullanıcı veritabanına bağlandı ve aşağıdaki SQL sorgusunu çalıştırdı:

SELECT * FROM MUSTERILER;

Bu sorgu basitçe müşteri tablosundaki kayıtları görüntülemek anlamına gelir.

Guardium, yapılandırılmış izleme mekanizması sayesinde bu aktiviteyi yakalayabilir ve şu bilgileri kayıt altına alabilir:

  • Kullanıcı: Seyhan
  • Veritabanı: BANKA_DB
  • Tablo: MUSTERILER
  • İşlem: SELECT
  • Tarih: 11.11.2026
  • Kaynak: 10.10.10.25
  • SQL: SELECT * FROM MUSTERILER

Böylece kurum, veritabanında gerçekleşen işlemler hakkında denetlenebilir bir kayıt elde eder.

Kısacası Guardium, veritabanının güvenlik kamerası gibidir.

Ancak bu kamera sadece görüntü kaydetmez. Gelen aktiviteleri analiz eder, belirlenen kurallarla karşılaştırır ve gerektiğinde alarm üretebilir veya desteklenen yapılandırmalarda işlemi engelleyebilir.

2. Neden Guardium kullanılır?

Bir şirketin veritabanlarında çok değerli bilgiler bulunur:

  • Müşteri bilgileri
  • T.C. kimlik numaraları
  • Kredi kartı bilgileri
  • Maaş ve personel bilgileri
  • Finansal kayıtlar
  • Ticari sırlar
  • Şirketin gizli iş verileri

Bu bilgilerin korunması yalnızca veritabanına şifre koymakla sağlanamaz.

Çünkü bir kullanıcının veritabanına erişim yetkisi olması, yaptığı her işlemin güvenli olduğu anlamına gelmez.

Örneğin bir veritabanı yöneticisi teknik olarak tüm müşteri kayıtlarına erişebiliyor olabilir.

Ancak bu yöneticinin gece yarısı binlerce müşterinin bilgilerini sorgulaması normal midir?

Guardium bu tür davranışların görünür olmasını sağlar.

Başlıca kullanım amaçları:

  1. Aktivite izleme: Veritabanında kim, ne zaman, ne yaptı?
  2. Denetim: Kullanıcıların işlemlerini geriye dönük inceleyebilmek.
  3. Anomali tespiti: Normal davranıştan farklı aktiviteleri belirlemek.
  4. Politika uygulama: Belirli işlemleri izlemek, alarm üretmek veya desteklenen durumlarda engellemek.
  5. Uyumluluk: KVKK, PCI DSS ve benzeri denetim gereksinimlerine yönelik kanıt üretmek.
  6. Raporlama: Yönetim, bilgi güvenliği ve denetim ekiplerine anlamlı sonuçlar sunmak.

Önemli bir ayrıntı: Guardium veritabanı kullanıcılarının yetkilerini yöneten bir veritabanı yönetim sistemi değildir. Veritabanının kendi erişim kontrollerinin yerini almaz. Bu kontrolleri tamamlayan bir güvenlik katmanı olarak düşünülmelidir.

3. Önce veritabanını anlayalım

Guardium’u anlamak için önce çok basit bir veritabanı örneğine bakalım.

Bir şirketin müşteri bilgilerini sakladığı bir veritabanı olduğunu düşünelim.

Bu veritabanının içerisinde MUSTERILER adında bir tablo bulunsun.

IDADSOYADBAKIYE
1SeyhanTekelioğlu25.000
2AyşeDemir40.000
3MehmetKaya15.000

Buradaki tabloyu Excel dosyasındaki bir sayfa gibi düşünebilirsiniz.

Veritabanında çalışan kullanıcılar bu bilgilere SQL adı verilen komutlarla erişir.

En sık karşılaşacağımız dört temel işlem:

SELECT – Bilgi okumak

SELECT * FROM MUSTERILER;

Müşteri tablosundaki bilgileri görüntüler.

INSERT – Yeni bilgi eklemek

INSERT INTO MUSTERILER VALUES (…);

Yeni müşteri kaydı ekler.

UPDATE – Mevcut bilgiyi değiştirmek

UPDATE MUSTERILER SET BAKIYE=30000 WHERE ID=1;

Seyhan’ın bakiyesini değiştirir.

DELETE – Bilgi silmek

DELETE FROM MUSTERILER WHERE ID=1;

Seyhan’ın kaydını siler.

Guardium’un izlediği aktivitelerin önemli bir bölümünü bu işlemler oluşturur.

Bir kullanıcı sadece bilgi okumaz. Bilgi ekleyebilir, değiştirebilir, silebilir veya veritabanının yapısını değiştiren işlemler gerçekleştirebilir.

Guardium’un görevi, bu aktiviteleri yapılandırılmış kurallara göre izlemek ve kayıt altına almaktır.

4. Guardium nasıl çalışır?

Şimdi en önemli konuya geldik.

Bir kullanıcı veritabanına bağlandığında Guardium bu işlemi nasıl görür?

Önce basit bir örnek:

Bir banka çalışanı, bilgisayarındaki uygulama üzerinden müşteri hesabını görüntülemek istiyor.

Bu uygulama veritabanına bir SQL sorgusu gönderiyor.

Guardium’un çalışma mantığını şu şekilde düşünebiliriz:

Kullanıcı → Uygulama → Veritabanı sunucusu → S-TAP → Collector

Burada S-TAP, veritabanı sunucusundaki aktiviteleri izleyen yazılım ajanıdır.

S-TAP tarafından iletilen trafik Guardium Collector üzerinde analiz edilir.

Collector gelen aktiviteyi inceler, ilgili kuralları değerlendirir ve yapılandırmaya bağlı olarak kayıt oluşturur veya alarm üretir.

Bu sürecin temel adımları şöyledir:

  1. Kullanıcı uygulamaya giriş yapar.
  2. Uygulama veritabanına bağlantı kurar.
  3. Veritabanına SQL komutu gönderilir.
  4. S-TAP, yapılandırılmış izleme mekanizması üzerinden ilgili aktiviteyi yakalar.
  5. Aktivite Collector’e iletilir.
  6. Collector üzerindeki Inspection Engine aktiviteyi analiz eder.
  7. Policy kuralları değerlendirilir.
  8. Aktivite kayıt altına alınır.
  9. Gerekiyorsa alarm veya başka bir politika aksiyonu uygulanır.
  10. Kayıtlar raporlar üzerinden incelenebilir.

Burada önemli bir ayrıntı var:

Guardium’un her kurulumunda bütün SQL içeriklerinin aynı şekilde yakalandığını varsayamayız. İzleme yöntemi, veritabanı platformu, S-TAP yapılandırması, policy ayarları ve hassas veri maskeleme tercihleri sonucu etkiler.

5. Guardium mimarisi: Sistemin parçaları

Guardium’u büyük bir şirketin güvenlik organizasyonu gibi düşünebiliriz.

Her bileşenin ayrı bir görevi vardır.

Başlıca bileşenler:

  • S-TAP
  • GIM
  • Collector
  • Aggregator
  • Central Manager
  • Inspection Engine
  • Policy
  • Archive
  • Export
  • Reporting

Şimdi bunları tek tek inceleyelim.

5.1 S-TAP: Veritabanının yanındaki gözlemci

S-TAP, Guardium’un en önemli bileşenlerinden biridir.

İzlenecek veritabanının bulunduğu sunucuya kurulan yazılım ajanıdır.

Görevi, veritabanı aktivitelerini izlemek ve ilgili verileri Guardium Collector’e iletmektir.

S-TAP’ı bir güvenlik kamerasının sensörüne benzetebiliriz.

Kamera görüntüyü kaydeden merkez sisteme nasıl bilgi gönderiyorsa S-TAP da izlediği veritabanı aktivitelerini Collector’e gönderir.

Örneğin:

BANKA_DB sunucusuna S-TAP kuruldu.

Seyhan isimli kullanıcı müşteri tablosunu sorguladı.

S-TAP bu aktiviteyi izleme mekanizması üzerinden yakaladı ve Collector’e iletti.

Önemli: S-TAP veritabanının kendisi değildir. Veritabanının çalışmasını sağlayan uygulama da değildir. Veritabanı sunucusunda çalışan bir izleme bileşenidir.

S-TAP nasıl log toplar?

Bu konu genellikle yeni başlayanların kafasını karıştırır.

S-TAP’ın yaptığı işi, veritabanının oluşturduğu klasik metin log dosyalarını okuyup merkeze göndermek şeklinde düşünmemek gerekir.

Guardium S-TAP, desteklenen platformlarda veritabanı iletişimini izleyen mekanizmalar kullanır.

Platforma ve yapılandırmaya bağlı olarak:

  • Veritabanı ile istemci arasındaki iletişimi gözlemler.
  • İlgili veritabanı aktivitelerini yakalar.
  • Trafiği analiz edilmek üzere Collector’e iletir.
  • Collector’ün aktiviteyi yorumlamasına yardımcı olacak bilgileri taşır.

Bazı ortamlarda S-TAP, veritabanı sunucusundaki işletim sistemi seviyesindeki izleme mekanizmalarından yararlanır.

Bazı ortamlarda ise farklı izleme yöntemleri ve bileşenleri kullanılabilir.

K-TAP nedir?

K-TAP, bazı platformlarda S-TAP’ın trafik yakalama işlevine yardımcı olan kernel seviyesindeki bileşendir.

Kernel, işletim sisteminin çekirdeğidir.

İşletim sisteminin donanım ve süreçlerle ilgili temel işlemlerini yönetir.

K-TAP’ı, güvenlik kamerasının görüntüyü doğrudan kaynağından almasına yardımcı olan bir sensör gibi düşünebiliriz.

Her platformda aynı şekilde kullanılmaz. Desteklenen işletim sistemi, veritabanı ve S-TAP mimarisine bağlıdır.

A-TAP nedir?

A-TAP, desteklenen platformlarda veritabanı süreci seviyesinde izleme yapılmasını sağlayan alternatif bir izleme yaklaşımıdır.

K-TAP ile aynı şey değildir.

Hangi yöntemin kullanılacağı veritabanı platformuna ve kurulum tasarımına bağlıdır.

Önemli: K-TAP ve A-TAP bütün Guardium kurulumlarında birlikte bulunmak zorunda değildir.

5.2 GIM: Ajanların kurulum ve yönetim merkezi

GIM, Guardium Installation Manager anlamına gelir.

Görevi, Guardium ajanlarının kurulumunu ve yönetimini kolaylaştırmaktır.

Örneğin 100 veritabanı sunucunuz olduğunu düşünün.

Her sunucuya tek tek bağlanarak S-TAP kurmak, sürüm yükseltmek ve konfigürasyon değiştirmek oldukça zahmetlidir.

GIM bu işlemleri merkezi olarak yönetmeye yardımcı olur.

GIM mimarisinde:

  • GIM Server Guardium sistemi üzerinde çalışır.
  • GIM Client izlenecek sunucularda bulunur.
  • Server ve Client birbirleriyle iletişim kurar.
  • Kurulum, güncelleme ve konfigürasyon işlemleri merkezi olarak yürütülebilir.

Bir benzetme yapalım:

100 bilgisayara aynı programı kurmanız gerekiyor.

Her bilgisayara tek tek gitmek yerine merkezi yazılım dağıtım sistemi kullanırsınız.

GIM de Guardium ajanlarının dağıtımı ve yönetimi için benzer bir kolaylık sağlar.

Ancak GIM’in görevi veritabanı aktivitelerini toplamak değildir. Bu işin temel sorumlusu S-TAP’tır.

5.3 Collector: Verilerin toplandığı ve analiz edildiği merkez

Collector, Guardium mimarisinin en önemli merkezlerinden biridir.

S-TAP ajanlarından gelen aktiviteleri alır.

Gelen verileri analiz eder, policy kurallarını değerlendirir ve kayıt altına alır.

Collector’ı bir güvenlik operasyon merkezine benzetebiliriz.

Güvenlik kameralarından gelen görüntüler bir merkeze ulaşır. Merkez bu görüntüleri inceler, olayları kaydeder ve gerekli durumlarda uyarı oluşturur.

Guardium’da bu görevleri Collector üstlenir.

Collector’ın başlıca görevleri:

  • S-TAP aktivitelerini almak.
  • Gelen trafiği analiz etmek.
  • SQL aktivitelerini anlamlandırmak.
  • Policy kurallarını uygulamak.
  • Audit verilerini saklamak.
  • Raporların çalışmasını sağlamak.
  • Alarm ve uyarıları üretmek.

Önemli bir ayrıntı:

Collector sadece veri depolayan bir sunucu değildir. Gerçek zamanlı izleme ve analiz işlevlerinin de merkezidir.

5.4 Inspection Engine: Gelen trafiği anlayan analiz motoru

S-TAP’ın Collector’e gönderdiği verinin anlamlandırılması gerekir.

İşte Inspection Engine burada devreye girer.

Inspection Engine, izlenecek veritabanı platformunu ve ilgili instance’ları tanımlayan yapılandırmanın parçasıdır.

Gelen veritabanı trafiğinin incelenmesinde rol oynar.

Örneğin:

S-TAP Collector’e bir aktivite gönderdi.

Inspection Engine bu aktivitenin hangi veritabanı türü ve instance ile ilgili olduğunu değerlendiren izleme mekanizmasının parçasıdır.

Burada önemli ayrım:

Inspection Engine ayrı bir fiziksel Guardium sunucusu veya S-TAP gibi bağımsız bir ajan değildir.

Collector üzerindeki izleme ve analiz mimarisinin bir parçasıdır.

Bir S-TAP üzerinde birden fazla Inspection Engine yapılandırılabilir.

5.5 Aggregator: Birden fazla Collector’ın verilerini birleştiren merkez

Büyük şirketlerde tek bir Collector yeterli olmayabilir.

Örneğin bir holding düşünelim:

  • İstanbul’da 10 veritabanı sunucusu, 2 Collector’de tutuluyor.
  • Ankara’da 15 veritabanı sunucusu, 3 Collector’de tutuluyor.
  • İzmir’de 8 veritabanı sunucusu, 2 Collector’de tutuluyor.

Her bölge için, veritabanı sayısına göre ayrı ayrı Collectorler konumlandırıldığını varsayalım.

Bu durumda 7 Collector bulunur.

Peki yönetim bütün şirketin veritabanı aktivitelerini tek bir yerden görmek isterse ne olacak?

Aggregator burada devreye girer.

Aggregator, farklı Collector’lardan gelen verileri birleştirerek merkezi raporlama imkânı sağlar.

Basit bir örnek:

Collector 1-2: İstanbul verileri

Collector 3-4-5: Ankara verileri

Collector 6-7: İzmir verileri

Aggregator: İstanbul + Ankara + İzmir verilerinin bir araya getirildiği merkez.

Böylece yönetim tek bir rapor üzerinden tüm bölgelerdeki veritabanı aktivitelerini inceleyebilir.

Önemli bir ayrıntı:

Aggregator normal mimaride S-TAP’lardan doğrudan trafik toplayan bir Collector değildir. Collector’lardan aktarılan verileri birleştirir.

Ayrıca Aggregation işlemi kayıtları basitçe özetlemek anlamına gelmez. Guardium, aktarılan kayıtları hedef sistemin veri deposuna birleştirir.

5.6 Central Manager: Guardium sistemlerinin yöneticisi

Büyük Guardium mimarilerinde çok sayıda Collector ve Aggregator bulunabilir.

Bunların ayrı ayrı yönetilmesi zorlaşır.

Central Manager, Guardium sistemlerinin merkezi yönetimini sağlayan özel işlevdir.

Örneğin:

  • 10 Collector
  • 2 Aggregator
  • 1 Central Manager

Bulunan bir yapı düşünelim.

Central Manager üzerinden yönetilen birimler merkezi olarak takip edilebilir.

Başlıca görevleri:

  • Yönetilen sistemlerin merkezi yönetimi
  • Ortak tanım ve yapılandırmaların yönetimi
  • Patch ve güncelleme süreçlerinin koordinasyonu
  • Kullanıcı ve erişim yönetimi
  • Merkezi yönetim operasyonları

Önemli: Central Manager, Collector gibi tüm veritabanı trafiğini toplayan sistem değildir.

Ayrıca Central Manager işlevi Aggregator ile aynı kurulum seçeneğini paylaşabilir. Bu nedenle mimari tasarımda bu rollerin nasıl konumlandırılacağı önemlidir.

6. Guardium Policy: Sistem neyi izleyeceğini nasıl bilir?

Guardium’un güçlü yönlerinden biri Policy mekanizmasıdır.

Policy, Guardium’a hangi aktivitelerin izleneceğini ve hangi koşullarda ne yapılacağını söyleyen kurallar bütünüdür.

Bunu bir güvenlik görevlisine verilen talimatlar gibi düşünebiliriz.

Örneğin:

  • Gece 22.00’den sonra müşteri tablosuna erişimleri izle.
  • DBA kullanıcılarının yaptığı işlemleri kayıt altına al.
  • Belirli hassas tablolara erişildiğinde alarm oluştur.
  • Bir uygulama kullanıcısının normal dışı davranışlarını takip et.
  • Belirli koşullarda desteklenen engelleme mekanizmasını uygula.

Bir Policy genel olarak kurallardan ve bu kurallara bağlı aksiyonlardan oluşur.

Örnek Policy

Bir banka, müşteri tablosuna yapılan erişimleri takip etmek istiyor.

Kural:

Tablo = MUSTERILER

İşlem = SELECT

Aksiyon:

  • Aktiviteyi kaydet.
  • Belirlenen koşullarda alarm üret.

Sonuç:

Müşteri tablosuna erişen kullanıcıların aktiviteleri takip edilebilir.

Burada önemli nokta şudur:

Guardium yalnızca belirli bir SQL komutunu değil, yapılandırılmış koşullara göre kullanıcı, veritabanı, nesne, istemci ve başka kriterleri de değerlendirebilir.

Policy tasarımı Guardium’un verimli çalışması için kritik öneme sahiptir.

Yanlış veya gereğinden geniş bir Policy, çok fazla kayıt oluşmasına ve sistem kaynaklarının gereksiz kullanılmasına neden olabilir.

7. Guardium’da veriler nasıl kaydedilir?

S-TAP aktiviteyi yakaladı.

Collector aktiviteyi analiz etti.

Policy kuralları değerlendirildi.

Peki bu bilgiler nerede tutuluyor?

Guardium, aktiviteleri kendi veri deposunda kayıt altına alır.

Bu kayıtlar daha sonra raporlama, denetim ve analiz amacıyla kullanılır.

Bir aktivite kaydında yapılandırmaya ve aktivitenin türüne bağlı olarak şu bilgiler bulunabilir:

  • Kullanıcı adı
  • Veritabanı adı
  • Veritabanı sunucusu
  • Erişen uygulama
  • İstemci IP adresi
  • İşlem türü
  • SQL bilgisi
  • Erişilen nesne
  • Tarih ve saat
  • İlgili oturum bilgileri

Örneğin bir kullanıcı aşağıdaki işlemi gerçekleştirdi:

UPDATE MUSTERILER SET BAKIYE=50000 WHERE ID=2;

Guardium bu aktiviteyi yapılandırmaya bağlı olarak kaydedebilir.

Daha sonra denetçi şu soruyu sorabilir:

“11 Kasım günü Ayşe isimli kullanıcı müşteri bakiyelerinde değişiklik yaptı mı?”

Guardium raporları üzerinden bu aktivite araştırılabilir.

8. Export ve Aggregation: Veriler nasıl merkezileştirilir?

Şimdi birden fazla Collector bulunan mimaride verilerin nasıl taşındığına bakalım.

Collector kendi üzerinde topladığı verileri Aggregator’a aktarabilir.

Bu işleme Export denir.

Export, kaynak Guardium sistemindeki verilerin belirlenen tarih aralığına göre dışarı aktarılmasıdır.

Guardium Data Protection mimarisinde tipik olarak günlük veri aktarımı planlanabilir.

Örnek:

Collector İstanbul’da çalışıyor.

Aggregator Ankara’da çalışıyor.

Her gece Collector, önceki güne ait verileri Export işlemiyle hazırlar.

Veriler sıkıştırılmış ve şifrelenmiş dosyalar halinde Aggregator’a gönderilir.

Aggregator ise kendi planlanan Import işlemiyle bu dosyaları alır ve kendi veri deposuna aktarır.

Süreç:

  1. Collector günlük verileri toplar.
  2. Export işlemi çalışır.
  3. Aktarılacak veriler hazırlanır.
  4. Veriler şifrelenmiş dosya halinde gönderilir.
  5. Aggregator Import işlemini gerçekleştirir.
  6. Veriler Aggregator üzerinde birleştirilir.
  7. Merkezi raporlama yapılabilir.

Burada Export ile Aggregation aynı şey değildir.

Export: Veriyi kaynak sistemden dışarı aktarma işlemidir.

Import: Aktarılan veriyi hedef sisteme alma işlemidir.

Aggregation: Alınan verileri hedef sistemin veri deposuna birleştirme işlemidir.

Bir benzetme:

Üç farklı şubeden gelen günlük evraklar düşünün.

Export, evrakların hazırlanıp gönderilmesidir.

Import, evrakların merkez ofise ulaşmasıdır.

Aggregation ise evrakların merkez ofisin kayıt sistemine işlenmesidir.

Önemli teknik ayrıntı: Export ve Import işlemlerinin başarılı olması için iki sistemin gerekli iletişim ve güvenlik ayarlarının doğru olması gerekir. Örneğin System Shared Secret değerlerinin eşleşmesi önemlidir.

9. Archive: Verilerin güvenli şekilde saklanması

Guardium gün boyunca çok sayıda aktivite kaydı toplar.

Bu kayıtlar zamanla büyür.

Örneğin:

  • Günlük 1 milyon aktivite
  • Aylık 30 milyon aktivite
  • Yıllık milyonlarca aktivite

Bu kadar büyük verinin sürekli aktif sistem üzerinde tutulması hem depolama hem performans açısından yönetilmesi gereken bir konudur.

Archive, Guardium verilerinin belirlenen plana göre arşivlenmesini sağlar.

Bunu şirketin eski dosyalarını arşiv odasına kaldırmasına benzetebiliriz.

Güncel dosyalar çalışma masasındadır.

Eski dosyalar arşiv odasında saklanır.

İhtiyaç olduğunda arşivden geri alınabilir.

Guardium’da Archive işlemi, ilgili verilerin belirlenen arşivleme mekanizmasıyla saklanmasını sağlar.

Örnek:

Kurum son 60 günlük verileri aktif sistemde tutmak istiyor.

Daha eski kayıtlar arşivlenerek saklanıyor.

Denetim ekibi altı ay önceki bir işlemi araştırmak istediğinde, ilgili arşiv verileri geri yüklenerek inceleme yapılabiliyor.

Burada önemli bir ayrıntı:

Archive, tek başına felaket kurtarma veya sistem yedeği kavramıyla aynı değildir.

Arşivleme planının yanında sistem yedekleme, arşiv dosyalarının güvenliği, saklama süresi ve geri yükleme testleri de ayrıca planlanmalıdır.

Guardium’da Data Archive ve Results Archive gibi farklı arşivleme türleri bulunur.

Data Archive, yakalanan aktivite verileriyle ilgilidir.

Results Archive ise rapor sonuçları, değerlendirme sonuçları ve benzeri denetim çıktıları gibi verileri kapsayabilir.

10. Purge: Eski kayıtların temizlenmesi

Purge, Guardium’da saklama politikası doğrultusunda artık aktif sistemde tutulması gerekmeyen verilerin temizlenmesidir.

Archive ile Purge birbirinin alternatifi değildir.

Bunlar farklı amaçlara hizmet eder.

Bir örnek düşünelim:

Kurumun politikası şu şekilde olsun:

  • Son 60 gün: Aktif sistemde tutulacak.
  • 60 günden eski: Arşivlenecek.
  • Arşivleme doğrulandıktan ve saklama koşulları sağlandıktan sonra: Aktif sistemden temizlenecek.

Burada:

Archive = Saklamak.

Purge = Aktif sistemden temizlemek.

Purge sayesinde sistemin disk alanı kontrol altında tutulabilir.

Ancak Purge işlemi dikkatle planlanmalıdır.

Yanlış yapılandırılmış bir Purge işlemi, ihtiyaç duyulan kayıtların aktif sistemden beklenenden erken silinmesine neden olabilir.

Bu nedenle aşağıdaki sorular cevaplanmadan Purge politikası belirlenmemelidir:

  • Veriler kaç gün aktif sistemde tutulacak?
  • Hangi veriler arşivlenecek?
  • Arşivleme başarılı olmadan Purge çalışabilir mi?
  • Denetim gereksinimleri nelerdir?
  • Arşiv verileri ne kadar süre saklanacak?
  • Geri yükleme işlemi düzenli test ediliyor mu?

En önemli kural: Arşivleme ve saklama politikası doğrulanmadan Purge sürecine güvenilmemelidir.

11. Reporting: Guardium bize ne anlatır?

Guardium’un topladığı veriler tek başına çok anlamlı olmayabilir.

Milyonlarca aktivite kaydını tek tek incelemek mümkün değildir.

Bu nedenle Reporting mekanizması kullanılır.

Raporlar, toplanan verileri belirli kriterlere göre süzerek anlamlı hale getirir.

Örneğin:

  • Hangi kullanıcılar müşteri tablolarına erişti?
  • Son 24 saatte hangi veritabanlarında DELETE işlemi yapıldı?
  • Hangi DBA kullanıcıları işlem gerçekleştirdi?
  • Hangi IP adreslerinden bağlantı kuruldu?
  • Belirli bir kullanıcı hangi SQL komutlarını çalıştırdı?
  • Hangi veritabanlarında olağan dışı aktiviteler görüldü?

Guardium’da hazır raporlar bulunur. İhtiyaca göre özel raporlar da hazırlanabilir.

Örnek rapor

Rapor adı: Müşteri Tablosu Erişimleri

Filtreler:

  • Tarih: Son 7 gün
  • Tablo: MUSTERILER
  • İşlem: SELECT
  • Kullanıcı: Tüm kullanıcılar

Sonuç:

KullanıcıİşlemTarih
SeyhanSELECT10.11.2026
AyşeSELECT10.11.2026
MehmetSELECT11.11.2026

Bu rapor sayesinde bilgi güvenliği ekibi müşteri bilgilerine erişimleri inceleyebilir.

Raporlar nerede çalıştırılır?

Tek Collector bulunan bir mimaride raporlar Collector üzerinden çalıştırılabilir.

Birden fazla Collector bulunan mimaride ise Aggregator üzerinden merkezi raporlama yapılabilir.

Böylece farklı sistemlerden gelen veriler tek raporda incelenebilir.

Burada raporun hangi sistem üzerinde çalıştırıldığı önemlidir.

Rapor Collector üzerinden çalıştırılırsa, sadece o Collector’de bulunan veritabanlarının logunu gösterir.

Aggregator üzerinde ilgili veriler henüz bulunmuyorsa raporun eksik sonuç vermesi mümkündür.

12. Alarm ve olay yönetimi

Guardium yalnızca geçmişte ne olduğunu göstermez.

Policy kuralları üzerinden belirli aktiviteler gerçekleştiğinde uyarı oluşturabilir.

Örnek:

Bir veritabanı kullanıcısı gece saat 03.00’te müşteri tablosundan binlerce kayıt sorguluyor.

Kurum bu davranışı riskli olarak değerlendirmiş olsun.

Guardium’da uygun bir Policy tanımlanmışsa ilgili aktivite için alarm oluşturulabilir.

Alarmın gönderileceği hedefler yapılandırmaya bağlıdır:

  • E-posta
  • SNMP
  • SIEM entegrasyonu
  • Diğer desteklenen bildirim mekanizmaları

Alarm mekanizmasının amacı güvenlik ekibinin önemli olaylardan haberdar olmasını sağlamaktır.

Ancak alarm üretmek ile saldırıyı engellemek aynı şey değildir.

Engelleme için ilgili ürün özelliğinin, politika aksiyonunun ve teknik gereksinimlerin ayrıca yapılandırılması gerekir.

13. Guardium tasarımı: Kuruluma başlamadan önce

Guardium kurmak yalnızca bir sanal sunucu oluşturup S-TAP yüklemek değildir.

Önce doğru bir mimari tasarım yapılmalıdır.

Çünkü yanlış tasarlanan bir Guardium ortamı ilerleyen dönemlerde performans, kapasite ve yönetim sorunları oluşturabilir.

Adım 1: İzlenecek veritabanlarını belirleyin

Öncelikle şu sorular cevaplanmalıdır:

  • Kaç veritabanı sunucusu var?
  • Hangi veritabanı platformları kullanılıyor?
  • Kaç veritabanı instance’ı bulunuyor?
  • Hangi sunucular kritik?
  • Hangi sistemler hassas veri içeriyor?

Örneğin:

VeritabanıSunucu sayısı
Oracle20
Microsoft SQL Server15
PostgreSQL10
DB25
Toplam50

Adım 2: Trafik miktarını hesaplayın

50 veritabanı sunucusunun hepsi aynı miktarda trafik üretmez.

Bir sunucu saatte 10 bin işlem gerçekleştirirken diğeri milyonlarca işlem gerçekleştirebilir.

Bu nedenle yalnızca sunucu sayısına bakarak Collector kapasitesi belirlenmemelidir.

Değerlendirilmesi gerekenler:

  • Günlük SQL aktivite sayısı
  • Trafik yoğunluğu
  • Eş zamanlı bağlantılar
  • İzlenecek veri miktarı
  • SQL uzunlukları ve detay seviyesi
  • Saklama süresi
  • Raporlama yükü

Adım 3: Collector mimarisini belirleyin

Küçük ortamlarda tek Collector yeterli olabilir.

Büyük ortamlarda ise birden fazla Collector kullanılması tercih edilebilir.

Örnek:

İstanbul: Collector 1

Ankara: Collector 2

İzmir: Collector 3

Bu tasarımda her Collector kendi sorumluluğundaki veritabanlarını izler.

Adım 4: Aggregator ihtiyacını değerlendirin

Merkezi raporlama ihtiyacı varsa Aggregator konumlandırılır.

Collector’lar günlük verilerini Aggregator’a aktarır.

Böylece kurum genelindeki aktiviteler merkezi olarak incelenebilir.

Adım 5: Central Manager tasarımını yapın

Birden fazla Guardium ünitesinin merkezi yönetimi gerekiyorsa Central Manager planlanır.

Yönetim, patch, kullanıcı ve ortak yapılandırmalar açısından mimari değerlendirilir.

Adım 6: Saklama politikasını belirleyin

Veriler ne kadar süre aktif sistemde tutulacak?

Ne kadar süre arşivlenecek?

Purge ne zaman çalışacak?

Bu soruların cevapları tasarımın başlangıcında verilmelidir.

Adım 7: Ağ ve güvenlik gereksinimlerini belirleyin

S-TAP ile Collector arasındaki iletişim, yönetim bağlantıları, Export/Import trafiği, DNS, sertifikalar ve gerekli portlar kontrol edilmelidir.

Verilerin hangi ağ üzerinden taşınacağı ve nasıl korunacağı belirlenmelidir.

Adım 8: Kapasite ve süreklilik planını oluşturun

Collector ve Aggregator için CPU, RAM, disk ve ağ kapasitesi değerlendirilmelidir.

Önemli Not: Kurulumdan sonra disk kapasitesi arttırılıp azaltılamaz.

Yüksek erişilebilirlik, yedeklilik, yedekleme ve felaket kurtarma ihtiyaçları ayrıca tasarlanmalıdır.

Unutmayın: Guardium tasarımında doğru kapasite planlaması, ürünün sağlıklı çalışmasının temelidir.

14. Kurulumdan canlı kullanıma: Baştan sona

Şimdi bütün süreci bir araya getirelim.

Bir şirketin 20 Oracle veritabanı sunucusunu Guardium ile izlemek istediğini düşünelim.

İşlem sırası:

1. Mimari hazırlık

İzlenecek sunucular belirlenir.

Trafik miktarı hesaplanır.

Collector ve gerekiyorsa Aggregator tasarlanır.

2. Guardium kurulumu

Collector kurulur.

Gerekliyse Aggregator ve Central Manager hazırlanır.

Ağ iletişimi kontrol edilir.

3. GIM kurulumu

İzlenecek veritabanı sunucularına GIM Client kurulur.

4. S-TAP kurulumu

GIM üzerinden veya uygun kurulum yöntemiyle S-TAP yüklenir.

5. S-TAP konfigürasyonu

Collector adresi, iletişim ayarları ve gerekli izleme parametreleri tanımlanır.

6. Inspection Engine tanımları

İzlenecek veritabanı platformu, instance ve ilgili izleme yapılandırmaları oluşturulur.

7. Policy hazırlanması

Hangi kullanıcıların, tabloların ve işlemlerin izleneceği belirlenir.

8. Test

Veritabanında örnek SQL işlemleri gerçekleştirilir.

Guardium üzerinde aktivitelerin görülüp görülmediği kontrol edilir.

9. Raporlama

İlgili raporlar hazırlanır ve sonuçlar doğrulanır.

10. Export ve Aggregation

Merkezi raporlama gerekiyorsa günlük aktarım ve Import süreçleri devreye alınır.

11. Archive ve Purge

Saklama politikası doğrultusunda arşivleme ve temizleme planlanır.

12. Canlı operasyon

Sistem düzenli olarak izlenir, raporlar kontrol edilir, hatalar giderilir ve kapasite takip edilir.

15. Günlük Guardium operasyonları

Guardium kurulduktan sonra iş bitmez.

Asıl önemli olan sistemin sürekli sağlıklı çalışmasını sağlamaktır.

Günlük operasyonlarda kontrol edilmesi gereken başlıca konular:

KontrolNeden önemli?
S-TAP durumuVeritabanı aktiviteleri izleniyor mu?
GIM durumuAjan yönetimi sağlıklı mı?
Collector durumuVeri toplama ve analiz çalışıyor mu?
Inspection Engineİzleme yapılandırması doğru mu?
AggregationVeriler merkeze aktarılıyor mu?
Export/ImportGünlük aktarım tamamlandı mı?
ArchiveArşivleme başarılı mı?
PurgeTemizleme planı doğru çalışıyor mu?
Disk kullanımıDepolama alanı yeterli mi?
CPU/RAMSistem kaynakları yeterli mi?
RaporlarBeklenen kayıtlar raporlarda görülüyor mu?
PolicyKurallar beklenen şekilde çalışıyor mu?

Bir sorun nasıl araştırılır?

Örneğin Aggregator’da dünün verileri görünmüyor.

İlk kontrol edilecek yer doğrudan rapor değildir.

Önce veri akışını kontrol etmek gerekir:

  1. Collector’da ilgili güne ait veri var mı?
  2. Export işlemi başarılı mı?
  3. Export dosyası oluşturulmuş mu?
  4. Dosya Aggregator’a ulaşmış mı?
  5. Import işlemi başarılı mı?
  6. Aggregation tamamlanmış mı?
  7. İlgili rapor doğru tarih aralığında mı çalıştırılmış?

Bu yaklaşım, sorunun hangi aşamada olduğunu bulmayı kolaylaştırır.

16. Gerçek hayattan bir örnek: Bir kullanıcının yaptığı işlem

Artık bütün bileşenleri öğrendik.

Şimdi bir olayı baştan sona takip edelim.

Bir banka çalışanı olan Seyhan, müşteri hesabını görüntülemek istiyor.

Saat 10.00

Seyhan uygulamaya giriş yapıyor.

Saat 10.01

Uygulama BANKA_DB veritabanına bağlanıyor.

Saat 10.02

Aşağıdaki SQL sorgusu çalıştırılıyor:

SELECT * FROM MUSTERILER WHERE ID=100;

Saat 10.02

Veritabanı sunucusunda kurulu S-TAP ilgili aktiviteyi yakalıyor.

Saat 10.02

S-TAP aktiviteyi Collector’e iletiyor.

Saat 10.02

Collector üzerindeki Inspection Engine aktiviteyi analiz ediyor.

Saat 10.02

Policy kuralları değerlendiriliyor.

Müşteri tablosuna erişimlerin izlenmesi gerektiği için aktivite kayıt altına alınıyor.

Günün sonunda

Collector üzerindeki veriler ilgili saklama ve aktarım planına göre işleniyor.

Ertesi gün

Collector günlük Export işlemini gerçekleştiriyor.

Aggregator verileri Import ediyor ve merkezi veri deposuna birleştiriyor.

Bir hafta sonra

Denetim ekibi şu soruyu soruyor:

” Seyhan son bir hafta içerisinde müşteri bilgilerine erişmiş mi?”

Aggregator üzerinde ilgili rapor çalıştırılıyor.

Seyhan’ın yaptığı işlem raporda görüntüleniyor.

Birkaç ay sonra

Kurumun saklama politikası doğrultusunda eski kayıtlar arşivlenmiş ve aktif sistemden temizlenmiş olabilir.

Denetim ihtiyacı oluştuğunda ilgili arşiv verileri geri yüklenerek incelenebilir.

İşte Guardium’un temel çalışma mantığı budur.

17. Sık sorulan sorular

Guardium bir veritabanı mıdır?

Hayır. Guardium, veritabanı aktivitelerini izleyen ve analiz eden bir güvenlik çözümüdür.

Guardium veritabanının içine mi kurulur?

Hayır. S-TAP gibi ajanlar izlenecek veritabanının bulunduğu sunucuya kurulur. Collector, Aggregator ve Central Manager ise ayrı Guardium sistemleridir.

S-TAP olmadan Guardium çalışabilir mi?

Bazı mimarilerde Universal Connector veya External S-TAP gibi alternatif yöntemler kullanılabilir. Ancak klasik veritabanı izleme mimarisinde S-TAP yaygın kullanılan yöntemdir.

Collector ile Aggregator arasındaki fark nedir?

Collector, veritabanı aktivitelerini doğrudan izleyen ve analiz eden sistemdir. Aggregator ise birden fazla Collector’dan gelen verileri birleştirerek merkezi raporlama sağlar.

Central Manager bütün verileri toplar mı?

Hayır. Temel görevi Guardium sistemlerinin merkezi yönetimidir.

Archive ile Purge aynı şey midir?

Hayır. Archive verileri arşivler. Purge ise belirlenen koşullara göre aktif sistemdeki verileri temizler.

Export ile Aggregation aynı şey midir?

Hayır. Export verileri dışarı aktarır. Import verileri hedef sisteme alır. Aggregation ise kayıtları hedef sistemin veri deposunda birleştirir.

Guardium yapılan her işlemi engeller mi?

Hayır. Temel işlevi izleme, analiz ve kayıt altına almadır. Engelleme, uygun özellikler ve politika aksiyonları yapılandırıldığında mümkündür.

Guardium yalnızca Oracle veritabanlarını mı izler?

Hayır. Desteklenen farklı veritabanı platformlarını ve veri kaynaklarını izleyebilir. Desteklenen platform ve sürümler ürünün ilgili sürüm dokümantasyonundan kontrol edilmelidir.

Guardium veritabanı yedeği alır mı?

Hayır. Guardium’un Archive özelliği veritabanının yedeğini almakla aynı şey değildir.

18. Guardium sözlüğü: Bilinmesi gereken terimler

TerimBasit açıklama
DAMDatabase Activity Monitoring – Veritabanı aktivitelerini izleme
S-TAPVeritabanı sunucusundaki izleme ajanı (Software TAP)
GIMAjanların kurulum ve yönetim bileşeni
K-TAPBazı platformlarda kernel seviyesinde trafik yakalama bileşeni (Kernel-TAP)
A-TAPDesteklenen platformlarda alternatif izleme yaklaşımı (Application-TAP)
CollectorAktiviteleri toplayan ve analiz eden sistem
AggregatorCollector verilerini birleştiren sistem
Central ManagerGuardium sistemlerini merkezi yöneten bileşen
Inspection EngineVeritabanı izleme ve analiz yapılandırmasının parçası
Policyİzleme ve aksiyon kuralları
AuditDenetim amacıyla tutulan kayıt ve süreçler
ExportVerilerin kaynak sistemden dışarı aktarılması
ImportAktarılan verilerin hedef sisteme alınması
AggregationVerilerin hedef sistemde birleştirilmesi
ArchiveVerilerin arşivlenmesi
PurgeAktif sistemdeki verilerin temizlenmesi
ReportKayıtların filtrelenerek anlamlı hale getirilmesi
AlertBelirlenen koşullarda oluşturulan uyarı
DatasourceGuardium’da tanımlanan veritabanı kaynağı
InstanceVeritabanı sunucusu üzerindeki belirli veritabanı örneği
SQLVeritabanıyla iletişim kurmak için kullanılan sorgulama dili

SONUÇ: Guardium’u anlamak aslında zor değil

IBM Guardium ilk bakışta çok sayıda bileşeni, ayarı ve teknik terimi olan karmaşık bir ürün gibi görünebilir.

Ancak temel mantığı oldukça basittir:

  • S-TAP aktiviteleri izler.
  • Collector aktiviteleri toplar ve analiz eder.
  • Policy neyin izleneceğini ve hangi aksiyonların uygulanacağını belirler.
  • Aggregator farklı Collector’lardan gelen verileri birleştirir.
  • Central Manager sistemlerin merkezi yönetimini sağlar.
  • Export ve Import verilerin sistemler arasında taşınmasını sağlar.
  • Archive verileri saklar.
  • Purge aktif sistemdeki eski verileri temizler.
  • Reporting toplanan bilgileri anlamlı hale getirir.

Guardium’un bütün mimarisini anlamak için bu işleyişi kavramak yeterli bir başlangıçtır.

Unutmayın: Bir veritabanında kimin ne yaptığını bilmiyorsanız, o veritabanının güvenliğini gerçekten yönetmeniz de oldukça zordur.

Guardium’un sağladığı en önemli değer, veritabanı aktivitelerini görünür, izlenebilir ve denetlenebilir hale getirmesidir.

Bu doküman IBM Guardium Data Protection ürününü başlangıç seviyesinde tanıtmak amacıyla hazırlanmıştır. Teknik özellikler, desteklenen platformlar ve yapılandırma seçenekleri Guardium sürümüne ve kullanılan mimariye göre değişebilir.

Seyhan Tekelioğlu

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir