هر سازمانی که بخواهد زیرساخت فناوری اطلاعات خودش را بومی کند، زود به یک سؤال ساده و جدی می‌رسد: آیا باید همه‌چیز را از صفر نوشت؟ پاسخ واقعی تقریباً همیشه «نه» است. نرم‌افزار متن‌باز (Open Source)، با لینوکس در مرکزش، این امکان را می‌دهد که سازمان‌ها و کشورها روی کدی که دهه‌ها آزموده شده بنا کنند، کد را خودشان ببینند و تغییر دهند و برای ادامه کار به مجوز یا سرور یک شرکت خارجی وابسته نمانند. با این حال، «متن‌باز» به‌خودی‌خود یعنی «امن» یا «بومی» نیست. در این مقاله توضیح می‌دهیم متن‌باز چطور می‌تواند پایه بومی‌سازی امن و کم‌هزینه باشد، چه محدودیت‌هایی دارد و بازبینی کد آن چه الزاماتی می‌خواهد.
چرا متن‌باز نقطه شروع منطقی بومی‌سازی است؟
همان‌طور که در مقاله بومی‌سازی سیستم‌ها چیست و چرا برای امنیت ملی و سازمانی حیاتی است؟ گفتیم، هدف بومی‌سازی لزوماً ساختن همه اجزا در داخل نیست. هدف این است که کنترل، شناخت و توان نگهداری سیستم‌ها در اختیار خود سازمان باشد. نرم‌افزار متن‌باز دقیقاً همین سه چیز را ممکن می‌کند:
- شفافیت: کد منبع در دسترس است و می‌شود آن را خواند، ممیزی کرد و رفتارش را بررسی کرد.
- حق تغییر و توزیع: مجوزهایی مثل GPL، Apache و MIT اجازه می‌دهند نسخه داخلی بسازید، آن را سفارشی کنید و در سازمان یا کشور پخش کنید.
- استقلال از فروشنده: اگر شرکت اصلی پشتیبانی را قطع کند، کد از بین نمی‌رود. شما یا جامعه کاربران می‌توانید پروژه را ادامه دهید (Fork).
این ویژگی‌ها مستقیماً به ریسک‌هایی جواب می‌دهند که در مقاله تحریم، قطع سرویس و وابستگی فناوری بررسی شد: لغو لایسنس، قفل‌شدن حساب کاربری، توقف به‌روزرسانی و وابستگی به سرویس‌های ابری خارجی.
لینوکس؛ ستون اصلی زیرساخت بومی
هسته لینوکس (Linux Kernel) امروز روی بخش بزرگی از سرورها، تجهیزات شبکه، سیستم‌های تعبیه‌شده و ابرهای عمومی اجرا می‌شود. این پروژه به‌طور منظم نسخه جدید منتشر می‌کند. برای نمونه، طبق سایت رسمی kernel.org، نسخه اصلی 7.3 در مهر ۱۴۰۵ (اکتبر ۲۰۲۶) منتشر شد و هم‌زمان چند شاخه پشتیبانی بلندمدت (LTS) هم نگهداری می‌شوند. چون این اعداد زود تغییر می‌کنند، برای برنامه‌ریزی همیشه به همان منبع رسمی مراجعه کنید.
چرا لینوکس برای بومی‌سازی مناسب است؟
- بلوغ و پایداری: بیش از سه دهه توسعه با مشارکت هزاران توسعه‌دهنده و شرکت.
- توزیع‌های متنوع: توزیع‌هایی مثل Debian، Rocky Linux، AlmaLinux و Ubuntu پایه خوبی برای ساخت یک «توزیع سازمانی یا ملی» هستند.
- امکان مخزن داخلی: می‌شود کل مخزن بسته‌ها (Repository Mirror) را داخل کشور نگه داشت تا به‌روزرسانی‌ها حتی در صورت قطع دسترسی بین‌المللی ادامه پیدا کنند.
- سخت‌سازی امنیتی: ابزارهایی مثل SELinux، AppArmor، auditd و nftables بدون هزینه لایسنس در دسترس‌اند.
پشته متن‌باز برای زیرساخت سازمانی
بالاتر از سیستم‌عامل هم تقریباً برای هر لایه زیرساخت جایگزین متن‌باز پخته‌ای وجود دارد:
| لایه زیرساخت | نمونه‌های متن‌باز | کاربرد در بومی‌سازی |
|---|---|---|
| مجازی‌سازی و ابر | KVM، Proxmox VE، OpenStack | ساخت ابر خصوصی داخل سازمان |
| کانتینر و ارکستراسیون | Podman، Kubernetes | استقرار مستقل از ابرهای خارجی |
| ذخیره‌سازی | Ceph، MinIO، ZFS | نگهداری داده در زیرساخت داخلی |
| پایگاه داده | PostgreSQL، MariaDB | جایگزین پایگاه‌داده‌های تجاری |
| هویت و دسترسی | FreeIPA، Keycloak | مدیریت متمرکز کاربران و SSO |
| پایش و لاگ | Prometheus، Grafana، Wazuh | نظارت امنیتی و عملیاتی |
| ارتباطات سازمانی | Postfix، Dovecot، Matrix، Nextcloud | ایمیل، پیام‌رسان و اشتراک فایل داخلی |
مزایای متن‌باز در بومی‌سازی
۱. هزینه کمتر، اما نه صفر
با متن‌باز هزینه لایسنس حذف یا خیلی کم می‌شود. این موضوع برای سازمان‌های ایرانی، که خرید قانونی لایسنس خارجی برایشان اغلب ممکن نیست یا پرریسک است، اهمیت دوچندان دارد. ولی هزینه واقعی به سمت نیروی متخصص، پشتیبانی، آموزش و نگهداری جابه‌جا می‌شود. مقایسه دقیق‌تر هزینه کل مالکیت را در مقاله مقایسه نرم‌افزار بومی و خارجی آورده‌ایم.
۲. امکان ممیزی امنیتی واقعی
در نرم‌افزار بسته‌کد، باید به ادعای فروشنده اعتماد کنید. در متن‌باز، تیم امنیتی داخلی می‌تواند دنبال درِ پشتی، ارتباطات مخفی با سرورهای خارجی یا جمع‌آوری داده بدون اجازه بگردد. این همان اصلی است که معماری Zero Trust درباره کاربران و شبکه می‌گوید و اینجا به خود نرم‌افزار هم تعمیم پیدا می‌کند: هیچ جزئی را بدون راستی‌آزمایی قبول نکن.
۳. انتقال دانش و تربیت متخصص
کار روی پروژه‌های متن‌باز، مهندسان داخلی را با استانداردهای جهانی توسعه، بازبینی کد و مدیریت انتشار آشنا می‌کند. این دانش از مهم‌ترین دستاوردهای پایدار بومی‌سازی است.
۴. سرعت توسعه
به‌جای اینکه سال‌ها صرف نوشتن یک پایگاه داده یا فایل‌سیستم تازه شود، تیم‌ها روی لایه‌ای تمرکز می‌کنند که واقعاً ارزش افزوده بومی دارد: یکپارچه‌سازی، بومی‌سازی زبان و تقویم، انطباق با مقررات داخلی و رابط کاربری.
محدودیت‌ها و ریسک‌ها
نگاه واقع‌بینانه به متن‌باز یعنی ضعف‌هایش را هم بشناسیم:
- «باز بودن» یعنی «بازبینی‌شدن» نیست: خیلی از کتابخانه‌های پرکاربرد را فقط یک یا دو داوطلب نگهداری می‌کنند و عملاً کسی کدشان را عمیق بررسی نمی‌کند.
- حمله به زنجیره تأمین: نمونه معروفش درِ پشتی کتابخانه XZ Utils (CVE-2024-3094) است که در فروردین ۱۴۰۳ (مارس ۲۰۲۴) کشف شد. مهاجم طی چند سال اعتماد جامعه پروژه را جلب کرد و کد مخرب را در نسخه‌های 5.6.0 و 5.6.1 جاسازی کرد. این کد در شرایط خاص می‌توانست دسترسی از راه دور از طریق SSH بدهد. این حادثه را مهندسی به نام Andres Freund تصادفی، با دنبال‌کردن یک کندی غیرعادی، کشف کرد.
- ملاحظات تحریم و حاکمیت پروژه: کد متن‌باز معمولاً آزادانه در دسترس است، اما پلتفرم‌های میزبانی و بنیادهای نگهدارنده تابع قوانین کشور خودشان هستند. محدودیت‌هایی که در سال‌های گذشته برای کاربران برخی کشورها در پلتفرم‌های توسعه یا در مشارکت در پروژه‌ها اعمال شد نشان می‌دهد که داشتن نسخه محلی از کد و مخازن ضروری است.
- کمبود پشتیبانی تجاری: برای سیستم‌های حیاتی، «جامعه کاربری» جای قرارداد پشتیبانی با زمان پاسخ مشخص را نمی‌گیرد. باید تیم داخلی یا شرکت پشتیبان داخلی وجود داشته باشد.
- پیچیدگی مجوزها: ترکیب کدهایی با مجوزهای مختلف (مثلاً GPL با کد اختصاصی) می‌تواند تعهدات حقوقی ایجاد کند.
- تغییر مجوز پروژه‌ها: بعضی پروژه‌ها در سال‌های اخیر از مجوز متن‌باز به مجوزهای محدودتر رفته‌اند. پس باید نسخه‌ای را که به آن وابسته‌اید و مجوزش را پایش کنید.
بومی‌سازی واقعی با متن‌باز یعنی «مالکیت عملیاتی» کد: نگه‌داشتن نسخه محلی، توان ساخت مستقل، بازبینی تغییرات و توان وصله‌کردن بدون انتظار برای دیگران.
الزامات بازبینی کد و امنیت زنجیره تأمین
برای اینکه متن‌باز پایه‌ای امن برای بومی‌سازی شود، سازمان به یک فرایند رسمی نیاز دارد، نه فقط دانلود و نصب. حداقل‌های پیشنهادی:
۱. فهرست اجزا و SBOM
برای هر سامانه یک فهرست اجزای نرم‌افزار (SBOM) با قالب‌های استاندارد مثل SPDX یا CycloneDX تهیه کنید تا معلوم باشد دقیقاً چه کتابخانه‌ها و چه نسخه‌هایی استفاده شده‌اند. بدون SBOM، وقتی آسیب‌پذیری‌ای مثل XZ اعلام شود، حتی نمی‌دانید آسیب‌پذیر هستید یا نه.
۲. ارزیابی سلامت پروژه پیش از پذیرش
- تعداد نگهدارندگان فعال و تنوع سازمانی آن‌ها
- تاریخچه پاسخ به آسیب‌پذیری‌ها و وجود سیاست امنیتی (SECURITY.md)
- امضای انتشارها و کامیت‌ها
- امتیاز ابزارهایی مثل OpenSSF Scorecard که شیوه‌های امنیتی مخزن را خودکار ارزیابی می‌کنند
۳. ساخت مستقل و بازتولیدپذیر
باینری‌ها را از کد منبع و روی زیرساخت داخلی بسازید و تا جای ممکن از ساخت بازتولیدپذیر (Reproducible Builds) استفاده کنید تا بشود ثابت کرد باینری دقیقاً از همان کد بازبینی‌شده ساخته شده است. چارچوب SLSA برای سنجش سطح اطمینان به فرایند ساخت راهنمای خوبی است. درس مهم ماجرای XZ این بود که بخشی از کد مخرب در فایل‌های تست و اسکریپت‌های ساخت پنهان شده بود، نه فقط در کد اصلی.
۴. بازبینی تفاضلی تغییرات
بازبینی کامل میلیون‌ها خط کد عملی نیست. رویکرد عملی این است:
- یک بار ممیزی عمیق اجزای حیاتی، مثل احراز هویت، رمزنگاری و سرویس‌هایی که به شبکه وصل‌اند.
- بعد از آن، بازبینی تفاضل (diff) هر نسخه جدید پیش از ورود به مخزن داخلی.
- تحلیل ایستا (SAST) و تحلیل ترکیب نرم‌افزار (SCA) در خط لوله CI.
- بررسی دستی تغییرات مشکوک در اسکریپت‌های ساخت، فایل‌های باینری داخل مخزن و وابستگی‌های جدید.
نمونه ساده‌ای از تأیید امضای یک بسته پیش از استفاده:
gpg --verify package-1.2.3.tar.gz.asc package-1.2.3.tar.gz
sha256sum -c package-1.2.3.sha256۵. آزمون امنیتی و پایش مداوم
بازبینی کد جای آزمون عملی را نمی‌گیرد. سامانه‌های مبتنی بر متن‌باز هم باید به‌طور دوره‌ای تست نفوذ شوند. وب‌اپلیکیشن‌ها و APIهای ساخته‌شده روی آن‌ها هم باید طبق راهنماهای OWASP ارزیابی شوند. اشتراک در فیدهای آسیب‌پذیری (CVE) و آماده‌بودن برای وصله سریع هم بخشی از همین چرخه است.
مدل پیشنهادی: مصرف‌کننده آگاه، مشارکت‌کننده فعال
سازمان‌هایی که با متن‌باز موفق شده‌اند معمولاً این الگو را دنبال می‌کنند:
- مخزن آینه داخلی برای کد منبع، بسته‌های سیستم‌عامل و وابستگی‌های زبان‌های برنامه‌نویسی (npm، PyPI، Maven و غیره).
- توزیع پایه استاندارد سازمانی با تنظیمات سخت‌سازی‌شده و حذف سرویس‌های غیرضروری.
- تیم نگهداری داخلی که توان وصله‌کردن و Backport اصلاحات امنیتی را داشته باشد.
- مشارکت در پروژه‌های بالادستی، تا جایی که قوانین اجازه می‌دهد، تا دانش و اعتبار فنی داخل کشور بماند.
- بررسی حقوقی مجوزها پیش از توزیع محصول نهایی.
سوالات متداول
آیا یک توزیع لینوکسی که فقط تغییر نام داده، بومی محسوب می‌شود؟
نه. عوض‌کردن لوگو و نام، بومی‌سازی نیست. بومی‌سازی واقعی یعنی سازمان یا تیم داخلی بتواند بسته‌ها را مستقل بسازد، به‌روزرسانی امنیتی را خودش منتشر کند، کد را بازبینی کند و مخزن‌ها را داخل کشور نگه دارد.
آیا نرم‌افزار متن‌باز از نرم‌افزار تجاری امن‌تر است؟
نه لزوماً. متن‌باز «امکان» بازبینی را می‌دهد، اما امنیت به این بستگی دارد که این بازبینی واقعاً انجام شود، پروژه نگهدارنده فعال داشته باشد و وصله‌ها سریع اعمال شوند. یک پروژه متن‌باز رهاشده ممکن است از نرم‌افزار تجاری خوب پرریسک‌تر باشد.
تحریم‌ها روی استفاده از نرم‌افزار متن‌باز اثر دارند؟
خود کد معمولاً آزادانه منتشر می‌شود، اما دسترسی به پلتفرم‌های میزبانی، سرویس‌های ابری، بعضی مخازن و امکان مشارکت مستقیم ممکن است محدود شود. این شرایط هم با گذر زمان تغییر می‌کند. به همین دلیل نگه‌داشتن نسخه محلی از کد و مخازن یک الزام است، نه یک انتخاب.
کوچک‌ترین گام برای شروع چیست؟
اول برای سامانه‌های فعلی SBOM تهیه کنید و یک مخزن آینه داخلی برای بسته‌های سیستم‌عامل راه بیندازید. همین دو اقدام وابستگی شما را مشخص و در دسترس‌بودن به‌روزرسانی‌ها را تضمین می‌کند.
جمع‌بندی
لینوکس و اکوسیستم متن‌باز سریع‌ترین و کم‌هزینه‌ترین راه برای ساخت زیرساخت فناوری اطلاعاتی‌اند که در کنترل خود سازمان باشد. ولی این مزیت فقط وقتی به امنیت تبدیل می‌شود که متن‌باز با فرایند جدی همراه شود: SBOM، ارزیابی سلامت پروژه‌ها، ساخت مستقل، بازبینی تغییرات، آزمون نفوذ و تیم نگهداری داخلی. متن‌باز مصالح ساختمان را می‌دهد و مسئولیت مهندسی، نظارت و نگهداری بنا همچنان با خود سازمان است.
