<![CDATA[TurkTeam | Türk Siber Güvenlik Topluluğu - Veritabanları (SQL/NoSQL)]]> https://www.turkteam.org/ Sun, 25 Oct 2026 18:48:36 +0000 MyBB <![CDATA[MongoDB Guvenligi: Kimlik Dogrulama, RBAC ve Ag Izolasyonu Rehberi]]> https://www.turkteam.org/konu-mongodb-guvenligi-kimlik-dogrulama-rbac-ve-ag-izolasyonu-rehberi.html Sat, 17 Oct 2026 11:26:20 +0300 BilgeKagan]]> https://www.turkteam.org/konu-mongodb-guvenligi-kimlik-dogrulama-rbac-ve-ag-izolasyonu-rehberi.html [Resim: attachment.php?aid=99]
Selamlar,

Yillardir haberlerde "acikta kalan MongoDB" sizintilari goruyoruz; cogunun tek sebebi internete kimlik dogrulamasiz acilmis bir veritabani. Bu konuda MongoDB'yi guvenli sekilde yapilandirmanin temel adimlarini derledim.

Konuda Anlatilacaklar
  1. En sik yapilan hata: acik bind
  2. Kimlik dogrulamayi etkinlestirme
  3. RBAC ile yetki ayrimi
  4. TLS ve ag izolasyonu
  5. Hizli kontrol listesi

1) Acik Bind Sorunu
Varsayilan kurulumlarin bir kismi tum arayuzlere dinlemeye acilabiliyor. Ilk is, erisimi sinirlamaktir. Yalnizca gerekli arayuzlere baglanin:

Kod:
# mongod.conf net: bindIp: 127.0.0.1,10.0.0.5 port: 27017

Veritabaninizi dogrudan internete acmayin; uygulama sunucusu ile ayni ozel agda tutun.

2) Kimlik Dogrulama
Authorization varsayilan olarak kapali gelebilir. Mutlaka acin ve once bir yonetici kullanicisi olusturun.

Kod:
// mongosh use admin db.createUser({ user: "admin", pwd: passwordPrompt(), roles: [ { role: "userAdminAnyDatabase", db: "admin" } ] })

Kod:
# mongod.conf security: authorization: enabled

Servisi yeniden baslattiktan sonra artik kimlik olmadan erisim reddedilir.

3) RBAC ile Yetki Ayrimi
Her uygulama tek bir sinirli kullaniciyla baglanmali. Uygulamaniza yalnizca kendi veritabaninda okuma/yazma verin:

Kod:
use appdb db.createUser({ user: "app", pwd: passwordPrompt(), roles: [ { role: "readWrite", db: "appdb" } ] })

Tek bir "root" kullanicisiyla her yere baglanmak en sik gorulen kotu aliskanliktir.

4) TLS ve Ag
Baglantilari sifrelemek icin TLS kullanin ve mumkunse guvenlik duvariyla yalnizca uygulama sunucusunun IP'sine izin verin.

Kod:
net: tls: mode: requireTLS certificateKeyFile: /etc/ssl/mongodb.pem

5) Hizli Kontrol Listesi
  • authorization: enabled acik mi?
  • bindIp sinirli mi, internete acik degil mi?
  • Her uygulama icin ayri, en az yetkili kullanici var mi?
  • TLS acik mi?
  • Yedekler sifreli ve erisimi kisitli mi?

Kaynaklar
Alıntı:Yasal not: Yapilandirmalari yalnizca kendi veritabani sunucularinizda uygulayin.


.png   bilgekagan-b05.png (Dosya Boyutu: 94.12 KB / İndirme Sayısı: 6) ]]> [Resim: attachment.php?aid=99]
Selamlar,

Yillardir haberlerde "acikta kalan MongoDB" sizintilari goruyoruz; cogunun tek sebebi internete kimlik dogrulamasiz acilmis bir veritabani. Bu konuda MongoDB'yi guvenli sekilde yapilandirmanin temel adimlarini derledim.

Konuda Anlatilacaklar
  1. En sik yapilan hata: acik bind
  2. Kimlik dogrulamayi etkinlestirme
  3. RBAC ile yetki ayrimi
  4. TLS ve ag izolasyonu
  5. Hizli kontrol listesi

1) Acik Bind Sorunu
Varsayilan kurulumlarin bir kismi tum arayuzlere dinlemeye acilabiliyor. Ilk is, erisimi sinirlamaktir. Yalnizca gerekli arayuzlere baglanin:

Kod:
# mongod.conf net: bindIp: 127.0.0.1,10.0.0.5 port: 27017

Veritabaninizi dogrudan internete acmayin; uygulama sunucusu ile ayni ozel agda tutun.

