Laravel Geliştiricileri için GDPR: Veri Depolama, Silme ve Sunucu Lokasyonu Deploynix Üzerinde

GDPR uyumluluğu, bir sunucu yapılandırması anahtarı veya yükleyeceğiniz bir Laravel paketi değildir. Bu, uygulamanızın her katmanını etkileyen bir yükümlülük setidir; veritabanı şemasından sunucu altyapısına kadar, kullanıcı arayüzünden başlayarak. Bir Laravel geliştiricisi olarak, hem uygulama kodunu hem de Deploynix aracılığıyla çalıştığı altyapıyı kontrol ediyorsunuz.

Bu rehber, GDPR uygunluğu için pratik ve kod odaklı bir yaklaşım izliyor. Kullanıcıların sahip olduğu hakları, bunları Laravel’de nasıl uygulayacağınızı, sunucularınızın nerede bulunması gerektiğini ve Deploynix’in altyapı özelliklerinin uyumluluk duruşunu nasıl desteklediğini ele alacağız. Yasal soyutlamalardan kaçınacağız. Sadece bu hafta alabileceğiniz somut adımlar sunacağız.

Yükümlülüklerinizi Anlamak

GDPR, bireylere kişisel verileri üzerinde belirli haklar tanır. Bu verileri işleyen uygulamayı geliştiren bir geliştirici olarak, bu haklar doğrudan uygulamanızda yapmanız gereken özelliklere ve yapılandırmanız gereken altyapıya dönüşür.

Laravel geliştiricileri için en ilgili haklar şunlardır:

Erişim Hakkı (Madde 15): Kullanıcılar, kendileri hakkında sahip olduğunuz tüm kişisel verilerin bir kopyasını talep edebilir. Veriyi uygulamanızın her yerinden toplamak ve yapılandırılmış bir formatta sağlamak için bir mekanizmaya ihtiyacınız var.

Silme Hakkı (Madde 17): “Unutulma hakkı” olarak da adlandırılır. Kullanıcılar, tüm kişisel verilerinin silinmesini talep edebilir; bazı yasal yükümlülükler için istisnalar olabilir. Bir kullanıcının verilerinin her izini bulup silmek için bir mekanizmaya ihtiyacınız var.

Veri Aktarım Hakkı (Madde 20): Kullanıcılar, verilerini yaygın olarak kullanılan, makine tarafından okunabilir bir formatta talep edebilir. API odaklı uygulamalar için standart seçim JSON’dur.

Düzeltme Hakkı (Madde 16): Kullanıcılar, yanlış kişisel verilere düzeltme talep edebilirler. Çoğu Laravel uygulamasında, bu, kullanıcı profilleri ve ilgili veriler için düzenleme işlevselliği sağlamadığınızda tatmin edilir.

Veri İşleme Kısıtlama Hakkı (Madde 18): Kullanıcılar, bir şikayet veya düzeltme talebi işlenirken verilerinin işlenmesini durdurmanızı talep edebilir.

Şimdi her birini Laravel’de pratik olarak uygulayalım.

Veri İhracı Hakkını Uygulamak

Veri ihracı, hem erişim hakkı hem de veri aktarım hakkı için temeldir. Uygulamanız, bir kullanıcı ile ilişkili tüm kişisel verileri toplamalı ve bunları indirilebilir bir dosya olarak sağlamalıdır.

Veritabanınızı denetlemeye başlayın. Her user_id yabancı anahtarını içeren veya kişisel olarak tanınabilir bilgileri depolayan her tablo ihraca dahil edilmelidir. Tipik bir Laravel uygulamasında, bu kullanıcılar tablosu, siparişler, adresler, destek biletleri, etkinlik günlükleri, yüklenen dosya metadata’ları ve bildirim tercihleri gibi tablolar olabilir.

Veri ihracı için özel bir hizmet sınıfı oluşturun. Bu hizmet, ilgili tablolardan kullanıcının verisini sorgulayıp yapılandırılmış bir JSON dosyasında derlemelidir. Aşağıdaki yaklaşımı dikkate alın:

