Veritabanında Şifreleme (Encryption at Rest)

Bir veri merkezinde arızalanan disk iade edilirken üzerindeki veriler silinmemiş olabilir. Bir sunucu satıldığında ya da bir sanal makine imajı yanlış yere kopyalandığında, o imajdaki veritabanı dosyaları tek bir komutla okunabilir. Veritabanında şifreleme (encryption at rest), tam olarak bu senaryolara karşı bir savunmadır: diskteki dosyalar çalınsa bile içerikleri anlaşılmaz olsun. KVKK ve benzeri düzenlemelerin "uygun teknik tedbir" beklentisinin de somut karşılıklarından biridir.

Ancak bu koruma, sanıldığından çok daha dar bir tehdit kümesini kapsar ve bu rehberin en önemli mesajı budur. Diskteki şifreleme, veritabanı çalışırken ve doğru kimlik bilgileriyle bağlanan birine karşı hiçbir şey yapmaz; sorgu geldiğinde veritabanı veriyi zaten şeffaf biçimde çözer. Aşağıda katman katman hangi şifrelemenin hangi riski kapattığını, LUKS ile disk şifrelemeyi, MySQL/MariaDB tablo alanı şifrelemesini, PostgreSQL'de kolon bazında pgcrypto kullanımını, anahtar yönetiminin neden işin asıl zor kısmı olduğunu ve yedeklerin nasıl şifrelendiğini gerçek komutlarla göreceksiniz.

Neyi Neye Karşı Koruyorsunuz#

Şifrelemeye başlamadan önce cevaplanması gereken soru şudur: hangi saldırganı düşünüyorsunuz? Farklı katmanlar farklı senaryoları kapatır ve birini diğerinin yerine koymak yanlış bir güvenlik hissi yaratır.

Tablonun anlattığı hikâye net: disk ve veritabanı seviyesindeki şifreleme, veriye dosya olarak erişen birine karşı işe yarar. Veriye sorgu olarak erişen birine karşı yalnızca kolon ya da uygulama seviyesinde şifreleme koruma sağlar, çünkü orada çözme anahtarı veritabanında değil uygulamadadır.

Bu yüzden gerçekçi bir plan üç katmanı birlikte kurar: temel için disk ya da tablo alanı şifreleme, gerçekten hassas alanlar (kimlik numarası, sağlık verisi, kart bilgisi) için kolon seviyesinde şifreleme, ve aktarım için TLS. Hangi verinin hangi katmanı hak ettiğine karar verirken veritabanı anonimleştirme ve KVKK uyumu yazısındaki veri sınıflandırma yaklaşımı işinizi kolaylaştırır.

Disk Seviyesinde Şifreleme: LUKS#

Linux'ta blok cihaz şifrelemesinin standart yolu LUKS'tur. Tüm dosya sistemini şifreler; veritabanı, loglar, geçici dosyalar ve takas alanı dahil her şey korunur. En büyük avantajı, veritabanı motorundan tamamen bağımsız olmasıdır — PostgreSQL, MySQL, MongoDB fark etmez.

# Ayrı bir veri diskini şifreli olarak hazırlama (VERİ SİLİNİR, boş diskte yapın)
sudo cryptsetup luksFormat --type luks2 /dev/sdb

# Şifreli cihazı aç ve /dev/mapper altında eşle
sudo cryptsetup luksOpen /dev/sdb veri_diski

# Dosya sistemi oluştur ve bağla
sudo mkfs.ext4 /dev/mapper/veri_diski
sudo mkdir -p /var/lib/veritabani
sudo mount /dev/mapper/veri_diski /var/lib/veritabani

# Durumu doğrula
sudo cryptsetup status veri_diski

Açılışta otomatik bağlanması için /etc/crypttab ve /etc/fstab dosyalarına giriş eklersiniz. İşte burada, uzak sunucularda kritik bir tasarım kararı çıkar karşınıza: parolayı elle girmeniz gerekirse sunucu yeniden başladığında birinin konsola bağlanıp parola yazması gerekir. Anahtar dosyasını aynı sunucuda saklarsanız da disk çalındığında anahtar onunla birlikte gider — yani korumanın çoğunu kaybedersiniz.

Pratikte kabul edilen orta yol, anahtar dosyasını sunucuda ama şifreli ana diskten ayrı ve erişimi kısıtlı tutmak ya da ağ üzerinden anahtar sunan bir servis kullanmaktır. Fiziksel disk hırsızlığı senaryosunda bu bile yeterlidir, çünkü saldırgan yalnızca veri diskini alır.

