Ana içeriğe geç

Syslog Entegrasyonu

Loglama Kategorileri​

Apinizer'da loglama mekanizması temel olarak iki ana kategoriye ayrılır:

Trafik Logları

Apinizer üzerinden geçen tüm API trafik bilgilerini içerir ve varsayılan olarak Elasticsearch uygulamasına kaydedilir.

Sistem Logları

Sistemle ilgili işlemleri ve olayları kaydeder. Bunlar varsayılan olarak MongoDB veritabanına atılır.

Sistem Logları Alt Kategorileri​

Sistem Logları kendi içinde beş alt kategoriye ayrılır. Bunlardan dördü Syslog üzerinden harici bir ürüne gönderilebilir:

bilgi

Denetim (Audit), Giriş (Login), Token ve Uygulama loglarının alıcıları artık SIEM ve Log Yönlendirme sayfasından yönetilir. Hedefler, olay tipi ve kapsam filtreleri, gizlilik profili ile boyut politikası oradan hat bazında tanımlanır.

Bu sayfada gösterilen çıktı biçimi Legacy Raw yük profiline karşılık gelir; seçilebilen dört profil için aşağıdaki Yük Biçimleri bölümüne bakınız.

  • Audit Log (Sistem Üzerindeki İşlemler): Apinizer management uygulamasında yapılan değişiklikler ve işlemlerle ilgili loglardır. İsteğe bağlı olarak Yönetim Konsolu/API'lerine yapılan yazma istekleri ve reddedilen istekler de bu kapsama alınabilir; bkz. Denetim Kayıtları.
  • Token Log: Apinizer'ın token sağlayıcı olarak kullanılması durumunda, token alımıyla ilgili logları içerir.
  • Application Log: Apinizer uygulamalarının/modüllerinin yazılımsal loglarıdır. Varsayılan olarak hata (Error) seviyesinde tutulur ve kullanıcılar ihtiyaca göre seviyesini değiştirebilir.
  • Giriş (Login) Denetimi: Başarılı ve başarısız giriş denemeleri, çıkışlar ve proje token yenileme olayları; bkz. Giriş Kayıtları. SIEM ve Log Yönlendirme sayfasında SESSION hattı üzerinden iletilir; bkz. SESSION hattı — olay tipleri ve legacy yük.

Yük Biçimleri​

Her hedef, olayı hedef bazında seçilen tek bir biçimde gönderir:

ProfilAyrıştırıcınıza ulaşan içerik
Legacy RawBugünkü çıktı; dondurulmuştur ve değişmez. Bu sayfada ve Sistem Loglarının Syslog'a Aktarılması sayfasında belgelenen her alan aynen üretilir, mevcut ayrıştırıcılarınız çalışmaya devam eder. Sonraki sürümlerde eklenen alanlar bu çıktıda yer almaz.
Apinizer JSON v2Dört hattın da paylaştığı kanonik zarf: sabit alan sırası, önem derecesi, açık bir sonuç değeri ve token değerleri, parolalar ile kimlik doğrulama başlıklarının yapısı gereği dışarıda bırakıldığı seçilmiş bir data nesnesi.
CEF 0ArcSight Common Event Format söz diziminde tek satır; aynı zarftan, gizlilik profili ve boyut politikası uygulandıktan sonra üretilir. Yalnızca Syslog hedeflerinde seçilebilir; bkz. CEF ve LEEF.
LEEF 2.0IBM QRadar Log Event Extended Format söz diziminde, sekme ayraçlı tek satır; aynı yolla üretilir. Yalnızca Syslog hedeflerinde seçilebilir.

Bu sayfada gösterilen alan listesi Legacy Raw profiline karşılık gelir. Zarfın alan referansı, filtreleme kuralları, gizlilik profili ve boyut politikası SIEM ve Log Yönlendirme sayfasındadır.

Karşılıklı TLS (mTLS) Kurulumu​