class UserDataExportService
{
    public function export(User $user): array
    {
        return [
            'personal_information' => $this->getPersonalInfo($user),
            'orders' => $this->getOrders($user),
            'addresses' => $this->getAddresses($user),
            'support_tickets' => $this->getSupportTickets($user),
            'activity_log' => $this->getActivityLog($user),
            'preferences' => $this->getPreferences($user),
            'exported_at' => now()->toIso8601String(),
        ];
    }
}

Her metod, kullanıcının o alana ait verilerini bir dizi olarak döndürmelidir. İçsel tanımlayıcıları, yabancı anahtarları ve kişisel veri olmayan sistem meta verilerini temizlemek gerekecektir. Kullanıcı, stripe_customer_id ya da içsel order_status_id gibi bilgilerle ilgilenmeyecektir; onu ilgilendiren yalnızca adı, e-posta adresi, sipariş geçmişi ve oluşturduğu içeriğin görünmesidir.

Büyük veri kümesi durumunda, ihracı Laravel’in kuyruk sistemini kullanarak arka planda oluşturun. Deploynix’te, kuyruk işlerine ait görevler özel çalışan sunucularında çalıştığı için ihracat süreci uygulamanızın yanıt verme yetisini etkilemez. İhracat hazır olduğunda, kullanıcıyı geçici indirme bağlantısıyla e-posta yoluyla bilgilendirin.

İhracı sağlamadan önce kullanıcının kimliğini doğrulamak önemlidir. GDPR, talepte bulunan kişinin kimliğini doğrulamanızı gerektirir. Kimlik doğrulama sürecinde, doğrulanmış kullanıcıların ihracı başlatmadan önce şifrelerini yeniden girmelerini talep etmek genellikle yeterlidir.

Silme Hakkını Uygulamak

Silme hakkı, göründüğünden daha karmaşıktır. Sadece $user->delete() çağrısı yapmak ve işlemi tamamlamış saymak mümkün değildir. Kişisel verilerin her yerdeki izlerini bulup silmeniz gerekiyor; bu, yumuşak silinmiş kayıtlar, ilgili modeller, yüklenen dosyalar, önbellek kayıtları, oturum verileri, günlük dosyaları ve yedeklemeleri de dahil edilmelidir.

Sistematik bir yaklaşım şu şekildedir:

Adım 1: Tüm kişisel veri konumlarını tanımlayın. Kullanıcı modeline bağlantısı olan veya kişisel veri depolayan her modeli inceleyin. Bir kontrol listesi oluşturun. Yaygın konumlar şunlardır:

• Kullanıcılar tablosu (belirgin olan)
• İlişkili modeller (siparişler, gönderiler, yorumlar, biletler)
• Medya ve dosya yüklemeleri (avatar resimleri, belgeler)
• Etkinlik günlükleri ve denetim izleri
• Kullanıcı ID’si ile anahtarlanan önbellek girişleri
• Oturum verileri
• E-posta bildirim geçmişi
• Üçüncü taraf hizmet kayıtları (Stripe müşterileri, e-posta pazarlama listeleri)

Adım 2: Silinecekler ile anonimleştirilecekler arasında karar verin. GDPR, yasal olarak saklamanız gereken verileri silmenizi zorunlu kılmaz. Vergi amaçları doğrultusunda saklamanız gereken finansal kayıtlar, silinmek yerine anonimleştirilmelidir: kullanıcının adını ve e-posta adresini yer tutucu değerlerle değiştirirken işlem verilerini saklayın.

