Veritabanı Şifresi Güvenliği: Kritik Best Practice Rehberi

Bir saldırgan web sunucunuza erişirse en kötü ihtimalle birkaç dosyaya ulaşır. Ama veritabanı kimlik bilgilerini ele geçirirse — tüm kullanıcı verisi, sipariş geçmişi, şifreli alanlar dahil — uygulamanızın kalbi önünde açılır. Raporlanan veri ihlallerinin büyük çoğunluğunda ele geçirilen kimlik bilgileri (credential) başlıca etken olarak görünmektedir. Paylaşımlı hostingden VDS'ye geçen geliştiricilerin önemli bir kısmı eski alışkanlıkla şifreleri kaynak koda gömmektedir. Bu rehberde, veritabanı şifrelerini hangi yöntemlerle sakladığınızın farkını anlayacak ve hangi yaklaşımın hangi ortamda kabul edilebilir olduğunu öğreneceksiniz.

Hata 1: Kaynak Koda Gömülü Şifre

PHP, Python, Node.js fark etmez — en yaygın hata şudur:

$conn = new mysqli("localhost", "root", "P@ssw0rd123", "mydb");

Bu satır bir kez git push edildiğinde, şifre kalıcı olarak git geçmişine işlenir. Repoyu sonradan private yapmanız veya ilgili commit'i silmeniz geçmişi temizlemez; git log veya git reflog ile hâlâ ulaşılabilirdir.

Neden tehlikeli:

• Public repoysa GitHub/GitLab taramaları bu şifreyi dakikalar içinde bulur
• Private repo olsa bile ekip üyesi sayısı arttıkça maruz kalma yüzeyi genişler
• CI/CD loglarında şifre açıkta görünebilir

Mevcut reponuzda gömülü kimlik bilgisi olup olmadığını şu komutla kontrol edebilirsiniz:

git log -p | grep -iE "password|passwd|db_pass|secret"

Çıktı dolu geliyorsa, o commit'lerin geçmişten tamamen silinmesi için git filter-repo aracı kullanılmalıdır — salt commit'i geri almak yeterli değildir.

Hata 2: .env Dosyasını Yanlış Kullanmak

.env dosyası doğru bir yaklaşımdır ancak yanlış uygulanınca zararsız değildir.

Doğru kullanım adımları:

1. .gitignore dosyasına mutlaka .env ekleyin
2. Sunucuda chmod 600 .env ve chown www-data:www-data .env uygulayın
3. .env.example dosyasına sadece anahtar isimleri yazın, değer değil:

DB_HOST=
DB_NAME=
DB_USER=
DB_PASSWORD=

Paylaşımlı hostingde bu dosyanın public_html dizini dışında tutulması kritiktir. VDS kullanıyorsanız dosyayı web kök dizininin bir seviye üstüne alın.

Hata 3: Root Kullanıcısıyla Bağlanmak

MySQL veya PostgreSQL'de uygulamanızı root ya da postgres kullanıcısıyla çalıştırmak, kasiyere şirketin tüm banka hesaplarına erişim vermekle eşdeğerdir.

En az yetki (least privilege) ilkesi:

Her uygulama için yalnızca o uygulamanın ihtiyaç duyduğu işlemlere izin verilmiş ayrı bir veritabanı kullanıcısı oluşturun.

MySQL örneği:

CREATE USER 'uygulama_user'@'localhost' IDENTIFIED BY 'guclu_sifre_buraya';
GRANT SELECT, INSERT, UPDATE, DELETE ON myapp_db.* TO 'uygulama_user'@'localhost';
FLUSH PRIVILEGES;

Bu kullanıcı DROP TABLE, CREATE DATABASE, GRANT gibi yıkıcı işlemleri yapamaz. Uygulama katmanında bir SQL injection açığı olsa bile saldırgan veritabanı yapısını bozamaz, başka bir veritabanına sıçrayamaz.

Dikkat: 'uygulama_user'@'%' yerine 'uygulama_user'@'localhost' veya belirli bir IP adresi belirtin. % joker karakteri tüm IP adreslerine izin verir ve uzaktan kaba kuvvet (brute-force) saldırılarının önünü açar.

Secrets Manager: Kurumsal Düzeyde Çözüm

Ortam değişkenleri bir adım iyidir; ancak secrets manager (gizli bilgi yöneticisi) kimlik bilgilerini şifreli depolar, her erişimi loglar ve otomatik rotasyon (yenileme) uygular.

HashiCorp Vault

