بسیاری از قطعیهای قابلپیشگیری از یک مسئله ساده شروع میشوند: گواهی SSL/TLS منقضی شده است. ممکن است سرویس از نظر CPU، شبکه و Application سالم باشد، اما Browser، API Client یا سرویس داخلی اتصال را رد کند. در سازمانی که دهها یا صدها Certificate روی Web Server، Load Balancer، Application Gateway، VPN و سرویسهای داخلی دارد، مدیریت دستی تاریخ انقضا بهسرعت به Blind Spot تبدیل میشود.
Certificate Lifecycle Management با Key Manager Plus برای متمرکزکردن Inventory، Discovery، Expiry Monitoring، Renewal و Audit گواهیها و کلیدهای سازمانی استفاده میشود تا گواهی منقضیشده به Incident تبدیل نشود.
مسئله اصلی فقط Expiry نیست
Expiry مهم است، اما Lifecycle گواهی از چند مرحله تشکیل میشود: Discovery، Ownership، Issuance، Deployment، Monitoring، Renewal و در نهایت Revocation یا Retirement.
| مرحله | ریسک در صورت ضعف | کنترل |
|---|---|---|
| Discovery | Certificate ناشناخته | Inventory متمرکز |
| Ownership | مسئول نامشخص | Owner Assignment |
| Monitoring | Expiry ناگهانی | Alert |
| Renewal | Downtime | Renewal Workflow |
| Revocation | Credential Risk | Controlled Retirement |
Certificate Discovery چرا حیاتی است؟
اولین مشکل این است که تیم امنیت نمیداند چند Certificate دارد. گواهیها ممکن است روی IIS، Apache، Nginx، Load Balancer، Java Keystore یا دستگاه شبکه پراکنده باشند. Key Manager Plus برای کشف و Inventory گواهیهای SSL/TLS و کلیدهای SSH طراحی شده است.
سناریو: گواهی API نیمهشب منقضی میشود
فرض کنید API مالی بین دو سیستم داخلی با TLS محافظت میشود. Certificate در نیمهشب Expire میشود و از صبح همه Integrationها Fail میشوند. مانیتورینگ Application ممکن است Failure را ببیند، اما علت اصلی Certificate است.
اگر Expiry Alert چند هفته قبل به Owner ارسال شود، این Incident اصولاً نباید رخ دهد.
Expiry Window را چندمرحلهای تعریف کنید
یک Alert در روز آخر کافی نیست. مدل بهتر:
- ۶۰ روز مانده: اطلاع اولیه؛
- ۳۰ روز مانده: Ticket Renewal؛
- ۱۴ روز مانده: Escalation؛
- ۷ روز مانده: High Priority؛
- ۳ روز مانده: Critical.
مقادیر دقیق باید با CA، Vendor و Change Window سازمان هماهنگ شوند.
Owner و Business Service را ثبت کنید
Certificate بدون Owner، حتی اگر Alert داشته باشد، باز هم خطرناک است. Inventory باید حداقل شامل:
- CN/SAN؛
- Issuer؛
- Expiry Date؛
- Host/Port؛
- Application Owner؛
- Business Service؛
- Environment؛
- Renewal Method.
Wildcard Certificate؛ سادهتر اما پرریسکتر
Wildcard مدیریت را ساده میکند، اما Private Key آن ارزش بیشتری پیدا میکند. اگر Key در چند Server کپی شود، سطح Exposure افزایش مییابد. Key Manager Plus کمک میکند Keyها و Certificateها متمرکزتر مدیریت و Audit شوند.
Private Key Security
Certificate بدون Private Key کاربرد ندارد، اما افشای Private Key میتواند اعتماد TLS را از بین ببرد. دسترسی به Key باید حداقلی، ثبتشده و Role-based باشد.
Renewal Workflow را به Change Management وصل کنید
تمدید Certificate در Production معمولاً نیاز به Deploy و Reload/Restart سرویس دارد. بنابراین Renewal فقط کار PKI نیست؛ Change عملیاتی هم هست.
برای محیطهای حساس، Ticket باید شامل Certificate، Target Host، Window، Rollback Plan و Test بعد از Deployment باشد. در صورت استفاده از ServiceDesk Plus، میتوان این فرآیند را به Change Management متصل کرد؛ منابع عملی در Service Desk مدانت در دسترس است.
Certificate Expiry با Monitoring چه تفاوتی دارد؟
ابزار Monitoring ممکن است فقط نزدیکشدن Expiry را Alert کند. Certificate Lifecycle Management علاوه بر Alert، Inventory، Ownership، Renewal Process و مدیریت Key را پوشش میدهد.
SSH Key Management را جدا نبینید
Key Manager Plus علاوه بر Certificate، برای مدیریت SSH Key نیز طراحی شده است. SSH Keyهای قدیمی، بدون Owner یا مشترک بین چند Admin میتوانند مشابه Passwordهای ثابت به Risk تبدیل شوند.
| دارایی | ریسک | کنترل |
|---|---|---|
| SSL Certificate | Expiry / Trust Failure | Discovery + Renewal |
| Private Key | Compromise | Access Control |
| SSH Key | Persistent Access | Inventory + Rotation |
Certificate Hygiene؛ چه مواردی را Review کنیم؟
- Certificate نزدیک Expiry؛
- Self-signed غیرضروری؛
- Weak Signature Algorithm؛
- Key Length نامناسب؛
- Certificate بدون Owner؛
- Duplicate/Unused Certificate؛
- Certificate روی Host بازنشسته.
Runbook پیشنهادی
- Discovery دورهای انجام شود.
- Owner و Service برای هر Certificate ثبت شود.
- Expiry Alert چندمرحلهای فعال شود.
- Renewal Ticket خودکار یا نیمهخودکار ساخته شود.
- Certificate جدید روی Pilot/Pre-production تست شود.
- Deployment در Change Window انجام شود.
- TLS Handshake و Application Health بعد از تغییر بررسی شود.
- Certificate قدیمی Retire شود.
KPIهای مفید
- Certificateهای کمتر از ۳۰ روز تا Expiry؛
- Certificate بدون Owner؛
- تعداد Renewal Failure؛
- Mean Time to Renew؛
- SSH Keyهای قدیمی؛
- Certificateهای Self-signed یا Weak.
ارتباط با PAM360
در معماری Privileged Access گستردهتر، PAM360 نیز قابلیتهای Key و Certificate Management دارد. Key Manager Plus زمانی مناسب است که تمرکز اصلی سازمان روی مدیریت تخصصی SSH Key و SSL/TLS Certificate باشد. برای شناخت مسیر PAM میتوانید مقاله SSH Command Control در PAM360 و صفحه PAM360 مدانت را ببینید.
نکات کلیدی
- Certificate Expiry یک Incident کاملاً قابلپیشگیری است.
- Inventory بدون Owner کافی نیست.
- Renewal باید به Change Management متصل شود.
- Private Key و SSH Key بخشی از همان Risk Surface هستند.
- Alert باید چند هفته قبل از Expiry آغاز شود.
منابع
سخن پایانی
گواهی SSL/TLS یک فایل فراموششدنی نیست؛ بخشی از زنجیره اعتماد سرویس است. وقتی Inventory، Owner، Expiry و Renewal در یک Lifecycle مدیریت شوند، احتمال قطعی ناشی از Certificate بهطور محسوسی کاهش مییابد.
مدانت خدمات استعلام و خرید لایسنس Key Manager Plus، Discovery گواهیها، طراحی Certificate Lifecycle، مدیریت SSH Key، استقرار، Integration و پشتیبانی ارائه میکند. برای استعلام قیمت به صفحه لایسنس ManageEngine مدانت و برای طراحی معماری به تماس با مدانت مراجعه کنید.
