1. Özet
Bu teknik inceleme raporu, PostgreSQL veritabanını güvenliğini sağlamak ve korumak için bir çerçeve ve bir dizi öneri sunmaktadır. Fiziksel güvenliği, ağ güvenliğini, sunucu erişim kontrolünü, veritabanı erişim yönetimini ve veri güvenliğini ele alan katmanlı bir güvenlik modelinden söz etmekteyiz. Her ne kadar tüm bu özellikler eşit derecede önemli olsa da bu raporda, PostgreSQL’e özel olan veritabanı ve veri güvenliği özelliklerine odaklanılmıştır. Veritabanıyla ilgili belirli güvenlik konuları ve veritabanında yönetilen veriler hakkında yaptığımız tartışmada, bilgisayar ve ağ güvenliği için yaygın bir AAA (Kimlik Doğrulama, Yetkilendirme ve Denetleme) yaklaşımı kullanmaktayız.

Bu teknik inceleme raporundaki önerilerin çoğu PostgreSQL (topluluk sürümü) ve PostgreSQL’in kurumsal sınıf, özellik açısından zengin ticari dağıtımı olan EnterpriseDB ® ‘nin (EDBTM) EDB PostgresTM Advanced Server için geçerlidir. PostgreSQL’de aynı şekilde bulunmayan Parola Profilleri, Denetleme, Veri Azaltma ve SQL Server Enjeksiyon Koruması gibi ek güvenlik geliştirmelerini Advanced Server sağlar.

Bu belge PostgreSQL 12 ve EDB Postgres Advanced Server 12 için güncellenmiştir.

2. Giriş
Güvenliği katmanlar olarak düşünebiliriz ve ilk fırsatta gereksiz erişimi engelleyerek herhangi bir iş veya rol için gerekli olan en az erişimi verme stratejisini önerebiliriz.
1- Birincisi, sunucuya fiziksel erişimi güvenceye almaktır
2- Bir sonraki adım kurumsal ağınıza genel olarak erişimi sınırlandırmaktır
3- Bir sonraki adım veritabanı sunucusuna erişimi sınırlandırmaktır
4- Bir sonraki adım veritabanı uygulamasına erişimi sınırlandırmaktır
5- Bir sonraki adım içinde bulunan verilere erişimi sınırlandırmaktır
6- Bir sonraki adım içinde depolanan verilerin güvenliğini sağlamaktır

Güvenliği katmanlar olarak düşünebiliriz ve en az gerekli erişimi sağlama stratejisi önerebiliriz.

Genel Öneriler

• İşletim sisteminizi ve veritabanınızı güncel tutun. EDB’nin destek abonelikleri, Postgres için uygun güvenlik güncellemeleri ve yamaların zamanında bildirimlerini sağlar. yum/dnf veya apt gibi paket yönetim sistemleriyle entegre edilebilen işletim sistemlerinin güncellemelerini izleyebilecek birçok araç bulunmaktadır.
• İşletmeniz için gerçekten çok önem taşımadığı sürece, internete açık postmaster port bırakmayın. Bu portu uygun şekilde güvenlik duvarı ile koruyun; eğer bu mümkün değilse, bu portta okuma-yazma veritabanı yerine yalnız okuma (read-only) standby veritabanı kullanın. Tüm bağlantıları denetlenen ağ port yönlendirmesi geçerli bir diğer seçenek olacaktır.
• Alt ağ (subnet) oluşturma veya diğer tekniklerle veritabanı portunu diğer ağ trafiğinden izole edin.
• Kullanıcılara işlerini yapmak için gerekli en az erişim yetkisini verin, daha fazlası değil; yetkili kullanıcı hesaplarının kullanımını kesinlikle gerekli olduğunda görevler veya roller için saklayın.
• Sistem yöneticilerinin yapılandırma dosyalarına (postgresql.conf ve PG_hba.conf) ve günlük dosyalarına (PG_log) erişimini kısıtlayın.
• Veritabanı süper kullanıcı rolleri (PostgreSQL’de postgres, EDB Postgres Advanced Server’da enterprisedb) tarafından sunucu oturumuna izin vermeyin. Olağanüstü durumlarda yalnızca gerektiğinde yetkili kullanıcı erişimini etkinleştirin.
• Tüm kullanıcılara kendi giriş bilgilerini verin; paylaşılan erişim bilgileri önerilen bir uygulama değildir ve denetlemeyi daha karmaşık hale getirir. Seçenek olarak, uygulamaların uygulama düzeyindeki bağlantılardan kaynaklanan oturumlara daha fazla denetleme bilgisi eklemesine izin vermek için edb_audit_tag özelliğini (yalnızca EDB Postgres Advanced Server’da mevcuttur) kullanın.
• Veritabanınıza yetkisiz erişimi önlemek için yalnızca ön yüzdeki uygulamanıza güvenmeyin; veritabanı güvenliğini, LDAP/ad veya Kerberos gibi kurumsal düzeyde kimlik doğrulama ve yetkilendirme modelleriyle entegre edin.
  Yedeklemeleri saklayın ve test edilmiş bir kurtarma planına sahip olun. Sisteminizi ne kadar iyi güvenceye alırsanız alın, izinsiz giriş yapan bir kişi verilerinizi silebilir veya değiştirebilir. Yetkisiz erişimi önlemek için yedeklelerinizin de güvenli şekilde saklandığından emin olun.

