PostgreSQL, MSSQL ve Oracle Güvenliği: Kritik Yapılandırmalar ve Farklar

Kurumsal ortamlarda tek bir veritabanı teknolojisi kullanılması giderek daha az rastlanan bir durumdur.

Bir kurum aynı anda;

PostgreSQL,

Microsoft SQL Server – MSSQL,

Oracle Database

ve farklı açık kaynak veya cloud database platformlarını birlikte kullanabilir.

Bu nedenle database security yaklaşımı sadece:

“Veritabanını güvenli hale getirelim.”

demekle tamamlanamaz.

Her platformun;

authentication yapısı,

privileged account modeli,

network configuration,

audit mekanizmaları,

encryption yetenekleri,

patching yaklaşımı

ve işletim modeli farklıdır.

Buna rağmen güvenliğin temel prensipleri değişmez.

Hangi DBMS kullanılırsa kullanılsın;

Least Privilege,

Secure Configuration,

Network Segmentation,

Encryption,

Audit,

Patch Management,

Backup Security

ve Continuous Monitoring

uygulanmalıdır.

Bu nedenle doğru database security yaklaşımı iki katmandan oluşmalıdır:

Vendor-Neutral Security Baseline

Platform-Specific Hardening

İlk katman kurum genelindeki minimum güvenlik seviyesini belirler.

İkinci katman ise PostgreSQL, MSSQL veya Oracle'ın kendine özgü risklerini ve güvenlik özelliklerini ele alır.

PostgreSQL, MSSQL ve Oracle Güvenliği Aynı mı?

Temel güvenlik prensipleri aynıdır.

Ancak teknik implementation farklıdır.

Örneğin:

PostgreSQL'de;

roles,

pg_hba.conf,

listen_addresses,

extensions

kritiktir.

MSSQL'de;

Windows Authentication,

SQL Logins,

sa,

sysadmin,

SQL Server Audit,

service account

ön plana çıkar.

Oracle'da ise;

SYS,

SYSTEM,

listener,

profiles,

roles,

Unified Auditing,

TDE

gibi konular özellikle önemlidir.

Vendor-Neutral Database Security Nedir?

Platformdan bağımsız uygulanması gereken temel güvenlik prensipleridir.

Örneğin:

• Public database exposure minimum olmalı
• Kullanıcılar kişiye özel olmalı
• Shared administrator account kullanılmamalı
• Least Privilege uygulanmalı
• TLS kullanılmalı
• Critical activity audit edilmeli
• Patch seviyesi güncel olmalı
• Backup şifrelenmeli
• Privileged kullanıcılar izlenmeli
• Configuration baseline oluşturulmalı

Bu maddeler üç database platformu için de geçerlidir.

Database Platformuna Özel Hardening Neden Gereklidir?

Her DBMS'nin kendi;

default configuration,

authentication mechanism,

network behavior,

extension architecture,

administrative privilege modeli

vardır.

Bu nedenle generic checklist tek başına yeterli olmayabilir.

PostgreSQL Güvenliği Nedir?

PostgreSQL güvenliği;

authentication,

role management,

network restriction,

TLS,

logging,

extension governance,

operating system security

katmanlarını kapsar.

PostgreSQL esnek ve güçlü bir database sistemidir.

Ancak bu esneklik yanlış configuration durumunda güvenlik riski oluşturabilir.

PostgreSQL'de Role Kavramı

PostgreSQL'de kullanıcı ve rol kavramları birbirine oldukça yakındır.

Bir role login yeteneği verilirse database'e bağlanabilen kullanıcı gibi davranabilir.

PostgreSQL Superuser Nedir?

Superuser PostgreSQL üzerindeki birçok güvenlik kontrolünü aşabilen yüksek yetkili roldür.

Bu nedenle kullanımı minimum tutulmalıdır.

Application PostgreSQL Superuser Olmalı mı?

Kesinlikle gereksizse hayır.

Application yalnızca ihtiyaç duyduğu schema, table veya procedure üzerinde yetkili olmalıdır.

PostgreSQL Superuser Kişiye Özel Olmalı mı?

Yüksek yetkili erişimlerin mümkün olduğunca kişiye özel ve audit edilebilir olması gerekir.

Ortak administrator hesapları accountability sorununa yol açar.

PostgreSQL pg_hba.conf Nedir?

PostgreSQL güvenliğinin en kritik configuration dosyalarından biridir.

pg_hba.conf, hangi client'ın;

hangi database'e,

hangi kullanıcıyla,

hangi network'ten,

hangi authentication yöntemiyle

bağlanabileceğini belirler.

pg_hba.conf Neden Bu Kadar Önemlidir?

Yanlış veya aşırı geniş bir kural database'e beklenmeyen network'lerden erişime izin verebilir.

Bu nedenle kurallar mümkün olduğunca spesifik tasarlanmalıdır.

pg_hba.conf İçin Temel Güvenlik Yaklaşımı