class UserDeletionService
{
    public function delete(User $user): void
    {
        // Yasal nedenlerle saklamamız gereken kayıtları anonimleştir
        $user->orders()->update([
            'customer_name' => 'Silinmiş Kullanıcı',
            'customer_email' => '[email protected]',
        ]);

        // Saklamamız gerekmeyen kayıtları sil
        $user->supportTickets()->forceDelete();
        $user->activityLogs()->delete();
        $user->addresses()->delete();

        // Yüklenen dosyaları depolama alanından kaldır
        Storage::delete($user->avatar_path);
        $user->documents()->each(function ($document) {
            Storage::delete($document->path);
            $document->delete();
        });

        // Önbellek girişlerini temizle
        Cache::forget("user:{$user->id}:preferences");
        Cache::forget("user:{$user->id}:permissions");

        // Üçüncü taraf hizmetlerden kaldır
        // Stripe::customers()->delete($user->stripe_id);

        // Son olarak, kullanıcıyı sil
        $user->forceDelete();
    }
}

Adım 3: Yumuşak silinmiş kayıtları ele alın. Eğer Laravel’in yumuşak silme özelliğini kullanıyorsanız, yumuşak silinmiş kayıtların hala kişisel verileri içerdiğini unutmayın. Silme servisi, GDPR silme taleplerinde forceDelete() kullanmalıdır. Alternatif olarak, kişisel veri alanlarını anonimleştirip sonra yumuşak silin, böylece referans bütünlüğü için kayıt mevcut olur ama kişisel bilgi içermez.

Adım 4: Yedeklemeleri ele alın. Bu en zor kısımdır. Deploynix’teki veritabanı yedeklemeleri kişisel verileri içerir ve bir yedekten bir kullanıcının verisini seçerek kaldırmanız mümkün değildir. GDPR kapsamında kabul edilen yaklaşım, yedeklerin belirli bir süre (örneğin, 30 gün) boyunca saklanacağını belgelemektir ve silinen verilerin doğal olarak yedek döngüsünden zaman içinde geçeceğini belirtmektir. Eğer bir yedekten geri yükleme yaparsanız, bu tarihten sonra silme taleplerini yeniden uygulamanız gerekecektir.

Silme taleplerinin zaman damgaları ile kaydını tutun. Eğer yedekten geri yükleme yaparsanız, bu kaydı sorgulayıp, yedekleme tarihinden sonra silme talep eden kullanıcılar için silme işlemlerini tekrarlayın.

Çerez Onayı ve İzleme

GDPR (ve ePrivacy Yönergesi), gerekli olmayan çerezler ayarlamadan önce bilgilendirilmiş onayın alınmasını gerektirir. Bir Laravel uygulamasında, bu, aşağıdaki özellikleri olan bir çerez onayı mekanizması gerektirir:

1. Analitik scriptleri, reklam piksellerini ve gerekli olmayan çerezleri kullanıcı onay vermeden engelleyin.
2. Kullanıcılara bazı çerez kategorilerine onay verme seçeneği sunun.
3. Onayı zaman damgasıyla kaydedin.
4. Kullanıcıların herhangi bir zamanda onaylarını geri çekmelerine izin verin.

Onay kaydını çerezlere güvenmek yerine veritabanınızda saklayın. Bir veritabanı kaydı, denetlenebilir bir onay izi sağlar. Kullanıcının onay tercihlerini, zaman damgasını, bu onayı verdikleri gizlilik politikası sürümünü ve IP adreslerini saklayın.

Laravel uygulamanızın middleware’ı, çerezleri ayarlamadan veya izleme scriptlerini dahil etmeden önce onay durumunu kontrol etmelidir. Çerez onayını okumak için bir middleware oluşturun (veya doğrulanmış kullanıcılar için veritabanı kaydı) ve bu bilgiyi Blade şablonlarınızda kullandığınız bir değişken ayarlayın, böylece izleme scriptlerini ÇİZİLECEK biçimde yönetebilirsiniz.

// Blade şablonunuzda
@if(request()->cookie() === )

@endif

Sunucu Konumu ve Veri İkameti

Sunucularınızın fiziksel olarak nerede bulunduğu GDPR açısından önemlidir. Deploynix, birden fazla bulut sağlayıcısında sunucu sağlayımını destekler ve AB veri ikameti için en güçlü seçenek Hetzner’dir.

