PostgreSQL Güvenlik Rehberi: Kimlik Doğrulama, Yetkilendirme, RLS, Şifreleme ve Audit

PostgreSQL güvenliği beş katmanda ele alınır: kimlik doğrulama (kim bağlanabilir), yetkilendirme (kim neyi görebilir ve değiştirebilir), satır ve kolon düzeyinde erişim kontrolü, şifreleme (ağda ve diskte) ve denetim kayıtları (kim ne yaptı). PostgreSQL bu katmanların çoğu için güçlü yerleşik özellikler sunar; ancak varsayılan ayarlar her ortam için yeterli değildir ve bazı ihtiyaçlar (örneğin ayrıntılı denetim kaydı) eklenti gerektirir.

Bu rehber, PostgreSQL’i production’da (üretim ortamında) işleten ekipler ve KVKK, BDDK veya ISO 27001 denetimlerine hazırlanan kurumlar için hazırlandı. Örnekleri PostgreSQL 18 üzerinde test ettik.

Kısaca: PostgreSQL Güvenlik Katmanları

1. Kimlik Doğrulama

PostgreSQL’e kimin, nereden ve nasıl bağlanabileceğini pg_hba.conf dosyası belirler. Kurallar yukarıdan aşağıya okunur ve eşleşen ilk kural uygulanır.

Kurulum aşamasındaki kimlik doğrulama ve uzak erişim ayarlarını PostgreSQL kurulum rehberimizde adım adım anlattık.

2. Roller ve En Az Yetki

PostgreSQL’de kullanıcılar ve gruplar aynı kavramdır: roller. İyi bir yetki modeli, kişilere doğrudan yetki vermek yerine görev rolleri tanımlar ve kişileri bu rollere üye yapar.

CREATE ROLE app_owner NOLOGIN;
CREATE ROLE app_rw NOLOGIN;
CREATE ROLE app_ro NOLOGIN;
CREATE SCHEMA sales AUTHORIZATION app_owner;
GRANT USAGE ON SCHEMA sales TO app_rw, app_ro;
-- Privileges for tables app_owner creates from now on
ALTER DEFAULT PRIVILEGES FOR ROLE app_owner IN SCHEMA sales
  GRANT SELECT, INSERT, UPDATE, DELETE ON TABLES TO app_rw;
ALTER DEFAULT PRIVILEGES FOR ROLE app_owner IN SCHEMA sales
  GRANT SELECT ON TABLES TO app_ro;
-- Login roles are members of the job roles
CREATE ROLE web_app LOGIN PASSWORD 'change_me' IN ROLE app_rw;
CREATE ROLE report_user LOGIN PASSWORD 'change_me' IN ROLE app_ro;

PostgreSQL 15 ve sonrasında yeni veritabanlarında PUBLIC rolü public şemasında nesne oluşturamaz. Daha eski sürümlerden yükseltilmiş veritabanlarında bu yetki hâlâ açık olabilir; kontrol edip kapatın.

Yüksek yetkili rolleri düzenli olarak gözden geçirin:

SELECT rolname, rolsuper, rolcreaterole, rolcreatedb, rolreplication, rolbypassrls
FROM pg_roles
WHERE rolsuper OR rolcreaterole OR rolreplication OR rolbypassrls
ORDER BY rolname;

3. Row-Level Security: Satır Düzeyinde Erişim

Row-Level Security (RLS), aynı tablodaki satırların kullanıcıya göre filtrelenmesini sağlar. Örneğin her şube yalnızca kendi müşterilerini görmelidir. Filtre uygulama kodunda değil, veritabanında uygulandığı için uygulamadaki bir hata veriyi açığa çıkarmaz.

CREATE TABLE customers (id int PRIMARY KEY, branch text NOT NULL, name text NOT NULL);
INSERT INTO customers VALUES (1, 'istanbul', 'Acme'), (2, 'ankara', 'Beta'), (3, 'istanbul', 'Gama');

ALTER TABLE customers ENABLE ROW LEVEL SECURITY;
CREATE POLICY branch_isolation ON customers
  USING (branch = current_setting('app.branch', true));

CREATE ROLE branch_user LOGIN PASSWORD 'change_me';
GRANT SELECT ON customers TO branch_user;