Mantık şu olmalıdır:

Sadece gerekli network.

Sadece gerekli kullanıcı.

Sadece gerekli database.

Güçlü authentication.

PostgreSQL'de listen_addresses Nedir?

Database server'ın hangi network interface'lerinde bağlantı kabul edeceğini belirler.

PostgreSQL Tüm Interface'lerde Dinlemeli mi?

İş ihtiyacı yoksa hayır.

Database yalnızca gerekli network interface'lerinde erişilebilir olmalıdır.

PostgreSQL Public Internet'e Açılmalı mı?

Production PostgreSQL database'in doğrudan internete açık olması çoğu kurumsal mimaride gereksiz risk oluşturur.

Application veya management network üzerinden kontrollü erişim tercih edilmelidir.

PostgreSQL TLS Kullanmalı mı?

Evet.

Client-database trafiğinde TLS kullanılması hassas verinin network üzerinde korunmasına yardımcı olur.

PostgreSQL Authentication Nasıl Güçlendirilir?

Güçlü password authentication, certificate tabanlı yöntemler veya uygun centralized identity entegrasyonları kullanılabilir.

Modern password authentication yöntemleri tercih edilmelidir.

PostgreSQL SCRAM Nedir?

SCRAM tabanlı password authentication, eski password yöntemlerine kıyasla daha modern bir authentication yaklaşımıdır.

PostgreSQL'de Password Policy Nasıl Yönetilir?

DBMS seviyesi yanında merkezi identity veya organization policy kullanılması değerlendirilebilir.

PostgreSQL Public Schema Neden Kontrol Edilmeli?

Default privilege davranışları kurumun security baseline'ına uygun olmayabilir.

Bu nedenle;

schema ownership,

CREATE permission,

default privileges

gözden geçirilmelidir.

Default Privileges Nedir?

Yeni oluşturulan database objelerine varsayılan olarak hangi yetkilerin verileceğini belirler.

PostgreSQL'de Role Inheritance Riskli mi?

Karmaşık role yapılarında kullanıcı beklenenden fazla yetki kazanabilir.

Effective permission analizi yapılmalıdır.

PostgreSQL Extension Nedir?

Database'e ek yetenek sağlayan modüllerdir.

Extension'lar Neden Güvenlik Riski Olabilir?

Gereksiz veya güvensiz extension;

attack surface,

dependency,

code execution capability

ekleyebilir.

PostgreSQL'de Her Extension Kurulmalı mı?

Hayır.

Sadece iş ihtiyacı olan extension'lar kullanılmalıdır.

PostgreSQL Logging Neden Önemlidir?

Connection,

authentication,

query,

role activity

gibi olaylar security monitoring için kullanılabilir.

PostgreSQL log_statement Her Sistemde Açılmalı mı?

Hayır.

Yoğun production sistemlerinde yüksek log hacmi oluşturabilir.

Risk bazlı logging policy kullanılmalıdır.

PostgreSQL Audit Nasıl Yapılır?

Native logging yetenekleri yanında uygun audit mekanizmaları kullanılabilir.

Amaç özellikle;

privileged activity,

role changes,

critical table access

gibi event'lerin izlenmesidir.

PostgreSQL OS Security Neden Önemlidir?

PostgreSQL çoğunlukla Linux gibi işletim sistemleri üzerinde çalışır.

Bu nedenle database security aynı zamanda;

service account,

file permission,

OS patching,

SSH access

güvenliğine bağlıdır.

PostgreSQL Data Directory Permissions Neden Kritik?

Database dosyalarına yetkisiz OS kullanıcısının erişebilmesi ciddi risk oluşturur.

PostgreSQL Backup Security

pg_dump veya fiziksel backup dosyaları production verisini içerebilir.

Bu nedenle backup;

encryption,

restricted access,

secure storage

ile korunmalıdır.

PostgreSQL Replication Security

Replication connection'ları ayrı kullanıcı, minimum permission ve network restriction ile korunmalıdır.

PostgreSQL'de Replication Account Normal Kullanıcı Olmalı mı?

Sadece replication görevine gerekli yetki verilmelidir.

PostgreSQL Patch Management

PostgreSQL major ve minor version lifecycle takip edilmelidir.

Security fix içeren güncellemeler kontrollü şekilde uygulanmalıdır.

Unsupported PostgreSQL Version Kullanmak Riskli mi?

Evet.

Security update almayan sürümler zamanla yüksek risk oluşturur.

Microsoft SQL Server Güvenliği Nedir?

MSSQL güvenliği;

Windows/AD integration,

SQL Login,

server role,

database role,

service account,

encryption,

audit

gibi katmanları içerir.

Windows Authentication Nedir?

Kullanıcının Windows veya Active Directory kimliğiyle SQL Server'a erişmesidir.

Windows Authentication Neden Tercih Edilebilir?

Central identity management sağlar.

Kullanıcı lifecycle, MFA ve security policy merkezi kimlik altyapısıyla yönetilebilir.

