طراحی سلسله مراتب CA

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

یک سلسله مراتب CA به خوبی طراحی شده مزایای زیر را ارائه می دهد:

• کنترل های امنیتی دانه ای متناسب با هر CA
• تقسیم وظایف اداری برای تعادل و امنیت بهتر بار
• استفاده از CAS با اعتماد محدود و قابل بازگشت برای عملیات روزانه
• دوره اعتبار و محدودیت مسیر گواهینامه

نمودار زیر یک سلسله مراتب CA ساده و سه سطح را نشان می دهد.

هر CA در درخت توسط یک گواهی X. 509 V3 با مرجع امضای (نماد نماد قلم و کاغذ) پشتیبانی می شود. این بدان معناست که به عنوان CA ، آنها می توانند گواهینامه های دیگری را که تابع آنها است ، امضا کنند. هنگامی که یک CA گواهی CA سطح پایین را امضا می کند ، مجوز محدود و قابل تغییر را در گواهی امضا شده به شما اعطا می کند. Root CA در سطح 1 گواهینامه های CA فرعی سطح بالا را در سطح 2 نشان می دهد. این CA به نوبه خود ، گواهینامه های مربوط به CAS را در سطح 3 که توسط مدیران PKI (زیرساخت های کلیدی عمومی) استفاده می شود که گواهینامه های ورودی نهایی را مدیریت می کنند ، علامت گذاری می کند.

امنیت در یک سلسله مراتب CA باید پیکربندی شود تا در بالای درخت قوی ترین باشد. این ترتیب از گواهی CA ریشه و کلید خصوصی آن محافظت می کند. مجریان ریشه CA به همه CAS فرعی و گواهینامه های نهایی در زیر آن اعتماد دارند. در حالی که خسارت موضعی می تواند ناشی از سازش گواهی ورودی نهایی باشد ، به خطر انداختن ریشه اعتماد به کل PKI را از بین می برد. CA های فرعی ریشه و سطح بالا فقط به ندرت استفاده می شوند (معمولاً برای امضای سایر گواهینامه های CA). در نتیجه ، آنها کاملاً کنترل و حسابرسی شده اند تا خطر کمتری از سازش را تضمین کنند. در سطوح پایین سلسله مراتب ، امنیت کمتر محدود کننده است. این رویکرد اجازه می دهد تا وظایف معمول اداری صدور و ابطال گواهینامه های نهایی برای کاربران ، میزبان رایانه و خدمات نرم افزاری باشد.

توجه داشته باشید

استفاده از ریشه CA برای امضای گواهی فرعی ، یک اتفاق نادر است که فقط در تعداد معدودی از شرایط رخ می دهد:

• وقتی PKI ایجاد می شود
• هنگامی که یک مجوز سطح بالا باید جایگزین شود
• هنگامی که یک لیست ابطال گواهینامه (CRL) یا پروتکل وضعیت گواهینامه آنلاین (OCSP) پاسخ دهنده نیاز به پیکربندی دارد

ریشه و سایر CA های سطح بالا به فرآیندهای عملیاتی بسیار ایمن و پروتکل های کنترل دسترسی نیاز دارند.

موضوعات

• اعتبار سنجی گواهی های موجودیت نهایی
• برنامه ریزی ساختار سلسله مراتب CA
• تنظیم محدودیت های طول در مسیر صدور گواهینامه

اعتبار سنجی گواهی های موجودیت نهایی

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

Trust store کتابخانه ای از CA های قابل اعتماد است که مرورگر یا سیستم عامل شامل آن است. برای یک PKI خصوصی، IT سازمان شما باید اطمینان حاصل کند که هر مرورگر یا سیستم قبلاً CA ریشه خصوصی را به فروشگاه اعتماد خود اضافه کرده است. در غیر این صورت، مسیر صدور گواهینامه قابل تایید نیست و در نتیجه خطاهای مشتری ایجاد می شود.

نمودار بعدی مسیر اعتبار سنجی را نشان می دهد که مرورگر هنگام ارائه گواهینامه X. 509 موجودیت نهایی دنبال می کند. توجه داشته باشید که گواهی موجودیت نهایی فاقد مجوز امضا است و فقط برای احراز هویت نهادی که مالک آن است عمل می کند.

