Denetim Kayıtları

Denetim Kayıtları — liste ekranı

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.

not

Bu ekran bir varlığın kendi Denetim ve Geri Yükleme görünümünden açıldığında (bir sekme ya da örneğin bir API Proxy veya Proxy Group'un düzenleme ekranında Diğer işlemler (⋯) > Geçmiş > Denetim ve Geri Yükleme yan paneli), 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 (Manager İsteği, Erişim Reddedildi 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ı —, proje silme işlemini izleyen bir olay türü — bkz. Proje Silme Olayı — 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.
Manager İsteği	Aşağıda açıklanan ayar açıldığında, Yönetim Konsolu ekranlarına, Yönetim API'lerine, APIops'a veya API Portal'ın yönetim arka ucuna ulaşan bir yazma işlemi gerçekleştiğinde.
Erişim Reddedildi	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.

not

Manager İsteği ve Erişim Reddedildi 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 Reddedildi satırı ve aşağıdaki ayar açıksa sonucu reddedildi olan bir Manager İsteği satırı. Bu bilinçli bir davranıştır; ikisini birlikte görmek için Correlation ID ile filtreleyin.

Manager İsteği olaylarının kaydedilmesi varsayılan olarak kapalıdır. Yönetim → Sistem Ayarları → Genel Ayarlar → Audit Log bölümündeki Manager İsteklerini Denetle anahtarından etkinleştirilebilir. Etkinleştirildiğinde, Yönetim Konsolu ekranlarına, Yönetim API'lerine, APIops'a ve API Portal'ın yönetim arka ucuna 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 Reddedildi 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 Manager İsteği kaydı olarak hem de — reddin bir yetkilendirme hatasından kaynaklanması durumunda — ayrı bir Erişim Reddedildi 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.

uyarı

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 Manager İstek Gövdelerini Denetle anahtarı, yukarıdaki Manager İsteklerini Denetle ayarı açıkken kullanılabilir hale gelir ve varsayılan olarak kapalıdır.

Açıldığında:

• Yalnızca Yönetim Konsolu'nun kendi /api uç noktalarına gönderilen istekler kapsanır — APIops, API Portal ve yönetim (management) uç noktaları bu kapsamda değildir.
• Yalnızca application/json iç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, paket ve Keystore Studio (anahtar deposu/anahtar çifti inceleme aracı) gibi uç noktalar bu yakalamanın her zaman dışındadır — bu ayar açık olsa bile bu uç noktaların istek gövdesi hiç saklanmaz.
• 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. Bir API İstemcisi için elle girilen yeni bir gizli anahtar (secret) değeri de artık bu korumaya dahildir; önceki sürümlerde bu değer istek gövdesinde açık metin olarak görünebiliyordu.
• Bu koruma yalnız tek bir nesne taşıyan gövdelerle sınırlı değildir: birden fazla kayıt içeren istek gövdelerinde de her kayıttaki gizli alan aynı şekilde temizlenir. İstek gövdesi beklenmeyen bir veri nedeniyle sunucu tarafında ayrıştırılamadığında bile gizli alanların adları gövdeden çıkarılmaya çalışılır; hiçbiri güvenle çıkarılamıyorsa gövde o istek için hiç kaydedilmez.
• Kaydedilen gövde bir SIEM hedefine yalnızca Referans nesnesini yüke ekle açıkken, data.reference alanı ü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 Manager İ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ı ve vektör veritabanı 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 Reddedildi 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 Reddedildi kaydı üretir, burada ikinci kez kaydedilmez.

not

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 tüketiciye bir API Proxy'nin metotlarına erişim izni verildiğinde. Metot başına değil, proxy × tüketici başına tek satır yazılır.	Kaynak (ACL ekranı veya Portal), gerekçe tipi, tüketici 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 tüketicinin bir API Proxy'nin metotlarına erişimi kaldırıldığında. Aynı şekilde proxy × tüketici başına tek satır yazılır.	Erişim Verildi (ACL) ile aynı.	Başarılı.

not

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.

Proje Silme Olayı

Bir proje silindiğinde Proje Silindi olay tipiyle tek bir özet kayıt yazılır. Kayıtta şu bilgiler bulunur: sonuç (başarılı, kısmi veya başarısız), silinen kayıt sayısı, tamamlanan adım sayısı, silme anında aktif yasal saklama sayısı, süre ve başarısız adımlar (ilk 20). Sonuç başarısız ise denetim kaydının sonucu da Başarısız olur; kısmi sonuç (örneğin worker'a ulaşılamaması) özet bilgisinde belirtilir. Silme işlemi hakkında ayrıntı için bkz. Proje Silme.

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

bilgi

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 Kaydı — detay ve JSON Diff

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.

Davranış değişikliği

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.

not

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.