SQL Authentication Nedir?

SQL Server içerisinde tanımlanan username/password ile authentication yöntemidir.

Windows Authentication Her Zaman Daha mı Güvenli?

Her ortam için otomatik olarak değil.

Active Directory güvenliği zayıfsa database riski de artabilir.

Mixed Mode Authentication Nedir?

SQL Server'ın hem Windows Authentication hem SQL Authentication kabul etmesidir.

Mixed Mode Gereksizse Açık Olmalı mı?

Security baseline iş ihtiyacına göre gereksiz authentication yöntemlerini kapatmalıdır.

MSSQL sa Hesabı Nedir?

sa, SQL Server'ın yüksek yetkili built-in administrator hesabıdır.

sa Hesabı Neden Kritik?

Bilinen account ismidir ve çok yüksek yetkiye sahip olabilir.

Bu nedenle kullanılmıyorsa güvenli şekilde devre dışı bırakılması veya çok sıkı korunması değerlendirilmelidir.

sa Hesabını Rename Etmek Yeterli mi?

Hayır.

Asıl kontrol;

disable,

strong authentication,

limited usage,

monitoring

olmalıdır.

Sadece isim değiştirmek temel güvenlik kontrolünün yerine geçmez.

MSSQL sysadmin Nedir?

SQL Server üzerindeki en yüksek yetkili server role'lerinden biridir.

Kaç Kullanıcı sysadmin Olmalı?

Minimum sayıda.

“Belki lazım olur” yaklaşımıyla sysadmin verilmemelidir.

Application Account sysadmin Olmalı mı?

Genellikle kesinlikle hayır.

Application'a sadece ihtiyacı olan database ve objeler üzerinde yetki verilmelidir.

MSSQL Server Role ile Database Role Farkı

Server role tüm SQL Server instance seviyesinde yetki sağlayabilir.

Database role ise belirli database içindeki yetkileri yönetebilir.

MSSQL Windows Group Kullanımı Faydalı mı?

Evet.

AD group üzerinden role assignment merkezi yönetimi kolaylaştırabilir.

Ancak AD Group Riskli Olabilir mi?

Group membership kontrol edilmezse kullanıcı dolaylı olarak yüksek database yetkisi alabilir.

MSSQL Service Account Nedir?

SQL Server servislerinin işletim sistemi üzerinde çalıştığı kimliktir.

MSSQL Service Account Domain Admin Olmalı mı?

Hayır.

Service account minimum OS ve network yetkisine sahip olmalıdır.

Dedicated Service Account Kullanılmalı mı?

Kritik servisler için ayrı service identity tercih edilebilir.

MSSQL Network Exposure Nasıl Sınırlandırılmalı?

Database portları yalnızca gerekli application ve management network'lerinden erişilebilir olmalıdır.

SQL Server Browser Service Nedir?

SQL Server instance keşfi ve bağlantı süreçlerine yardımcı olan servistir.

SQL Server Browser Her Zaman Gerekli mi?

Hayır.

Gereksizse kapatılması attack surface azaltabilir.

MSSQL xp_cmdshell Nedir?

SQL Server üzerinden işletim sistemi komutlarıyla etkileşime izin verebilen güçlü bir özelliktir.

xp_cmdshell Açık Olmalı mı?

İş ihtiyacı yoksa kapalı tutulması genel hardening yaklaşımıdır.

Çünkü database compromise etkisini operating system seviyesine taşıyabilir.

MSSQL CLR veya Diğer Gelişmiş Özellikler Kontrol Edilmeli mi?

Evet.

Kullanılmayan advanced özellikler kapalı tutulmalıdır.

MSSQL TLS Kullanmalı mı?

Evet.

Client bağlantılarında encryption zorunlu hale getirilebilir.

Force Encryption Nedir?

SQL Server tarafında client bağlantılarının şifreli olmasını zorlamaya yönelik configuration yaklaşımıdır.

MSSQL Certificate Yönetimi Neden Önemlidir?

Yanlış veya süresi dolmuş certificate application connectivity problemi oluşturabilir.

MSSQL TDE Nedir?

Transparent Data Encryption, SQL Server data ve log dosyalarının disk üzerinde şifrelenmesini sağlar.

TDE DBA'dan Veriyi Gizler mi?

Hayır.

Yetkili kullanıcı SQL üzerinden plaintext veriyi okuyabilir.

MSSQL Backup Encryption Neden Ayrı Kontrol Edilmeli?

Database encryption ile backup encryption'ın kapsamı ve key dependency'si doğru doğrulanmalıdır.

MSSQL SQL Server Audit Nedir?

Server ve database seviyesindeki güvenlik aktivitelerini kaydetmek için kullanılabilen audit mekanizmasıdır.

MSSQL Extended Events Nedir?

SQL Server üzerindeki event'leri detaylı izlemek için kullanılan güçlü diagnostic ve monitoring mekanizmasıdır.

