Compliance & Regulation serimizin bir parçası
Tam kılavuzu okuyunTasarım gereği gizlilik bir öneri değildir --- GDPR Madde 25 kapsamında yasal bir gerekliliktir. Kuruluşlar, veri koruma ilkelerinin işleme sürecine entegre edilmesini sağlamak için "uygun teknik ve organizasyonel önlemleri" uygulamalıdır. Ancak çoğu geliştirme ekibi, mimari belirlendikten sonra izin formlarını ve çerez başlıklarını kullanarak gizliliği sonradan akla gelen bir düşünce olarak ele alıyor.
Bu kılavuz, Tasarımdan Dolayı Gizliliğin yedi temel ilkesini uygulanabilir mühendislik uygulamalarına, tasarım modellerine ve kod düzeyindeki uygulamalara dönüştürmektedir.
Önemli Çıkarımlar
- Tasarım Yoluyla Gizlilik, gizliliğin sonradan bir özellik olarak eklenmesi değil, mimari kararların içine dahil edilmesi anlamına gelir
- Şema düzeyindeki veri minimizasyonu, başlangıçtan itibaren aşırı toplamayı önler
- Takma ad kullanma ve şifreleme, ihlaller meydana geldiğinde derinlemesine savunma sağlar
- Gizliliği koruyan analizler, bireysel kullanıcı verilerini ifşa etmeden iş öngörüleri sunabilir
Yazılıma Uygulanan Yedi İlke
1. Proaktif, Reaktif Değil
Bir ihlalden sonra değil, veri toplamadan önce gizlilik kontrolleri oluşturun.
Uygulamada:
- Kullanıcı hikayesi kabul kriterlerine gizlilik gerekliliklerini dahil edin
- Mimari incelemeleri sırasında bir gizlilik tehdidi modeli çalıştırın
- Kullanıcı verilerine dokunan her çekme isteği için bir gizlilik kontrol listesi oluşturun
2. Varsayılan Ayar Olarak Gizlilik
Kullanıcıların gizliliklerini korumak için herhangi bir işlem yapmasına gerek yoktur.
Uygulamada:
- Yeni kullanıcı hesapları varsayılan olarak minimum veri paylaşımına ayarlıdır
- Analitik izleme, devre dışı değil, isteğe bağlıdır
- Profil görünürlüğü varsayılan olarak özeldir
- Veri saklama varsayılan olarak gereken minimum süreye ayarlanır
// Default privacy settings for new users
const DEFAULT_PRIVACY_SETTINGS = {
profileVisibility: 'private', // Not 'public'
analyticsTracking: false, // Opt-in required
marketingEmails: false, // Opt-in required
dataSharing: false, // Opt-in required
activityLog: true, // Security feature, on by default
twoFactorAuth: true, // Security feature, on by default
};
3. Tasarımın İçinde Gizlilik Var
Gizlilik sistemin bir eklenti değil, temel bir bileşenidir.
Veritabanı şeması tasarımı:
-- Privacy-aware schema design
CREATE TABLE users (
id UUID DEFAULT gen_random_uuid() PRIMARY KEY,
-- Separate PII from operational data
email VARCHAR(255) NOT NULL, -- PII
email_hash VARCHAR(64) NOT NULL, -- For lookups without exposing email
name_encrypted BYTEA, -- Encrypted at rest
-- Operational fields (non-PII)
role VARCHAR(50) NOT NULL DEFAULT 'user',
created_at TIMESTAMP DEFAULT NOW(),
-- Privacy metadata
consent_timestamp TIMESTAMP,
consent_version VARCHAR(20),
data_retention_until TIMESTAMP,
deletion_requested_at TIMESTAMP
);
-- Separate sensitive data into its own table with stricter access
CREATE TABLE user_pii (
user_id UUID PRIMARY KEY REFERENCES users(id) ON DELETE CASCADE,
phone_encrypted BYTEA,
address_encrypted BYTEA,
date_of_birth_encrypted BYTEA,
-- Audit trail
last_accessed_at TIMESTAMP,
last_accessed_by UUID
);
4. Tam İşlevsellik (Pozitif Toplam)
Gizlilik, işlevsellik pahasına olmamalıdır. Her ikisini de sağlayan sistemler tasarlayın.
Örnek: Kişiselleştirme ile gizlilik arasında seçim yapmak yerine gizliliği koruyan kişiselleştirmeyi kullanın:
- Birleşik öğrenme: Yerel veriler üzerinde eğitilen makine öğrenimi modelleri, yalnızca toplu sonuçlar paylaşılır
- Farklı gizlilik: Bireysel kimlik tespitini önlemek için analitiklere gürültü ekleyin
- Cihaz üzerinde işleme: Öneriler sunucuda değil kullanıcının cihazında hesaplanır
5. Uçtan Uca Güvenlik
Verileri tüm yaşam döngüsü boyunca koruyun.
| Yaşam Döngüsü Aşaması | Güvenlik Önlemi |
|---|---|
| Koleksiyon | TLS 1.3 aktarımda, giriş doğrulama |
| İşleme | Bellek açısından güvenli kullanım, kişisel bilgilerin günlüğe kaydedilmesi yok |
| Depolama | Kullanımda olmayan AES-256 şifreleme, anahtar yönetimi |
| Paylaşma | Şifreli kanallar, alıcılı DPA'lar |
| Arşiv | Şifrelenmiş arşiv, erişim günlüğü |
| Silme | Kriptografik silme, doğrulama |
6. Görünürlük ve Şeffaflık
Kullanıcılar verilerine ne olacağını anlamalıdır.
Uygulama:
// Privacy dashboard API endpoint
@Controller('privacy')
export class PrivacyController {
@Get('my-data')
@ApiOperation({ summary: 'Get all personal data (GDPR Art. 15)' })
async getMyData(@Req() req: AuthenticatedRequest) {
return {
profile: await this.userService.getProfile(req.user.sub),
orders: await this.orderService.getUserOrders(req.user.sub),
supportTickets: await this.supportService.getUserTickets(req.user.sub),
loginHistory: await this.authService.getLoginHistory(req.user.sub),
consentRecords: await this.consentService.getUserConsents(req.user.sub),
dataProcessors: this.getDataProcessorList(),
};
}
@Post('export')
@ApiOperation({ summary: 'Export personal data (GDPR Art. 20)' })
async exportMyData(@Req() req: AuthenticatedRequest) {
// Generate machine-readable export (JSON)
return this.privacyService.generateDataExport(req.user.sub);
}
@Post('delete')
@ApiOperation({ summary: 'Request data deletion (GDPR Art. 17)' })
async requestDeletion(@Req() req: AuthenticatedRequest) {
return this.privacyService.initiateDataDeletion(req.user.sub);
}
}
7. Kullanıcı Gizliliğine Saygı
Kullanıcıyı her tasarım kararının merkezinde tutun.
Gizliliği Koruyan Mimari Desenler
Desen 1: Veri Ayırma
Kişisel olarak tanımlanabilir bilgileri operasyonel verilerden ayırın:
[Frontend] --> [API Gateway] --> [Application Service]
|
+----------------+----------------+
| |
[Operational DB] [PII Vault]
(Orders, products, (Names, emails,
analytics - by ID) addresses - encrypted)
Model 2: Rızaya Dayalı İşleme
// Consent middleware
async function requireConsent(purpose: string) {
return async (req: Request, res: Response, next: NextFunction) => {
const consent = await consentService.check(req.user.id, purpose);
if (!consent.granted) {
throw new ForbiddenException(
`Processing for "${purpose}" requires user consent`
);
}
next();
};
}
// Usage
@Get('recommendations')
@UseGuards(requireConsent('personalization'))
async getRecommendations(@Req() req: AuthenticatedRequest) {
return this.recommendationService.getForUser(req.user.sub);
}
Model 3: Otomatik Veri Sona Ermesi
// TTL-based data retention
const RETENTION_POLICIES = {
supportTickets: { days: 1095, action: 'anonymize' }, // 3 years
recruitmentData: { days: 730, action: 'delete' }, // 2 years
analyticsEvents: { days: 365, action: 'aggregate' }, // 1 year
sessionLogs: { days: 90, action: 'delete' }, // 90 days
tempUploads: { days: 7, action: 'delete' }, // 7 days
};
Üçüncü Taraf Entegrasyonlarında Gizlilik
Her üçüncü taraf entegrasyonu potansiyel bir gizlilik riskidir. Uygulamanız kullanıcı verilerini harici bir hizmete gönderdiğinde, söz konusu hizmetin bunu nasıl işleyeceğinden siz sorumlu olursunuz.
Entegrasyon Gizlilik Değerlendirmesi
Kullanıcı verilerini işleyen herhangi bir üçüncü taraf hizmetini entegre etmeden önce:
| Değerlendirme Sorusu | Evet ise Eylem |
|---|---|
| Hizmet PII alıyor mu? | DPA'yı zorunlu tutun, veri işlemeyi değerlendirin |
| Veriler AEA'dan çıkıyor mu? | Uygulama aktarım mekanizması (SCC'ler) |
| Hizmet SOC2 / ISO 27001 sertifikalı mı? | Sertifikasyonun güncel olduğunu doğrulayın |
| Hizmet verilere düz metin olarak erişebilir mi? | İstemci tarafı şifrelemeyi düşünün |
| Hizmet verileri kendi amaçları doğrultusunda kullanıyor mu? | DPA'nın bunu yasakladığından emin olun |
Ortak Entegrasyon Gizlilik Riskleri
Analytics: Google Analytics, Mixpanel ve benzeri hizmetler kullanıcı davranış verilerini alır. Verilerin açığa çıkmasını en aza indirmek için sunucu tarafı analizlerini veya çerez içermeyen alternatifleri (Plausible, Fathom) kullanın.
Ödeme işleme: Stripe, PayPal ve benzeri hizmetler finansal verileri işler. PCI-DSS kapsamının genişletilmesini önlemek için barındırılan ödeme formlarını (Stripe Elements) kullanın. Asla kredi kartı numaralarının tamamını kaydetmeyin.
E-posta hizmetleri: SendGrid, Mailgun ve benzer hizmetler e-posta adreslerini ve mesaj içeriğini işler. E-posta servis sağlayıcısının imzalı bir DPA'ya sahip olduğundan ve alıcı verilerinizi reklam amacıyla kullanmadığından emin olun.
Müşteri desteği: Zendesk, Intercom ve benzeri hizmetler, PII içerebilecek müşteri görüşmelerini saklar. Destek platformunda veri saklamayı yapılandırın ve DPA'nın tüm veri türlerini kapsadığından emin olun.
Geliştirici Kontrol Listesi
Kullanıcı Verilerine Dokunan Her Özellik İçin
- Bu özellik hangi kişisel verileri topluyor? (Belgeleyin)
- Tahsilatın yasal dayanağı nedir? (Rıza, sözleşme, meşru menfaat)
- Bu gereken minimum veri mi? (Veri minimizasyonu)
- Bunu ne kadar süre elimizde tutacağız? (Saklama politikası)
- Kimin erişimi var? (En az ayrıcalık)
- Kullanımda değilken ve aktarılırken şifrelenmiş mi? (Güvenlik)
- Kullanıcı verilerine erişebilir, verileri dışa aktarabilir ve silebilir mi? (Haklar)
- Denetim amacıyla günlüğe kaydediliyor mu? (Sorumluluk)
- Sınırları geçiyor mu? (Aktarım mekanizmaları)
- Yüksek risk durumunda DPIA tamamlandı mı? (Değerlendirme)
Sıkça Sorulan Sorular
Tasarımsal Gizlilik yalnızca GDPR için mi geçerlidir?
Hayır. GDPR bunu yasal bir gereklilik haline getirse de (Madde 25), Tasarımdan Gelen Gizlilik dünya çapında tanınan en iyi uygulamadır. Kaliforniya'nın CPRA'sı, Brezilya'nın LGPD'si ve Hindistan'ın DPDP'si, gizliliğin sistem tasarımına dahil edilmesi konusunda benzer gereklilikleri içermektedir. GDPR uyumluluğu için Tasarımdan Gizliliğin uygulanması, diğer birçok yargı bölgesinin gerekliliklerini otomatik olarak karşılar.
Gizliliği mevcut bir uygulamaya nasıl uyarlayabiliriz?
Öncelik verin: (1) Hangi kişisel verilere sahip olduğunuzu ve bunların nerede yaşadığını denetleyin, (2) Veri sahibi istek iş akışlarını uygulayın (erişim, silme, dışa aktarma), (3) Kullanımda olmayan hassas veriler için şifreleme ekleyin, (4) Saklama politikaları ve otomatik silme uygulayın, (5) Eksik olduğunda izin yönetimi ekleyin. Bu ideal değildir ancak öncelikle en yüksek risk açıklarına hitap eder.
Tasarım gereği gizlilik, analitiği kullanamayacağımız anlamına mı geliyor?
Hayır. Bu, analitiği sorumlu bir şekilde kullanmak anlamına gelir. Bireysel izleme yerine verileri toplu hale getirin. Web sitesi ölçümleri için çerezsiz analizler (Makul, Fathom) kullanın. Ürün analitiği için olayları kişisel bilgiler olmadan toplayın veya tanımlayıcılara takma ad verin. A/B testi için, istemci tarafı izleme çerezleri olmadan sunucu tarafı atamasını kullanın. Gizlilik ve analitik, düşünceli tasarımla uyumludur.
Odoo'da Tasarımdan Doğan Gizliliği nasıl uygularız?
Odoo çeşitli yerleşik gizlilik özellikleri sunar: kullanıcı erişim grupları (modül başına erişim kontrolü), denetim günlüğü (kayıtlardaki sohbetler) ve veri arşivleme. Bunları şu şekilde geliştirin: hassas veriler için şifrelenmiş özel alanlar, planlanmış eylemleri kullanan otomatik saklama kuralları, özel raporları kullanan GDPR verilerini dışa aktarma işlevi ve kişi kayıtlarında izin takibi. ECOSIRE'ın Odoo kişiselleştirme hizmetleri tasarım gereği gizlilik uygulamasını içerir.
Sırada Ne Var?
Tasarımdan Gelen Gizlilik bir mühendislik disiplinidir. Yaşam döngüsü yönetimi için veri saklama politikaları, web mülkleri için çerez izni uygulaması ve dahili sistemler için çalışan veri gizliliği ile eşleştirin.
Tasarım gereği gizlilik danışmanlığı ve yazılım mimarisi incelemesi için ECOSIRE ile iletişime geçin.
ECOSIRE tarafından yayınlandı - işletmelerin kodun her satırında gizlilik oluşturmasına yardımcı oluyor.
Yazan
ECOSIRE TeamTechnical Writing
The ECOSIRE technical writing team covers Odoo ERP, Shopify eCommerce, AI agents, Power BI analytics, GoHighLevel automation, and enterprise software best practices. Our guides help businesses make informed technology decisions.
ECOSIRE
ECOSIRE ile İşinizi Büyütün
ERP, e-Ticaret, yapay zeka, analitik ve otomasyon genelinde kurumsal çözümler.
İlgili Makaleler
Odoo ve Tryton 2026: Mimari, Modülerlik ve Topluluk
Dengeli Odoo ve Tryton ERP karşılaştırması: mimari, modülerlik, muhasebe, özelleştirme modeli, dağıtım ve ciddi kullanıcılar için her birinin kazandığı yer.
OpenClaw Çok Kiracılı Üretim Dağıtım Mimarisi
OpenClaw çok kiracılı dağıtım modelleri: kiracı izolasyonu, paylaşılan ve özel çalışma zamanı, mesaj veri yolu tasarımı, sırlar, gözlemlenebilirlik ve ölçeklendirme.
Kanada PIPEDA Uyumluluğu: Dijital İşletmeler için Gizlilik Kılavuzu
Kanada gizlilik yasasına ilişkin eksiksiz kılavuz: PIPEDA, Quebec Yasası 25, CPPA reformu, On Adil Bilgi İlkesi, PIPEDA ihlal bildirimi ve OPC yaptırımı.
Compliance & Regulation serisinden daha fazlası
BMF Programmablaufplan Lohnsteuer 2026: Almanya'nın Resmi Ücret-Vergi Hesaplamasının Uygulanması (XML, API, Odoo)
BMF Programmablaufplan Lohnsteuer 2026 için geliştirici kılavuzu: PAP nedir, XML sözde kod formatı, resmi test hizmeti ve Odoo maaş bordrosuna eşleme.
Giyim ve Moda Markaları için ERP: Beden-Renk Matrisi, Sezon Planlaması ve Uyumluluk (2026 Kılavuzu)
Moda ve giyim markaları 2026'da ERP'yi nasıl seçiyor: beden-renk matrisi çeşitleri, sezon planlaması, GoBD ve DATEV uyumluluğu, tedarikçi karşılaştırması ve maliyetler.
ERPNext İK ve 2026'da Bordro: Kurulum, Maaş Yapıları ve Çok Ülkeli Uyumluluk
2026 için adım adım ERPNext HR ve bordro kurulumu: HRMS uygulamasının kurulumu, maaş yapıları, bordro girişi işlemleri, gelir vergisi dilimleri, çok ülkeli uyumluluk.
2026'da GoHighLevel A2P 10DLC Uyumluluğu: Kayıt, Ücretler ve Engellenen SMS'leri Düzeltme
2026 için GoHighLevel A2P 10DLC kılavuzunu tamamlayın: marka ve kampanya kayıt adımları, operatör ücretleri, yaygın ret nedenleri ve filtrelenmiş SMS'lerin nasıl düzeltileceği.
ERP Sistemleri için GxP Doğrulaması: 2026 Doğrulama RFP'nizin Gerektirmesi Gerekenler (CSV, IQ/OQ/PQ, Denetim Yolları)
Bir GxP ERP doğrulama RFP'sinin 2026'da gerektirmesi gerekenler: CSV ve CSA kapsamı, 21 CFR Bölüm 11, AB Annex 11, IQ/OQ/PQ çıktıları, denetim izleri ve GAMP 5 riski.
OpenClaw Güvenlik Modeli, Veri Yerleşimi, SOC 2 ve ISO 27001
OpenClaw güvenlik mimarisi: kiracı izolasyonu, şifreleme, gizli yönetim, denetim günlükleri, veri yerleşimi, SOC 2, ISO 27001, GDPR, HIPAA uygunluğu.