CSR به‌تنهایی ثبت‌نام نیست: آنچه یک CA وی‌پی‌ان باید بررسی کند

درخواست امضای گواهی یک کلید عمومی و یک subject درخواستی را حمل می‌کند که با کلید خصوصی متناظر امضا شده است. آن امضا اثبات می‌کند که درخواست‌دهنده کلید را در اختیار دارد. اثبات نمی‌کند که درخواست‌دهنده مستحق نام، دستگاه یا نقش VPN درخواستی است، و برخورد با آن به‌گونه‌ای که گویی چنین چیزی را اثبات می‌کند، همان راهی است که یک تیکت میز پشتیبانی به اعطای دسترسی تبدیل می‌شود.

دو مدل ثبت‌نام را باید بر اساس آنچه مقید می‌کنند سنجید، نه بر اساس پروتکلی که با آن سخن می‌گویند.

درخواست یک نام را ادعا می‌کند و آن را اثبات نمی‌کند

درخواست را بر اساس آنچه واقعاً دارد بخوانید: یک کلید عمومی، یک subject که درخواست‌دهنده برگزیده، و یک خودامضا روی هر دو. هیچ چیزی در آن ساختار به فهرست موجودی، دفتر حساب‌ها یا گردش تأیید شما ارجاع نمی‌دهد. subject‌ای مانند cn=finance-laptop رشته‌ای است که کسی تایپ کرده است. تا زمانی که فرایند صدور آن رشته را با سندی که به آن اعتماد دارد نسنجد، گواهی یک ادعا با امضای پیوست است. همین تمایز تمام دلیل وجود یک فرایند ثبت‌نام است.

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

مدل‌ها را بر اساس آنچه مقید می‌کنند مقایسه کنید

امضای دستی هر چیزی را که اپراتور به یاد دارد بررسی کند مقید می‌کند. یک سرویس ثبت‌نام خودکار درخواست احراز هویت‌شده را به تصمیمی مقید می‌کند که سرویس می‌تواند اجرا کند، و RFC 7030 یکی از چنین طرح‌هایی را توصیف می‌کند که در آن مشتری پیش از بازگرداندن گواهی احراز هویت می‌شود. تفاوتی که از یک ممیزی جان سالم به در می‌برد خودکارسازی نیست؛ بلکه این است که بررسی هویت درون مسیر صدور انجام می‌شود یا در کنار آن.

هر دو مدل هنوز باید به همان سه پرسش پاسخ دهند. چه کسی می‌پرسد، روی کدام دستگاه یا نقش، و برای چه مدت. سامانه تیکتی که پاسخ‌ها را ثبت می‌کند کار واقعی انجام می‌دهد؛ صفی که کسی در آن به یک نام مشترک خیره می‌شود انجام نمی‌دهد، هر‌چند گواهی بعداً با چه دقتی قالب‌بندی شود.

مدل را بر اساس شمار ثبت‌نام‌هایی که انتظار دارید و گردش دستگاه‌ها انتخاب کنید. چند سرور در سال می‌توانند بازبینی دستی با یک چک‌لیست نوشته‌شده را تحمل کنند. ناوگان لپ‌تاپ نمی‌تواند.

چرخه عمر را از نخستین صدور ثبت کنید

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

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

گواهی صادرشده را بررسی کنید، سپس دسترسی را

پس از ثبت‌نام، بررسی کنید چه چیزی صادر شده و تأیید کنید که به مرجعی که انتظار دارید زنجیره می‌شود. دو فرمان خطاهای رایج را پوشش می‌دهند: گواهی با کاربرد نادرست، و زنجیره‌ای که فقط کار می‌کند چون مشتری برای نادیده گرفتن اعتبارسنجی پیکربندی شده است.

openssl req -in client.csr -noout -verify -subject
openssl x509 -in client.crt -noout -subject -issuer -dates -ext extendedKeyUsage
openssl verify -CAfile ca.crt client.crt

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

پروفایلی که به دلیل نادرست کار می‌کند، مانند نام مشترک منطبق و بدون هیچ بررسی هویت، پس از حذف کنترلی که فکر می‌کردید دارید همچنان کار خواهد کرد.