Bu rehber neyi çözer?
Database güvenliği yalnız parola politikası değildir. Network, identity, least privilege, şifreleme, audit, OS hardening, patch, secret yönetimi ve backup güvenliği birlikte tasarlanmalıdır.
Network izolasyonu
Database portları internete doğrudan açılmamalı; uygulama subnet/VLAN, firewall/security group ve bastion/VPN gibi katmanlar kullanılmalıdır.
Management erişimi ile application traffic mümkünse ayrıştırılmalıdır.
Authentication ve yetkilendirme
Shared admin account yerine kişisel hesap/identity, role-based permission ve least privilege uygulanmalıdır.
Service account credential’ları vault/secret manager içinde tutulmalı, source code veya config repository’ye yazılmamalıdır.
TLS ve at-rest encryption
Client-server trafik TLS ile korunmalı; hassas veri için engine’in desteklediği TDE/tablespace/storage encryption seçenekleri değerlendirilmelidir.
Encryption key’leri data dosyalarıyla aynı güvenlik alanında tutulmamalı; key rotation ve recovery prosedürü test edilmelidir.
Audit ve monitoring
Login failure, privilege changes, schema changes, administrative operations ve kritik data erişimleri risk seviyesine göre audit edilmelidir.
Audit logları DB sunucusundan bağımsız merkezi log/SIEM’e aktarılmalıdır.
Patch ve backup güvenliği
Database engine, OS, driver/client ve backup agent patch süreci birlikte yönetilmelidir.
Backup repository production credential’larından ayrıştırılmalı, immutable/offsite kopya ve restore testleri kullanılmalıdır.
Sık Sorulan Sorular
Database portunu sadece farklı porta almak yeterli mi?
Hayır. Port değişikliği temel güvenlik kontrolü değildir; network izolasyonu, firewall ve güçlü authentication gerekir.
TDE database’i tamamen güvenli yapar mı?
Hayır. TDE storage hırsızlığı riskini azaltır; yetkili kullanıcı, uygulama açığı veya credential hırsızlığına karşı diğer kontroller gerekir.
Backup neden ayrı credential kullanmalı?
Production compromise olduğunda saldırganın backup kopyalarını da silememesi veya şifreleyememesi için yetki alanları ayrılmalıdır.
Resmî teknik kaynaklar
- https://www.postgresql.org/docs/current/security.html
- https://dev.mysql.com/doc/refman/8.4/en/security.html
- https://learn.microsoft.com/sql/relational-databases/security/
- https://docs.oracle.com/en/database/oracle/oracle-database/23/dbseg/
- https://www.mongodb.com/docs/manual/security/
- https://mariadb.com/docs/server/security/
Veritabanı Altyapınızı Birlikte Değerlendirelim
Workload, güvenlik, donanım, HA ve yedekleme gereksinimlerinize göre altyapıyı birlikte planlayabiliriz.
Mimari ve çalışma modeli
Veritabanı güvenliği ağ erişimi, kimlik, rol, nesne izni, audit ve şifreleme katmanlarını birlikte kapsar. TLS aktarımı korur; disk/TDE koruması yetkili SQL okumasını otomatik engellemez. Uygulama hesabının schema değiştirme veya yönetici yetkisi gerekip gerekmediği sınanmalıdır. Backup ve anahtar erişimi aynı hassasiyetle yönetilir.
- 1Ağ/TLS erişimi
- 2Kimlik ve roller
- 3Nesne/audit politikası
- 4Backup ve anahtar kurtarma
Tasarım parametreleri
- Rol ve schema
- Uygulama runtime yetkisiyle migration/DDL yetkisini ayırın; ortak admin hesabından kaçının.
- Şifreleme sınırı
- TLS, disk/TDE ve sütun şifrelemesi farklı tehditleri kapsar; anahtar kurtarma ve plaintext yollarını kaydedin.
- İş yükü ve sorgu dağılımı
- Okuma/yazma oranı, bağlantı sayısı, transaction süresi ve yoğun sorguları ölçün. Veritabanı boyutu tek başına donanım gereksinimini açıklamaz.
- Bellek ve depolama
- Çalışma kümesi, günlük yazması, geçici alan ve checkpoint davranışını ayrı inceleyin. Güvenilir yazma garantisi performans kadar önemlidir.
- Kurtarma zinciri
- Başlangıç yedeği, gerekli günlükler, yapılandırma ve anahtarların birlikte geri getirilebildiğini sınayın.
- Erişim ve değişiklik
- Uygulama rolü, yönetici rolü ve schema değişiklik yetkisini ayırın. Üretimde indeks veya parametre değişimini kontrollü yapın.
Hesap ve uygulama örneği
Örnek uygulama rolü yalnız gerekli tabloları okuyup yazabilsin. Ayrı test hesabıyla diğer schema, backup ve yönetim işlemi reddedilsin. Audit kayıtları gerçek kimliğe bağlansın. Anahtar değişikliği sonrası eski şifreli backupın restore edilebildiğini doğrulayın.
Hata teşhisi
| Belirti | Olası neden / ayrım | Doğrulama |
|---|---|---|
| Şifreli backup restore olmuyor | Sertifika veya anahtar erişimi eksik olabilir. | Ana sunucu olmadan gerekli anahtarlarla izole restoreu doğrulayın. |
| CPU düşük, sorgu yavaş | Kilit, I/O veya istemci beklemesi baskın olabilir. | Yürütme planını ve bekleme türünü aynı sorgu için inceleyin. |
| Replica bağlı ama verisi eski | Gönderme, uygulama veya transaction beklemesi gerilik yaratabilir. | Son uygulanmış işlem ve kaynağın commit zamanını karşılaştırın. |
| Disk sürekli büyüyor | Günlük tutma, açık transaction, replication slot veya bakım ihtiyacı etkili olabilir. | Ürünün desteklediği istatistikleri inceleyin; günlükleri elle silmeyin. |
Kabul ve doğrulama kontrolleri
- Şifreleme, yetki ve audit sonuçlarını ayrı testlerle kanıtlayın.
- Temsilî transactionları ve sorguları gerçek veri dağılımıyla test edin.
- Ayrı hedefe restore yapıp uygulama kayıtlarını doğrulayın.
- Yetkisiz okuma ve schema değişikliği denemelerini test kimliğiyle reddedin.
- Failover sonrasında tek yetkili yazıcı ve doğru bağlantı hedefini doğrulayın.
- Bakım sırasında kilit, günlük hacmi ve gecikme değişimini ölçün.
İlgili kavramlar
En az yetki ve görev ayrımı
En az yetki, bir görevin gerektirdiği izinlerin belirli kaynak ve süreyle sınırlandırılmasıdır. Herkese aynı yönetici rolünü vermek, erişim incelemesini ve olay araştırmasını zorlaştırır. Günlük kullanıcı hesabı ile ayrıcalıklı hesabı ayırın; servis hesaplarının etkileşimli kullanımını ve gereksiz ağ erişimini kısıtlayın. Yetki matrisi, kimliğin kaynağa hangi işlemle eriştiğini göstermelidir. Bir izin kaldırıldığında uygulamanın çalışmayı sürdürmesi de test kapsamına girer: gereksiz yetkiler bazen yalnız kontrollü azaltma sırasında ortaya çıkar.
Kimlik doğrulama ve oturum
Kimlik doğrulama kullanıcının veya iş yükünün kim olduğunu kanıtlar; yetkilendirme ise bu kimliğin ne yapabileceğini belirler. Başarılı oturum açma, bütün kaynaklara erişim izni anlamına gelmez. Kullanıcı oturumları, servis kimlikleri, API belirteçleri ve cihaz sertifikaları farklı yaşam döngülerine sahiptir. İlk giriş kadar oturum süresi, belirteç yenileme, işten ayrılma, kayıp cihaz ve acil erişim senaryolarını da tasarlayın. Kimlik sağlayıcı erişilemez olduğunda hangi oturumların süreceğini ve hangi yeni erişimlerin engelleneceğini ölçün.
TLS ve sertifika doğrulaması
TLS iletişimin gizliliğini ve bütünlüğünü sağlar; sertifika doğrulaması karşı taraf kimliğinin kontrolüne yardımcı olur. Sertifika adı, zincir, geçerlilik süresi ve güvenilen kökler birlikte değerlendirilmelidir. Bir bağlantının şifreli olması uygulamanın yetkilendirmesinin doğru olduğu anlamına gelmez. Reverse proxy veya inspection kullanılıyorsa TLS oturumunun hangi noktada sonlandırıldığını çizimde açıkça gösterin. Hata teşhisinde sertifika kontrolünü kapatmak kalıcı çözüm değildir; yanlış hostname, eksik ara sertifika ve cihaz saatini ayrı inceleyin.
Şifreleme ve anahtarın yaşam döngüsü
Şifreleme, verinin anahtar olmadan okunmasını zorlaştırır; erişim kontrolü, silinme koruması ve yedekleme farklı ihtiyaçları karşılar. Taşınan veri ile disk üzerindeki veri için hangi katmanın şifreleme sağladığını belirtin. Anahtarların oluşturulması, korunması, döndürülmesi ve acil geri kazanımı tasarımın parçasıdır. Yedeği kurtarmak için gereken anahtar yalnız felaket sırasında kaybedilecek sunucuda bulunmamalıdır. Test ortamında ayrı bir yöneticiyle veriyi açma ve anahtar erişimini geri kazanma adımlarını uygulayın; gerçek anahtarları dokümana veya destek mesajına koymayın.
Telemetri ve zaman eşleştirmesi
Telemetri, sistemin ne yaptığını açıklayan log, metrik ve olay kayıtlarının bütünüdür. Log bir olayın ayrıntısını, metrik zaman içindeki davranışı, dağıtık iz ise isteğin bileşenler arasındaki yolunu gösterir. Saat farkları aynı olayı farklı zamanlarda olmuş gibi gösterebilir. Merkezi zaman senkronizasyonu, kaynak kimliği ve tutarlı saat dilimi kullanın. Alarm tasarımında yalnız eşik değil, ne kadar sürdüğü ve kullanıcıya etkisi de değerlendirilmelidir. Kayıtların kesildiği durum ayrıca izlenmeli; günlük kaydı bulunmaması, olay yaşanmadığı şeklinde yorumlanmamalıdır.
Politikanın yaşam döngüsü
Bir politika yalnız etkinleştirildiği anda değil, kapsamı değiştikçe de yönetilmelidir. Taslak, gözlem, pilot, uygulama ve periyodik inceleme aşamalarını ayırın. Her istisnanın sahibi, gerekçesi, kapsamı ve sona erme tarihi olmalıdır. Test verileri gerçek kullanıcı davranışını temsil etmezse başarılı pilot üretimde yanlış engellemelere dönüşebilir. Önce kimin ve hangi uygulamanın etkilenebileceğini belirleyin; sonra ölçülebilir kabul koşullarıyla devreye alın. Geri alma yolu yalnız düğme konumunu değil, değişikliğin kim tarafından ve hangi koşulda geri alınacağını da tanımlamalıdır.