Mongodb

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

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

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

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

گام نهم :

استفاده از گواهی X.509 برای تایید عضویت

MongoDB از احراز هویت گواهی x.509 برای استفاده از اتصال امن TLS / SSL پشتیبانی می کند . اعضای Sharded cluster و اعضای replica set میتوانند از گواهی x.509 برای تأیید عضویت خود در cluster یا replica set به جای استفاده از keyfiles اصلی استفاده کنند.

فعال کردن احراز هویت داخلی ، کنترل دسترسی مبتنی بر نقش را امکان پذیر می کند . مشتریان باید به عنوان یک کاربر به منظور اتصال و انجام عملیات در استقرار ، احراز هویت کنند . دستورالعمل های استفاده از گواهی x.509 برای احراز هویت کاربر را می توانید از دستورالعمل های x.509 که در گام های قبلی ذکر شده مشاهده کنید

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

عضو گواهی x.509

جهت اتصال حتما باید گواهی های x.509 معتبر داشته باشید.

شروع در MongoDB 4.0 :  اگر  sslAllowInvalidCertificates – – یا  ssl.allowInvalidCertificates – – را پیکربندی کنید باید توجه داشته باشید زمانی که از احراز هویت x.509 استفاده می کنید ، تنها یک گواهی معتبر برای ایجاد اتصال TLS / SSL کافی است، اما برای احراز هویت کافی نیست .

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

گواهی اعضاء مورد استفاده برای احراز هویت داخلی جهت تأیید عضویت در sharded cluster یا یک replica set ، باید دارای ویژگی های زیر باشد :

  • یک (CertificateAuthority (CA باید همه گواهینامه ۵۰۹ را برای اعضای یک sharded cluster یا یک replica set صادر کند.

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

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

در مثال زیر، دو 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 هستند که یکی شامل دو مشخصات OU و دیگری تنها شامل یک مشخصات است

CN=host1,OU=Dept1,OU=Sales,O=MongoDB
CN=host2,OU=Dept1,O=MongoDB

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

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

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 Keywise (extendedKeyUsage باشد،

 باید شامل (“clientAuth (“TLS Web Client Authentication نیز باشد.

extendedKeyUsage = clientAuth

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

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

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

پیکربندی Replica Set/Sharded Cluster

خارج از روال ارتقاء دادن ، هر عنصری در هر یک از Replica Set یا Sharded Cluster باید از همان تنظیمات “clusterAuthMode” استفاده کند تا اطمینان حاصل شود که می تواند به راحتی به تمام اجزای دیگر در استقرار متصل شود.

این موضوع برای راه اندازی مجموعه Replica Set شامل تمام اعضاء mongod می باشد و برای گسترش و استقرار sharded cluster شامل تمام نمونه های mongod یا mongos می باشد

نکته : در لحظه شروع MongoDB 3.6 ، Mongod و Mongos به طور پیش فرض به Localhost متصل می شوند. اگر اعضای استقرار شما در میزبان های مختلف اجرا می شوند و یا اگر مایل باشید که مشتریان از راه دور بتوانند در پیاده سازی شما متصل شوند ، باید  bind_ip – – یا net.bindIp را مشخص کنید

از گزینه های خط فرمان استفاده کنید

برای مشخص کردن گواهی x.509 جهت احراز هویت عضو خوشه داخلی، گزینه های جانبی TLS / SSL که شامل clusterAuthMode – – و  sslClusterFile – – است را اضافه کنید  .

مثال زیر یک عضو از یک replica set را نشان می دهد :

mongod --replSet <name> --sslMode requireSSL --clusterAuthMode x509 --sslClusterFile <path to membership certificate and key PEM file> --sslPEMKeyFile <path to TLS/SSL certificate and key PEM file> --sslCAFile <path to root CA PEM file> --bind_ip localhost,<hostname(s)|ip address(es)>

این پیکر بندی گزینه های اضافی TLS / SSL و غیره می باشد که برای پیکربندی خاص شما لازم است . به عنوان مثال، اگر کلید عضویت رمزگذاری شده باشد ، sslClusterPassword – – را به عبارت رمز عبور تنظیم کنید تا کلید رمزگشایی شود .

هشدار : اگر گزینه  sslCAFile – – و فایل مقصد آن مشخص نشده باشند ، کلاینت x.509 و احراز هویت عضو ، عملکردی نخواهند داشت . Mongod و Mongos در سیستم های انحصاری قادر به تأیید گواهی های فرآیند اتصال به آن در برابر گواهی معتبر (CA (CA نیست .

از فایل پیکربندی استفاده کنید

می توانید پیکربندی MongoDB را در یک فایل پیکربندی قالب بندی YAML مشخص کنید ، همانطور که در مثال زیر عنوان شده است :

security:
 clusterAuthMode: x509
net:
 ssl:
  mode: requireSSL
  PEMKeyFile: <path to TLS/SSL certificate and key PEM file>
  CAFile: <path to root CA PEM file>
  clusterFile: <path to x.509 membership certificate and key PEM file>
 bindIp: localhost,<hostname(s)|ip address(es)>

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

سرفصل گام دهم : ارتقاء از احراز هویت Keyfile به احراز هویت x.509

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

 

 

 

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

تست نفوذ

۰۲

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

مراحل اجرایی تست نفوذ وب اپلیکیشن ها – Web Application Penetration Testing

آزمایش نفوذ یا تست نفوذ Penetration Testing چیست؟ تست نفوذ یا Penetration Testing یک فرایند ارزیابی امنیتی است که جهت بررسی آسیب پذیری های برنامه های وب توسط کارشناسان امنیتی آموزش دیده (مانند آزمون های نفوذ یا هکرهای اخلاقی) مورد استفاده قرار می گیرد . هدف از این آزمایش تقویت آسیب پذیری های امنیتی است که اپلیکیشن مورد نظر […]

ISMS ISO27001

۰۲

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

راهنمای پیاده سازی ISMS سازگار با ISO 27001

چک لیست ISO 27001  : راهنمای گام به گام برای پیاده سازی ایزو ۲۷۰۰۱ مشاوره ، استقرار و پیاده سازی ISMS سازگار با ISO 27001 (سیستم مدیریت امنیت اطلاعات) کار بس دشواری به نظر می رسد  اما همانطور که مطلع هستید هیچ استاندارد ارزشگذاری شده ایی آسان نیست و ایزو ۲۷۰۰۱ مطمئنا ارزش آن را دارد. تیم[…]