MongoDB Güvenlik Kontrol Listesi: Kendi Sunucunuzda Adım Adım Sertleştirme

Kontrol listesine genel bakış

1. Erişim denetimini açın ve kimlik doğrulamayı zorunlu kılın

Belgelere göre MongoDB erişim denetimini varsayılan olarak açık getirmez ve mongod güvenilir bir ortamda çalıştığını varsayar. Bu nedenle ilk madde erişim denetimini açmak ve bir kimlik doğrulama mekanizması seçmektir. MongoDB Community, varsayılan olan SCRAM'i ve X.509 sertifika doğrulamasını destekler; Enterprise ve Atlas ayrıca LDAP proxy ve Kerberos destekler. Kendi sunucunuzda en pratik yol SCRAM'dir.

security:
  authorization: enabled

Bu satırı eklemeden önce bir kullanıcı yöneticisi oluşturmayı unutmayın; aksi halde yalnızca localhost istisnası üzerinden ilk kullanıcıyı ekleyebilirsiniz. Tüm prosedür authentication yazısında var.

2. Rol tabanlı erişimi yapılandırın

Kontrol listesi önce bir kullanıcı yöneticisi, ardından sisteme erişen her kişi ve uygulama için ayrı bir MongoDB kullanıcısı oluşturmanızı ister. En az ayrıcalık ilkesine göre bir grup kullanıcının tam olarak neye ihtiyacı varsa onu tanımlayan roller oluşturulur ve kullanıcılara yalnızca işlerini yapmalarına yetecek roller verilir. Bir kullanıcı birden çok veritabanında yetki istiyorsa onu her veritabanında yeniden oluşturmak yerine tek kullanıcıya birden çok rol verilmesi önerilir.

Pratikte bu, uygulama bağlantı dizesinde root veya userAdminAnyDatabase taşıyan bir hesabın bulunmaması demektir. Uygulama hesabı kendi veritabanında readWrite, raporlama hesabı read, yedekleme hesabı backup rolüyle yetinmelidir. Ayrıntılar ve örnek kurulum için kullanıcı ve rol yönetimi yazısına bakın.

3. Ağ maruziyetini sınırlayın

net.bindIp: hangi arayüzleri dinleyeceğinizi seçin

mongod ve mongos varsayılan olarak yalnızca localhost'a bağlanır; net.bindIp ayarının varsayılan değeri de localhost'tur. net.ipv6 açıksa ayrıca IPv6 localhost adresine bağlanır. Uygulamanız aynı sunucudaysa bu varsayılanı değiştirmenize gerek yoktur. Uygulama başka bir sunucudaysa, birden çok ağ arayüzü olan sistemlerde MongoDB'yi özel (iç) ağ arayüzüne bağlamanız önerilir. net.bindIp virgülle ayrılmış bir liste kabul eder:

net:
  port: 27017
  bindIp: localhost,10.0.0.5

Bu örnekte 10.0.0.5, sunucunun yalnızca iç ağdan erişilebilen adresini temsil ediyor; kendi iç ağ adresinizi yazmalısınız. Belgeler tüm IPv4 adreslerine bağlanmak için 0.0.0.0, tüm adresler için net.bindIpAll veya --bind_ip_all seçeneklerini de tanımlar; ancak net.bindIp ile net.bindIpAll birlikte verilirse süreç hata verip sonlanır.

Güvenlik duvarı: yalnızca uygulama sunucusuna izin verin

Belgeler Linux'ta iptables ile temel bir desen önerir: mongod'a gelen trafiğe yalnızca uygulama sunucusunun adresinden izin vermek ve dönüş trafiğini yalnızca o adrese bırakmak. Varsayılan iptables politikasının açıkça kapatılmadıkça tüm trafiğe izin verdiğini, bu kuralların ancak varsayılan politika DROP'a çevrildiğinde anlam kazandığını hatırlatır. 198.51.100.55 yerine kendi uygulama sunucunuzun adresini yazın:

iptables -A INPUT -s 198.51.100.55 -p tcp --destination-port 27017 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -d 198.51.100.55 -p tcp --source-port 27017 -m state --state ESTABLISHED -j ACCEPT

