SIEM ve Log Yönlendirme
Yönetim → Sistem Ayarları → SIEM ve Log Yönlendirme yolunu izleyerek bu ekrana erişebilirsiniz. Ekranı yalnızca Yönetici (Admin) rolüne sahip kullanıcılar açabilir. Değişiklikleri kaydetmek için Kaydet ve Yükle butonuna tıklayınız; kayıt sonrası yapılandırma çalışan ağ geçidi ortamlarına anında iletilir.
Genel Bakış
Denetim, oturum, token ve uygulama olayları için kayıt sistemi Apinizer yapılandırma veritabanıdır. SIEM tarafına yönlendirdiğiniz her şey, korelasyon, alarm ve uzun süreli arşiv amacıyla üretilen bir kopyadır.
Teslim sözleşmesi en iyi çaba (best effort) ilkesine dayanır:
- Olay, onu üreten akış üzerinde konnektöre teslim edilir; konnektör olayı tamponlar ve gönderir.
- Konnektörün kuyruğu dolduğunda olaylar düşürülür; olayı üreten isteğin bekletilmesi tercih edilmez.
- UDP ve düz TCP syslog üzerinde "teslim edildi" bilgisi gözlemlenemez. Bu nedenle test butonu syslog hedefleri için Gönderildi değil Kuyruğa alındı sonucunu bildirir.
- Kalıcı bir kuyruktan yeniden gönderim yapılmaz. SIEM erişilemez durumdaysa kayıt Apinizer veritabanında durur, ancak SIEM'e sonradan ulaşmaz.
SIEM kopyasına tek başına dayanan bir uyumluluk kontrolü tasarlamayınız. Kesin yanıt gerektiğinde Apinizer veritabanındaki kayıtları (Denetim Kayıtları, Giriş Kayıtları, Token İstekleri, Uygulama Logları) sorgulayınız; SIEM kopyasını korelasyon ve alarm için kullanınız.
Kavramlar
Hatlar
Hat, tek bir olay ailesidir. Her hattın kendi üreticisi, Apinizer veritabanında kendi koleksiyonu, kendi olay tipleri ve kendi sonuç türetme biçimi vardır.
| Hat | Neyi kaydeder | Apinizer veritabanı koleksiyonu | Olay tipleri | Sonuç |
|---|---|---|---|---|
| Denetim (Audit) | Yönetimsel değişiklikler, Yönetim Konsolu istekleri, reddedilen istekler, hassas erişim olayları (gizli değer görüntüleme, dışa aktarma, API token yaşam döngüsü, PII maskesi kaldırma) ve operasyon olayları (dağıtım, API Promotion yaşam döngüsü, ACL verme/geri alma) | audit_event | ENTITY, MANAGER_REQUEST, ACCESS_DENIED, SECRET_REVEALED, EXPORT, API_TOKEN_CREATED, API_TOKEN_REVOKED, PII_UNMASK, DEPLOY, UNDEPLOY, PROMOTION_REQUESTED, PROMOTION_APPROVED, PROMOTION_REJECTED, PROMOTION_STARTED, PROMOTION_EXECUTED, PROMOTION_CANCELLED, ACL_GRANT, ACL_REVOKE | SUCCESS, FAILURE, DENIED |
| Oturum (Session) | Yönetim Konsolu ve API Portal giriş, çıkış, token yenileme, hesap kilitleme ve parola yaşam döngüsü olayları | persistent_audit_event | LOGIN_SUCCESS, LOGIN_FAILURE, LOGOUT, TOKEN_REFRESH_SUCCESS, TOKEN_REFRESH_FAILURE, ACCOUNT_LOCKED, PASSWORD_CHANGED, PASSWORD_CHANGE_REQUIRED, PASSWORD_POLICY_VIOLATION | Olay tipinden türetilir; ACCOUNT_LOCKED için DENIED, PASSWORD_POLICY_VIOLATION için FAILURE |
| Token | Ağ geçidinde token üretimi, yenilenmesi ve reddi | log_tokentraffic | TOKEN_ISSUED, TOKEN_REFRESHED, TOKEN_REJECTED | Hata yoksa SUCCESS, varsa FAILURE; kimlik doğrulama hataları DENIED |
| Uygulama (Application) | Yönetim Konsolu, ağ geçidi, önbellek ve entegrasyon modüllerinin bileşen logları | apinizer_log | LOG.TRACE … LOG.ERROR | WARN ve ERROR için FAILURE, diğerleri SUCCESS |
| API Güvenliği (API Security) | Ağ geçidinde engellenen veya hata veren HTTP, gRPC ve WebSocket istekleri — başarılı istekler hiç kaydedilmez | log_apisecurityevent | AUTHENTICATION, AUTHORIZATION, QUOTA, THROTTLING, VALIDATION, IP_SECURITY, THREAT, ROUTING, GATEWAY, OTHER | Engellenen istek DENIED, hata veren istek FAILURE |
| API Erişimi (API Access) | Ağ geçidinden geçen her istek — başarılılar dâhil — gövdesiz metadata olarak; HTTP, gRPC ve WebSocket trafiğinin tamamı | log_apiaccess | API Güvenliği ile aynı on kategori | Tamamlanan istek SUCCESS, engellenen istek DENIED, hata veren istek FAILURE |
| Portal | API Portal'ın kendi alan olayları — bir uygulamanın kaydedilmesi/silinmesi, bir aboneliğin talep edilmesi/onaylanması/reddedilmesi/iptali, bir organizasyon üyeliği veya katılım talebinin yönetilmesi, bir destek talebinin açılması, kişisel bir API erişim token'ının oluşturulması/iptali | audit_event (Denetim ile aynı koleksiyon — bkz. Portal Olayları) | PORTAL_APP_CREATED, PORTAL_APP_DELETED, PORTAL_SUBSCRIPTION_REQUESTED, PORTAL_SUBSCRIPTION_APPROVED, PORTAL_SUBSCRIPTION_REJECTED, PORTAL_SUBSCRIPTION_CANCELLED, PORTAL_ORG_MEMBER_INVITED, PORTAL_ORG_MEMBER_ADDED, PORTAL_ORG_MEMBER_ROLE_CHANGED, PORTAL_ORG_MEMBER_REMOVED, PORTAL_ORG_JOIN_REQUESTED, PORTAL_ORG_JOIN_APPROVED, PORTAL_ORG_JOIN_REJECTED, PORTAL_TICKET_CREATED, PORTAL_API_TOKEN_CREATED, PORTAL_API_TOKEN_REVOKED | SUCCESS, FAILURE, DENIED |
Portal giriş ve çıkışları Portal hattının parçası DEĞİLDİR — bunlar Oturum (Session) olaylarıdır ve persistent_audit_event yerine ayrı bir koleksiyonda, portal_login_logs'ta fiziksel olarak tutulur. Yukarıdaki Oturum satırındaki PORTAL_LOGIN_SUCCESS, PORTAL_LOGIN_FAILURE, PORTAL_LOGOUT, PORTAL_ACCOUNT_LOCKED, PORTAL_ACCOUNT_UNLOCKED, PORTAL_PASSWORD_CHANGED, PORTAL_PASSWORD_CHANGE_REQUIRED, PORTAL_PASSWORD_RESET_REQUESTED, PORTAL_PASSWORD_POLICY_VIOLATION veya PORTAL_ACCOUNT_DISABLED olay tipi source.component: PORTAL ve data.portalId taşır; böylece bir kural, Yönetim Konsolu girişlerine dokunmadan portal girişlerini seçebilir veya dışlayabilir — tam katalog için bkz. API Portal Giriş Kayıtları (toplam on tip). PORTAL_ACCOUNT_DISABLED şimdilik yalnızca inaktif-hesap görevi tarafından yazılır; PORTAL_ACCOUNT_UNLOCKED yalnızca bir yöneticinin Accounts/Developers ekranındaki açık Unlock işlemiyle yazılır — kilit kendiliğinden dolduğunda kendi olayını üretmez, ardından gelen giriş satırı ne olduğunu anlatır.
API Erişimi hattı istek başına bir olay üretir; yani olay hacmi, arıza sayınızla değil trafik hacminizle birlikte büyür. Hattı iki anahtar yönetir ve ikisi de varsayılan olarak kapalıdır:
- Yerel saklama — olayların
log_apiaccesskoleksiyonuna yazılıp yazılmayacağı; Hatlar sekmesinden açılır. Açarken onay istenir, çünkü o andan itibaren her istek bir veritabanı yazımı demektir. - Yetki (Authority) — hattın bu sayfadaki hedeflerden gönderilip gönderilmeyeceği.
İkisinden birini açmadan önce koleksiyona kısa bir saklama süresi tanımlayın — önerilen aralık 3-7 gündür — bunu Uygulama Logu Temizleme Görevleri sayfasındaki API Access Events satırından yapabilirsiniz; ayrıca hattı yönlendiren kuralda örneklemeyi değerlendirin.
Bir politikanın engellediği veya hatayla sonuçlanan bir istek hem bir API Güvenliği olayı hem bir API Erişimi olayı üretir. İki hattın bu noktada örtüşmesi bilinçlidir: böylece bir hedef, trafiği almadan yalnızca güvenlik olaylarına ya da güvenlik olaylarını çiftlemeden yalnızca trafiğe abone olabilir.
İki hattı da aynı hedefe yönlendiriyorsanız API Erişimi kuralında Sonuçlar alanını SUCCESS yapın. Böylece engellenen ve hata veren istekleri API Güvenliği kuralı, yalnızca başarılı istekleri de API Erişimi kuralı taşır ve hiçbir şey iki kez sayılmaz.
İstek/yanıt gövdelerini de içeren tam trafik logları ayrı bir mekanizmadır ve SIEM hatlarına dahil değildir; bunlar ağ geçidi ortamının log konnektörleri üzerinden iletilmeye devam eder. Bir API Erişimi olayı yalnızca metadata'dır; gövde, header veya sorgu dizesi asla taşımaz.
Hedefler
Hedef, bir konnektör ile birlikte olay o konnektöre ulaşmadan önce uygulanan her şeydir:
| Bileşen | Anlamı |
|---|---|
| Konnektör | Yükü taşıyan bağlantı yapılandırması — Syslog, Kafka, Webhook, RabbitMQ, ActiveMQ, Logback, Elasticsearch, Graylog veya bir veritabanı konnektörü. |
| Yük profili | Yükün biçimi. Aşağıya bakınız. |
| Hat kuralları | Hat başına: o hattın bu hedefe gönderilip gönderilmeyeceği ve hangi olaylarının seçileceği. |
| Gizlilik profili | Yük Apinizer'dan çıkmadan önce uygulanan isteğe bağlı maskeleme, hash'leme, silme veya şifreleme. |
| Boyut politikası | İsteğe bağlı en büyük olay boyutu ve sınır aşıldığında yapılacak işlem. |
Bir hat için kuralı olmayan hedef, o hattı hiç almaz. Aynı bağlantı yapılandırması birden fazla hedef tarafından kullanılabilir.
Yük profilleri
| Profil | Ne üretir | Kullanılabildiği yerler |
|---|---|---|
| Legacy Raw | Konnektör tipiniz için bugünkü çıktı, değişmeden — veritabanı konnektörü yine SQL kolonlarını yazar, Graylog konnektörü yine GELF mesajı üretir, Elasticsearch konnektörü yine kendi dokümanını yazar, metin tabanlı konnektörler ise bugün aldıkları JSON'un aynısını alır. Alan listesi dondurulmuştur: sonraki sürümlerde Apinizer'a eklenen alanlar bu çıktıda görünmez. | Tüm konnektör tipleri |
| Apinizer JSON v2 | Şema v2 bölümünde anlatılan kanonik zarf — sabit alan sırası, tipli alan listesi, önem derecesi ve yalnızca o hat için açıkça izin verilen alanları taşıyan bir data nesnesi. | Syslog, Kafka, Webhook, RabbitMQ, ActiveMQ, Logback, Elasticsearch, Graylog |
| CEF 0 | ArcSight'ın CEF 0 sözdiziminde tek satır: boru ayraçlı başlık ve ardından anahtar=değer uzantısı. Alan eşlemesi için CEF ve LEEF bölümüne bakınız. | Yalnızca Syslog |
| LEEF 2.0 | QRadar'ın LEEF 2.0 sözdiziminde tek satır: boru ayraçlı başlık ve ardından sekme ayraçlı anahtar=değer çiftleri. Alan eşlemesi için CEF ve LEEF bölümüne bakınız. | Yalnızca Syslog |
Veritabanı konnektörleri sabit tablo kolonlarına yazdığı için v2 zarfını taşıyamaz; bu hedefler Legacy Raw profilinde kalır. Gizlilik profili ve boyut politikası Legacy Raw dışındaki her profilde uygulanır — CEF ve LEEF satırları da maskelenmiş ve boyutu uygulanmış zarftan üretilir. Maskeleme gereken bir hedefin Legacy Raw dışında bir profile geçirilmesi gerekir.
Elasticsearch hedefi için bağlantıda Cluster Yönetimi anahtarını KAPALI bırakın ve API trafik logundan ayrı bir Indeks Adı verin. Apinizer SIEM index şablonunu oluşturmaz; şablonu, ILM politikasını ve data stream'i Elasticsearch kümesinin sahibi kurum oluşturur ve yönetir. Hazır komutlar için SIEM Hedefleri için Elasticsearch Index Şablonları sayfasına bakabilirsiniz.
Veritabanı hedefi için de aynı ilke geçerlidir: Apinizer tabloları oluşturmaz. Legacy Raw ile yazılan log_AuditEvent, log_LoginLog, log_TokenTraffic ve log_Application tablolarını kurum oluşturur. Komutlar için Apinizer Logları için Tablo Oluşturma Komutları sayfasına bakabilirsiniz.
Legacy Raw, yükseltme sonrası mevcut SIEM ayrıştırıcılarınızın çalışmaya devam etmesi için bayt düzeyinde uyumlu tutulur. Bugün ne gönderiyorsa onu göndermeye devam eder — token logundaki clientInfo gibi alanlar dahil. Alan listesinin özenle seçildiği yer v2 profilidir: token değerleri, parolalar ile Authorization, Cookie ve API anahtarı başlıkları bu profilin parçası hiçbir zaman olmaz, adı kimlik bilgisine benzeyen alanlar ise gönderimden hemen önce ikinci kez elenir.
Yetki
Her hat, iki kaynaktan tam olarak biriyle beslenir ve aralarında hat bazında geçiş yaparsınız:
| Yetki | Hedefler nereden gelir | Kurallar uygulanır mı? |
|---|---|---|
| LEGACY | Daha önce Genel Ayarlar altında yapılandırılmış alıcı listeleri | Hayır — her olay her alıcıya, yükseltme öncesindeki gibi gider |
| ACTIVE | Bu sayfadaki hedefler | Evet — kurallar, yük profili, gizlilik profili ve boyut politikası uygulanır |
Geçiş her iki yönde de anında etkilidir; hatları teker teker taşıyabilir ve olay kaybetmeden geri alabilirsiniz.
Portal hattının düşeceği bir eski (legacy) alıcı listesi yoktur — LEGACY'deyken (yükseltme sonrası varsayılan) on altı alan olayı hiçbir hedefe ulaşmaz. Bunları iletmeye başlamak için ACTIVE'e çevirin. Portal giriş/çıkışları bu anahtardan etkilenmez: onlar Oturum hattının yetkisini izler, bkz. aşağıdaki "Taşıma ve Geçiş Rehberi" bölümü.
Sayfa Turu
Sayfa üç sekmeden oluşur.
Hedefler
Sekmenin en üstünde, kaydedilmiş her hedef için bir teslim sağlığı kartı bulunur; ayrıntısı Teslim Sağlığı bölümündedir. Kartların altındaki hedef listesi; adı, konnektör tipi ile bağlantı yapılandırmasını, yük profilini, o hedefe yönlendirilen her hat için bir rozeti ve hedefin etkin olup olmadığını gösterir. Hedef Ekle hedef penceresini açar; burada şunları yapılandırırsınız:
- Ad, Açıklama ve Etkin anahtarı.
- Konnektör — Konnektör Seç ile Apinizer'ın başka ekranlarında da kullanılan konnektör düzenleyicisi açılır; mevcut bir hedef için Konnektörü Düzenle aynı düzenleyiciyi yeniden açar.
- Yük Profili — liste konnektör tipine göre filtrelenir: CEF 0 ve LEEF 2.0 yalnızca konnektör bir Syslog bağlantısıyken seçilebilir, listenin altındaki açıklama bunu hatırlatır.
- Boyut Politikası — Olay boyutunu sınırla, bayt cinsinden en büyük olay boyutu ve sınır aşıldığında yapılacak işlem.
- Gizlilik Profili — Gizlilik profilini uygula ile birlikte kimlik kurallarını sizin yerinize dolduran Önerilen SIEM profilini uygula butonu.
- Hat Kuralları — her hat için bir bölüm; her biri Bu hattı bu hedefe gönder anahtarıyla başlar. Denetim ve Portal bölümlerinde ayrıca Referans nesnesini yüke ekle (varsayılan kapalı) ve Değişiklik listesini yüke ekle (varsayılan açık) içerik anahtarları, Uygulama bölümünde ise Hata yığınını yüke ekle (varsayılan açık) anahtarı bulunur.
Bir Veritabanı hedefinin konnektörü, Gateway Runtime konnektörleriyle aynı Operasyon alanını kullanır — veritabanı tipinden bağımsız olarak yalnızca Insert-Update-Delete sunulur. Detay için bkz. Log Konnektörü Eklenmesi.
Bir hattı taşımadan önce bağlantıyı doğrulamak için kaydedilmiş hedefin Test olayı gönder işlemini kullanınız.