Syslog bağlantısı TLS ile kapsüllenirken Apinizer'ın sunucuya bir istemci sertifikası sunması ve sunucunun zincirini kurum sertifika otoritesine göre doğrulaması sağlanabilir. Bu, RFC 5425 çalışan kurumsal SIEM ürünlerinin (QRadar, Splunk, ArcSight ve benzeri) sıklıkla beklediği kurulumdur.

bilgi

Karşılıklı TLS zorunlu değildir. TLS kullanmayan kurumlar düz TCP veya UDP ile çalışmaya devam eder; istemci sertifikası, güven deposu, sunucu adı doğrulaması ve yapılandırılmış veri alanlarının hepsi isteğe bağlıdır ve boş bırakılabilir.

Kurum sertifika otoritesiyle istemci sertifikası üretin

Apinizer'ın syslog sunucusuna sunacağı istemci sertifikasını kurumunuzun sertifika otoritesiyle imzalayınız. Sertifikayı ve özel anahtarını tek parolalı bir PKCS12 paketine koyunuz: Apinizer, kayıttaki tek parolayı hem depo hem de anahtar parolası olarak kullanır.

# 1) İstemci özel anahtarı ve sertifika imzalama isteği (CSR)
openssl req -new -newkey rsa:2048 -nodes \
  -keyout apinizer-gw.key \
  -out apinizer-gw.csr \
  -subj "/CN=apinizer-gw/O=Kurum"

# 2) İsteği kurum sertifika otoritesiyle imzalama
openssl x509 -req -in apinizer-gw.csr \
  -CA kurum-ca.crt -CAkey kurum-ca.key -CAcreateserial \
  -days 825 -sha256 \
  -out apinizer-gw.crt

# 3) Sertifika ve anahtarı tek parolalı PKCS12 paketine koyma
openssl pkcs12 -export \
  -inkey apinizer-gw.key -in apinizer-gw.crt \
  -name apinizer-gw \
  -out apinizer-gw.p12 -passout pass:DEPO_PAROLASI

# 4) Kurum kök sertifikasını güven deposu olarak paketleme
keytool -importcert -noprompt -alias kurum-ca \
  -file kurum-ca.crt \
  -keystore kurum-truststore.p12 -storetype PKCS12 \
  -storepass DEPO_PAROLASI

Sunucu adı doğrulamasını kullanacaksanız sunucu sertifikasının alternatif ad (SAN) alanı, bağlantıda gireceğiniz ana bilgisayar adını içermelidir. Hedefi IP adresiyle giriyorsanız o IP'nin de alternatif ad alanında bulunması gerekir.

İstemci sertifikasını Key Store olarak kaydedin

Yönetim → Gizlilik Yönetimi → Key Stores ekranından yeni bir kayıt oluşturarak apinizer-gw.p12 dosyasını ve parolasını yükleyiniz. Adım adım anlatım için Keystore Yönetimi sayfasına bakınız.

Kurum kök sertifikasını güven deposu olarak kaydedin

Aynı ekranda ikinci bir kayıt oluşturarak kurum-truststore.p12 dosyasını yükleyiniz. Güven deposu PKCS12 veya JKS biçiminde olabilir ve yalnızca syslog sunucusunun zincirini doğrulayacak kök sertifikayı taşıması yeterlidir.

bilgi

Bir güven deposu seçildiğinde yalnızca o depo geçerli olur; Java çalışma ortamının varsayılan kök sertifikaları bu depoya eklenmez. Sunucu sertifikanız genel bir sertifika otoritesinden alınmışsa güven deposu alanını boş bırakınız.

Syslog bağlantısını yapılandırın

Connection → Syslog Bağlantısı ekranında hedef bağlantıyı açınız:

  • Syslog Protocol Type alanını TCP yapınız ve portu SIEM'in TLS dinleyicisine göre giriniz (yaygın değer 6514).
  • Syslog SSL Enabled anahtarını açınız.
  • Keystore alanında ikinci adımda oluşturduğunuz kaydı seçiniz. Sunucu istemci sertifikası istemiyorsa bu alan boş bırakılabilir.
  • Truststore alanında üçüncü adımdaki kaydı seçiniz.
  • Sunucu Adı (Hostname) Doğrulaması anahtarını kontrol ediniz. Bu anahtar yalnızca ekrandan yeni oluşturulan kayıtlarda açık gelir; sürüm yükseltmesinden gelen ya da APIops üzerinden oluşturulmuş kayıtlarda alan hiç ayarlanmamışsa kapalıdır. Sunucu sertifikasındaki ad hedef adresle eşleşiyorsa açınız.

