اگر از یک سازمان بپرسیم «کجا RSA یا ECC استفاده میکنید؟» پاسخ معمولاً ناقص است. بخشی در Certificateها دیده میشود، بخشی داخل Application Library، بخشی در VPN و SSH و بخشی در Code Signing یا تجهیزات. Crypto Inventory تلاش میکند این تصویر پراکنده را به یک موجودی قابلمدیریت تبدیل کند.
Crypto Inventory فقط لیست Certificate نیست
Certificate Inventory نقطه شروع خوبی است، اما Cryptography در Protocol، Key، Library، Service و Data Flow هم وجود دارد. NCCoE تعریف Inventory را بهصورت رکورد توصیفی از Cryptography مورد استفاده در System، Application، Service، Device و Data Flow مطرح میکند.
فیلدهایی که واقعاً به درد Migration میخورند
| فیلد | چرا مهم است؟ |
|---|---|
| Asset / Application | بدانیم Cryptography متعلق به کدام سیستم است. |
| Owner | بدون Owner هیچ Migration Task صاحب ندارد. |
| Algorithm / Key Type | برای تشخیص Quantum-vulnerable یا Legacy. |
| Protocol / Use | TLS، SSH، VPN، Signing یا Encryption. |
| Certificate Chain / Expiry | برای برنامه Renewal و PKI Dependency. |
| Data Lifetime | برای HNDL Risk. |
| Vendor / Version | برای PQC Readiness و Upgrade Path. |
| Exposure | Public، Internal، Partner، DMZ. |
| Migration Complexity | برای برنامهریزی Waveها. |
Discovery را از کجا شروع کنیم؟
- اسکن TLS Endpointهای داخلی و خارجی.
- جمعآوری Certificate از Windows/Linux Serverها، Load Balancerها و Applianceها.
- بررسی CA/PKI و Certificate Templateها.
- Inventory پروتکلهایی مانند SSH، IPsec، VPN و S/MIME.
- جستوجوی Dependencyهای Cryptographic در Application و Middleware.
- بررسی HSM، Code Signing، Firmware Signing و Device Certificateها.
چرا Excel بهتنهایی کافی نیست؟
Excel برای شروع Pilot بد نیست؛ ولی Inventory باید Change را دنبال کند. Certificate جدید، Server جدید، Upgrade یا Application Release میتواند وضعیت را عوض کند. برای محیط بزرگ، Discovery تکرارشونده و اتصال Inventory به Asset/Owner و Risk بهتر از Snapshot دستی است.
Crypto Inventory و QShield
در یک محصول تخصصی Crypto Inventory، ارزش واقعی از «کشف» شروع میشود اما به «اولویتبندی» ختم میشود: Certificate، TLS Endpoint، Algorithm، HNDL Risk و Migration Priority باید در یک مدل قابلجستوجو و گزارش قرار بگیرند تا تیم اجرایی بداند اول سراغ چه چیزی برود.
Asset بدون Owner نداریم یا درصد آنها مشخص است.
Certificateهای Expired/Weak جداگانه مشخصاند.
Public-Key Algorithmها Query میشوند.
External-facing TLS Endpointها پوشش داده شدهاند.
Long-lived Data به سیستمهای رمزنگاریشده نگاشت شده است.
Inventory برنامه Refresh دورهای دارد.
Inventory را به یک Data Model تبدیل کنید
یک Inventory مفید باید قابلیت Query داشته باشد. مثلاً بتوانید بپرسید: «همه Certificateهای RSA روی سرویسهای Internet-facing که Owner آنها Finance است و تا ۱۸ ماه آینده Expire میشوند کداماند؟» اگر پاسخ این سؤال نیازمند سه فایل Excel و تماس با پنج تیم باشد، Inventory هنوز عملیاتی نشده است.
رابطهها از خود Asset مهمتر میشوند
Certificate به یک Service وابسته است، Service روی یک Host اجرا میشود، Host متعلق به یک Business Owner است، و Business Service یک Data Classification دارد. برای PQC Migration این Relationshipها مهماند؛ چون اولویت فقط از Algorithm نمیآید.
چه چیزهایی را داخل Inventory ذخیره نکنیم؟
- Private Key Material یا Secret واقعی را داخل Inventory عمومی ذخیره نکنید.
- Credentialهای اسکن را کنار داده Inventory نگه ندارید؛ Vault جدا داشته باشید.
- داده خام بیش از نیاز جمع نکنید؛ هدف Visibility است نه ساختن Data Lake بدون Governance.
مراحل بلوغ Crypto Inventory
| سطح | ویژگی |
|---|---|
| ۱ — دستی | Certificate Export و Excel؛ مناسب Discovery اولیه. |
| ۲ — تکرارشونده | Scan دورهای TLS/Certificate و Owner Mapping. |
| ۳ — یکپارچه | اتصال به CMDB/Asset Inventory و Risk. |
| ۴ — عملیاتی | Change Detection، Alert، Migration Priority و Dashboard مدیریتی. |
چطور کیفیت Inventory را بسنجیم؟
Coverage شبکههای On-Prem، Cloud و DMZ مشخص است.
هر Asset بحرانی Owner دارد.
Unknown Algorithm/Unknown Owner بهعنوان Gap گزارش میشود.
تغییر Certificate/Endpoint بین دو Scan قابلتشخیص است.
داده Duplicate و Stale پاکسازی میشود.
گزارش Executive و خروجی فنی از یک Source of Truth ساخته میشوند.
برای ساخت Crypto Inventory سازمانی به ابزار نیاز دارید؟
QShield برای Discovery، Inventory، HNDL Assessment و Migration Prioritization طراحی شده است.