2) Kimlik Dogrulama
Authorization varsayilan olarak kapali gelebilir. Mutlaka acin ve once bir yonetici kullanicisi olusturun.

Kod:
// mongosh use admin db.createUser({ user: "admin", pwd: passwordPrompt(), roles: [ { role: "userAdminAnyDatabase", db: "admin" } ] })

Kod:
# mongod.conf security: authorization: enabled

Servisi yeniden baslattiktan sonra artik kimlik olmadan erisim reddedilir.

3) RBAC ile Yetki Ayrimi
Her uygulama tek bir sinirli kullaniciyla baglanmali. Uygulamaniza yalnizca kendi veritabaninda okuma/yazma verin:

Kod:
use appdb db.createUser({ user: "app", pwd: passwordPrompt(), roles: [ { role: "readWrite", db: "appdb" } ] })

Tek bir "root" kullanicisiyla her yere baglanmak en sik gorulen kotu aliskanliktir.

4) TLS ve Ag
Baglantilari sifrelemek icin TLS kullanin ve mumkunse guvenlik duvariyla yalnizca uygulama sunucusunun IP'sine izin verin.

Kod:
net: tls: mode: requireTLS certificateKeyFile: /etc/ssl/mongodb.pem

5) Hizli Kontrol Listesi
  • authorization: enabled acik mi?
  • bindIp sinirli mi, internete acik degil mi?
  • Her uygulama icin ayri, en az yetkili kullanici var mi?
  • TLS acik mi?
  • Yedekler sifreli ve erisimi kisitli mi?

Kaynaklar
Alıntı:Yasal not: Yapilandirmalari yalnizca kendi veritabani sunucularinizda uygulayin.


.png   bilgekagan-b05.png (Dosya Boyutu: 94.12 KB / İndirme Sayısı: 6) ]]> <![CDATA[PostgreSQL 18 Güvenlik Temelleri: Rol, pg_hba ve OAuth 2.0 Desteği]]> https://www.turkteam.org/konu-postgresql-18-guvenlik-temelleri-rol-pg-hba-ve-oauth-2-0-destegi.html Fri, 16 Oct 2026 11:23:10 +0300 BilgeKagan]]> https://www.turkteam.org/konu-postgresql-18-guvenlik-temelleri-rol-pg-hba-ve-oauth-2-0-destegi.html [Resim: attachment.php?aid=36]
Selamlar,

PostgreSQL 18 (25 Eylül 2025) ile birlikte OAuth 2.0 kimlik doğrulama desteği geldi; asenkron I/O ve bir sürü performans iyileştirmesiyle birlikte güvenlik tarafında da bakılacak maddeler arttı. Bu konuda "yeni kurduğum Postgres'i nasıl sıkılaştırırım?" diyenler için temel bir kontrol listesi bırakıyorum.

Konuda Anlatılacaklar
  1. PostgreSQL 18'den güvenlikle ilgili notlar
  2. Rol ve yetki: süperuser alışkanlığını kırmak
  3. pg_hba.conf: SCRAM, md5'in düşüşü
  4. OAuth 2.0 (özet)
  5. Lab'da hızlı sıkılaştırma listesi

1) PG 18 Güvenlik Notları
Resmi duyuruya göre:
  • oauth kimlik doğrulama yöntemi: SSO entegrasyonu için (uzantı destekli)
  • md5 parola doğrulama deprecated; parola kullanacaksanız SCRAM
  • ssl_tls13_ciphers ile TLS 1.3 cipher kontrolü
  • Yeni kümelerde sayfa checksum'ları varsayılan açık (pg_upgrade senaryolarına dikkat)

2) Rol Disiplini
Kod:
-- uygulama kullanıcısı: süperuser DEĞİL CREATE ROLE app_user LOGIN PASSWORD 'uzun-ve-rastgele'; CREATE DATABASE appdb OWNER app_user; \c appdb -- şema ve tablo yetkilerini bilinçli verin GRANT CONNECT ON DATABASE appdb TO app_user; GRANT USAGE ON SCHEMA app TO app_user; GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA app TO app_user;

Yedekleme için ayrı bir rol (REPLICATION veya pg_dump yetkisi), izleme için salt okunur rol. Hepsi postgres süperuser ile bağlanmasın.

3) pg_hba.conf
Kod:
# Örnek: sadece localhost, SCRAM # TYPE DATABASE USER ADDRESS METHOD local all all peer host all all 127.0.0.1/32 scram-sha-256 host all all ::1/128 scram-sha-256 # Uzaktan erişim gerekiyorsa: VPN CIDR + scram + TLS zorunlu

