پرسش گواهی در AWS Client VPN به‌عنوان پرسش محصول مطرح می‌شود، در حالی که در واقع پرسش عملیاتی است. هر یک از سه چیدمان معمول یک تونل فعال را حفظ می‌کند: یک CA سازمانی موجود، یک صادرکننده خودگردان اختصاصی، یا AWS Private CA. تفاوت آن‌ها در این است که چه کسی دستگاه را تأیید می‌کند، چه کسی کلید امضا را نگه می‌دارد، و چه کسی وقتی لپ‌تاپ در ساعتی نامناسب گم می‌شود پاسخ می‌دهد. گزینه‌ای را انتخاب کنید که بتوانید مسئولش را نام ببرید.

AWS برای احراز هویت با گواهی به Private CA نیاز ندارد. قرار دادن گواهی سرور در ACM یک گام استقرار است، نه فرایند ثبت‌نام.

سه شرطی که آن را تعیین می‌کنند

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

به ترتیب آن‌ها را بررسی کنید. پریدن مستقیم به مقایسه هزینه همان چیزی است که تیم‌ها را با یک CA مدیریت‌شده و بدون کسی که بداند گواهی لپ‌تاپ بعدی را چه کسی صادر می‌کند رها می‌کند.

OptionYou still ownFits when
Existing organizational CAEnrollment, approvals, revocation listA device process already exists
Self-run issuerSigning-key custody, backups, revocation listYou can staff key custody
AWS Private CAPolicy, permissions, certificate deliveryYour PKI already lives in AWS

شرط یکم: آیا ثبت‌نام از قبل وجود دارد؟

اگر سازمان شما از قبل CA‌ای با مسیر تأییدشده ثبت‌نام دستگاه اداره می‌کند، صدور گواهی‌های کلاینت Client VPN از آن کوتاه‌ترین مسیر است. تأییدها، فرایند و سوابق دارایی از قبل آنجاست. یک صادرکننده فرعی اختصاصی زیر آن سلسله‌مراتب معمولاً بهتر از CA صادرکننده عمومی است، زیرا به VPN مرز اعتماد خودش و فهرست ابطال خودش را می‌دهد. آن فهرست را از بقیه سلسله‌مراتب جدا نگه دارید تا یک حادثه VPN تغییر در کل PKI را تحمیل نکند.

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

شرط دوم: آیا می‌توانید کلید امضا را اداره کنید؟

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

AWS Private CA آن نگهداری را به یک سرویس مدیریت‌شده منتقل می‌کند. سیاست ثبت‌نام، گام تأیید یا تحویل گواهی به دستگاه را منتقل نمی‌کند.

شرط سوم: ابطال چگونه می‌رسد؟

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

این تمدید را به یک مورد پایش با مسئول تبدیل می‌کند، نه کاری که هنگام راه‌اندازی تمام می‌شود. پیش از آنکه واقعاً به این سازوکار نیاز پیدا کنید، یک گواهی آزمایشی را سرتاسر ابطال کنید.

چیزی که هیچ‌کدام از گزینه‌ها حذف نمی‌کند

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

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

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

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

مقالات مرتبط