Ubuntu'da güvenlik duvarını UFW ile yönetiyorsanız aynı mantığı (27017 portunu yalnızca uygulama sunucusunun adresine açmak) UFW güvenlik duvarı rehberindeki adımlarla uygulayabilirsiniz. Replica set üyeleri arasındaki iç kimlik doğrulama isteklerini ayrıca IP ile sınırlamak isterseniz security.clusterIpSourceAllowlist ayarı vardır; bu ayar kimlik doğrulaması olmadan başlatılmış bir mongod üzerinde etkisizdir. Kullanıcı başına IP kısıtlaması için db.createUser() yöntemindeki authenticationRestrictions alanı kullanılır.

VPN, SSH ve IP yönlendirme

Kontrol listesi doğrudan SSH root erişimini kapatmanızı da ister. Belgeler, iki ağı şifreli ve sınırlı bir tünelle bağlamak için VPN kullanımını ve bunun ortadaki adam saldırılarını önlemeye yardım ettiğini anlatır; MongoDB kullananların performans nedeniyle genellikle IPSEC VPN yerine TLS tercih ettiğini de not eder. Bir diğer öneri, mongod çalıştıran sunucularda IP yönlendirmeyi (IP forwarding) kapatmaktır:

sudo sysctl -w net.ipv4.ip_forward=0

Değişikliği kalıcı yapmak için /etc/sysctl.conf dosyasına net.ipv4.ip_forward = 0 satırını ekleyin. Windows'ta IP yönlendirme varsayılan olarak kapalıdır.

4. İletişimi TLS ile şifreleyin

Kontrol listesi, mongod ile mongos bileşenleri arasındakiler dahil, tüm gelen ve giden bağlantılar için TLS kullanılmasını ister. MongoDB işletim sisteminin yerel TLS kitaplığını kullanır: Linux'ta OpenSSL, Windows'ta Secure Channel, macOS'ta Secure Transport. Bunun pratik önemi, parolaların da bu kanaldan geçmesidir: belgelere göre db.createUser() verdiğiniz parolayı, passwordPrompt() kullansanız bile, TLS yoksa düz metin olarak iletir.

Sunucu tarafında en temel yapılandırma net.tls.mode değerini requireTLS yapmak ve net.tls.certificateKeyFile ile sertifika ve özel anahtarı içeren PEM dosyasını göstermektir. İstemci sertifikası da istemek isterseniz net.tls.CAFile ile istemci sertifikalarını doğrulayacak CA dosyasını eklersiniz:

net:
  port: 27017
  bindIp: localhost,10.0.0.5
  tls:
    mode: requireTLS
    certificateKeyFile: /etc/ssl/mongodb.pem
    CAFile: /etc/ssl/caToValidateClientCertificates.pem

requireTLS sunucunun yalnızca TLS ile şifrelenmiş bağlantıları kabul etmesini sağlar. Aynı portta karma kullanım için allowTLS ve preferTLS değerleri de vardır; bunlar genellikle mevcut bir kurulumu TLS'e kademeli geçirirken kullanılır. PEM dosyası sertifikayı ve özel anahtarı tam RFC 7468 BEGIN ve END satırlarıyla içermelidir. İstemci tarafında mongosh şu seçeneklerle bağlanır:

mongosh "mongodb://mongo0.example.com:27017" --tls --tlsCAFile /etc/ssl/mongodb/ca.pem

--tls şifrelemeyi açar, --tlsCAFile sunucu sertifikasını imzalayan CA'yı göstererek mongosh'un sunucuyu doğrulamasını sağlar. Sunucu istemci sertifikası istiyorsa --tlsCertificateKeyFile ile istemci sertifikası da verilir. Belgelerdeki bir not: --tlsMode değeri disabled dışında bir şey olduğunda, replica set içi bağlantılarda sunucu ve istemci kimliği için de net.tls.certificateKeyFile sertifikası kullanılır.

5. Veriyi koruyun

Diskteki veriyi korumanın birkaç katmanı vardır. MongoDB Enterprise, WiredTiger için yerel bir şifreli depolama motoru sunar; bu seçenek Community sürümünde yoktur. Belgeler, WiredTiger şifrelemesini kullanmıyorsanız verinin her sunucuda dosya sistemi, aygıt veya fiziksel şifreleme ile (örneğin dm-crypt) şifrelenmesini önerir. Ayrıca MongoDB verisinin, yani veri dosyalarının, yapılandırma dosyalarının, denetim loglarının ve anahtar dosyalarının dosya sistemi izinleriyle korunması gerekir.