Alan açıklamalarının tamamı Syslog bağlantısı sayfasındadır.

Test Connection çıktısını okuyun

[Test Connection] butonuna tıklayınız. TLS ile kurulan bağlantılarda sonuç kutusu, el sıkışmanın hangi koşullarda tamamlandığını gösteren bir tanılama satırı içerir:

ok: tls: TLSv1.3 / TLS_AES_256_GCM_SHA384 / peer=CN=siem.kurum.local / clientCert=CN=apinizer-gw (expires 2036-08-31)
  • peer sunucunun sunduğu sertifikadır; clientCert Apinizer'ın sunduğu istemci sertifikasıdır. İstemci sertifikası seçilmemişse bu bölüm clientCert=none olur — sunucu istemci kimlik doğrulaması bekliyorsa bağlantı bu noktada başarısız olmalıdır.
  • Seçilen depolardan biri çözülemezse test açık bir hata mesajı döndürür; bağlantı sessizce düz TLS'e ya da düz TCP'ye düşmez. Aynı davranış üretimde de geçerlidir: o hedefe hiçbir olay gönderilmez ve yaklaşık 30 saniyede bir açıklayıcı bir hata kaydı düşer.
  • Test çerçevesi yapılandırılmış veri taşımaz; sunucu tarafında bu alanı doğrulamak için gerçek bir olay gönderiniz.

Sertifikanın içeriği yenilendiğinde çalışan gönderici havuzu eski materyalle bağlantısını sürdürür. Yenilemeden sonra Syslog bağlantısını yeniden kaydediniz ya da ortamı yeniden dağıtınız.

Syslog sunucusunda istemci kimlik doğrulamasını açın

İstemci sertifikası yalnızca sunucu istediğinde sunulur. Syslog sunucusunda istemci kimlik doğrulaması açık değilse Apinizer'daki Keystore seçimi hiçbir işe yaramaz: sertifika hiç gönderilmez ve bağlantı yalnız sunucu TLS'i olarak kurulur. Bu adım atlanırsa karşılıklı TLS kurulmuş olmaz.

global(
  DefaultNetstreamDriver="gtls"
  DefaultNetstreamDriverCAFile="/etc/rsyslog.d/tls/kurum-ca.crt"
  DefaultNetstreamDriverCertFile="/etc/rsyslog.d/tls/syslog-server.crt"
  DefaultNetstreamDriverKeyFile="/etc/rsyslog.d/tls/syslog-server.key"
)

module(load="imtcp"
  StreamDriver.Name="gtls"
  StreamDriver.Mode="1"
  StreamDriver.AuthMode="x509/name"
  PermittedPeer=["apinizer-gw"]
)

input(type="imtcp" port="6514" SupportOctetCountedFraming="on" maxFrameSize="2000000")

StreamDriver.AuthMode="x509/name" istemci sertifikasının adını PermittedPeer listesiyle karşılaştırır; listedeki değer istemci sertifikasının adıyla (yukarıdaki örnekte apinizer-gw) eşleşmelidir.

RFC 5424 Yapılandırılmış Veri (STRUCTURED-DATA)​

Syslog bağlantısında RFC 5424 Yapılandırılmış Veri (SD) Yaz anahtarı açıldığında, çerçevenin bugüne kadar boş bırakılan yapılandırılmış veri alanı doldurulur. SIEM ayrıştırıcınız olay üstverisini mesaj gövdesine düzenli ifade yazmadan, doğrudan bu alandan okuyabilir.

Örnek bir çerçeve:

<110>1 2026-09-03T10:23:25.922Z gw-1 Apinizer - - [origin software="Apinizer" swVersion="2026.09.2"][timeQuality tzKnown="1"][apinizer@99999 stream="AUDIT" eventType="ENTITY" outcome="SUCCESS" eventId="68493da280f5de2a3c29c975" correlationId="dccababd-16e3-415e-b801-9f6a52b6a28c" severity="3"] {json}

Alanların anlamı:

ElemanNe zaman yazılırİçerik
originYapılandırılmış veri açıkken her zamanÜrün adı ve sürümü. IANA'da kayıtlı bir elemandır, kurum numarası gerektirmez.
timeQualityYapılandırılmış veri açıkken her zamanZaman damgasının saat dilimi bilgisi taşıdığını bildirir.
apinizer@<numara>Yalnızca bağlantıda Kurum Numarası (PEN) doluykenOlay üstverisi: hat, olay tipi, sonuç, olay kimliği, korelasyon kimliği ve önem derecesi.

Kapsam ve sınırlar:

  • Örnekteki 99999 yalnızca bir örnektir. Gerçek değer, Syslog bağlantısındaki Kurum Numarası (PEN) alanına girdiğiniz IANA numarasıdır; alan boşken apinizer@ elemanı hiç yazılmaz ve çerçeve yalnızca origin ile timeQuality taşır.
  • Mesaj formatı RFC 3164 seçildiğinde yapılandırılmış veri kavramı yoktur; anahtar açık olsa bile bir şey yazılmaz. Aynı biçimde UDP yolunda da yazılmaz.
  • Legacy Raw yük profilinden geçen kayıtlarda olay üstverisi bulunmadığı için apinizer@ elemanı üretilmez; bu yolda yalnızca origin ve timeQuality yazılır.
  • Çerçevenin mesaj kimliği (MSGID) alanı bu sürümde her zaman boş (-) kalır; olay kimliği yapılandırılmış veri içinde taşınır.
  • Yapılandırılmış veri yalnızca üstveri taşır. Olay gövdesi, aktör bilgisi ve bağlantıdaki mesaj ana bilgisayar adı bu alana hiçbir zaman yazılmaz; gövde mesajın kendisinde kalır.
  • Anahtar kapalıyken çerçeveler sürüm yükseltmesi öncesiyle bayt düzeyinde aynıdır; mevcut ayrıştırıcılarınız etkilenmez.

Bölünmüş Mesajları Birleştirme​

Bir Syslog connection'ında Maksimum Mesaj Boyutu (Bayt) ayarlandığında, bu boyutu aşan bir kayıt alıcıya tek mesaj yerine birden fazla syslog mesajı olarak ulaşır — ayarın kendisi ve her parçanın nasıl göründüğü için bkz. Büyük Mesajları Bölme. Yeniden birleştirme alıcı tarafta yapılır; Apinizer'ın alıcının parçaları gerçekten birleştirip birleştirmediğini doğrulamasının bir yolu yoktur.

Her parçanın mesaj gövdesi [chunk i/N id] ile başlar — parçanın sırası, toplam parça sayısı ve o tek kaydın tüm parçalarında ortak olan bir kimlik. Gelen mesajları bu kimliğe göre gruplayın, sıraya göre dizin, öneki kaldırın ve kalan metni sırayla birleştirerek orijinal kaydı elde edin.

uyarı

Bunu herhangi bir JSON ayrıştırma kuralını çalıştırmadan önce yapın. Bir parça, önek dahil, orijinal metnin bir dilimidir — JSON ayrıştırıcınızın kendi başına okuyabileceği bir belge değildir.

rsyslog​

