# PostgreSQL, MSSQL ve Oracle Güvenliği: Kritik Yapılandırmalar ve Farklar **URL:** https://securesys.com.tr/tr/bilgi-merkezi/veritabani-guvenligi/postgresql-mssql-oracle-guvenligi ![PostgreSQL, MSSQL ve Oracle Güvenliği: Kritik Yapılandırmalar ve Farklar](/images/bilgi-merkezi/covers/cover-veritabani-09.webp) 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.