افزودن قابلیت پویشگرایی به دایرکتوری سرور openldap

با افزایش حجم اطلاعاتی که باید ذخیره شود تا در اختیار بقیه قرار بگیرد و یا بعدا توسط خود سیستم پردازش شود ، نیاز به یک ساختار ساده تر و مفهومی تر برای ذخیره و دسته بندی اطلاعات است . ساختار مورد نظر همان ساختار سلسله مراتبی یا درختی می باشد که اطلاعات بر اساس تقسیم بندیهای جغرافیایی یا سازمانی یا هر معیار مناسب دیگری در آن قرار می گیرند . این ساختار در مقیاس بزرگ و برای حجم زیاد اطلاعات سرعت دسترسی بالایی را پدید می آورد که نتیجه آن ، استفاده از دایرکتوری ها در کنار پایگاه داده های رابطه ای می باشد . بدیهی است که دایرکتوریها باید به طور فیزیکی توزیع شوند تا هم کارایی سیستم بالاتر رود و هم اینکه قابلیت اطمینان اطلاعات برآورده شود . امروزه از دایرکتوری ها به عنوان انباری بزرگ ، جهت نگهداری انبوه اطلاعات به منظور اشتراک منابع و پردازشهای تکمیلی استفاده می شود . سرعت بالای دسترسی به اطلاعات و سادگی پیاده سازی آن باعث گسترش استفاده از آن در تمام زمینه ها شده است . با این حال این تکنولوژی نیز عاری از نقطه ضعف نبوده و با گسترش کاربرد آن در تمام زمینه ها ، این نقاط ضعف نمود بیشتری پیدا کرده و تلاش برای حل این نقاط ضعف نیز بیشتر شده است . یکی از برجسته ترین نقاط ضعف دایرکتوری ها ، مسئله تغییر اطلاعات و باخبر کردن کاربران از این تغییرات می باشد . به طور مثال اگر در سیستم دایرکتوری دانشگاه ، نمرات یک درس اعلام شود ، تغییر نمره و تغییر معدل هر کدام یک از دانشجویان باید به اطلاع آنها برسد . در بعضی از محیط ها ، سرعت مطلع کردن کاربران حیاتی بوده و در تصمیم گیری آنها عامل تعیین کننده می باشد. مثلا در محیطی مانند بورس ، تغییر قیمتها مهمترین عامل برای خرید یا فروش سهام می باشد و تاخیر در ارسال تغییرات می تواند موجب ضرر و شکایت کاربران قرار بگیرد . در محیط های معمولی مانند دانشگاه و مسئله اعلام نمره ، شاید سرعت مطلع کردن کاربران خیلی حیاتی به نظر نرسد و بتوان آنرا به عهده خود کاربران گذاشت به این ترتیب که کاربران در هر بازه زمانی مشخص ( مثلا روزی یکبار ) با ارسال درخواستی به سیستم دایرکتوری ، از وضعیت نمرات خود آگاه شوند . ولی در محیطی مانند بورس اگر قرار باشد هر کاربر در فاصله زمانی کوتاه ( هر 10 دقیقه ) تمام اطلاعات بورس را بازیابی کند مطمئنا سیستم با مشکل مواجه خواهد شد . البته بعضی ها معتقدند که در چنین محیط هایی بهتر است از سرویسهای دایرکتوری استفاده نکنیم . بعضی از روش های ارائه شده جهت حل این مسئله ، کاربران یا کلاینتها را وادار می کنند که خودشان با یک سرعت مراجعه مشخصی به سرورهای مورد نظر سرکشی کرده و درخواست خود را تحویل دهند ، سپس با پردازش جواب به دست آمده از تغییرات به وجود آمده مطلع شوند . بعضی روشها نیز یک سرور خاص را موظف به جمع آوری تغییرات رخ داده در سرور های دیگر می کند تا کلاینتها با مراجعه به فقط یک سرور از بروز تغییرات مطلع شوند و در صورت نیاز به اطلاعات کاملتر ، به سرور مبدا که تغییرات در آن رخ داده مراجعه کنند . بعضی دیگر ، سرور واسطه را موظف می کنند علاوه بر جمع آوری تغییرات ، موارد مورد نیاز کلاینت ها را برای آنها ارسال نمایند . به این منظور باید کلاینتها قبلا موارد مورد نیازشان را در سرور واسطه ثبت نمایند. در محیط های محاسباتی مبتنی بر گرید و همچنین محیط های محاسباتی منتشر شونده ، نیاز شدیدی به سرویس دایرکتوری کارا و مقیاس پذیر وجود دارد . در این محیط ها ، مطلع بودن کلاینتها از وضعیت اشیا و تغییرات آنها بسیار حیاتی بوده و گاه این تغییرات بایستی در حداقل زمان ممکن و با کمترین تاخیر به دست کلاینت برسد . این تغییرات ممکن است هرگونه تغییری باشد . تغییر مقدار خصوصیت یک شی یا مدخل ، اضافه شدن یا حذف یک خصوصیت از یک شی و یا اضافه شدن یک مدخل جدید ... . در بعضی محیط ها ، سرعت تغییر اطلاعات محدود بوده و حجم تغییرات قابل تحمل می باشد . مثلا در محیط دانشگاه فرکانس تغییرات کم است و یک نمره خاص یکبار در ترم تغییر می کند ( حداکثر دو بار ! ) ولی ممکن است یک دانشجو برای مطلع شدن از نمره خود بارها و بارها به سرور مراجعه کند ( افزایش بار شبکه ولی بدون نتیجه ) . در این نوع محیط ها بدیهی است که مطلع کردن کلاینت از تغییر مورد نیازش ، باعث کاهش شدید دسترسی های بی مورد می شود . حالا فرض کنید در محیطی مانند بورس ، تعداد کلاینتها بسیار و اشیا مورد نظر که تغییراتشان مهم می باشد نیز زیاد می باشد . مسئله اصلی آن است که تعداد تغییرات هر کدام از این اشیا نیز زیاد و غیر قابل پیش بینی می باشد . هر گونه تغییری نیز باید در سریعترین زمان و کمترین تاخیر به دست کلاینت مورد نظر برسد . شاید اولین راهی که به نظر برسد آن باشد که هرگونه تغییر به اطلاع تمام کلاینتها برسد ! این روش پهنای باند زیادی را بیهوده اشغال می کند ( بیهوده به این دلیل که خیلی از این تغییرات مورد نیاز خیلی از کلاینتها نیست ) و حتی کارایی کلاینتها را نیز کاهش می دهد زیرا آنها باید مدام در حال بررسی انبوه پیام های رسیده باشند تا تشخیص دهند که ، آیا تغییر مورد نظر به دردشان می خورد یا نه . در نتیجه دسته بندی کلاینتها بر اساس موارد مورد نیازشان و فیلتر کردن تغییرات قبل از ارسال آنها به کلاینتها ضروری به نظر می رسد. مسئله بعدی آن است که شاید نوع نیاز کلاینتها نیز در حال تغییر باشد . مثلا یک کلاینت نیاز خود را در سرور واسطه اینگونه تعریف کرده باشد : " تمام سهامی که در حال افزایش بیش از 3 درصد می باشند " . پس از مدتی کلاینت سهام مورد نیازش را یافته و خرید خود را انجام می دهد و سپس تصمیم می گیرد از سبد سهام خود ، موردی را که در حال کاهش ارزش است بفروشد . این تغییر نیاز باید در سرور ثبت شود . یعنی فیلترکردن تغییرات باید به صورت پویا انجام گیرد ، زیرا تغییر اطلاعات ممکن است خود باعث تغییر نیاز ها شود و این مسئله باید مورد پشتیبانی سیستم قرار بگیرد . در کنار این موضوع , مسئله دیگری وجود دارد که اهمیت ویژه ای دارد و آن بحث امنیت است . می توان به طور خلاصه این طور گفت که هدف از اِعمال سیاست های امنیتی عبارتند از حفظ محرمانگی اطلاعات ( حفظ حریم خصوصی کاربران ) ، حفظ سازگاری اطلاعات ( مخصوصا در محیط های توزیع شده ) و در دسترس نگه داشتن سیستم و جلوگیری از رفتارهای مخرب کاربران . سیستم openldap از نسخه 2.3 به بعد ، با تکنیکهای مختلفی این اهداف را برآورده کرده است . ارزش و اهمیت وجود امنیت در محیط های واقعی اطلاعاتی نظیر دانشگاه ، بورس ، بانک و ... واضح است و سیستمی که فاقد سیاست های امنیتی باشد ، در این محیط ها هیچ ارزشی ندارد . متاسفانه • سیستم pds که کاراترین سرویس دایرکتوری با قابلیت مطلع کردن کاربران از تغییرات می باشد هیچ چهارچوب امنیتی تعریف شده ندارد ! • همچنین سیستم openldap که پیاده سازی موفقی از سرویس دایرکتوری می باشد و کارایی و امنیت بسیار خوبی دارد ، هیچ مکانیزمی جهت مطلع کردن کاربران از تغییرات اطلاعات نداشته و حتی تکنیک جستجوی دائم ( که در بخش تاریخچه ، معرفی و نواقص و نقاط ضعفش بررسی می شود ) نیز در آن پیشتیبانی نمی شود . پروتکل dap که برای سیستمهایx.500 طراحی شده فوق العاده پیچیده بوده و مبتنی بر استاندارد شبکه osi می باشد، به همین دلیل با وجود تمام قدرت و ابزارش مورد استقبال قرار نگرفت و کنار گذاشته شد. موفقترین پروتکل برای دسترسی به اطلاعات درون یک فهرست ، پروتکل ldap می باشد که مبتنی بر tcp بوده و در محیط اینترنت قابل استفاده است . البته این پروتکل ، عملا پوششی ساده و سریع برای کار با سیستمهای x.500 می باشد . بدین معنی که سرور ldap واسطی بین کلاینتهای ldap و سرورهای x.500 می باشد( شکل 2 ) . [1][3][4][9][19] گرچه استفاده از سرور ldap به عنوان front-end ، تا حد زیادی از مشکلات سیستمهای x.500 را برطرف می کند ولی پیچیدگی ذاتی این سیستم و ناهمخوانی آن با پروتکل اینترنت همچنان لاینحل باقی می ماند . لذا در کنار این روش ، روش دیگری مطرح شده است که در آن ازیک سرور ldap متکی به خود به نام slapd استفاده می شود . این سرور تمام وظایف و اعمال یک سرورldap شرح داده شده در بالا را انجام می دهد، با این تفاوت که پشت قضیه دیگر از x.500 خبری نیست . openldap اولین پیاده سازی موفق کلاینت و سرور slapd می باشد که در سیستم عامل linux و دیگر سیستمهای عامل باز از آن به عنوان نرم افزار زیربنایی سرویس فهرست استفاده می شود. 4-1- روش جستجوی دائم یکی از ساده ترین روش های ارائه شده جهت مطلع کردن کاربران از تغییرات مورد نیازشان ، که کارایی نسبتا خوبی از خود نشان داده است ، روش جستجوی دائم ، پیشنهاد شده توسط smith et al. می باشد . این روش که توسعه ایی برای نسخه 3 پروتکل ldap است با افزودن دو کنترل جدید به تقاضای جستجو باعث می شود تا یک کلاینت بتواند گزارش تغییرات انجام شده در سرور مورد نظر را دریافت کند . مکانیزم این روش بسیار ساده بوده و طوری طراحی شده تا بتوان با اندک دستکاری در کد برنامه سرویس دایرکتوری ، آنرا فعال نمود . مکانیزم این روش به زبان ساده به این صورت است که وقتی درخواست کلاینتها به سرور می رسد ، به جای آنکه جواب آن درخواست ارسال و ارتباط قطع شود ، ارتباط همچنان برقرار می ماند تا کلاینت صریحا درخواست قطع اتصال کند و در این فاصله هر گونه تغییری در دایرکتوری که درخواست کلاینت را برآورده کند ، به کلاینت گزارش می شود . 4-2 روش پویشگرایانه مکانیزم این روش کمی پیچیده تر است ولی در عوض نیازها را به طور کاملتر و بهینه تر برطرف می کند . در این روش ، یک سرور واسطه موظف به ثبت درخواست مورد نظر کلاینتها می باشد . این سرور اشیاء مورد نظر را در بقیه سرور ها جستجو کرده و آنها را موظف می کند تا در صورت هرگونه تغییر ( در مقدار صفت ها ، خود صفت ها و یا حتی ورود شیء جدید به محیط یا حذف شیئی از آن محیط ) ، آن تغییرات را به سرور واسطه گزارش دهند . سرور واسطه با دریافت گزارش تغییرات ، آنها را بین کلاینتهای مقصد منتشر می کند. قبل از آنکه روش پویشگرا مطرح شود ، روش غیرفعال استفاده می شد. در روش غیر فعال ، کلاینتها ، خود با یک فرکانس مشخص به اشیاء مورد نظرشان مراجعه کرده و شرط را بررسی می کردند . پایین بودن کارایی و اشغال بیش از حد پهنای باند ، در این روش قابل پیش بینی است و در محیط های محدودی می توان از آن استفاده کرد . 4-2-1 فیلتر کردن گزارش ها جهت افزایش کارایی سیستم ، گزارش ها فیلتر می شوند . می توان این فیلتر را جزئی از پردازشی که قرار است در کلاینت انجام شود دانست . برای بیان فیلتر از زبان ecl که زیر مجموعه از زبان c می باشد استفاده شده است . البته می توان از خود زبان c و java را نیز استفاده نمود . شاید فیلتر کردن گزارش ها در مقصد یعنی توسط کلاینتها لازم و کافی به نظر برسد ، زیرا بعضی ها معتقدند موظف کردن سرور به فیلتر کردن گزارشات بار کاری زیادی بر دوش سرور قرار داده و کارایی آنرا کاهش می دهد . بر خلاف چنین نظری می توان با اطمینان گفت که اگر قرار باشد فیلتر کردن گزارش ها در کلاینتها انجام شود آنگاه سرور تمام گزارش ها را برای کلاینتها ارسال خواهد کرد و در نتیجه همین ارسال گزارشها ، هم بار پردازشی برای سرور و کلاینت به وجود می آید ، هم پهنای باند اشغال می شود و نهایتا اینکه آن فیلتر بالاخره باید اجرا شود ! ولی در این حالت روی کلاینت . به همین دلیل پیشنهاد می شود فیلتر کردن گزارشها بهتر است در سرور واسطه انجام شود . در چنین حالتی بار کاری سرور و کلاینتها کاهش می یابد . ارزیابی ها و مدلسازی ها صحت این ادعا را ثابت کرده اند . اگر گزارشات بدون فیلتر شدن در سرور به سمت کلاینتها گسیل شوند آنگاه ، کلاینتها خود را در انبوهی از گزارش های تغیرات می بینند که باید آنها را پردازش کنند و در صورت مطابقت با شرط عکس العمل مناسبی در مقابلشان ، نشان دهند . این روش ، بهبود فوق العاده ایی جهت کاهش بار کاری کلاینتها و سرور ها به وجود می آورد ، لیکن ، هیچ نوع سیاست امنیتی در آن دیده نشده و هیچ سطحی از امنیت در آن وجود ندارد. لذا سیستم pds ، برای کار در محیط های واقعی نظیر بورس که حریم خصوصی اطلاعات افراد بایستی حفظ شود ، دسترسی هر گروه از کاربران باید محدود به اعمال مشخصی باشد و کاربران نتوانند با ایجاد تغییرات کاذب و زیاد سیستم را از دسترس خارج نمایند ، قابل استفاده نبوده و فعلا در سطح یک سیستم آزمایشی مطرح شده است . از طرفی سیستم openldap ، که یک سرویس دایرکتوری موفق از نظر کارایی و امنیت می باشد به طوریکه اکثر نیاز های امنیتی یک محیط واقعی را پیاده سازی کرده ، هیچ قابلیتی جهت مطلع کردن کاربران از تغییرات انجام شده روی اشیا و اطلاعات مورد علاقه آنها ندارد و حتی تکنیک جستجوی دائم ، با تمام نواقص و نقاط ضعفش هم در نسخه های جدید پشتیبانی نشده است . متاسفانه تا به امروز ، هیچ سرویس دایرکتوری که کارایی ، امنیت و پویشگرایی را همزمان داشته باشد طراحی و پیاده سازی نشده است . هدف از این تحقیق ، اضافه نمودن سرویس دایرکتوری پویشگرا به معماری سیستم openldap می باشد.