Log Yönetim Sistemlerinin Veritabanı Sistemleriyle İmtihanı

Log yönetim sistemleri birçok farklı ürün, platform, uygulama ve sistemle entegre çalışmak zorundadır. Bu kaynaklardan toplayacağı veriyi birçok yöntem ve protokolü destekleyecek şekilde merkezileştirmelidir. Toplanan kayıtları kendi üzerinde bir veritabanı üzerinde ya da noSQL yapıda tutabilmelidir. Veritabanı kullanılıyorsa ilişkisel metotlar yerine alternatif çözümler, indeksli, bölümlemeli yollara başvurması performans açısından avantajdır. Konumuz kayıtları saklama şekli değil, farklı veritabanlarından hangi yöntemlerle ve nasıl log toplandığıdır. Veritabanı yönetim sistemi olarak birçok ürün ve çözüm karşımıza çıkmaktadır. Geliştirdiğimiz uygulamaların arkasında bunlardan bir ya da birkaçına başvururuz.

Veritabanı sistemleri, verilerin saklanması, sorgulanması, güncellenmesi için geliştirilmiş ürünlerdir. Peki bu veriler üzerinde yapılan aktivitelerin kayıtlarının nasıl tutulması gerektiğine dair her üretici bir çözüm oluşturmuştur. Bu çözümlerin detayları hakkında bir şeyler karalamaya çalışacağım. Temel olarak, Native SQL Bağlantıları, SQL Auditing, Trace Dosyalar, İşletim sistemi günlükleri, dosya sistemi loglama, Ara katman (ODBC/JDBC) bağlantılar kullanılabilir. Bu yöntemlerden her biri Veritabanı sunucusuna ek bir yük getirecektir ve hatta işlemin çokluğu, loglama detayına göre, veritabanını cevap veremez hale getirebilmektedir. Alternatif çözüm olarak veritabanı güvenlik duvarları kullanılır. Bu ürünler veritabanına gelen bağlantı ve sorgu isteklerini önce kendi üzerine çeker, güvenlik tehdidi olmadığına kanaat getirdiği isteği transparan ya da direkt olarak ana sisteme yönlendirir. Bu durum da konumuz dışındadır. Mevcut veritabanı sistemleri üzerine yoğunlaşalım.

MSSQL
Microsoft SQL Veritabanı, SQL Auditleme yöntemiyle hem sunucu hem veritabanı seviyesinde loglama yapabilmektedir. Bu kayıtları, veritabanında audit_trail tablosuna, windows olay günlüklerine yazabilmektedir. Trigger yazılarak bu kayıtlar XML yapısında dosya sistemine çıkarılabilmektedir. C2 auditleme yöntemi ile de SQL Trace dosyalarına da kaydedilebilmektedir. Tablo, şema seviyesinde yapılan her işlem, farklı kullanıcı/gruplar için farklı seviyelerde açılabilir. Bu yöntemlerin her biri için log yönetim sistemleri entegrasyon için farklı çözümler sunmaktadır. CryptoLog audit_trail tablosundan native sql bağlantısı ile logları çeker, event loglarından WMI ya da ajan ile okur, Trace dosyaları için ajan üzerinde trace için geliştirilmiş özel uygulama yöntemini seçer, XML ya da dosya sistemine çıkarılan dosyaları için ise paylaşım veya ajan tercih edilir.

ORACLE
Oracle sunucusuna ve üzerinde tutulan verilere erişim/aktivite kayıtları da birçok yönteme göre saklanabilmekte veya dışarı çıkarılabilmektedir. Genellikle kendi üzerinde DBA_AUDIT_TRAIL tablosunda tutulur. Buradan log çekmek için oracle istemcisi ve düzgün bir sorgunuzun olması gerekir. Yine XML dosyaları halinde dosya sisteminde de saklanabilir. Bu logları işletim sistemine göre ssh, cifs, smbfs yöntemine göre CryptoLog kendi üzerine bağlayıp, okuyup, logu ayrıştırabilir. Oracle audit kayıtlarını Syslog ile de farklı sunuculara gönderebilmektedir.

MYSQL
Mysql 5.0 sürümü öncesinde kısıtlı auditleme özelliği vardır. Genel olarak kendine yapılan bağlantı detaylarını ve çalıştırılan sorgu cümleciğini loglayabiliyordu. Kullanıcı ve işlem tipine göre ayrı tanımlamalar mümkün değildi. Ancak Enterprise Audit Plugin özelliği geliştirildi. Bu sayede farklı işlemlere göre farklı tipte kullanıcılar için audit açılabilmektedir. Log dosyası olarak XML yapısında dosya sistemine kayıt atmaktadır. Log dosyasını alıp işleme log yönetim sisteminin işidir artık.

POSTGRESQL
Auditlemesi en kolay veritabanı sistemi denilebilir. Seviye, çıktı formatı, loglayacağı yer gibi bir çok değişkeni bir konfigürasyon dosyası üzerinden ayarlıyorsunuz. Sonrasında dosya sistemine, syslog sunucusuna, olay günlüğüne (windows işletim sistemi üzerinde koşuyorsa) yazabilmektedir bu kayıtları. Log yönetim sistemi de her yöntemi deneyenilir logu kendine aktarmak için.

IBMDB2
MSSQL ve ORACLE'a göre daha sınırlı seviyede auditleme yapılmaktadır. Ayrıca ilk başta kendi formatında binary aud dosyaları şeklinde tutar. Bu dosyaları okunabilir hale getirmek için db2audit komutunu kullanırsınız. Direkt olarak aud dosyalarını okumak için log yönetim sistemi db2 kütüphanelerini içererek okuma fonksiyonlarını geliştirir.

SYBASE
Veritabanı giriş, çıkış; nesneler üzerinde yapılan işlemler; izin/role değişiklikleri; veri aktarımları detaylıca loglanabilmektedir. Sysaudits tablolarında direkt sorgularla veriler çekilebilmektedir.

BLABLASQL
Tabi ki böyle bir üretici ya da ürün yok :) Her veritabanı sistemi, ara katman olarak veritabanı bağımsız olarak üretilmiş bir protokol için sürücüsünü geliştirir. Katmanlardan ODBC ve JDBC API'leriyle her türlü veritabanına bağlanmanız mümkündür.


Zorluklar

• Veritabanı sistemlerinde auditleme seviyelerini belirlemek zor bir iştir. Hangi kullanıcı hangi nesne üzerinde ne yaptığında kayıt altına alınmaldır? sorusunun cevabını doğru vermek gerekir. Bunun için ilgili Veritabanı Yöneticisi 'nin fikirlerine danışmakta fayda vardır.
• Auditleme işlemi veritabanına fazladan yük getirecektir. Performansı etkilemeden, güvenlik paranoyasına çok fazla düşmeden, orta karar bir yol bulmak gerekir. Performans iyileştirici yöntemleri de es geçmemek lazım.
• Tablolarda tutulan verileri toplarken son kalınan noktaların kaydedilmesi açısından otomatik_artan kolon, kimlik no, zaman damgası, tarih, indeks alanları olmazsa olmazdır. 
• Toplanan verileri tanımak, alarmlamak, raporlamak gibi işlemleri log yönetim sistemi çok iyi yaplmalıdır.