خلاصه اجرایی: محیط Disconnected زمانی پایدار میماند که Repository داخلی، Transfer Station، امضای Package، چرخه Patch، روش License Operations، DNS/NTP/PKI، Backup و فرایند Support از قبل طراحی شوند. راهکار قانونی و پشتیبانیشده باید بر مستندات رسمی و Entitlement معتبر متکی باشد؛ دورزدن License یا کنترل دسترسی بخشی از این طراحی نیست.
Disconnected و Air-Gapped یکسان نیستند
در یک محیط Disconnected، سامانه اصلی دسترسی مستقیم اینترنت ندارد اما انتقال کنترلشده فایل از مسیر مشخص ممکن است. Air-Gapped معمولاً جداسازی سختگیرانهتری دارد و حتی Transfer باید با رسانه، ایستگاه واسط و کنترلهای چندمرحلهای انجام شود. سطح کنترل باید از Threat model و Compliance سازمان بیاید.
استفاده مبهم از این دو واژه باعث طراحی ناقص میشود. باید صریحاً مشخص شود چه اتصالهایی ممنوع، چه مسیرهایی موقت، چه دامنههایی مجاز و چه کسی مجوز انتقال میدهد.
«بدون اینترنت» نباید به معنی «بدون بهروزرسانی و شواهد» باشد. هرچه اتصال کمتر است، فرایند انتقال و ثبت باید دقیقتر باشد.
Trust Zoneها را قبل از Repository طراحی کنید
Connected Zone
دریافت از منبع رسمی با حساب و Entitlement مجاز؛ هیچ دسترسی به محیط Production ندارد.
Quarantine/Transfer
بررسی امضا، Hash، Malware، منشأ، مجوز و ثبت Approval پیش از عبور.
Internal Repository
نسخه تأییدشده Package، Metadata، Retention و دسترسی Role-based نگهداری میشود.
VCF Production
فقط Artifact مصوب را طبق Change و Runbook مصرف میکند؛ Egress ناخواسته مسدود است.
برای هر Zone باید Owner، Log، Time source، Access path و Data retention تعریف شود. Transfer Station نباید به پل دائمی میان اینترنت و Production تبدیل شود.
زنجیره ورود Artifact
Bundleهای VCF تنها Artifact نیستند. Firmware، Driver، Vendor add-on، Container image، Helm chart، Signature database، Certificate chain و گاهی Model/Package AI نیز باید همان کنترل را طی کنند.
Request
نام، نسخه، منبع، دلیل نیاز، مالک و Change مرتبط ثبت میشود.
Acquire
فایل فقط از منبع رسمی و با Entitlement معتبر دریافت میشود.
Verify
Checksum/Signature، Malware scan، Release note و Compatibility کنترل میشوند.
Approve
Security و Platform دامنه استفاده و نسخه مجاز را تأیید میکنند.
Transfer
رسانه یا کانال کنترلشده با ثبت Chain of Custody وارد Zone داخلی میشود.
Retain/Retire
نسخههای فعال، بازگشت و منقضی با Retention روشن مدیریت میشوند.
Repository داخلی باید Source of Truth باشد
کپیکردن فایل در یک Folder مشترک Repository نیست. Catalog، Version، Hash، Signature، Approval، Compatibility، Owner و Expiry باید قابل جستوجو باشند. دسترسی Write محدود و مصرف Read برای سرویسهای مشخص تعریف میشود.
| فیلد | کاربرد | ریسک نبود آن |
|---|---|---|
| Source URL/Vendor | اثبات منشأ | ورود Artifact نامعتبر |
| Hash/Signature | اثبات یکپارچگی | دستکاری یا فایل اشتباه |
| Compatibility | ارتباط با Build و Hardware | ترکیب پشتیبانینشده |
| Approval/Change | ردگیری تصمیم | نصب خارج از فرایند |
| Retention | نگهداری نسخه لازم برای Recovery | نبود Package هنگام بازگشت |
Patch Lifecycle در محیط قطع
فرایند Patch باید Cadence عادی و مسیر اضطراری داشته باشد. Advisoryها در Connected Zone پایش میشوند، Applicability روی Inventory داخلی سنجیده میشود و سپس Package مورد نیاز وارد میشود. نبود Telemetry مستقیم، مسئولیت Inventory و Vulnerability mapping را بیشتر میکند.
Patch backlog باید Severity، Exposure، Dependency، Downtime، Workaround و Deadline داشته باشد. Priority صرفاً از CVSS نمیآید؛ قابل دسترس بودن سرویس و Controlهای جبرانی نیز مهماند.
دریافت Package، تأیید فنی و اجرای Change سه Approval متفاوتاند. ترکیب آنها کنترل و امکان Audit را ضعیف میکند.
License Operations در حالت Disconnected
VCF ۹.۱.۱ بهبودهایی برای License Operations در محیطهای قطع ارائه کرده است. با این حال روش دقیق باید از مستند رسمی نسخه، Entitlement و قرارداد سازمان اجرا شود. فرایند معمولاً نیازمند تولید Request در محیط داخلی، انتقال کنترلشده، پردازش در ناحیه متصل و بازگرداندن Response معتبر است.
تاریخ انقضا، Renewal، مسئول حساب، نگهداری فایلها و سناریوی خرابی باید در Runbook باشد. هیچ روش دورزدن License، جعل Response یا استفاده خارج از Entitlement قابل قبول یا پشتیبانیشده نیست.
DNS، NTP و PKI؛ پایههای فراموششده
محیط بدون اینترنت همچنان به DNS و Time دقیق نیاز دارد. اختلاف زمان روی Certificate، Log correlation، Authentication و Signature validation اثر میگذارد. NTP داخلی باید مرجع، Redundancy و Monitoring داشته باشد.
PKI باید issuance، renewal، revocation، Root/Intermediate protection و انتقال CRL یا دادههای مورد نیاز را پوشش دهد. Certificate renewal نباید به اتصال اضطراری اینترنت وابسته باشد. DNS zone، Forwarder و Record ownership نیز باید مستند شوند.
Support و Evidence چگونه انجام میشود؟
برای بازکردن Case ممکن است Log bundle، Configuration یا Screenshot نیاز باشد. پیش از خروج داده باید طبقهبندی، Redaction، Approval و ثبت Chain of Custody انجام شود. پاسخ Vendor نیز از همان مسیر کنترلشده وارد میشود.
Collect
فقط داده مرتبط با Incident و بازه زمانی لازم جمعآوری شود.
Review
Secret، IP، نام کاربر و داده حساس طبق Policy بازبینی/حذف شود.
Transfer
مسیر، گیرنده، Hash و زمان خروج/ورود ثبت شود.
Redaction نباید Evidence فنی را بیارزش کند؛ تیم Security و Support باید از قبل روی قالب قابل قبول توافق کنند.
Emergency Change وقتی اینترنت نداریم
برای آسیبپذیری بحرانی، مسیر عادی ممکن است کند باشد. Emergency workflow باید از قبل تعریف کند چه کسی Advisory را تأیید میکند، چه Control موقتی اعمال میشود، Package چگونه اولویت میگیرد و چه تست حداقلی پیش از Production لازم است.
فوریت نباید یکپارچگی Artifact را حذف کند. Hash/Signature، Source و Approval همچنان الزامیاند؛ فقط زمانبندی و سطح تست با تصمیم Risk owner تغییر میکند.
Backup و DR در محیط ایزوله
Backup باید از همان Failure Domain و Credential plane جدا باشد. Copy آفلاین یا Immutable، تست Restore، نگهداری Key و ظرفیت Recovery site باید طراحی شود. اگر DR site نیز Disconnected است، هماهنگی Package، Build و Certificate میان دو سایت اهمیت دارد.
Recovery Plan باید سناریوی از دست رفتن Repository، SDDC Manager، Identity یا PKI را هم ببیند. نگهداری Backup بدون ابزار، Key یا Package لازم برای Restore، بازیابیپذیری واقعی نمیسازد.
Supply Chain مدل و Container در Private AI
مدل، Dataset، Python package، Container image و Driver باید مانند Software Artifact مدیریت شوند. License مدل، منشأ، Hash، Vulnerability، Dependency و Use Case مجاز ثبت میشود. Model file بزرگ یا مشهور، بهخودیخود امن یا مجاز نیست.
Registry داخلی، Package mirror و Model catalog باید نسخهدار باشند. خروج Prompt/Response یا Dataset برای Support و ارزیابی نیز تابع طبقهبندی داده است.
نقشها و Audit Evidence
| نقش | مسئولیت | Evidence |
|---|---|---|
| Artifact owner | تعریف نیاز و نسخه | Request و Release reference |
| Security reviewer | منشأ، Scan و Data transfer | Approval و Scan report |
| Repository custodian | Catalog، Access و Retention | Inventory و Access log |
| Platform operator | Precheck، Change و Validation | Runbook و Post-check |
| Risk owner | پذیرش استثنا و Emergency | Risk acceptance محدود و زماندار |
Audit موفق محصول انبوه Log نیست؛ زنجیرهای خوانا از نیاز، منبع، تأیید، اجرا و نتیجه است. هر Evidence باید Timestamp، Owner و Retention داشته باشد.
پرسشهای متداول
آیا VCF در محیط بدون اینترنت قابل اداره است؟
بله، با فرایند و ابزارهای مناسب؛ اما Patch، License، Support و Repository باید عمداً طراحی شوند.
آیا Air-Gap یعنی هیچ فایل یا دادهای جابهجا نمیشود؟
سطح جداسازی به Policy بستگی دارد. اگر انتقال لازم است، باید کنترلشده، ثبتشده و حداقلی باشد.
آیا میتوان Bundle را از هر منبعی دانلود و وارد کرد؟
خیر. منبع رسمی، Entitlement، امضا/Hash و Compatibility باید تأیید شوند.
اگر License activation آنلاین نباشد چه میشود؟
باید از workflow رسمی Disconnected همان نسخه و قرارداد استفاده شود؛ هیچ روش غیررسمی یا دورزدن قابل توصیه نیست.
چطور Advisoryهای امنیتی را بدون اینترنت دنبال کنیم؟
یک نقش یا سرویس در Zone متصل باید منابع رسمی را پایش و Applicability را روی Inventory داخلی نگاشت کند.
منابع رسمی و ملاحظات
- اعلام رسمی VCF ۹.۱.۱ و بهبود License Operations در محیط Disconnected
- FAQ رسمی VMware Cloud Foundation ۹
- راهنمای رسمی Planning و مسیرهای VCF ۹
روش انتقال، License و Patch باید براساس مستند همان Build، قرارداد معتبر و سیاست امنیتی سازمان نهایی شود.
برای مطالعه بعدی
Operating Model محیط Disconnected را مستند کنید
Repository، Patch، License، PKI، Support و Recovery را در یک نقشه مسئولیت و Runbook قابل ممیزی جمع کنید.