PostgreSQL’de Veri Maskeleme: Test Ortamlarında KVKK’ya Uygun Hassas Veri Yönetimi

Veri maskeleme, kişisel ve hassas verilerin gerçek değerleri yerine değiştirilmiş, kısmen gizlenmiş veya sahte değerlerle gösterilmesidir. PostgreSQL’de iki temel yaklaşım vardır: test ve geliştirme ortamlarına kopyalanan verinin kalıcı olarak değiştirildiği statik maskeleme ve verinin yerinde kaldığı, yalnızca yetkisi olmayan kullanıcılara maskeli gösterildiği dinamik maskeleme. Production verisinin maskelenmeden test ortamına kopyalanması, KVKK açısından en sık karşılaşılan risklerden biridir.

Bu rehber, test ortamlarını production verisiyle besleyen yazılım ekipleri ve KVKK uyumundan sorumlu BT yöneticileri için hazırlandı. Örnekleri PostgreSQL 18 üzerinde test ettik.

Kısaca: Statik ve Dinamik Maskeleme

Neden Maskeleme Gerekli?

Production veritabanının bir kopyasını test ortamına almak, yazılım ekiplerinin gerçekçi veriyle çalışması için yaygın bir uygulamadır. Ancak test ortamları genellikle production kadar korunmaz: daha geniş erişim, daha zayıf parolalar, dış geliştiriciler ve kayıt altına alınmayan sorgular. Bu ortamlardaki gerçek kişisel veri, production’daki tüm güvenlik önlemlerini anlamsız hale getirir.

KVKK, kişisel verilerin işlenme amacıyla bağlantılı, sınırlı ve ölçülü olmasını şart koşar. Bir yazılım testinin gerçek müşteri kimlik numaralarına ihtiyacı yoktur.

1. Adım: Kişisel Veriyi Bulun

Maskelemenin ilk adımı, hangi kolonların kişisel veya hassas veri içerdiğini bilmektir. Kolon adları iyi bir başlangıç noktasıdır:

SELECT table_schema, table_name, column_name, data_type
FROM information_schema.columns
WHERE table_schema NOT IN ('pg_catalog', 'information_schema')
  AND column_name ~* '(tckn|tc_?kimlik|kimlik|ad_?soyad|full_?name|e_?mail|eposta|telefon|phone|gsm|adres|address|iban|kart|card|dogum|birth|maas|salary)'
ORDER BY table_schema, table_name, column_name;

Kolon adlarına bakmak yeterli değildir; “aciklama” veya “not” gibi serbest metin alanları da kişisel veri içerebilir. Bu alanlarda örnek veriler üzerinde desen kontrolü yapın (örneğin 11 haneli sayılar, e-posta adresleri). Bulguları, hangi kolonun hangi yöntemle maskeleneceğini gösteren bir envanter tablosuna dönüştürün.

2. Adım: Maskeleme Yöntemini Seçin

Statik Maskeleme: Test Ortamı İçin

En basit ve en şeffaf yöntem, test ortamına geri yüklenen kopya üzerinde maskeleme script’i çalıştırmaktır. Script’in her geri yüklemede otomatik çalışması ve kopya kullanıcılara açılmadan önce tamamlanması gerekir.

-- Runs on the TEST copy right after the restore, before anyone gets access
UPDATE customers
SET full_name = 'Müşteri ' || id,
    email     = 'musteri' || id || '@ornek.test',
    phone     = '0500' || lpad((id % 10000000)::text, 7, '0'),
    tckn      = NULL;

-- Consistent pseudonym: the same input always maps to the same output
UPDATE orders
SET customer_email = 'u_' || left(md5(customer_email || 'proje-gizli-tuz'), 12) || '@ornek.test';

Tutarlı takma ad yönteminde kullanılan “tuz” (salt) değeri gizli tutulmalıdır; aksi halde yaygın e-posta adresleri denenerek eşleştirme yapılabilir.

Dinamik Maskeleme: Production İçin

Yerleşik yöntem: view ve kolon yetkileri

PostgreSQL’in yerleşik özellikleriyle dinamik maskeleme, maskeli bir view oluşturup kullanıcıya tabloya değil view’a yetki vererek yapılır:

CREATE TABLE customers (id int PRIMARY KEY, full_name text, tckn text, phone text);
INSERT INTO customers VALUES (1, 'Ayşe Yılmaz', '12345678901', '05321234567');

CREATE VIEW customers_masked AS
SELECT id,
       left(full_name, 1) || '*** ' || left(split_part(full_name, ' ', 2), 1) || '***' AS full_name,
       repeat('*', 7) || right(tckn, 4) AS tckn,
       left(phone, 4) || ' *** ** ' || right(phone, 2) AS phone
FROM customers;

CREATE ROLE support_user LOGIN PASSWORD 'change_me';
REVOKE ALL ON customers FROM support_user;
GRANT SELECT ON customers_masked TO support_user;

-- As support_user:
SELECT * FROM customers_masked;
--  id | full_name | tckn        | phone
--   1 | A*** Y*** | *******8901 | 0532 *** ** 67

Bu yöntem sade ve şeffaftır; ancak uygulamanın tablo yerine view’u sorgulaması gerekir ve maskeleme kuralları her view’da ayrı ayrı yönetilir.

Eklentiler

Hangi aracı seçerseniz seçin, maskeleme kurallarının bir envantere bağlı olması ve yeni eklenen kolonların bu envantere girmesini sağlayan bir sürecin bulunması gerekir.

Maskelemeyi Atlatma Riskleri

Dinamik maskeleme, yetkisiz kullanıcının verinin kendisine hiçbir yoldan ulaşamaması şartıyla güvenlidir. Şu noktaları kontrol edin:

• Doğrudan tablo erişimi: Maskeli view’u kullanan rolün asıl tabloya yetkisi olmamalıdır.
• Çıkarım saldırıları: Maskeli kolon üzerinde WHERE tckn LIKE '1%' gibi filtreler çalışıyorsa, değer tahmin edilerek bulunabilir.
• Yedekler ve dışa aktarımlar: Yedekler gerçek veriyi içerir; erişimi kısıtlı ve şifreli olmalıdır.
• Loglar: Sorgu logları parametre olarak gerçek değerleri içerebilir.

Maskeleme Süreci İçin Kontrol Listesi

Aryasoft ile Veri Maskeleme

Aryasoft, PostgreSQL ve SQL Server ortamlarınızdaki kişisel verileri tespit eder, kolon bazında maskeleme kurallarını sizinle birlikte belirler ve test ortamlarını otomatik olarak maskelenmiş veriyle yenileyen bir süreç kurar. Veri yönetişimiyle ilgili saha gözlemlerimizi veri yönetişimi yazımızda, PostgreSQL’in diğer güvenlik katmanlarını PostgreSQL güvenlik rehberimizde anlattık. Ayrıntılar PostgreSQL hizmetleri sayfamızda.

Sıkça Sorulan Sorular

Kaynaklar

Bu rehberdeki teknik bilgiler Kasım 2026’da aşağıdaki kaynaklarla karşılaştırıldı.

1. PostgreSQL dokümantasyonu: CREATE VIEW
2. PostgreSQL dokümantasyonu: Privileges
3. PostgreSQL Anonymizer dokümantasyonu
4. AWS: Using dynamic masking with Aurora PostgreSQL (pg_columnmask)
5. Kişisel Verileri Koruma Kurumu