Denetim Kayıtları

Filtreleme
Sayfanın üst tarafında bulunan filtre bölümünden kriterler belirleyerek sonuçları log tablosunda görüntüleyebilirsiniz. Silme butonu ile filtre içerikleri temizlenebilir.
Tarih Aralığı alanları takvimden seçilebileceği gibi doğrudan klavyeden de girilebilir. Bir kaydın detayına girip listeye geri döndüğünüzde, o ana kadar uyguladığınız tarih aralığı dahil tüm filtreler korunur; sayfa varsayılan tarih aralığına sıfırlanmaz.
Bu ekran bir varlığın kendi Denetim ve Geri Yükleme sekmesinden açıldığında (örneğin bir API Proxy veya Proxy Group'un düzenleme ekranında), Nesne ID filtresi o varlığa kilitlenir ve değiştirilemez — alanın yanındaki kilit simgesi bunu belirtir. Bu durumda listede yalnızca o varlığa ait kayıtlar görüntülenir.
Kaynak filtresi, listeyi bir kaydın geldiği dört yüzeyden birine daraltır: Manager (Yönetim Konsolu ve Yönetim API'leri), APIOps, Portal (API Portal'ın yönetim arka ucu — bkz. Portal Olayları) veya System (arkasında bir istek olmayan bir arka plan görevi/geçiş). Platform kapsamlı (projesiz) görünümde gösterilen Portal ID kolonu, Portal kaynaklı bir kaydın hangi portala ait olduğunu belirtir; diğer kaynaklarda boştur. Tabloda ayrıca bir Proje kolonu bulunur; kaydın ait olduğu projenin adını gösterir ve bir projeye bağlı olmayan kayıtlarda (Yönetim İsteği, Erişim Reddi gibi) boş kalır.
Olay Tipleri
Denetim Kayıtları üç temel olay türünü yakalayabilir; bunlar Olay Tipi kolonunda, işlemin geldiği İstemci IP ile birlikte gösterilir. Bu üçüne ek olarak hassas veriye erişimi izleyen beş olay türü — bkz. Hassas Erişim Olayları —, dağıtım, API Promotion ile erişim izni (ACL) işlemlerini izleyen on olay türü — bkz. Operasyon Olayları — ve API Portal'ın kendi alan olaylarını izleyen on altı olay türü daha vardır — bkz. Portal Olayları.
| Olay Tipi | Ne zaman kaydedilir |
|---|---|
| Varlık | Bir varlık — API Proxy, Politika, bağlantı vb. — oluşturulduğunda, güncellendiğinde veya silindiğinde. Aşağıdaki Değişiklik Detayları bölümünün kapsadığı olay budur. |
| Yönetim İsteği | Aşağıda açıklanan ayar açıldığında, Yönetim Konsolu ekranlarına, Yönetim API'lerine veya APIops'a ulaşan bir yazma işlemi gerçekleştiğinde. |
| Erişim Reddi | Yönetim Konsolu'na veya Yönetim API'lerine yapılan bir istek reddedildiğinde — çağıran yetkili değilse (FORBIDDEN) veya sunulan token geçersiz ya da süresi dolmuşsa (UNAUTHENTICATED). Aşağıdaki ayardan bağımsız olarak her zaman kaydedilir. |
Bir kaydın detayına girildiğinde ayrıca işlemin Sonucu (başarılı, başarısız veya reddedildi), istemcinin gönderdiği User Agent, aynı istekten üretilen tüm denetim satırlarını birbirine bağlayan bir Correlation ID ve isteğin geldiği Kaynak (Yönetim Konsolu, APIops, API Portal veya arkasında istek olmayan işlemler için Sistem) görüntülenir.
Yönetim İsteği ve Erişim Reddi kayıtları belirli bir projeye bağlı değildir; bu nedenle yalnızca Denetim Kayıtları proje filtresi olmadan görüntülendiğinde görünür. Bu platform kapsamlı görünüm ve tüm projelerin kayıtları Sistem Yöneticisi ve Proje Yöneticisi kullanıcılara açıktır. Diğer kullanıcılar yalnızca Denetim → Görüntüleme yetkisine sahip oldukları kapsamı görür: bir projenin kayıtları için o projede, platform kapsamlı kayıtlar içinse Yönetim menüsünde bu yetkiyi taşıyan roller (örneğin Sistem Analisti) gerekir. Bu kullanıcılar için platform kapsamlı liste de aynı kapsamla daraltılır: platform kapsamlı kayıtların yanı sıra yalnızca okuyabildikleri projelerin kayıtları listelenir.
Yönetim Konsolu İsteklerinin Kaydedilmesi
Reddedilen bir yazma isteği aynı Correlation ID'yi paylaşan iki satır üretir: her zaman kaydedilen bir Erişim Reddi satırı ve aşağıdaki ayar açıksa sonucu reddedildi olan bir Yönetim İsteği satırı. Bu bilinçli bir davranıştır; ikisini birlikte görmek için Correlation ID ile filtreleyin.
Yönetim İsteği olaylarının kaydedilmesi varsayılan olarak kapalıdır. Yönetim → Sistem Ayarları → Genel Ayarlar → Audit Log bölümündeki Yönetim Konsolu isteklerinin denetim kaydı anahtarından etkinleştirilebilir. Etkinleştirildiğinde, Yönetim Konsolu ekranlarına, Yönetim API'lerine ve APIops'a gönderilen her yazma işlemi (HTTP POST, PUT, PATCH veya DELETE) kaydedilir — kimlik doğrulama, token yenileme ve çıkış uç noktaları hariç; bunlar zaten Giriş Kayıtları sayfasında ayrıntılı olarak izlenir.
Erişim Reddi olayları, tamamlanmış bir işlemi değil reddedilen bir isteği temsil ettiği için bu ayardan bağımsız olarak her zaman kaydedilir. Bu nedenle reddedilen tek bir istek, hem sonucu reddedildi olan bir Yönetim İsteği kaydı olarak hem de — reddin bir yetkilendirme hatasından kaynaklanması durumunda — ayrı bir Erişim Reddi kaydı olarak görünebilir.
Bu satırlar hem çağıranın yetkili olmadığı durumları (FORBIDDEN) hem de sunulan bir token'ın geçersiz ya da süresi dolmuş olduğu durumları (UNAUTHENTICATED) kapsar. Kimlik bilgisi hiç sunulmayan anonim istekler ile giriş ve oturum uç noktaları burada kaydedilmez; token geçersizliğinden doğan satırlar, ani bir toplu sona erme dalgasının kayıtları boğmaması için saniyede en fazla 20 ile sınırlıdır.
Bu olaylar için sorgu parametreleri ve kimlik doğrulama başlıkları (Authorization veya Cookie gibi) hiçbir zaman denetim kaydına yazılmaz — varsayılan olarak yalnızca yol, HTTP metodu, sonuç ve süre kaydedilir. İstek gövdesinin de kaydedilmesi ayrı ve varsayılan olarak kapalı bir ayardır; bkz. aşağıdaki İstek Gövdesinin Kaydedilmesi.
İstek Gövdesinin Kaydedilmesi
Yönetim → Sistem Ayarları → Genel Ayarlar → Audit Log bölümündeki İstek gövdesini kaydet anahtarı, yukarıdaki Yönetim Konsolu isteklerinin denetim kaydı ayarı açıkken kullanılabilir hale gelir ve varsayılan olarak kapalıdır.
Açıldığında:
- Yalnızca Yönetim Konsolu'nun kendi
/apiuç noktalarına gönderilen istekler kapsanır — APIops, API Portal ve yönetim (management) uç noktaları bu kapsamda değildir. - Yalnızca
application/jsoniçerikli gövdeler kaydedilir. - Gövde en fazla 16 KB'tır; daha büyük bir gövde kırpılmış olarak işaretlenir ve hiç saklanmaz.
- Sertifika, anahtar deposu, JWK, kriptografik anahtar bilgisi, lisans yönetimi, içe/dışa aktarma ve paket gibi uç noktalar bu yakalamanın her zaman dışındadır.
- Adı gizli bir bilgiye benzeyen alanlar gövdeden çıkarılır; değeri token veya anahtara benzeyen alanlar kısa bir özetle değiştirilir.
- Kaydedilen gövde bir SIEM hedefine yalnızca Referans nesnesini yüke ekle açıkken,
data.referencealanı üzerinden ulaşır; bkz. SIEM ve Log Yönlendirme.
Hassas Erişim Olayları
Denetim Kayıtları, yukarıdaki üç temel olay tipine ek olarak hassas veriye erişimi izleyen beş olay tipini daha yakalar. Bunlar da aynı Olay Tipi kolonunda görünür ve yukarıdaki Yönetim İsteği ayarından bağımsız olarak her zaman kaydedilir.
| Olay Tipi | Ne zaman kaydedilir | Önemli detay alanları | Sonuç |
|---|---|---|---|
| Gizli Bilgi Görüntülendi | Saklı bir gizli değer bir kullanıcıya açık metin olarak ulaştığında. Buna bir API istemcisi sırrının Göster işlemiyle görüntülenmesi, bir portal hesabı parolasının gösterilmesi, bir sertifika ya da anahtar deposunun indirilmesi, sunucunun değeri zaten açık metin döndürdüğü bazı düzenleme formlarının açılması (OIDC kimlik sağlayıcısının istemci sırrı her zaman; yönetme yetkisiyle açılan LLM sağlayıcı, vektör veritabanı, MCP ve A2A bağlantı formları) ve sunucunun değeri maskeli döndürdüğü, göz ya da kopyala tuşu taşıyan herhangi bir gizli alan ekranında bu tuşlardan birine basılması dahildir. | Değerin ait olduğu varlığın türü, gizli değerin türü, görüntüleme yöntemi ve — göz/kopyala tuşu kaynaklıysa — ekran adı; varsa değerin geri döndürülemez bir özeti. | Her zaman Başarılı; yetkisi olmadığı için reddedilen bir deneme bunun yerine ayrı bir Erişim Reddi kaydı üretir. |
| Dışa Aktarma | Bir dışa aktarma paketi üretildiğinde — sihirbaz, Yönetim API'leri veya APIops üzerinden fark etmeksizin. Paket başına tek satır yazılır; paketteki nesne sayısı satır sayısını etkilemez. | Paketteki nesne tipleri ve sayısı, paketin gizli değer taşıyıp taşımadığı, şifrelenip şifrelenmediği ve isteğin geldiği yüzey. | Başarılı veya Başarısız. |
| API Token Oluşturuldu | Bir kullanıcı için yeni bir API erişim token'ı üretildiğinde. | Token'ın sahibi olan kullanıcı, token'ın geri döndürülemez bir özeti ve varsa son kullanma bilgisi. Token'ın değeri hiçbir zaman kaydedilmez. | Başarılı. |
| API Token İptal Edildi | Var olan bir API erişim token'ı iptal edildiğinde. | API Token Oluşturuldu ile aynı; özet sayesinde iptal satırı oluşturma satırıyla eşleştirilebilir. | Başarılı. |
| PII Maskesi Kaldırma | Maskelenmiş bir kişisel veri değeri orijinal haline çevrildiğinde. | İlişkili korelasyon kimliği, kural kimliği, ortam ve işlemin sonucu. | Başarılı veya Başarısız; reddedilen bir deneme yalnızca bir Erişim Reddi kaydı üretir, burada ikinci kez kaydedilmez. |
Bu satırlar gizli değerin kendisini hiçbir zaman taşımaz — en fazla geri döndürülemez bir özet. Bir varlığı düzenleme ekranında açmak ya da kaydını görüntülemek tek başına bir kayıt üretmez: gizli alan ekranda maskeli kalır, kullanıcı göz ya da kopyala tuşuna basmadığı sürece hiçbir satır yazılmaz.
Operasyon Olayları
Denetim Kayıtları, yukarıdaki üç temel olay tipine ve beş hassas erişim olayına ek olarak dağıtım, API Promotion yaşam döngüsü ve erişim izni (ACL) verme/geri alma işlemlerini izleyen on olay tipini daha yakalar. Bunlar da aynı Olay Tipi kolonunda görünür.
| Olay Tipi | Ne zaman kaydedilir | Önemli detay alanları | Sonuç |
|---|---|---|---|
| Dağıtım (Deploy) | Bir API Proxy veya Proxy Group bir ortama dağıtıldığında. | Hedef tipi (API Proxy / Proxy Group), ortam kimliği ve adı, revizyon numarası, dağıtımın kalıcı olup olmadığı, dağıtım açıklaması; başarısız denemede hata detayı. | Başarılı veya Başarısız. |
| Dağıtım Kaldırma (Undeploy) | Bir API Proxy veya Proxy Group bir ortamdan kaldırıldığında. | Dağıtım ile aynı alanlar (revizyon numarası hariç). | Başarılı veya Başarısız. |
| Promotion Talep Edildi | Bir API Promotion çalıştırması oluşturulduğunda — onay gerekmiyorsa doğrudan çalışmaya, gerekiyorsa onay bekleme durumuna geçer. | Mapping kimliği ve adı, kaynak ve hedef instance, kaynak ve hedef API, onay gerekip gerekmediği, başlangıç durumu. | Başarılı. |
| Promotion Onaylandı | Onay bekleyen bir çalıştırma onaylandığında — hemen çalıştırma veya ileri bir tarihe planlama seçeneklerinden biriyle. | Onaylayan kullanıcı; planlama seçildiyse planlanan tarih. | Başarılı. |
| Promotion Reddedildi | Onay bekleyen bir çalıştırma reddedildiğinde. | Red gerekçesi. | Başarılı. |
| Promotion Başlatıldı | Bir çalıştırma çalışmaya başladığında — kullanıcı manuel başlattığında veya planlanan tarih geldiğinde zamanlayıcı tetiklediğinde. | Tetikleyici (manuel veya zamanlanmış). | Başarılı. |
| Promotion Yürütüldü | Bir çalıştırma tamamlandığında. | Toplam süre, adım sayısı; başarısız sonuçta hata mesajı. | Başarılı veya Başarısız. |
| Promotion İptal Edildi | Çalışan veya planlanmış bir çalıştırma iptal edildiğinde. | Çalıştırmanın iptalden önceki durumu. | Başarılı. |
| Erişim Verildi (ACL) | Bir kimlik bilgisine bir API Proxy'nin metotlarına erişim izni verildiğinde. Metot başına değil, proxy × kimlik bilgisi başına tek satır yazılır. | Kaynak (ACL ekranı veya Portal), gerekçe tipi, kimlik bilgisi organizasyonu, ürün adı (Portal kaynaklıysa), ilgili API Proxy, metot sayısı ve ilk 20 metodun adı. | Başarılı. |
| Erişim Geri Alındı (ACL) | Bir kimlik bilgisinin bir API Proxy'nin metotlarına erişimi kaldırıldığında. Aynı şekilde proxy × kimlik bilgisi başına tek satır yazılır. | Erişim Verildi (ACL) ile aynı. | Başarılı. |
Bu on olay tipi, ilgili işlemin ürün içindeki kendi geçmiş ekranına (Dağıtım Geçmişi, API Promotion Çalıştırma Listesi, ACL Denetim Kayıtları) ek bir kayıttır; bu ekranların davranışı ve verisi değişmez. Başarısız bir dağıtım denemesi Dağıtım Geçmişi'ne yazılmaz, ama burada sonucu Başarısız olan bir Denetim Kaydı olarak görünür.
Portal Olayları
Denetim Kayıtları, yukarıdakilere ek olarak on altı portal alan olayını daha yakalar — geliştiricilerin bir API Portal üzerinde gerçekten yaptığı şeyler: uygulama kaydı, bir API ürününe abonelik, organizasyona katılma veya organizasyon yönetimi, destek talebi açma ve kişisel API erişim token'ı oluşturma/iptal etme. Her biri ilgili varlığın kendi kaydına ek olarak yazılır, detaylarında Portal ID taşır ve her zaman Kaynak: Portal'dır.
| Olay Tipi | Nereden üretilir | Önemli detay alanları |
|---|---|---|
| Portal Uygulaması Oluşturuldu | My Apps ekranından yeni bir uygulama kaydı. | Uygulama kimliği, uygulama adı, organizasyon kimliği |
| Portal Uygulaması Silindi | My Apps ekranından bir uygulamanın silinmesi. | Uygulama kimliği, uygulama adı, organizasyon kimliği |
| Portal Abonelik Talebi | Bir uygulamanın bir API ürününe abone edilmesi. | Uygulama kimliği, API ürünü kimliği, plan tipi |
| Portal Abonelik Onaylandı | Bekleyen bir aboneliğin bir yönetici tarafından (veya otomatik onayla) onaylanması. | Uygulama kimliği, API ürünü kimliği, plan tipi, onaylayan |
| Portal Abonelik Reddedildi | Bekleyen bir aboneliğin bir yönetici tarafından reddedilmesi. | Uygulama kimliği, API ürünü kimliği, plan tipi |
| Portal Abonelik İptal Edildi | Bir uygulamanın bir API ürününden aboneliğinin iptal edilmesi. | Uygulama kimliği, API ürünü kimliği |
| Portal Organizasyon Üyesi Davet Edildi | Bir kullanıcının bir organizasyona davet edilmesi. | Organizasyon kimliği, davet edilen hesap kimliği, rol |
| Portal Organizasyon Üyesi Eklendi | Bir üyenin eklenmesi — organizasyon yöneticisi tarafından doğrudan ya da bir daveti kabul ederek. | Organizasyon kimliği, üye hesap kimliği, rol |
| Portal Organizasyon Üyesi Rolü Değiştirildi | Bir organizasyon yöneticisinin bir üyenin rolünü değiştirmesi. | Organizasyon kimliği, üye hesap kimliği, yeni rol |
| Portal Organizasyon Üyesi Çıkarıldı | Bir üyenin organizasyondan çıkarılması. | Organizasyon kimliği, üye hesap kimliği |
| Portal Organizasyon Katılım Talebi | Bir geliştiricinin mevcut bir organizasyona katılma talebinde bulunması (self-servis kayıt akışı). | Organizasyon kimliği, talep eden hesap kimliği |
| Portal Organizasyon Katılımı Onaylandı | Bir organizasyon yöneticisinin katılım talebini onaylaması. | Organizasyon kimliği, talep eden hesap kimliği |
| Portal Organizasyon Katılımı Reddedildi | Bir organizasyon yöneticisinin kat ılım talebini reddetmesi. | Organizasyon kimliği, talep eden hesap kimliği |
| Portal Destek Talebi Oluşturuldu | Support ekranından bir destek talebi açılması — gömülü destek sistemi veya Jira entegrasyonu fark etmeksizin. | Talep kimliği, konu (en fazla 128 karakter — talep gövdesi asla) |
| Portal API Token Oluşturuldu | My Apps ekranından kişisel bir API erişim token'ı üretilmesi. | Token adı, son kullanma tarihi — token değeri asla |
| Portal API Token İptal Edildi | Kişisel bir API erişim token'ının iptal edilmesi. | Token adı — token değeri asla |
Bir portal olayında kaydedilen aktör, işlemi yapan portal hesabıdır — API Portal arka ucunun kimlik doğrulaması için kullandığı Yönetim API'si servis hesabı değil. Bu, API Portal arka ucunun Manager'a yaptığı her çağrıda giriş yapmış geliştiricinin kimliğini de taşıması sayesinde mümkündür; çağıranı bu şekilde belirlenemeyen bir çağrı, bu olay kataloğu var olmadan önceki davranışla aynı şekilde servis hesabına düşer.
Bu kayıtlar her zaman bu ekranın audit_event koleksiyonuna yazılır, ama Denetim ve Oturum hatlarının aksine Portal hattının düşeceği bir eski (legacy) alıcı listesi yoktur: bu on altı olay tipini harici bir SIEM'e iletmek için SIEM ve Log Yönlendirme ekranından Portal hattını Active'e çevirin.
Değişiklik Detayları
"Değişiklik Detayı" ekranı verilerin sağındaki göz simgeli detay butonuna tıklanarak görüntülenir.
Bu sürümden itibaren yazılan Varlık kayıtlarında ekran, ham karşılaştırma yerine daha okunabilir bir görünüm sunar: karşılaştırmanın hangi koşulda üretildiğini gösteren bir durum rozeti (fark başarıyla hesaplandığında, karşılaştıracak önceki bir kayıt olmadığında, gizli alanlar nedeniyle farkın eksik olabileceği durumlarda ya da değişiklik sayısı sınırı aştığında farklı bir rozet görünür), etkilenen alanları özetleyen değişiklik türü etiketleri (bir endpoint'in eklenmesi ya da kaldırılması, bir politikanın değişmesi, yönlendirmenin değişmesi gibi) ve her satırı işlem, yol, anahtar, eski değer ve yeni değer olarak listeleyen bir değişiklik tablosu. Bu ayrıntı için bkz. SIEM ve Log Yönlendirme — Değişiklik listesi.
Yükseltmeden önce yazılmış kayıtlar bu ayrıntıyı taşımaz; onlarda ekran önceki davranışıyla, eski versiyon ve yeni versiyonu yan yana karşılaştıran diff editörüyle görüntülenmeye devam eder.

Denetim Kayıtlarında Gizli Alanlar
Parola, API anahtarı, token, istemci sırrı ve özel anahtar gibi gizli değerler denetim kaydına yazılmaz. Şifrelenmiş biçimde de saklanmaz; kaydedilen anlık görüntüde hiç yer almazlar ve bu nedenle karşılaştırma ekranından okunamazlar. Bu kural sistemde denetlenen tüm kayıt tipleri için geçerlidir, belirli bir ekranla sınırlı değildir. Bir gizli alanın kim tarafından, ne zaman görüntülendiği ayrı ve daha dar kapsamlı bir olay tipiyle izlenir; bkz. Hassas Erişim Olayları. Gateway Runtime ortamının token imzalama anahtarı (JWT Token Doğrulama Anahtarı) da bu kapsamdadır.
Bu kural, bu sürümden itibaren yazılan kayıtlar için geçerlidir. Yükseltmeden önce oluşturulmuş denetim kayıtları geriye dönük olarak değiştirilmez; yazıldıkları haliyle kalır. Eski kayıtların da temizlenmesi gerekiyorsa bu ayrı bir veritabanı bakım işi olarak değerlendirilmelidir.
Gizli alan taşıyan bir varlığı yükseltmeden sonra ilk kez kaydettiğinizde, karşılaştırma ekranında bu alanlar kaldırılmış gibi görünür: önceki kayıtta hâlâ yer alırlar, yeni kayıtta artık yoktur. Bu beklenen bir durumdur; ikinci kayıttan itibaren karşılaştırma normale döner.
Yalnızca gizli alanı değiştiren işlemler
Yalnızca bir gizli alan değiştiğinde — örneğin bir parola ya da API anahtarı yenilendiğinde — iki anlık görüntü birbirinin aynısı görünür, çünkü hiçbirinde değer yer almaz. Bu durumda da bir denetim kaydı oluşturulur; böylece işlemin kendisi, işlemi yapan kullanıcı ve zamanı izlenebilir kalır. Yalnızca değerin kendisi görünmez.
Önceki bir kayda dönme
Bir varlığı denetim geçmişindeki önceki bir haline döndürme işlemi gizli alanları geri yüklemez; bu alanlar mevcut değerinde bırakılır. Ayrıntı için Varlık Yaşam Döngüsü sayfasına bakabilirsiniz.