بنیانگذار انجمن تخصصی فناوری اطلاعات ایران ، هکر کلاه خاکستری ، کارشناس امنیت اطلاعات و ارتباطات

کاملترین آموزش طراحی PKI یا رمزنگاری کلید عمومی

یکی از مهمترین مباحثی که در خصوص رمزنگاری داده ها وجود دارد زیرساختار کلیک عمومی یا PKI است ، این نوع رمزنگاری از نوع نامتقارن است که دارای دو کلید است که یکی برای رمزنگاری و دیگری برای رمزگشایی استفاده می شود ، معمولا تا نامی از ساختار PKI در سیستم عامل های مایکروسافت می آید به فکر سختی ها و ابهاماتی می افتیم که همیشه در این مسئله جزئی از کار هستند ، اکثر ایرانی هایی که در راه اندازی PKI دستی دارند و در سازمان خود از PKI های مایکروسافتی استفاده می کنند .

دوره های شبکه، برنامه نویسی، مجازی سازی، امنیت، نفوذ و ... با برترین های ایران

برای مشاهده تخفیف های ویژه امروز کلیک کنید

سرفصل های این مطلب

نیازمندی های PKI
ساختار سلسله مراتبی
طرح مدیریت CA

از مفاهیم موجود در آن اطلاعاتی ندارند و صرفا آن را نصب می کنند ، در این سری مقالات ضمن بررسی چیستی PKI به بررسی و طراحی این ساختار بصورت اصولی در سیستم عامل های مایکروسافت خواهیم پرداخت . در شبکه های تحت سیستم عامل ویندوز سرور 2008 زیرساخت کلید عمومی یا PKI به یک یا چندین Certificate Authority یا CA گفته می شود که از طریق سرویس Active Directory Certificate Services پیاده سازی شده باشند.

تعجب نکنید در خصوص تمامی این واژه ها در ادامه توضیحات کاملی را ارائه خواهیم داد اما توجه کنید که پیاده سازی PKI به همین سادگی ها نیست که صرفا در Server Manager یک Role نصب کنید و کار تمام شود. برای بیشتر سازمان های متوسط و رو به بزرگ پیاده سازی PKI نیازمند طراحی اولیه و تهیه مستندات است.

مدت ها بود که استفاده از زیر ساختار PKI در سازمان ها چندان معمول نبود تا اینکه اکثر نرم افزارهای کاربردی و سرویس های شبکه برای بالا بردن سطح امنیتی خود استفاده از PKI را در زیرساخت نرم افزاری خود به عنوان یک الزام قرار دادند و این خود دلیلی بود که سازمان ها نیز به سمت استفاده از PKI بروند . قطعا اگر سازمان شما از استانداردهای بین المللی امنیت اطلاعات مانند ایزو 27001 استفاده می کند و یا حداقل چیزی به عنوان خط مشی امنیت سازمان وجود دارد استفاده از PKI معمولا در این سیاست های کلان دیده می شود.

نیازمندی های PKI

اگر در خط مشی امنیتی سازمانی شما PKI دیده شده است که به ندرت چنین چیزی در ساختارهای سازمانی ایران دیده می شود به سراغ بررسی نیازمندیهای اولیه PKI از قبیل نیازمندیهای تجاری ، نیازمندیهای خارجی و نیازمندیهای اکتیودایرکتوری می رویم . بعد از اینکه تمامی این موارد را بررسی کردید که با توجه به تجارب بنده بررسی نخواهید کرد به سراغ طراحی PKI برای سازمان می رویم و آن را در بر اساس خط مشی امنیتی سازمان و نیازمندیهای سازمان جلو می بریم.

مروری بر مفاهیم PKI

PKI مخفف کلمه Public Key Infrastructure یا زیرساخت کلید عمومی می باشد که در واقع یک سری از تکنولوژی ها هستند که به شما امکان استفاده از رمزنگاری نامتقارن یا در لفظی دیگر رمزنگاری کلید عمومی را می دهند. در رمزنگاری کلید عمومی یک جفت کلید با استفاده از الگوریتم های رمزنگاری ریاضی تولید می شوند که به نام های کلید عمومی یا Public Key و کلید خصوصی یا Private Key معرفی می شوند ، با استفاده از مجموع این دو کلید شما می توانید عملیات رمزنگاری و رمزگشایی اطلاعات را انجام دهید.

اگر کلید خصوصی برای رمزنگاری استفاده می شود ، صرفا کلید عمومی مرتبط با آن می تواند اطلاعات مربوطه را رمزگشایی کند. عکس همین عمل هم ممکن است و اگر شما با کلید عمومی چیزی را رمزنگاری کنید ، صرفا با کلید خصوصی مرتبط با آن عملیات رمزگشایی انجام خواهد شد. اگر بخواهیم تخصصی تر در این مورد توضیح بدهیم می توانیم بگوییم که PKI یک سیستم است که از ترکیبی از گواهینامه های دیجیتال ( Digital Certificates ) ، مراکز صدور گواهینامه ( Certificate Authorities ) و مراکز ثبت گواهینامه ( Registration Authorities ) تشکیل شده است که در مجموع می توانند سرویسی برای رمزنگاری اطلاعات ایجاد کنند که بتواند تبادلات الکترونیک را رمزنگاری و یا اشخاص را احراز هویت کنند. ساختار PKI در ساده ترین حالت شامل اجزای زیر می باشد:

گواهینامه های دیجیتال یا Digital Certificates : در ترجمه به معنی اعتبار است اما بهتر است بگوییم که Credential های الکترونیکی می باشند که شامل کلید عمومی هستند که برای رمزنگاری داده ها و استفاده به عنوان امضاء الکترونیکی استفاده می شوند. در واقع Digital Certificate ها پایه و اساس کار PKI هستند و بدون آنها PKI بی معنی است.

یک یا بیش از یک مرکز صدور گواهینامه دیجیتال یا Certificate Authority : مراجع یا موجودیت های مورد اعتمادی هستند که برای صدور Digital Certificate ها مورد استفاده قرار می گیرند. زمانیکه از بیش از یک عدد CA در یک مجموعه استفاده می شود ، همیشه برای آنها یک نظم در طراحی وجود دارد که وظایف هر یک از آنها را به تفکیک روشن کرده است ، برای مثال CA ریشه یا Root در هسته اصلی مرکز قرار دارد ، در زیر مجموعه Root CA مرکزی به نام Subordinate CA وجود دارد و در نهایت مرکزی برای صدور گواهینامه برای کاربران به نام Issuing CA وجود دارد.

Certificate Policy و Certificate Practice Statement : اینها دو عدد مستند مکتوب هستند که در آنها شیوه استفاده از CA و همچنین Certificate هایی که در آن وجود دارند تشریح شده است و همچنین درجه اعتمادی که می توان به Certificate های این مجموعه داد را تعیین می کند ، تمامی موارد و مسائلی که در خصوص از بین رفتن اعتماد به CA و از این قبلی مشکلاتی که در ساختار PKI به وجود می پیوندند در این مستندات دیده شده است.

Certificate Repository: محلی است که مانند یک ساختار directory Service که از اکانت های کاربری محافظت می کند ، از Certificate های تولید شده توسط ساختار PKI موجود محافظت و آنها را ذخیره می کند ، Certificate ها از این محل منتشر می شوند . در یک محیط دامین معمولا پایگاه داده اکتیودایرکتوری معمولترین Repository است که برای انتشار و نگهداری Certificate ها مورد استفاده قرار می گیرد.

Certificate Revocation List یا CRL : لیستی از Certificate هایی است که قبل از اینکه تاریخ انقضای آنها برسد بر اساس شرایط بوجود آمده باطل یا Revoke شده اند.

شناسایی ابزارها و سرویس های کاربردی PKI یا PKI-Enabled Applications

همیشه زمانی استفاده از یک تکنولوژی باب می شود که نیازی به استفاده از آن ایجاد شود و PKI هم از این قضیه استثناء نیست . سازمان هایی که امروزه از PKI استفاده می کنند نیاز به استفاده از آن را بیشتر در نرم افزاهای کاربردی و سرویس هایی می بینند که برای بالا بردن سطح امنیت خود از PKI استفاده می کنند. بعد از اینکه نیاز به PKI ملموس شد سازمان مجبور می شود که بر اساس نیاز پشتیبانی های لازم برای برآورده سازی نیازهای راه اندازی PKI را برطرف کند. در ادامه لیستی از تکنولوژی های و نرم افزارهای کاربردی که سازمان را مجبور به استفاد از PKI می کند را به شما معرفی خواهیم کرد :