Extended Events Security Monitoring İçin Kullanılabilir mi?

Evet.

Ancak hangi event'lerin toplandığı ve storage etkisi doğru tasarlanmalıdır.

MSSQL Login Audit

Successful ve failed login olayları özellikle privileged account'lar için izlenmelidir.

MSSQL Agent Job'ları Audit Edilmeli mi?

Evet.

SQL Server Agent üzerinden çalışan job'lar database ve OS üzerinde önemli işlemler yapabilir.

Linked Server Nedir?

Bir SQL Server'ın başka database veya data source'a bağlanmasını sağlar.

Linked Server Neden Risklidir?

Bir instance compromise olduğunda başka sisteme lateral movement veya unauthorized data access yolu oluşturabilir.

Linked Server Credential'ları Nasıl Korunmalı?

Minimum permission ve secure credential management uygulanmalıdır.

MSSQL Database Mail Security Açısından Kontrol Edilmeli mi?

Gereksiz özelliklerin aktif olması attack surface'i artırabilir.

Kullanım ihtiyacı değerlendirilmelidir.

MSSQL Patch Management

SQL Server cumulative update ve security update seviyeleri takip edilmelidir.

MSSQL EOL Sürüm Kullanmak Riskli mi?

Evet.

Security update almayan SQL Server sürümleri ciddi operasyonel ve güvenlik riski oluşturur.

Oracle Database Güvenliği Nedir?

Oracle security;

privileged account,

listener,

roles,

profiles,

TDE,

audit,

patch management

gibi alanları kapsar.

Oracle kurumsal yapılarda yüksek değerli ve kritik database sistemlerinde sık kullanıldığı için privileged access security özellikle önemlidir.

Oracle SYS Hesabı Nedir?

Oracle'ın en yüksek yetkili administrative account'larından biridir.

SYS Günlük İşlerde Kullanılmalı mı?

Hayır.

Yalnızca gerçekten gerekli yüksek yetkili yönetim işlemlerinde kullanılmalıdır.

Oracle SYSTEM Hesabı Nedir?

Yüksek yönetim yetkisine sahip başka bir built-in administrative account'tur.

SYS ve SYSTEM Shared Kullanılmalı mı?

Mümkün olduğunca kişiye özel administrator kimlikleri ve accountability yaklaşımı tercih edilmelidir.

Oracle SYSDBA Nedir?

Çok yüksek database administration yetkisi sağlayan ayrıcalıklı yönetim yetkisidir.

SYSDBA Yetkisi Minimum Kullanıcıda mı Olmalı?

Evet.

Application User SYSDBA Olabilir mi?

İş gereği yoksa kesinlikle hayır.

Oracle Listener Nedir?

Client'ların Oracle database servislerine network üzerinden bağlanmasını yöneten temel bileşendir.

Listener Neden Security Açısından Kritik?

Database'e network erişiminin önemli giriş noktalarından biridir.

Oracle Listener İnternete Açılmalı mı?

Kritik production database için doğrudan public exposure çoğu mimaride gereksiz risk oluşturur.

Oracle Network Restriction Nasıl Yapılmalı?

Firewall,

network segmentation,

allowed hosts,

secure protocol

yaklaşımlarıyla sınırlandırılmalıdır.

Oracle Profiles Nedir?

User password ve session politikaları gibi kontrollerin tanımlanmasına yardımcı olan yapılardır.

Oracle Password Policy Nasıl Yönetilebilir?

Profile üzerinden;

password lifecycle,

failed login,

session

gibi politikalar uygulanabilir.

Oracle Default Account'lar Neden Kontrol Edilmeli?

Kurulum veya component'lerle gelen kullanılmayan default/sample account'lar attack surface artırabilir.

Sample Schema Production'da Bulunmalı mı?

İhtiyaç yoksa kaldırılması veya kullanılmaması daha güvenli olabilir.

Oracle Role Management

Kullanıcılara direct grant yerine iş rollerine göre yetki verilmesi yönetimi kolaylaştırabilir.

Oracle PUBLIC Privilege Neden Kontrol Edilmeli?

PUBLIC'a verilen yetkiler çok geniş kullanıcı kitlesine erişim sağlayabilir.

Bu nedenle düzenli olarak review edilmelidir.

Oracle TDE Nedir?

Oracle Transparent Data Encryption, database verilerinin at-rest korunmasını sağlayan önemli security mekanizmalarından biridir.

Oracle TDE Key Management Neden Kritik?

Encrypted database'in kullanılabilmesi encryption key veya wallet erişimine bağlıdır.

Oracle Wallet / Keystore Nedir?

Encryption key ve certificate gibi cryptographic materyallerin güvenli yönetiminde kullanılan yapıdır.

Keystore Backup Gerekli mi?

Evet.

Encryption key kaybolursa database recovery ciddi şekilde etkilenebilir.

Oracle Unified Auditing Nedir?