Açık kaynak ve kendi VDS'nize kurulabilir. Şifreyi uygulama doğrudan çalışma zamanında çeker; dosyaya hiçbir zaman yazılmaz.

# Vault'tan şifreyi çekme
vault kv get -field=password secret/myapp/db

AWS Secrets Manager / Azure Key Vault

Yönetilen (managed) bulut çözümleri. Saklanan gizli bilgi başına aylık birkaç dolar maliyetle otomatik rotasyon, versiyon geçmişi ve ince ayarlı erişim politikaları sunar.

Küçük Projeler için Kabul Edilebilir Minimum

Her projenin Vault altyapısı kurması gerekmez. Küçük ölçekli projeler için geçerli minimum:

• .env dosyası (git dışında, chmod 600)
• Least privilege veritabanı kullanıcısı
• Paylaşımlı hosting yerine izole VDS ortamı

Veritabanı Bağlantısını TLS ile Şifrelemek

Uygulama sunucusu ile veritabanı sunucusu aynı fiziksel makinede değilse ve TLS yapılandırılmamışsa, kimlik bilgileri ve sorgu sonuçları ağ üzerinde açık metin (plaintext) olarak iletilir.

MySQL'de TLS zorunlu hale getirme (my.cnf):

[mysqld]
require_secure_transport = ON
ssl-ca   = /etc/mysql/ssl/ca-cert.pem
ssl-cert = /etc/mysql/ssl/server-cert.pem
ssl-key  = /etc/mysql/ssl/server-key.pem

Bağlantının gerçekten şifreli olup olmadığını doğrulamak için:

SHOW STATUS LIKE 'Ssl_cipher';

Boş çıktı, TLS olmadan bağlandığınız anlamına gelir.

PostgreSQL'de bağlantı dizesine sslmode=verify-full parametresi eklenerek sunucu sertifikası doğrulaması zorunlu kılınır. sslmode=require sertifikayı doğrulamaz; bu nedenle man-in-the-middle saldırılarına karşı korumasızdır.

Uygulama Kullanıcı Şifrelerini Hashleme

Bu başlık veritabanına bağlanmak için değil, kullanıcı şifrelerini veritabanında saklamak için geçerlidir. Yanlış hashleme algoritması seçimi, şifre veritabanının sızdığı durumlarda kullanıcı hesaplarının toplu olarak ele geçirilmesine yol açar.

Python ile Argon2id örneği:

from argon2 import PasswordHasher
ph = PasswordHasher(time_cost=2, memory_cost=65536, parallelism=2)
hash_degeri = ph.hash("kullanici_sifresi")

Cost factor parametrelerini düzenli olarak gözden geçirin; donanım güçlendikçe hash hesaplama süresi azalır ve parametrelerin artırılması gerekir.

Kimlik Bilgisi Rotasyonu

Şifreyi bir kez belirleyip yıllarca değiştirmemek, güvenliğin görünmez deliklerinden biridir. Kimlik bilgisi daha önce sızmış olsa bile fark etmeyebilirsiniz.

Minimum rotasyon politikası:

• Veritabanı şifreleri en az 90 günde bir değiştirilmeli
• Ekip üyesi ayrıldığında ilgili tüm kimlik bilgileri derhal yenilenmeli
• CI/CD sistemlerindeki gizli değişkenler (secret variables) 6 ayda bir rotasyona tabi tutulmalı

Secrets manager kullanıyorsanız otomatik rotasyon yapılandırılabilir. AWS Secrets Manager'da Lambda entegrasyonuyla 30 günde bir otomatik şifre değişimi birkaç adımda kurulur; bu süreçte uygulama kesintisiz çalışır.

Ortama Göre Hangi Yöntemi Kullanmalısınız?

Sonuç

Veritabanı kimlik bilgilerini korumak için karmaşık altyapı gerekmez, ancak birkaç temel kuralı atlamak tüm uygulamanın kontrolünü kaybetmenize yol açar. Bugün yapabileceğiniz en etkili üç adım şunlardır: kaynak kodunuzu şimdi tarayın ve gömülü kimlik bilgisi içerip içermediğini kontrol edin, veritabanı kullanıcısının yetkilerini yalnızca ihtiyaç duyduğu işlemlerle sınırlayın ve .env dosyanızın hem git dışında hem de chmod 600 ile korunduğundan emin olun. Bu üç adım, ek araç maliyeti olmadan maruz kalma yüzeyinizi ciddi ölçüde daraltır.