Veritabanı Güvenliği: MySQL ve PostgreSQL için Erişim Kontrolü ve Şifreleme

Veritabanları uygulamanızın en değerli varlığını - veriyi - barındırır. Bir veritabanı ihlali müşteri bilgilerinin sızmasına, finansal kayba ve itibar hasarına yol açar. MySQL ve PostgreSQL'de varsayılan kurulum üretim ortamı için yeterli güvenlik sağlamaz. Bu rehberde erişim kontrolünden şifrelemeye, audit loglarından yedekleme güvenliğine kadar veritabanı güvenliğinin tüm katmanlarını ele alıyoruz.

Erişim Kontrolü ve Yetkilendirme

En az yetki prensibi veritabanı güvenliğinin temelidir. Her uygulama ve kullanıcı yalnızca ihtiyaç duyduğu tablolara ve işlemlere erişebilmelidir. Root/superuser hesabını uygulama bağlantıları için asla kullanmayın.

mysql-access-control.sql

-- Uygulama icin sinirli yetkili kullanici
CREATE USER 'app_user'@'10.0.10.%'
  IDENTIFIED BY 'guclu_parola_32_karakter';

-- Yalnizca gerekli yetkiler
GRANT SELECT, INSERT, UPDATE, DELETE
  ON myapp.* TO 'app_user'@'10.0.10.%';

-- Yedekleme icin ayri kullanici (yalnizca okuma)
CREATE USER 'backup_user'@'localhost'
  IDENTIFIED BY 'baska_guclu_parola';
GRANT SELECT, LOCK TABLES, SHOW VIEW, RELOAD
  ON *.* TO 'backup_user'@'localhost';

-- Gereksiz kullanicilari kaldir
DROP USER IF EXISTS ''@'localhost';  -- Anonim kullanici
FLUSH PRIVILEGES;

Ağ Güvenliği ve Bağlantı Şifreleme

Veritabanı portunu (MySQL: 3306, PostgreSQL: 5432) internete açmayın. Yalnızca uygulama sunucularından gelen bağlantılara izin verin. İstemci-sunucu arasındaki trafiği TLS ile şifreleyin.

postgresql pg_hba.conf

# PostgreSQL erisim kontrolu - pg_hba.conf
# TYPE  DATABASE  USER       ADDRESS        METHOD

# Yerel baglanti (Unix socket)
local   all       postgres                  peer

# Uygulama sunucusu (TLS zorunlu)
hostssl myapp     app_user   10.0.10.0/24   scram-sha-256

# Diger tum baglantilar reddedilir
host    all       all        0.0.0.0/0      reject

⚠️ Dikkat: PostgreSQL'de md5 kimlik doğrulama yöntemi artık güvenli kabul edilmemektedir. PostgreSQL 14+ sürümlerinde varsayılan olarak scram-sha-256 kullanılır. Mevcut kurulumlarınızı scram-sha-256'ya geçirin.

Veri Şifreleme: Transit ve At-Rest

Şifreleme Türü	Kapsam	Uygulama
In-Transit	İstemci-sunucu arası	TLS 1.2+ (require_secure_transport)
At-Rest (Disk)	Disk üzerindeki veri	LUKS/dm-crypt veya TDE
Column-Level	Hassas alanlar	pgcrypto / AES_ENCRYPT
Backup	Yedek dosyaları	GPG / openssl enc ile şifreleme

encrypted-backup.sh

#!/bin/bash
# Sifreli veritabani yedegi
DATE=$(date +%Y%m%d_%H%M%S)

# PostgreSQL yedek + GPG sifreleme
pg_dump -U backup_user myapp | \
  gpg --encrypt --recipient [email protected] \
  > /backups/myapp_${DATE}.sql.gpg

# MySQL yedek + openssl sifreleme
mysqldump -u backup_user myapp | \
  openssl enc -aes-256-cbc -salt -pbkdf2 \
  -out /backups/myapp_${DATE}.sql.enc

Veritabanı yedekleme otomasyonu için yedekleme rehberimizi, sunucu güvenliği için Hardening Checklist yazımızı inceleyin. Ağ izolasyonu için VPC rehberimize göz atın. Hosted Cloud bulut sunucuları ile güvenli veritabanı altyapınızı oluşturun.

Sıkça Sorulan Sorular

Veritabanı portunu internete açmak neden tehlikelidir?

İnternete açık veritabanı portları brute force saldırılarına, bilinen güvenlik açıklarının istismarına ve veri sızıntısına davetiye çıkarır. Shodan gibi tarama motorları açık veritabanı portlarını dakikalar içinde tespit eder.

At-rest şifreleme performansı etkiler mi?

Modern CPU'lardaki AES-NI donanım hızlandırması sayesinde at-rest şifreleme performans etkisi genellikle %2-5 arasındadır. Hassas veri barındıran sistemlerde bu maliyet kabul edilebilir düzeydedir.

SQL injection'ı ORM tamamen önler mi?

ORM'ler parametreli sorgular kullanarak SQL injection riskini büyük ölçüde azaltır. Ancak raw query kullanımı, dinamik tablo/kolon adları ve ORM bypass senaryolarında hala risk vardır. Input doğrulama her zaman ek katman olarak uygulanmalıdır.

Veritabanı audit logları ne kadar süre saklanmalı?

PCI DSS en az 1 yıl saklama gerektirir (3 ay anında erişilebilir). KVKK/GDPR için veri işleme logları ilgili verinin saklanma süresi boyunca tutulmalıdır. Genel öneri minimum 90 gün, ideal 1 yıldır.

Connection pooling güvenlik riski oluşturur mu?

Connection pooling doğru yapılandırıldığında güvenlik riski oluşturmaz. Ancak bağlantı havuzundaki tüm bağlantılar aynı veritabanı kullanıcısını paylaşır. Farklı yetki seviyelerine ihtiyaç varsa ayrı havuzlar oluşturun.

Sonuç

Veritabanı güvenliği çok katmanlı bir yaklaşım gerektirir. En az yetki prensibiyle erişim kontrolü, TLS ile bağlantı şifreleme, at-rest şifreleme ve düzenli audit logları ile verilerinizi koruyun. Yedeklerinizi şifreleyin ve veritabanı portlarını asla internete açmayın.

Güvenli Veritabanı Altyapısı

Hosted Cloud bulut sunucuları ile izole ağ, şifreli bağlantı ve otomatik yedekleme destekli veritabanı altyapınızı kurun.

Bulut Sunucu Planlarını İncele →