Oracle üzerindeki audit event'lerinin daha merkezi biçimde yönetilmesini sağlayan audit yaklaşımıdır.

Oracle Audit Hangi Olayları İzlemeli?

Risk bazlı olarak;

privileged login,

role changes,

user creation,

critical table access,

configuration changes

izlenebilir.

Oracle Fine-Grained Auditing Nedir?

Belirli object veya koşullara göre daha detaylı audit yapılmasını sağlayan yaklaşımdır.

Fine-Grained Audit Ne İşe Yarar?

Örneğin yalnızca hassas salary kolonuna erişim gibi daha spesifik aktiviteler izlenebilir.

Oracle Database Vault Nedir?

Yüksek yetkili administrator erişimini bile belirli data domain'lerinde sınırlamaya yardımcı olabilen güvenlik özelliğidir.

Oracle Database Vault DBA'dan Veriyi Koruyabilir mi?

Doğru tasarımda separation of duties ve privileged user access kontrolünü güçlendirebilir.

Oracle Patch Management Neden Kritik?

Oracle Critical Patch Update yayınlarını ve desteklenen sürüm seviyelerini takip etmek gerekir.

Oracle EOL Sürüm Kullanmak Riskli mi?

Evet.

Security support almayan sürümler kritik risk oluşturabilir.

PostgreSQL, MSSQL ve Oracle Authentication Karşılaştırması

Alan	PostgreSQL	MSSQL	Oracle
Local User/Role	Var	Var	Var
Central Identity	Entegrasyon mümkün	AD/Windows güçlü	Entegrasyon mümkün
Built-in High Privilege	Superuser	sa/sysadmin	SYS/SYSDBA
Certificate/TLS	Var	Var	Var
Role-Based Access	Var	Var	Var

Platform farklı olsa da amaç aynıdır:

güçlü kimlik doğrulama ve minimum yetki.

Privileged Account Karşılaştırması

PostgreSQL:

Superuser

MSSQL:

sysadmin / sa

Oracle:

SYS / SYSDBA

Bu hesapların ortak özelliği çok geniş yetkidir.

Bu nedenle;

MFA,

PAM,

JIT,

Audit

gibi ek kontrollerle korunmalıdır.

Network Security Karşılaştırması

PostgreSQL:

pg_hba.conf + listen_addresses + firewall

MSSQL:

instance network config + firewall + encryption

Oracle:

listener + network restriction + firewall

Platform farklıdır ancak güvenlik prensibi:

Database'e yalnızca gerekli sistemler bağlanmalıdır.

Encryption Karşılaştırması

Her üç platformda da;

TLS,

at-rest encryption,

backup security

değerlendirilmelidir.

Özellik isimleri ve lisanslama yapıları farklı olabilir.

Database Encryption Özellikleri Lisansa Bağlı Olabilir mi?

Evet.

Özellikle kurumsal database ürünlerinde bazı security feature'ları edition veya lisans modeline bağlı olabilir.

Bu nedenle mimari yalnızca teknik değil lisans açısından da doğrulanmalıdır.

Audit Karşılaştırması

PostgreSQL:

Native logs + uygun audit mekanizmaları.

MSSQL:

SQL Server Audit + Extended Events.

Oracle:

Unified Auditing + diğer audit mekanizmaları.

Amaç her platformda aynıdır:

Accountability ve visibility.

Platform Farklı Olsa da SIEM'e Tek Format Gönderilebilir mi?

Normalization ile evet.

SIEM farklı database event'lerini ortak security schema'ya dönüştürebilir.

Örnek Normalized Event

Database Type: PostgreSQL

Event: Privileged Login

User: DBA01

Source: 10.x.x.x

Severity: High

Aynı event MSSQL veya Oracle'dan da gelebilir.

Çoklu Database Ortamında DAM Neden Değerlidir?

PostgreSQL, MSSQL ve Oracle aktivitelerini ortak security dashboard üzerinde toplamak mümkündür.

Bu SOC açısından önemli avantaj sağlar.

Database Administration Tool Security

DBA'lar farklı GUI ve management tool'ları kullanabilir.

Bu araçların;

credential storage,

version,

endpoint security

durumu da kontrol edilmelidir.

DBA Tool İçinde Password Kaydetmek Riskli mi?

Endpoint compromise olursa stored credential'lar risk altında olabilir.

Bu nedenle PAM veya secure vault yaklaşımı tercih edilebilir.

Developer Database Client Riskli mi?

Production credential developer laptop'unda tutuluyorsa risk artar.

Production Database'e Kişisel Laptop'tan Erişim Olmalı mı?

Kritik yapılarda kontrollü PAW, bastion veya PAM yaklaşımı tercih edilebilir.

PostgreSQL, MSSQL ve Oracle İçin Ortak OS Hardening

Database platformundan bağımsız olarak;

unnecessary services disabled,

OS patched,

local admin restricted,

EDR deployed,

file permissions hardened

olmalıdır.

Database Server Domain'e Dahil Edilmeli mi?

