Active Directory certificate Servicesکد 640-70

ایجاد سلسله مراتب در CA ها – CA Hierarchy

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

همانطور که می دانید، هر سناریوی طبقاتی و سلسله مراتبی، از چندین طبقه یا مرحله تشکیل شده است. این تعداد طبقه به چند فاکتور بستگی دارد. شما می بایست اندازه و توزیع منطقه ای شبکه و Trust relationship هایی که بین CA ها و سرورهای مسئول نگهداری certificate ها را بررسی کنید. به خاطر داشته باشید که هر زمانی یک certificate آماده و صادر شد، می بایست از طریق CRL یا online responder معتبر شود تا قابل استفاده گردد؛ بنابراین شما می بایست با برخی از سطوح یا طبقات ارتباط داشته باشید.

حال می بایست به مواردی بپردازید که نصب AD CS شما را تحت شعاع قرار می دهد. آیا شما با افراد یا شبکه هایی در خارج از شبکه شما در ارتباط خواهید بود؟ از smart card استفاده خواهید کرد یا خیر؟ از شبکه های وایرلس استفاده می کنید؟ از IPsec یا SSTP جدید استفاده می کنید؟ بطور کلی، شما نیاز دارید که همیشه هویت یک تجهیز، برنامه یا یک کاربر را مشخص کنید که توسط AD CS یا CA های غیر مایکروسافتی انجام می پذیرد.

پس از پاسخ به این سوالات و تصمیم گیری درباره نحوه پیاده سازی آن، می توانید سلسله مراتب CA را پیاده سازی کنید. بنابراین برای اجرای آن:

  • ایجاد سلسله مراتب یک طبقه ای (one-tiered hierarchy)  – فقط در موارد خیلی نادر از این حالت استفاده می شود. در این حالت، یک CA هم root CA بوده و هم CA صادر کننده certificate. یک root CA در واقع زنجیره اصلی trust در PKI است که مسیر آغازین trust در امنیت یک دامین از اینجا شروع می شود. تمامی کاربران، برنامه ها و یا کامپیوترهایی که نیاز به certificate دارند، به root CA اعتماد و trust داشته که خب در این صورت به تمامی certificate های صادر شده trust و دسترسی خواهند داشت. پیاده سازی این سلسله مراتب در سناریوها و محیط های عملی توصیه نمی شود، زیرا دسترسی به این سرور به معنای دسترسی به کل ساختار PKI خواهد بود. جایگزین کردن به root CA مورد تهاجم بسیار کار مشکلی است.

certificate services 1

  • ایجاد سلسله مراتب دوگانه (two-tiered hierarchy) با یک root CA و تعدادی CA صادر کننده – هنگامی که شما نیاز دارید از root CA خود محافظت کنید اما اندازه سازمان و هدف این پیاده سازی پیچیدگی این سلسله مراتب را ضمانت نمیکند؛ می توانید از این حالت استفاده کنید. در این حالت می توانید root CA را آفلاین کنید. این حالت بیشترین کاربرد را در بین سازمان ها دارد. هنگامی که root CA آفلاین است، private key های root CA بیشتر محافظت می شوند. Two-tier hierarchy

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

certificate services 2

 

  • ایجاد سلسله مراتب سه گانه (three-tiered hierarchy) – با یک root CA، یک یا چند intermediate CA و چند CA صادر کننده، می توانید PKI پیچیده و بزرگی ایجاد کنید؛ که برای زمانی مناسب است که شما نیاز به امنیت و قابلیت دسترسی بسیار بالایی برای CA ها صادر کننده certificate و مدیریت آنها دارید. در این حالت، root CA آفلاین، CA های صادر کننده آنلاین و یک سری CA های میانی که بین این دو CA قرار گرفته اند. قرار گیری این CA ها میانی یا intermediate می تواند به چند دلیل باشد: اولین دلیل می تواند این باشد که به عنوان دومین دسته، وظیفه CA policy را به عهده گیرد. به عنوان مثال، یک policy CA در واقع certificate هایی را برای CA های صادر کننده خاصی (CA هایی که نوع خاصی از certificate ها را صادر میکنند) صادر می کند. Policy CA می تواند به عنوان مرز مدیریتی عمل کند.

certificate services 3

 

  • ایجاد بیش از سه سطح فقط در شرکت های بسیار بزرگ و پیچیده پیاده سازی شده و مدیریت می شود.

خلاصه این چند مدل پیاده سازی در جدول زیر آمده است که کدام سرورها در کدام حالت آنلاین یا آفلاین هستند:

certificate services 4

مشاهده بیشتر

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

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

دکمه بازگشت به بالا