Güvenliği, ağ ve bilgisayar güvenliği için geliştirilen AAA modeli açısından düşünmek yararlı olabilir. AAA, Authentication (Kimlik Doğrulama), Authorization (Yetkilendirme) ve Auditing (Denetleme) anlamına gelir.

• Kimlik Doğrulama: Kullanıcının iddia ettiği kişi olduğunu doğrulayın.
• Yetkilendirme: Kullanıcının erişimine izin verildiğini doğrulayın.
• Denetleme (veya hesap verebilme): Kullanıcı adı ve zaman bilgisi dahil olmak üzere tüm veritabanı etkinliklerini günlük dosyalarına kaydedin.

Tüm özellikler bu kategorilere tam olarak uygun değildir, ancak AAA modeli bu teknik rapor için kullanışlı bir çerçeve sunmaktadır.

3. Kimlik Doğrulama, Yetkilendirme ve Denetim Çerçevesine PostgreSQL Güvenlik Özelliklerinin Uygulanması

Aşağıdaki bölümlerde, Kimlik Doğrulama, Yetkilendirme ve Denetim (AAA) Çerçevesine PostgreSQL güvenlik özelliklerinin nasıl ekleneceği hakkında ayrıntılı bilgiler verilmektedir.

3.1. Kimlik Doğrulama

— PG_hba.conf (PostgreSQL sunucu tabanlı erişim) dosyası, erişimi kullanıcı adı, veritabanı ve kaynak IP adresine göre (eğer kullanıcı TCP/IP üzerinden bağlanıyorsa) kısıtlar. Kimlik doğrulama yöntemleri de bu dosyada atanır. Seçtiğiniz kimlik doğrulama yöntemi (veya yöntemleri) kullanım senaryonuza bağlıdır.

— Kerberos/GSSAPI — PostgreSQL, RFC 1964’e göre Kerberos kimlik doğrulamayı içeren GSSAPI’yi destekler. GSSAPI, destekleyen sistemler için otomatik kimlik doğrulamayı (tek oturumda açma) sağlar. Kimlik doğrulamanın kendisi güvenlidir, ancak GSS veya SSL şifreleme kullanılmadığı sürece veritabanı bağlantısı üzerinden gönderilen veriler şifrelenmez.

— SSPI — Windows sistemini kullanıyorsanız ve Tek Oturumda Açma (Single Sign-On, SSO) kimlik doğrulaması uygulamak istiyorsanız bu özelliği kullanın.

— LDAP yalnızca -hem SSPI hem de GSSAPI içeren- Kerberos söz konusu değilse kullanılmalıdır. LDAP daha az güvenlidir, çünkü parolalar LDAP sunucusuna iletilir ve güvenli olmayan şekilde kolayca ayarlanabilir.

