MongoDB'de kimlik doğrulamayı açmak için önce admin veritabanında başka kullanıcıları yönetebilecek bir yönetici kullanıcı oluşturursunuz, ardından mongod.conf dosyasına security.authorization: enabled satırını ekleyip (ya da sunucuyu --auth seçeneğiyle başlatıp) mongod sürecini yeniden başlatırsınız. Bu andan sonra bağlanan her istemci kullanıcı adı, parola ve kimlik doğrulama veritabanı bilgisini vermek zorundadır ve yalnızca kendisine atanmış rollerin izin verdiği işlemleri yapabilir.
Bu ayrıntı önemlidir, çünkü belgelere göre MongoDB erişim denetimini varsayılan olarak açık getirmez; security.authorization ayarının varsayılan değeri disabled olarak tanımlanmıştır ve bu durumda bağlanabilen herkes her veritabanında her işlemi yapabilir. Bu yazıda kendi sunucunuzda (self-managed) çalışan tek bir mongod için SCRAM ile kimlik doğrulamayı adım adım açıyor, localhost istisnasını, kimlik doğrulama veritabanı kavramını ve sık yapılan hataları anlatıyoruz. Kurulum için MongoDB Ubuntu kurulumu, kullanıcı ve rollerin ayrıntısı için MongoDB kullanıcı ve rol yönetimi yazılarına bakabilirsiniz.
Kimlik doğrulama ve yetkilendirme aynı şey değildir
MongoDB belgeleri iki kavramı açıkça ayırır. Kimlik doğrulama (authentication), bağlanan istemcinin gerçekten iddia ettiği kullanıcı olup olmadığını doğrular. Yetkilendirme (authorization) ise kimliği doğrulanmış bu kullanıcının hangi kaynaklara erişip hangi işlemleri yapabileceğini belirler. MongoDB yetkilendirme için rol tabanlı erişim denetimi (RBAC) kullanır: kullanıcıya bir veya daha fazla rol verilir, kullanıcı rol atamaları dışında sisteme hiçbir şekilde erişemez.
Pratikte ikisi birlikte açılır. security.authorization ayarını enabled yaptığınızda MongoDB, erişimi belirlemek için tüm istemcilerin kendini doğrulamasını ister. Bu nedenle "kimlik doğrulamayı açmak" ile "erişim denetimini açmak" bu yazıda aynı işlemi anlatır. Belgeler ayrıca replica set ya da sharded cluster üyeleri arasında iç kimlik doğrulama (keyfile veya X.509) etkinleştirmenin istemci yetkilendirmesini de otomatik olarak açtığını belirtir.
Hangi kimlik doğrulama mekanizmaları var?
MongoDB'nin varsayılan mekanizması SCRAM'dir (Salted Challenge Response Authentication Mechanism). Parolalı kimlik doğrulama için IETF RFC 5802 standardına dayanan bu yöntemde sunucu, verilen kimlik bilgilerini kullanıcının adı, parolası ve kimlik doğrulama veritabanı ile karşılaştırır. MongoDB'nin SCRAM uygulaması ayarlanabilir bir iş faktörü (yineleme sayısı), kullanıcı başına rastgele tuz (salt) ve sunucu ile istemci arasında iki yönlü doğrulama sunar.
| Mekanizma | Hangi sürümde | Not |
|---|---|---|
| SCRAM-SHA-1 / SCRAM-SHA-256 | Community ve Enterprise | Varsayılan; parola ile doğrulama |
| X.509 sertifikası | Community ve Enterprise | Geçerli bir CA imzalı sertifika ve TLS bağlantısı gerekir |
| Kerberos | Enterprise | Mevcut Kerberos altyapısına bağlanır |
| LDAP proxy | Enterprise ve Atlas | Belgelerde kullanımdan kaldırılma uyarısı bulunur |
| OpenID Connect | Enterprise | OAuth2 üzerine kurulu, harici kimlik sağlayıcı ile tek oturum açma |
Kendi VPS'inizde Community sürümünü çalıştırıyorsanız pratik seçim SCRAM'dir. Kullanıcı oluştururken hangi SCRAM mekanizmasının kullanılacağını mechanisms alanıyla seçebilirsiniz; belirtmezseniz hem SCRAM-SHA-1 hem SCRAM-SHA-256 kimlik bilgisi oluşturulur. SCRAM-SHA-256 kullanıldığında parolanın sunucu tarafında özetlenmesi (passwordDigestor: "server", varsayılan değer) zorunludur. Belgelerdeki önemli bir kural da şudur: aynı kullanıcı için SCRAM ile başka bir kimlik doğrulama türünü birlikte kullanamazsınız.
Adım 1: Erişim denetimi kapalıyken yönetici kullanıcıyı oluşturun
Resmî prosedür, sunucu henüz erişim denetimi olmadan çalışırken ona bağlanmanızı ve ilk iş olarak bir kullanıcı yöneticisi oluşturmanızı önerir. Paketle kurulmuş bir Ubuntu sunucusunda mongod zaten systemd servisi olarak /etc/mongod.conf ile çalışır ve varsayılan olarak yalnızca localhost arayüzünü dinler. Bu yüzden aynı sunucudan mongosh ile bağlanmanız yeterlidir:
mongosh --port 27017Ardından admin veritabanına geçip kullanıcıyı oluşturun. Aşağıdaki örnek belgelerdeki prosedürle aynı rolleri kullanır: userAdminAnyDatabase kullanıcı oluşturma, rol verme ve özel rol tanımlama yetkisi verir; readWriteAnyDatabase ise local ve config dışındaki tüm veritabanlarında okuma ve yazma izni ekler.
use admin
db.createUser(
{
user: "yonetici",
pwd: passwordPrompt(),
roles: [
{ role: "userAdminAnyDatabase", db: "admin" },
{ role: "readWriteAnyDatabase", db: "admin" }
]
}
)passwordPrompt() çağrısı parolayı ekrana yazdırmadan sizden ister. Parolayı doğrudan metin olarak da verebilirsiniz, ancak belgeler bunun parolanın ekranda görünmesine ve kabuk geçmişine sızmasına yol açabileceğini hatırlatır ve passwordPrompt() kullanımını önerir. Kullanıcıyı oluşturduğunuz veritabanı (burada admin) bu kullanıcının kimlik doğrulama veritabanı olur; kullanıcı ileride bağlanırken bu veritabanını belirtmek zorundadır.
Adım 2: Erişim denetimini yapılandırma dosyasında açın
Kullanıcı oluştuktan sonra mongod'u erişim denetimi açık olacak şekilde yeniden başlatmanız gerekir. Sunucuyu systemd ile yönetiyorsanız kalıcı yöntem yapılandırma dosyasını düzenlemektir. /etc/mongod.conf içinde security bölümünü ekleyin (dosyada zaten varsa yalnızca alt satırı ekleyin):
security:
authorization: enabledArdından servisi yeniden başlatın. Linux paketleri systemd ile başlatıldığında bu yapılandırma dosyasını otomatik olarak yükler:
sudo systemctl restart mongod
systemctl status mongodBelgelerdeki prosedür paketsiz, elle başlatılan bir sunucu için de aynı mantığı izler: önce sunucuyu erişim denetimi olmadan mongod --port 27017 --dbpath /var/lib/mongodb ile başlatırsınız, kullanıcıyı oluşturduktan sonra mongosh içinden db.adminCommand( { shutdown: 1 } ) ile kapatır ve bu kez --auth ekleyerek başlatırsınız. Belgeler bu adımları mongod kullanıcısı olarak yapmanızı ister; süreci root olarak başlatırsanız veri dizininde oluşan dosyaların sahipliğini sonradan düzeltmeniz gerekir. Ubuntu ve Debian paketlerinde servis kullanıcısının adı mongodb'dir.
mongod --auth --port 27017 --dbpath /var/lib/mongodb| Amaç | Yapılandırma dosyası | Komut satırı |
|---|---|---|
| Erişim denetimini aç | security.authorization: enabled | --auth |
| Dinlenen port | net.port: 27017 | --port 27017 |
| Veri dizini | storage.dbPath: /var/lib/mongodb | --dbpath /var/lib/mongodb |
| Dinlenen adresler | net.bindIp: localhost | --bind_ip localhost |
Yapılandırma dosyasının diğer bölümleri ve komut satırı karşılıkları için mongod.conf yapılandırma yazısına, servis yönetimi için systemd servis yönetimi rehberine göz atabilirsiniz.
Adım 3: Yönetici olarak bağlanın ve kimliğinizi doğrulayın
Artık sunucu kimlik doğrulaması istiyor. İki yol vardır. Birincisi bağlanırken kimlik bilgilerini vermektir: -u kullanıcı adını, -p parolayı (değer vermezseniz sorulur), --authenticationDatabase ise kullanıcının oluşturulduğu veritabanını belirtir.
mongosh --port 27017 --authenticationDatabase "admin" -u "yonetici" -pİkincisi önce kimliksiz bağlanıp sonra kabuk içinde doğrulamaktır. Bunun için önce kimlik doğrulama veritabanına geçer, sonra db.auth() çağırırsınız:
use admin
db.auth("yonetici", passwordPrompt())Kimliksiz bağlantı açılabilir, ancak erişim denetimi açık olduğu için doğrulama yapılmadan yetki gerektiren işlemler reddedilir. Belgelerin vurguladığı bir davranış daha vardır: aynı mongosh oturumunda kullanıcı değiştiremezsiniz. Bir oturumda ikinci bir kullanıcıyla da kimlik doğrularsanız oturum her iki kullanıcının yetkilerine birden sahip olur. Başka bir kullanıcıya geçmek için mongosh'tan çıkıp yeniden başlatın. Kabuğun genel kullanımı için mongosh kullanımı yazısına bakabilirsiniz.
Localhost istisnası: önce erişim denetimini açarsanız
Kullanıcıyı erişim denetimini açmadan önce ya da açtıktan sonra oluşturabilirsiniz. Erişim denetimini hiç kullanıcı yokken açarsanız MongoDB size localhost istisnası tanır: sunucuya localhost arayüzünden bağlanan bir oturum, kimlik doğrulamadan admin veritabanında ilk kullanıcıyı ya da ilk rolü oluşturabilir. Bu istisna yalnızca örnekte hiç kullanıcı veya rol yokken geçerlidir ve ilk createUser ya da createRole çağrısıyla sona erer.
Belgeler bu noktada açık bir uyarı yapar: localhost istisnasıyla yalnızca ilk kullanıcı veya ilk rol oluşturulabilir ve rolü önce oluşturmak yalnızca kullanıcıları LDAP ile yetkilendiriyorsanız mantıklıdır. Bu yüzden ilk kullanıcı mutlaka başka kullanıcıları oluşturma yetkisine sahip olmalıdır; userAdmin veya userAdminAnyDatabase rolleri bu yetkiyi verir. İlk kullanıcıya yalnızca read rolü verirseniz istisna sona erer ve elinizde yeni kullanıcı oluşturabilecek kimse kalmaz.
Localhost istisnası açıkken yapılabilecekler belgelerde sınırlı olarak listelenmiştir: createUser ve createRole çalıştırmak (ikisi de istisnayı bitirir), bir replica set'i replSetInitiate ile başlatmak, replSetGetStatus ile durum okumak ve birincil üyede replSetReconfig çalıştırmak. Replica set başlatıyorsanız ilk kullanıcıyı eklemeden önce bir primary seçilmesini beklemeniz gerekir.
Kimlik doğrulama veritabanı ne anlama gelir?
Bir kullanıcıyı hangi veritabanında oluşturursanız o veritabanı kullanıcının kimlik doğrulama veritabanı olur. Bu, kullanıcının yetkilerini o veritabanıyla sınırlamaz; kullanıcı başka veritabanlarında da rol sahibi olabilir. Örneğin test veritabanında oluşturulup reporting veritabanında read rolü verilen bir kullanıcı, bağlanırken --authenticationDatabase "test" belirtir ama reporting'i okuyabilir.
Kullanıcı adı ile kimlik doğrulama veritabanı birlikte kullanıcının benzersiz kimliğini oluşturur. Aynı adla iki farklı veritabanında oluşturulan iki kullanıcı, MongoDB açısından iki ayrı kullanıcıdır. Birden çok veritabanında yetkisi olması gereken biri için kullanıcıyı her veritabanında tekrar oluşturmak yerine tek bir kullanıcı oluşturup her veritabanı için ayrı rol vermeniz önerilir. Tüm kullanıcı bilgileri admin veritabanındaki system.users koleksiyonunda tutulur; belgeler bu koleksiyonu doğrudan değiştirmemenizi, kullanıcı yönetimi komutlarını kullanmanızı ister.
Uygulamanız için ayrı bir kullanıcı oluşturun
Yönetici kullanıcıyı uygulama bağlantısında kullanmak yaygın ama riskli bir alışkanlıktır. Belgeler her uygulamanın ve her kişinin ayrı bir MongoDB kullanıcısına karşılık gelmesini, yalnızca gereken en az yetkinin verilmesini önerir. Yönetici olarak doğruladıktan sonra, örneğin yalnızca magaza veritabanında okuma ve yazma yapabilen bir uygulama kullanıcısı şöyle oluşturulur:
use magaza
db.createUser(
{
user: "magazaApp",
pwd: passwordPrompt(),
roles: [ { role: "readWrite", db: "magaza" } ]
}
)Bu kullanıcının kimlik doğrulama veritabanı magaza olduğu için uygulamanın bağlantı dizesinde de bunu belirtmeniz gerekir. Bağlantı dizesinde kimlik doğrulama veritabanı authSource seçeneğiyle verilir; ayrıntı için MongoDB connection string yazısına bakın. Yerleşik rollerin tam listesi ve özel rol tanımlama kullanıcı ve rol yönetimi yazısında anlatılıyor.
Parolalar ağda nasıl taşınır?
Belgelerdeki önemli bir uyarıya göre db.createUser() varsayılan olarak verdiğiniz tüm verileri sunucuya düz metin olarak gönderir; passwordPrompt() kullansanız bile bu değişmez. MongoDB parolayı düz metin olarak saklamaz, ancak parola istemciden sunucuya giderken TLS açık değilse korunmasızdır. Bu nedenle kullanıcıları sunucunun kendisinden (localhost) oluşturmak ya da bağlantıyı TLS ile şifrelemek gerekir. TLS yapılandırması ve ağ sertleştirmesi için MongoDB güvenlik kontrol listesi yazısını okuyun.
Replica set ve sharded cluster'da durum
Bu yazıdaki prosedür tek başına çalışan (standalone) bir mongod içindir. Replica set ve sharded cluster için belgeler ayrı öğreticiler sunar: üyelerin birbirini doğrulaması için keyfile ya da X.509 iç kimlik doğrulaması kurulur ve bu iç kimlik doğrulama istemci yetkilendirmesini de açar. Çalışan bir replica set'te kesinti olmadan keyfile erişim denetimine geçiş için ayrı bir öğretici vardır. Sharded cluster'da kullanıcılar mongos üzerinden eklenir ve config sunucularının admin veritabanında saklanır; mongos üzerinden oluşturulan kullanıcıyla doğrulama da mongos üzerinden yapılmalıdır. Replica set kurulumu için MongoDB replica set kurulumu, sharding kavramları için MongoDB sharding yazılarına bakabilirsiniz.
MongoDB 9.0 ile gelen ilgili değişiklikler
MongoDB 9.0 sürüm notları kimlik doğrulama tarafında iki küçük ekleme listeler. usersInfo komutuna isteğe bağlı authenticatedMechanism alanı eklenmiştir; bu alan, kullanıcı yetki bilgisi aranırken hangi yetkilendirme arka ucunun sorgulanacağını bir kimlik doğrulama mekanizmasına göre belirler (db.getUsers() seçenekleri arasında da yer alır). Ayrıca useInternalAuthzForX509 parametresi eklenmiştir: true yapıldığında MONGODB-X509 ile doğrulanan istemciler, LDAP yetkilendirmesi yapılandırılmış olsa bile iç yetkilendirmeyi kullanır. SCRAM ile çalışan standart bir kurulumda bu ikisini değiştirmeniz gerekmez. Diğer 9.0 değişiklikleri için MongoDB 9.0 yenilikleri yazısına bakın.
Sık yapılan hatalar
- İlk kullanıcıya yetersiz rol vermek: Localhost istisnası ilk kullanıcıyla biter. Bu kullanıcının
userAdminveyauserAdminAnyDatabaserolü yoksa yeni kullanıcı ekleyemezsiniz. - Yanlış kimlik doğrulama veritabanı: Kullanıcı
admin'de oluşturulduysa--authenticationDatabase "admin"(veya bağlantı dizesindeauthSource=admin) vermeden doğrulama başarısız olur. - Ayarı yapıp servisi yeniden başlatmamak:
mongod.confdeğişikliği süreç yeniden başlayana kadar etkili olmaz. - Parolayı komut satırına açık yazmak:
-pseçeneğine değer vermeden bırakın veyapasswordPrompt()kullanın; böylece parola kabuk geçmişine girmez. - Kimlik doğrulamayı açınca sunucuyu internete açmak: Parola tek başına yeterli koruma değildir;
bindIp, güvenlik duvarı ve TLS ile birlikte düşünülmelidir. - Uygulamada yönetici hesabı kullanmak:
userAdminAnyDatabasefiilen bir süper kullanıcı rolüdür; uygulamaya yalnızca kendi veritabanındareadWriteverin.
Sık Sorulan Sorular
Kimlik doğrulamayı açınca mevcut verilerim silinir mi?
Hayır. Erişim denetimini açmak verilere dokunmaz; yalnızca bağlantıların kimlik doğrulamasını ve yetki denetimini zorunlu hale getirir. Yine de yapılandırma değişikliğinden önce yedek almak iyi bir alışkanlıktır; mongodump ve mongorestore yazısı bu konuyu anlatıyor.
Kullanıcıyı önce mi oluşturmalıyım, erişim denetimini önce mi açmalıyım?
İkisi de mümkündür. Önce kullanıcıyı oluşturmak en az sürprizli yoldur. Önce erişim denetimini açarsanız localhost istisnası sayesinde sunucunun kendisinden ilk yönetici kullanıcıyı yine oluşturabilirsiniz; ancak bu yalnızca hiç kullanıcı ve rol yokken çalışır.
Hangi SCRAM mekanizmasını seçmeliyim?
Belirtmezseniz MongoDB kullanıcı için her iki SCRAM kimlik bilgisini de oluşturur. Yalnızca SCRAM-SHA-256 kimlik bilgisi istiyorsanız mechanisms: [ "SCRAM-SHA-256" ] verebilirsiniz; bu durumda parola sunucu tarafında özetlenmelidir. FIPS modu kullananlar için belgeler SCRAM-SHA-1 yerine SCRAM-SHA-256, Kerberos, LDAP veya X.509 önerir.
Erişim denetimini sonradan kapatabilir miyim?
Kendi sunucunuzda security.authorization değerini disabled yapıp yeniden başlatırsanız denetim kapanır ve belgelerin tanımıyla herkes her işlemi yapabilir hale gelir. Bu, internete açık bir sunucuda kabul edilebilir bir durum değildir. Atlas'ta ise erişim denetimi kapatılamaz.
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 kullanıcı ve rol yönetimi · MongoDB güvenlik kontrol listesi · mongod.conf yapılandırması · MongoDB connection string · MongoDB bağlantı hataları · VPS güvenlik sertleştirme