Hetzner’in veri merkezleri yalnızca AB’de (Almanya ve Finlandiya) bulunmaktadır. Deploynix üzerinden Hetzner’de sunucular sağladığınızda, verilerinizin AB’de bulunduğundan emin olabilirsiniz. Diğer bölgelere veri çoğaltımı veya gizli sınır ötesi transferler hakkında belirsizlik yoktur.

Deploynix’te GDPR uyumlu bir Laravel kurulumu için, tüm sunucularınızı aynı AB bölgesinde sağlayın:

• Uygulama sunucusu Hetzner’de (Nuremberg, Falkenstein veya Helsinki)
• Veritabanı sunucusu Hetzner’de (en düşük gecikme için aynı bölge)
• Önbellek sunucusu Hetzner’de (aynı bölge)
• Çalışan sunucusu Hetzner’de (aynı bölge)

Veritabanı yedeklemelerinizi yalnızca AB bölgesinde saklanacak şekilde yapılandırın. AWS S3 kullanıyorsanız, yedekleme depolama için eu-central-1 (Frankfurt) bölgesini seçin ve çapraz bölge çoğaltmayı etkinleştirmeyin. Wasabi kullanıyorsanız, Amsterdam veya Frankfurt lokasyonunu tercih edin.

Veri İşleme Belgeleri

GDPR Madde 30, işleme faaliyetlerinizi kayıt altına almanızı gerektirir. Deploynix üzerinde konuşlandırılan bir Laravel uygulaması için bu belgeler şunları içermelidir:

Topladığınız kişisel veriler: Veritabanınızda kişisel verileri içeren her alanı listeleyin. İsim, e-posta, IP adresi, fiziksel adres, ödeme bilgileri ve bir doğal kişiyi tanımlayabilecek diğer veriler.

Neden topluyorsunuz: Her veri noktası, yasal bir temele dayanmalıdır. Hesap kimliği için kullanıcı e-postası (sözleşme gerekliliği), güvenlik kaydı için IP adresi (meşru menfaat), pazarlama tercihleri (onay). Özel olun.

Nerede saklanır: Sunucu konumlarınızı belgeleyin (örneğin, Hetzner Nuremberg), yedek depolama yerinizi ve kişisel verileri alan üçüncü taraf hizmetleri kaydedin.

Ne kadar süreyle saklanır: Her veri kategorisi için saklama sürelerini tanımlayın. Aktif hesap verileri, hesabın süresi boyunca saklanır. Silinen hesap verileri, 30 gün içerisinde temizlenir. Finansal kayıtlar, vergi uyumluluğu için 7 yıl boyunca saklanır. Günlük kayıtları, 90 gün boyunca tutulur.

Kime erişim var: Hangi ekip rollerinin kişisel verilere erişebileceğini belgelerle gösterin. Deploynix’te, bu organizasyon rollerinize denk gelir: Hangi ekip üyeleri veritabanına erişime sahip, hangileri günlükleri görebilir ve hangileri doğrudan sunucuya erişebilir.

Ne tür güvenlik önlemleri vardır: Şifrelemenizi (geçişte SSL, yedeklerin dinlenme halindeki şifrelemesi), güvenlik duvarı kurallarınızı (Deploynix üzerinden yapılandırılmış), erişim kontrollerinizi (Deploynix organizasyon rolleri) ve uygulama düzeyinde güvenlik önlemlerinizi (şifre hashleme, iki aşamalı kimlik doğrulama) belgelendirin.

Veri Sahibinden Gelen Talepleri Yönetme

Veri sahibinden gelen talepleri almak ve izlemek için bir sistem oluşturun. GDPR, bir talebe yanıt vermek için 30 gün tanır (karmaşık durumlar için iki ay uzatılabilir). Gerçekleştirmeniz gereken adımlar şunlardır:

1. Talep edenin kimliğini doğrulayın.
2. Tarihlerle birlikte isteği kaydedin.
3. Talebi işleyin (ihracat, silme, düzeltme).
4. Kullanıcıya tamamlandığını bildirin.

