Mongodb

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

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

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

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

گام چهارم :

پیکر بندی MongoDB بوسیله Kerberos Authentication و Active Directory Authorization

این آموزش نحوه تنظیم MongoDB جهت انجام احراز هویت از طریق یک سرور Kerberos و مجاز بودن (authorization) از طریق یک سرور (Active Directory (AD از طریق کتابخانه های پلت فرم را توضیح می دهد.

دیتابیس MongoDB با استفاده از مکانیزم SASL ، اتصال بین سرور MongoDB و اکتیو دایرکتوری را پشتیبانی می کند.  مکانیسم SASL یا الزامات خاص پیکربندی اکتیو دایرکتوری AD ، فراتر از محدوده این آموزش است. بنابراین باید دانش SASL و موضوعات مربوط به آن را در حوزه اطلاعات عمومی خود داشته باشید .

طبق گفته های قبلی : راه اندازی ، پیکربندی و استقرار Kerberos فراتر از محدوده این سند می باشد و در این آموزش ما فرض می کنیم که یک سرویس Kerberos را برای هر نمونه Mongod و Mongos در deployment MongoDB خود پیکربندی کرده اید و یک فایل keytab برای هر نمونه Mongod و Mongos دارید.

برای مجموعه های replica sets  و  sharded clusters باید اطمینان داشته باشید که پیکربندی شما با استفاده از یک نام دامنه کامل (FQDN) به جای آدرس های IP یا نام های میزبان نامحدود مورد استفاده قرار می گیرد . همچنین  باید از FQDN برای GSSAPI جهت resolve  کردن Kerberos استفاده کنید تا اجازه اتصال امن داشته باشید .

برای بررسی فایلهای MongoDB Enterprise binaries ، از گزینه خط فرمان version — در mongod یا mongos استفاده کنید :

mongod --version

در خروجی از این دستور، ماژول های رشته (string) را جستجو می کنیم :

 اشتراک یا ماژول ها : گزینه Enterprise برای تایید سیستم شما یعنی MongoDB Enterprise بسیار گزینه مناسبی است .  باید اطمینان حاصل کنید که نام میزبان سیستم در مثال mongod یا mongos یک نام دامنه واجد شرایط و کامل است.

ملاحظات

این آموزش تطبیق مجوز اکتیو دایرکتوریActive Directory برای تأیید هویت Kerberos در MongoDB را توضیح می دهد . برای انجام این روش در سرور MongoDB خود ، باید رویه های داده شده را با توجه به زیرساخت های خاص خود ، به ویژه تنظیمات Kerberos ، ساخت پرس و جوهای AD یا مدیریت کاربران، اصلاح کنید.

امنیت لایه حمل و نقل یا Transport Layer

به طور پیش فرض ، دیتابیس MongoDB هنگام اتصال به سرور اکتیو دایرکتوری یک اتصال TLS / SSL ایجاد می کند. این فرآیند به پیکربندی سرور میزبان MongoDB جهت دسترسی به (Certificate Authority (CA اکتیودایرکتوری سرور نیاز دارد.

این آموزش دستورالعمل هایی برای تنظیمات میزبان مورد نیاز را فراهم می کند. و فرض می کند که شما به گواهینامه های CA سرور اکتیو دایرکتوری دسترسی داشته باشید و می توانید یک کپی از گواهی ها را در سرور MongoDB ایجاد کنید.

مثال Active Directory Schema

مثال زیر نمونه های اکتیودایرکتوری AD را به عنوان مبنایی برای نمایش داده شده، تنظیمات و خروجی ارائه می دهد. هر شی تنها یک زیر مجموعه از ویژگی های ممکن را نشان می دهد.

User Objects

dn:CN=bob,CN=Users,DC=marketing,DC=example,DC=com
userPrincipalName: [email protected]
memberOf: CN=marketing,CN=Users,DC=example,DC=com

dn:CN=alice,CN=Users,DC=engineering,DC=example,DC=com
userPrincipalName: [email protected]
memberOf: CN=web,CN=Users,DC=example,DC=com
memberOf: CN=PrimaryApplication,CN=Users,DC=example,DC=com

dn:CN=sam,CN=Users,DC=dba,DC=example,DC=com
userPrincipalName: [email protected]
memberOf: CN=dba,CN=Users,DC=example,DC=com
memberOf: CN=PrimaryApplication,CN=Users,DC=example,DC=com

dn:CN=joe,CN=Users,DC=analytics,DC=example,DC=com
userPrincipalName: [email protected]
memberof: CN=marketing,CN=Users,DC=example,DC=com

Group Objects

dn:CN=marketing,CN=Users,DC=example,DC=com
member:CN=bob,CN=Users,DC=marketing,DC=example,DC=com
member:CN=joe,CN=Users,DC=analytics,DC=example,DC=com

dn:CN=engineering,CN=Users,DC=example,DC=com
member:CN=web,CN=Users,DC=example,DC=com
member:CN=dba,CN=users,DC=example,DC=com

dn:CN=web,CN=Users,DC=example,DC=com
member:CN=alice,CN=Users,DC=engineering,DC=example,DC=com

dn:CN=dba,CN=Users,DC=example,DC=com
member:CN=sam,CN=Users,DC=dba,DC=example,DC=com

dn:CN=PrimaryApplication,CN=Users,DC=example,DC=com
member:CN=sam,CN=Users,DC=dba,DC=example,DC=com
member:CN=alice,CN=Users,DC=engineering,DC=example,DC=com

مجوزهای Active Directory

در این مرحله از نام کاربری و رمز عبور برای انجام نمایش در سرور اکتیو دایرکتوری AD استفاده می کند. اعتبارهای ارائه شده باید از سرور Active Directory برای پشتیبانی از پرس و جو مربوط به

security.ldap.userToDNMapping یا security.ldap.authz.queryTemplate برخوردار باشند.

Replica Sets

مجوز LDAP MongoDB برای هر Mongod در Replica Sets باید حداقل MongoDB 3.4.0 یا بالاتر باشد.

Sharded Clusters

مجوز MongoDB LDAP به هر Mongod و Mongos در sharded cluster به حداقل MongoDB 3.4.0 یا بالاتر نیاز دارد.

دستورالعمل ها

۱ . پیکربندی TLS / SSL برای سرور در حال اجرای MongoDB.

برای اتصال به سرور (AD (AD از طریق TLS / SSL ، mongod یا mongos نیاز به دسترسی به گواهینامه (Certificate Authority (CA را دارند .

در لینوکس، Certificate CA سرور را از طریق گزینه TLS_CACERT یا TLS_CACERTDIR در فایل ldap.conf مشخص کنید.

مدیرت بسته پلت فرم در هنگام نصب وابستگی libldap MongoDB Enterprise ، فایل ldap.conf را ایجاد می کند .

در مایکروسافت ویندوز ، گواهی (Certificate Authority (CA سرور اکتیودایرکتوری را با ابزار مدیریت اعتبارسنجی پلتفرم بارگذاری کنید . این ابزار دقیق مدیریت اعتبارات وابسته به ویندوز است .

اگر mongod یا mongos نمی توانند به فایل های AD CA دسترسی داشته باشند، نمی توانند اتصال TLS / SSL را به سرور Active Directory ایجاد کنند. به دلخواه خودتان طوری security.ldap.transportSecurity را تنظیم کنید تا TLS / SSL غیرفعال شود.

۲ . (فقط ویندوز) نام سرویس اصلی را به سرویس Windows MongoDB اختصاص دهید.

برای سرورهای MongoDB که در سیستم عامل ویندوز اجرا می شون، باید از setupn.exe برای اختصاص نام اصلی سرویس (SPN) به حساب کاربری سرویس MongoDB استفاده کنید.

setspn.exe -S <service>/<fully qualified domain name> <service account name>

به عنوان مثال، mongod به عنوان یک سرویس به نام mongodb در mongodbserver.example.com اجرا می شود

فرمان اختصاص دادن SPN به شرح زیر است:

setspn.exe -S mongodb/mongodbserver.example.com [email protected]

توجه داشته باشید

ویندوز سرور ۲۰۰۳ از setupn.exe -S پشتیبانی نمی کند.

۲ . (فقط لینوکس) فایل keytab را برای سرور MongoDB ایجاد کنید.

برای سرورهای MongoDB در حال اجرا بر روی پلت فرم لینوکس باید اطمینان حاصل کنید که سرور دارای یک کپی از فایل keytab خاص به عنوان مثال MongoDB در آن سرور است. بنابراین باید به کاربر لینوکس مجوزهای خواندن سرویس MongoDB را در فایل keytab اعطا کنید

۳ . اتصال به سرور دیتابیس MongoDB

با استفاده از mongo shell از گزینه های  host – –  و  port – – به سرور MongoDB وصل شوید.

mongo --host <hostname> --port <port>

اگر سرور MongoDB شما در حال حاضر احراز هویت را تأیید می کند ، باید پایگاه داده مدیریت را به عنوان یک کاربر با امتیازات مدیریت نقش، مانند موارد ارائه شده توسط UserAdmin یا UserAdminAnyDatabase تأیید کنید.

این کار شامل authenticationMechanism —  مناسب برای مکانیزم احراز هویت پیکربندی سرور MongoDB است.

mongo --host <hostname> --port <port> --username <user> --password <pass> --authenticationDatabase="admin" --authenticationMechanism="<mechanism>"

توجه داشته باشید

برای استقرار Windows MongoDB باید mongo را با mongo.exe جایگزین کنید

۴ . ایجاد نقش کاربر مدیر

برای مدیریت کاربران MongoDB با استفاده از اکتیو دایرکتوری ، باید حداقل یک نقش را در پایگاه داده مدیریت ایجاد کنید که بتواند نقش ها را ایجاد و مدیریت کند ، مانند مواردی که توسط userAdmin یا userAdminAnyDatabase ارائه شده است.

نام نقش ها باید دقیقا مطابق با نام برجسته یک گروه اکتیودایرکتوری باشد . این گروه باید حداقل یک کاربر اکتیو دایرکتوری را به عنوان یک عضو داشته باشد.

با توجه به گروه های Active Directory موجود در عملیات زیر:

  • ایجاد یک نقش در گروه اکتیو دایرکتوری

CN=dba,CN=Users,DC=example,DC=com

  • در پایگاه داده مدیریت آن را به نقش UserAdminAnyDatabase اختصاص می دهد

var admin = db.getSiblingDB("admin")
admin.createRole(
  {
    role: "CN=dba,CN=Users,DC=example,DC=com",
    privileges: [],
    roles: [ "userAdminAnyDatabase" ]
  }
)

شما می توانید نقش userAdmin را به طور جایگزین برای هر پایگاه داده ای که کاربر باید دارای امتیازات مدیریتی در آن باشد، اعطا کنید . این نقش ها امتیازات لازم را برای ایجاد و مدیریت نقش فراهم می کند.

نکته مهم : در هنگام پیکربندی نقش های MongoDB ، گروه های AD یا اعضای گروه باید از اصل حداقل امتیاز برخوردار باشند .

۵ . ایجاد یک فایل پیکربندی MongoDB

معمولا فایل پیکربندی در دیتابیس MongoDB یک فایل YAML متن ساده با پسوند فایل conf. است.

 (فقط لینوکس) :  اگر این استقرار جدید برای کارتان باشد و شما از مدیریت بسته ها برای نصب MongoDB Enterprise استفاده می کنید ، این نصب شامل فایل پیکربندی پیش فرض etc/mongod.conf/ است.  و می توانید از پرونده پیکربندی پیش فرض یا یک کپی از آن فایل را برای کار خود استفاده کنید .

اگر چنین فایل وجود نداشته باشد، یک فایل خالی .conf ایجاد کنید و از آن فایل پیکربندی جدید  شروع به کار کنید.

۶ . پیکربندی دیتابیس MongoDB برای اتصال به Active Directory

در فایل پیکربندی MongoDB ، security.ldap.servers را در میزبان و پورت سرور AD تنظیم کنید . اگر زیرساخت اکتیو دایرکتوری شما شامل چندین سرور AD برای تکرار باشد ، میزبان و پورت سرور را به عنوان لیست محدود شده با کاما در security.ldap.servers مشخص کنید .

مثال : موارد پیکر بندی زیر شامل اتصال به سرور اکتیو دایرکتوری واقع در activatedirectory.example.net می باشد

security:
 ldap:
  servers: "activedirectory.example.net"

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

همچنین شما می توانید تنظیمات زیر را در فایلی که ذکر شده پیکربندی کنید تا به سرور اکتیو دایرکتوری با استفاده از SASL متصل شوید:

  • تنظیم ldap.bind.method به sasl

  • ldap.bind.saslMechanisms ، مشخص کردن یک رشته از مکانیزم SASL جدا شده با کاما که سرور اکتیو دایرکتوری پشتیبانی می کند.

نکته : این آموزش از مکانیزم احراز هویت ساده LDAP استفاده می کند.

۷ . پیکربندی دیتابیس MongoDB برای احراز هویت Kerberos.

در فایل پیکربندی دیتابیس MongoDB، مجوز امنیتی را برای فعال کردن و تنظیم پارامتر authenticationMechanisms به GSSAPI تنظیم کنید.

برای فعال کردن احراز هویت از طریق Kerberos ، در فایل پیکربندی زیر موارد زیر را وارد کنید:

security:
  authorization: "enabled"
setParameter:
  authenticationMechanisms: "GSSAPI"

۸ . پیکربندی الگوی پرس و جو LDAP برای مجوز.

در فایل پیکربندی MongoDB ، set security.ldap.authz.queryTemplate را به الگوی پرس و جو LDAP قالب بندی شده RFC4516 تنظیم کنید.

نکته مهم : توضیحات کامل  RFC4515،  RFC4516، و یا درخواست های AD از محدوده این آموزش خارج است. queryTemplate که در این آموزش ارائه شده است فقط یک مثال است و ممکن است برای استقرار خاص AD شما قابل استفاده نباشد.

مثال : در قالب پرس و جو زیر هر گروهی را که {USER}  به عنوان یک عضو فهرست می کند، بازمی گرداند .

پس از عضویت گروه های بازگشتی  پرس و جو LDAP فرض می کند که گروه object با استفاده از ویژگی عضو و ذخیره ی نام کاربری مشخص ، کاربر (DN) را با استفاده از ویژگی عضو به اشتراک می گذارد.

 پرس و جو شامل قانون تطابق خاص OID OOI 1.2.840.113556.1.4.1941 برای LDAP_MATCHING_RULE_IN_CHAIN است. این قانون تطبیق یک فرمت خاص اکتیو دایرکتوری برای فیلترهای جستجو LDAP است.

security:
 ldap:
  authz:
   queryTemplate:
    "DC=example,DC=com??sub?(&(objectClass=group)(member:1.2.840.113556.1.4.1941:={USER}))"

برای مثال : یک کاربر به عنوان CN=sam,CN=Users,DC=dba,DC=example,DC=com تایید می شود . MongoDB پرس و جو LDAP را بر اساس queryTemplate ایجاد می کند ، با استفاده از نام کاربری ارائه شده {USER} را جایگزین می کند . سرور Active Directory یک جستجوی گروه بازگشتی را برای هر گروه انجام می دهد که به طور مستقیم یا به صورت دو طرفه لیست کاربر را به عنوان یک عضو می دهد . بر اساس گروه های فعال دایرکتوری، سرور AD ، CN = dba، CN = Users، DC = example، DC = com و CN = engineering، CN = Users، DC = example، DC = com را نشان می دهد.

MongoDB نقشه های هر DN گروه بازگشتی را به یک نقش در پایگاه داده مدیریت اختصاص می دهد .

برای هر DN گروه بندی شده ، اگر یک نقش موجود در پایگاه داده مدیریت وجود داشته باشد که نام آن دقیقا با DN مطابقت داشته باشد ، MongoDB نقش و امتیازات اختصاص داده شده را به آن کاربر می دهد.

قانون تطابق LDAP_MATCHING_RULE_IN_CHAIN نیاز به ارائه DN کامل از کاربر برای  تأیید اعتبار دارد. از آنجا که Kerberos نیاز به تأیید اعتبار با کاربر userPrincipalName دارد ، شما باید نامهای ورودی کاربری را به DN ها با استفاده از security.ldap.userToDNMapping تبدیل کنید. مرحله بعدی راهنمایی را برای تبدیل نامهای کاربری ورودی به پشتیبانی از queryTemplate ارائه می دهد.

۹ . تبدیل نام های کاربری برای احراز هویت از طریق Active Directory

در فایل پیکربندی MongoDB ، userToDNMapping را طوری تنظیم میکنیم تا نام کاربری ارائه شده توسط کاربر مکانیسم احراز هویت را به DN AD برای پشتیبانی از queryTemplate تبدیل کند.

مثال : تنظیمات UserToDNMapping زیر از فیلد اصلاح برای گرفتن نام کاربری ارائه شده استفاده می کند. MongoDB نام کاربری گرفته شده را قبل از اجرای پرس و جو به الگوی query ldapQuery وارد می کند.

security:
 ldap:
  userToDNMapping:
   '[
     {
       match : "(.+)",
       ldapQuery: "DC=example,DC=com??sub?(userPrincipalName={0})"
     }
]'

در این مرحله باید پیکربندی نمونه داده شده را اصلاح کنید تا با استقراری که انجام می دهید سازگار شود .

به عنوان مثال : پایه ldapQuery DN باید با پایه DN منطبق باشد که شامل کاربر شما بشود با این حال ممکن است تغییرات دیگری نیز برای پشتیبانی از گسترش AD شما ضروری باشد.

مثال :  فرض کنیم یک کاربر به عنوان [email protected] احراز هویت می شود . MongoDB برای اولین بار هر تغییری که در userToDNMapping مشخص شده باشد رااعمال می کند . بر اساس پیکربندی ارائه شده ، MongoDB نام کاربری را در هر مرحله رکورد کرده و یک درخواست LDAP را اجرا می کند:

DC=example,DC=com??sub?([email protected])

بر اساس کاربران پیکربندی شده اکتیو دایرکتوری ، سرور اکتیو دایرکتوری باید CN=alice,CN=Users,DC=engineering,DC=example,DC=com را بازگردد

سپس  MongoDB پرس و جو LDAP را در queryTemplate پیکربندی کرده و بوسیله نام کاربری جایگزین

USER} token} می کند

CN=alice,CN=Users,DC=engineering,DC=example,DC=com.

نکته مهم : اگر از پارامتر تعویض userToDNMapping برای تغییر نام گروه استفاده کنید ، نتیجه جایگزینی باید یک RFC4514 escaped باشد.

۱۰ . پیکر بندی پرس و جوی گواهی ها

MongoDB برای انجام پرس و جو در سرور اکتیو دایرکتوری نیاز به اعتبار دارد نظیمات زیر را در فایل تنظیمات پیکربندی کنید:

security.ldap.bind.queryUser : برای مشخص کردن کاربر Kerberos ، mongod یا mongos برای انجام پرس و جو در سرور اکتیو دایرکتوری متصل می شود.

security.ldap.bind.queryPassword : تعیین رمز عبور برای queryUser مشخص شده .

security:
 ldap:
  bind:
   queryUser: "[email protected]"
   queryPassword: "secret123"

در سرورهای Windows MongoDB می توانید security.ldap.bind.useOSDefaults را پیکربندی کنید تا از اعتبار کاربری OS به جای queryUser و queryPassword استفاده شود.

توجه داشته باشید queryUser باید مجوز انجام تمام درخواستهای LDAP را از طرف MongoDB داشته باشد.

۱۱ . اختیاری : افزودن تنظیمات پیکربندی اضافی

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

۱۲ . شروع استارت سرور MongoDB با تأیید اعتبار Kerberos و مجوز فعال دایرکتوری

با استفاده از گزینه  config – – سرور MongoDB را راه اندازی کنید  و مسیر فایل فشرده ایجاد شده در این روش را مشخص کنید. اگر سرور MongoDB در حال اجرا است ، جهت توقف سرور آماده سازی مناسب را انجام دهید.

سرورهای Linux MongoDB

در لینوکس ، باید متغیر محیطی KRB5_KTNAME را مشخص کرده و مسیر فایل keytab را برای سرور MongoDB مشخص کنید.

env KRB5_KTNAME <path-to-keytab> mongod --config <path-to-config-file>

سرویس مایکروسافت ویندوز MongoDB

در ویندوز،  سرور MongoDB را باید به عنوان حساب اصلی سرویس در پیکربندی اولیه شروع کنید:

mongod.exe --config <path-to-config-file>

۱۳ . اتصال به سرور MongoDB

فرآیند احراز هویت در اتصال به سرور MongoDB  می تواند به عنوان یک کاربر که عضو  مستقیم و یا پیوسته  گروه است انجام شود با یک نقش MongoDB در پایگاه داده مدیریت باکاربری UserAdminAnyDatabase

، که در این بین userAdmin  با امتیازات برابر مقایسه می شود .

در تنظیمات زیر از mongo shell برای تأیید اعتبار به سرور MongoDB استفاده می شود :

--host with the hostname of the MongoDB server

--port with the port of the MongoDB server

--username to the user’s userPrincipalName

--password to the user’s password

--authenticationMechanism to "GSSAPI"

--authenticationDatabase to "$external"

مثال : قبلا در این روش شما dn: CN = dba dn:CN=dba,CN=Users,DC=example,DC=com را در پایگاه داده مدیریت با مجوزهای لازم تنظیم کرده اید.  این نقش مربوط به گروه اکتیو دایرکتوری است و بر اساس کاربران پیکربندی شده در اکتیو دایرکتوری عمل می کند بنابراین می توانید به عنوان کاربر [email protected] احراز هویت کرده و مجوزهای لازم را دریافت کنید.

mongo --username [email protected] --password 'secret123' --authenticationMechanisms="GSSAPI" --authenticationDatabase "$external" --host <hostname> --port <port>

در نصب ویندوز MongoDB باید به جای mongo از mongo.exe استفاده شود و با توجه به کاربران پیکربندی شده در اکتیو دایرکتوری ، کاربر با موفقیت احراز هویت کرده و مجوز های مناسب را دریافت می کند.

نکته مهم : اگر میخواهید به عنوان یک کاربر غیر خارجی یا non-$external  احراز هویت را تأیید کنید ، مکانیزم احراز هویت را باید به مکانیزم SCRAM authentication تنظیم کنید

به عنوان مثال : SCRAM-SHA-1 or SCRAM-SHA-256

این امر مستلزم آن است که مکانیزم اعتبار سنجی SetParameter سرور MongoDB شامل SCRAM-SHA-1  و یا SCRAM-SHA-256  باشد .

۱۴ . ایجاد نقش هایی برای گروه های بازگشتی اکتیو دایرکتوری

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

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

DN CN=PrimaryApplication,CN=Users,DC=example,DC=com,

اختصاص دادن نقشها و امتیازات مناسب برای گروه :

db.getSiblingDB("admin").createRole(
 {
  role: "CN=PrimaryApplication,CN=Users,DC=example,DC=com",
  privileges: [],
  roles: [
   { role: "readWrite", db: "PrimaryApplication" }
  ]
 }
)

با توجه به گروه های پیکربندی شده در اکتیو دایرکتوری ، MongoDB تأیید هویت کاربر را به عنوان [email protected] یا [email protected] انجام داده و اعلان نقش readWrite را در پایگاه داده PrimaryApplication می دهد.

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

۱۵ . اختیاری : انتقال کاربران موجود از externalبه سرور اکتیو دایرکتوری

اگر نیاز به ارتقاء کاربران پیکربندی شده در پایگاه داده external$ را دارید ،  باید برای هر کاربر شرایط زیر را جهت حصول اطمینان از دسترسی پس از پیکربندی MongoDB جهت تأیید هویت Kerberos و مجوز های اکتیو دایرکتوری تضمین کنید:

  • کاربر دارای یک user object در سرور اکتیو دایرکتوری فعال است.

  • کاربر دارای عضویت در گروه های مناسب در سرور اکتیو دایرکتوری است.

  • MongoDB شامل نقش هایی در پایگاه داده مدیریت شده در user’s AD groups است . به طوری که کاربر مجاز امتیازات خود را حفظ می کند.

مثال : کاربر زیر در پایگاه داده external$ وجود دارد :

{
 user : "[email protected]",
 roles: [
  { role : "read", db : "web_analytics" },
  { role : "read", db : "PrimaryApplication" }
 ]
}

فرض بر این که کاربر متعلق به گروه اکتیو دایرکتوری است

CN=marketing,CN=Users,DC=example,DC=com,

عملیات زیر یک امتیاز تطبیقی با امتیازات مناسب ایجاد می کند :

db.getSiblingDB("admin").createRole(
 {
  role: "CN=marketing,CN=Users,DC=example,DC=com",
  privileges: [],
  roles: [
   { role: "read", db: "web_analytics" }
   { role: "read", db: "PrimaryApplication" }
  ]
 }
)

بر اساس queryTemplate پیکربندی شده ، MongoDB به هر کاربری که عضویت مستقیم یا پیوسته در CN=marketing,CN=Users,DC=example,DC=com است را احراز هویت می کند و برای انجام عملیات خواندن در پایگاه داده های web_analytics و PrimaryApplication مجاز می داند .

نکته مهم : هنگام تنظیم یک نقش برای یک گروه  مربوط به اکتیو دایرکتوری ، به یاد داشته باشید که تمام کاربران دارای عضویت در آن گروه می توانند نقش ها و امتیازات اختصاص داده شده را دریافت کنند. در هنگام پیکربندی نقش ها در دیتابیس MongoDB  در گروه های اکتیو دایرکتوری یا اعضای گروه ، از اصل حداقل نفوذ یا least privilege استفاده کنید.

اگر می خواهید همچنان به کاربران اجازه دسترسی به پایگاه داده های non-$external یا غیر خارجی را برای دسترسی به دیتابیس MongoDB بدهید ، توصیه می شود از از مکانیسم اعتبار سنجی SCRAM در پیکربندی خود استفاده کنید . مانند SCRAM-SHA-1 و / یا SCRAM-SHA-256 در گزینه تنظیمات مکانیسم احراز هویت setParameter .

setParameter:
  authenticationMechanisms: "GSSAPI,SCRAM-SHA-1,SCRAM-SHA-256"

بدین ترتیب با پیروی از روش فوق، یک انتقال غیرمستقیم به کاربران non-$external یا غیر خارجی در اکتیو دایرکتوری خود خواهید داشت .

روش فوق ، فایل پیکربندی زیر را تولید می کند :

security:
  authorization: "enabled"
  ldap:
   servers: activedirectory.example.net"
   bind:
    queryUser: "[email protected]"
    queryPassword: "secret123"
   userToDNMapping:
      '[
         {
           match: "(.+)"
           ldapQuery: "DC=example,DC=com??sub?(userPrincipalName={0})"
         }
      ]'
    authz:
       queryTemplate: "DC=example,DC=com??sub?(&(objectClass=group)(member:1.2.840.113556.1.4.1941:={USER}))"
setParameter:
  authenticationMechanisms: "GSSAPI"

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

 

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

سرفصل گام پنجم : مکانیزم احراز هویت LDAP Proxy 

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

 

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

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

۰۵

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

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

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

رکوردهای DNS

۱۹

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

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

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