reject satırlarıyla istenmeyen ağları erken kesin. Docker lab'ında bile 0.0.0.0/0 + trust kombinasyonundan kaçının.

4) OAuth 2.0 (Özet)
PG 18, oauth yöntemini pg_hba içinde kullanmanıza izin veriyor; asıl doğrulama bir validator kütüphanesi / IdP entegrasyonu ile yapılıyor. Kurumsal SSO (Entra ID, Keycloak vb.) planlıyorsanız resmi dokümantasyondaki "OAuth Support" bölümüne bakın. Lab'da şart değil; production'da parola paylaşımını azaltır.

5) Hızlı Lab Checklist
  • listen_addresses'i ihtiyaca göre daraltın
  • password_encryption = scram-sha-256
  • ssl = on (lab'da self-signed bile olsa alışkanlık)
  • Süperuser uzaktan kapalı
  • Düzenli pg_dump + checksum doğrulama

Kaynaklar
Alıntı:Lab ve kendi sunucularınız için. Başkasının veritabanına izinsiz erişim suçtur.

Kapak: özgün TurkTeam görseli.

.png   bilgekagan-07.png (Dosya Boyutu: 94.96 KB / İndirme Sayısı: 13) ]]> [Resim: attachment.php?aid=36]
Selamlar,

PostgreSQL 18 (25 Eylül 2025) ile birlikte OAuth 2.0 kimlik doğrulama desteği geldi; asenkron I/O ve bir sürü performans iyileştirmesiyle birlikte güvenlik tarafında da bakılacak maddeler arttı. Bu konuda "yeni kurduğum Postgres'i nasıl sıkılaştırırım?" diyenler için temel bir kontrol listesi bırakıyorum.

Konuda Anlatılacaklar
  1. PostgreSQL 18'den güvenlikle ilgili notlar
  2. Rol ve yetki: süperuser alışkanlığını kırmak
  3. pg_hba.conf: SCRAM, md5'in düşüşü
  4. OAuth 2.0 (özet)
  5. Lab'da hızlı sıkılaştırma listesi

1) PG 18 Güvenlik Notları
Resmi duyuruya göre:
  • oauth kimlik doğrulama yöntemi: SSO entegrasyonu için (uzantı destekli)
  • md5 parola doğrulama deprecated; parola kullanacaksanız SCRAM
  • ssl_tls13_ciphers ile TLS 1.3 cipher kontrolü
  • Yeni kümelerde sayfa checksum'ları varsayılan açık (pg_upgrade senaryolarına dikkat)

2) Rol Disiplini
Kod:
-- uygulama kullanıcısı: süperuser DEĞİL CREATE ROLE app_user LOGIN PASSWORD 'uzun-ve-rastgele'; CREATE DATABASE appdb OWNER app_user; \c appdb -- şema ve tablo yetkilerini bilinçli verin GRANT CONNECT ON DATABASE appdb TO app_user; GRANT USAGE ON SCHEMA app TO app_user; GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA app TO app_user;

Yedekleme için ayrı bir rol (REPLICATION veya pg_dump yetkisi), izleme için salt okunur rol. Hepsi postgres süperuser ile bağlanmasın.

3) pg_hba.conf
Kod:
# Örnek: sadece localhost, SCRAM # TYPE DATABASE USER ADDRESS METHOD local all all peer host all all 127.0.0.1/32 scram-sha-256 host all all ::1/128 scram-sha-256 # Uzaktan erişim gerekiyorsa: VPN CIDR + scram + TLS zorunlu

reject satırlarıyla istenmeyen ağları erken kesin. Docker lab'ında bile 0.0.0.0/0 + trust kombinasyonundan kaçının.

4) OAuth 2.0 (Özet)
PG 18, oauth yöntemini pg_hba içinde kullanmanıza izin veriyor; asıl doğrulama bir validator kütüphanesi / IdP entegrasyonu ile yapılıyor. Kurumsal SSO (Entra ID, Keycloak vb.) planlıyorsanız resmi dokümantasyondaki "OAuth Support" bölümüne bakın. Lab'da şart değil; production'da parola paylaşımını azaltır.

5) Hızlı Lab Checklist
  • listen_addresses'i ihtiyaca göre daraltın
  • password_encryption = scram-sha-256
  • ssl = on (lab'da self-signed bile olsa alışkanlık)
  • Süperuser uzaktan kapalı
  • Düzenli pg_dump + checksum doğrulama

Kaynaklar
Alıntı:Lab ve kendi sunucularınız için. Başkasının veritabanına izinsiz erişim suçtur.

Kapak: özgün TurkTeam görseli.

.png   bilgekagan-07.png (Dosya Boyutu: 94.96 KB / İndirme Sayısı: 13) ]]>