802.1x Port Based Authentication : این قابلیت به شما اجازه می دهد که بتوانید دسترسی به شبکه وایرلس و یا شبکه اترنت خود را برای کاربران غیرمجاز مسدود کرده و صرفا به کسانی اجازه متصل شدن به سیستم را بدهند که از طریق 802.1x احراز هویت شده اند. زمانی که شما در این سرویس از پروتکل های Extensible Authentication Protocol-Transport Layer Security (EAP-TLS) Extensible Authentication Protocol-Tunneled Transport Layer Security (EAP-TTLS یا (Protected Extensible Authentication Protocol (PEAP استفاده می کنید بایستی از ساختار PKI استفاده کنید.

امضای دیجیتال یا Digital Signatures : مهمترین رکن در امضاهای دیجیتال ساختار PKI است . Digital Signatures تبادلاتی که در اینترنت انجام می شوند را امن می کنند و روشی را برای شما فراهم می کنند که متوجه بشوید چه کسی ، چه اطلاعاتی و چه محتوایی را منتقل کرده است و از طرفی از دستکاری نشدن اطلاعات نیز اطمینان حاصل می کند. بسته به روشی که Certificate صادر شده است شما می توانید از امضاهای دیجیتال برای انکارناپذیری یا non-repudiation نیز استفاده کنید ، بدین معنی که اگر کسی کاری را انجام داده است نتواند انجامش را انکار کند. در این حالت اگر شخصی اطلاعاتی را منتقل کند ، نمی تواند منکر این قضیه شود به دلیل اینکه صرفا کسی که دارای Private Key مربوطه می باشد توانایی انتقال چنین داده ای را دارد.

Encryption File System یا EFS : این قابلیت ، سرویس محرمانگی یا Confidentiality را به NTFS می دهد. در این قابلیت از دو کلید عمومی و خصوصی برای رمزنگاری و رمزگشایی فایل ها و همچنین برای بازیابی اطلاعات در مواقع ضروری یا Recovery Agent استفاده می شود. Certificate هایی که برای EFS ایجاد می شوند صرفا از طریق Enterprise CA ها امکان صدور دارند ، در جایی که شما Enterprise CA در اختیار ندارید هرگاه از EFS استفاده کنید ، Certificate ها بصورت Self-Signed صادر و استفاده می شوند.

IPSec : اگر با پروتکل امنیتی IPSecurity یا IPSec آشنایی داشته باشید حتما می دانید که این پروتکل برای رمزنگاری و همچنین Tunneling بین دو سیستم برای برقراری ارتباط امن مورد استفاده قرار می گیرد ، اما برای اینکه بتوانید ساختار احراز هویت را نیز به IPSec اضافه کنید می توانید از Certificate ای که در PKI تولید می شود استفاده کنید. IPSec می توانید ارتباطات بین دو Endpoint را به خوبی Digitally Sign کند. توجه کنید که Certificate های بصورت مستقیم برای رمزنگاری داده هایی که توسط IPSec منتقل می شوند استفاده نمی شوند بلکه برای Authentication یا احراز هویت دو Endpoint استفاده می شوند.

Secure E-Mail یا S/MIME : پروتکل Secure Multipurpose Internet Mail Extensions یا همان SMIME برای برقراری ارتباطات ایمیل محرمانه ، دارای تمامیت و صحت اطلاعات و انکارناپذیری استفاده می شود. SMIME از Certificate برای شناسایی هویت فرستنده ، اصل و ماهیت پیام ارسالی و صحت و تمامیت پیام ایمیل استفاده می کند. همچنین SMIME محرمانگی پیام ایمیل را با استفاده از رمزنگاری اطلاعات درون آن انجام می دهد.

کارت های هوشمند یا Smart Card : کارت های هوشمند شبیه کارت های اعتباری هستن که در آنها Certificate کاربر ذخیره می شود. شما می توانید با استفاده از کارت های هوشمند فرآیند احراز هویت Two Factor با درجه امنیتی بالاتری نسبت به رمزعبور خالی برای ورود به سیستم ها ایجاد کنید.

Code Signing : با استفاده از قابلیت Code Signing شما می توانید از نصب درایورها یا نرم افزارهای غیر مجاز بر روی سیستم جلوگیری و محافظت کنید ، نرم افزارهایی که از قابلیت Code Signing پشتیبانی می کنند مانند Microsoft Internet Explorer می توانند به گونه ای تنظیم شوند که از اجرا کنترل ها و کدهای Unsigned جلوگیری کنند.

Virtual Private Network یا VPN: سرویس VPN به شما اجازه برقراری ارتباط از راه دور با شبکه های خصوصی از طریق پروتکل های Tunneling از قبیل PPTP و L2TP و SSTP را می دهد. البته تمامی پروتکل های VPN از Certificate برای برقراری ارتباط استفاده نمی کنند بلکه پروتکل L2TP زمانیکه از IPSec استفاده می کند از Certificate برای فرآیند احراز هویت استفاده می کند و از طرفی کلیه فعالیت های SSTP که با SSL رمزنگاری می شود از Certificate برای اینکار استفاده می کند.

Web Authentication و SSL: این دو سرویس با استفاده از این دو سرویس با استفاده از Certificate ها می توانند برای وب سرور قابلیت رمزنگاری اطلاعات مربوط به احراز هویت در شبکه داخلی و یا اینترنت را فراهم کند ، با استفاده از SSL کاربران وب می توانند از هویت اصلی و واقعی بودن سرور وب اطمینان حاصل کنند و تمامی ارتباطات بین کلاینت و سرور رمزنگاری خواهد شد. تمامی وب سرورهایی که دارای سرویس SSL هستند دارای Certificate هستند که توسط یک Third Party CA معتبر صادر می شود اما در برخی از مواقع پیش می آید که شما می توانید از Certificate ای که Client ها دارند برای سرور هم استفاده کنید که این مورد معمولا به ندرت پیاده سازی می شود.

شناسایی نیازمندیهای Certificate

بعد از اینکه تعیین کردید که از کدامیک از سرویس ها یا نرم افزارهای مرتبط یا PKI می خواهید در سازمان خود استفاده کنید ، بایستی تعیین کنید که چه کسی مسئول صدور Certificate ها و نوع Certificate ای خواهد بود که قرار است صادر شود. معمولا Certificate ها به شکل زیر صادر می شوند :

User Certificate: این نوع Certificate برای یک کاربر خاص صادر می شود که قرار است از سرویس ها یا نرم افزارهای PKI استفاده کند. کاربر مورد نظر در این حالت یک Certificate مخصوص به خود دریافت می کند که با استفاده از آن می تواند از سرویس ها و قابلیت های PKI مختص یک کاربر مانند سرویس EFS که برای رمزنگاری اطلاعات یک کاربر خاص مورد استفاده قرار می گیرد استفاده کند ، این Certificate در این حالت صرفا برای مصرف EFS مورد استفاده قرار می گیرد . Certificate هایی که برای کاربران صادر می شود در Current User Certificate Store ذخیره می شوند.

Computer Certificate: این نوع Certificate همانطور که از نامش پیداست صرفا برای یک کامپیتور صادر می شود و زمانی که یک کامپیوتر یا یک User به این کامپیوتر متصل می شود این Certificate هویت واقعی این کامپیوتر را مشخص می کند. این Certificate هویت کامپیوتر را مشخص می کند و در قسمت Local Machine Certificate Store ذخیره می شود.

Network Device Certificate : برخی از سخت افزارهایی که در شبکه فعالیت می کنند می توانند از امکانات و سرویس هایی که PKI در اختیار آنها قرار می دهد استفاده کنند و احراز هویت کلاینت ها و سرورها را با استفاده از PKI انجام دهند. این دستگاه ها شامل تجهیزات سخت افزاری VPN و Firewall و Router ها هستند اما فقط به اینها محدود نمی شوند. فرآیند نصب یک Certificate بر روی یک دستگاه بستگی به نوع سیستم عامل بکار رفته بر روی دستگاه مورد نظر و از طرفی Interface های شبکه ای دارد که بر روی دستگاه مورد نظر وجود دارد. Network Device Enrollment یک امکان جدید است که در CA های مایکروسافت بر روی ویندوز سرور 2008 معرفی شده است ، این قابلیت وابستگی مستقیمی به سرویس Network Device Enrollment Service یا NDES دارد. این سرویس در واقع معادل مایکروسافتی سرویسی به نام Simple Certificate Enrollment Protocol یا SCEP است ، این سرویس در واقع یک پروتکل است که به شما امکان پیاده سازی استاندارد X.509 را بر روی سخت افزارها و دستگاه هایی که قابلیت احراز هویت در شبکه را دارند فراهم می کند و این بدین معناست که این دستگاه ها می توانند از CA برای خود Certificate دریافت کنند.

Service Certificate : سرویس ها نیز برای احراز هویت و رمزنگاری از Certificate هایی که برای کامپیوترها صادر می شود استفاده می کنند. Certificate ها در واقع برای سرویس ها صادر نمی شوند بلکه در عوض Certificate ای که برای کامپیوتر صادر می شود و توسط سرویس مورد استفاده قرار می گیرد در Local Machine Store یا در پروفایل اکانت سرویس مورد نظر ذخیره می شود. برای مثال اگر یک Certificate برای سرویس World Wide Web یا WWW یک سرویس وب نصب شود ، Certificate مورد نظر در قسمت Local Machine Store ذخیره خواهد شد. از طرفی دیگر Certificate ای که برای Recovery Agent مربوط به EFS مورد استفاده قرار می گیرد در User Profile کاربر سرویس مورد نظر ذخیره می شود.

نکته : کجا باید برای یک سرویس Certificate مورد نیازش را نصب کنید ؟
ساده ترین روشی که شما می توانید تعیین کنید که آیا یک سرویس نیاز به Certificate دارد یا خیر این است که تشخیص دهید که سرویس مورد نظر به وسیله چه چیزی احراز هویت را انجام می دهند ، اگر سرویس از Local System استفاده می کند ، Certificate مورد نظر بایستی در Local Machine Store ذخیره شود و اگر سرویس مورد نظر از یک نام کاربری و رمز عبور مشخص شده استفاده می کند ، بنابراین Certificate مورد نظر در پروفایل کاربر مورد نظر ذخیره می شود.

شناسایی نیازمندی های امنیتی Certificate ها

نیازمندی های امنیتی Certificate ها بر اساس نوع سرویس PKI ای که قصد استفاده از آن در سازمان خود دارید ، متفاوت است . شناسایی این نیازمندی ها به شما اجازه می دهد که تنظیمات Certificate های مورد نیاز را به خوبی برآورد کنید ، برای هر مجموعه ای از Certificate ها شما بایستی نیازمندی های امنیتی زیر را به خوبی شناسایی و درک کنید:

طول کلید خصوصی یا Private Key Length : در یک پیاده سازی تعریف شده ، طول کلید خصوصی هایی که در یک سطح از hierarchy یا سلسله مراتب ساختار PKI قرار میگیرند نصب طول کلید خصوصی است که در سطح بالایی خود استفاده می شود. برای مثال در ساختار PKI طول کلید خصوصی که برای یک کاربر صادر می شود ممکن است 1024 بیتی باشد و در همین حال طول کلید خصوصی CA صادر کننده 2048 بیتی باشد و طول کلید خصوصی Root CA یا ریشه 4096 بیتی باشد. توجه کنید که با اگر طول کلید خصوصی شما طولانی تر باشد طبیعی است که برای شکستن این کلید زمان بیشتری از لحاظ دانش ریاضی مورد نیاز می باشد بنابراین به تناسب طول کلید بیشتر ، عمر Certificate ای که صادر می شود نیز بیشتر خواهد بود. برای انتخاب طول کلید خصوصی در هر لایه از CA ها بزرگترین مسئله قابلیت استفاده نرم افزارها و سرویس ها از کلید هایی با طول زیاد است ، برخی از سرویس ها و نرم افزارها نمی توانند از کلید هایی با طول زیاد پشتیبانی کنند.

الگوریتم رمزنگاری یا Cryptographic Algorithm : الگوریتم های رمزنگاری جزء جدا ناشدنی Certificate ها هستند. تنظیمات استاندارد Certificate هایی که از طریق CA های ویندوز سرور 2008 صادر می شوند بایستی دارای یک سری پارامترهای امنیتی پیشفرض باشند. اما گاهی برای شما پیش می آید که می خواهید برای گروه خاصی که در شبکه فعالیت می کنند تنظیماتی انجام دهید که طول کلید خصوصی آنها و عمر گواهینامه یا Lifetime آن طولانی تر یا کمتر از موراد مشابهی باشد که برای سایر کاربران وجود دارد. شما با استفاده از الگوریتم های رمزنگاری خاص می توانید روش ذخیره سازی کلید خصوصی در کارت های هوشمند را به گونه ای تعیین کنید که از درجه امنیتی بالاتری برخوردار باشند.

عمر گواهینامه یا Lifetime و کلید خصوصی و چرخه تجدید Certificate : یک Certificate در زمان صدور دارای یک تاریخ و زمان اعتبار و یک تاریخ و زمان انقضاء می باشد. شما نمی توانید اعتبار یک Certificate صادر شده را بعد از صدور تغییر دهید. عمر گواهینامه دیحیتال یا Certificate Lifetime بسته به نوع Certificate ، نیازهای امنیتی ، استانداردهای بکار گرفته شده در سازمان شما و همچنین مقررات دولتی می تواند متغیر باشد

نکته : عمر گواهینامه ها یا Certificate Lifetime : زمانی که شما می خواهید Certificate Lifetime را برای ساختار PKI خود تعیین کنید ، گزینه درست این است که Certificate Lifetime مربوط به CA های Parent یا والد را دو برابر CA های Subordinate یا میانی در نظر بگیرید. علاوه بر این زمان اعتبار یا Validity Period مربوط به CA ای که به عنوان صادر کننده یا Issuing CA مشغول به کار است را بایستی حداقل دو برابر زمان اعتبار Certificate هایی باشد که توسط همان CA صادر می شود. برای مثال شما برای یک Certificate که برای کاربر صادر می شود تاریخ اعتبار یک ساله در نظر می گیرد و این در حالی است که CA صادر کننده دارای تاریخ اعتبار 5 ساله می باشد و CA ریشه یا Root CA دارای تاریخ اعتبار 10 ساله می باشد.

نگهداری و ذخیره سازی کلید های خصوصی خاص یا Special Private Keys : هر سازمانی برای خود بایست دارای یک خط مشی امنیتی یا Security Policy باشد که در آن به نیازمندی های امنیتی که برای نگهداری کلید خصوصی CA وجود دارد اشاره شده باشد. برای مثال یک سازمان ممکن است برای نگهداری کلید خصوصی خود از استاندارد محافظتی Federal Information Processing Standards یا FIPS شماره 140-2 استفاده کند. در خصوص این استاندارد به امید خدا در مقاله ای جداگانه بصورت مفصل توضیحاتی ارائه خواهیم کرد.

معیارهایی که شما می توانید برای محافظت از کلید خصوصی CA خود استفاده کنید شامل استفاده از یک Cryptographic Service Provider یا CSP است که به شما این قابلیت را می دهد که بتوانید کلید خصوصی CA خود را در درون هارد دیسک کامپیوتر خود ، در داخل یک کارت هوشمند CSP که اطلاعات مربوط به کلید خصوصی را در خود ذخیره می کند و با استفاده از یک PIN Code از آن نگهداری می کند ، در داخل یک Hardware Security Module یا HSM که بالاترین سطح امنیتی را برای کلید خصوصی شما فراهم می کند ، می باشد. HSM ها سخت افزارهای ویژه ای هستند که برای نگهداری کلید های خصوصی مورد استفاده قرار می گیرند.

Cryptographic Service Provider یا CSP چیست؟

یک CSP در واقع چگونگی و روش دسترسی و محافظت از کلید خصوصی یا Private Key را تعیین می کند . این CSP است که تعیین می کند در کجا زوج کلید های Certificate ایجاد شود و چه زمانی Certificate در خواست شود و همچنین مکانیزم های امنیتی برای محافظت از کلید خصوصی را نیز تعیین می کند. برای مثال در یک CSP ممکن است برای دسترسی به کلید خصوصی موجود در یک کارت هوشمند حتما یک PIN Code نیاز باشد. CSP پیشفرضی که در ساختار AD CS در ویندوز سرور 2008 وجود دارد به نام RSA#Microsoft Software Key Storage Provider است . این CSP ضمن اینکه از الگوریتم های رمزنگاری قدیمی پشتیبانی می کند ، از الگوریتم های جدید نیز پشتیبانی می کند.

بازنگری و تازه سازی خط مشی امنیتی سازمان

بعد از اینکه ساختار و نیازمندیهای PKI و Certificate ها در سازمان دیده شد ، شما بایستی خط مشی امنیتی سازمان را مجددا بازنگری کنید. خط مشی امنیت اطلاعات یا Security Policy در واقع یک مستند تدوین شده توسط اعضای قانونی یا مدیران سازمان ، منابع انسانی و دپارتمان فناوری اطلاعات یک سازمان است که در آن استانداردهای امنیتی سازمان مشخص و مستند شده است.

این مستند معمولا حاوی دارایی هایی است که برای سازمان دارای ازرش هستند و تهدیداتی که در مقابل این دارایی ها وجود دارد ، در نهایت کنترل هایی که برای محافظت از این دارایی ها در مقابل تهدیدات وجود دارد در این مستند آورده شده است. خط مشی امنیت اطلاعات یک سازمان برای اینکه بتواند به سئوالاتی که در سطوح بالا از پیاده سازی های PKI به وجود می آیند پاسخگو باشند بایستی به روز رسانی شوند که نمونه ای از این سئوالات به شرح زیر می باشد:

چه نرم افزارهایی بایستی به وسیله Certificate ها امن شوند ؟
چه سرویس های امنیتی بایستی به وسیله Certificate ها ارائه شوند ؟

معمولا در زمان طراحی و معماری ساختار PKI بایستی به خاطر داشته باشیم که PKI بایستی بتواند خط مشی امنیتی سازمان را مجبور به تغییر کند . یک ساختار PKI تنها زمانی به درستی می تواند در حیطه امنیتی خود عمل کند که خط مشی امنیتی سازمان و دستورالعمل های این خط مشی بتوانند از آن پشتیبانی کنند و PKI را قابل پیاده سازی کنند.

ارزیابی نیازمندی های تجاری

نیازمندی های تجاری مشخص کننده اهداف یک سازمان هستند. نیازمندی های تجاری تاثیر مستقیمی بر طراحی ساختار PKI در یک سازمان دارند و در واقع PKI بایستی به نحوی طراحی شود که در راستای برآورده سازی نیازهای سازمانی و فرآیندهای کاری باشد. برای مثال نیازمندی های تجاری که در ادامه مشاهده می کنید تاثیر مستقیمی بر روی طراحی ساختار سلسله مراتبی CA ها دارند:

کاهش هزینه های مرتبط با PKI : در طراحی ساختار سلسله مراتبی PKI بایستی به این مورد توجه کنید که از حداقل تعداد ممکن از CA ها استفاده کنید برای مثال برخی از سازمان ها به جای استفاده از دو عدد CA به عنوان Policy CA و Issuing CA ، هر دوی آنها را بر روی یک سرور قرار می دهند تا هزینه های خود را پایین بیاورند ، در این حالت ضمن صرفه جویی در هزینه ها کارایی نیز تا حدودی در سطوح پایین ، بالا خواهد رفت.

دسترسی پذیری بالا در صدور Certificate ها : یک سازمان همیشه به یک CA نیاز دارد که در صورت بروز مشکل برای CA های صادر کننده Certificate بتواند به روند کاری خود ادامه دهد و به هر دلیلی روند صدور Certificate ها دچار اخلال نشود. برای اطمینان از دسترسی همیشگی به یک CA شما بایستی از ساختار های Clustering برای Issuing CA های خود بر اساس Certificate Template تعریف شده استفاده کنید. اگر نیاز به uptime شما زیاد هم ضروری نیست شما می توانید Certificate Template تعریف شده در Issuing CA را در CA ها مختلفی که در ساختار سلسله مراتبی وجود دارند منتشر کنید تا در صورت بروز مشکل برای یکی از CA ها فرآیند کاری در جریان باشد.

مسئولیت شرکای PKI : در یک ساختار سلسله مراتبی CA یکی از CA ها در نقش Policy CA فعالیت می کند ، این CA تعیین کننده مسئولیت های CA می باشد. این مسئولیت ها بایستی بتوانند تمامی مراوداتی که از طریق Certificate هایی که از طریق CA ها صادر شده اند را پوشش دهند. معمولا در این چنین شرایطی محلی از سازمان که مسئول قانون گذاری در سازمان شما می باشد مسئولیت ها را در این خصوص تعیین کرده و به ساختار PKI و شرکایی که از آن استفاده می کنند ابلاغ می کند.

ارزیابی نیازمندی های خارجی

در برخی اوقات پیش می آید که سازمان بایستی نیازمندی های خارجی را نیز در ساختار PKI خود در نظر بگیرد ، مثلا نیازمندی هایی که توسط سایز سازمان های طرف قرارداد یا مرتبط هستند و یا نیازمندی های کشورهایی که سازمان شما با آنها مراوده دارد ، برای مثال برخی از این نیازمندی های خارجی را می توان به شرح زیر معرفی کرد:

ارائه امکاناتی برای سازمان های خارجی که بتوانند Certificate های صادر شده برای کارکنان را شناسایی کنند. اگر می خواهید سایر سازمان ها بتوانند Certificate هایی که در سازمان شما به موجودیت ها داده می شود را شناسایی کنند ، شما می توانید در این حالت به جای استفاده از یک طراحی PKI داخلی ، از یک طراحی PKI جانبی و تجاری مثل VeriSign یا RSA یا GeoTrust استفاده کنید. علاوه بر این گزینه جانبی دیگری نیز وجود دارد که شما می توانید برای CA های خود Trust بین CA ها را ایجاد کنید.

استفاده از Certificate های صادر شده توسط CA های سازمان شما در سازمان های همکار ، ممکن است پرسنلی که در سازمان شما مشغول به کار هستند بخواهد اطلاعات یا امضاهای دیجیتال خود را که در سازمان شما استفاده می کنند را در یک سازمان همکار نیز مورد استفاده قرار دهند ، در این حالت شما می توانید یک Certificate دلخواه سازی شده یا Custom ایجاد کنید که نیازمندیهای سایر سازمان های همکار را نیز برطرف کند.

قوانین صنعتی و دولتی ، برخی از کشورها وجود دارند که قوانین خاصی برای طراحی ساختار سلسله مراتبی PKI و CA ها برای خود دارند. برای مثال کشور کانادا قانونی دارد که در آن نگهداری و حفاظت از اطلاعات شخصی افراد و مستندات الکترونیک که نمایانگر اطلاعات مشتری Certificate می باشد بایستی در شرکت بصورت کاملا محرمانه و حفاظت شده نگهداری شوند. این یعنی اینکه در صورت بروز مشکل برای اطلاعات شخصی افراد شرکت یا شخص مسئولی بایستی وجود داشته باشد که پاسخگوی این مشکل باشد و این اجبار در قالب یک قانون در طراحی های CA در کشور کانادا به اجرا در می آید.

Certificate ها برای اشخاص غیر خودی ( Non Personnel ) ، اگر شما برای افراد خارج از سازمان خود نیز قصد ارائه Certificate دارید ، می توانید به شکلی ساختار سلسله مراتبی CA های خود را طراحی کنید که در Certificate Policy جزئیات بیشتری در خصوص شیوه ارائه سرویس به مشتری های بیرونی لحاظ شده باشد.

ارزیابی نیازمندی های Active Directory

شما قبل از اینکه اقدام به نصب و راه اندازی یک Enterprise CA در محیط اکتیو دایرکتوری ویندوز سرور 2008 یا 2003 یا 2012 کنید بایستی یک سری آماده سازی های اولیه و همچنین نیازمندی ها را پیشبینی و انجام دهید ، این آماده سازی ها به شرح زیر می باشد:

تعیین تعداد Forest های موجود در محیط : تعداد Forest های موجود در مجموعه در تعداد Enterprise CA هایی که می خواهید در ساختار AD CS خود داشته باشید تاثیر مستقیمی دارد. یک Enterprise CA صرفا می تواند برای User ها و Computer هایی که در همان Forest وجود دارند Certificate صادر کند.اگر تعداد Forest های شما در مجموعه بیش از یکی است ، برای هر یک از Forest های خود در طراحی بایستی یک Enterprise CA را در نظر بگیرید.

تعیین تعداد Domain های موجود در محیط : اگر بیش از یک Domain در ساختار Forest شما وجود دارد ، یکی از مهمترین مسائل در طراحی ساختار PKI محل قرار دادن CA ها بر روی Domain مد نظر است .انتخاب Domain ای که میزبانی Computer Account های مربوط به CA را بر عهده داشته باشد تا حدود زیادی به این بستگی دارد که آیا مدیریت Domain های شما بصورت متمرکز انجام می شود و یا بصورت غیر متمرکز انجام می شود. در یک مدل مدیریت متمرکز معمولا CA ها در یک Domain قرار می گیرند ، در یک محیط با مدیریت غیر متمرکز شما ممکن است CA ها خود را بر روی چندین Domain قرار دهید.

تعیین عضویت گروه Local Administrators بر روی Member Server : اگر شما از CSP برای نگهداری Private Key مربوط به CA استفاده می کنید ، تمامی اعضای گروه Local Administrators ای که بر روی CA قرار دارند می توانند Private Key مربوط به CA را Export کنند.در این مواقع شما بایستی Domain یا OU ای که دارای کمترین و محدودترین تعداد Local Administrators می باشد را شناسایی کنید. برای مثال در سازمانی که دارای یک Forest خالی می باشد ، شما ممی توانید تمامی Enterprise CA های خود را در ساختار Forest بر روی Forest Root Domain ایجاد کنید که کمترین تعداد ممکن Local Administrator را دارد.

تعیین نسخه Schema موجود در Domain : برای پیاده سازی CA های ویندوز سرور 2008 و استفاده از تمامی امکاناتی که این CA در اختیار ما قرار می دهد شما بایستی آخرین نسخه از Active Directory Domain Services Schema را در اختیار داشته باشید. Schema در ویندوز سرور 2008 می تواند در Forest هایی که دارای دامین کنترلر های ویندوز سرور 2000 یا 2003 یا 2008 هستند پیاده سازی شود.

ارزیابی نیازمندی های Certificate Template

Certificate Template ها امکانی را فراهم می کنند تا شما بتوانید فرآیند ثبت نام Certificate یا Enrollment را در یک محیط مدیریت شده در Active Directory انجام دهید.با توجه به اینکه هر نسخه از محصولات ویندوز سروری که مایکروسافت ارائه کرده است دارای Certificate Template هایی با ویژگیها و نسخه های خاصی خود هستند ، مسئله هماهنگی یا Compatibility بایستی یکی از مسائلی باشد که در طراحی PKI بایستی در نظر بگیرید.

اگر تاریخچه Certificate Template هایی که مایکروسافت ارائه داده است را بررسی کنیم ، میبینیم که در نسخه ویندوز سرور 2000 مایکروسافت تعداد 71 عدد Certificate Template ایستا و ثابت ارائه کرد ، در ویندوز سرور 2003 به Certificate Template ها قابلیت دلخواه سازی یا Customization را اضافه کرد و تعداد Certificate Template های خود را به 73 عدد اضافه کرد ، اما در ویندوز سرور 2008 ضمن اینکه مایکروسافت Certificate Template های نسبتا بیشتری ، نسبت به محصولات قبلی خود اضافه کرده بود امکانات بیشتری به این قابلیت در ساختار CA نیز اضافه کرده بود ، تعداد Certificate Template ها در ویندوز سرور 2008 به عدد 73 رسید.

به دلیل محدودیت ها و وابستگی هایی که مربوط به سیستم عامل می باشد ، Template های ویندوز سرور 2008 صرفا می تواند به CA هایی ارائه شوند که بر روی آنها ویندوز سرور 2008 نصب شده باشد . فقط کلاینت های ویندوز ویستا و سون و سرور 2008 می توانند برای ثبت نام هر 73 عدد Template ای که در ساختار PKI این سرور وجود دارد برای کامپیتورهای خود ثبت نام کنند.

اگر تا به حال فقط 72 عدد از Template ها را در AD DS Forest نصب کرده اید ، بایستی Template های فعلی خود را بروز رسانی کرده و به جدید ترین تعداد که 73 عدد است ارتقاء دهید ، اگر هیچگونه Certificate Template ای در ساختار خود ندارید ، هر تعداد Template که تاکنون ایجاد شده است را می توانید در قسمت Configuration Container در AD DS Forest براحتی اضافه کنید.

ساختار سلسله مراتبی

ساختار PKI و Certificate Authority و Root CA

قطعا تا اینجا متوجه شده اید که ساختار PKI یک ساختار سلسله مراتبی یا موروثی است و در اینگونه ساختارها همیشه یک یا چند والد یا Parent و چندین فرزند یا Child وجود دارد ، مشابه این طراحی را در بسیاری از ساختارهای مشابه مانند ساختار DSN و همچنین Domain های Active Directory در یک Forest مشاهده کرده اید . در این مقاله به نکاتی که در طراحی این ساختار در PKI نیاز است اشاره خواهیم کرد . منظور از طراحی ساختار سلسله مراتبی برای CA ها در PKI در واقع تعیین تعداد CA های موجود در PKI و همچنین روابط اعتمادی یا Trust Relationship بین آنها می باشد. در بیشتر شبکه های متوسط و رو به بزرگ استقرار بیش از یک CA پیشنهاد می شود.

طرح ریزی زیرساختار CA

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

محل قرار گیری CA های ریشه یا Root CA
استفاده از CA های داخلی یا Third-Party
انواع CA و نقش های آن
تعداد CA های مورد نیاز

طراحی CA های ریشه یا Root CA ها

یک زیرساختار CA شامل یک سلسله مراتب و ساختار موروثی از CA ها می باشد که در بین تک تک آنها اعتماد یا Trust وجود داد و هر یک از آنها توانایی احراز هویت Certificate های یکدیگر را در این ساختار دارا می باشند. در این زیرساختار یک قدرت مطلق یا قدرت نهایی وجود دارد که در راس ساختار قرار گرفته است ، به این راس هرم یا شاخه در اصطلاح Root CA یا CA ریشه گفته می شود . بدون شک در هر ساختاری از CA یک Root CA وجود دارد. وظیفه اصلی Root CA انتخاب و پذیرش سایر CA های موجود در مجموعه جهت انتشار و مدیریت Certificate هایی است که در مجموعه سازمان صادر و مدیریت می شود.

انتخاب CA داخلی یا Third-Party CA

بسته به کارکرد هایی که شما نیاز دارید ، قابلیت هایی که زیرساختارهای فناوری اطلاعات و مدیران فناوری اطلاعات سازمان شما دارند و همچنین هزینه هایی که سازمان شما می تواند متقبل شود ، شما می توانید پایه و اساس زیر ساختار CA خود را بر اساس CA های داخلی بنا کنید و یا از CA های Third-party و یا ترکیبی از این دو را استفاده کنید.

CA های داخلی

اگر سازمان شما بیشتر فعالیت های تجاری و مروادات الکترونیکی خود را با سایر سازمان های همکار مدیریت و کنترل می کند و قصد نظارت بر شیوه صدور و استفاده Certificate ها دارد ، بهترین گزینه استفاده از CA ها داخلی می باشد ، مهمترین مزیت های استفاده از CA های داخلی عبارتند از :

به سازمان اجازه مدیریت و هدایت مستقیم بر روی خط مشی امنیتی سازمان را می دهد.
به سازمان اجازه می دهد که بتواند Certificate Policy خود را به خط مشی امنیتی سازمانی اضافه کند.
می تواند با زیر ساختار Active Directory Domain Services سازمان یکپارچه سازی شود.
براحتی می توان با هزینه ای بسیار پایین قابلیت های جدیدی به آن اضافه کرد و آن را توسعه داد.

مضرات استفاده از CA های داخلی نیز شامل موارد زیر می باشد :

سازمان بایستی Certificate های خود را مدیریت کند.
زمانی که برای پیاده سازی CA های داخلی صرف می شود بسیار بیشتر از زمانی است که برای استفاده از CA های خارجی صرف می شود
سازمان بایستی خطرات و مشکلاتی که در ساختار PKI به وجود می آید را قبول کند.

CA های خارجی

اگر سازمان شما بیشتر فعالیت ها و مراودات الکترونیکی خود را با مشتریان خارجی انجام می دهد و می خواهد که فرآیند صدور و مدیریت Certificate ها در جای دیگری انجام شود ، بهترین گزینه استفاده از ساختار CA های خارجی است ، مزایای استفاده از CA های خارجی یا Third-Party CA ها به شرح زیر می باشند :

به مشتریان شما اجازه می دهد که درجه اعتماد بالاتری به سازمان شما داشته باشند و از امنیت در تبادلات خود با سازمان شما مطمئن باشند.
به سازمان شما این اجازه را می دهد که از مزیت استفاده از یک سرویس دهنده حرفه ای استفاده کنید.
به سازمان این اجازه را می دهد که از یک ساختار امنیتی Certificate Based را بدون نیاز به راه اندازی CA داخلی استفاده کند.
کلیه مسائل تجاری مربوط به Certificate ها و مشکلات مربوط به آن بر عهده سرویس دهنده مربوطه می باشد.

مضرات استفاده از Third-Party CA ها به شرح زیر می باشند :

هزینه ها به ازای هر Certificate برای سازمان تا حدودی بالا می رود
ممکن است برای مدیرت و توسعه دو عدد استاندارد مدیریتی نیاز باشد ، یکی برای مدیریت داخلی Certificate ها و یکی برای مدیریت Certificate های تجاری که بصورت خارجی صادر می شوند.
قابلیت انعطاف پذیری و انجام تنظیمات و مدیریت آنها قطعا برای داخل سازمان محدود می شود.
سازمان بایستی به Third-Party CA برای دسترسی پیدا کردن به CRL دسترسی داشته باشد.
عملیات Auto Enrollment غیر ممکن است.
Third-Part CA ها معمولا قابلیت کمی برای یکپرچگی با دایرکتوری های داخلی و نرم افزارهای کاربردی درون سازمانی دارند و یکپارچه کردن آنها با زیرساختارهای سازمانی داخلی معمولا مشکل ساز می شود.

تعریف انواع CA و نقش های آن

برای طراحی زیرساختار CA شما بایستی انواع مختلف CA هایی که در ویندوز سرور 2008 وجود دارند و نقشی که می توانند در شبکه شما ایفا کنند را به درستی درک کنید. سرویس Windows Server 2008 Certificate Services از دو نوع CA پشتیبانی می کند که به شرح زیر می باشند :

Enterprise CA
Standalone CA

هر دو نوع Enterprise و Standalone می توانند به عنوان Root CA و یا Subordinate CA در شبکه فعالیت کنند. Subordinate CA ها همچنین می توانند به عنوان Intermediate CA یا CA های سطح میانی که به عنوان Policy CA نیز شناخته می شوند و یا Issuing CA که برای صدور Certificate می باشد ، مورد استفاده قرار بگیرند. قبل از اینکه زیرساختار CA های خود را ایجاد کنید ، شما بایستی نوع CA های مورد استفاده و نقشی که در ساختار PKI بر عهده دارند را به دقت در طراحی خود تعیین کنید.

مقایسه Enterprise CA و Standalone CA ها

Enterprise CA بصورت کامل با اکتیودایرکتوری یکپارچه می شوند . آنها Certificate ها و CRL ها را در اکتیودایرکتوری منتشر می کنند. Enterprise CA ها از اطلاعات ذخیره شده در اکتیودایرکتوری از قبیل اکانت های کاربری و Security Group ها برای تایید یا عدم تایید درخواست های Certificate استفاده می کنند. آنها از Certificate Template ها استفاده می کنند. زمانیکه یک Certificate صادر می شود ، Enterprise CA اطلاعات موجود در Certificate Template برای تولید Certificate ای با خاصیت های مرتبط با نوع Certificate در خواست شده ، استفاده می کند.

اگر شما می خواهید که فرآیند تایید خودکار Certificate ها و همچنین صدور خودکار Certificate ها یا Auto Enrollment داشته باشید بایستی از Enterprise CA ها استفاده کنید. این اممانات صرفا در زیرساختارهای CA ای وجود دارند که با زیرساختار اکتیودایرکتوری یکپارچه شده اند. علاوه بر این ، تنها Enterprise CA ها هستند که می توانند Certificate هایی صادر کنند که برای استفاده در Smart Card های ورود به سیستم مورد استفاده قرار بگیرند ، این امر به این دلیل است که این فرآیند نیاز به این دارد که Smart Card Certificate ای که صادر می شود به یک کاربر موجود در اکتیودایرکتوری مرتبط شود.

Standalone CA ها از زیرساختار اکتیودایرکتوری استفاده نمی کنند و از طرفی از Certificate Template ها نیز استفاده نمی کنند. در صورتیکه از Standalone CA ها استفاده میکنید ، تمامی اطلاعاتی که برای صدور Certificate مورد نظر نیاز می باشد را بایستی در درون درخواست یا Request خود بگنجانید. بصورت پیشفرض تمامی درخواست های Certificate ای که برای CA ارسال می شوند در صف pending در CA باقی می مانند تا مدیر CA آنها را تایید کند.شما می توانید Standalone CA ها را به گونه ای طراحی کنید که به درخواست های رسیده برای دریافت Certificate را بصورت خودکار پاسخ داده و Certificate را صادر کنند ، اما اینکار پیشنهاد نمی شود زیرا از لحاظ امنیتی درخواستی که به CA ارسال شده است هنوز احراز هویت نشده به مرحله صدور خواهد رسید.

از لحاظ بحث کارایی سیستم ، Standalone CA ها با قابلیت صدور خودکار Certificate سریعتر از Enterprise CA ها عمل می کنند. اما به این موضوع هم توجه کنید که در محیط های سازمانی بسیار بزرگ وجود چنین CA ای باعث بالا رفتن بار کاری مدیر CA خواهد شد ، زیرا هر روز بایست بصورت دستی تک تک درخواست ها را بررسی و در صورت نیاز تایید کند. به همین دلیل است که از Standalone CA ها معمولا در محیط های شبکه های Extranet و یا اینترنت استفاده می شود.

در واقع شما زمانی از Standalone CA ها استفاده می کنید که تعداد کاربران شما محدود است و از لحاظی درخواستی که برای صدور Certificate به CA ارسال می شود لزوما نبایستی دارای یک اکانت کاربری ویندوزی باشد. علاوه بر این شما زمانی از Standalone Ca ها استفاده می کنید که از یک Directory Service از نوع Third-Party استفاده می کنید و یا ساختار اکتیودایرکتوری وجود ندارد که بخواهید با آن یکپارچه شوید. نکته قابل توجه در این است که شما در طراحی ساختار PKI خود می توانید از ترکیبی از Enterprise CA ها و Standalone CA ها استفاده کنید.

مقایسه Enterprise CA و Standalone CA در مایکروسافت

جدول یک : مقایسه امکانات Enterprise CA ها و Standalone CA ها

معمولا شما زمانی از یک Standalone CA استفاده می کنید که یکی از موارد زیر وجود داشته باشد :

CA مورد نظر یک Offline CA است که در سطح Root و یا Intermediate مشغول به فعالیت است .
استفاده از Template های درخواستی برای Certificate ها نیاز نیست.
یک فرآیند امنیتی قوی برای تاییدیه Certificate ها لازم است.
تعداد Certificate هایی که صادر می شوند محدود است و فرآیند صدور Certificate بصورت دستی قابل پذیرش است.
کاربرهای درخواست کننده Certificate نمی توانند از وجود اکتیودایرکتوری استفاده کنند و یا نیازی ندارند.
قصد صدور Certificate برای Router ها با استفاده از NDES SCEP را دارید.

معمولا شما زمانی از یک Enterprise CA استفاده می کنید که یکی از موارد زیر وجود داشته باشد :

تعداد زیادی Certificate بایستی بصورت خودکار تایید و صادر شوند.
دسترسی پذیری و خطاپذیری یک اجبار است.
مشتریان می خواهند از مزایای یکپارچگی با اکتیودایرکتوری بهره مند شوند.
امکاناتی نظیر Auto enrollment و Certificate Template های قابل تغییر مورد نیاز است .
آرشیو سازی کلید ها و بازیابی آنها برای برون سپاری مورد نیاز است.

CA های ریشه یا Root CA

Root CA در واقع CA ای است که در بالاترین سطح از سلسله مراتب ساختار PKI قرار گرفته است ، تمامی Client ها و سازمان بایستی بدون قید و شرط به این CA اعتماد کنند. تمامی زنجیره هایی که دز ساختار PKI وجود دارند در نهایت به Root CA ختم می شوند. بدون توجه به اینکه شما از Enterprise CA یا Standalone CA استفاده می کنید ، شما در نهایت بایستی یک Root CA داشته باشید.

با توجه به اینکه در این سلسله مراتب مرجعه بالاتری برای دریافت Certificate وجود ندارد ، Root CA برای خود نیز Certificate صادر می کنید که در اطلاح به آن Self-Signed Certificate گفته می شود. خوب پس تا همینجا نتیجه می گیریم که در هر جایی که ما یک Self-Signed Certificate مشاهده کردیم ، آن CA در واقع یک Root CA می باشد. تصمیم گیری در خصوص اینکه یک CA به عنوان Trusted Root CA فعالیت کند می تواند هم در سطوح بالای سازمانی اتخاذ شود و یا در همان قسمت فناوری اطلاعات سازمان تصمیم گیری شود.

Root CA به عنوان پایه و بنیاد اصلی مدل اعتماد یا Trust Model ای است که شما در سلسله مراتب CA خود استفاده می کنید. این CA در واقع شما را از صحت وجود اطلاعاتی که در یک Certificate وجود دارد مطمئن می کند. CA های مختلف می توانند با استاندارد های مختلفی این ارتباط را برقرار کنند ، بنابراین قبل از پیاده سازی ساختار و مدل اعتماد برای تایید کلید های عمومی حتما خط مشی ها و دستورالعمل های مربوط به Root CA را به درستی تدوین کنید.

Root CA مهمترین رکن و قسمت در سلسله مراتب CA می باشد. اگر Root CA شما دچار مشکل و اختلال شود ، تمامی CA هایی که در این سلسله مراتب قرار گرفته اند نیز دچار اختلال و مشکل خواهند شد. شما می توانید با قطع کردن ارتباط Root CA با شبکه و استفاده از CA های Subordinate یا میانی برای صدور Certificate ها ، امنیت این ساختار را تا حدود زیادی بالا ببرید.

CA های وابسته یا Subordinate CA

CA هایی که به عنوان Root CA در ساختار قرار نمی گیرند به عنوان Subordinate CA یا CA های وابسته معرفی می شوند. اولین Subordinate CA ای که در ساختار شروع به کار کند ، Certificate خود را از Root CA دریافت می کند . اولین Subordinate CA می تواند از این کلید دریافت شده برای صدور Certificate های برای اطمینان از صحت سایر Subordinate CA ها استفاده کند. این Subordinate هایی که در بالاترین سطح قبل از Root CA قرار می گیرند به عنوان Intermediate CA یا CA های سطح میانی نیز شناخته می شوند. یک Intermediate CA برای Root CA به عنوان Subordinate CA شناخته می شود اما برای سایر CA هایی که در سلسله مراتب قرار دارند به عنوان CA مرجع شناخته می شود.

به Intermediate CA ها به عنوان Policy CA نیز اطلاق می شود ، این نامگذاری به این دلیل است که این CA می تواند به عنوان جدا کننده کلاس های Certificate که به وسیله Policy ها انجام می شود مورد استفاده قرار می گیرد. برای مثال ، تفکیکی Policy های یا Policy Separation شامل سطح اطمینانی است که CA ها برای شناسایی کاربرانی که در مناطق جغرافیایی مختلف از سرویس مورد نظر استفاده می کنند . یک Policy CA می تواند هم آنلاین باشد و هم آفلاین باشد. بسیاری از سازمان ها از یک Root CA و دو عدد Policy CA استفاده می کنند ، یکی برای پشتیبانی از کاربران داخلی و یکی دیگر برای پشتیبانی از کاربرانی که در بیرون از سازمان هستند.

سطح بعدی در ساختار سلسله مراتبی CA معمولا شامل Issuing CA ها یا CA های صادر کننده Certificate می باشد. Issuing CA ها برای Computer ها و User ها Certificate صادر می کنند و همیشه در حالت آنلاین قرار دارند. در بسیاری از ساختار های سلسله مراتبی CA پایین ترین سطح Subordinate CA ها با RA ها که مراکز ثبت نام هستند جایگزین می شوند

RA ها می توانند در نقش واسط CA ها برای احراز هویت شناسه User ای که درخواست Certificate داده است ، ثبت درخواست های ابطال Certificate و انجام عملیات بازیابی کلید یا Key Recovery مورد استفاده قرار بگیرند. برخلاف CA ها RA ها Certificate صادر نمی کنند و همچنین CRL تولید نمی کنند ، بلکه کلیه فعالیت هایی که انجام می دهند را از طریق CA ای که تحت امر آن هستند انجام می دهند . ساختار سلسله مراتبی CA مشابه شکل شماره یک شامل Root CA ، Policy CA و Issuing CA ها می باشد.

شکل شماره یک : ساختار سلسله مراتبی PKI و CA

استفاده از CA ها آفلاین

برقراری امنیت برای ساختار PKI یکی از مهمترین مسائل موجود است . اگر یک مهاجم بتواند به CA شما دسترسی پیدا کند ، حال چه بصورت فیزیک و یا بصورت شبکه ای ، می تواند کلید خصوصی CA را دریافت کرده و با استفاده از آن به اطلاعات حساسی در شبکه شما دسترسی پیدا کند. به خطر افتادن کلید یک CA در ساختار اعتبار و امنیت همان CA و تمامی CA هایی که در زیرمجموعه آن قرار می گیرند را زیر سئوال می برد .

به همین دلیل شما نبایستی Root CA ها را بصورت مستقیم به شبکه سازمان خود متصل کنید. برای اطمینان از قابل اعتماد بودن زیرساختار CA شما بایستی تمامی CA هایی که در نقش صادر کننده Certificate یا Issuing CA هستند را از قبیل Root CA و Intermediate CA ها را از مدار خارج کرده و در حالت آفلاین قرار دهید . با اینکار خطر و ریسک کشف رمز شدن کلید خصوصی CA تا حدود زیادی کم می شود.شما می توانید از روش های زیر CA را به حالت Offline در بیاورید :

با نصب و راه اندازی Standalone CA در یکی از ویندوز سرورهای 2000 یا 2003 یا 2008 یا 2012
بوسیله قطع کردن ارتباط فیزیکی سرور با شبکه
بوسیله خاموش کردن کامپیتور سرور
بوسیله غیرفعال کردن سرویس CA

مطمئن شوید که CA در حالت آفلاین در محلی امن و با حداقل دسترسی های مجاز نگهداری شود. توجه کنید که حتما Root CA ای که بصورت آفلاین ایجاد می کنید را در حالت Standalone و در یک شبکه Workgroup ایجاد کنید . ایجاد و راه اندازی Root CA در سروری که در عضویت دامین می باشد بعد از مدتی که شما CA را از شبکه قطع می کنید برای برقراری ارتباط مجدد بین CA و اکتیودایرکتوری به دلیل از بین رفتن Secure Channel موجود در این میان ، برای CA مشکل ایجاد خواهد کرد.

این مشکل به این دلیل است که رمز عبور حساب کامپیوتر یا Computer Account موجود در اکتیودایرکتوری هر 30 روز یکبار بایستی تعویض شود. به همین دلیل شما می توانید با عضویت سرور در یک Workgroup و آفلاین کردن آن از بروز چنین مشکلاتی جلوگیری کنید.نصب Root CA به شکل Enterprise Root CA به دلیل آفلاین شدن CA ممکن است مشکلاتی را برای بروز کردن اکتیودایرکتوری در هنگام آفلاین بودن CA ایجاد کند . بنابراین در هنگام ایجاد Root CA از مدل Enterprise استفاده نکنید.

زمانیکه قرار است یک CA به عنوان Offline CA در نظر گرفته شود ، شما همچنان قادر خواهید بود که Certificate ها و CRL های آن را در درون اکتیودایرکتوری منتشر کنید. شما بایستی Offline CA را هر چند وقت یکبار به حالت آنلاین در بیاورید که بتواند اطلاعات مربوط به CRL ها و تولید CRL جدید را بروز رسانی کند که این مورد معمولا بصورت برنامه ریزی شده برای Root CA انجام می شود. همچنین دلیل دیگری که شما بایستی در وهله های زمانی معین Root CA را به حالت آنلاین در بیاورید ، صدور Certificate برای Subordinate CA ها می باشد. به دلیل اینکه Offline CA ها معمولا حجم و تعداد کمی درخواست برای صدور Certificate در وهله های زمانی مختلف دارند ، هزینه نگهداری و مدیریت Offline CA ها به مراتب پایینتر از CA های دیگر می باشد.

تعیین تعداد CA های مورد نیاز در ساختار PKI

بعد از اینکه شما نیازهای کاربری و همچنین نرم افزارهای مرتبط با PKI را مشخص کردید ، می توانید به بررسی تعداد CA های مورد نیاز در ساختار PKI بپردازید.اگر سازمان شما به تعداد محدودی Certificate نیاز دارد و نیاز اساسی به این ساختار احساس نمی شود ، شما می توانید از تنها یک CA در ساختار استفاده کنید که همه نقش ها را بر عهده خواهد داشت. با استفاده از تنها یک CA شما می توانید ضمن استفاده از تمامی مواردی که از ترکیب های مختلف CA برداشت می شود

از Certificate Template ها نیز استفاده کنید. بهرحال اگر دسترسی پذیری و فعالیت های توزیع شده مربوط به Certificate Services برای شما دارای اهمین است ، شما بایستی از چندین CA در ساختار PKI استفاده کنید.شما همچنین زمانی می توانید از ترکیب چندین CA استفاده کنید که می خواهید وظایف مربوط به صدور Certificate و اهداف دیگر را در سرورها بصورت تفکیک شده استفاده کنید. برای تعیین تعداد CAهای مورد نیاز بایست به سئوالات زیر به ترتیب پاسخ دهید :

آیا شما فقط یک CA نیاز دارید ؟ اگر استفاده از Certificate در سازمان شما صرفا برای تعداد محدود و یا حتی فقط یک نرم افزار است و در یک محل محدود مورد استفاده قرار می گیرد و 100 توانایی های مورد نظر از یک ساختار PKI ایده آل مد نظر شما نیست و همچنین دسترسی پذیری CA یک امر حیاتی به حساب نمی آید ، شما می توانید فقط از یک سرور به عنوان CA استفاده کنید. در غیر اینصورت شما حتما و حداقل به یک Root CA و چندین Subordinate CA نیاز خواهید داشت.

اگر شما به بیش از یک عدد CA نیاز دارید به چه تعداد Root CA نیاز دارید ؟ معمولا و بر حسب پیشنهاد شما یک عدد Root CA دارید که به عنوان نقطه اصلی اعتماد یا Single Point Of Trust معرفی می شود. این بیشتر به این دلیل است که نگهداری و محافظت از Root CA ها در برابر سوء استفاده ها و مشکلات هزینه زیادی در بر دارد. استفاد از چندین سرور به عنوان Root CA دردسرهای نگهداری از آنها را به یکباره چندین برابر می کند.بهرحال سازمان هایی که از ساختارهای مدیریت توزیع شده استفاده می کنند و دارای قسمت های تجاری مجزایی می باشند به بیشتر از یک CA ریشه نیاز خواهند داشت و دردسرهای آن را هم قبول می کنند.

به چه تعداد Intermediate CA و Policy CA نیاز داریم ؟
به چه تعداد Issuing CA و RA نیاز داریم ؟

تعیین تعداد Intermediate CA ها و Issuing CA هایی که برای ساختار PKI شما لازم است بسته به فاکتورهای زیر است :

همانطور که در مقاله اول عنوان کردیم Certificate ها برای اهداف مختلفی از جمله امنیت در ایمیل ، احراز هویت در شبکه و موارد مشابهی از اینگونه استفاده می شوند ، هر کدام از این Certificate ها دارای قالب و Template مخصوص به خود هستند که بسته به نوع استفاده شما از Certificate های صادر شده استفاده از CA های جداگانه برای هر یک از سرویس های ذکر شده مدیریت هر یک از این موارد را که تفکیک می شوند بسیار ساده تر خواهد کرد.

تقسیم بندی های سازمانی و جغرافیایی می توانند در طراحی ساختار CA شما تاثیرگذار باشند ، شما برای سازمان ها و تقسیم بندی های سازمانی که در محل های فیزیکی دور از هم قرار گرفته اند ، ممکن است بخواهید خط مشی های خاص خود را طراحی کنید ، با استفاده از Subordinate CA های تفکیک شده به لحاظ سازمانی و جغرافیایی مدیریت Policy ها نیز براحتی تفکیک خواهد شد.

توزیع بار کاری ایجاد و صدور Certificate ها یکی از معیارهایی است که بایستی در نظر گرفته شود ، شما می توانید چندین Issuing CA در طراحی خود در نظر بگیرید به گونه ای که بار کاری صدور Certificate ها برای سایت ها و شبکه و سرورها بین آنها تقسیم شود و سرویس دهی بهتری داشته باشید.برای مثال ، اگر پهنای باند بین سایت های فیزیکی شما کم است شما می توانید یک Issuing CA در هر یک از سایت های خود قرار دهید تا کارایی و استفاده بهینه از Certificate Services در هر سایت انجام شود.

انعطاف پذیری تنظیمات نیز یکی دیگر از موارد مهم در تعیین تعداد CA های میانی می باشد. شما می توانید تناسب بین CA ها در خصوص پارامترهای محیطی مثل طول کلید ، حفاظت فیزیکی ، حفاظت در مقابل حملات شبکه ای و ... را با استفاده از ایجاد تعادل بین امنیت و قابلیت استفاده از آن CA ایجاد کنید. برای مثال شما می توانید کلیدها و Certificate های مربوط به CA های میانی و issuing CA هایی که دارای درجه ریسک بالایی هستند را در وهله های زمانی سریعتر و بدون از بین رفتن Trust Relationship بین CA ها و Root CA جدید سازی کنید.

بدون شک استفاده از سرویس های جایگزین برای Certificate Services نیز یک ملاک اصلی به حسای می آید. اگر یک Enterprise CA دچار مشکل شود ، سرویس جایگزین یا بهتر بگوییم سرور جایگزین می تواند سرویس های دچار مشکل شده را پشتیبانی کرده و سرویس را از دسترسی پذیری بالایی برخوردار کند.

سعی کنید همیشه در طراحی های سازمانی از تعداد معقولی و با توجه به نیازهای سازمانی خود ، CA و RA بکار ببرید. اگر سازمان کوچکی دارید و می دانید که بار کاری CAها صرفا بر عهده یک نفر خواهد بود از طراحی و پیاده سازی ساختار های پیچیده و گسترده خودداری کنید زیرا در نهایت به ضرر شما تمام خواهد شد و دردسرهای مدیریتی آن بر عهده خودتان می افتد. فراموش نکنید که اضافه شدن CA های زیاد با اینکه کارایی را افزایش می دهد اما از جهتی مدیریت سخت تر و نقاط ضعف امنیتی سیستم را نیز بیشتر خواهد کرد.

طرح مدیریت CA

در ادامه قصد داریم به شما روش ایجاد یک طرح مدیریتی CA را نمایش دهیم . قبل از اینکه شما هرگونه Certificate را بخواهید صادر کنید بایستی دارای یک طرح باشید که در آن چگونگی صدور Certificate ، تازه سازی یا Renew کردن Certificate و همچنین روش ابطال 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 شما به یک دامین کنترلر ویندوز سرور 2003 یا 2008 یا 2012 به عنوان سرور نیاز دارید و از طرفی به کلاینت هایی با سیستم عامل ویندوز 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 ویندوز سرور 2008 درخواست 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 در ویندوز سرور 2008 تعیین شده است برای 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 ویندوز سرور 2008 که استفاده از راهکار توزیع سنتی CRL ها مرسوم نیست ، از یک فرآیند آنلاین به نام OCSP برای مدیریت و توزیع وضعیت Certificate های باطل شده استفاده می شود. در ادامه در خصوص OCSP بیشتر صحبت خواهیم کرد.

لیست Certificate های باطل شده یا Certificate Revocation List

در برخی مواقع پیش می آید که CA باید Certificate صادر شده را قبلا از تاریخ انقضای آن باطل کند. زمانیکه یک Certificate باطل می شود ، CA یک شماره سریال از Certificate و همچنین دلیل باطل کردن Certificate را در درون CRL قرار می دهد . ویندوز سرور 2008 از دو نوع 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 استفاده کنید . برای کسب اطلاعات بیشتر در خصوص 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 در سیستم عامل ویندوز سرور 2008 و شیوه طراحی و پیاده سازی زیرساخت کلید عمومی پرداختیم ، کاملا طبیعی است که مبحث PKI اصلا در قالب یک مقاله قابل پوشش نیست و هدف من از ارائه این مقاله صرفا آشنایی اولیه با ساختار PKI های مایکروسافتی بوده است ، چه بسا برای هر یک از تعاریفی که ما در این مقاله عنوان کردیم بتوان یک کتاب کامل ارائه کرد ، در هر صورت امیدوارم کمی توانسته باشیم شما را با این مفاهیم آشنا کنم و در نهایت امیدوارم مورد توجه شما دوستان قرار گرفته باشد. ورزشکار باشید.

2 24

محمد نصیری

بنیانگذار انجمن تخصصی فناوری اطلاعات ایران ، هکر کلاه خاکستری ، کارشناس امنیت اطلاعات و ارتباطات

محمد نصیری هستم ، بنیانگذار انجمن تخصصی فناوری اطلاعات ایران و مجموعه توسینسو ، هکر قانونمند و کارشناس امنیت سایبری ، سابقه همکاری با بیش از 80 سازمان دولتی ، خصوصی ، نظامی و انتظامی در قالب مشاور ، مدرس و مدیر و ناظر پروژه ، مدرس دوره های تخصص شبکه ، امنیت ، هک و نفوذ ، در حال حاضر در ایران دیگه رسما فعالیتی غیر از مشاوره انجام نمیدم ، عاشق آموزش و تدریس هستم و به همین دلیل دوره های آموزشی که ضبط می کنم در دنیا بی نظیر هستند.

نظرات

البرز - کرج - شاهین ویلا - نبش خیابان هفتم شرقی - مجتمع تجاری مهرگان - طبقه 6 - واحد 704

زمان پاسخ گویی روز های شنبه الی چهارشنبه ساعت 9 الی 18

فقط به موضوعات مربوط به محصولات آموزشی و فروش پاسخ داده می شود

شماره تماس: 02634209662

پشتیبانی تلگرام: کلیک کنید

توسینسو (ToSinSo) مخفف کلمه های Total Single Solutions می باشد و یک مجموعه آموزشی تخصص محور در حوزه فناوری اطلاعات بصورت آنلاین بوده که بیش از ده سال از فعالیت آن به زبان فارسی می گذرد. ارائه بهترین منابع آموزش شبکه ، آموزش لینوکس ، آموزش برنامه نویسی ، آموزش مجازی سازی ، آموزش هک و تست نفوذ و امنیت اطلاعات با همکاری اساتید بین المللی و حرفه ای از جمله مهمترین خدمات آموزشگاه توسینسو می باشد.

کلیه حقوق این وب سایت متعلق به مجموعه توسینسو است