By · Last updated 2026-06-05

Bloga DönTeknik

Uygulama Loglarında GDPR: JSON KKV Uyum Rehberi

Uygulama logları; GDPR Madde 5(1)(e) kapsamında yönetilmesi gereken müşteri e-posta adreslerini, IP'leri ve hesap numaralarını barındırır.

June 5, 20266 dk okuma
API logsGDPR complianceJSON anonymizationobservabilitystorage limitation

Log Yığınınızdaki Sessiz GDPR Riski

2026 için güncellendi

Çoğu ekip kişisel veri için yalnızca veritabanını kontrol eder. Log sistemini aynı titizlikle inceleyen ekip sayısı ise çok daha azdır.

GDPR Madde 5(1)(e), kişisel verilerin ne kadar süre saklanabileceğini sınırlandırır. Veritabanları için ekipler politikalar belirler ve silme işlemleri çalıştırır. Log dosyaları için kural genellikle daha basittir: hata ayıklama amacıyla her şeyi 90 gün saklayın.

Sorun şu ki bu kayıtlar kişisel veri içerir. İstek girdileri kullanıcı e-postalarını barındırır. Hata kayıtları ham girdi değerlerini tutar. Erişim kayıtları IP adreslerini içerir. Bunların tamamı GDPR kapsamında kişisel veri sayılır. Ekibinizin her biri için hem hukuki dayanak hem de saklama planı oluşturması gerekir.

Log Dosyalarınıza Ne Düşer?

Standart bir web uygulaması loglama sürecinde çok geniş bir KKV yelpazesi toplanır.

Erişim kayıtları (nginx/Apache):

  • IP adresleri — EDPB rehberine göre kişisel veri
  • Kullanıcı ajanı (user-agent) dizileri — cihaz parmak izi çıkarmayı mümkün kılabilir
  • Oturum belirteçleri — çıktıya yazıldığında

Uygulama kayıtları (yapılandırılmış JSON):

  • Kullanıcı kimlikleri ve e-posta adresleri
  • Girdi hataları — çoğunlukla ham geçersiz değeri içerir; bu değer gerçek kullanıcı bilgisi olabilir
  • İş olayları — müşteri hesaplarına bağlı sipariş kimlikleri
  • Arama sorguları — ad veya adres içerebilir

API ağ geçidi kayıtları:

  • Kimlik doğrulama başlıkları — bazı yapılandırmalarda kısmen yakalanır
  • Sorgu parametreleri — kullanıcı kimliklerini, adları veya e-postaları taşıyabilir
  • İstek ve yanıt gövdeleri — hata ayıklama düzeyindeki yapılandırmalarda mevcut

Veritabanı denetim girdileri:

  • email = 'user@example.com' gibi WHERE koşulları içeren SQL sorguları
  • Sorgu parametrelerindeki gerçek kişisel değerler

Bu durum kasıtlı değildir. Loglama, GDPR için değil hata ayıklama için tasarlandığından ortaya çıkan bir yan etkidir.

EDPB'nin IP Adresleri Hakkındaki Tutumu

Avrupa Veri Koruma Kurulu (EDPB), IP adreslerinin kişisel veri olduğunu açıkça belirtmektedir. İnternet servis sağlayıcıları bu adresleri abonelerine bağlayabilir. Kurum içinde ise belirli kullanıcıları tanımlamaya yarayabilirler.

Pratik sonucu doğrudan etkiler. IP adresi içeren erişim kayıtları kişisel kayıt niteliği taşır. nginx çıktısını 12 ay saklamak, kişisel veriyi 12 ay saklamak anlamına gelir. Bunun için Madde 6 uyarınca hukuki dayanak gerekmektedir. Ayrıca saklama süresinin belirtilen amaca uygun olması zorunludur.

Çoğu ekip bu adımı atlar. "Güvenlik ekibi 90 gün diyor, biz de öyle yapıyoruz" bir kural değil, sezgisel bir yaklaşımdır. GDPR Madde 5(1)(e) değerlendirmesi değildir. Bu konunun daha kapsamlı bir uyum programına nasıl oturduğunu görmek için Hukuki Uyum genel bakışımıza bakabilirsiniz.

Uyuma Nasıl Ulaşılır?

Çoğu ekip için pratik yol, saklama sürelerini kısaltmak değildir. Daha uzun sürelerin operasyonel ve güvenlik açısından gerçek gerekçeleri vardır. Daha iyi yol, kayıtları uzun vadeli depolamaya göndermeden önce maskelemektir.

Katmanlı bir model iyi çalışır.

0–7 gün: Aktif hata ayıklama için tam ham kayıtlar. Yedi gün, çoğu ekip için yeterince kısadır.

7–90 gün: Trend analizi ve güvenlik incelemesi için maskelenmiş kayıtlar. IP adresleri değiştirilir. Kullanıcı e-postaları kararlı belirteçlere dönüştürülür. Hesap numaraları maskelenir. Zaman damgaları, hata kodları, gecikme süreleri, uç noktalar gibi kritik alanlar olduğu gibi korunur.

90+ gün (gerekirse): Yalnızca toplu çıktı. Olay sayıları, hata oranları, gecikme aralıkları. Kullanıcı düzeyinde hiçbir kayıt kalmaz.

Kişisel veri yedi günde durur. Toplu çıktı ise kimseyi ifşa etmeden ileriye taşınabilir. Daha fazla ayrıntı için Güvenlik ve Uyum sayfamıza bakın.

İzleme İçin Yapıyı Koruyun

