Mongodb

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

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

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

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

گام ششم :

مجوز های LDAP یا LDAP Authorization

در سرورهای LDAP ، MongoDB Enterprise از پرس و جو (query) در گروه های LDAP که کاربر معتبر دارد پشتیبانی می کند و اسامی متمایز (DN) هر گروه بازگشتی را به role ها در پایگاه داده مدیریت می دهد و کاربر را براساس role ها و امتیازات مربوط به آن مجاز می کند .

مواردی که مربوط به فرایند تأیید LDAP است در زیر خلاصه شده :

  1. یک مشتری به MongoDB متصل می شود و احراز هویت را با هر مکانیزم احراز هویت که از تایید هویت خارجی پشتیبانی می کند، انجام می دهد.

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

  1. MongoDB به سرور LDAP از طریق ldap.servers با استفاده از اعتبار مشخص شده با security.ldap.bind.queryUser و security.ldap.bind.queryPassword متصل می شود .

MongoDB از اتصال ساده به طور پیش فرض استفاده می کند ، اما می تواند در صورت استفاده از security.ldap.bind.method و security.ldap.bind.saslMechanisms از sasl binding استفاده کند.

  1. MongoDB یک query LDAP را با استفاده از ldap.authz.queryTemplate کرده و سرور LDAP را برای عضویت در گروه کاربر تأیید شده نمایش می دهد. همچنین می تواند از گزینه security.ldap.userToDNMapping برای تبدیل نام کاربری جهت پشتیبانی از الگوی پرس و جو استفاده کند.

  2. سرور LDAP پرس و جو ها را ارزیابی کرده و لیستی از گروه هایی را که کاربر تأیید شده متعلق به آن است را باز می گرداند.

  3. MongoDB کاربر را به انجام اقدامات در سرور با role بندی نام هر گروه بازگشتی (DN) در پایگاه داده مدیریت مجاز میکند . اگر گروه DN بازگشتی دقیقا مطابق با نام یک role موجود در پایگاه داده مدیریت باشد، MongoDB به کاربر مربوطه role و امتیاز اختصاص یافته به آن role را اعطا می کند .

  4. مشتری می تواند اقداماتی در سرور MongoDB انجام دهد که نیاز به یک role و امتیازات اعطا شده به کاربر معتبر را دارد .

  5. در یک بازه تعریف شده توسط ldapUserCacheInvalidationInterval ، MongoDB فضای حافظه external $ را از بین می برد. قبل از اجرای عملیات بعدی توسط کاربران خارجی مجاز ، MongoDB مجددا اعضاء گروه خود را از سرور LDAP به دست می آورد.

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

مکانیزم های احراز هویت زیر با (authorization) مجوز MongoDB LDAP سازگار است :

  • تأیید هویت پروکسی LDAP

  • تأیید اعتبار Kerberos

  • ۵۰۹

مدیریت کاربران

از طریق مجوزهای LDAP می توان در سرور LDAP کاربری را ایجاد و مدیریت کرد . MongoDB نیاز به ایجاد role در پایگاه داده مدیریت دقیقا مطابق با گروه LDAP و نام متمایز (DN) را دارد . این در مقایسه با مجوز مدیریت MongoDB که نیاز به ایجاد کاربران در پایگاه داده external$ را دارد متفاوت است .

برای مدیریت role ها در سرور MongoDB ، یک کاربر که عضویت در گروه مربوط به یک role پایگاه داده مدیر را دارد  برای احراز هویت لازم است موارد ارائه شده توسط userAdmin را داشته باشد .  از این رو ، role های مرتبط با DN های گروه LDAP نیاز به روزرسانی دارند ، به طوری که کاربران با عضویت در آن گروه ، role ها و امتیازات مناسب را دریافت می کنند.

مثلا : یک گروه LDAP برای مدیران پایگاه داده ممکن است یک role را با role های مدیریتی و امتیازات لازمه داشته باشد.

نکته مهم : هنگام تنظیم یک role برای یک گروه corresponding LDAP ، به یاد داشته باشید که تمام کاربران با عضویت در آن گروه می توانند role ها و امتیازات پیکربندی شده را دریافت کنند . در هنگام پیکربندی role  در MongoDB ، ابتدا باید حداقل امتیازات را در نظر بگیرید.

اگر هیچ role در اختیار مدیریت role وجود نداشته باشد و هیچ کاربر غیر خارجی یا non-$external با این امتیاز وجود نداشته باشد ، نمیتوانید به طور موثر مدیریت کاربر را انجام دهید ، زیرا هیچ یک از role های جدید یا در حال تغییر را نمیتوان تغییر داد تا این تغییرات را در گروهها و در سرور LDAP تغییر دهند .