مرورگر گواهی موجودیت نهایی را بررسی می کند. مرورگر متوجه می شود که گواهینامه امضایی از CA زیر مجموعه (سطح 3) را به عنوان اعتبار اعتماد خود ارائه می دهد. گواهینامه های CAهای تابعه باید در همان فایل PEM گنجانده شوند. از طرف دیگر، آنها همچنین می توانند در یک فایل جداگانه باشند که حاوی گواهینامه هایی است که زنجیره اعتماد را تشکیل می دهند. پس از یافتن این موارد، مرورگر گواهینامه CA زیرمجموعه (سطح 3) را بررسی می کند و متوجه می شود که امضایی از CA تابع (سطح 2) ارائه می دهد. به نوبه خود، CA تابع (سطح 2) یک امضا از CA ریشه (سطح 1) به عنوان اعتبار اعتماد خود ارائه می دهد. اگر مرورگر نسخه ای از گواهی CA ریشه خصوصی را که از قبل در فروشگاه اعتماد خود نصب شده است بیابد، گواهینامه موجودیت نهایی را به عنوان مورد اعتماد تأیید می کند.

به طور معمول، مرورگر هر گواهی را در برابر فهرست ابطال گواهی (CRL) نیز بررسی می کند. گواهی منقضی شده، لغو شده یا پیکربندی نادرست رد می شود و اعتبارسنجی ناموفق است.

برنامه ریزی ساختار سلسله مراتب CA

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

از نظر تئوری ، یک CA ریشه ، که هیچ (پارامتر pathlenconstraint) ندارد ، می تواند سطح نامحدودی از CAS فرعی را مجاز کند. یک CA فرعی می تواند به همان تعداد CA های فرعی کودک که توسط پیکربندی داخلی آن مجاز است ، داشته باشد. سلسله مراتب مدیریت شده AWS Private CA از مسیرهای صدور گواهینامه CA تا پنج سطح عمق پشتیبانی می کند.

ساختارهای CA به خوبی طراحی شده دارای چندین مزیت هستند:

• کنترل های اداری جداگانه برای واحدهای سازمانی مختلف
• امکان تفویض دسترسی به CAS فرعی
• یک ساختار سلسله مراتبی که از CAS سطح بالاتر با کنترل های امنیتی اضافی محافظت می کند

دو ساختار مشترک CA همه اینها را انجام می دهند:

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

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

ساختارهای CA کمتر رایج شامل موارد زیر است:

• چهار یا بیشتر سطح CA هرچند کمتر از سلسله مراتب سه سطح مشترک است ، سلسله مراتب CA با چهار یا بیشتر سطح امکان پذیر است و ممکن است لازم باشد که به نمایندگی اداری اجازه دهد.
• یک سطح CA: Root CA فقط این ساختار معمولاً برای توسعه و آزمایش در صورت نیاز به زنجیره ای کامل اعتماد استفاده می شود. در تولید استفاده می شود ، غیرعادی است. علاوه بر این ، این بهترین روش برای حفظ سیاستهای امنیتی جداگانه برای ریشه CA و CAS که گواهینامه های انتهای نهایی را صادر می کند ، نقض می کند. با این حال ، اگر در حال حاضر گواهینامه هایی را مستقیماً از ریشه CA صادر می کنید ، می توانید به AWS Private CA مهاجرت کنید. انجام این کار مزایای امنیتی و کنترل را در مورد استفاده از Root CA که با OpenSSL یا سایر نرم افزارها اداره می شود ، فراهم می کند.

نمونه ای از PKI خصوصی برای یک سازنده

در این مثال ، یک شرکت فناوری فرضی دو محصول اینترنت از چیزها (IoT) ، یک لامپ هوشمند و یک توستر هوشمند تولید می کند. در حین تولید ، هر دستگاه یک گواهی انتهای نهایی صادر می شود تا بتواند با تولید کننده به طور ایمن از طریق اینترنت ارتباط برقرار کند. PKI این شرکت همچنین زیرساخت های رایانه ای خود را از جمله وب سایت داخلی و خدمات رایانه ای مختلف خود میزبان که دارای امور مالی و تجاری است ، ایمن می کند.

