Log Konnektörü Eklenmesi
Gateway Runtime ortamlarında API Proxy'ler üzerindeki API trafiğinin kayıt altına alınması söz konusu olduğunda aşağıdaki ayarlar ile ilgili logların nerede saklanması gerektiği ayarı yapılabilmektedir. Gateway Runtime ortamlarındaki API trafiğini diğer ortamlara göndermek için aşağıdaki konnektörler kullanılabilir:
Bu konnektörlere gönderilecek olan verinin yapısını incelemek için şu dokümana göz atabilirsiniz.
Log konnektörü eklenmesini içeren görsele aşağıda yer verilmiştir:
- Apinizer Yönetim Konsolunda ilgili API Trafiğinin sorgulanması ve analitik olarak görselleştirilmesi ancak ilgili Gateway Runtime ortamına Elasticsearch Konnektörü eklenmesi ile mümkün olmaktadır.
- Eğer birden fazla Elasticsearch Konnektörü tanımlanması durumunda Apinizer Yönetim Konsolunda ilk eklenen Elasticsearch Konnektöründeki veriler görüntülenebilir.
- Eğer Elasticsearch Konnektörü hiç eklenmemiş ise aşağıdaki alanlar/menüler tamamen kapatılır:
- Analitikle ilgili tüm ekranlar ve menüler
- API Proxy'nin Trace, API Trafiği ve Analitikler sekmeleri
- Monitör menüsündeki Anomali Dedektörü
- Yönetim menüsündeki Genel Bakış'a ait Analitik kısmı
- OAuth2 politikası
- Test konsolda yer alan Log sekmesi
- Denetim menüsünde yer alan Token İstekleri
- Rapor oluşturucu menüsü
- Portaldaki Pano ve API Trafiği
Konnektörlerdeki Ortak Alanlar
Konnektör oluşturulurken her tip için aynı olan bazı girdi alanları vardır. Bu bilgiler aşağıdaki görselde seçili alanlardır.
Konnektörlerdeki ortak bilgilerin konfigürasyonu için kullanılan alanlar aşağıdaki tabloda görülmektedir.
| Alan | Açıklama |
|---|---|
| API Proxy Trafik Log Ayarları Ayrıntılarını Yapılandır (Configure API Proxy Traffic Log Setting Detail) | Bu ayar aktifleştirildiğinde loglanacak olan alanlar seçilir. Loglama için gönderilecek alanlar arasında uzun metinler yer alıyorsa bu alanlar için boyut limiti ayarlanabilir. |
| Etkinleştirilse, API Proxy'sinin bulunamadığı veya mevcut olmadığı tüm trafik log kayıtları da hedefe aktarılır (If enabled, all traffic logs of which API proxy is not found or not exists are also exported to target) | Bu ayar ile istenirse API Proxy'nin bulunmadığı veya mevcut olmadığı tüm trafik logları da hedefe aktarılır. |
| API Proxy Trafik Gizlilik Ayarlarını Yapılandır (Configure API Proxy Traffic Privacy Setting) | Bu ayar aktifleştirildiğinde log kayıtları içerisinde açık bir şekilde erişilmesi istenmeyen verilerin, olduğu gibi görüntülenmesinin önüne geçilebilir. Bu bölüme ilişkin detaylı bilgi aşağıda anlatılmaktadır. |
| Etkinleştirilirse, gönderilmemiş istekler failover bağlantısına gönderilir (If enabled, unsent requests will be sent to failover connector) | Konnektör çevrimdışıysa veya erişilemiyorsa, bu durumda gönderilemeyen log kayıtları için yeni failover bağlantısı tanımlanabilir. |
| Failover Executable Tipi (Failover Connector Type) | Tanımlanacak failover konnektörünün tipi seçilir. |
| Tip | Failover tipinin Veritabanı (Database) seçilmesi durumunda bu alan aktifleşir. Veritabanı tipi seçilir. |
| Failover Bağlantısı (Failover Connection) | Seçilen failover tipine göre tanımlanacak failover bağlantısı seçilir. |
| Operasyon (Operation) | Failover tipinin Veritabanı (Database) seçilmesi durumunda bu alan aktifleşir. Operasyon tipi seçilir. |
Bu ekrandan birincil log alıcısının kendisi pasif hale getirilirse, failover konnektör tanımlı olsa bile o alıcı için hiçbir log üretilmez. Failover yalnız aktif bir alıcıya erişilemediğinde devreye girer; kapatılmış bir alıcı için geçerli değildir.
Veritabanı Alıcısında Operasyon Alanı
Bir Veritabanı log alıcısı eklerken veya düzenlerken, Operasyon alanı seçilen veritabanı tipinden bağımsız olarak her zaman tek seçenek sunar: Insert-Update-Delete. MongoDB ve Trino dahil tüm tipler için geçerlidir. Daha önce eski bir değerle kaydedilmiş bir alıcı düzenlemeye açıldığında Operasyon Insert-Update-Delete olarak görünür; kayıtlı değer ancak Kaydet'e basıldığında değişir. Stored Procedure seçeneği bu ekrandan kaldırılmıştır çünkü hiçbir zaman log yazmıyordu; Job, Alert ve Task Flow Routing'de kullanılan Stored Procedure seçeneği bundan etkilenmez.
Aynı diyalog SIEM ve Log Yönlendirme ekranında ve bir portalın Login Log ayarlarında da paylaşılır; bu davranış oralarda da geçerlidir.
Enable Failover Connector (Failover Konnektörünü Etkinleştir) seçeneği ve Configure API Proxy Traffic Log Setting Detail altındaki detay filtre anahtarları artık bir Veritabanı alıcısında hatasız açılır; önceden bu alıcı tipinde açılmıyordu.
API Proxy Trafik Log Ayarları Ayrıntılarını Yapılandırma
"Configure API Traffic Log Setting Detail" (API Trafik Log Ayarları Ayrıntılarını Yapılandırma) seçeneği etkinleştirildiğinde, API trafik loglarının nasıl kaydedileceğini özelleştirebilirsiniz. Apinizer logları, sistemdeki trafik akışına göre dört farklı bölgeye ayrılmıştır.
API Trafik Log Bölgeleri
Apinizer, API trafiğini bu dört bölgede loglar:
- Client'tan Apinizer'a Gelen İstek (Request from Client)
- Apinizer'dan Backend'e Giden İstek (Request to Target)
- Backend'den Apinizer'a Gelen İstek (Response from Target)
- Apinizer'dan Client'a Giden İstek (Response to Client)
"Configure API Traffic Log Setting Detail" seçeneği etkinleştirildiğinde, bu bölgelerin her biri için loglama özelleştirilebilir.
Varsayılan olarak, tüm mesaj bölgelerindeki alanların loglanması aktiftir. Loglanan alanlar ihtiyaca göre veya log sunucusunun kaynak tüketimi baz alınarak kısıtlanabilir.
Üretim Gateway Runtime ortamı için aşağıdaki bölgelere ait ögeleri loglama işleminin devre dışı bırakılması tavsiye edilmektedir:
- Apinizer'dan Backend'e Giden İstek (Request to Target)
- Backend'den Apinizer'a Gelen İstek (Response from Target)
Eğer bir API Proxy üretim Gateway Runtime ortamında çalışıyorsa, API Proxy'deki tüm poliçelerin ayarları ve testleri tamamlandığı ve artık geliştirme yapılmayacağı anlamına gelmektedir. Bu yüzden veri tabanında verilerinin aşırı büyümemesi için bu iki bölgedeki başlık, parametre ve gövde verilerinin yazılmaması tavsiye edilir.
Tüm loglama alanları kapalı olsa dahi istekte bir hata oluştuysa log alanlarının tümü hatanın tespit edilebilmesi için kayıt edilir. Bu özellik genel ayarlarda açılıp, kapatılabilir.
Formdata istekleri değişken veri büyüklükleri ve veri formatları nedeniyle dosya kısımları hiçbir şekilde loglanmamaktadır. Sadece diğer metadata alanları loglanmaktadır.
WebSocket ve gRPC istekleri Apinizer'a gelen ve Apinizer'dan çıkan veriler şeklinde tutulmakta olduğundan bu tip API Proxylerde sadece 2 bölge vardır.
Log Ayarları Ekranı
"Configure API Traffic Log Setting Detail" seçeneği etkinleştirildiğinde karşımıza gelen log ayarları ekranını içeren görsele aşağıda yer verilmiştir:
Bu ekranda her bölge için hangi alanların loglanacağı seçilebilir ve uzun metinler içeren alanlar için boyut limiti ayarlanabilir.
Özelleştirilebilir Log Alanları
API traffic log ayarlarında özelleştirilebilecek alanlar aşağıda verilmiştir. Her alan için loglanıp loglanmayacağı seçilebilir ve uzun metinler içeren alanlar için boyut limiti ayarlanabilir.
| Grup | İçerik |
|---|---|
| HTTP Request Details | IP, Method, URI, Port |
| Performance Metrics | Duration, Size, Cache |
| Response Status Info | Status Code, Error Type |
| Routing Address | Routing Address |
Bu gruplar birbirinden bağımsızdır; bir grubu devre dışı bırakmanız diğer grupları etkilemez.
Request and Response Flow bölümünde ise log akışının her bir bölgesi için aşağıdaki alanları ayrı ayrı açıp kapatabilirsiniz:
- Request from Client: Parameter, Header, Body
- Request to Target: Parameter, Header, Body
- Response from Target: Header, Body
- Response to Client: Header, Body
Uzun içeriklerin log boyutunu sınırlandırmak için her bölge için Partial Size seçeneğini etkinleştirip karakter bazında limit belirleyebilirsiniz.
Boyut Limitleri
Loglama için gönderilecek alanlar arasında uzun metinler yer alıyorsa bu alanlar için boyut limiti ayarlanabilir. Bu sayede log kayıtlarının boyutu kontrol altında tutulabilir ve veri tabanı veya log hedef sistemindeki depolama alanı optimize edilebilir.
Her alan için ayrı ayrı boyut limiti belirlenebilir. Belirlenen limit aşıldığında, ilgili alanın içeriği kesilerek loglanır veya tamamen atlanabilir.
İstisna: Bir API Proxy'nin Bu Kısıtları Ezmesi
Burada yapılandırdığınız detay filtresi ve boyut sınırları ortam geneline ait bir kuraldır: trafiği bu konnektöre ulaşan her API Proxy için geçerlidir. Kimi zaman tek bir proxy kuralın izin verdiğinden fazlasına ihtiyaç duyar — örneğin incelemeye alınmış bir ödeme entegrasyonu, ortam genelinde gövde loglaması kapalıyken.
Bu istisna artık konnektör tarafında değil, doğrudan ilgili API Proxy'nin kendi Log Ayarları sekmesinde yönetilir: Ortam kısıtlarını ez anahtarı açıldığında, o proxy bu konnektördeki detay filtresinden ve boyut limitlerinden muaf tutulur. Konnektörden ayrıca bir izin ayarı beklenmez; karar tek başına proxy sahibine aittir.
Konnektör penceresinde bu durumu takip edebilmeniz için "Bu filtreyi ezen API Proxy'ler: N" satırı görünür; N, o an bu kısıtı ezen proxy sayısıdır. Sayı sıfırdan büyükse satır tıklanabilir: açılan salt-okunur pencerede ezen her API Proxy'nin adı ve bağlı olduğu proje adı listelenir. Bu pencereden herhangi bir değişiklik yapılamaz — istisnayı açmak veya kapatmak yine ilgili proxy'nin kendi Log Ayarları sekmesinden yapılır. Konnektör henüz kaydedilmemiş bir ortamda bu satır görünmez.
Gizlilik ayarları bu anahtarın tamamen dışındadır. Maskeleme, hash'leme, silme ve şifreleme kuralları ezmeden bağımsız olarak her kayıtta çalışmaya devam eder; çünkü bunlar bir görüntüleme tercihi değil, veri koruma yükümlülüğüdür. Veri saklama profili de etkilenmez: No Payload veya No Persist yürürlükteyken gövde hiç toplanmaz ve ezmenin yeniden açacağı bir şey kalmaz.
Ayar proxy tarafında kaydedildiğinde anında geçerli olur, API Proxy'nin yeniden dağıtımı (redeploy) gerekmez.
Hata Durumunda Devre Dışı Alanları Loglama
Konnektör eklenirken Override on Block / Failure bölümündeki iki seçenek ile, kapalı olarak işaretlenmiş loglama alanlarının (başlık, parametre, gövde gibi) belirli durumlarda yine de loglanması sağlanır:
| Alan | Açıklama |
|---|---|
| Engellenme durumunda devre dışı alanları logla (Log disabled fields when request is blocked by policy) | Bir politika isteği engellediğinde (örneğin yetkilendirme başarısız olduğunda), bu konnektöre gönderilen logda kapalı tutulan alanlar yine de gönderilir. Engelleme nedeninin ve istek sahibinin tespiti için kullanışlıdır. |
| Hata durumunda devre dışı alanları logla (Log disabled fields on policy failure or error) | İstek veya yanıt hattında bir hata oluştuğunda, bu konnektöre gönderilen logda kapalı tutulan alanlar yine de gönderilir. Hatanın hangi mesaj içeriğinden kaynaklandığının analizi için kullanışlıdır. |
Bu seçenekler daha önce Genel Ayarlar üzerinden tüm platform için tek noktadan yönetilirken, artık her konnektör için bağımsız olarak yapılandırılabilir.
API Proxy Trafik Gizlilik Ayarlarını Yapılandırma
Apinizer üzerinden akan mesaj trafiğinin (istek ve yanıt) kayıtlarını tutmaktadır.
Mesajların herhangi bir bölümünde (başlık, parametre, gövde) kredi kartı bilgileri, şifre, telefon numarası gibi hassas ya da kişisel veriler bulunabilir.
Bu verilerin log kayıtları içerisinde açık bir şekilde erişilmesi istenmediği durumlarda Apinizer "API Proxy Trafik Gizlilik Ayarları" ile log kayıtları içerisindeki hassasiyet/gizlilik taşıyan alanlara aşağıdaki işlemleri uygulayarak, verinin olduğu gibi görüntülenmesinin önüne geçilebilir:
API Proxy bazlı log ayarları için API Proxy Konfigürasyonu - Ayarlar Sekmesi sayfasındaki API Trafik Log Ayarları bölümüne bakabilirsiniz.
- Maskeleme: Alanın değerine * işaretiyle maske uygulanır.
- Silme: Alanın değeri loglanırken silinir.
- Şifreleme: Uygulama bazında üretilen salt kodu ile alanın değeri şifrelenir.
- Hashleme: Alanın değeri hashlenerek loglanır.
API Proxy Trafik Gizlilik Ayarları, sadece Apinizer üzerinde tutulan log kayıtlarındaki verinin saklanması ile ilgilidir. Herhangi bir şekilde Backend API'ye giden veri veya Client'a dönen veri ile ilgili değildir! Bu veriler üzerinde işlem yapmak için politikalardan faydalanabilirsiniz.
Gizlilik Ayarlarının Uygulanması
Log kaydının oluşturulması zamanında istek ve yanıt mesajlarının "başlık, parametre, gövde ve istek adresi (URL)" alanları üzerinde tarama yapılır. Bir kuralın veriyi nasıl bulacağı, tanım eklenirken seçilen Kural tipi ile belirlenir: element adı (bir alanın, başlığın ya da sorgu parametresinin adı), düzenli ifade (regex) veya yerleşik kişisel veri tipi (TC Kimlik No, IBAN, telefon, e-posta, kredi kartı ve benzeri). Eşleşme bulunduğunda kural üzerinde tanımlı işlem (maskeleme, silme, şifreleme, hashleme) uygulanır.
İstek veya yanıt gövdesi üzerinde element adının aranması için gövde değerinin XML, JSON veya Form verisi (form-data, x-www-form-urlencoded) olması gereklidir.
Veri eğer XML veya JSON ise tüm element isimlerinde (recursive olarak), form verisi ise tüm anahtar kelimelerde "hassas veri element adı" değeri aranır, bulunması durumunda XML veya JSON ise element değerine, form verisi ise anahtar karşılığındaki değere ilgili işlem (maskeleme, silme, şifreleme, hashleme) uygulanır. Veri üzerindeki ilgili element/anahtar adının sonuna da işlem yapıldığını belirtmek amacıyla "-PA" suffix'i eklenir. PA: Privacy Applied anlamındadır.
Tanımlanan bir alan başına "API Proxy Trafik Gizlilik Ayarları"nın uygulanması için şu alanların tamamında tarama yapılır:
- İstemciden Gelen Mesajın Başlık, Sorgu(Query) Parametresi ve Gövdesi
- Backend'e Giden Mesajın Başlık, Sorgu(Query) Parametresi ve Gövdesi
- Backend'den Dönen Mesajın Başlık ve Gövdesi
- İstemciye Dönen Mesajın Başlık ve Gövdesi
- Loglanan istek adresi: sorgu (query) dizesi ve istek yolu
Sorgu dizesi her iki kural türüyle de kapsanır: element adı kuralı, parametre listesindeki id değerini nasıl gizliyorsa ?id=... içindekini de aynı şekilde gizler; desen kuralları ise değerin kendisini eşler. İstek yolu yalnızca düzenli ifade ya da yerleşik tiple kapsanır; çünkü bir yol parçasının eşleşecek bir adı yoktur — /user/12345678901 içindeki numara böyle gizlenir. Adrese yüzde-kodlu gelen değerler (user%40example.com) desen uygulanmadan önce çözülür; hiçbir kural eşleşmezse adres geldiği gibi loglanır. Proxy'nin kendi yönlendirme adresi bilerek değiştirilmez, çünkü trafik listeleri ve raporlar bu alana göre gruplanır.
Taranan alanlardan da anlaşılacağı üzere API Proxy Trafik Gizlilik Ayarları performans anlamında maliyetli bir işlemdir.
Loglama işlemleri asenkron yapıldığından her ne kadar API Trafiğine etkisi olmasa da yoğun olarak kullanılacaksa işlemci gücüne olacak etkisi göz önüne alınarak sistem konfigürasyonu yapılmalıdır.
Tanımlar Ekranı
"API Proxy Trafik Gizlilik Ayarları"nı aktif hale getirmek için Aktifleştir seçeneği etkin olmalıdır.
API Proxy Trafik Gizlilik Ayarları aktifleştirildiğinde karşımıza gelen ekranı içeren görsele aşağıda yer verilmiştir:
Her tanım için önce Kural tipi seçilir (Element Adı, Regex ya da Yerleşik), ardından o tipe ait giriş doldurulur — element adı, düzenli ifade ya da listeden bir kişisel veri tipi — ve bu tanıma ne yapılacağı (işlem bilgisi) belirtilir. Ekle tuşu ile tanım listesine eklenir. Kural tipi değiştirildiğinde diğer tiplere ait girişler temizlenir; böylece bir tanım her zaman tek bir eşleşme yöntemi taşır.
Burada tanımlanan bir element adı ve ilgili işlem tüm API Proxyler için geçerli olur.
Bir tanım oluşturulduğunda otomatik olarak tüm API Proxy'lere eklenir. Bir tanım silindiğinde ise tüm API Proxy'lerden bu ayar kaldırılır.
Eğer bir API Proxy yoksa, gelen isteklere tanımların hepsi uygulanır.
Salt (Tuz) Nedir?
API Proxy Trafik Gizlilik Ayarları işlemlerinden bir tanesi de hashlemedir.
Hashleme yöntemi seçildiğinde verinin bir algoritma ile geri dönüşmeyecek şekilde hashlenerek tutulması sağlanır. Hashlenen veri tek yönlüdür, ve geri getirilemez. Sadece hashli verinin tekrar oluşturulması sağlanabilir.
Salt ile normalde hash algoritması seçilerek oluşacak olan çıktının farklı oluşması sağlanarak hashlenen değerin kıyaslama yapılarak bulunabilmesinin önüne geçilir.
API Proxy Trafik Gizlilik Ayarları ilk aktif hale getirildiğinde Apinizer bir tane salt değeri oluşturur ve verileri bununla hashler.
Normalde her değerin farklı saltlar ile hashlenmesi daha doğru gibi gözükse de, bazı durumlarda verinin aranarak bulunması veya verinin değerinin doğru olduğunun da bilinmesi gerekliliği oluşabileceğinden, bu salt Apinizer tarafından değiştirilmeden gizli bir şekilde saklanır. Kullanıcıya ise değer girerek aynı hashli veriyi ekran üzerinden oluşturabilmesine izin verilir.