کلید ریشهٔ CA داخلی سازمان شما الان کجاست؟ در بیشتر بازدیدهایی که داشته‌ایم، پاسخ دقیقی برای این سؤال نبود. پیش از خرید HSM، باید بدانید کدام کلیدها را می‌خواهید از دیسک سرورها بیرون بیاورید. در یکی از همین بازدیدها، فایل کلید ریشه در پوشهٔ پشتیبان یک ماشین مجازی بود و کلید امضای کد روی سرور Build.
ماجرای این هفتهٔ eMudhra، که کلیدهای ضعیف هشت CA میانی‌اش از فهرست اعتماد حذف شد، یک یادآوری جدی بود: اعتماد به گواهی، به اندازهٔ امنیت کلید خصوصی آن است.
ریشهٔ آفلاین: سرور ریشه خاموش و جدا از شبکه، کلید داخل HSM و فقط در مراسم کلید مستند روشن شود.
CA صادرکننده روی HSM شبکه‌ای: AD CS از طریق KSP به HSM وصل شود؛ کلید هیچ‌وقت بیرون نمی‌آید. دو دستگاه به‌صورت HA.
جداسازی وظایف: مدیر CA، مدیر HSM و ممیز سه نفر جدا؛ کارهای حساس با سهمیهٔ چندنفره.
از ژوئن ۲۰۲۳ کلید گواهی‌های امضای کد عمومی باید در سخت‌افزاری با سطح حداقل FIPS 140-2 Level 2 باشد. برای کلیدهای داخلی هم همین منطق درست است: سرور Build فقط هش فایل را برای امضا بفرستد و هر امضا لاگ شود.
سقف عمر گواهی TLS عمومی امسال ۲۰۰ روز شد، سال بعد ۱۰۰ روز و از ۲۰۲۹ فقط ۴۷ روز است. دو کار را از همین حالا شروع کنید:
رمزگشایی TLS را روی ADC متمرکز کنید تا کلید در جاهای کمتری باشد.
صدور و تمدید را با ثبت‌نام خودکار AD CS و پروتکل ACME خودکار کنید.
هر سال فرض کنید کلید CA صادرکننده لو رفته است. ابطال، صدور دوباره و به‌روزرسانی CRL چقدر طول می‌کشد؟ پاسخ این سؤال، میزان آمادگی واقعی شماست.
یک اشتباه رایج را هم جدی بگیرید: بسیاری از سازمان‌ها HSM می‌خرند، اما کلید قدیمی را فقط وارد دستگاه می‌کنند و فایل اصلی را روی سرور نگه می‌دارند. در این حالت عملاً چیزی عوض نشده است. بهتر است کلید تازه داخل خود HSM ساخته شود و گواهی‌ها با آن دوباره صادر شوند. یک HSM تنها بدون پشتیبان هم خطرناک است؛ خرابی آن یعنی از دست رفتن کلید CA.
در نسخهٔ کامل، فهرست پنج دسته کلید، معیارهای انتخاب HSM، چهار اشتباه رایج و یک چک‌لیست هشت‌مرحله‌ای را آورده‌ام.
نسخهٔ کامل این مطلب همراه با چک‌لیست اقدام در این نشانی منتشر شده است؛ آن را در نوار آدرس مرورگر وارد کنید: symantecland.com/enterprise-pki
— کاظم مرتضوی، مشاور مستقل امنیت شبکه