İyi bir maskeleme, JSON yapısını bütün tutar; yalnızca içeriği değiştirir. Bu sayede çıktı hata ayıklama ve uyarılar için kullanılabilir kalmaya devam eder.

Olduğu gibi korunanlar:

  • JSON anahtarları ve iç içe geçme
  • Zaman damgaları ve kronolojik sıra
  • Hata türleri ve HTTP durum kodları
  • HTTP metodları, yollar ve gecikme değerleri
  • İş olayı türleri

Değiştirilenler:

  • E-posta adresleri → orijinal başına kararlı belirteç (örn. user1@example.com)
  • IP adresleri → RFC 5737 aralıkları (192.0.2.x)
  • Hesap numaraları → ACCT_XXXXX
  • Telefon numaraları → +XX XXX XXX XXXX
  • Hata metnindeki adlar → [PERSON]

Kararlı belirteçler izleri kullanılabilir kılar. user1@example.com için 40 kayıt boyunca sürdürülen bir iz, orijinaliyle aynı işlevi görür. Hata oranları, gecikme, iş hacmi gibi toplu metrikler için kişisel veriye hiç gerek yoktur. Takma adlandırma ve anonimleştirme terimlerinin tanımları için Sözlük'e bakabilirsiniz.

Üç Entegrasyon Yöntemi

Üç pattern çoğu mühendislik ekibini kapsar.

Seçenek 1 — Pipeline maskeleme: Fluentd veya Logstash, her satırı iletmeden önce yakalar. Maskeleme adımı satır içi çalışır. Elastic veya Datadog yalnızca temizlenmiş kayıtları alır. Uygulama kodu değişikliği gerekmez.

Seçenek 2 — Gece toplu işlemi: Ham kayıtlar yerel depolamaya düşer. Gece çalışan bir iş, bir önceki günün çıktısını maskeler ve ham sürümü siler. Maskelenmiş kayıtlar uzun vadeli depolamaya gönderilir. Ham çıktı yalnızca yedi gün saklanır.

Seçenek 3 — Paylaşım öncesi maskeleme: Ham kayıtlar katı erişim denetimleriyle dahili olarak tutulur. Sızma testi uzmanları veya dış yüklenicilerle paylaşmadan önce bir maskeleme işlemi uygulanır. Dış taraflar her zaman temizlenmiş sürümleri alır.

GDPR belgelendirmesi açısından maskeleme, Madde 32 kapsamında bir "teknik tedbir" sayılır. Kullanılan aracı, yapılandırmasını ve saklama politikanızı Madde 30 uyarınca İşleme Faaliyetleri Kayıtlarınıza (RoPA) kaydedin. Yaygın RoPA soruları için SSS sayfamıza bakabilirsiniz.

Gerçek dünyadan örnekler görmek ister misiniz? Somut uygulama ayrıntıları için örnek olay incelemelerine göz atabilirsiniz. Yerleşik maskeleme pipeline'larını hangi planın kapsadığını öğrenmek için fiyatlandırmamızı da inceleyebilirsiniz.

Kaynaklar

Verilerinizi korumaya hazır mısınız?

48 dilde 285+ varlık türü ile PII anonimleştirmeye başlayın.

About this page

We update this page when our platform or the law changes.

Read our founder note for how we work.

Each change shows up in the timestamp at the top.

Related reading

We follow these rules

  • GDPR (EU 2016/679).
  • ISO/IEC 27001:2022.
  • NIS2 (EU 2022/2555).
  • HIPAA safe harbor under 45 CFR § 164.514(b)(2).

Our promise

We do not sell your data.

We do not train models on your text.

We store your files in Germany.

You can delete your account at any time.

You own your work.

Where we run

Our servers live in Falkenstein, Germany.

We use Hetzner. They hold ISO 27001 certification.

All data stays in the EU.

Backups run every day.

Need help?

Email support@anonym.legal.

We reply within one business day.

How we test

We run a full check suite on every release.

Each surface gets its own sweep script and report.

Human reviewers spot-check the output each week.

We track recall and precision on a labelled set.

Bad runs block the deploy.

What we never do

  • We never sell your information to third parties.
  • We never train models on what you upload.
  • We never keep your work after you delete it.
  • We never share keys with any outside firm.
  • We never run ads inside the product.

Plans in plain words

We sell credits, not seats.

One credit covers one short job.

Long jobs use a few credits each.

You can top up at any time.

Unused credits roll over each month.

Read the plans page for current rates.

Who built this

A small team of engineers and lawyers built this.

We ship from Europe and work in the open.

Our founder note spells out why we started.

Where to start

How the parts fit

A browser add-on cleans text inside Chrome.

A Word plug-in handles drafts in Office.

A small desktop tool works on whole folders.

An agent protocol link feeds large models safely.

All four share one core engine and one rule set.

Words from our team

We started this work after a lunch about cookies.

One friend kept getting odd ads on her phone.

We asked why a court file leaked through a draft.

We sketched the first build on a napkin that week.

By month three we had a tiny demo for a friend.

She used it on her first case the next day.

Common questions we hear

Can the tool read scanned PDFs? Yes, with OCR.

Does it work on long files? Yes, in small chunks.

Can I roll my own rule set? Yes, save it as a preset.

Does it run offline? The desktop build runs offline.

Do you keep my files? No, the cloud build wipes after each run.

Will it learn from my work? No, we never train on inputs.

A short tour of the workflow

Upload a file or paste a snippet of prose.

Pick the entities you want gone from the draft.

Choose a method: replace, mask, hash, encrypt, or redact.

Press run and watch the side panel show each hit.

Skim the result and tweak any rule that misfired.

Save the cleaned file or send it to a teammate.