در نتیجه ، سلسله مراتب CA از نزدیک این جنبه های اداری و عملیاتی تجارت را مدل می کند.

این سلسله مراتب شامل سه ریشه ، یکی برای عملیات داخلی و دو مورد برای عملیات خارجی (یک ریشه CA برای هر خط تولید). همچنین طول مسیر صدور گواهینامه را نشان می دهد ، با دو سطح CA برای عملیات داخلی و سه سطح برای عملیات خارجی.

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

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

تنظیم محدودیت های طول در مسیر صدور گواهینامه

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

• کالیفرنیا - آیا گواهینامه یک CA را تعریف می کند. اگر این مقدار نادرست باشد (پیش فرض) ، گواهی نامه نهایی است.
• Pathlenconstraint-حداکثر تعداد CA های زیر مجموعه سطح پایین که می توانند در یک زنجیره اعتماد معتبر وجود داشته باشند. گواهی انتهای ورودی شمارش نمی شود زیرا گواهی CA نیست.

گواهی ریشه CA به حداکثر انعطاف پذیری نیاز دارد و شامل محدودیت طول مسیر نیست. این به ریشه اجازه می دهد تا یک مسیر صدور گواهینامه از هر طول را تعریف کند.

توجه داشته باشید

AWS خصوصی CA مسیر صدور گواهینامه را به پنج سطح محدود می کند.

CA های فرعی بسته به موقعیت مکانی در قرار دادن سلسله مراتب و ویژگی های مورد نظر ، مقادیر pathlenconstraint برابر یا بیشتر از صفر دارند. به عنوان مثال ، در یک سلسله مراتب با سه CAS ، هیچ محدودیت مسیر برای ریشه CA مشخص نشده است. اولین CA فرعی دارای طول مسیر 1 است و بنابراین می تواند CAS کودک را امضا کند. هر یک از این کودکانی که لزوماً باید دارای یک مقدار حرکات صفر باشند. این بدان معنی است که آنها می توانند گواهینامه های ورودی نهایی را امضا کنند اما نمی توانند گواهینامه های اضافی CA صادر کنند. محدود کردن قدرت برای ایجاد CAS جدید یک کنترل مهم امنیتی است.

نمودار زیر این انتشار از اقتدار محدود را در سلسله مراتب نشان می دهد.

در این سلسله مراتب چهار سطحی ، ریشه بدون محدودیت است (مثل همیشه). اما اولین CA فرعی دارای ارزش Pathlenconstraint 2 است که باعث می شود CAS کودک خود از بیش از دو سطح عمیق تر حرکت کند. در نتیجه ، برای یک مسیر صدور گواهینامه معتبر ، مقدار محدودیت باید در دو سطح بعدی به صفر کاهش یابد. اگر یک مرورگر وب با یک گواهی انتهای ورودی از این شاخه که دارای طول مسیر بیشتر از چهار است برخورد کند ، اعتبارسنجی از بین می رود. چنین گواهی می تواند نتیجه یک CA به طور تصادفی ایجاد شده ، یک CA نادرست و یا صدور غیرمجاز باشد.

مدیریت طول مسیر با قالب ها

AWS Private CA قالب هایی را برای صدور گواهینامه های ریشه ، فرعی و ورودی نهایی ارائه می دهد. این الگوها بهترین روشها را برای مقادیر اساسی محدودیت ها ، از جمله طول مسیر ، محاصره می کنند. الگوهای زیر شامل موارد زیر است:

• rootcacertificate/v1
• Subordinatecacertificate_Pathlen0/V1
• SubordinateCacertificate_Pathlen1/V1
• Subordinatecacertificate_Pathlen2/V1
• SubordinateCacertificate_Pathlen3/V1
• endentitycertificate/v1

در صورت تلاش برای ایجاد CA با طول مسیر بزرگتر از یا مساوی با طول مسیر گواهی CA صادر کننده ، API API IssuEcertificate خطایی را بازگرداند.

برای اطلاعات بیشتر در مورد الگوهای گواهی ، به درک الگوهای گواهی مراجعه کنید.

خودکار سازی تنظیم سلسله مراتب CA با AWS CloudFormation

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