-- As branch_user:
SET app.branch = 'istanbul';
SELECT id, name FROM customers;
--  id | name
--   1 | Acme
--   3 | Gama

RLS’i devreye alırken üç noktaya dikkat edin:

• Tablo sahibi ve süper kullanıcılar politikalardan muaftır. Sahibin de politikaya tabi olması için ALTER TABLE ... FORCE ROW LEVEL SECURITY kullanın.
• BYPASSRLS yetkisine sahip roller politikaları atlar; bu yetkiyi kimin taşıdığını düzenli kontrol edin.
• Performans: Politika koşulu her sorguya eklenir; koşulda kullanılan kolonları indeksleyin.

4. Kolon Düzeyinde Erişim ve Maskeleme

Bir tablonun yalnızca bazı kolonlarına erişim vermek için kolon yetkileri kullanılabilir:

CREATE TABLE employees (id int, full_name text, tckn text, salary numeric);
REVOKE ALL ON employees FROM PUBLIC;
GRANT SELECT (id, full_name) ON employees TO app_ro;

Bu durumda app_ro rolü T.C. kimlik numarası ve maaş kolonlarını okuyamaz; SELECT * sorgusu yetki hatası verir. Verinin tamamen gizlenmesi yerine kısmen gösterilmesi gerekiyorsa (örneğin kimlik numarasının yalnızca son dört hanesi) maskeleme kullanılır. Test ortamları için veri maskeleme yöntemlerini PostgreSQL veri maskeleme rehberimizde anlattık.

5. Şifreleme

6. Denetim Kayıtları

PostgreSQL’in sunucu logları bağlantıları, oturum kapanışlarını ve DDL komutlarını kaydedebilir. Temel ayarlar:

ALTER SYSTEM SET log_connections = 'on';
ALTER SYSTEM SET log_disconnections = 'on';
ALTER SYSTEM SET log_statement = 'ddl';
ALTER SYSTEM SET log_line_prefix = '%m [%p] %q%u@%d from %h ';
SELECT pg_reload_conf();

Denetim gereksinimleri bunun ötesine geçtiğinde, örneğin hassas tablolara kimin hangi sorguyla eriştiğinin kaydedilmesi gerektiğinde, açık kaynak pgAudit eklentisi kullanılır. pgAudit, oturum düzeyinde (tüm okuma ve yazma işlemleri gibi sınıflar) veya nesne düzeyinde (yalnızca belirli tablolara erişim) ayrıntılı ve denetçilerin beklediği formatta kayıt üretir.

KVKK ve Denetimler İçin Kontrol Listesi

Aryasoft ile PostgreSQL Güvenliği

Aryasoft’un kıdemli PostgreSQL uzmanları ortamınızın yetki matrisini çıkarır, kimlik doğrulama ve şifreleme ayarlarını inceler, denetim kayıtlarını kurumunuzun gereksinimlerine göre yapılandırır ve bulguları öncelik sırasıyla raporlar. Finans ve enerji gibi düzenlemeye tabi sektörlerde edindiğimiz deneyimle, denetimlerde istenen kanıtları ilk günden hazır tutmanıza yardımcı oluruz. Ayrıntılar PostgreSQL hizmetleri sayfamızda. Genel production kuralları için PostgreSQL Best Practices yazımıza göz atabilirsiniz.

Sıkça Sorulan Sorular

Kaynaklar

Bu rehberdeki teknik bilgiler Kasım 2026’da aşağıdaki resmi dokümantasyonla karşılaştırıldı.

1. PostgreSQL dokümantasyonu: The pg_hba.conf File
2. PostgreSQL dokümantasyonu: Database Roles
3. PostgreSQL dokümantasyonu: Predefined Roles
4. PostgreSQL dokümantasyonu: Row Security Policies
5. PostgreSQL dokümantasyonu: CREATE FUNCTION (Writing SECURITY DEFINER Functions Safely)
6. PostgreSQL dokümantasyonu: Secure TCP/IP Connections with SSL
7. PostgreSQL dokümantasyonu: pgcrypto
8. PostgreSQL dokümantasyonu: Error Reporting and Logging
9. pgAudit