# /etc/crypttab — anahtar dosyası ile otomatik açılış
# isim        cihaz          anahtar_dosyasi          seçenekler
veri_diski    /dev/sdb       /etc/luks/veri.key       luks

# Anahtar dosyası izinleri asla gevşek olmamalı
sudo chmod 0400 /etc/luks/veri.key
sudo chown root:root /etc/luks/veri.key

LUKS'un performans maliyeti, modern işlemcilerde AES donanım hızlandırma (AES-NI) sayesinde çoğu iş yükünde tek haneli yüzdelerde kalır. Donanım desteğini grep -m1 aes /proc/cpuinfo ile doğrulayabilirsiniz; desteklenmiyorsa maliyet belirgin biçimde artar.

MySQL ve MariaDB'de Tablo Alanı Şifreleme#

MySQL ve MariaDB, InnoDB tablo alanlarını (tablespace) şifreleyebilir. Bu, disk şifrelemeden daha ince taneli bir kontrol sunar: hangi tabloların şifreleneceğini seçebilirsiniz. Önce anahtar saklama bileşenini yapılandırmanız gerekir.

# MariaDB: file_key_management eklentisi ile anahtar dosyası tabanlı şifreleme
[mariadb]
plugin_load_add = file_key_management
file_key_management_filename = /etc/mysql/anahtarlar/keys.enc
file_key_management_filekey  = FILE:/etc/mysql/anahtarlar/keyfile.key
file_key_management_encryption_algorithm = AES_CTR

innodb_encrypt_tables = ON      # yeni tablolar varsayılan olarak şifreli
innodb_encrypt_log    = ON      # redo log da şifrelensin
innodb_encryption_threads = 4

-- MySQL 8: tek bir tabloyu şifrele ya da şifreyi kaldır
ALTER TABLE musteriler ENCRYPTION = 'Y';

-- Hangi tablolar şifreli, kontrol edin
SELECT TABLE_SCHEMA, TABLE_NAME, CREATE_OPTIONS
FROM information_schema.TABLES
WHERE CREATE_OPTIONS LIKE '%ENCRYPTION%';

Burada sıkça atlanan üç nokta var. Birincisi, tablo verisi şifrelenmiş olsa bile redo log, undo log ve binlog varsayılan olarak şifresizdir; bu dosyalar aynı verinin bir kopyasını taşır. İkincisi, geçici tablolar disk üzerine taştığında şifresiz yazılabilir. Üçüncüsü, mysqldump çıktısı düz metindir — şifreleme yalnızca veri dosyaları için geçerlidir.

# MySQL 8: log ve geçici dosyaları da kapsayacak ek ayarlar
innodb_redo_log_encrypt   = ON
innodb_undo_log_encrypt   = ON
binlog_encryption         = ON

Anahtar dosyasını datadir içinde tutmak yaygın ama hatalı bir alışkanlıktır: aynı dizini kopyalayan biri hem şifreli veriyi hem anahtarı alır. Anahtarı ayrı bir dizinde, dar izinlerle ve tercihen ayrı bir birimde tutun. MariaDB kurulumunda güvenlik sertleştirmesinin tamamı için MariaDB kurulumu ve güvenliği yazısına bakabilirsiniz.

PostgreSQL: Disk Şifreleme ve pgcrypto#

PostgreSQL'in topluluk sürümünde, MySQL'deki gibi yerleşik bir tablo alanı şifreleme özelliği bulunmaz. Bu bir eksiklik gibi görünse de, pratikte tercih edilen yol zaten LUKS ile disk seviyesinde şifrelemektir; sonuç dosya erişimi açısından eşdeğerdir ve motora hiçbir yük bindirmez.

Gerçekten hassas alanlar için ise pgcrypto uzantısı kolon bazında şifreleme sağlar:

-- Uzantıyı etkinleştir
CREATE EXTENSION IF NOT EXISTS pgcrypto;

-- Hassas alanı bytea olarak sakla
CREATE TABLE saglik_kayitlari (
    id          bigserial PRIMARY KEY,
    hasta_id    bigint NOT NULL,
    tani_sifreli bytea NOT NULL,
    olusturuldu timestamptz NOT NULL DEFAULT now()
);

-- Yazarken şifrele: anahtar SORGUYLA gelir, veritabanında saklanmaz
INSERT INTO saglik_kayitlari (hasta_id, tani_sifreli)
VALUES (1042, pgp_sym_encrypt('Örnek tanı metni', :'sifreleme_anahtari'));