Mimari ve platform ihtiyacına göre değerlendirilmelidir.

Özellikle MSSQL tarafında AD integration sık kullanılır.

Ancak domain compromise riskinin database'e etkisi ayrıca değerlendirilmelidir.

Database Server EDR Kullanmalı mı?

Uyumluluk ve performance testleriyle kritik server'larda endpoint detection değerlendirilebilir.

EDR Database File'larını Tararken Performance Sorunu Oluşturabilir mi?

Evet.

Vendor best practice ve exclusions dikkatle tasarlanmalıdır.

Security tool tuning yapılmalıdır.

Antivirus Exclusion Güvenlik Riski Oluşturur mu?

Gereğinden geniş exclusion attack surface oluşturabilir.

Sadece doğrulanmış teknik gereksinimler uygulanmalıdır.

Database Service Account OS Yetkileri

Database service account local administrator veya root olmamalıdır.

Sadece gerekli permission'lar verilmelidir.

Root ile PostgreSQL Çalıştırılmalı mı?

Database service dedicated düşük yetkili OS account ile çalışmalıdır.

MSSQL Service Account Domain Admin Olmalı mı?

Hayır.

Oracle OS Account Ayrı Olmalı mı?

Evet.

Oracle service/process'leri dedicated OS identity ile yönetilmelidir.

Database File Permission Neden Kritik?

OS seviyesinde database file'a erişim DBMS security layer'ını bypass edebilir.

Backup File Permission Neden Kritik?

Backup file database'in tam kopyasını içerebilir.

Database Dump Security

PostgreSQL dump,

MSSQL backup,

Oracle export

dosyalarının tümü hassas kabul edilmelidir.

Export Encryption Kullanılmalı mı?

Hassas veriler dışarı aktarılıyorsa encryption ve controlled access uygulanmalıdır.

Test Ortamlarında Vendor Fark Etmeksizin En Büyük Risk Nedir?

Production data'nın kontrolsüz kopyalanmasıdır.

PostgreSQL Production Data Test'e Kopyalanabilir mi?

İş ihtiyacı varsa masking uygulanmalıdır.

MSSQL Backup Test Ortamına Restore Edilebilir mi?

Yalnızca controlled ve authorized şekilde.

Oracle Data Pump Export Test İçin Kullanılabilir mi?

Hassas veriler masking veya anonymization süreçlerinden geçirilmelidir.

Database Masking Üç Platformda da Önemli mi?

Evet.

Özellikle dev/test ortamlarında.

Configuration Baseline Nasıl Yönetilmeli?

Her platform için ayrı baseline oluşturulabilir:

PostgreSQL Security Baseline

MSSQL Security Baseline

Oracle Security Baseline

Platform Baseline Neleri İçermeli?

Authentication

Administrator Accounts

Network

TLS

Encryption

Audit

Patch

Backup

OS Security

Configuration Drift Nasıl Tespit Edilir?

Periyodik configuration assessment veya automated compliance araçları kullanılabilir.

Upgrade Sonrası Hardening Bozulabilir mi?

Evet.

Major version upgrade veya migration sonrası bazı settings default hale dönebilir.

Migration Sonrası Security Validation Yapılmalı mı?

Kesinlikle.

Örneğin;

Oracle → PostgreSQL

veya

MSSQL → cloud managed database

migration sonrası eski permission modelinin aynen taşınması güvenli olmayabilir.

Database Migration Security Checklist

Migration sırasında:

User/Role Mapping

Encryption

Network Access

Audit

Backup

Secrets

Application Connection

kontrol edilmelidir.

Cloud Managed PostgreSQL Güvenliği

Cloud provider database engine'i yönetebilir.

Ancak customer;

IAM,

public access,

network rules,

user roles,

logs,

backup

konularından sorumludur.

Cloud Managed MSSQL Güvenliği

Managed SQL servislerinde işletim sistemi yönetimi provider'da olabilir.

Ancak access control ve database security hâlâ müşteri sorumluluğundadır.

Cloud Oracle Security

Oracle database cloud üzerinde çalışsa da IAM, network, encryption ve audit configuration doğru yapılmalıdır.

Shared Responsibility Database Security İçin Neden Kritik?

Managed database kullanmak:

“Security provider'ın sorumluluğunda.”

anlamına gelmez.

Container İçinde PostgreSQL Çalıştırmak Güvenli mi?

Doğru hardening ile kullanılabilir.

Ancak;

container image,

secret,

persistent volume,

network policy

güvenliği ayrıca önemlidir.

Kubernetes Database Security

Stateful workload çalıştırılıyorsa;

Secrets,

RBAC,

NetworkPolicy,

PersistentVolume encryption,

backup

değerlendirilmelidir.

Kubernetes Secret Database Password İçin Yeterli mi?

Default secret storage modelinin güvenlik özellikleri ayrıca değerlendirilmelidir.

Gerekirse external secret manager kullanılabilir.