Hatlar
Her hat için bir satır ve dört sütun bulunur:
| Sütun | Ne yapar |
|---|---|
| Hat | Hattın adı. Platformda var olup henüz yapılandırılamayan bir hat Planlandı rozeti taşırdı; bu sürümde her hat yapılandırılabilir durumdadır. |
| Apinizer Veritabanı / Yerel Saklama | Hattın yerel olarak saklanıp saklanmadığını ve ilgili log ailesinin saklama yapılandırmasına giden Saklama ayarları bağlantısını gösterir. Denetim, oturum, API güvenliği ve portal hatları Her zaman saklanır olarak işaretlidir ve kapatılamaz. Token ve uygulama hatlarında Apinizer veritabanında sakla anahtarı bulunur ve varsayılan olarak açıktır. API Erişimi hattında da aynı anahtar vardır; ancak varsayılan olarak kapalıdır ve açılırken onay ister — yukarıdaki uyarıya bakınız. Denetim satırı ayrıca, Yönetim Konsolu isteklerinin hiç kaydedilip kaydedilmeyeceğini belirleyen ve bir Genel Ayarlar değeri olmayı sürdüren Yönetim isteklerini denetle anahtarını taşır. |
| Hedefler | O hat için yapılandırılmış her hedefin kural özeti. Hedef yoksa hücre bunu belirtir; hâlâ LEGACY olan hatlarda Kurallar, yetki ACTIVE olduğunda etkinleşir uyarısı görünür. |
| Yetki | LEGACY ⇄ ACTIVE anahtarı; onay penceresi ve önerilen geçiş sırası ile birlikte. Anahtar kendi başına ve anında kaydedilir; yalnızca kaydedilmiş yapılandırmayı taşır: henüz kaydetmediğiniz hedef düzenlemeleri ekranda kalır ancak geçişe dahil edilmez, onay penceresi bunu ayrıca hatırlatır. Anahtarın onları da kapsaması gerekiyorsa önce kaydedin. |