در سناریویی که قادر نیستید role ها را بر روی سرور MongoDB مدیریت یا اصلاح کنید ، روش های زیر را انجام دهید:

  1. راه اندازی مجدد سرور MongoDB بدون احراز هویت و مجوز LDAP

  2. یک role در پایگاه داده مدیریت ایجاد کنید که نام آن مربوط به گروه LDAP مناسب نام آن است . هنگام انتخاب DN گروه ، در نظر بگیرید که کدام گروه مناسب تر برای مدیریت پایگاه داده است.

  3. سرور MongoDB با احراز هویت و مجوز LDAP را راه اندازی مجدد کنید

  4. احراز هویت به عنوان یک کاربر با عضویت در گروه مربوط به role ایجاد شده

کاربران موجود

یک سرور MongoDB با استفاده از مکانیزم LDAP برای مجوز هر کاربر موجود در پایگاه داده external$ ، آن را غیرقابل دسترسی می کند . اگر کاربران موجود در پایگاه داده external$ وجود داشته باشند ، برای هر کاربر در پایگاه داده external$ باید شرایط زیر را برای اطمینان از دسترسی مداوم داشته باشید :

  • کاربر دارای یک user object مربوطه در سرور LDAP است

  • user object دارای عضویت در گروه های LDAP است

  • MongoDB در پایگاه داده مدیریت شده دارای role برای گروه LDAP کاربر است ، به طوری که role ها و امتیازات اعطا شده همانند آنهایی است که به کاربر غیر خارجی non-$external اعطا شده است.

اگر می خواهید همچنان اجازه دسترسی توسط کاربران را در پایگاه داده $external بیابید ، مطمئن شوید که پارامتر authenticationMechanisms شامل SCRAM-SHA-1 و یا SCRAM-SHA-256 به صورت مناسب است . متناوبا از سوی دیگر، الزامات ذکر شده در بالا را برای انتقال این کاربران به مجوز LDAP اعمال کنید.

پیکربندی

برای استفاده از مجوز LDAP باید تنظیمات زیر را انجام دهید:

برای استفاده از مجوز LDAP از طریق کتابخانه های سیستم عامل، تنظیمات زیر را به عنوان بخشی از فایل پیکربندی mongod یا mongos خود مشخص کنید:

option

description

required

security.ldap.servers