— LDAP ve RADIUS — LDAP ve RADIUS, çok sayıda kullanıcınız ve parolaları merkezi bir konumdan yönetmeniz gereken durumlar olduğunda yararlıdır. Bu merkezileştirmenin avantajı pg_hba.conf dosyanızı küçük ve yönetilebilir tutmaktır ve merkezileştirmeyle kullanıcılarınıza altyapınızda “birleştirilmiş parola deneyimi” sağlanabilir., Veritabanınıza erişirken bu hizmete ve bağlantıya güveneceğiniz için Hem LDAP hem de RADIUS için sağlam bir altyapı gerekmektedir.

— RADIUS — şifrelemesi zayuf olduğundan ve kimlik bilgileri için md5 hashinge sahip olduğundan kullanılmamalıdır.

— Cert — TLS sertifikası kimlik doğrulaması (bazen SSL olarak da adlandırılır), kablo üzerindeki trafiği şifrelemek ve kimlik doğrulama için kullanılabilir. Sertifikalar genellikle makineden makineye iletişimde kullanılır.

— md5 — md5 kullanıcı adı ve parola bilgilerini veritabanında saklar; çok az sayıda kullanıcınız varsa uygun bir alternatif olabilir. Parolalar güvenli şekilde karma olduğundan md5’e göre SCRAM tercih edilir.

— Scarm — çok az sayıda güvenilir kullanıcınız varsa, scram-sha-256 kimlik doğrulamasını kullanabilirsiniz. Parolalar güvenli şekilde karma olduğundan md5’e göre SCRAM tercih edilir.

— Reject (Reddet) — belirli kullanıcıları, belirli veritabanlarına bağlantıları ve/veya belirli kaynak IP adreslerini reddetmek için bu yöntemi kullanın.

— Trust (Güven) — güvenilir kimlik doğrulama, eşleşen bir istemcinin başka bir kimlik doğrulaması olmadan sunucuya bağlanmasını sağladığı için, yalnızca istisnai durumlarda kullanılmalıdır.

Bütün kimlik doğrulama yöntemlerinin sonuçlarını tam olarak bilmeniz gereklidir. Yukarıda verilenler ve diğer kimlik doğrulama yöntemleri hakkında daha ayrıntılı araştırma için PostgreSQL belgelerini inceleyebilirsiniz.

Tanıtım bölümünde belirtildiği gibi, pg_hba.conf dosyası erişimi sistem yöneticileri için sınırlı olmalıdır. Bu dosyayı düzgün şekilde kısıtlı tutmaya çalışın; daha büyük, daha karmaşık dosyaların bakımı daha zordur ve yanlış ya da eski kayıtları içerme olasılığı daha yüksektir. Gereksiz kayıtlar için bu dosyayı düzenli olarak inceleyin.

3.2. Parola Profilleri

Advanced Server, 9.5 sürümünden başlayarak MD5 veya SCRAM kimlik doğrulaması kullanılarak Oracle uyumlu parola profillerini desteklemektedir. Parola profili, DBA’nın benzer kimlik doğrulama gereksinimlerini paylaşan bir grup rolü kolayca yönetmesine olanak tanıyan bir parola özellikleri kümesidir. Her profil bir veya daha fazla kullanıcıyla ilişkilendirilebilir. Bir kullanıcı sunucuya bağlandığında, sunucu oturum açma rolüyle ilişkili profili uygular.

Daha fazla bilgi için EDB’s Database Compatibility for Oracle® Developer’s Guide belgesinin 2.3 “Profile Management” Bölümüne bakabilirsiniz..

Profiller aşağıdaki işlemler için kullanılabilir:
• İzin verilen başarısız oturum açma girişimi sayısının belirtilmesi.
• Aşırı başarısız oturum açma girişimleri nedeniyle hesabın kilitlenmesi.
• Sona ermesi için bir parolanın işaretlenmesi.
• Parola sona erdikten sonra ek sürenin tanımlanması.
• Parola karmaşıklığı için kuralların tanımlanması.
• Parolanın yeniden kullanımını sınırlayan kuralların tanımlanması.