Database Secrets Rotation

Platform ne olursa olsun application credential'ları kontrollü olarak rotate edilmelidir.

Credential Rotation Sonrası Uygulama Kesilebilir mi?

Yanlış planlanırsa evet.

Dual-secret veya staged rotation gibi yöntemler değerlendirilebilir.

Database Connection Pool Security

Application connection pool database credential'ını uzun süre memory'de tutabilir.

Bu nedenle application host security önemlidir.

PostgreSQL Connection Pooler Güvenliği

Pooler ayrı authentication ve network attack surface oluşturabilir.

Bu nedenle ayrıca hardening gerekir.

MSSQL Connection Pooling Güvenliği

Application identity ve connection string security önemlidir.

Oracle Connection Pool Güvenliği

Application server üzerindeki credential ve pool configuration korunmalıdır.

Database Güvenliğinde En Zayıf Halka Nedir?

Tek bir cevap yoktur.

Kurumdan kuruma;

credential,

patch,

public exposure,

application account,

backup

olabilir.

Vendor Güvenliği Değil Mimari Güvenlik

PostgreSQL kullanmak otomatik olarak daha güvenli değildir.

MSSQL kullanmak otomatik olarak daha güvenli değildir.

Oracle kullanmak da otomatik güvenlik garantisi değildir.

Asıl konu configuration ve operasyon kalitesidir.

“Hangi Database Daha Güvenli?” Sorusu Doğru mu?

Tek başına değil.

Daha doğru soru:

“Hangi platform bizim security architecture, operational capability ve business requirement'larımızla daha güvenli işletilebilir?”

olmalıdır.

Platform Seçiminde Security Kriterleri

Örneğin:

Authentication Integration

Encryption Capability

Audit Features

Patching Model

High Availability

Backup/Recovery

Vendor Support

Operational Expertise

değerlendirilebilir.

PostgreSQL Güvenlik Avantajları

Açık kaynak yapısı ve güçlü role/network configuration seçenekleri önemli avantajlar sağlayabilir.

Ancak yönetim disiplinine ihtiyaç vardır.

MSSQL Güvenlik Avantajları

Active Directory entegrasyonu ve Microsoft ekosistemiyle merkezi identity management güçlü avantaj sağlayabilir.

Oracle Güvenlik Avantajları

Kurumsal güvenlik, encryption, audit ve privileged access alanında gelişmiş özellikler sağlayabilir.

Her Platformda İnsan Hatası Riskli mi?

Evet.

Yanlış GRANT komutu veya yanlış firewall kuralı tüm platformlarda risk oluşturabilir.

Database Security Automation Neden Önemlidir?

Yüzlerce database'in manuel kontrolü sürdürülebilir değildir.

Automated Compliance Neleri Kontrol Edebilir?

Örneğin:

Public Exposure

Unsupported Version

Audit Disabled

Encryption Disabled

Excessive Privileges

Database Security Posture Management Nedir?

Database sistemlerinin security configuration, exposure ve risklerini merkezi olarak görünür hale getirmeye yönelik yaklaşımdır.

Security Posture Dashboard Neler Gösterebilir?

Database Count

Critical Findings

Unsupported Versions

Privileged Users

Encryption Coverage

Audit Coverage

PostgreSQL, MSSQL ve Oracle İçin Ortak Güvenlik Checklist

• Supported version kullanılıyor mu?
• Security patch'ler güncel mi?
• Public access kapalı mı?
• Network segmentation var mı?
• Privileged hesaplar minimum mu?
• Shared administrator account var mı?
• Application hesapları minimum yetkili mi?
• TLS aktif mi?
• At-rest encryption var mı?
• Backup encryption var mı?
• Audit aktif mi?
• SIEM entegrasyonu var mı?
• Sensitive data access izleniyor mu?
• Backup/restore test ediliyor mu?
• OS hardening uygulanmış mı?
• Configuration drift izleniyor mu?

PostgreSQL Security Checklist

• pg_hba.conf kontrollü mü?
• listen_addresses sınırlandırılmış mı?
• Superuser sayısı minimum mu?
• Role inheritance kontrol edildi mi?
• Public schema privilege'ları gözden geçirildi mi?
• Gereksiz extension'lar kaldırıldı mı?
• TLS aktif mi?
• Logging/Audit uygun mu?
• Data directory permission güvenli mi?
• Backup encrypted mı?

MSSQL Security Checklist

• sa kullanımı sınırlandırıldı mı?
• sysadmin sayısı minimum mu?
• Windows/SQL authentication ihtiyacı değerlendirildi mi?
• Service account minimum yetkili mi?
• Gereksiz SQL Server feature'ları kapalı mı?
• xp_cmdshell gereksizse kapalı mı?
• TLS aktif mi?
• TDE ihtiyaca göre aktif mi?
• SQL Server Audit var mı?
• Linked Server'lar kontrol edildi mi?

Oracle Security Checklist

