بیشتر سازمان‌ها روزی متوجه وابستگی خود به نرم‌افزار خارجی می‌شوند که دیگر دیر شده است؛ صبحی که پنل ابری باز نمی‌شود، لایسنس تمدید نمی‌شود یا مخزن کد با پیام «دسترسی شما محدود شده است» روبه‌رو می‌شود. این ریسک‌ها نظری نیستند و در یک دهه گذشته بارها برای کاربران ایرانی و شرکت‌هایی در کشورهای دیگر اتفاق افتاده‌اند. در این مقاله ریسک‌های اصلی اتکا به نرم‌افزار و سرویس خارجی را دسته‌بندی می‌کنیم: قطع لایسنس، توقف به‌روزرسانی، مسدودشدن حساب‌ها، کلید خاموشی (Kill Switch) و درهای پشتی (Backdoor). برای هر کدام نمونه‌های واقعی و ماندگار را مرور می‌کنیم و در پایان راهکارهای عملی برای کاهش این ریسک‌ها را می‌گوییم.
وابستگی فناوری یعنی چه و چرا مسئله‌ای امنیتی است؟
وابستگی فناوری یعنی ادامه کار یک سیستم حیاتی به تصمیم، زیرساخت یا حسن نیت یک طرف خارجی بستگی داشته باشد که شما هیچ کنترلی روی آن ندارید. این طرف می‌تواند یک شرکت نرم‌افزاری باشد، یک ارائه‌دهنده ابری، یک مخزن بسته‌های متن‌باز یا حتی یک توسعه‌دهنده تنها که کتابخانه‌ای پرکاربرد را نگه می‌دارد.
مشکل فقط تحریم نیست. شرکت‌های فناوری باید از قوانین کشور خودشان پیروی کنند، مثل مقررات کنترل صادرات آمریکا و فهرست‌های OFAC. پس حتی اگر یک شرکت بخواهد به شما خدمات بدهد، ممکن است از نظر قانونی نتواند. به همین دلیل مفهوم بومی‌سازی سیستم‌ها و نقش آن در امنیت ملی و سازمانی از یک شعار به یک نیاز مدیریت ریسک تبدیل شده است.
ریسک اول: قطع لایسنس و توقف فروش
بسیاری از نرم‌افزارهای سازمانی امروز به‌صورت اشتراکی (Subscription) فروخته می‌شوند. یعنی شما مالک نرم‌افزار نیستید و فقط تا زمانی که اشتراک فعال است حق استفاده دارید. اگر فروشنده تمدید را متوقف کند، نرم‌افزار ممکن است از کار بیفتد یا به حالت فقط‌خواندنی برود.
نمونه ماندگار: خروج شرکت‌های نرم‌افزاری از روسیه در ۲۰۲۲
پس از آغاز جنگ اوکراین در سال ۲۰۲۲، شرکت‌های بزرگی مانند مایکروسافت، اوراکل، SAP و Autodesk فروش جدید یا بخشی از خدمات خود در روسیه را متوقف کردند. سازمان‌های روسی که ERP، پایگاه داده یا نرم‌افزار طراحی‌شان کاملاً به این شرکت‌ها وابسته بود، ناگهان با مشکل تمدید لایسنس، پشتیبانی و مهاجرت روبه‌رو شدند. این تجربه نشان داد که حتی یک اقتصاد بزرگ هم در برابر قطع لایسنس آسیب‌پذیر است.
- لایسنس دائمی: معمولاً پس از قطع رابطه هم کار می‌کند، اما بدون به‌روزرسانی و پشتیبانی.
- لایسنس اشتراکی یا ابری: با قطع اشتراک، دسترسی هم می‌تواند فوراً قطع شود.
- فعال‌سازی آنلاین: اگر نرم‌افزار برای کار کردن مرتب با سرور مجوز تماس بگیرد، قطع اینترنت بین‌الملل یا مسدود شدن IP هم کافی است تا متوقف شود.
ریسک دوم: توقف به‌روزرسانی و وصله‌های امنیتی
نرم‌افزاری که وصله امنیتی دریافت نکند، با گذشت زمان به هدفی آسان برای مهاجمان تبدیل می‌شود. وقتی دسترسی به سرور به‌روزرسانی مسدود می‌شود، تیم فناوری اطلاعات معمولاً به سراغ منابع غیررسمی می‌رود. این یعنی دانلود فایل نصب از سایت‌های ناشناس و نسخه‌های کرک‌شده، که خودش ریسک بزرگ‌تری است.
چرا این ریسک برای کاربران ایرانی جدی‌تر است؟
بسیاری از سرویس‌ها از روی IP، کاربران ایرانی را از مخازن به‌روزرسانی، فروشگاه‌های برنامه و مستندات محروم می‌کنند. یک نمونه مشخص Docker Hub است. در سال ۲۰۲۴ کاربران با IP ایران و چند کشور تحریمی دیگر هنگام دریافت ایمیج با خطای 403 و پیامی درباره رعایت مقررات کنترل صادرات آمریکا روبه‌رو شدند. پایپ‌لاین‌های CI/CD که مستقیم به این مخزن وابسته بودند، یک‌شبه از کار افتادند.
درس اصلی: هر سیستمی که برای ساخت، استقرار یا به‌روزرسانی به یک مخزن خارجی وصل است، یک نقطه شکست بیرون از کنترل شما دارد.
ریسک سوم: مسدودشدن حساب‌ها و حذف داده‌ها
شاید آسیب‌زننده‌ترین سناریو این باشد که حساب کاربری شما، همراه با داده‌ها، کدها یا دارایی‌هایتان، بدون هشدار قبلی بسته شود.
- GitHub (۲۰۱۹): GitHub دسترسی کاربران ایران، سوریه و کریمه به مخازن خصوصی و برخی امکانات را محدود کرد. بعدها در سال ۲۰۲۱ با گرفتن مجوز از دولت آمریکا، خدمات برای توسعه‌دهندگان ایرانی تا حد زیادی دوباره باز شد. با این حال این دوره نشان داد که کد یک تیم کامل می‌تواند ناگهان در دسترس نباشد.
- Slack (۲۰۱۸): تعدادی از حساب‌های مرتبط با ایران، حتی برخی کاربران مقیم خارج، بدون اطلاع قبلی بسته شدند.
- فروشگاه‌های اپلیکیشن: اپل در چند نوبت اپلیکیشن‌های ایرانی را از App Store حذف کرد. کسب‌وکارهایی که کانال توزیع‌شان فقط این فروشگاه بود، دسترسی به کاربرانشان را از دست دادند.
- دنیای کریپتو: صرافی‌های متمرکز و سرویس‌های زیرساختی مانند ارائه‌دهندگان RPC بارها کاربران مناطق تحریمی را مسدود کرده‌اند. در سال ۲۰۲۲ هم تحریم Tornado Cash باعث شد مخازن و حساب برخی توسعه‌دهندگان مرتبط با آن تعلیق شوند. این تحریم بعدها لغو شد، اما آن اتفاق نشان داد ابزارهای «غیرمتمرکز» هم لایه‌های متمرکز آسیب‌پذیری دارند.
نکته مهم این است که در این موارد مشکل فقط «قطع سرویس» نبود. از دست دادن داده و تاریخچه هم بود؛ از ایمیل و اسناد گرفته تا کد منبع و دارایی دیجیتال.
ریسک چهارم: کلید خاموشی و کنترل از راه دور
دستگاه‌ها و نرم‌افزارهایی که به سرور سازنده متصل‌اند، از نظر فنی می‌توانند از راه دور غیرفعال شوند. معروف‌ترین نمونه در سال ۲۰۲۲ رخ داد. گزارش‌ها نشان دادند ماشین‌آلات کشاورزی John Deere که از نمایندگی‌ای در اوکراین غارت و به روسیه منتقل شده بودند، از راه دور قفل شدند. انگیزه آن اقدام هرچه بود، اصل ماجرا روشن است: وقتی سازنده بتواند محصول را خاموش کند، مالکیت واقعی با شما نیست.
همین منطق در مقیاس سازمانی برای فایروال‌ها، سوئیچ‌های مدیریت‌شده ابری، سامانه‌های مدیریت دستگاه (MDM) و نرم‌افزارهای امنیتی با کنسول ابری هم صدق می‌کند.
وقتی خطا به اندازه تحریم ویرانگر است
کلید خاموشی همیشه عمدی نیست. در ژوئیه ۲۰۲۴ یک به‌روزرسانی معیوب از نرم‌افزار امنیتی CrowdStrike میلیون‌ها رایانه ویندوزی را در سراسر جهان از کار انداخت. فرودگاه‌ها، بانک‌ها و بیمارستان‌ها مختل شدند. این رویداد نشان داد که اعتماد کامل به به‌روزرسانی خودکار از یک فروشنده واحد، خودش یک ریسک تمرکز است.
ریسک پنجم: درهای پشتی و نرم‌افزار آلوده
وقتی کد منبع یک محصول در اختیار شما نیست، نمی‌توانید مطمئن باشید دقیقاً چه کاری انجام می‌دهد. تاریخ امنیت سایبری چند نمونه مستند و آموزنده در این زمینه دارد:
- Crypto AG: در سال ۲۰۲۰ گزارش‌های رسانه‌ای نشان داد این شرکت سوئیسی سازنده تجهیزات رمزنگاری، که ده‌ها دولت مشتری آن بودند، سال‌ها در مالکیت پنهان سازمان‌های اطلاعاتی آمریکا و آلمان بوده است. تجهیزاتش هم عمداً تضعیف شده بودند.
- Juniper ScreenOS (۲۰۱۵): شرکت Juniper اعلام کرد در سیستم‌عامل فایروال‌هایش «کد غیرمجاز» پیدا کرده است. این کد امکان رمزگشایی ترافیک VPN و ورود مدیریتی را فراهم می‌کرد.
- SolarWinds (۲۰۲۰): مهاجمان به‌روزرسانی رسمی نرم‌افزار Orion را آلوده کردند و هزاران سازمان، از جمله نهادهای دولتی آمریکا، نسخه آلوده را نصب کردند.
- xz Utils (۲۰۲۴): یک درب پشتی با شناسه CVE-2024-3094 پس از سال‌ها جلب اعتماد نگه‌دارندگان، در این کتابخانه فشرده‌سازی پرکاربرد لینوکس جاسازی شد. پیش از رسیدن به نسخه‌های پایدار توزیع‌ها، به‌طور تصادفی کشف شد.
- Protestware در node-ipc (۲۰۲۲): نگه‌دارنده یک بسته npm کدی اضافه کرد که روی سیستم‌هایی با IP روسیه و بلاروس فایل‌ها را بازنویسی می‌کرد. این نمونه نشان داد انگیزه سیاسی هم می‌تواند وارد زنجیره تأمین شود.
دو نمونه آخر یادآوری می‌کنند که متن‌باز بودن به‌تنهایی تضمین امنیت نیست. متن‌باز بودن فقط امکان بررسی را فراهم می‌کند. اگر کسی واقعاً کد را بررسی نکند، این امکان بی‌فایده است.
مقایسه ریسک‌ها در یک نگاه
| نوع ریسک | نمونه واقعی | شدت اثر | راهکار اصلی |
|---|---|---|---|
| قطع لایسنس | توقف فروش شرکت‌های نرم‌افزاری در روسیه | بالا، به‌ویژه در ERP و پایگاه داده | جایگزین متن‌باز یا بومی، لایسنس دائمی |
| توقف به‌روزرسانی | مسدودشدن Docker Hub برای IP ایران | متوسط تا بالا | مخزن آینه (Mirror) داخلی |
| مسدودشدن حساب | GitHub در ۲۰۱۹، Slack در ۲۰۱۸ | بالا، با احتمال از دست رفتن داده | نسخه پشتیبان مستقل، میزبانی داخلی |
| کلید خاموشی | قفل از راه دور ماشین‌آلات، رخداد CrowdStrike | بحرانی | حالت آفلاین، به‌روزرسانی مرحله‌ای |
| درب پشتی | Crypto AG، Juniper، SolarWinds، xz | بحرانی و پنهان | ممیزی کد، Zero Trust، پایش ترافیک |
چگونه این ریسک‌ها را کاهش دهیم؟
حذف کامل وابستگی خارجی در عمل تقریباً ممکن نیست و همیشه هم لازم نیست. هدف درست این است که وابستگی را بشناسید، اولویت‌بندی کنید و برای سیستم‌های حیاتی جایگزین داشته باشید.
۱. فهرست وابستگی‌ها را تهیه کنید
همه نرم‌افزارها، سرویس‌های ابری، APIها و کتابخانه‌ها را فهرست کنید. برای کد هم یک فهرست اجزای نرم‌افزار (SBOM) بسازید. برای هر مورد بپرسید: اگر فردا قطع شود، چه چیزی متوقف می‌شود؟
۲. مخازن و نسخه‌های پشتیبان داخلی بسازید
- برای Docker، npm، PyPI و مخازن سیستم‌عامل، رجیستری و Mirror داخلی راه بیندازید.
- از کد منبع، ایمیل و اسناد ابری، پشتیبان مستقل و منظم روی زیرساخت خودتان بگیرید.
- نسخه‌های نصب و لایسنس‌های دائمی را با هش (Hash) معتبر بایگانی کنید.
۳. به هیچ مؤلفه‌ای کورکورانه اعتماد نکنید
برای مقابله با درهای پشتی، شبکه را طوری طراحی کنید که حتی یک تجهیز آلوده هم دسترسی نامحدود نداشته باشد. اصول معماری Zero Trust دقیقاً برای همین ساخته شده است: تقسیم‌بندی شبکه، حداقل دسترسی و پایش ترافیک خروجی. اتصال‌های ناشناخته تجهیزات به سرورهای خارجی را هم ثبت و بررسی کنید.
۴. نرم‌افزار را پیش از اعتماد بیازمایید
چه نرم‌افزار خارجی باشد و چه بومی، باید پیش از استقرار در محیط حساس ارزیابی شود. تست نفوذ منظم و بررسی امنیت سرویس‌ها و رابط‌ها بر پایه استانداردهای OWASP کمک می‌کند ضعف‌ها پیش از سوءاستفاده پیدا شوند.
۵. به‌روزرسانی را مرحله‌ای کنید
به‌روزرسانی‌ها را اول روی گروه کوچکی از سیستم‌ها اعمال کنید و بعد به همه گسترش دهید. این کار هم جلوی خطاهایی مثل رخداد CrowdStrike را می‌گیرد و هم فرصت شناسایی به‌روزرسانی آلوده را می‌دهد.
۶. جایگزین بومی یا متن‌باز را جدی بگیرید
برای سیستم‌های حیاتی مانند ایمیل، احراز هویت، ذخیره‌سازی، مخزن کد و نود بلاکچین، استفاده از راهکارهای متن‌باز که روی زیرساخت داخلی میزبانی می‌شوند یا محصولات بومی معتبر، وابستگی را به‌طور چشمگیری کاهش می‌دهد. البته این جایگزین‌ها هم باید از نظر امنیت و پشتیبانی ارزیابی شوند؛ «بومی بودن» به‌تنهایی معیار کیفیت نیست.
سوالات متداول
آیا استفاده از نرم‌افزار متن‌باز خارجی هم ریسک تحریم دارد؟
خود کد متن‌باز معمولاً با مجوزهایی منتشر می‌شود که محدودیت جغرافیایی ندارند. اما بسترهای توزیع مثل GitHub، Docker Hub یا برخی مخازن بسته‌ها ممکن است دسترسی را محدود کنند. راه‌حل این است که نسخه‌ای از کد و بسته‌های موردنیاز را در مخزن داخلی نگه دارید.
استفاده از نرم‌افزار کرک‌شده چه خطری دارد؟
فایل‌های کرک‌شده از منابع ناشناس یکی از رایج‌ترین راه‌های ورود بدافزار و درب پشتی به سازمان‌ها هستند. علاوه بر این، به‌روزرسانی امنیتی هم دریافت نمی‌کنند. در سیستم‌های حساس، ریسک آن‌ها از بیشتر جایگزین‌های قانونی بیشتر است.
چطور بفهمیم یک تجهیز شبکه درب پشتی دارد؟
اطمینان صددرصدی تقریباً ممکن نیست. اما پایش ترافیک خروجی، محدود کردن دسترسی تجهیز به اینترنت، بررسی میان‌افزار (Firmware) و تست نفوذ دوره‌ای احتمال کشف رفتار مشکوک را بسیار بالا می‌برند.
آیا کیف پول‌ها و سرویس‌های کریپتو هم در معرض این ریسک‌ها هستند؟
بله. صرافی‌های متمرکز، ارائه‌دهندگان RPC و برخی رابط‌های کاربری وب ممکن است کاربران مناطق تحریمی را مسدود کنند. استفاده از کیف پول غیرحضانتی و اجرای نود شخصی این وابستگی را کم می‌کند، اما ریسک‌های فنی و بازار رمزارزها همچنان پابرجاست.
آیا بومی‌سازی یعنی کنار گذاشتن کامل نرم‌افزار خارجی؟
خیر. بومی‌سازی منطقی یعنی برای سیستم‌های حیاتی کنترل و جایگزین داشته باشید و برای بقیه، ریسک را آگاهانه بپذیرید و مدیریت کنید.
جمع‌بندی
قطع لایسنس، توقف به‌روزرسانی، مسدودشدن حساب‌ها، کلید خاموشی و درهای پشتی، ریسک‌هایی هستند که با نمونه‌های مستند در سال‌های اخیر بارها رخ داده‌اند. سازمانی که وابستگی‌هایش را بشناسد، پشتیبان و مخزن داخلی داشته باشد، اصول Zero Trust را اجرا کند و برای سیستم‌های حیاتی جایگزین بومی یا متن‌باز آماده کرده باشد، روز قطع سرویس فقط با یک مشکل فنی روبه‌رو می‌شود، نه یک بحران. پیش از هر تصمیمی، شرایط و قوانین هر سرویس را بررسی کنید؛ این سیاست‌ها ممکن است در طول زمان تغییر کنند.