3.3. Yetkilendirme

Kullanıcı uygun şekilde kimlik doğruladıktan sonra, verileri görüntülemesi ve veritabanında çalışması için izin vermeniz gerekir. Daha önce de belirtildiği gibi, yalnızca kullanıcının ilgili işi gerçekleştirmesi için gereken ayrıcalıkları verin ve paylaşılan (grup) oturum açma kimlik bilgilerine izin vermeyin. PostgreSQL’deki kullanıcıları ve grupları, rol atamaları aracılığıyla yönetin. Bir rol, bireysel bir kullanıcıyı veya bir grup kullanıcıyı ifade edebilir. Postgres’te roller, küme (veya veritabanı sunucusu) düzeyinde oluşturulur. Bu durum, rollerin küme/veritabanı sunucusu için tanımlanan tüm veritabanlarına uygulandığı anlamına gelir ve rol izinlerinin uygun şekilde sınırlandırılması çok önemlidir. İzinler veritabanı nesnelerine (tablolar, görüntüler, işlevler vb.), tabloların içindeki satırlara ve veri azaltma politikalarına uygulanabilir.

3.3.1 – Veritabanı nesnelerine erişim

Atanan ayrıcalıklar ve uyarılar, PostgreSQL CREATE ROLE belgelerinde özetlenir:

• • • Tüm kullanıcıların CREATE ayrıcalıklarını iptal edin ve yalnızca güvenilir kullanıcılara geri verin.
    • Güvenilmeyen prosedür dillerinde yazılmış fonksiyonların veya tetikleyicilerin kullanımına izin vermeyin.
    • SECURITY DEFINER işlevleri, kullanıcıların işlevleri kontrollü olarak yüksek ayrıcalık düzeyinde çalıştırmasını sağlar ancak kazara dikkatsizce yazılmış bir işlev, güvenliği azaltabilir. Daha fazla ayrıntı için belgeleri inceleyin (Writing Security Definer Functions Safely of CREATE FUNCTION bölümü).
    • Veritabanı nesnelerine, herhangi bir uygulama kullanıcısının bağlanabileceği bir rol tarafından değil, ideal olarak veritabanına çok kısıtlı erişimi olan (örn. Yalnızca Unix Etki Alanı soketinden) güvenli bir rol tarafından sahip olunmalıdır. Böylece saldırganın nesneleri değiştirme veya aktarma şansını en aza indirilir. Bu, güvenlik açısından tercih edilse de, şemayı kendisi yöneten uygulama çerçeveleri ile sorun yaratabilir; bu tür işlevler dikkatli şekilde uygulanmalıdır.

Log_Statement ‘ddl’ veya daha yüksek bir değere ayarlandığında, rolün parolasını ALTER ROLE komutu aracılığıyla değiştirmenin EDB Postgres Advanced Server 11 ve sonraki sürümleri dışında günlüklerde parolanın ifşası ile sonuçlanacağına dikkat edin, burada, edb_filter_log.redakct_password_command, sunucuya günlük dosyasından tutulan parolaları daraltma talimatını verir. Daha fazla bilgi için tıklayın.

Kimlik doğrulama bilgileri (örn. Kullanıcı adları ve parolalar) bir tabloda tutulduğunda, tablo özel olarak güvenli olsa bile komut kayıtlarının (statement logging) kullanımı bu bilgileri açığa çıkarabilir. Benzer şekilde, sorgularda hassas bilgiler kullanılırsa (örneğin, bir anahtar olarak kişisel tanımlayıcı herhangi bir bilgi), bu parametreler komut kayıtları ile ortaya çıkarılabilir.

3.3.2 – Görünümler