لیستی جدا شده از کاما که از سرورهای LDAP در قالب  [port[host

نقل شده است.

YES

security.ldap.authz.queryTemplate

·   در RFC4515  و RFC4516 الگوی پرس و جو URL قالب بندی شده LDAP توسط MongoDB برای به دست آوردن گروه های LDAP که کاربر به آن تعلق دارد انجام می شود .

·   از {USER} ویژه placeholder استفاده کنید تا بتوانید نام کاربری تأیید شده یا نام کاربری تبدیل شده را در پرس و جو LDAP جایگزین کنید.

·   فقط mongod این پارامتر را پشتیبانی می کند.

YES

security.ldap.bind.queryUser

·   هویت سرور MongoDB همانی است که در هنگام اتصال و اجرای عملیات و نمایش داده ها به یک سرور LDAP متصل می شود.

·   با queryPassword استفاده کنید.

·   کاربر تعیین شده باید دارای امتیازات مناسب برای پشتیبانی از درخواست های LDAP تولید شده از configuredqueryTemplate باشد.

YES

security.ldap.bind.queryPassword

رمز عبور مورد استفاده برای اتصال به سرور LDAP هنگام استفاده از queryUser را مشخص می کند .

YES

security.ldap.bind.method

·   برای مشخص کردن روش mongod یا mongos جهت احراز هویت و یا اتصال به سرور LDAP استفاده می شود.

·   مشخص میکند sasl از یکی از پروتکل  های SASL استفاده می کند

insecurity.ldap.bind.saslMechanisms.

·   پیشفرض : simple

NO,

مگر اینکه از sasl برای اتصال به سرور LDAP استفاده کنید.

security.ldap.bind.saslMechanisms

·   مورد استفاده برای مشخص کردن مکانیزم های SASL در mongod یا mongos می باشد که می تواند هنگام تایید یا اتصال به سرور LDAP استفاده شود .

·   MongoDB و سرور LDAP باید حداقل یک مکانیزم SASL را بپذیرند.

·   Default به DIGEST-MD5

NO,

مگر اینکه تنظیم    bindMethod  به  sasl باشد  و شما نیاز به مکانیسم های SASL متفاوت یا اضافی داشته باشید

security.ldap.bind.useOSDefaults

استقرار ویندوز MongoDB می تواند از اعتبار سیستم عامل به جای queryUser و queryPassword برای احراز هویت یا ارتباط به هنگام اتصال به سرور LDAP استفاده کند.

NO,

مگر اینکه جایگزین queryUser  و queryPassword شود.

security.ldap.userToDNMapping

بسته به queryTemplate شما ، نام کاربری مشتری تأیید شده ممکن است نیاز به تغییراتی برای حمایت از آدرس پرس و جوی LDAP داشته باشد.

userToDNMapping اجازه می دهد MongoDB نام های کاربری ورودی را تبدیل کند .

NO,

مگر اینکه نامهای کاربری مشتری نیاز به تغییر در DN های LDAP داشته باشند.

الگو پرس و جوی LDAP

MongoDB از security.ldap.authz.queryTemplate برای ایجاد آدرس پرس و جوی LDAP فرمت RFC4516 استفاده می کند . در الگو ، از حفره {USER} استفاده کنید تا نام کاربری تأیید شده را در URL query LDAP جایگزین کنید و قالب پرس و جو را برای بازیابی گروه های کاربر تأیید شده طراحی کنید . اگر MongoDB نام کاربری را با استفاده از Mapping تغییر بدهد می تواند جایگزین {Token {USER با نام کاربری تبدیل شده هنگام ساخت URL پرس و جو LDAP شود.

مثال :

قالب پرس و جو زیر ، هر گروهی را که در ویژگی user object’s memberOf لیست شده است را باز می کند. این پرس و جو فرض می کند که ویژگی memberOf وجود دارد   .  استقرار LDAP شما ممکن است از یک ویژگی یا روش دیگر برای ردیابی عضویت گروه استفاده کند . این درخواست همچنین DN کامل خود را از طریق احراز هویت کاربر با استفاده از LDAP ، به عنوان نام کاربری خود فرض می کند.

"{USER}?memberOf?base"

URL پرس و جو LDAP باید مطابق با فرمت تعریف شده در RFC4516 باشد:

[ dn  [ ? [attributes] [ ? [scope] [ ? [filter] [ ? [Extensions] ] ] ] ] ]

تعریف هر مولفه را به عنوان نقل قول از RFC4516 در نظر بگیرید:

“ dn“ یک نام متمایز LDAP می باشد و با استفاده از فرمت رشته ای است که در

`RFC4514 <https://tools.ietf.org/html/rfc4514<’

 شرح داده شده است.  این شناسه پایه جستجوی LDAP یا هدف یک عملیات غیر جستجو است.

ساختار “ attributes“ برای نشان دادن این  است که کدام صفات باید از ورود یا ورودی بازگردانده شود استفاده می شود.

ساخت “ scope“ برای تعیین دامنه جستجو در سرور LDAP داده شده استفاده می شود. اسکوپ های مجاز برای پایگاه جستجوی base object ، ” base” هستند  ” one” برای جستجوی یک سطح ، یا ” sub” برای جستجو در subtree می باشد .

“ filter“ جهت تعیین فیلد جستجو برای اعمال ورودی در محدوده مشخص شده در طول جستجو استفاده می شود. این فرمت در قالب [RFC4515] مشخص شده است.

ساخت “ extensions“ نشانی اینترنتی LDAP را با یک مکانیزم توسعه پذیر فراهم می کند. و اجازه می دهد که قابلیت های URL در آینده گسترش یابد.

اگر پرس و جو شامل یک ویژگی باشد ، MongoDB  فرض می کند که پرس و جو مربوطه صرفا بازیابی یک DN است که عضوی از آن می باشد و اگر پرس و جو یک ویژگی را شامل نمی شود ،MongoDB  فرض می کند که پرس و جو مربوطه صرفا بازیابی تمام DN است که کاربر در آن عضو است.

MongoDB در حال حاضر هر پسوند مشخص شده در پرس و جو LDAP را نادیده می گیرد.

اتصال به یک سرور MongoDB با استفاده از مجوز LDAP

هنگام استفاده از مجوز LDAP برای کاربران  از طریق mongo shell ، باید :

  • تنظیم authenticationDatabase – – به external$ انجام شود

  • تنظیم authenticationMechanism – – به مکانیزم احراز هویت مناسب

اگر از LDAP authentication استفاده میکنید ، تنظیم به PLAIN

اگر از Kerberos authentication استفاده میکنید ، تنظیم به GSSAPI

اگر از  x.509 استفاده می کنید ، تنطیم به MONGODB-X.509

  • تنظیم username – – به یک نام کاربری که با ldap.authz.queryTemplate در ارتباط است، یا هر الگوی پیکر بندی configured security.ldap.userToDNMapping

  • تنظیم به password – – با رمز عبور مناسب

شامل host – – و  port – –  از سرور MongoDB ، همراه با هر گزینه دیگر مربوط به استقرار شما

مثال : عملیات زیر یک سرور MongoDB در حال اجرا با تأیید هویت و مجوز LDAP معتبر است :

mongo --username [email protected] --password "secret123" --authenticationDatabase '$external' --authenticationMechanism "PLAIN"  --host "mongodb.example.com" --port 27017

Role های MongoDB برای مجوز LDAP

MongoDB هر نام بازگشتی (DN) که توسط درخواست LDAP به یک role در پایگاه داده مدیریت برگشت خورده  است را نشان می دهد.

اگر MongoDB گروهی را پیدا کند که DN آن دقیقا با نام یک role موجود مطابقت داشته باشد ، می تواند اهداف و امتیازات تأیید شده مربوط به آن role را تأمین کند . اگر MongoDB نتواند هیچ یک از گروههای برگشتی را به یک role نشان دهد ، هیچ گونه امتیازی به کاربر نمی دهد.

نکته : احراز هویت LDAP و kerberos به طور معمول نیاز به ایجاد کاربران در پایگاه داده خارجی external$ دارند . اگر از مجوز LDAP نیز استفاده می کنید ، نیازی به ایجاد کاربران در پایگاه داده خارجی external$ نیستید. و فقط باید نقش های مناسب را در پایگاه داده مدیریت ایجاد کنید .

مثال :

یک پایگاه داده Role های زیر را در پایگاه داده مدیریت پیکربندی می کند:

{

    role: "CN=dba,CN=Users,DC=example,DC=com",

    privileges: [],

    roles: [ "dbAdminAnyDatabase", "clusterAdmin" ]

}

{

   role: "CN=analytics,CN=Users,DC=example,DC=com"

   privileges: [],

   roles: [

         { role : "read", db : "web_statistics" },

         { role : "read", db : "user_statistics" }

       ]

}

پس از تأیید هویت کاربر [email protected] در مقابل پایگاه داده external$ ، سرور MongoDB یک پرس و جو از قالب پرس و جو پیکربندی شده را برای بازیابی گروه هایی که شامل کاربر تأیید شده به عنوان یک عضو است را انجام می دهد . در این مثال ، سرور MongoDB گروه DN های زیر را برای کاربر بازیابی می کند:

(پیکربندی شده در پایگاه داده مدیریت)

dn:CN=dba,CN=Users,dc=example,dc=com

dn:CN=admin,CN=Users,dc=example,dc=com

MongoDB این گروه DNs را به یک Role در پایگاه داده مدیریت می دهد . اولین DN گروه با Role اول مواجه می شود و MongoDB کاربری را تأیید می کند که Role ها و امتیاز هایش را بر عهده دارد . گروه دوم DN هایی است که با هر Role در سرور مطابقت ندارد ، بنابراین MongoDB اجازه هیچ گونه مجوز دیگری را نمی دهد.

کاربر جدید [email protected] در برابر پایگاه داده external$ معتبر است. سرور MongoDB پردازش پرس و جو را با استفاده از نام کاربری ارائه شده در قالب پرس و جو انجام می دهد. در این مثال ، سرور MongoDB ، DN های گروه زیر را برای کاربر بازیابی می کند:

dn:cn=analytics,CN=Users,dc=example,dc=com

MongoDB maps این گروه DN ها را به Role ی در پایگاه داده مدیریت می دهد که این Role اعطا شده توسط کاربر احراز هویت شده Role است و از Role دوم می باشد .

کاربر جدید [email protected] در برابر پایگاه داده external$ معتبر است . سرور MongoDB پردازش پرس و جو را با استفاده از نام کاربری ارائه شده در قالب پرس و جو انجام می دهد . در این مثال ، سرور MongoDB ، DN های گروه زیر را برای کاربر بازیابی می کند:

dn:cn=guest,CN=Users,dc=example,dc=com

MongoDB این گروه را به یک Role در پایگاه داده مدیریت می دهد و چون هیچ Role تطبیقی وجود ندارد ، به کاربر مربوطه هیچ دسترسی اضافی را نمی دهد.

 

 

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

سرفصل گام هفتم : احراز هویت داخلی یا Internal Authentication

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

 

 

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

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

۰۵

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

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

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

رکوردهای DNS

۱۹

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

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

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