GDPR Uyumlu Veritabanı Tasarımı: Teknik Mimari ve Şema Rehberi

GDPR Uyumlu Veritabanı Tasarımı: Tasarım Yoluyla Veri Koruma ve Teknik Şema Mimarisi

Avrupa Birliği Genel Veri Koruma Yönetmeliği (GDPR), şirketlerin kişisel verileri işlerken yalnızca idari ve hukuki önlemler almasını yeterli bulmaz. Yönetmeliğin 25. Maddesi (Data Protection by Design and by Default - Tasarım Yoluyla ve Varsayılan Olarak Veri Koruma), veri koruma ilkelerinin daha yazılım geliştirme aşamasındayken sisteme entegre edilmesini zorunlu kılar. Bu doğrultuda, sistemin kalbi olan veritabanı mimarisinin GDPR uyumlu olarak tasarlanması, hem cezai riskleri azaltmak hem de kullanıcı güvenini kazanmak adına hayati bir öneme sahiptir.

Bu teknik kılavuzda, resmi GDPR maddelerine ve Avrupa Veri Koruma Kurulu (EDPB) kılavuzlarına dayanarak, uyumlu bir veritabanı şemasının nasıl tasarlanması gerektiğini somut örneklerle ele alacağız.

1. Resmi Yasal Dayanaklar ve Veritabanı Mimarisindeki Yansımaları

GDPR kapsamında veritabanı tasarlarken temel almamız gereken dört temel ilke mevcuttur (GDPR Madde 5):

• Veri Minimizasyonu (Data Minimisation - Madde 5(1)(c)): Veritabanında yalnızca işleme amacı için kesinlikle gerekli olan veriler tutulmalıdır. "Gelecekte belki kullanırız" düşüncesiyle fazladan kolon eklenmemelidir.
• Saklama Sınırlaması (Storage Limitation - Madde 5(1)(e)): Kişisel veriler, işleme amacının gerektirdiği süreden daha uzun süre saklanmamalıdır. Veritabanı mimarisi, otomatik veri silme (purging) veya anonimleştirme süreçlerini desteklemelidir.
• Bütünlük ve Gizlilik (Integrity and Confidentiality - Madde 32): Kişisel verilere yetkisiz erişimi engellemek için şifreleme (encryption) ve erişim kontrolü veritabanı seviyesinde de uygulanmalıdır.
• Hesap Verilebilirlik (Accountability - Madde 5(2)): Hangi verinin ne zaman, kim tarafından ve hangi rıza beyanına (consent) dayanılarak işlendiği doğrulanabilir olmalıdır.

2. Teknik Mimaride GDPR Uyum Adımları

A. Kişisel Verilerin (PII) Ayrıştırılması ve Takma Adlandırma (Pseudonymisation)

GDPR Resital 26'da tanımlanan Pseudonymisation (Takma Adlandırma), kişisel verilerin ek bilgi kullanılmaksızın belirli bir veri sahibiyle ilişkilendirilemeyecek şekilde işlenmesini ifade eder.

Veritabanı düzeyinde bunu sağlamanın en etkili yolu, PII (Personally Identifiable Information - Kişisel Olarak Tanımlanabilir Bilgi) barındıran kolonları (ad, soyad, e-posta, telefon vb.) ana operasyonel tablolardan ayırmak ve bunları farklı erişim yetkilerine sahip izole tablolarda saklamaktır.

B. Unutulma Hakkının (Right to Erasure / Madde 17) Uygulanması

Kullanıcılar verilerinin silinmesini talep ettiğinde, teknik ekiplerin en sık düştüğü hata veritabanında sadece bir is_deleted = true (soft delete) flag'i kullanmaktır. Hukuki açıdan bakıldığında, soft delete veriyi sistemden fiilen silmediği için GDPR Madde 17 uyumluluğunu sağlamaz.

Kullanıcı silindiğinde şu iki yöntemden biri uygulanmalıdır:

1. Hard Delete (Fiziksel Silme): Kullanıcıya ait tüm PII satırlarının veritabanından kalıcı olarak silinmesi (ilişkili tablolarda ON DELETE CASCADE veya özel trigger'lar kullanılarak).
2. Geri Döndürülemez Anonimleştirme: Kullanıcı kimliğini belirten alanların rastgele hash değerleri veya boş verilerle ezilmesi (e-posta adresinin deleted_user_1234@anon.com yapılması gibi). Bu yöntem, geçmiş finansal raporların ve istatistiklerin bozulmaması için tercih edilir.

C. Rıza Yönetimi (Consent - Madde 7) ve Denetim Günlüğü (Audit Trail)

Kullanıcıların hangi tarihte, hangi Gizlilik Sözleşmesi (Privacy Policy) sürümünü onayladığını kanıtlayabilmek yasal bir zorunluluktur. Bu amaçla veritabanında her rıza işlemini zaman damgası (timestamp) ve IP adresi ile kaydeden bağımsız bir log tablosu bulunmalıdır.

3. Örnek SQL Şeması: GDPR Uyumlu Kullanıcı Yapısı

Aşağıdaki PostgreSQL şeması, kişisel verilerin operasyonel verilerden ayrıştırıldığı, rıza yönetiminin izlendiği ve veri saklama sürelerine uygun yapılandırılmış profesyonel bir veritabanı mimarisini göstermektedir.

-- 1. ADIM: Ana Kullanıcı Tablosu (PII içermez, sadece ilişkisel ID ve takma ad barındırır)
CREATE TABLE users (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    pseudonym_id VARCHAR(50) UNIQUE NOT NULL, -- Dış analiz araçlarına verilecek anonim ID
    created_at TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP,
    updated_at TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP
);

-- 2. ADIM: Kişisel Veriler (PII) Tablosu (Şifrelenmiş ve izole edilmiş)
CREATE TABLE user_profiles_pii (
    user_id UUID PRIMARY KEY REFERENCES users(id) ON DELETE CASCADE,
    -- Hassas kolonlar şifrelenmiş (encrypted) olarak saklanmalıdır
    encrypted_first_name BYTEA NOT NULL,
    encrypted_last_name BYTEA NOT NULL,
    email VARCHAR(255) UNIQUE NOT NULL,
    phone_number VARCHAR(50),
    birth_date DATE,
    updated_at TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP
);

-- 3. ADIM: Rıza (Consent) Kayıt Tablosu (Madde 7 Uyum Logu)
CREATE TABLE user_consents (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    user_id UUID NOT NULL REFERENCES users(id) ON DELETE CASCADE,
    policy_version VARCHAR(10) NOT NULL, -- Örn: 'v2.1'
    consent_given BOOLEAN DEFAULT FALSE,
    given_at TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP,
    ip_address VARCHAR(45) NOT NULL, -- IPv4 veya IPv6 desteği için 45 karakter
    user_agent TEXT
);

-- 4. ADIM: İşlemsel Veriler (Kişisel veri barındırmaz, istatistik amaçlı tutulur)
CREATE TABLE user_transactions (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    user_id UUID REFERENCES users(id) ON DELETE SET NULL, -- Kullanıcı silinse de işlem verisi kalır, anonimleşir
    amount DECIMAL(10, 2) NOT NULL,
    transaction_date TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP
);

Şema Tasarımının Avantajları:

1. ON DELETE CASCADE: Kullanıcı kaydını sildiğinizde (DELETE FROM users WHERE id = ...), kullanıcının ad, soyad ve e-posta gibi kişisel bilgileri (user_profiles_pii) ve rıza geçmişi otomatik olarak veritabanından fiziksel olarak silinir.
2. ON DELETE SET NULL: Kullanıcı silindiğinde finansal işlemler silinmez, ancak user_id alanı NULL yapılarak işlem verisi tamamen anonim hale getirilir. Böylece ciro ve muhasebe raporlarınız bozulmadan GDPR Madde 17'ye tam uyum sağlanır.
3. Pseudonymisation: Üçüncü taraf analitik araçlarına veya veri bilimcilere users tablosundaki pseudonym_id verilir, böylece gerçek kimlikler gizli kalır.

4. Güvenlik ve Veri Koruma Yükümlülükleri (Madde 32)

Veritabanı düzeyinde şifreleme iki ana katmanda uygulanmalıdır:

1. Durağan Verilerin Şifrelenmesi (Encryption at Rest): Veritabanı sunucusunun fiziksel olarak çalınması veya disk kopyalanması durumuna karşı tüm veri diski (AWS KMS veya PostgreSQL transparent data encryption kullanılarak) şifrelenmelidir.
2. Sütun Bazlı Şifreleme (Column-Level Encryption): SQL injection gibi uygulama düzeyi saldırılarda veritabanı sızdırılsa bile, isim ve soyisim gibi hassas verilerin okunamaması için uygulama katmanında AES-256 gibi güçlü algoritmalarla şifrelenip veritabanına BYTEA tipinde yazılması gerekir.

5. Sıkça Sorulan Sorular (FAQ)

Soru 1: Veritabanında kişisel verileri "soft delete" (is_deleted flag) ile silmek GDPR uyumlu mudur?

Cevap: Hayır. GDPR Madde 17 (Unutulma Hakkı) kapsamında verinin sistemden fiilen silinmesi veya geri döndürülemez şekilde anonim hale getirilmesi gerekir. Salt görünürlüğü kapatan bir is_deleted bayrağı kullanmak, veri hala diskte okunabilir olduğu için yasal gerekliliği karşılamaz.

Soru 2: Takma adlandırma (Pseudonymisation) veriyi tamamen anonimleştirir mi?

Cevap: Hayır. GDPR Resital 26'ya göre takma adlandırılmış veri, ek bilgi veya tablolar birleştirilerek hala kimlik tespitine izin veriyorsa kişisel veri statüsünü korur. Tam anonimleşme ancak verinin hiçbir şekilde geriye döndürülemeyecek hale getirilmesiyle sağlanır.

Soru 3: Veritabanı loglarında (Audit trail) kişisel veri tutulabilir mi?

Cevap: Hayır. Hata analizi veya denetim amacıyla tutulan log kayıtlarında şifrelenmemiş PII (isim, e-posta, şifre, vb.) bulunmamalıdır. Loglarda sadece işlemin kimliği (User ID), zamanı ve işlem türü tutulmalı, hassas veriler maskelenmelidir.

Sonuç

GDPR uyumlu bir veritabanı tasarımı sadece yasal bir yükümlülük değil, aynı zamanda olası bir veri sızıntısında (data breach) şirketin alacağı cezayı doğrudan etkileyen bir faktördür. Tasarım yoluyla veri koruma ilkesine sadık kalarak, PII verilerini izole eden, unutulma hakkını teknik olarak cascade yapılarıyla otomatikleştiren ve rıza geçmişini değiştiremez şekilde loglayan yapılar kurmak sürdürülebilir bir yazılım geliştirme sürecinin temel taşıdır.