در مقالات قبلی در خصوص موجودیت Certificate ها و محل استفاده از آنها و همچنین طراحی ساختار سلسله مراتبی PKI و نیازمندی ها و چالش های موجود در آن صحبت کردیم، در این مقاله قصد داریم به شما روش ایجاد یک طرح مدیریتی CA را نمایش دهیم. قبل از اینکه شما هرگونه Certificate را بخواهید صادر کنید بایستی دارای یک طرح باشید که در آن چگونگی صدور Certificate، تازه سازی یا Renew کردن Certificate و همچنین روش ابطال Certificate تشریح شده باشد.
مقاله: طراحی و معماری زیرساخت کلید عمومی یا PKI قسمت اول
مقاله: طراحی و معماری زیرساخت کلید عمومی یا PKI قسمت دوم
مقاله: طراحی و معماری زیرساخت کلید عمومی یا PKI قسمت سوم
ایجاد یک طرح مدیریت Certificate
انتخاب یک روش ثبت نام یا Enrollment برای Certificate
برای فعال سازی قابلیت Enrollment شما نیازمند به تعیین یک فرآیند برای ثبت نام و Renew کردن Certificate ها هستید. فرآیند Enrollment شامل تعیین سطول دسترسی برای شخصی است که قرار است به Template های موجود دسترسی Enroll داشته باشد ( البته در زمانی که شما از Enterprise CA ها استفاده می کنید ) یا تعیین کردن شخصی به عنوان مدیر Certificate ها برای مرور هر درخواست Certificate و صدور یا رد درخواست با توجه اطلاعاتی است که هنگام ثبت نام وارد کرده است، می باشد. AD CS از قابلیت های پردازش درخواست های صدور Certificate بصورت دستی پشتیبانی می کند، این زمانی است که برای صدور Certificate نیاز به داشتن تاییدیه مدیریتی می باشد و بایستی فرآیند بصورت دستی انجام شود.
موارد زیر از روش های انجام فرآیند Renewal و Enrollment هستند:
Certificate autoenrollment and renewal: با استفاده از این قابلیت شما قادر خواهید بود برای User ها و Computer هایی که در محیط اکتیودایرکتوری قرار دارند و سرویس های مورد استفاده آنها مانند مانند smart card logon SSL EFS و SMIME بصورت خودکار Certificate صادر کنید. قابلیت Autoenrollment ترکیبی از تنظیمات Group Policy و Certificate Template ها می باشد که این قابلیت را به شما و کاربران دامین شما می دهد که بتوانند بصورت خودکار Certificate دریافت کنند. برای استفاده از قابلیت autoenrollment شما به یک دامین کنترلر ویندوز سرور به عنوان سرور نیاز دارید و از طرفی به کلاینت هایی با سیستم عامل ویندوز XP سرویس پک 3 و بالاتر از آن در شبکه نیاز دارید، Autoenrollmetn همانطور که چندین بار تکرار شده است صرفا در محیط Enterprise CA موجود است.
Certificate Request Wizard and Certificate Renewal Wizard: این ویزارد از طریق کنسول Certificates در MMC قابل دسترس می باشد. با استفاده از کنسول فوق شما می توانید درخواست های Certificate خود برای صدور User یا Computer و یا Service را برای یک Enterprise CA ارسال کنید. در صورت مراجعه مجدد به این کنسول می توانید برای Renew کرده Certificate اقدام کنید.
Web Enrollment Support: این یکی از قابلیت هایی است که در ویندوز سرور 2000 معرفی شد و تا کنون به قوت خود باقی مانده است. با استفاده از این قابلیت شما می توانید برای User ها و Computer ها و سرویس های خود از طریق وب درخواست های خود را برای CA ارسال کنید. دلیل وجود چنین امکانی، ارائه مکانیزمی برای سازمان هایی که نیاز به صدور و Renew کردن Certificate های User ها و Computer هایی است که در عضویت Domain نیستند و یا اینکه بصورت مستقیم به شبکه متصل نشده اند، همچنین کاربرانی که از سیستم عامل های غیرمایکروسافتی استفاده می کنند از این نوع Enrollment می توانند استفاده کنند. Web Enrollment قابلیت استفاده هم از طریق Internet و هم از طریق Intranet را دارد.
Network Device Enrollment Service: روش NDES یک پیاده سازی مایکروسافتی از مکانیزمی به نام SCEP می باشد. SCEP یک پروتکل ارتباطی PKI است که به نرم افزارهایی که تحت شبکه و در قالب دستگاه های شبکه ای فعالیت می کنند مانند روترها و سویچ ها که امکان احراز هویت در شبکه را ندارند، امکان دریافت X.509 Certificate را از CA می دهد.
خوب روش های مورد استفاده جهت انجام فرآیند های Enrollment و Renewal مربوط به Certificate ها را معرفی کردیم اما برای اینکه بتوانید از میان این روش ها یکی را برای سازمان خود انتخاب کنید که نیازهای شما را برطرف کند بایستی به نکات و موارد زیر توجه کنید:
به User ها، Computer ها، دستگاه ها و سرویس ها توجه کنید. توجه کنید که اینها در خارج از سازمان هستند یا در درون سازمان مشغول به کار هستند. سیستم عامل های مورد استفاده توسط آنها را شناسایی کنید و به این نکته بصورت ویژه توجه کنید که آیا این سیستم عامل ها توانایی برقراری ارتباط با Active Directory را دارند یا خیر. به Policy یا خط مشیی که برای مدیریت توزیع Certificate ها وجود دارد توجه کنید. این مورد شامل دستورالعمل هایی است که شما برای PKI خود توسط تنظیمات Group Policy اعمال می کنید.
لازمه انتخاب یک روش درست برای فرآیند Certificate Enrollment و Renewal شامل تصمیم گیری در خصوص موارد زیر نیز می باشد:
- فرآیند درخوسات خودکار باشد یا بصورت دستی انجام شود ؟
- فرآیند تایید درخوسات خودکار باشد یا بصورت دستی انجام شود ؟
- از چه رابطی یا Interface ای برای فرآیند Enrollment و Renewal استفاده شود ؟
- فرآیند Renewal مربوط به CA چگونه انجام شود ؟
مقایسه انتخاب روش خودکار با روش دستی درخواست Certificate
بسته به تعداد و نوع Certificate ای که شما می خواهید از آن استفاده کنید شما می توانید از روش تولید درخواست ها بصورت خودکار یا بصورت دستی استفاده کنید. برای مثال اگر می خواهید تمامی User ها و Computer های موجود در شبکه از یک نوع مشخص از Certificate استفاده کنند، این کار منطقی نیست که برای هر یک از آنها وقت گذاشته و درخواست را بصورت دستی ایجاد کنید. همچنین توجه کنید که ایجاد Certificate بصورت گروهی و برای تمامی افرادی که در سازمان وجود دارند به شکل یکباره، ترافیک زیادی را می تواند در شبکه ایجاد کند، شما بایستی توجه کنید که در این حالت برای هر یک از OU های خود و Object های درون آن به صورت جداگانه درخواست Certificate دهید.
از طرفی دیگر ممکن است شما User ها یا Administrator هایی داشته باشید که درخواست Certificate هایی با سطوح امنیتی بسیار بالا را داشته باشند، برای مثال می خواهند در امضاهای دیجیتال از آن استفاده کنند و یا فعالیت های مدیریتی انجام دهند. در اینجاست که حتما بایستی نظارت مدیریتی بر روی Certificate ها وجود داشته باشد، زیرا حساسیت کار به گونه ای است که نیازمند نظارت می باشد.
شما می توانید کنترل خود بر روی Certificate ها را با استفاده از محدود کردن استفاده از User Certificate ها به روش های زیر انجام دهید:
محدود کردن Enrollment Agent: در ویندوز سرور 2008 به بعد نسخه Enterprise و نسخه Datacenter یا سازمان ها می توان تنظیماتی انجام داد که enrollment agent موجود فقط به یک سری از گروه کاربران خاص Certificate بدهند. امکانات محدود سازی یا Restriction برای Agent ها باعث می شوند شما بتوانید از تعداد بیشتری از Certificate Template ها استفاده کنید. برای هر یک از Certificate Template ها شما می توانید تاعیین کنید که چه گروه یا کاربر خاصی از طرف Enrollment Agent میتواند برای آن Certificate درخواست شود. این قابلیت در CA های ویندوز سرور 2008 نسخه Standard وجود ندارد.
محدود کردن دسترسی به Certificate Template های خاص: برای Certificate Template های موجود سطوح دسترسی را به گونه ای تعیین کنید که صرفا کاربرانی که مجاز هستند دسترسی Enroll و Read به Template ها را داشته باشند، اینگونه سطوح دسترسی در اصطلاح Discretionary Access Control یا DAC نامیده می شود.
خودکار سازی فرآیند گسترش computer certificate ها: با استفاده از تنظیمات Group Policy و به وسیله اضافه کردن Certificate Template مورد نظرتان به قسمت Automatic Certificate Request Settings کاری کنید که Computer Certificate ها براحتی واگذار و گسترش پیدا کنند.
مقایسه روش خودکار و روش دستی تایید Certificate
کاربران می توانند هم بصورت خودکار و هم بصورت دستی به CA ویندوز سرور درخواست Certificate بدهند. این درخواست در حالتی که بصورت دستی باشد تا زمانیکه مدیر CA آنرا تایید نکند در صف انتظار یا Pending باقی می ماند. زمانیکه درخواست Certificate تایید شد، فرآیند autoenrollment بصورت خودکار Certificate صادر شده را به جای کاربر درخواست دهنده و بر اساس Certificate Template تعیین شده نصب می کند، همچنین فرآیند تازه سازی یا Renewal نیز به همین روش انجام می شود. در بیشتر اوقات شما همان فرآیندی که برای درخوسات Certificate انتخاب می کنید را برای تایید Certificate نیز بکار می برید. بهرحال در حالت هایی استثناء هم وجود دارد. برای مثال، اگر شما بر روی Group Policy و Certificate Template مورد نظر محدودیت های دسترسی دارید، می توانید برای سرور تعیین کنید که درخواست هایی که بصورت دستی صادر شده اند را بصورت خودکار تایید کند. اما توجه کنید که برخی اوقات پیش می آید که شما Certificate هایی که بصورت خودکار درخواست شده اند را بایستی بصورت دستی تایید کنید. بهرحال در حالت معمول برای Certificate هایی که روزمره هستند و یا بسیار زیاد مورد استفاده قرار می گیرند، مثال برای Email-Certificates فرآیند تایید خودکار با توجه به اینکه کاربر درخواست دهنده Certificate قبلا توسط ساختار اکتیودایرکتوری احراز هویت شده است، می تواند بهترین گزینه باشد. زمانیکه دقت و ظرافت خاصی و همچنین کاربردهای ویژه ای برای Certificate ها مد نظر است، مثلا شما برای Code Signing نیاز به داشتن Certificate دارید، در اینجا حتما درخواست ها بصورت دستی و با نظارت مدیر CA انجام شود بهتر است. با استفاده از کنسول و ویزارد Certificate Request wizard شما می توانید هر Certificate را بصورت جداگانه ارزیابی کنید و یا مسئولیت نظارت بر تایید آن را به یک مدیر دیگر محول کنید.
انتخاب رابط کاربری فرآیند Enrollment و Renewal مربوط به Certificate
انتخاب رابط کاربری برای فرآیند پردازش درخواست و تایید Certificate بستگی به این دارد که شما از روش خودکار یا دستی برای ارسال درخواست و تایید Certificate استفاده می کنید. اگر از قابلیت autoenrollment برای هم درخواست و هم تایید Certificate استفاده می کنید شما بایستی از ساده ترین رابط کاربری استفاده کنید. بهرحال اگر همه یا قسمتی از فرآیند enrollment بصورت دستی انجام می شود، شما بایستی بین دو رابط کاربری Web Enrollment و Certificate Request Wizard یکی را انتخاب کنید. رابط کاربری تحت وب یا Web Enrollment برای کاربران نسبتا کاربرد ساده تری دارد، کاربران براحتی می توانند کارهای زیر را با استفاده از صفحه وب Web Enrollment انجام دهند:
- درخواست و دریافت یک User Certificate ساده
- درخواست و دریافت انواع Certificate های دیگر با استفاده از Advanced Options
- درخواست یک Certificate با استفاده از فایل درخواست Certificate
- Renew کردن Certificate با استفاده از فایل درخواست Renew کردن Certificate
- ذخیره کرده درخواست Certificate در قالب یک فایل
- ذخیره کردن Certificate صادر شده در قالب فایل
- بررسی درخواست های معلق Certificate در سرور CA
- دریافت Certificate یک CA
- درخواست لیست آخرین Certificate های باطل شده یا CRL از CA
- درخواست کردن Certificate برای Smart Card ها به جای سایر کاربران (فقط برای مدیران دارای مجوز)
بهرحال مدیران ممکن است دوست داشته باشند از ویزارد های Certificate Request Wizard و Certificate Renewal Wizard برای Request و Renewal مربوط به Certificate ها استفاده کنند. برای دسترسی به این ویزارد بایستی وارد کنسول MMC شده و Snap-In مورد نظر را اضافه کنید، به دلیل اینکه این ویزارد به Certificate Snap-In لینک شده است شما می توانید یک صفحه دلخواه Snap-In درست کرده و آن را برای مدیران CA ای که برایشان وظایف تعریف شده است، توزیع کنید. تا زمانیکه در بین قسمت های سازمانی شما فایروالی وجود نداشته باشد که ترافیک را محدود کند، شما هم می توانید از Web Enrollment و هم می توانید از Certificate Snap-In استفاده کنید، اما اگر در این میان یک فایروال وجود داشته باشد، البته منظور از در این میان ارتباط بین کلاینت و CA می باشد، شما بایستی پورت های 80 و 443 و همچنین 135 و پورت های Dynamic بالای 1024 را که سرویس های وب و MMC از آنها استفاده می کنند را بر روی فایروال باز کنید تا ارتباطات DCOM و HTTP و HTTPS بتوانند براحتی انجام شوند.
چه از Web Enrollment استفاده کنید و یا از Certificate Request Wizard یا Certificate Renewal Wizard بایستی برای این فرآیند درخواست Certificate مستندات لازم را آماده کنید، در این مستندات بایست روش درخواست Certificate توسط کاربران تشریح شده باشد، برای مثال چه چیزهایی را بایستی کاربر بعد از ارسال درخواست خود به CA برای صدور Certificate باید بداند؟ آیا بایستی منتظر صدور آنی Certificate با استفاده از autoenrollment باشد و یا اینکه بایستی منتظر بماند تا مدیر CA به درخواست وی ترتیب اثر دهد؟ همچنین چگونگی استفاده کاربر از Certificate بعد از صدور آن نیز بایستی در این مستند آورده شده باشد.
درخواست صدور مجدد Certificate برای CA
زمانیکه Certificate یک CA منقضی می شود، CA دیگر قادر به ارائه سرویس نخواهد بود. برای اینکه بتوانید براحتی و بدون وارد شدن خلل در کار CA سرویس ارائه دهید، قبل از اینکه Certificate مربوط به CA منقضی شود بایستی آن را تمدید کنید، اینکار را می توانید از طریق کنسول Certificates انجام دهید. وهله های زمانی که شما بایستی Certificate مربوط به CA خود را Renew کنید بستگی به lifetime ای دارد که برای CA تعیین کرده اید. بعد از اینکه یک CA را Renew کردید، CA می تواند با استفاده از Certificate جدید صادر شده به کار خود ادامه دهد و چرخه به همین شکل ادامه پیدا می کند. Certificate قبلی که برای CA صادر شده بود و هنوز به تاریخ انقضاء آن نرسیده ایم همچنان قابل اعتماد بوده و می توان از آن تا زمان منقضی شدن استفاده کرد. می توانید برای اطمینان بیشتر این Certificate قبلی را بصورت دستی منقضی کنید و یا آن را باطل کنید. شما می توانید از روش های استانداردی که برای فرآیند Enrollment در ویندوز سرور تعیین شده است برای Renew کردن Certificate مربوط به CA نیز استفاده کنید. شما می توانید در فرآیند Renew کردن از همان کلید خصوصی و عمومی قبلی استفاده کنید و یا جفت کلید جدیدی ایجاد کنید. بهرحال اگر شما نیازمندی های خاصی دارید، می توانید نرم افزارهای خاصی به منظور انجام فرآیند های Enrollment و Renewal بصورت برنامه نویسی شده ایجاد کنید و از آنها با استاندارد خاص خود استفاده کنید.
ایجاد یک استراتژی برای فرآیند Renewal کردن Certificate مربوط به CA
Certificate Lifetime یا زمان حیات یک Certificate به دلایل زیر تاثیر مستقیمی بر روی امنیت ساختار PKI شما دارد:
پس از گذشت زمان، کلید های رمزنگاری در مقابل حملاتی که آنها انجام می شود آسیب پذیری بیشتری از خود نشان می دهند. معمولا هر چقدر مدت زمان استفاده از یک کلید طولانی تر شود، احتمال شکسته شدن و دستکاری شدن کلید آن نیز بیشتر خواهد شد. برای کاهش این ریسک، شما می توانید کلید های مربوط به CA ها را در وهله های زمانی، قبل از تاریخ انقضاء آنها تعویض کنید تا احتمال بروز مشکل و دستکاری شدن آنها کاهش یابد. توجه کنید که حتما نبایستی تاریخ انقضاء به انتهای خود برسد تا به فکر Renew کردن Certificate بیافتیم. زمانیکه Certificate یک CA منقضی شد، تمامی Subordinate CA هایی که در زیرمجموعه زنجیره اعتماد این CA قرار داشته اند نیز منقضی خواهند شد. این فرآیند به عنوان Time Nesting شناخته می شود. زمانیکه Certificate یک CA باطل می شود، تمامی Certificate هایی که توسط این CA صادر شده اند نیز بایستی مجددا صادر شوند و باطل محسوب می شوند. Certificate هایی که در نهایت برای کارهای کاربردی صادر می شوند در زمانیکه Certificate مربوط به Issuing CA منقضی می شود به عمر خود پایان می دهند، مگر اینکه Certificate مجددا Renew شود و یک جفت کلید جدید با lifetime طولانی تر نسبت به جفت کلید قبلی صادر شود. شما بایستی طرح Renewal کردن Certificate مربوط به CA ها را در فاز اولیه طراحی PKI خود انجام دهید. اگر این قسمت بسیار مهم از طراحی جا بیافتد، ممکن است کل ساختار PKI شما به یکباره از کار افتاده و دیگر قادر به سرویس دهی نباشد، دلیل این امر کاملا مشخص است زیرا تمامی Certificate های صادر شده بر پایه و اساس Certificate ای هستند که در CA وجود دارد و در صورت از بین رفتن یا باطل شدن این Certificate دیگر سایر Certificate ها قادر به انجام فرآیند رمزنگاری و رمزگشایی نخواهند بود. نکته جالب در اینجاست که شما نیز به خاطر باید داشته باشید، Certificate های باطل شده و یا منقضی شده همچنان می توانند برای رمزگشایی اطلاعات مورد استفاده قرار بگیرند.
تعریف یک خط مشی باطل سازی یا Revocation Policy
شما بایستی برای سازمان خود و ساختار PKI یک خط مشی باطل سازی یا Revocation Policy داشته باشید که در آن تمامی شرایطی که در آنها یک Certificate باطل می شود را به دقت تشریح کرده باشد. در این خط مشی باطل سازی، بایستی ضمن اینکه شرایط باطل سازی به دقت تشریح می شود، افرادی که می توانند Certificate ها را باطل کنند، روشی که بایستی Certificate ها را باطل کنند و در نهایت روشی که اطلاعات مربوط به باطل سازی Certificate ها بین PKI کلاینت ها توزیع شود را به دقت توضیح می دهند. معمول ترین روشی که توسط آن وضعیت Certificate ها اطلاع رسانی می شود، توزیع لیستی از Certificate های باطل شده بین کلاینت ها می باشد که به CRL یا Certificate Revocation List معروف است. در ساختار PKI ویندوز سرور که استفاده از راهکار توزیع سنتی CRL ها مرسوم نیست، از یک فرآیند آنلاین به نام OCSP برای مدیریت و توزیع وضعیت Certificate های باطل شده استفاده می شود. در ادامه در خصوص OCSP بیشتر صحبت خواهیم کرد.
لیست Certificate های باطل شده یا Certificate Revocation List
در برخی مواقع پیش می آید که CA باید Certificate صادر شده را قبلا از تاریخ انقضای آن باطل کند. زمانیکه یک Certificate باطل می شود، CA یک شماره سریال از Certificate و همچنین دلیل باطل کردن Certificate را در درون CRL قرار می دهد. ویندوز سرور از دو نوع CRL به نامهای Base CRL و Delta CRL پشتیبانی می کند.
یک Base CRL شامل لیستی از Certificate های باطل شده ای است که با خود CA مرتبط هستند و همچنین دلیل باطل شدن Certificate نیز در Base CRL آورده می شود. تمامی Certificate هایی که به دلیل تمام شدن مدت اعتبار آنها باطل شده اند توسط کلید خصوص خود CA امضا یا Sign می شوند. زمانیکه Certificate خود CA تازه سازی یا Renew شد و یک جفت کلید جدید دریافت کرد، یک Base CRL جدید ایجاد می شود که صرفا شامل Certificate های باطل شده ای است که دارای Sign خود CA می باشند.
یک Delta CRL صرفا شامل لیستی از شماره سریال و دلیل باطل شدن Certificate ها از آخرین باری است که یک Base CRL منتشر شده است. Delta CRL زمانی پیاده سازی می شود که می خواهیم مدت زمان دانلود CRL را کاهش دهیم و یا سرعت باطل شدن Certificate ها در CA را بالا ببریم. زمانیکه یک Base CRL منتشر می شود، Certificate های باطل شده ای که در Delta CRL وجود دارند به Base CRL اضافه می شوند Delta CRL بعدی صرفا شامل Certificate های باطل شده ای است که از بعد از منتشر شدن Base CRL باطل شده اند، به نوعی اگر با فایل های Backup کار کرده باشید Base CRL ها به شکل Normal Backup و Delta CRL ها به شکل Incremental Backup می باشند. حجم اطلاعات موجود در Delta CRL کمتر از حجم اطلاعات موجود در Base CRL ها می باشد، Base CRL ها معمولا در وهله های زمانی طولانی تری دانلود می شوند.
نکته: Delta CRL ها بدون وجود Base CRL ها کار نمی کنند . اگر شما Delta CRL را پیاده سازی کرده اید، عناصر مرتبط با CA حتما Base CRL را باید دانلود کنند. همیشه و بدون شک ترکیب Base CRL و Delta CRL می باشد که اطلاعات کاملی در خصوص Certificate های باطل شده در اختیار کاربران قرار می دهد.
نکته مهم: Delta CRL ها همیشه و در همه جا پشتیبانی نمی شوند. تمامی عناصر مرتبط با CA و ساختار PKI از Delta CRL ها پشتیبانی نمی کنند، اگر یکی از عناصر مرتبط از Delta CRL پشتیبانی نکند، صرفا از طریق Base CRL ها قادر خواهد بود اطلاعات مربوط به Certificate های باطل شده را دریافت کند.
مشکلات مربوط به CRL ها
CRL ها بصورت سنتی به عنوان اصلی ترین روش برای تعیین وضعیت ابطال Certificate ها مورد استفاده قرار گرفته اند. همچنین استفاده از CRL ها بصورت گسترده ای مورد پشتیبانی می باشد، اما چندین نکته در مورد اشکالات استفاده صرف از CRL ها وجود دارد که ممکن است برای بررسی وضعیت ابطال Certificate ها شما را دچار مشکل کند:
تاخیر: بزرگترین مشکلی که با CRL ها وجود دارد در این است که در شناسایی Certificate های باطل شده تاخیر دارند. بعد از اینکه شما یک Certificate را باطل کردید، عناصر درگیر در ساختار PKI تا زمانیکه انتشار بعدی از CRL دریافت نکنند نمی توانند Certificate های جدید باطل شده را شناسایی کنند. دسترسی پذیری در اینجا بستگی به زمانبندی انتشار CRL ها دارد. برای مثال اگر شما یک Base CRL را بصورت روزانه در ساعت 7 صبح منتشر کنید و یک Certificate در ساعت 8 صبح باطل شود، عناصر درگیر در PKI تا زمانیکه در روز بعد Base CRL جدید منتشر نشود قادر به شناسایی ابطال Certificate صادر شده نخواهند بود.
کش کردن CRL ها: زمانیکه یک کامپیوتر کلاینت وضعیت ابطال یک Certificate را بررسی می کند، اولین کاری که می کند اطلاعات Base CRL و Delta CRL موجود در کش CryptoAPI را بررسی می کند. اگر توانست Base CRL و Delta CRL را بیابد، سپس به بررسی زمان اعتبار یا time-valid مربوط به CRL می پردازد. همانند Certificate ها، CRL ها نیز در درون خود یک دوره اعتبار تعریف شده دارند که در هر باز انتشار CRL به آن اضافه می شود، اگر یک CRL دارای اعتبار زمانی درست در کش CryptoAPI پیدا شود، همان نسخه از CRL برای بررسی وضعیت ابطال Certificate ها مورد استفاده قرار می گیرد، حتی اگر نسخه بروز شده بصورت دستی منتشر شده باشد. استفاده از نسخه کش شده CRL برای بالا بردن کارایی سیستم مورد استفاده قرار می گیرد تا ترافیک شبکه برای دریافت CRL بالا نرود. علاوه بر این استفاده از CRL های کش شده جزئی از پیشنهاداتی است که در RFC 3280 به نام Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile وجود دارد. در این RFC استفاده از CRL های کش شده ای که زمان اعتبار آنها باقی است پیشنهاد می شود.
پروتکل وضعیت Certificate آنلاین یا Online Certificate Status Protocol OCSP
در ویندوز سرور 2008 یک روش جایگزین برای CRL ها برای شناسایی Certificate های باطل شده بصورت بلادرنگ در شبکه معرفی شد. غیر از اینکه یک کلاینت Base CRL ها و Delta CRL ها را دانلود می کند، کلاینت که در اینجا به آن OSCP Client گفته می شود یک درخواست تحت وب برای سرور که در اینجا به آن OCSP Responder می گوییم ارسال می کند. کلاینت در این مرحله بایستی هویت اصلی سرور را تشخیص دهد و اینکار را با استفاده از بررسی AIA یا Authority Information Access ای که در URL موجود در OCSP Responder وجود دارد انجام می دهد، اگر این اطلاعات صحت داشت و کلاینت با OCSP Responder درستی ارتباط برقرار کرده بود و همچنین کلاینت از این OCSP Responder پشتیبانی می کرد، سپس کلاینت با ارسال یک درخواست OCSP به سرور ادامه فعالیتش را انجام می دهد.
نکته: OCSP یک سرویس جدید در ویندوز سرور 2008 می باشد. OCSP در نسخه قبلی ویندوز سرور که 2003 می باشد وجود نداشت. قبل از معرفی ویندوز سرور 2008 شما می بایستی از OCSP های Third-Party برای کار خود در CA های مایکروسافتی استفاده می کردید.
برخلاف CRL ها که بصورت دوره ای توزیع و منتشر می شوند و حاوی تمامی اطلاعات در خصوص Certificate های باطل شده و معلق شده می باشند، یک Online Responder یا OCSP صرفا به درخواست کلاینت مربوط به اطلاعات وضعیت یک Certificate خاص را که پاسخگویی می کند. Responder با CA ای که Certificate را صادر کرده است ارتباط برقرار کرده و وضعیت آن Certificate خاص را دریافت کرده و به اطلاع کلاینت می رساند. OCSP Responder می تواند بصورت مستقیم با CA ارتباط برقرار کند یا اینکه اطلاعات مربوط به Certificate را از طریق CRL ای که توسط CA منتشر شده است بررسی و گزارش کند. مزیت OCSP در این است که اطلاعات بروزتری نسبت به CRL هایی که برای کلاینت ها ارسال می شود دریافت می کند. بهرحال OCSP هم برای خود مضرت هایی نیز دارد. یکی از مهمترین اشکالاتی که به OCSP وارد است، این است که در محیط هایی که درخواست های کلاینت ها بسیار زیاد است OCSP بار کاری زیادی را باید تحمل کند که باعث بروز مشکلاتی در این خصوص خواهد شد. به همین دلیل بهتر است که طراحی و پیاده سازی ساختار OCSP شما در یک محیط دارای Load Balancing و Clustering انجام شود تا بتواند بار کاری را در بین چندین سرور تقسیم کرد. یکی دیگر از مضرت های OCSP این است که پیاده سازی آنها دشوارتر از پیاده سازی CRL می باشد. در نهایت یکی از محدودیت های دیگر OCSP این است که صرفا در سیستم عامل های ویندوز ویستا و ویندوز سرور 2008 به بعد پشتیبانی می شود. زمانیکه شما برای طراحی ساختار اعتبارسنجی و بررسی ابطال Certificate های خود برنامه ریزی می کنید، اگر بررسی اعتبار Certificate ها از نظر زمانی اعتبار جزو اولویت های شما می باشد و بار کاری جزو اولویت های پایین شما می باشد، استفاده از OCSP به جای CRL ها توصیه می شود. برای پیاده سازی های بزرگ PKI که در محیط های عمومی مثل اینترنت نیز کاربرد دارند استفاده از CRL ها پیشنهاد می شود.
تعیین نقاط انتشار
آخرین نیازمندی فنی که شما بایستی در طراحی خود در نظر داشته باشید، تعیین نقاط انتشار یا Publishing Point ها می باشد. چه شما از ساختار CRL و CA Certificates استفاده کنید و یا اگر پیاده سازی از CRL Checking داشته باشید، یا از ساختار OCSP استفاده کرده باشید در نهایت شما بایستی این نقاط را در طراحی خود دیده باشید. یک PKI Client برای تعیین وضعیت ابطال یک Certificate می تواند از URL هایی که در CRL Distribution Point یا CDP (اگر CRL Checking استفاده می شود) و AIA (اگر OCSP استفاده می شود) استفاده کند. در هر CA در سلسله مراتب شما بایستی یک تعداد نقاط انتشار یا Publication Point برای CA ای که Certificate ها را صادر کرده است در نظر بگیرید. این نقاظ انتشار به شما اجازه می دهند که بتوانید به Certificate مربوط به CA و CRL های آن دسترسی پیدا کنید، شما می توانید با استفاده از پروتکل های زیر این نقاط انتشار را تعریف کنید:
Hypertext Transfer Protocol یا HTTP: آدرس های URL پروتکل HTTP همی می تواند برای استفاده داخلی و هم استفاده خارجی در نقاط انتشار مورد استفاده قرار بگیرد. مهمترین مزیت استفاده از آدرس های URL پروتکل HTTP این است که مدت زمان میان انتشار و در دسترس بودن اطلاعات بسیار پایین است. بعد از اینکه شما یک Update از CRL یا Certificate مربوط به CA را در یک آدرس URL پروتکل HTTP منتشر کردید، این Update بلافاصله برای نرم افزارهای کاربردی و سرویس هایی که از PKI استفاده می کنند قابل دسترس خواهد بود. علاوه بر این HTTP URL ها را می توان در پشت فایروال ها و همچنین کلاینت هایی که از اکتیودایرکتوری استفاده نمی کنند نیز مورد استفاده قرار داد. حتی سیستم عامل های قدیمی نیز قادر به استفاده از این امکان می باشند.
Lightweight Directory Access Protocol یا LDAP: بصورت پیشفرض زمانیکه شما یک CA Certificate را در درون یک آدرس URL پروتکل LDAP منتشر می کنید، این اطلاعات در Configuration Database اکتیودایرکتوری ذخیره می شوند و این بدین معناست که اطلاعات مربوط به CRL و Certificate مربوط به CA بر روی تمامی Domain Controller های موجود در مجموعه Forest وجود خواهند داشت.
نکته: پروتکل LDAP صرفا برای استفاده در اکتیودایرکتوری نمی باشد و شما می توانید به جای اینکه بصورت پیشفرض CRL و CA Certificate را در درون Active Directory منتشر کنید از سرویس های دایرکتوری دیگر مانند Active Directory Lightweight Directory Services یا ADLDS استفاده کنید.
دو اشکال یا بهتر بگوییم مضرت در استفاده از آدرسهای URL پیشفرض LDAP وجود دارد که به شرح زیر هستند:
برای اینکه CRL ها و Certificate CA ها بصورت کامل با تمامی Domain Controller های موجود در Forest عملیات Replication را انجام دهند مقداری زمان نیاز است. این زمان بستگی به تاخیر و شرایط موجود در شبکه دارد، مخصوصا زمانیکه Replication قرار است در بین دو سایت متفاوت انجام شود و Domain Controller ها از هم فاصله دارند این زمان طولانی می شود. عدم پشتیبانی از آدرس های URL پروتکل LDAP برای کلاینت ها می تواند باعث تاخیر در دریافت CRL و CA Certificate موجود در اکتیودایرکتوری شود. اگر آدرس LDAP URL در لیست URL ها در بالاترین قسمت قرار داشته باشد و این لیست در اختیار کلاینتی قرار بگیرد که از اکتیودایرکتوری پشتیبانی نمی کند، حداقل 10 ثانیه زمان لازم می باشد که کلاینت به این نتیجه برسد که از آدرس پشتیبانی نمی کند و بایستی به آدرس URL بعدی مراجعه کند.
تصمیم گیری در خصوص استفاده از هر یک از این پروتکل ها برای ایجاد نقاط انتشار CRL و CA Certificate ها بستگی به دفعاتی دارد که شما CRL را منتشر می کنید، عوامل موثر دیگر در این تصمیم گیری استفاده از فایروال در بین شبکه ها و اجازه عبور پروتکل های عنوان شده از بین آنها و همچنین سیستم عامل هایی که در شبکه استفاده می کنید، می باشد. برای اطمینان از بالاترین سطح دسترسی پذیری آدرس های URL بایستی به گونه ای مرتب سازی شوند که در لیست CDP در بالاترین سطح قرار بگیرند.
بعد از اینکه شما پروتکل های انتشار را انتخاب کردید، بایستی در خصوص محل قرار گیری CRL و CA Certificate ها نیز تصمیم گیری کنید. منظور از محل قرار گیری در واقع سرور فیزیکی است که در شبکه قرار گرفته است و فایل های منتشر شده را بر روی خود نگهداری می کند، این سرور می تواند در محیط اینترانت یا اکسترانت سازمانی قرار گرفته باشد.
برای انتخاب نقاط انتشار می توانید از راهنماهایی که در ادامه مشاهده می کنید استفاده کنید:
اگر بیشتر کامپیوترهای موجود و در عضویت Forest از سیستم عامل های ویندوز 2000 و بالاتر از آن استفاده می کنند، شما بایستی یک آدرس URL پروتکل LDAP یا LDAP URL را به عنوان مرجع برای Configuration اکتیودایرکتوری داشته باشید. این باعث می شود که تمامی دامین کنترلر های موجود در ساختار Forest از اطلاعات یکپارچه ای بهره مند شوند و Fault Tolerance و Availability بیشتری برای سرویس مورد نظر ایجاد شود.
اگر کامپیوترهایی دارید که در عضویت Forest نیستند و یا از سیستم عامل های Third-Party استفاده می کنند، مانند سیستم عامل های UNIX، شما بایستی از یک وب سرور به عنوان HTTP URL برای انتشار CRL و CA Certificate استفاده کنید.
اگر Certificate ها قرار است که توسط یک شبکه بیرونی ارزیابی شوند، CA Certificate و CDP بایستی به گونه ای منتشر شوند که بتوان از آنها در محیط خارجی استفاده کرد، مثلا می توان آنها را بر روی یک وب سرور و یا LDAP سرور قرار دارد و در یک ساختار DMZ برای دسترسی بیرونی قرار داد.
استفاده از ساختار انتشار مبتنی بر فایل معمولا برای بدست آوردن اطلاعات CRL و CA Certificate مورد استفاده قرار نمی گیرد، معمولا از این گزینه برای ارسال اطلاعات CRL و CA Certificate برای سرورهای ریموت استفاده می شود تا استفاده برای کلاینت هایی که به آن نیاز دارند.
ترتیب URL ها بر اساس نوع کلاینت های شبکه تعیین می شود. ترتیب بایستی بر اساس اولویت کلاینت ها برای دریافت CA Certificate و CRL از اولین URL لیست شده انجام شود. اگر کلاینتی نتواند CA Certificate و CRL را از اولین URL دریافت کند، کلاینت ابتدا یک Timeout دریافت کرده و سپس به سراغ URL بعدی لیست شده می رود. Delta CRL ها خیلی بیشتر از Base CRL ها منتشر می شوند. شما ممکن است بخواهید که Delta CRL ها را به خاطر وجود تاخیری که در Replication اکتیودایرکتوری وجود دارد در LDAP منتشر نکنید و به جای آن Delta CRL ها را در محل های HTTP منتشر کنید تا دسترسی پذیری بالاتری داشته باشید.
خلاصه
در این سه مقاله بصورت کاملا اجمالی به بررسی ساختار PKI در سیستم عامل ویندوز سرور و شیوه طراحی و پیاده سازی زیرساخت کلید عمومی پرداختیم، کاملا طبیعی است که مبحث PKI اصلا در قالب سه مقاله قابل پوشش نیست و هدف من از ارائه این مقاله صرفا آشنایی اولیه با ساختار PKI های مایکروسافتی بوده است، چه بسا برای هر یک از تعاریفی که ما در این مقاله ها عنوان کردیم بتوان یک کتاب کامل ارائه کرد، در هر صورت امیدوارم کمی توانسته باشیم شما را با این مفاهیم آشنا کنم و در نهایت امیدوارم مورد توجه شما دوستان قرار گرفته باشد.
