یکی از مهمترین مباحثی که در خصوص رمزنگاری داده ها وجود دارد زیرساختار کلیک عمومی یا PKI است، این نوع رمزنگاری از نوع نامتقارن است که دارای دو کلید است که یکی برای رمزنگاری و دیگری برای رمزگشایی استفاده می شود، معمولا تا نامی از ساختار PKI در سیستم عامل های مایکروسافت می آید به فکر سختی ها و ابهاماتی می افتیم که همیشه در این مسئله جزئی از کار هستند، اکثر ایرانی هایی که در راه اندازی PKI دستی دارند و در سازمان خود از PKI های مایکروسافتی استفاده می کنند، از مفاهیم موجود در آن اطلاعاتی ندارند و صرفا آن را نصب می کنند، در این سری مقالات ضمن بررسی چیستی PKI به بررسی و طراحی این ساختار بصورت اصولی در سیستم عامل های مایکروسافت خواهیم پرداخت.
مقاله: طراحی و معماری زیرساخت کلید عمومی یا PKI قسمت اول
مقاله: طراحی و معماری زیرساخت کلید عمومی یا PKI قسمت دوم
مقاله: طراحی و معماری زیرساخت کلید عمومی یا PKI قسمت سوم
در شبکه های تحت سیستم عامل ویندوز سرور زیرساخت کلید عمومی یا PKI به یک یا چندین Certificate Authority یا CA گفته می شود که از طریق سرویس Active Directory Certificate Services پیاده سازی شده باشند. تعجب نکنید در خصوص تمامی این واژه ها در ادامه توضیحات کاملی را ارائه خواهیم داد اما توجه کنید که پیاده سازی PKI به همین سادگی ها نیست که صرفا در Server Manager یک Role نصب کنید و کار تمام شود. برای بیشتر سازمان های متوسط و رو به بزرگ پیاده سازی PKI نیازمند طراحی اولیه و تهیه مستندات است.
شناسایی نیازمندیهای PKI
مدت ها بود که استفاده از زیر ساختار PKI در سازمان ها چندان معمول نبود تا اینکه اکثر نرم افزارهای کاربردی و سرویس های شبکه برای بالا بردن سطح امنیتی خود استفاده از PKI را در زیرساخت نرم افزاری خود به عنوان یک الزام قرار دادند و این خود دلیلی بود که سازمان ها نیز به سمت استفاده از PKI بروند. قطعا اگر سازمان شما از استانداردهای بین المللی امنیت اطلاعات مانند ISO 27001 استفاده می کند و یا حداقل چیزی به عنوان خط مشی امنیت سازمان وجود دارد استفاده از 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 های ویندوز سرور صادر می شوند بایستی دارای یک سری پارامترهای امنیتی پیشفرض باشند. اما گاهی برای شما پیش می آید که می خواهید برای گروه خاصی که در شبکه فعالیت می کنند تنظیماتی انجام دهید که طول کلید خصوصی آنها و عمر گواهینامه یا 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 در ویندوز سرور وجود دارد به نام 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 یا 2012 یا 2016 کنید بایستی یک سری آماده سازی های اولیه و همچنین نیازمندی ها را پیشبینی و انجام دهید، این آماده سازی ها به شرح زیر می باشد:
تعیین تعداد 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 های ویندوز سرور و استفاده از تمامی امکاناتی که این 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 براحتی اضافه کنید.