-- Okurken çöz
SELECT hasta_id, pgp_sym_decrypt(tani_sifreli, :'sifreleme_anahtari') AS tani
FROM saglik_kayitlari
WHERE hasta_id = 1042;

Bu yöntemin gücü de zayıflığı da aynı yerden gelir: anahtar uygulamada durur. Veritabanı parolasını ele geçiren bir saldırgan şifreli sütunu okuyabilir ama içeriğini çözemez. Buna karşılık şifreli kolonda arama yapamazsınız — WHERE tani LIKE '%...%' çalışmaz, indeks kurulamaz. Bu yüzden kolon şifrelemesi yalnızca kimlik numarası, sağlık verisi ya da erişim belirteci gibi üzerinde arama yapılmayan alanlar için uygundur.

Eşitlik araması yapmanız gerekiyorsa, şifreli değerin yanında deterministik bir özet (hash) kolonu tutabilirsiniz. Ancak dikkat: kısa ve tahmin edilebilir değerlerde (örneğin TC kimlik numarası) düz özet, kaba kuvvetle çözülebilir; mutlaka gizli bir tuz (salt) ya da HMAC kullanın.

-- Arama için HMAC tabanlı deterministik özet kolonu
ALTER TABLE saglik_kayitlari ADD COLUMN hasta_arama bytea;
UPDATE saglik_kayitlari
   SET hasta_arama = hmac(hasta_id::text, :'arama_anahtari', 'sha256');
CREATE INDEX idx_hasta_arama ON saglik_kayitlari (hasta_arama);

Özet üretiminin genel mantığını denemek isterseniz hash üretici aracıyla farklı algoritmaların çıktısını karşılaştırabilirsiniz.

Anahtar Yönetimi: İşin Asıl Zor Kısmı#

Şifreleme algoritması seçmek kolaydır; herkes AES-256 kullanır ve tartışma orada biter. Asıl zor olan, anahtarın nerede duracağı, kimin erişeceği ve nasıl döndürüleceğidir. Kötü anahtar yönetimi, şifrelemeyi tamamen anlamsız hâle getirebilir.

Üç kuralı baştan koyun:

1. Anahtar, şifrelediği veriyle aynı yerde durmaz. Anahtar dosyası veritabanı veri dizininde ya da aynı yedek arşivinde bulunuyorsa, koruma yoktur.
2. Anahtara erişim, veriye erişimden ayrı yetkilendirilir. Veritabanı yöneticisinin anahtar dosyasını okuyabilmesi gerekmez.
3. Anahtar döndürme (rotation) prosedürü önceden yazılır ve denenir. Anahtarı değiştirmeniz gereken gün, prosedürü ilk kez o gün yazmak istemezsiniz.

Anahtarları uygulamaya taşırken en yaygın hata, onları kod deposuna ya da yapılandırma dosyasına düz metin olarak yazmaktır. Minimum standart, anahtarı ortam değişkeni olarak vermek ve dosya izinlerini sıkmaktır; daha olgun kurulumlarda merkezi bir gizli bilgi yöneticisi (secret manager) kullanılır.

# Güçlü bir anahtar üret ve dar izinlerle sakla
openssl rand -base64 32 > /etc/uygulama/veri.key
chmod 0400 /etc/uygulama/veri.key
chown uygulama:uygulama /etc/uygulama/veri.key

# Yedekleme betiğine anahtarı ortam değişkeniyle geçirin, argüman olarak DEĞİL
# (argümanlar 'ps' çıktısında görünür ve kabuk geçmişine yazılır)
export YEDEK_ANAHTARI="$(cat /etc/uygulama/veri.key)"

Anahtar üretirken tahmin edilebilir değerlerden kaçının; rastgelelik kalitesi doğrudan güvenlik seviyenizdir. Uygulama parolaları ve servis hesapları için şifre üretici aracını kullanabilirsiniz.

Yedekler ve Aktarım Katmanı#

Şifrelenmiş bir veritabanının yedeği neredeyse her zaman şifresizdir ve bu, en sık atlanan boşluktur. mysqldump ve pg_dump düz metin üretir; bu dosya bir yedek sunucusuna, bir nesne depolamaya ya da bir geliştiricinin makinesine gittiği anda tüm şifreleme çabanız devre dışı kalır. Yedeği üretirken şifreleyin:

# PostgreSQL: dökümü diske hiç düşürmeden şifreleyerek yaz
pg_dump -Fc uygulama \
  | openssl enc -aes-256-cbc -pbkdf2 -salt -pass env:YEDEK_ANAHTARI \
  > /yedek/uygulama-$(date +%F).dump.enc

# Geri yükleme
openssl enc -d -aes-256-cbc -pbkdf2 -pass env:YEDEK_ANAHTARI \
  -in /yedek/uygulama-2026-08-25.dump.enc \
  | pg_restore -d uygulama_yeni

# MySQL: aynı mantık, boru hattı diske şifresiz veri bırakmaz
mysqldump --single-transaction --routines uygulama \
  | gzip \
  | openssl enc -aes-256-cbc -pbkdf2 -salt -pass env:YEDEK_ANAHTARI \
  > /yedek/uygulama-$(date +%F).sql.gz.enc

Yedek şifreleme anahtarını kaybetmek, yedeği kaybetmekle aynı şeydir. Bu yüzden anahtarın kendisinin de bir kurtarma planı olmalıdır; kopyaların nasıl dağıtılacağı konusunda veritabanları için 3-2-1 yedekleme stratejisi yazısındaki kurgu doğrudan uygulanabilir.

Aktarım katmanı da unutulmamalıdır. Uygulama sunucusu ile veritabanı farklı makinelerdeyse, aradaki trafik TLS ile şifrelenmelidir:

# MySQL: şifresiz bağlantıları tamamen reddet
require_secure_transport = ON
ssl_ca   = /etc/mysql/ssl/ca.pem
ssl_cert = /etc/mysql/ssl/server-cert.pem
ssl_key  = /etc/mysql/ssl/server-key.pem

# PostgreSQL: TLS'i aç, pg_hba.conf tarafında hostssl kuralları kullanın
ssl = on
ssl_cert_file = '/etc/postgresql/ssl/server.crt'
ssl_key_file  = '/etc/postgresql/ssl/server.key'

Sertifika tarafında yardıma ihtiyacınız olursa SSL sertifikası sayfamızdaki seçenekler bu senaryoyu da kapsar.

Sık Yapılan Hatalar#

Şifrelemeyi her şeyi çözen bir kalkan sanmak en temel hatadır. Encryption at rest, çalınmış bir diske karşı korur; çalınmış bir parolaya, SQL enjeksiyonuna ya da aşırı yetkili bir uygulama kullanıcısına karşı hiçbir şey yapmaz. Erişim kontrolü, en az yetki ilkesi ve güvenlik duvarı kuralları hâlâ birinci savunma hattıdır.

Anahtarı veriyle aynı yerde saklamak ikinci hatadır. Anahtar dosyası veri dizinindeyse ya da yedek arşivinin içindeyse, tek bir kopyalama işlemi hem kilidi hem anahtarı taşır.

Yalnızca tabloları şifreleyip logları unutmak üçüncüsüdür. Redo log, undo log, binlog, WAL arşivi ve geçici dosyalar aynı verinin izlerini taşır. Şifrelemeyi bunları da kapsayacak biçimde yapılandırın.

Kurtarmayı denememek dördüncüsüdür ve en pahalıya patlayanıdır. Şifreli bir yedeği geri yükleyebildiğinizi düzenli olarak sınamıyorsanız, elinizde yedek değil bir dosya yığını vardır. Yılda birkaç kez, şifreli yedekten temiz bir sunucuya tam geri yükleme provası yapın.

Sıkça Sorulan Sorular#

Veritabanı şifreleme performansı ne kadar düşürür#

Modern işlemcilerde AES donanım hızlandırma (AES-NI) bulunduğu için LUKS ve InnoDB tablo alanı şifrelemesinin maliyeti çoğu iş yükünde tek haneli yüzdelerde kalır. Etki en çok yoğun rastgele okuma yapan ve önbelleğe sığmayan iş yüklerinde hissedilir. Kolon bazında şifreleme ise farklıdır; her okuma ve yazmada çözme/şifreleme işlemi yapıldığı için maliyeti daha yüksektir ve şifreli kolonda indeks kullanılamadığı için sorgu planları da değişir. Bu yüzden kolon şifrelemesini tüm tabloya değil, yalnızca gerçekten hassas alanlara uygulayın.

KVKK veritabanı şifrelemesini zorunlu kılıyor mu#

