Mongodb

پیاده سازی الزامات امنیتی دیتابیس MongoDB – گام دوم

مطالبی که در پیش رو داریم لیستی از چک لیست امنیتی و اقدامات امنیتی است که باید برای حفاظت از نصب MongoDB خود انجام داده و همواره به یاد داشته باشید.

این مطالب در چند گام مختلف ارائه خواهد شد

انتشار محتوای سایت ایران سایبر فقط با ذکر منبع رسمی مجاز است 

گام دوم :

مکانیسم های احراز هویت – Authentication

SCRAM

با شروع نسخه ۴٫۰، MongoDB – پشتیبانی از مکانیسم تأیید اعتبار (MongoDB Challenge -Response (MONGODB-CR حذف می شود و اگر استقرار شما دارای اعتبار کاربری ذخیره شده در طرح MONGODB-CR است ، قبل از ارتقاء به نسخه ۴٫۰، باید مکانسیم احراز هویت را به SCRAM ارتقا دهید.

(Salted Challenge Response Authentication Mechanism (SCRAM

این یک مکانیسم احراز هویت پیش فرض برای MongoDB است. SCRAM مبتنی بر استاندارد IETF RFC 5802 است که بهترین شیوه ها را برای اجرای سازوکارهای واکنشی و چالشی در تأیید اعتبار کاربران با کلمه عبور تعریف می کند.

با استفاده از SCRAM ، پایگاه داده MongoDB اعتبار کاربری ارائه شده را براساس نام، رمز عبور و پایگاه داده احراز هویت تأیید می کند . پایگاه داده احراز هویت پایگاه داده ای است که در آن نام کاربر ایجاد شده ، به شناسایی کاربر کمک می کند.

امکانات SCRAM

  • یک فاکتور کاری قابل تنظیم (به عنوان مثال تعداد تکرار)

  • salts های تصادفی برای کاربر

  • تأیید اعتبار سرور به مشتری و همچنین مشتری به سرور

مکانیسم SCRAM

MongoDB از مکانیزم های SCRAM زیر پشتیبانی می کند:

Description

SCRAM Mechanism

استفاده از توابع هش SHA-1

اصلاح تعداد تکرار برای SCRAM-SHA-1

SCRAM-SHA-1

استفاده از تابع هش SHA-256

با نیاز به نسخه سازگار ویژگی (fcv) ، به نسخه ۴٫۰ تنظیم می شود

اصلاح تعداد تکرار برای SCRAM-SHA-256

New in version 4.0.

SCRAM-SHA-256

هنگام ایجاد یا به روز رسانی یک کاربر SCRAM ، می توانید مکانیسم خاص SCRAM را هنگامی که سرور یا مشتری رمز عبور را Digests می کنند نشان دهید

 هنگام استفاده از SCRAM-SHA-256 ، دیتابیس MongoDB نیاز به هش کردن رمز عبور سرور دارد

پشتیبانی درایور

برای استفاده از SCRAM، اگر درایور فعلی شما از SCRAM پشتیبانی نمی کند، باید درایور خود را ارتقا دهید . حداقل نسخه های درایوری که از SCRAM پشتیبانی می کنند عبارتند از:

Version

Driver Language

Version

Driver Language

۱٫۰٫۰

Perl

۱٫۱٫۰

C

۱٫۰

PHP

۱٫۰٫۰

++C

۲٫۸

Python

۱٫۱۰

#C

۰٫۴

Motor

۲٫۱۳

Java

۱٫۱۲

Ruby

۱٫۴٫۲۹

Node.js

۲٫۸٫۰

Scala

مکانیسم x.509

  • MongoDB از احراز هویت گواهی X.509 برای احراز هویت مشتری و احراز هویت داخلی اعضای replica sets و sharded clusters پشتیبانی می کند.

  • احراز هویت گواهی X.509 نیاز به اتصال امن TLS / SSL دارد.

نکته : از نسخه ۴٫۰ به بعد  MongoDB پشتیبانی از رمزگذاری TLS 1.0 را در سیستم هایی که TLS 1.1+ در دسترس است ، غیر فعال می کند .

صدور گواهی

در استقرار MongoDB باید از گواهی های معتبر تولید شده و امضا شده توسط یک مرجع گواهی معتبر استفاده شود . مدیران فناوری اطلاعات در سازمان ها می توانند یک گواهینامه مستقل تولید کنند یا از گواهی های تولید شده توسط یک فروشنده TLS / SSL شخص ثالث استفاده کنند . اخذ و مدیریت گواهینامه فراتر از محدوده این مستندات است.

گواهی مشتری x.509

برای تأیید هویت در سرورها ، مشتریان می توانند از گواهینامه x.509 به جای نام کاربری و کلمه عبور استفاده کنند.

الزامات گواهی مشتری

گواهی مشتری باید دارای ویژگی های زیر باشد:

  • یک (Certificate Authority (CA باید گواهی ها را برای مشتری و سرور صادر کند

  • گواهی های مشتری باید شامل موارد زیر باشد :

keyUsage = digitalSignature

extendedKeyUsage = clientAuth

  • هر کاربر منحصر به فرد MongoDB باید یک گواهی منحصر به فرد داشته باشد

  • یک subject گواهینامه ۵۰۹ مشتری که حاوی نام متمایز (DN) است ، باید با گواهی عضو x.509 دیگر متفاوت باشد. به طور مشخص کاربران باید با توجه به حداقل یکی از ویژگی های زیر متفاوت باشند :

 سازمان  (O)، واحد سازمانی (OU) یا (Component Domain (DC

هشدار

اگر  گواهینامه x.509 یک مشتری ترکیب O ، OU و DC را به عنوان Member x.509 Certificate داشته باشد ، آن مشتری به عنوان یک عضو کلاستر شناخته می شود و مجوز کامل در سیستم به او اعطا می شود .

کاربر MongoDB و پایگاه داده external$

برای تأیید اعتبار با یک گواهی مشتری (client certificate) ، ابتدا باید مقدار subject را در گواهی مشتری به عنوان یک کاربر MongoDB اضافه کنید . هر گواهی x.509 client  منحصر به فرد به یک کاربر MongoDB متصل است . به عنوان مثال شما نمیتوانید از یک گواهی تک مشتری برای تأیید اعتبار بیش از یک کاربر MongoDB استفاده کنید.

تغییر در نسخه ۳٫۶٫۳: برای استفاده از جلسات با احراز هویت کاربران external$ ، (یعنی Kerberos، LDAP، کاربران x.509)، نامهای کاربری نمیتوانند بیش از ۱۰K بایت باشند.

Authenticate

برای Authenticate با استفاده از گواهی x.509 client به MongoDB می توانید از طریق اتصال TLS / SSL متصل شوید؛ به عنوان مثال گزینه های خط فرمان شامل  ssl – – و sslPEMKeyFile – – می شود.

سپس در پایگاه داده خارجی می توانید از ()db.auth برای تأیید اعتبار کاربر مربوط به گواهی مشتری استفاده کنید.

 گواهی های x.509 کاربر

در نسخه ۳٫۰

برای احراز هویت داخلی، اعضای cluster shared و replica sets می توانند از فایل های keyfiles استفاده کنند که از مکانیسم اعتبار سنجی SCRAM استفاده می شود .

الزامات گواهی کاربر

گواهی کاربر جهت احراز هویت داخلی و تأیید عضویت در کلاستر بندی یا مجموعه ای از ماتریس ها ، باید دارای خواص زیر باشد :

  • یک (Certificate Authority (CA باید برای تمامی اعضای یک cluster shared یا یک replica sets گواهینامه ۵۰۹ صادر کند.

  • نام (Distinguished (DN که در موضوع گواهی عضو یافت می شود، باید یک مقدار غیر خالی را برای حداقل یکی از ویژگی های زیر تعیین کند: سازمان (O)، واحد سازمانی (OU) یا (Component Domain (DC

  • ویژگیهای سازمان (O)، ویژگیهای واحد سازمانی (OU)، و اجزای دامنه (DCs) باید برای دیگر اعضای کلاستر مطابقت داده شود . برای مطابقت گواهی باید تمام مشخصات این صفات یا حتی عدم مشخصه این صفات را مطابقت دهد. (منظور از ویژگی ها مهم نیست)

در مثال زیر دو DN دارای مشخصات مطابق در O، OU و در DC دارای مشخصات غیر مطابقی هستند .

CN=host1,OU=Dept1,O=MongoDB,ST=NY,C=US

C=US, ST=CA, O=MongoDB, OU=Dept1, CN=host2

با این حال، دو DN زیر شامل عدم هماهنگی در OU هستند

N=host1,OU=Dept1,OU=Sales,O=MongoDB

CN=host2,OU=Dept1,O=MongoDB

نام مشترک (CN) یا یکی از نامهای (Sub Name Alternative (SAN باید با نام سرور میزبان مطابقت داشته باشد که توسط سایر اعضای گروه استفاده می شود .

به عنوان مثال  برای یک کلاستر ، گواهی هامی توانند موضوعات زیر را داشته باشند:

subject= CN=<myhostname1>,OU=Dept1,O=MongoDB,ST=NY,C=US

subject= CN=<myhostname2>,OU=Dept1,O=MongoDB,ST=NY,C=US

subject= CN=<myhostname3>,OU=Dept1,O=MongoDB,ST=NY,C=US

اگر گواهی شامل تنظیمات کلید تمدید (Extended (extendedKeyUsage باشد،

ارزش آن باید شامل clientAuth باشد (“TLS Web Client Authentication”)

extendedKeyUsage = clientAuth

نکته : می توانید از  گواهی استفاده کنید که در استفاده از کلید تمدید (EKU) را شامل نمی شود.

پیکربندی MongoDB

برای تعیین کردن x.509 جهت احراز هویت داخلی ، علاوه بر سایر تنظیمات TLS / SSL مناسب برای استقرار ، برای هر یک از اعضای replica set یا sharded cluster ، نیاز به تنطیمات زیر دارید :

  • استفاده از یک فایل پیکر بندی clusterAuthMode و net.ssl.clusterFile

  • یا گزینه های خط فرمان clusterAuthMode – – و  sslClusterFile – –

گواهی کاربر و PEMKeyFile

برای پیکربندی MongoDB جهت احراز هویت گواهینامه مشتری ، mongod و mongos یک PEMKeyFile را برای نشان دادن هویت خود به مشتریان از طریق تنظیمات net.ssl.PEMKeyFile در پرونده پیکربندی یا گزینه خط فرمان sslPEMKeyFile – – مشخص می کنند.

اگر گواهی clusterFile جهت احراز هویت عضو داخلی مشخص نشده باشد ، MongoDB سعی خواهد کرد از گواهی PEMKeyFile برای احراز هویت عضو استفاده کند. برای استفاده از گواهی PEMKeyFile جهت احراز هویت داخلی و همچنین برای احراز هویت مشتری ، گواهی PEMKeyFile باید:

ExtendedKeyUsage تمدید شود یا مقادیر extendedKeyUsage را که شامل clientAuth علاوه بر serverAuth است را مشخص کنید.

استفاده از گواهینامه x.509 برای تأیید اعتبار مشتریان

MongoDB از احراز هویت گواهی x.509 برای استفاده از اتصال امن TLS / SSL پشتیبانی می کند . احراز هویت مشتری x.509 اجازه می دهد تا مشتریان بدون نام کاربری و رمز عبور و فقط با گواهینامه احراز هویت

به سرورها  متصل بشوند . در ادامه آموزش مراحل استفاده از x.509 برای احراز هویت مشتری را شرح خواهم داد .

نکته مهم : شرح کامل TLS / SSL، PKI (زیرساخت های کلید عمومی)، مخصوصا گواهینامه x.509 فراتر از محدوده این سند است. برای درک عمیق این آموزش باید با فرایند های TLS / SSL آشنایی کامل داشته و همچنین دسترسی به گواهی های معتبر x.509 را مطالعه کرده باشید .

هشدار : اگر گزینه  sslCAFile – – و فایل مقصد آن مشخص نشده باشند ، x.509 client و احراز هویت کاربر عملکردی نخواهند داشت.

گواهی x.509 Certificate – پیکربندی MongoDB برای x.509

گزینه های خط فرمان : می توانید mongod / mongos را برای احراز هویت x.509 از خط فرمان پیکربندی کنید. به عنوان مثال، اگر یک replica set را اجرا کنید، هر عضو می تواند گزینه های زیر را داشته باشد:

mongod --clusterAuthMode x509 --sslMode requireSSL --sslPEMKeyFile <path to TLS/SSL certificate and key PEM file> --sslCAFile <path to root CA PEM file> --replSet <name> --bind_ip <hostnames>

همانطور که مشاهده می کنید شامل گزینه های اضافی مورد نیاز برای تنظیمات می باشد به عنوان مثال، اگر میخواهید مشتریان از راه دور برای پیاده سازی خود ارتباط برقرار کنند یا کاربران مستقرشده در میزبان های مختلف اجرا شوند ، باید  — bind_ip را مشخص کنید

نیازمندی های پیکربندی x.509 :

NotesOption
اگر استقرار مربوطه ، یک replica set  یا sharded cluster باشد ، x509 را برای تمام اعضای replica set/sharded cluter اختصاص دهید.

– – clusterAuthMode.

مشخص کردن requireSSL

– – sslMode

نمونه گواهی x.509

– – sslPEMKeyFile

گواهی Authority file برای تأیید نمونه گواهی ارائه شده

– – sslCAFile

فایل پیکربندی : می توانید mongod / mongos را جهت احراز هویت x.509 در فایل پیکربندی ، تنظیم کنید. به عنوان مثال، اگر یک replica set را اجرا کنید، هر عضو شامل گزینه های زیر است :

security:
    clusterAuthMode: x509
net:
    ssl:
        mode: requireSSL
        PEMKeyFile: <path to TLS/SSL certificate and key PEM file>
        CAFile: <path to root CA PEM file>

موارد فوق ، شامل گزینه های اضافی مورد نیاز برای تنظیمات می باشد . به عنوان مثال، اگر مایل باشید که مشتریان از راه دور در پیاده سازی شما متصل شوند یا اعضای استقرار شما در میزبان های مختلف اجرا شوند، تنظیمات را در net.bindIp مشخص کنید.

نیازمندی های پیکربندی x.509 :

Notes

Option

اگر استقرار مربوطه ، یک replica set  یا sharded cluster باشد ، x509 را برای تمام اعضای replica set/sharded cluter اختصاص دهید.

security.clusterAuthMode

مشخص کردن requireSSL

net.ssl.mode

نمونه گواهی x.509

net.ssl.PEMKeyFile

گواهی Authority file برای تأیید نمونه گواهی ارائه شده

net.ssl.CAFile

روش ها

اضافه کردن subject گواهی x.509 به عنوان یک کاربر

برای تأیید اعتبار با یک گواهی مشتری (client certificate) ، ابتدا باید مقدار subject را در گواهی مشتری به عنوان یک کاربر MongoDB اضافه کنید . هر گواهی x.509 client  منحصر به فرد به یک کاربر MongoDB متصل است . به عنوان مثال شما نمیتوانید از یک گواهی تک مشتری برای تأیید اعتبار بیش از یک کاربر MongoDB استفاده کنید.

تغییر در نسخه ۳٫۶٫۳: برای استفاده از جلسات با احراز هویت کاربران external$ ، (یعنی Kerberos، LDAP، کاربران x.509)، نامهای کاربری نمیتوانند بیش از ۱۰K بایت باشند.

نکته : RDNs در subject string باید با استاندارد RFC2253 سازگار باشد.

۱ . می توانید subject  فرمت RFC2253 را از گواهی مشتری با دستور زیر بازیابی کنید:

openssl x509 -in <pathToClientPEM> -inform PEM -subject -nameopt RFC2253

دستور زیر subject string گواهی را بازگردانی می کند :

subject= CN=myName,OU=myOrgUnit,O=myOrg,L=myLocality,ST=myState,C=myCountry
-----BEGIN CERTIFICATE-----
# ...
-----END CERTIFICATE-----

۲ . مقداری سازگار  برای RFC2253 به عنوان یک کاربر اضافه کنید

db.getSiblingDB("$external").runCommand(
  {
   createUser: "CN=myName,OU=myOrgUnit,O=myOrg,L=myLocality,ST=myState,C=myCountry",
roles: [
      { role: "readWrite", db: "test" },
      { role: "userAdminAnyDatabase", db: "admin" }
   ],
   writeConcern: { w: "majority" , wtimeout: 5000 }
 }
)

Authenticate با یک گواهی x.509

بعد از اینکه subject  گواهی x.509 مشتری را به عنوان یک کاربر MongoDB مربوطه اضافه کردید، پس از آن می توانید با گواهی مشتری تایید کنید.

برقراری ارتباط با احراز هویت جهت  تأیید هویت در طول اتصال :

mongo --ssl --sslPEMKeyFile <path to CA signed client PEM file> --sslCAFile <path to root CA PEM file>  --authenticationDatabase '$external' --authenticationMechanism MONGODB-X509

Notes

Option

— ssl

فایل Client’s x.509

— sslPEMKeyFile

فایل Certificate Authority جهت تایید گواهی ارائه شده توسط

mongod/mongosinstance

— sslCAFile

مشخص کردن ‘$external’

— authenticationDatabase

مشخص کردن  MONGODB-X509

— authenticationMechanism

برقراری ارتباط پس از احراز هویت :

شما می توانید بدون احراز هویت متصل شده و از روش ()db.auth  برای  احراز هویت پس از اتصال استفاده کنید. برای مثال، استفاده از mongo shell

 ۱ . اتصال mongo shell به Mongod برای راه اندازی TLS / SSL:

mongo --ssl --sslPEMKeyFile <path to CA signed client PEM file> --sslCAFile <path to root CA PEM file>

Notes

Option

— ssl

فایلClient’s x.509

— sslPEMKeyFile

فایل Certificate Authority جهت تایید گواهی ارائه شده توسط

mongod/mongosinstance

— sslCAFile

۲ . برای انجام احراز هویت ، در پایگاه داده external$ از روش ()db.auth استفاده کنید.  زمینه برای فیلد mechanism ، “MONGODB-X509” را مشخص کنید.

db.getSiblingDB("$external").auth(
  {
    mechanism: "MONGODB-X509"
  }
)

 

پایان گام دوم
ادامه دارد …

گردآورنده : سید محمد اسماعیلی

 

نوشته های مرتبط

امنیت سرور ssh

۱۹

مرداد
همه موضوعات

سند امنیت در سرور OpenSSH – چک لیست امنیتی OpenSSh

انتشار محتوای سایت ایران سایبر فقط با ذکر منبع رسمی مجاز است OpenSSH اجرای پروتکل SSH است و به دلیل امنیت بالا برای ریموت لاگین ، ایجاد پشتیبان ، انتقال فایل از راه دور از طریق scp یا sftp و موارد دیگر توصیه می شود. SSH جهت حفظ محرمانگی و یکپارچگی داده های تبادل شده بین دو شبکه […]

کنترل پهنای باند اینترنت

۱۶

مرداد
همه موضوعات

محدود کردن سرعت اینترنت کاربران شبکه LAN در لینوکس

انتشار محتوای سایت ایران سایبر فقط با ذکر منبع رسمی مجاز است  اینترنت می تواند ترافیک نامطلوب زیادی را از جمله فعالیت هکرها ، اسپم ها ، جاسوس افزارها و موارد دیگر به همراه آورد. در این مقاله قصد دارم یک ابزار منبع باز را معرفی کنم تا بوسیله آن بتوانید ترافیک اینترنت را کنترل کرده و فعالیت[…]