rsyslog'un yerleşik modülleri mesajları içeriğe göre korelasyonlamaz; bu nedenle yeniden birleştirme için küçük bir dış toplayıcı gerekir. Chunk öneki taşıyan mesajları omprog ile bu toplayıcıya yönlendirin; toplayıcı her kimliğin parçalarını bellekte — id'ye göre gruplayıp i'ye göre sıralayarak — i, N'ye ulaşana kadar tutsun, ardından öneksiz, birleştirilmiş sonucu üretip yeniden birleştirilmiş kayıtların ait olduğu yere (bir dosya, başka bir syslog hedefi, SIEM'inizin alım ucu) iletsin.

ruleset(name="apinizerChunks") {
    action(type="omprog" binary="/opt/apinizer/reassemble-chunks.sh" template="RSYSLOG_TraditionalFileFormat")
}

if $msg contains '[chunk ' then {
    call apinizerChunks
} else {
    action(type="omfile" file="/var/log/apinizer.log")
}

Toplayıcı script, her satırı ^\[chunk (\d+)/(\d+) ([^\]]+)\] ile eşleştirerek sırayı, toplamı ve kimliği çıkarır, kimliğe göre tamponlar ve 1'den toplamına kadar her sıra geldiğinde kaydı akışa bırakır. Son parça hiç gelmezse gelen parçaları zaman aşımıyla akışa bırakıp loglayan bir mekanizma ekleyin; böylece kayıp bir parça bir kaydı belleğe süresiz hapsetmez.

Splunk​

Bir alan çıkarımı ve stats toplaması, aramada parçaları yeniden birleştirir:

index=syslog "[chunk "
| rex field=_raw "^\[chunk (?<chunk_i>\d+)/(?<chunk_n>\d+) (?<chunk_id>\S+)\] (?<chunk_body>.*)"
| eval chunk_i=tonumber(chunk_i)
| sort chunk_id, chunk_i
| stats list(chunk_body) as parts by chunk_id
| eval original_message=mvjoin(parts, "")

chunk_i, sıralamadan önce sayıya çevrilir; aksi halde "10" metin olarak "2"'den önce sıralanır. stats list() grup başına en fazla 100 değer tutar — gerçekçi her chunk sayısı için yeterlidir, ama tek bir kaydın yüzlerce parçaya bölündüğü bir durumda bilinmesi gereken bir sınırdır. Üretim hattında aynı gruplamayı zamanlanmış bir aramada veya index-time'da lookup tabanlı bir oturumlama ile yapın; böylece sonrasında çalışan JSON çıkarım kuralları yalnızca tam olarak yeniden birleştirilmiş olayları görür.

Sıkça Sorulan Sorular​

QRadar gibi bir SIEM ürününe log gönderirken yaşanan zorluklar nelerdir?

JSON formatındaki loglarda ilgili parametrelerin bir parser yazılarak ayrıştırılması ve bu şekilde tutulması gerekmektedir. Bu yüzden Apinizer ürünü yöneten/kullanan veya web servislere hakim olan kişilerle birlikte çalışılarak kurum için önemli alanların birlikte belirlenmesi gerekmektedir.

Bazı kullanımlarda tek seferde alınabilecek log kaydının uzunluğu da sorun olabilmektedir. Bu gibi durumlarda syslog entegrasyonu açılırken body alanının sadece belirli karaktere kadarının gönderilmesi de ayarlanabilmektedir.

Syslog üzerinden gelecek Sistem Denetim logları, Kullanıcı Denetim loglarını karşılamakta mıdır?

Hayır, Sistem Denetim logları ile Kullanıcı Denetim logları farklı içeriktedir ve ayrı yapılandırılır:

  • Sistem Denetim Logları: "Kim hangi sayfada ne iş yaptı" yani sistem üzerindeki yapılan değişikliklerle ilgili genel loglardır. Bu sayfada anlatılan Audit Log konnektörü ile gönderilir.
  • Giriş (Login) Denetim Logları: Başarılı ve başarısız giriş denemeleri, çıkışlar ve token yenileme olayları. SIEM ve Log Yönlendirme sayfasındaki SESSION hattı üzerinden gönderilir; bkz. SESSION hattı — olay tipleri ve legacy yük.
  • Test Konsol Kullanımı Denetimleri: Şu an için harici bir uygulamaya gönderilmemektedir.
Giriş (Login) Denetim logları bir Graylog konnektörüne iletilebilir mi?