Yapılandırma dosyası için belgelerdeki bir öneri, mongod.conf dosyasının sahibini servis kullanıcısı yapıp izinleri yalnızca sahibin okuyup yazabileceği şekilde daraltmaktır. Ubuntu ve Debian paketlerinde servis kullanıcısı mongodb olduğu için komut şöyle uyarlanır:

sudo chown mongodb:mongodb /etc/mongod.conf
sudo chmod 600 /etc/mongod.conf

Belgeler bunun yanında hassas alanların uygulama tarafında, veri ağa çıkmadan önce şifrelenmesi için Queryable Encryption ve istemci tarafı alan düzeyi şifreleme (CSFLE) seçeneklerini de anar. Antivirüs veya EDR tarayıcısı kullanıyorsanız storage.dbPath ve systemLog.path dizinlerini taramadan hariç tutmanız istenir; aksi halde tarayıcı önemli dosyaları karantinaya alabilir ya da silebilir, bu da veritabanının bozulmasına ve çökmesine yol açabilir.

6. Sistem etkinliğini kaydedin

Kontrol listesi logların merkezi bir log deposunda toplanmasını önerir, çünkü bu loglar kaynak IP adresleri dahil kimlik doğrulama denemelerini içerir. Kullanıcı işlemlerini ve bağlantı olaylarını kaydeden ayrıntılı denetim (auditing) özelliği ise MongoDB Enterprise'ta bulunur ve yalnızca kimlik doğrulama olayları gibi belirli olayları kaydedecek filtreler kurulabilir. Linux'ta paketle kurulan MongoDB logları varsayılan olarak /var/log/mongodb dizinine yazar.

7. MongoDB'yi ayrı bir işletim sistemi kullanıcısıyla çalıştırın

MongoDB süreçleri, veriye erişebilen ama gereksiz hiçbir yetkisi olmayan ayrı bir işletim sistemi hesabıyla çalışmalıdır. Paketle kurulumda bu hesap otomatik oluşturulur ve systemd servisi süreci onunla başlatır. mongod'u root olarak elle başlatmak hem bu ilkeye aykırıdır hem de veri dizininde root'a ait dosyalar bırakarak sonraki servis başlatmalarında izin sorunlarına yol açabilir. Belgeler ayrıca, root olmayan bir yöneticiye yalnızca mongod servisini başlatma, durdurma ve yeniden başlatma yetkisini sudoers üzerinden vermeyi gösteren ayrı bir sayfa sunar. Linux tarafındaki kullanıcı ve izin temelleri için Linux sunucu yönetimi temelleri yazısına bakabilirsiniz.

8. Güvenli yapılandırma seçenekleri: sunucu tarafı JavaScript

MongoDB bazı sunucu tarafı işlemlerde JavaScript çalıştırabilir: mapReduce, $where, $accumulator ve $function. Kontrol listesi bu işlemleri kullanmıyorsanız sunucu tarafı betik çalıştırmayı --noscripting seçeneğiyle kapatmanızı önerir. Yapılandırma dosyasındaki karşılığı security.javascriptEnabled ayarıdır; varsayılan değeri true'dur ve hem mongod hem mongos için geçerlidir.

security:
  authorization: enabled
  javascriptEnabled: false

Bu konuda MongoDB 9.0 ile bir değişiklik var: sürüm notlarına göre $accumulator, $function ve $where artık kullanımdan kaldırılmış sayılmıyor ve 9.0 bu işlevleri daha güçlü yalıtım sağlayan WebAssembly tabanlı bir JavaScript motoruyla yeniden etkinleştiriyor. Bu motor 9.0'da ppc64le mimarisinde kullanılamıyor ve sunucu tarafı JavaScript'teki tarih işlemleri artık sunucunun saat dilimi yerine UTC kullanıyor. Yine de kontrol listesinin önerisi değişmiyor: bu işlemlere ihtiyacınız yoksa kapatın. Ayrıntılar için MongoDB 9.0 yenilikleri yazısına bakın.

9. Düzenli ve sürekli kontroller