Basit bir Laravel uygulaması, veri sahibi talepleri için özel bir model ve kontrol sahip olabilir. Model, talep türü, durumu ve zaman çizelgesini izler. Kuyrukta bir iş, talebi işler ve e-posta bildirimi tamamlandığını teyit eder.

Önemli bir kullanıcı tabanına sahip uygulamalar için, doğrulanmış kullanıcıların verilerini indirebilecekleri, hesaplarını silebilecekleri ve onay tercihlerini yönetebilecekleri bir kendi kendine hizmet sağlayan gizlilik paneli eklemeyi düşünün. Bu, operasyonel yükünüzü azaltır ve kullanıcı deneyimini iyileştirir.

Üçüncü Taraf Hizmetlerin Denetimi

Laravel uygulamanız muhtemelen Deploynix altyapınızın dışındaki hizmetlerle etkileşimde bulunmaktadır. Bu hizmetlerin GDPR uyumluluğu her biri için değerlendirilmelidir:

E-posta dağıtımı (Mailgun, SES, Postmark): E-posta adreslerini ve içerikleri AB’de işlemekte midir? Birçoğu AB bölgesinde işleme sunmaktadır.

Ödeme işleme (Stripe, Paddle): Ödeme işlemcileri genellikle bağımsız veri denetleyicileri veya ortak denetleyiciler olarak hareket eder. Uygun anlaşmaların olduğundan emin olun. Deploynix, kendi faturalandırması için AB merkezli Paddle kullanmaktadır.

Analitik (Google Analytics, Plausible, Fathom): Google Analytics, birkaç AB yargı alanında uyumsuz bulunmuştur. Plausible veya Fathom gibi AB merkezli alternatifleri dikkate alın.

Hata izleme (Sentry, Bugsnag): Hata raporları genellikle kullanıcı verilerini (IP adreslerini, istek parametrelerini) içerir. AB barındırma seçenekleri sunan sağlayıcıları tercih edin veya veri temizleme yapılandırmasını gerçekleştirin.

Arama (Algolia, Meilisearch): Kişisel verileri indeksliyorsanız, buveri duruma göre işlenir. Meilisearch, Deploynix sunucularında kendi kendine barındırılabilir, böylece arama verilerini AB altyapınız içinde tutabilirsiniz.

Pratik Kontrol Listesi

Deploynix üzerinde dağıtım yapan Laravel geliştiricileri için keskin bir kontrol listesi:

• Tüm sunucuları Hetzner (AB veri merkezleri) üzerinde Deploynix üzerinden sağlayın
• Veritabanı ve önbellek erişimini kısıtlayacak şekilde güvenlik duvarı kurallarını yapılandırın
• AB’ye özel yedekleme depolama alanı oluşturun
• Kullanıcı veri ihracı işlevselliğini uygulayın
• Gerekli yasal kayıtlar için anonimleştirme ile kullanıcı veri silme işlemini gerçekleştirin
• Ayrıntılı onaylarla çerez kabul mekanizması ekleyin
• Tüm işleme faaliyetlerini belgeleyin (Madde 30 kayıtları)
• Tüm üçüncü taraf hizmetleri için AB veri işlemesini denetleyin
• Data subject talepleri izleme sistemini oluşturun
• Uygun saklama sürelerini ve otomatik temizleme işlevini yapılandırın
• 72 saatlik bir zaman dilimi ile ihlal bildirim süreçleri kurun
• Tüm alt işlemcilerle (Deploynix, Hetzner, e-posta sağlayıcı vb.) DP’leri imzalayın

GDPR uyumluluğu bir hedef değil. Sürekli bir uygulamadır. Laravel’in etkileyici çerçevesi ile Deploynix’in AB dostu altyapısının birleşimi, kullanıcılarınızın gizlilik haklarını gözeten ve verilerini güvenli bir şekilde tutan uygulamalar geliştirmenizin araçlarını sizlere sunmaktadır.