Evet. Graylog konnektörleri Giriş (Login) Denetim loglarını GELF mesajı olarak alır: kısa mesaj (short message) LogLogin değeridir, Mesaja Ekle (Append to Message) açıkken JSON olay gövdesi full_message alanına yazılır, Özniteliklere Ekle (Append to Attributes) açıkken dolu olan her olay alanı ayrı bir additional field olarak gönderilir. Syslog, Kafka, RabbitMQ, ActiveMQ, Webhook, Elasticsearch ve veritabanı konnektörleri de desteklenir; bkz. SESSION hattı — olay tipleri ve legacy yük.

Yönetim İsteği ve Erişim Reddi denetim olayları hangi alanları ekler?

Denetim Kayıtları sayfasında anlatılan Audit Log ayarı açıldığında, Yönetim Konsolu/API'lerine yapılan yazma istekleri Yönetim İsteği olayı, reddedilen her istek de Erişim Reddi olayı olarak yakalanır. İkisi de mevcut Audit Log yapısına ek niteliğindedir: Sistem Loglarının Syslog'a Aktarılması sayfasında anlatılan alanlar değişmez ve Syslog üzerinden iletilen her denetim olayı artık ayrıca şunları taşır:

  • eventType: Her zaman bulunur — daha önce belgelenmiş değişiklikler için ENTITY, bu iki olay için MANAGER_REQUEST / ACCESS_DENIED.
  • outcome: Her zaman bulunur — SUCCESS, FAILURE veya DENIED.
  • source: Her zaman bulunur — MANAGER, APIOPS, PORTAL veya SYSTEM.
  • clientIp, userAgent, correlationId: Yalnızca istek için biliniyorsa bulunur.

Bir Yönetim İsteği olayı örneği:

2026-09-02T08:14:22.101Z apinizer_demo Apinizer_demo {"id":"690b1a2c3d4e5f6789abcdef","principal":"admin","auditEventDate":"2026-09-02T08:14:22.101Z","state":"CREATED","objectId":"7c9e6679-7425-40de-944b-e07fc1f90ae7","objectName":"POST /api/apiproxy","referenceObjectJson":"{\"httpMethod\":\"POST\",\"path\":\"/api/apiproxy\",\"status\":200,\"durationMs\":184}","className":"MANAGER_REQUEST","eventType":"MANAGER_REQUEST","outcome":"SUCCESS","clientIp":"10.24.5.101","userAgent":"Mozilla/5.0 (Windows NT 10.0; Win64; x64)","correlationId":"7c9e6679-7425-40de-944b-e07fc1f90ae7","source":"MANAGER"}

Bir Erişim Reddi olayı örneği:

2026-09-02T08:16:47.552Z apinizer_demo Apinizer_demo {"id":"690b1a3d4e5f6789abcdef01","principal":"jdoe","auditEventDate":"2026-09-02T08:16:47.552Z","state":"CREATED","objectId":"/api/apiproxy/68493bb680f5de2a3c29c609","objectName":"403 DELETE /api/apiproxy/68493bb680f5de2a3c29c609","referenceObjectJson":"{\"path\":\"/api/apiproxy/68493bb680f5de2a3c29c609\",\"method\":\"DELETE\",\"problemTitle\":\"Forbidden\"}","className":"ACCESS_DENIED","eventType":"ACCESS_DENIED","outcome":"DENIED","clientIp":"10.24.5.212","userAgent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7)","source":"MANAGER"}

Audit Log için yapılandırılmış bir veritabanı (DB) konnektörü yalnızca Sistem Loglarının Syslog'a Aktarılması sayfasında gösterilen orijinal kolon kümesini yazar; yukarıdaki ek alanlar yalnızca JSON tabanlı konnektörler (Syslog, Kafka, Webhook, Elasticsearch) üzerinden kullanılabilir.

Log Aktarım Yapılandırması​

API trafik ve sistem loglarının syslog'a aktarılması için aşağıdaki sayfaları ziyaret edebilirsiniz:

Trafik Logları Aktarımı

Trafik loglarının syslog'a aktarım ayarları

Sistem Logları Aktarımı

Sistem loglarının syslog'a aktarım ayarları

SIEM ve Log Yönlendirme

Hedefler, hat başına filtre kuralları, gizlilik ve boyut politikaları

En son tarihinde güncellendi