Güvenlik bir kerelik bir ayar değildir. Belgeler üretimdeki sistem için şu düzenli işleri sayar: MongoDB ürün güvenlik duyurularını (CVE) takip edip ürünleri güncellemek, ürün yaşam sonu tarihlerine bakıp desteklenen en son sürüme geçmek, makineye düzenli yama uygulamak, özellikle MongoDB'nin yanlışlıkla internete açılmasına yol açabilecek ağ kuralı değişikliklerini gözden geçirmek ve veritabanı kullanıcılarını düzenli olarak gözden geçirip yenilemek. Güncellemeden önce mutlaka yedek alın; yöntemler mongodump ve mongorestore yazısında, genel yedekleme stratejisi ise veritabanı yedekleme stratejileri rehberinde anlatılıyor.

Kısa uygulama sırası

• Paketle kurulum yapın ve servisin localhost üzerinde çalıştığını doğrulayın.
• Localhost üzerinden kullanıcı yöneticisini oluşturun, security.authorization: enabled ekleyin, servisi yeniden başlatın.
• Uygulama, raporlama ve yedekleme için ayrı, en az ayrıcalıklı kullanıcılar oluşturun.
• Uygulama başka sunucudaysa TLS sertifikasını hazırlayın, net.tls ayarlarını ekleyin.
• net.bindIp listesine yalnızca iç ağ adresini ekleyin ve güvenlik duvarında 27017'yi yalnızca uygulama sunucusuna açın.
• Kullanmıyorsanız security.javascriptEnabled: false ile sunucu tarafı JavaScript'i kapatın.
• Yapılandırma dosyasının izinlerini daraltın, logları merkezi bir yerde toplayın, yedeklemeyi planlayın.

Sık yapılan hatalar

• Önce bindIp'i açıp sonra kimlik doğrulamayı düşünmek: Sıralama tam tersi olmalı; önce erişim denetimi, sonra ağa açma.
• Güvenlik duvarında 27017'yi herkese açmak: Belgeler yalnızca güvenilir istemcilerin MongoDB arayüzlerine ve portlarına erişebilmesini ister.
• TLS olmadan uzaktan kullanıcı oluşturmak: Parola ağda düz metin olarak gider.
• Uygulamada yönetici hesabı kullanmak: Tek bir uygulama açığı tüm veritabanlarını etkiler.
• Veri dizinini antivirüs taramasına bırakmak: Dosyaların karantinaya alınması veritabanını bozabilir.
• Ayar değiştirip yeniden başlatmamak: mongod.conf değişiklikleri süreç yeniden başlayana kadar uygulanmaz.

Sık Sorulan Sorular

Uygulama ile MongoDB aynı sunucudaysa TLS gerekli mi?

Bu durumda bindIp yalnızca localhost kalabilir ve trafik ağa çıkmaz. Kontrol listesi tüm bağlantılarda TLS önerir; ancak riskin asıl büyüdüğü yer, trafiğin sunucular arasında ağ üzerinden aktığı kurulumlardır. Uygulama ayrı bir sunucuya taşınırsa TLS'i mutlaka açın.

Portu 27017'den başka bir değere almak güvenlik sağlar mı?

Belgelerin kontrol listesinde böyle bir madde yoktur. Port değiştirmek erişim denetimi, güvenlik duvarı ve TLS'in yerine geçmez. Portu değiştirirseniz iptables kurallarını da buna göre uyarlamanız gerektiğini belgeler ayrıca hatırlatır.

Community sürümünde diskte şifreleme yapabilir miyim?

WiredTiger'ın yerel şifreli depolama motoru Enterprise'a özgüdür. Community kullanıyorsanız belgelerin önerdiği gibi dosya sistemi veya aygıt düzeyinde (örneğin dm-crypt) şifreleme kullanabilirsiniz.

Bağlanamıyorum; güvenlik ayarlarından mı kaynaklanıyor?

bindIp, güvenlik duvarı, TLS ve kimlik doğrulama ayarlarının her biri bağlantıyı farklı biçimde engeller. Hangi katmanın sorun çıkardığını ayırt etmek için MongoDB bağlantı hataları yazısındaki adımları izleyin.

Marka adları sahiplerine aittir. Bu yazı bağımsız bir teknik rehberdir; adı geçen kuruluşlarla bayilik veya ortaklık ilişkisi bulunduğu anlamına gelmez.

İlgili içerikler: MongoDB öğrenme rehberi · MongoDB authentication etkinleştirme · MongoDB kullanıcı ve rol yönetimi · mongod.conf yapılandırması · MongoDB production notları · Ubuntu UFW güvenlik duvarı · VPS güvenlik sertleştirme