Mongodb

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

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

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

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

گام هفتم :

احراز هویت داخلی یا Internal Authentication

  • Keyfiles

  • X.509

در دیتابیس MongoDB می توانید اعضای replica sets و sharded clusters را احراز هویت کنید. برای احراز هویت داخلی اعضا ، MongoDB می تواند از keyfile ها یا x.509 استفاده کند که روش انتخاب شده برای کلیه ارتباطات داخلی استفاده می شود.

به عنوان مثال، زمانی که یک مشتری به یک mongos با استفاده از یکی از مکانیسم های احراز هویت پشتیبانی شده متصل می شود ، از روش احراز هویت داخلی پیکربندی شده برای اتصال به فرآیندهای mongod مورد نیاز، معتبر می شود.

نکته مهم : فعال کردن احراز هویت داخلی نیز امکان تأیید کلاینت را فراهم می کند.

Keyfiles

Keyfile ها از چالش SCRAM و مکانیزم احراز هویت پاسخ استفاده می کنند و محتویات keyfiles به عنوان رمز عبور مشترک برای اعضا می باشد . کلید باید طولی بین ۶ تا ۱۰۲۴ کاراکتر داشته باشد و ممکن است فقط شامل صفاتی در مجموعه base64 باشد.

MongoDB برای سهولت استفاده cross-platform ، فضاهای خالی را strips میکند (مانند x0d، x09 و x20)

در نتیجه، عملیات زیر کلیدهای مشابه تولید می کند :

echo -e "my secret key" > key1

echo -e "my secret key\n" > key2

echo -e "my    secret    key" > key3

echo -e "my\r\nsecret\r\nkey\r\n" > key4

  • در سیستم های یونیکس ، فایل اصلی نباید دارای مجوزهای گروهی یا کلی باشد و در سیستم های ویندوز ، مجوز های Keyfile بررسی نمی شوند.

  • محتویات keyfile باید در تمام موارد mongod و mongos که به یکدیگر متصل هستند ، هم باشند بنابراین باید keyfile را در هر عضوی از replica set یا sharded clusters ذخیره کنید.

  • برای مشخص کردن keyfile ، از گزینه keyFile یا گزینه خط فرمان keyFile – – استفاده کنید.

  • برای دیدن یک نمونه از احراز هویت داخلی keyfile میتوانید Enforce Keyfile Access Control را در مجموعه Replica Set مشاهده کنید .

x.509

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

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

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

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

  • یک تک (Certificate Authority (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

از آنجا که یکی شامل دو مشخصات OU و دیگری شامل تنها یک مشخصات است دو DN زیر می توانند شامل عدم سازگاری برای ویژگی 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 (extendedKeyUsage باشد ، ارزش آن باید شامل

(“clientAuth (“TLS Web Client Authentication باشد.

extendedKeyUsage = clientAuth

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

پیکربندی MongoDB

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

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

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

گواهی Member و PEMKeyFile

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

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

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

 

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

سرفصل گام هشتم : نصب Replica Set با کنترل دسترسی KeyFile

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

 

 

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

مدیریت دستگاه های IOT

۰۵

آبان
همه موضوعات

مدیریت از راه دور دستگاه های IOT با استفاده از ابزار Upswift

انتشار محتوای سایت ایران سایبر فقط با ذکر منبع رسمی مجاز است اگر فقط از یک دستگاه IoT استفاده می کنید و درحال توسعه پروژه های خود هستید، به روزرسانی و مدیریت آن سریع و آسان است. اما اگر ۱۰ ، ۵۰ یا ۱۰۰ دستگاه داشته باشید چه می کنید؟ مدیریت همه آنها ناگهان به یک دردسر […]

رکوردهای DNS

۱۹

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

مدیریت رکوردهای DNS با DNStable

یافتن اطلاعات در مورد سوابق DNS فرآیندی است که متخصصان امنیتی با عملیات های خاصی انجام می دهند. این اطلاعات از چند طریق قابل دستیابی است که در این مقاله به آنها خواهیم پرداخت. مشکل این است که بیشتر ابزارها برای یافتن سوابق DNS به روز شده و استفاده از آنها دشوار است. بیشتر متخصصان با تجربه[…]