• SYS/SYSTEM kullanımı sınırlandırıldı mı?
• SYSDBA kullanıcıları minimum mu?
• Listener network olarak sınırlandırıldı mı?
• Default/sample account'lar kontrol edildi mi?
• Profile/password policy uygulanıyor mu?
• PUBLIC privilege'lar review edildi mi?
• Unified Auditing etkin mi?
• TDE/key management güvenli mi?
• Keystore recovery planı var mı?
• Patch seviyeleri güncel mi?

Database Güvenliğinde Yönetimin Sorması Gereken Sorular

Yönetim şu soruların cevabını bilmelidir:

Kaç PostgreSQL database'imiz var?

Kaç MSSQL instance var?

Kaç Oracle database var?

Hangileri kritik?

Hangileri destek dışı sürüm kullanıyor?

Kaç privileged account var?

Kaçı public erişilebilir?

Kaçında encryption aktif?

Kaçında audit aktif?

Hangileri SIEM tarafından izleniyor?

Bu sorular multi-database environment security maturity seviyesini ortaya çıkarır.

Sık Sorulan Sorular

PostgreSQL güvenli mi?

Doğru yapılandırıldığında güçlü güvenlik kontrolleri sunar. Ancak default kurulum tek başına production security anlamına gelmez.

MSSQL'de sa hesabı kapatılmalı mı?

Kullanılmıyorsa devre dışı bırakılması değerlendirilebilir. Aktifse çok sıkı korunmalı ve izlenmelidir.

Oracle SYS hesabı günlük kullanılmalı mı?

Hayır. Yalnızca gerçekten gerekli yüksek yetkili yönetim işlemlerinde kullanılmalıdır.

PostgreSQL pg_hba.conf nedir?

Database'e hangi kullanıcıların, hangi network'ten ve hangi authentication yöntemiyle bağlanabileceğini kontrol eden kritik configuration dosyasıdır.

MSSQL xp_cmdshell neden risklidir?

Database ile operating system arasında güçlü etkileşim sağlayabilir. İhtiyaç yoksa attack surface azaltmak için kapalı tutulması uygundur.

Oracle Listener neden önemlidir?

Client database connection'larının temel network bileşenidir ve erişimi sınırlandırılmalıdır.

PostgreSQL, MSSQL ve Oracle'dan hangisi daha güvenli?

Tek başına platform adıyla karar verilemez. Güvenlik configuration, architecture, patching ve operasyon kalitesine bağlıdır.

Üç platformda da TLS kullanılmalı mı?

Hassas database bağlantılarında encryption in transit önemli bir güvenlik kontrolüdür.

Üç platformda da audit gerekli mi?

Kritik production database'lerde privileged ve hassas aktivitelerin audit edilmesi önemlidir.

Database platformu cloud'daysa hardening gerekmez mi?

Hayır. Managed hizmetlerde bile identity, network, logging, encryption ve backup configuration müşteri açısından önemlidir.

Sonuç: Güvenli Database Platform Değil, Güvenli İşletilen Database'dir

PostgreSQL, Microsoft SQL Server ve Oracle Database teknik olarak birbirinden oldukça farklı platformlardır.

Ancak siber güvenlik açısından temel prensipler değişmez.

PostgreSQL'de:

pg_hba.conf

kritik olabilir.

MSSQL'de:

sa ve sysadmin

kritik olabilir.

Oracle'da:

SYS, SYSDBA ve Listener

kritik olabilir.

Ancak tüm platformların ortak ihtiyacı aynıdır:

Minimum Privilege

Minimum Network Exposure

Strong Authentication

Encrypted Communication

Secure Configuration

Audit

Patch Management

Backup Security

Continuous Monitoring

Bu nedenle database security yaklaşımı ürün bazlı değil, katmanlı şekilde tasarlanmalıdır.

İlk olarak kurum genelinde ortak bir:

Database Security Baseline

oluşturulmalıdır.

Ardından bu baseline;

PostgreSQL,

MSSQL,

Oracle

için platforma özel hardening maddeleriyle genişletilmelidir.

En önemli prensip şudur:

Default configuration hiçbir platformda otomatik olarak kurumunuz için ideal security configuration anlamına gelmez.

Kuruluş;

hangi kullanıcıların yetkili olduğunu,

hangi network'lerin erişebildiğini,

hangi data'nın encrypted olduğunu,

hangi aktivitelerin audit edildiğini,

hangi sürümlerin desteklendiğini

sürekli bilmelidir.

Bu nedenle doğru soru:

“PostgreSQL mi daha güvenli, MSSQL mi, Oracle mı?”

değildir.

Doğru soru:

“Kullandığımız database platformunu ne kadar güvenli yapılandırıyor, ne kadar iyi izliyor ve ne kadar disiplinli işletiyoruz?”

olmalıdır.

Gerçek database güvenliği ürün isminden değil;

Secure Architecture + Secure Configuration + Secure Operations

birleşiminden oluşur.