KVKK, belirli bir teknolojiyi adıyla zorunlu kılmaz; veri sorumlusundan verinin niteliğine uygun teknik ve idari tedbirleri almasını ister. Kurul rehberlerinde şifreleme, özellikle özel nitelikli kişisel veriler için önerilen tedbirler arasında açıkça yer alır. Pratikte sağlık verisi, biyometrik veri ya da kimlik numarası gibi alanları şifrelemeden saklamak, bir veri ihlali sonrasında savunulması zor bir konumdur. Kararınızı verirken verinin hassasiyetini ve ihlal hâlindeki etkisini ölçün.

Şifreli kolonda arama yapabilir miyim#

Doğrudan yapamazsınız; şifreli değer her kayıt için farklı olduğundan LIKE ya da aralık sorgusu çalışmaz ve indeks kurulamaz. Eşitlik araması gerekiyorsa, şifreli kolonun yanına gizli bir anahtarla üretilmiş deterministik bir HMAC özeti kolonu ekleyip onu indeksleyebilirsiniz. Kısa ve tahmin edilebilir değerlerde düz özet kullanmayın; gizli anahtar olmadan üretilen özetler kaba kuvvetle çözülebilir. Aralık ve metin araması gerektiren alanları ise şifrelemek yerine erişim kontrolüyle korumak daha gerçekçidir.

Disk şifreleme mi veritabanı şifreleme mi seçmeliyim#

İkisi birbirinin alternatifi değil, farklı taneliklerdedir. Disk şifreleme motordan bağımsızdır, her şeyi kapsar ve kurulumu tek seferliktir; bu yüzden çoğu kurulum için doğru temeldir. Veritabanı seviyesindeki tablo alanı şifrelemesi ise hangi tabloların şifreleneceğini seçmenize izin verir ve paylaşımlı depolama kullanılan ortamlarda ek fayda sağlar. Bütçe ve karmaşıklık açısından tek bir katman seçecekseniz disk şifrelemeyle başlayın, ardından gerçekten hassas alanlar için kolon şifrelemesi ekleyin.

Şifreleme anahtarını kaybedersem ne olur#

Veriyi kaybedersiniz. Bu, şifrelemenin en acımasız tarafıdır: düzgün uygulanmış bir şifrelemede anahtarsız kurtarma yolu yoktur. Bu yüzden anahtarların da yedeklenmesi gerekir ve bu yedek, şifreli veriden fiziksel olarak ayrı bir yerde tutulmalıdır. Kurumsal ortamlarda anahtarın parçalara bölünüp birden fazla sorumluya dağıtılması yaygın bir uygulamadır. En azından anahtar yedeğini kasada ya da ayrı bir gizli bilgi yöneticisinde tutun ve kurtarma prosedürünü yazılı hâle getirin.

Yedeklerimi de şifrelemem gerekir mi#

Kesinlikle. Şifreli bir veritabanının şifresiz yedeği, korumanın tamamını ortadan kaldırır; üstelik yedekler tanım gereği kopyalanan, taşınan ve uzak depolara gönderilen dosyalardır. Dökümü üretirken bir boru hattıyla şifreleyin ki diske hiçbir zaman şifresiz hâli düşmesin. Şifreleme parolasını komut satırı argümanı olarak vermeyin; süreç listesinde ve kabuk geçmişinde görünür. Ortam değişkeni ya da dar izinli bir anahtar dosyası kullanın.

Kapanış#

Veritabanında şifreleme, doğru kurulduğunda gerçek bir koruma; yanlış anlaşıldığında ise sahte bir güven duygusu üretir. Aklınızda kalması gereken dört alışkanlık şunlar: hangi katmanın hangi tehdidi kapattığını bilerek seçim yapın ve şifrelemeyi erişim kontrolünün yerine koymayın; anahtarı asla şifrelediği veriyle aynı yerde saklamayın; tabloları şifrelerken redo/undo/binlog ve WAL gibi yan dosyaları da kapsayın; ve yedekleri şifreleyip şifreli yedekten geri yükleme provasını düzenli olarak yapın.

Şifreli bir veri diski, TLS'li bağlantılar ve düzenli şifreli yedekler için tam yetkili bir sunucuya ihtiyacınız olur; VDS ve bulut sunucu paketlerinde LUKS kurulumundan anahtar yönetimine kadar her şeyi kendiniz yapılandırabilirsiniz. Bağlantı katmanı için SSL sertifikası seçeneklerine, yedeklerin dışarıda ve şifreli saklanması için yedekleme hizmetimize bakabilir, kurulum ve sertleştirmeyi devretmek isterseniz sunucu yönetimi hizmetimizden yararlanabilirsiniz.