Şema ve Örnekler
Bir hat ve bir profil seçtiğinizde sekme, çalışan platformun o kombinasyon için ürettiği yükü ve izin verilen alan listesini gösterir. Profil listesinde CEF 0 ve LEEF 2.0 da yer alır; böylece bu satırların gerçek biçimini hedefi kurmadan önce görebilirsiniz. Ayrıştırıcınızı bu çıktıya göre kurunuz ve yanındaki notu okuyunuz: şema sürümü artmadan yeni alanlar eklenebilir, bu nedenle ayrıştırıcınız bilinmeyen alanları yok saymalıdır.
Yükün altında ayrıca bir RFC 5424 yapılandırılmış veri örneği gösterilir. Bu, yükün parçası değil çerçeveleme üstverisidir ve yalnızca Syslog bağlantısında yapılandırılmış veri açıkken yazılır; örnekteki kurum numarası temsilîdir, gerçek değer bağlantı ayarından gelir.

Kurallar
Kurallar, olay bir konnektöre teslim edilmeden önce, olayı üreten akış üzerinde kaynağında değerlendirilir. Betik ya da düzenli ifade eşlemesi yoktur; değerlendirme sabit sıralı denetimlerden oluşur ve token yolunda bile ucuz kalır.
Değerlendirme sırası
| Adım | Denetim | Eşleştiğinde sonuç |
|---|---|---|
| 1 | Kural kapalı | Gönderilmez |
| 2 | Olay tipi Hariç tutulan olay tipleri içinde | Gönderilmez — hariç tutma her zaman dahil etmeye üstün gelir |
| 3 | Dahil edilen olay tipleri boş değil ve olay tipini içermiyor | Gönderilmez |
| 4 | Kapsam — hariç tut boyutlarından herhangi biri eşleşiyor | Gönderilmez |
| 5 | Kapsam — dahil et boş değil ve hiçbir boyut eşleşmiyor | Gönderilmez |
| 6 | Eşik olayı eliyor — uygulama hattında En düşük seviye, diğer hatlarda Sonuçlar | Gönderilmez |
| 7 | Örnekleme yüzdesi tanımlı (yalnızca API Erişimi) ve bu olay örneklem dilimine düşmüyor | Gönderilmez — örneklemeye takıldı |
| 8 | Saniyedeki en fazla olay o saniye için tükenmiş | Kısıtlanır |
| 9 | — | Gönderilir |
Boş liste her zaman hepsi anlamına gelir: dahil edilen olay tipi yoksa tüm tipler, sonuç seçilmemişse tüm sonuçlar, kapsam boşsa tüm olaylar geçer. Kapsam — dahil et içindeki boyutlar VEYA ile birleşir; olayın doldurulmuş boyutlardan en az biriyle eşleşmesi yeterlidir. Kapsam — hariç tut içindeki herhangi bir boyutla eşleşen olay ise düşürülür.
Örnekleme
Örnekleme yüzdesi alanı yalnızca API Erişimi kuralında görünür ve istek başına olay üreten bir hattı, olay adedine göre boyutlandırılan veya ücretlendirilen bir SIEM için taşınabilir kılan ayardır. Boş bırakırsanız kurala uyan her olay gönderilir; 10 yazarsanız yaklaşık onda biri gönderilir.
İki noktada net olmakta fayda vardır:
- Yalnızca yönlendirmeyi seyreltir, saklamayı değil. Örnekleme, hedefe neyin gideceğine karar verir.
log_apiaccesskoleksiyonuna neyin yazılacağını etkilemez — onu yalnızca yerel saklama anahtarı belirler. Bu nedenle Güvenlik Olayları ekranı, örnekleme yüzdesi ne olursa olsun bütün olayları göstermeye devam eder. - Karar rastgele değil, deterministiktir. Olayın kendi kimliğinden türetilir; aynı olay her değerlendirmede aynı sonucu alır ve bir istek, kendisini örnekleme dâhil eden hedeflerin ya hepsine ulaşır ya hiçbirine. Yeniden değerlendirme sonucu değiştirmez.
Belirli bir gürültü türünü azaltmak için örnekleme doğru araç değildir; bunun için Sonuçlar, Kapsam — dâhil et veya Kapsam — hariç tut kullanın. Örneklemeyi, her şeyden temsilî bir kesit istediğiniz duruma saklayın.
Örnekleme, API Erişimi hattını bir denetim izi olarak kullanmakla bağdaşmaz. Örneklenmiş bir hedef trafiğinizin tam değil istatistiksel bir görüntüsünü tutar; bir uyumluluk raporunu oraya bağlamayınız.
Kapsam boyutları
| Boyut | Neyle eşleşir | Anlamlı olduğu hatlar |
|---|---|---|
| Proje kimlikleri | Etkilenen nesnenin ait olduğu proje | Denetim, Oturum, Token |
| API proxy kimlikleri, API proxy adları | Olayın ilişkili olduğu API proxy | Token, Uygulama |
| HTTP metotları | Token isteğinin HTTP metodu | Token |
| Kimlik bilgileri | Token talep eden kimlik bilgisi veya istemci anahtarı | Token |
| Ortam kimlikleri | Olayı üreten ortam | Token, Uygulama |
| Bileşenler | Logu yazan Apinizer bileşeni — Manager, Gateway, Cache, Integration, Portal | Uygulama |
| İstemci CIDR blokları | İstemci IP adresi; IPv4 veya IPv6 CIDR bloklarıyla eşleştirilir | Denetim, Oturum, Token |
| Portal kimlikleri | Olayın ait olduğu API Portal | Oturum (yalnızca portal giriş/çıkış olaylarında), Portal |
Adlar büyük/küçük harf duyarsız, kimlikler tam eşleşme ile karşılaştırılır.
Yönetim Konsolu isteği ve erişim reddi denetim olayları hiçbir projeye ait değildir. Proje kimlikleri alanını bir proje kimliğiyle doldurursanız bu olaylar eşleşmeyi bırakır ve o hedeften kaybolur. Onları korumak için listeye admin değerini de ekleyiniz; bu değer projesi olmayan olayları seçer.
Yönetim Konsolu girişlerinin eşleşecek bir Portal kimlikleri'i, portal girişlerinin ise eşleşecek bir Proje kimlikleri'i yoktur — Oturum hattında doldurulmuş bir Portal kimlikleri kapsamı yalnızca portal tarafını seçer, tıpkı Proje kimlikleri'nin yalnızca Yönetim Konsolu tarafını seçmesi gibi.
Örnekler
| Amaç | Nasıl yapılandırılır |
|---|---|
| Yalnızca başarısız ve reddedilen yönetimsel işlemler gönderilsin | Denetim kuralı → Sonuçlar: FAILURE, DENIED |
| Yüksek hacimli Yönetim Konsolu istek akışı bir hedefin dışında tutulsun | Denetim kuralı → Hariç tutulan olay tipleri: MANAGER_REQUEST |
| Yalnızca tek bir projenin olayları gönderilsin | Denetim kuralı → Kapsam — dahil et → Proje kimlikleri: proje kimliği (platform seviyesindeki olaylar için admin de eklenir) |
| Yalnızca uyarı ve hatalar gönderilsin | Uygulama kuralı → En düşük seviye: WARN |
| Paylaşılan bir syslog hedefi token dalgasından korunsun | Token kuralı → Saniyedeki en fazla olay: 200 |
| Başarılı API trafiği, güvenlik olayları çiftlenmeden yönlendirilsin | API Erişimi kuralı → Sonuçlar: SUCCESS (engellenen ve hata veren istekleri API Güvenliği kuralı taşımaya devam etsin) |
| İstek başına olay üreten hat, olay adedine göre ücretlendirilen bir SIEM'de taşınabilir kalsın | API Erişimi kuralı → Örnekleme yüzdesi: 10 — kurala uyan olayların yaklaşık onda biri yönlendirilir, koleksiyon yine hepsini saklar |
| Yalnızca token redleri gönderilsin | Token kuralı → Dahil edilen olay tipleri: TOKEN_REJECTED |
| Yalnızca tek bir portalin giriş/çıkışları gönderilsin | Oturum kuralı → Kapsam — dahil et → Portal kimlikleri: portal kimliği |
| Bir değişikliğin türü görülsün, ama alan bazlı eski/yeni değer ayrıntısı yüke eklenmesin | Denetim/Portal hedefi → Değişiklik listesini yüke ekle: kapalı (data.changesStatus ve data.changeKinds yine de gönderilir) |
| Bir portalin uygulama/abonelik/destek talebi aktivitesi gönderilsin ama girişleri gönderilmesin | Kapsam kısıtı olmayan bir Portal kuralı; o hedef için Oturum kuralı kapalı bırakılır (veya başka bir portale kapsamlanır) |
Kurallar yalnızca yetkisi ACTIVE olan hatlarda uygulanır. Bir hat LEGACY durumdayken eski listedeki her alıcı her olayı almaya devam eder.
Gizlilik Profili
Hassas veri iki katmanda ele alınır.
Birinci katman kapatılamaz. Token değerleri, parolalar ve parola özetleri, Authorization, Cookie ve Set-Cookie başlıkları, API anahtarı başlıkları, sorgu dizeleri, sertifika ve anahtar materyali ile gizlilik tuzunun kendisi bir v2 yükünün parçası hiçbir zaman olmaz. Bunlar izin verilen alan listesinde yer almaz ve ikinci bir denetim, adı kimlik bilgisine benzeyen kalan alanları da kaldırır. Gateway Runtime ortamının token imzalama anahtarı (JWT Token Doğrulama Anahtarı sekmesindeki RSA özel anahtar) da bu katmanın parçasıdır: ne ortam kaydının denetim satırında ne değişiklik listesinde ne de yakalanan istek gövdesinde yer alır.
İkinci katman hedef başına yapılandırdığınız gizlilik profilidir. İsteğe bağlıdır ve yalnızca Apinizer JSON v2 yolunda, zarf üretildikten sonra ve boyut politikası çalışmadan önce uygulanır. Her kural bir zarf alanını adıyla, düzenli ifadeyle ya da hazır PII tipiyle (kimlik numarası, IBAN, e-posta adresi, telefon numarası, kart numarası) hedefler ve tek bir işlem uygular: maskeleme, hash'leme, silme, şifreleme veya tespit.
Hedef penceresinde tek tıkla uygulanan önerilen profil, kimlik alanlarını (user, email ve kimlik bilgisi adı) tuzlu hash'e çevirir ve IP adresini okunabilir bırakır. Serbest metin alanları için hazır PII tespiti bu ekrandaki tablodan henüz düzenlenemez.
Yeni oluşturduğunuz bir hedefte API Güvenliği hattı maskelemeyle birlikte başlar. Bu hattı yeni bir hedef için açtığınız anda hedefin gizlilik profiline üç hazır PII kuralı — TCKN, Türkiye IBAN'ı ve kart numarası — maskeleme işlemiyle eklenir. API Güvenliği olayı gövdesizdir, ancak credential ve path alanları çağıranın URL'e yazdığı ya da kota anahtarı olarak gönderdiği bir kimliği taşıyabilir. Üç kural hedefin gizlilik tablosunda listelenir ve kaydetmeden önce kaldırılabilir. Hâlihazırda var olan bir hedefe hiçbir şey uygulanmaz, kendi elinizle boşalttığınız ya da kapattığınız bir profil ezilmez ve kuralı sonradan kaldırmanız profili geri almaz; o noktadan sonra sıradan bir yapılandırmadır. Aynı varsayılan sunucu tarafında da uygulandığı için bu sayfadan geçmeden API ile oluşturulan bir hedef de korumasız kalmaz. Gizlilik profilinin tek bir hatta değil hedefe ait olduğunu unutmayınız: aynı hedef Denetim, Oturum veya Uygulama olaylarını da yönlendiriyorsa bu üç kural onlara da uygulanır.
| Genel kural | Neden |
|---|---|
| Kimlikleri silmek yerine hash'leyiniz | Tuzlu hash aynı kullanıcıyı olaylar arasında tutarlı tutar; korelasyon ve kullanıcı bazlı alarm çalışmaya devam eder. |
| IP adresini okunabilir bırakınız | SIEM tespitlerinin çoğu (imkânsız seyahat, kaba kuvvet, olağan dışı kaynak) IP üzerine kuruludur. |
| Her şeyi maskelemeyiniz | Aşırı maskeleme SIEM'in ihtiyaç duyduğu sinyalleri siler; aşırı maskelenmiş bir akış denetimden geçer ama hiçbir şey tespit etmez. |
| Hash kullanmadan önce tuz tanımlayınız | Tuzsuz hash kuralı kabul edilmez. |
| Tuzu bilinçli döndürünüz | Rotasyon sonrası aynı kullanıcı farklı bir değere hash'lenir; rotasyon sınırının iki yakası arasında takma ad korelasyonu kırılır. Bunu SIEM ekibinizle planlayınız. |
Bir olay için maskeleme başarısız olursa, o olay maskesiz gönderilmek yerine hiç gönderilmez. Kopyanın kaybı, hassas verinin sızmasına tercih edilir. Bu olaylar ayrı olarak sayılır ve görünür kalır.
Zarfın yapısal alanları — logType, schemaVersion, timestamp, event altındaki her şey ve apinizer altındaki her şey — korumalıdır. Bunları hedefleyen bir gizlilik kuralı yok sayılır; maskelenmeleri alt taraftaki tüm ayrıştırıcıları bozardı.
Gizlilik profilleri, bugünkü çıktıyı birebir üreten Legacy Raw hedeflerine uygulanmaz. Maskeleme gerekiyorsa hedefi Apinizer JSON v2 profiline geçiriniz.
Boyut Politikası
Boyut politikası da yalnızca v2 profilinde çalışır ve zarf dahil tüm yükün UTF-8 boyutunu sınırlar.
| Ayar | Davranış |
|---|---|
| Kapalı (varsayılan) | Sınır yok — yükseltme öncesiyle aynı davranış. |
| Veriyi kırp | data içindeki büyük alanlar — changes, reference, message, stackTrace — yük sığana kadar büyükten küçüğe kısaltılır (changes ve reference önce kısaltılır), her biri kırpma notuyla işaretlenir ve apinizer.truncated değeri true olur. Zarf alanlarına dokunulmaz. Kırpma yeterli olmazsa olay düşürülür. |
| Olayı düşür | Olay gönderilmez ve boyut aşımı olarak sayılır. |
| Veriyi hash ile değiştir | data yerine SHA-256 özeti ve bayt sayısı yazılır; olay korelasyon için kullanılabilir kalır ama yük taşımaz. |
Yapılandırılabilen en düşük değer 1024 bayttır. Syslog hedefleri için 8192 bayt ve Veriyi kırp iyi bir başlangıçtır; RFC 5424 alıcılarının çoğu mesaj başına 2–8 KB kabul eder ve daha uzununu sessizce keser. Kafka, Webhook ve Elasticsearch hedefleri genellikle sınıra ihtiyaç duymaz.
Bir olayı büyüten alanlar uygulama hata yığınları, denetim referans nesneleri ve denetim/Portal değişiklik listeleridir. Üçü de isteğe bağlıdır ya da sınırlanabilir: referans nesnesi denetim hattında varsayılan olarak kapalıdır, değişiklik listesi varsayılan olarak açıktır ve ihtiyaç duymayan bir hedef için kapatılabilir, hata yığını anahtarı ise aynı şekilde ihtiyaç duymayan bir hedef için kapatılabilir.
Bu, Syslog connection'ının kendisindeki Maksimum Mesaj Boyutu (Bayt) ayarından farklı bir kontroldür. Bu boyut politikası olayın içeriğini hedef boyuta sığması için kısaltır, düşürür veya hash'ler; Syslog connection'ındaki ayar ise içeriğin tamamını korur ve boyutu aşan mesajı birden fazla syslog mesajına böler. İkisinin bir hedefte birlikte kullanıldığında nasıl ilişkilendiğini görmek için bkz. Büyük Mesajları Bölme.
Taşıma ve Geçiş Rehberi
Sürüm yükseltmesinde ne oldu
Yükseltme sırasında, Genel Ayarlar altında uygulama, token, denetim ve giriş logları için yapılandırılmış her alıcı bu sayfada bir hedefe dönüştü:
- Alıcı başına bir hedef; bağlantı yapılandırması ve kimliği değişmeden korundu.
- Yük profili Legacy Raw, gizlilik profili ve boyut politikası tanımsız — çıktı, yükseltme öncesinde SIEM'inize ulaşanla birebir aynı.
- O alıcının hizmet ettiği hat için bir kural; Dahil edilen olay tipleri listesi yükseltme anında var olan tüm olay tiplerini içerir (uygulama hattı istisnadır, seviye ile filtrelendiği için listesi boş bırakılır). Böylece SIEM'iniz önceden aldığının aynısını almaya devam eder, fazlasını almaz.
- Token ve uygulama logları için yerel saklama anahtarları olduğu gibi taşındı.
- Tüm hatlar LEGACY yetkisinde bırakıldı; siz aksine karar verene kadar hiçbir şey değişmedi.
Korunacak bir alıcı listesinin bulunmadığı taze kurulumlarda her hat ACTIVE başlar — yalnızca eski alıcı listesi taşıyabilecek dört hat değil, hiç taşıması gereken bir liste olmayan API Güvenliği, API Erişimi ve Portal hatları da dahil.
Taşınan kural açık bir olay tipi listesi taşıdığı için, sonraki Apinizer sürümlerinde eklenen olay tipleri siz listeye ekleyene kadar o kural üzerinden yönlendirilmez. Bu bilinçli bir tercihtir: taşınan bir akış, yöneticinin kararı olmadan büyümez. Dahil edilen olay tipleri alanını boş bırakarak kendiniz yazdığınız bir kural ise sonradan eklenenler dahil tüm tipleri yönlendirir.
Bir hattın geçişi
- O hattın hedefini açınız ve kuralını gözden geçiriniz — olay tipleri, sonuçlar, kapsam ve saniyedeki olay sınırı.
- İsterseniz Apinizer JSON v2 profiline geçiriniz ve yükü Şema ve Örnekler sekmesinde SIEM ekibinizle doğrulayınız.
- Bir test olayı gönderiniz ve ulaştığını teyit ediniz.
- Hatlar sekmesinde hattın yetkisini ACTIVE yapınız.
- Bir sonraki hatta geçmeden önce birkaç dakika sayaçları ve SIEM tarafını izleyiniz.
Önerilen sıra Denetim → Oturum → Token → Uygulama şeklindedir: en düşük hacim önce, en yüksek ve en dalgalı olan en sonda.
Geri alma
Bir hattı LEGACY durumuna geri almak anında etkilidir. Eski alıcı listeleri bu sayfadaki her kayıtta güncel tutulduğu için her iki yönde de kayıp yaşanmaz.
Aynı mekanizma kademeli sürüm yükseltmesini de güvenli kılar. Önceki sürümü çalıştıran bir düğüm bu sayfayı bilmez ve güncel tutulan eski listeleri okur; aynı olayları yönlendirir, yalnızca yükseltilene kadar kural, gizlilik profili ve boyut politikası uygulamaz.
Portal girişlerinin iletimi
Bu hat gelmeden önce her API Portal'ın kendi, ayrı bir giriş/çıkış alıcı listesi vardı — ilgili portalin Ayarlar → Login Log sekmesinde yapılandırılırdı. Bu sürüme yükseltme o listeyi olduğu gibi bıraktı ve buraya kopyaladı: bir portalin listesindeki her konnektör için, bu sayfada artık o portala kapsamlanmış (Portal kimlikleri) ve o portalin ürettiği on olay tipiyle sınırlı bir Oturum kuralı taşıyan bir hedef vardır — o portalin konnektörünün eskiden aldığı başka hiçbir şey değişmedi. Bu sürümden önce kilitleme/parola-yaşam-döngüsü olay tiplerinin eklendiği bir hedef, o zaman verilen include listesini olduğu gibi korur — yeni bir Oturum olay tipi mevcut bir kuralın include listesine otomatik EKLENMEZ (her hat için geçerli aynı kural, aşağıda), yani boş olmayan bir include listesine sahip zaten göç etmiş bir hedef kendiliğinden PORTAL_ACCOUNT_UNLOCKED (veya diğer parola-yaşam-döngüsü tipleri) almaya başlamaz; include listesi boş bırakılmış bir kural her zaman yeni tipleri de alır.
Hangi listenin gerçekten canlı olduğuna Portal hattının değil Oturum hattının yetkisi karar verir:
- LEGACY (yükseltme sonrası varsayılan): her portalin kendi alıcı listesi tıpkı eskisi gibi kullanılır — bu sayfadaki kopyaları vardır ama etkisizdir.
- ACTIVE: portal başına alıcı listeleri artık hiçbir portal için kullanılmaz; her portal girişi ve çıkışı bunun yerine bu sayfadaki hedefler ve kurallarla iletilir — yükseltmenin oluşturduğu kopyalar dahil.
Portal başına bir anahtar YOKTUR — Oturum'u ACTIVE'e çevirmek aynı adımda her portalin eski listesini emekliye ayırır; bu yüzden her portalin Login Log sekmesi bunu yaptığınızda bilgilendirici bir not gösterir.
Alıcı listeleri ve iki yerel saklama anahtarı artık bu sayfaya aittir. Genel Ayarlar ekranı, Yönetim API'leri veya APIops üzerinden bu alanlar için gönderilen değerler yok sayılır; bütün proje yapılandırması içe aktarımındaki değerler de öyle. Bu ayarları buradan yapılandırınız — bu sayfanın kendi yapılandırması, Dışa/İçe Aktarma sihirbazındaki SIEM Ayarları tipiyle tek başına başka bir kuruluma taşınabilir; bkz. aşağıdaki Dışa/İçe Aktarma.
Yerel Depolama ve Saklama
Hatlar sekmesinin ilk sütunu, sayfadaki diğer her şeyden farklı bir soruyu yanıtlar: kopya nereye gönderiliyor değil, kayıt Apinizer veritabanında tutuluyor mu.
| Hat | Yerel saklama | Bugünkü saklama süresi |
|---|---|---|
| Denetim | Her zaman saklanır — kapatılamaz | Uygulama Logu Temizleme Görevleri sayfasındaki Audit Records satırından yapılandırılır; varsayılan olarak kapalıdır (etkinleştirildiğinde 365 gün). |
| Oturum | Her zaman saklanır — kapatılamaz | Uygulama Logu Temizleme Görevleri sayfasındaki Login Records satırından yapılandırılır; varsayılan olarak kapalıdır (etkinleştirildiğinde 365 gün). |
| Token | Anahtarla açılıp kapatılır | Log Saklama bölümünden yapılandırılır; varsayılan olarak kapalıdır. |
| Uygulama | Anahtarla açılıp kapatılır | Bileşen başına Log Saklama bölümünden ve Uygulama Logu Temizleme Görevleri sayfasından yapılandırılır; varsayılan olarak kapalıdır. |
| API Güvenliği | Her zaman saklanır — kapatılamaz | Log Saklama bölümünden ve Uygulama Logu Temizleme Görevleri sayfasındaki API Security Events satırından yapılandırılır; varsayılan olarak kapalıdır (birim gün, 30). |
| API Erişimi | Anahtarla açılıp kapatılır — varsayılan olarak kapalı, açılırken onay ister | Uygulama Logu Temizleme Görevleri sayfasındaki API Access Events satırından yapılandırılır; varsayılan olarak kapalıdır (istek başına bir satır yazıldığından 3-7 gün önerilir). |
| Portal | Her zaman saklanır — kapatılamaz | Yukarıdaki Denetim ile aynı audit_event koleksiyonunu paylaştığından aynı Audit Records saklama satırına tabidir; on altı alan olayı, aşağıdaki Portal Login Logs saklama anahtarının kapsamı dışındadır — o anahtar yalnızca giriş/çıkış kayıtlarını kaldırır. |
Yukarıdaki Oturum satırı yalnızca Yönetim Konsolu girişleri için tam resimdir. Portal girişleri ve çıkışları ayrı bir koleksiyonda, portal_login_logs'ta tutulur; persistent_audit_event'in aksine bu koleksiyonun bir saklama anahtarı vardır: Uygulama Logu Temizleme Görevleri altındaki Portal Login Logs, varsayılan olarak kapalı. Açıldığında yalnızca eski portal giriş/çıkış kayıtları silinir; persistent_audit_event'teki yönetici girişleri her koşulda etkilenmez.
Token veya uygulama hattı için yerel saklamayı kapatmak, o kayıtların Apinizer veritabanında hiç tutulmaması ve Token İstekleri ile Uygulama Logları sayfalarında görünmemesi demektir. Bunu yalnızca en az bir hedefin kayıtları aldığı doğrulandıktan sonra yapınız.
Dışa/İçe Aktarma
Bu sayfanın tüm yapılandırması — her hedef ve iki yerel saklama anahtarı — başka bir Apinizer kurulumuna, Dışa/İçe Aktarma sihirbazındaki SIEM Ayarları tipiyle taşınabilir. Bu tipi yalnızca sistem yöneticisi dışa ya da içe aktarabilir — ister sihirbazdan ister APIops üzerinden — ve yalnızca Administration → Dışa/İçe Aktar grubundan erişilir; bu yapılandırmanın sahibi bir proje olmadığı için hiçbir projenin kendi Dışa/İçe Aktar menüsünde görünmez.
- Bir hedefin bağlantısı — gönderdiği bağlantı yapılandırması ve varsa yedek (failover) bağlantısı dahil — diğer her bağlantı tabanlı tipte olduğu gibi bir bağımlılık olarak taşınır. Pakete dahil edin, ya da sihirbaz hedefte aynı ada sahip mevcut bir bağlantı yapılandırmasıyla adına göre eşlesin.
- Hat yetkisi (LEGACY/ACTIVE) hiçbir zaman taşınmaz. Bir paketin içe aktarılması hedefte hiçbir hattı devreye almaz; bunu yalnızca hedefteki bu sayfanın kendisi yapabilir.
- Replace Existing, hedefteki hedef listesini pakettekiyle tümüyle değiştirir ve iki yerel saklama anahtarını da paketten alır; hedefin kendi hat yetkisi olduğu gibi kalır. Import as New ise paketteki hedefleri hedefin mevcut listesine ekler — orada zaten kullanılan bir ad
-importedsoneki alır — ve hedefin kendi yerel saklama anahtarlarına ile hat yetkisine dokunmaz. - Sihirbaz yalnızca hedefi sorar; yeni ad ya da Portal istemez. SIEM yapılandırması kurulum genelinde tek bir nesnedir; bu yüzden Import as New onu yeniden adlandırmanızı istemez —
-importedson ekini yalnızca içindeki hedefler alır — ve yükleme adımında Hedef Portal seçimi yoktur; o seçim API Ürünleri gibi Portal kapsamlı tiplere aittir. - Bağlantısı hedefte çözülemeyen bir hedef — pakete dahil edilmemiş ve hedefte aynı ad/tipte bir bağlantı da yoksa — yine de içe aktarılır, yalnızca Enabled anahtarı kapalı olarak; içe aktarma sonucu hedefin adını ve bulunamayan bağlantıyı adlandırır. Bozuk bir referansla asla etkin içe aktarılmaz, asla sessizce düşürülmez. Aynı kural yedek bağlantı için de geçerlidir.
- Import as New ile oluşan ve API Güvenliği hattını gönderen, kendi gizlilik profili olmayan bir hedef, bu sayfadan doğrudan oluşturulan bir hedefle aynı şekilde yukarıdaki Gizlilik Profili bölümünde anlatılan maskeleme kurallarıyla gelir.
- Gizlilik tuzu pakette aynen, düz metin olarak taşınır — bugün başka paketlerdeki bir bağlantının tuzunun taşındığı gibi. Bu bilinçlidir: iki kurulum aynı tuzu paylaşmadan aynı değeri aynı özete indirmez. Paket paylaşılan bir yerde duracaksa — örneğin bir CI deposunda — Dışa/İçe Aktarma sihirbazı sayfasındaki Paket Şifreleme ile parolalı dışa aktarın.
Davranışın tamamı için — pakete ne girer, ad çakışması nasıl ele alınır, sunucu yönetimli alanlar nasıl davranır — bkz. Dışa/İçe Aktarma sihirbazı sayfasındaki SIEM Ayarları.