Veritabanı nesneleri olan görünümlere erişim yukarıda açıkladığı biçimde kontrol edilebilir. Bir tabloya VIEW yaratıp ve bu VIEW için yetkilerini kısıtlayarak verilerin görünürlüğünü belirli kullanıcı gruplarıyla sınırlandırmak görünümlerin kullanımıyla mümkün olabilir. Robert Haas’ın tanımladığı gibi olası güvenlik sorunlarından kaçınmak için ekstra önlem alınması gerektiği düşünüldüğünden, PostgreSQL 9.2 ve sonraki sürümleri, CREATE VIEW WITH (security_barrier) seçeneğini sunmaktadır.

3.3.3 – Satır Düzeyinde Güvenlik

PostgreSQL, 9.5 sürümünde Satır Düzeyinde Güvenliği (RLS) tanıtmıştır. RLS, kullanıcı rolüne bağlı olarak tablo satırlarına çok hassas erişim sağlar. Buna SELECT, UPDATE, DELETE ve INSERT işlemleri dahildir. Daha fazla bilgiyi burada bulabilirsiniz.

EDB Postgres Advanced Server, DBMS_RLS paketinde bu mekanizmanın Oracle’a uyumlu ADD_POLICY, DROP_POLICY ve UPDATE_POLICY uygulamalarını içerir. Daha fazla bilgi için tıklayın.

3.3.4 – Veri Azaltımı

Veri azaltımı – bazı veri öğelerini gizleme veya belirli kullanıcı grupları için verileri seçici olarak gizleme özelliği, verilere erişimi yönetmek için kullanılan başka bir tekniktir. EDB Postgres Advanced Server, 11 sürümünde veri azaltım özelliğini sunmuştur.

Veri azaltımı, belirli veri öğelerine okuma erişimini vermek veya iptal etmek için PostgreSQL rolleriyle birlikte çalışan politika bazlı bir araçtır. Örneğin, bir grup kullanıcı sosyal güvenlik numaralarını XXX-XX-1235 olarak görürken, veri yöneticisi rolüne sahip üyeler tüm ayrıntıları görür. Veri azaltımı hakkında ek bilgiler burada bulunmaktadır.

3.4 Denetleme

Advanced Server denetim raporları oluşturma olanağını sağlar. Veritabanı denetimi, veritabanı yöneticilerinin, denetçilerin ve operatörlerin karmaşık denetim gereksinimlerini desteklemek amacıyla veritabanı faaliyetlerini takip edip analiz etmelerine olanak tanır. Bu denetlenen faaliyetlerini veri oluşturma, değiştirme veya silme ile birlikte veritabanı erişimi ve kullanımı oluşturur. Denetime sistemi, yapılandırma dosyasında tanımlanan yapılandırma parametrelerine dayanır.

Denetleme düzeyini artırarak aşağıdakiler için denetim yapmanızı öneririz:
• Kullanıcı bağlantıları
• DDL değişiklikleri
• Veri değişiklikleri
• Veri görüntülemeleri

Çok ayrıntılı denetleme düzeyleri, çok sayıda günlük kaydına neden olabilir; yalnızca ihtiyacınız olan düzeyde günlük kayıtlarını toplayın. Postgres ile, günlük düzeylerini her bir kullanıcı ve her bir veritabanı için ayarlayabilirsiniz. Anormal hareketler için denetim günlüklerinizi sık sık gözden geçirin. Günlükleriniz için bir gözetim zincirini oluşturun.

Yüksek bir kayıt düzeyinin, veritabanındaki parolaların depolanmasıyla birlikte günlüklerde parolaların görüntülenmesine neden olabileceğini unutmayın. EDB Postgres Advanced Server, sunucuya denetim günlüğü dosyasından depolanan parolaları redaksiyon talimatını vermek amacıyla sürüm 11’de edb_filter_log.redakct_password_commands uzantısını kullanıma sunmuştur.

Advanced Server, veritabanı ve güvenlik yöneticilerinin, denetçilerin ve operatörlerin EDB Denetim Günlüğü işlevini kullanarak veritabanı etkinliklerini izleyip analiz etmelerine olanak tanır.

3.5 Veri Şifreleme

PostgreSQL, çeşitli düzeylerde şifreleme sunar ve veritabanı sunucusu hırsızlığı, etik olmayan yöneticiler ve güvensiz ağlar nedeniyle verilerin açıklanmasını önlemede esneklik sağlar:

• • Kullanıcı bağlantıları
  • DDL değişiklikleri
  • Veri değişiklikleri
  • Veri görüntüleri

Bu seçenekler hakkında daha fazla bilgi PostgreSQL belgelerinde bulunabilir.

Bir istemci ile veritabanı arasında aktarım sırasında verilerin ele geçirilmesinden endişe duyuyorsanız, veri ele geçirme işleminin risk oluşturmadığından emin olmadığınız sürece postgresql.conf dosyasında SSL’yi etkinleştirin. SSL şifrelemesi ek yük ekleyebilir ve sertifika yönetimi zor olabilir, ancak genel olarak bu önerilen bir uygulamadır.

Ayrıca veritabanı içinde veya dosya sistemi düzeyinde (biri veya diğeriyle) verileri şifreleyebilirsiniz. EDB’nin blogunda Şeffaf Veri Şifreleme (Transparent Data Encryption) hakkında daha fazla bilgi bulabilirsiniz. Bu şifreleme seçeneğiyle, veri, dosya sisteminden okunduğu anda şifre çözülür, böylece veritabanı yöneticileri verileri görüntüleyebilir; rollerin ve ayrıcalıkların kilitli olması zorunludur. Diğer seçenekler arasında Thales Vormetric Transparent Encryption (VTE) (Thales Vormetric Şeffaf Şifreleme) kullanımı bulunmaktadır.

Sütun başına veri şifrelemek için pgcrypto сontrib modülünü kullanın. Bu yöntemin birkaç sakıncası vardır:

• • Tablonun boyutuna bağlı olarak olası bir performans tıkanıklığı vardır.
  • Şifrelenmiş alanlarda arama yapılamaz veya dizine (indekse) alınamaz.
  • Şifreleme, tablo oluşturma sırasında uygulanmalıdır ve ayrıca ileri planlamayı gerektirir.
  • Şifreleme anahtarı yönetimi de karmaşık olabilir.

Buna ek olarak, uygulamanız şifreleme/şifre çözme işlemini gerçekleştirmesi gerekir, bu sayede veritabanındaki her değişimin etik olmayan bir veritabanı yöneticisinin verileri görüntülemesini önlemek için şifrelenmeyi sürdürmelidir.

3.6 SQL Enjeksiyon Saldırıları

SQL enjeksiyon saldırısı, bir veritabanının içeriği, yapısı veya güvenliği konusunda saldırgana ipuçları sağlayan SQL komutlarını çalıştırarak veritabanını tehlikeye atma girişimidir. SQL enjeksiyon saldırısını engellemek, normalde uygulama geliştiricisinin sorumluluğundadır. Veritabanı yöneticilerinin potansiyel tehdit üzerinde genellikle ya çok az ya da hiç kontrolü yoktur.

PostgreSQL SQL enjeksiyon saldırılarını önlemek için standart yöntem olarak parametre haline getirilmiş sorguları kullanır. EDB Postgres Advanced Server kullanıyorsanız SQL enjeksiyon saldırılarına karşı korunmak için SQL/Protect modülünü kullanmanızı öneririz. SQL/Protect, genel SQL profilleri için gelen sorguları inceleyerek normal veritabanı güvenlik politikalarına ek bir güvenlik katmanını sağlar. SQL/Protect, yöneticiyi potansiyel olarak tehlikeli sorgular konusunda uyararak ve bu sorguları engelleyerek kontrolü veritabanı yöneticisine geri verir. Daha fazla bilgi için tıklayın.

Kaynak: Security Best Practices for PostgreSQL
© Copyright EnterpriseDB Corporation 2020 EnterpriseDB Corporation
34 Crosby Drive Suite 201 Bedford, MA 01730
EnterpriseDB and Postgres Enterprise Manager are registered trademarks of EnterpriseDB Corporation. EDB and EDB Postgres are trademarks of EnterpriseDB Corporation. Oracle is a registered trademark of Oracle, Inc. Other trademarks may be trademarks of their respective owners.