چگونه از کابوس امنیت پروژه‌های منبع باز رهایی یابیم؟
امروزه شاهد ظهور مشکلات امنیتی بسیار مهمی در نرم‌افزارهای متن باز[1] یا اوپن سورس (به انگلیسی: Open Source) هستیم. برای مثال به تازگی یک توسعه‌دهنده نرم‌افزار به نام Marak Squires نسخه‌هایی دستکاری شده از پکیج‌های faker.js و colors.js را با هدف انتقام و ایجاد نقص فنی در پروژه‌هایی که از این پکیج‌ها استفاده می‌کنند منتشر کرده است. این اقدام خصمانه منجر به ایجاد اختلال و حتی از کار افتادگی هزاران پروژه شد.
بنابراین در چنین شرایطی آیا استفاده از نرم‌افزارهای متن باز کار عاقلانه‌ای است؟ همچنین پس از بروز مشکل Log4j که موجب ایجاد مخاطرات امنیتی بسیار زیادی برای سرورهای از راه دور گردید، کاخ سفید از سازمان‌های ارایه‌دهنده فناوری‌های مهم درخواست کرد که درباره امنیت پروژه‌های متن باز اظهارنظر کنند.
کارشناسان امنیتی توصیه می‌کنند که پیش از انتخاب یک نرم‌افزار متن باز و استفاده از آن به موارد و نکات زیر توجه کنید:
- آیا کدها توسط افراد داوطلبی که نسبت به کدهای توسعه‌دهندگان حرفه‌ای از ایمنی نسبتاً پایین‌تری برخوردار هستند نوشته شده‌اند؟
- آیا در صورت بروز مشکل برای یک محصول باید از شخص خاصی شکایت کنید؟
- آیا محصول دریافتی ارزش هزینه پرداختی را دارد؟
نرم‌افزار متن باز (یا اپن سورس) چیست؟
هیچ نظریه قطعی مبنی بر اینکه همه نرمافزارها و پروژه‌های متن بسته عاری از خطا هستند وجود ندارد. همچنین نمی‌توانیم با اطمینان کامل بگوییم که کلیه نرم‌افزارهای متن باز دارای مشکلات امنیتی هستند. ارایه‌دهندگان نرم‌افزارهای متن باز نیز معمولاً بر روی «امنیت» تمرکز ویژه‌ای داشته و حتی بعضی از آنها اهمیت خاصی برای ایجاد امنیت در محصولاتشان قائل هستند.
به طور کلی نرم‌افزارهای متن باز بر اساس ساختارشان به پنج گروه تقسیم می‌شوند که عبارتند از:
- نرم‌افزار انفرادی: این محصول توسط یک شخص یا حداکثر چند فرد که دارای چشم‌اندازی یکسان هستند ارایه می‌شود.
- نرم‌افزار سلطنتی: یک نرم‌افزار متن باز انفرادی است که حمایت جامعه‌ای بزرگ از مشارکت‌کنندگان را به دست آورده و سازنده اصلی آن مثل یک دیکتاتور خیراندیش عمل می‌کند. لینوکس از جمله نرم‌افزارهای سلطنتی می‌باشد.
- نرم‌افزار اجتماعی: نرم‌افزار متن بازی که توسط گروهی با اهداف مشابه ارایه شده و به صورت مشترک مدیریت می‌شود. PostgreSQL یک نرم‌افزار اجتماعی است.
- نرم‌افزار شرکتی: این محصول معمولاً به صورت انشعابی از یک پروژه تجاری عرضه می‌شود. برای مثال شرکت تکنولوژی آمریکایی Sun، OpenOffice[2] را به عنوان انشعابی متن باز از [3]StarOffice منتشر کرد. مسیر حرکت چنین پروژه‌ای توسط شرکت منتشر کننده آن مشخص می‌شود.
- نرم‌افزار بنیادی: این نرم‌افزار متن باز دارای یک ساختار تجاری مستقل بوده و نسبت به کلیه نرم‌افزارهای متن باز رسمی‌تر می‌باشد. یک گروه هیئت مدیره تصمیم‌گیری درباره این نرم‌افزار را بر عهده دارند. آپاچی بهترین نمونه از نرم‌افزارهای بنیادی است.
به صورت کلی پروژه‌های انفرادی معمولاً در معرض مخاطرات امنیتی قرار دارند. همان‌گونه که یک نویسنده می‌تواند صفحه وب‌سایت خودش را با هر مطلبی به روزرسانی نموده و محتوای دلخواهش را در آن قرار دهد، توسعه‌دهنده انفرادی نیز قابلیت به‌روزرسانی و اصلاح کد خودش را به هر روشی دارد. در حالی که امکان ایجاد انشعابات انفرادی در پروژه‌های اجتماعی وجود نداشته و این پروژه‌ها به عنوان پروژه استاندارد اصلی در نظر گرفته می‌شوند. برای مثال Squires به راحتی با ایجاد تغییرات در کد خود و اصلاح آن، مقادیر پرچم‌ها را چاپ نموده و کد را در حلقه‌های بی‌نهایت وارد کرد.
امنیت پروژه‌های متن باز و متن بسته در گرو تمرکز و هدف اصلی کدنویسان آنها است و نه ساختار پروژه. برای مثال دغدغه اصلی Linus Torvalds[4] و [5]Theo de Raadt (که به عنوان یک «دیکتاتور خیرخواه» شناخته می‌شود) امنیت است. Theo de Raadt همواره اهمیت خاصی برای تأمین و حفظ امنیت در OpenBSD[6] قائل است. در حالی که پروژه تجاری StarOffice و در نتیجه OpenOffice دارای آسیب‌پذیری‌های امنیتی بسیار زیادی هستند. این حفره‌های امنیتی امکان اجرای کدهای دلخواه در فایل‌های XML (مخفف Extensible Markup Language) را فراهم می‌کردند.
تمرکز مشارکت‌کنندگان در پروژه
یکی از فرضیات نادرستی که درباره پروژه‌های متن باز وجود دارد این است که هر چه کد پروژه توسط کاربران و افراد بیشتری مشاهده شود، امنیت پروژه افزایش می‌یابد. اگرچه از سالیان گذشته تا کنون مبلغان امنیت مدعی هستند که با توجه به امکان بازبینی کدها توسط جامعه توسعه‌دهندگان، امنیت پروژه‌های متن باز افزایش می‌یابد، ولی برخلاف تصور همگان، توسعه‌دهندگان وقت چندانی صرف بازبینی، اصلاح و به‌روزرسانی کدها نمی‌کنند.
برای مثال چنین حس امنیت کاذبی در خطای نرم‌افزاری Heartbleed در کتابخانه رمزنگاری متن باز [7]OpenSSL وجود دارد. آسیب‌پذیری Heartbleed امکان خواندن حافظه رایانه‌ای را که در حال اجرای این برنامه است به مهاجمان می‌دهد. وجود کدهای زیاد و عدم بازبینی آنها به صورت گسترده و کارآمد موجب ایجاد نیاز در فرایندها و سیستم‌های اتوماسیون به ارتقای امنیت پروژه‌های متن باز شده است.
البته این تفکر که چون امکان مشاهده نرم‌افزارهای متن بسته برای همگان وجود ندارد پس این نرمافزارها از امنیت بیشتری برخوردار هستند نیز کاملاً غلط است. برای مثال جامعه برنامه‌نویسان پس از انجام تحقیقات گسترده بر روی آسیب‌پذیری Heartbleed و شناسایی حفره‌های موجود در OpenSSL متوجه شدند که راه‌حل اصلی برای رفع این آسیب‌پذیری‌ها بازتر کردن پروژه است. LibreSSL یک انشعاب از OpenSSL بوده و تمرکز ویژه‌ای بر روی امنیت دارد.
امنیت پروژه‌های متن باز در گرو مسئولیت‌پذیری مشترک است
اگرچه نرم‌افزارهای متن باز رایگان هستند و شما برای خرید آنها هزینه‌ای پرداخت نمی‌کنید، ولی همچنان مسئولیت کلیه نرم‌افزارهای متن بازی که در اختیار دارید نسب به کسب‌وکار و به‌ویژه در مقابل اعتماد مشتریان‌تان بر عهده شما است. در ادامه یکسری از نکاتی را که در هنگام استفاده از نرم‌افزارهای متن باز باید به آنها توجه داشته باشید تا امنیت پروژه‌های متن باز حفظ شود، مورد بررسی قرار می‌دهیم.
توجه کنید که از چه محصولی استفاده می‌کنید
امکان استفاده آسان از پروژه متن باز در پروژه متن بازی دیگر در یک اکوسیستم از جمله مخاطرات امنیتی مهم بوده و پیامدهای منفی بسیار زیادی را هم به همراه خواهد داشت. امروزه در بسیاری از پروژه‌ها، از پروژه‌های دیگر نیز استفاده می‌شود. وجود سیستم‌هایی مثل کتابخانه متن باز و رایگان NPM (مخفف Node Package Manager) که امکان افزودن پکیج‌های مختلف را به پروژه فراهم می‌کند موجب درج کدهای مختلف در پروژه بدون داشتن درکی کامل از عملکردشان می‌شود. ابزارهایی برای تولید فهرست اجزای نرم‌افزاری در کد وجود دارد که با استفاده از آنها می‌توانید کد را بررسی نموده و مشخص کنید که آیا این کد وابسته به کدهای دیگری هست که شما از آن بی‌خبر بودید یا خیر.
خودداری از به کار بردن پروژه‌های انفرادی و رها شده
ممکن است (به ویژه در زمان‌هایی که قابلیت به‌روزرسانی خودکار را فعال نموده‌اید) یک توسعه‌دهنده انفرادی مخرب، کدهای مضر زیادی را در پروژه تزریق کند. عدم توجه، رسیدگی و اصلاح آسیب‌پذیری‌های جدید در پروژه‌های رها شده ممکن است امنیت پروژه‌های متن باز را با مخاطراتی روبرو کند. وضعیت پروژه‌های مورد استفاده‌تان را با انتشار هر نسخه از آنها حتماً دوباره بازبینی کنید.
اجرای آزمون پیش از انتشار کد
بخش عمده‌ای از مخاطرات ناشی از پروژه‌های متن باز ناشی از به‌روزرسانی پروژه بدون محک زدن آن است. اگر کد شما حاوی یک کتابخانه متن باز آسیب‌پذیر باشد، کاربران شما را مسئول می‌دانند. نسخه‌های مختلف پروژه‌ها را همواره بررسی کرده و به روز نگه دارید. بهتر است پیش از ارایه این نسخه‌ها آزمون‌های سعی و خطا را بر روی آنها اجرا کنید. برای مثال می‌توانید از کتابخانه‌های متن باز مورد استفاده‌تان یک انشعاب ایجاد کرده و منابعی را به بازبینی کدها اختصاص دهید.
برنامه‌ریزی برای به روزرسانی‌ها
آسیب‌پذیری Log4j امکان اجرای کدهای دلخواه در پلتفرم‌هایی که نرم‌افزار را در حافظه رام (ROM) تعبیه می‌کنند، فراهم کرد. در حالی که یکسری از سیستم‌های اینترنت اشیا مجهز به هیچ راه‌حلی برای ارتقای کتابخانه Log4j و حل مشکلات امنیتی ناشی از آن نیستند. در چنین شرایطی آسیب‌پذیری‌های دائمی که امکان رفع آنها وجود ندارد ایجاد می‌شوند. کارشناسان امنیتی توصیه می‌کنند که جهت جلوگیری از وقوع چنین رویدادهایی بهتر است پیش از بروز مشکلات امنیتی یک مسیر ارتقا و برگشت به نسخه‌های قبلی برای هر قطعه فراهم کنید. می‌توانید جهت افزایش امنیت کدها یک برنامه مشخص برای انجام به روزرسانی‌های منظم در نظر بگیرید.
مشارکت در پروژه‌های متن باز
بسیاری از پروژه‌های متن باز با وجود اینکه منابع چندان زیادی در اختیار ندارند ولی کدهای مفیدی ارایه می‌دهند. می‌توانید با ارایه کمک‌های مالی، مشارکت در توسعه محصول یا پاسخ به سوالات در پروژه‌های متن باز مورد استفاده‌تان از آنها پشتیبانی کنید. همچنین این پروژه‌های متن باز نیازمند حمایت پیوسته هستند بنابراین در برنامه‌های بلندمدت و بودجه سالیانه‌تان مبلغی را برای این کار در نظر گرفته و حمایت خود را محدود به یک روز یا یک بار نکنید. انجام چنین کارهایی کمک می‌کنند که آخرین نسخه به مراتب ایمن تر از اولین نسخه باشد.
سرمایه‌گذاری در حوزه DevSecOps
احتمال بروز نقایص امنیتی در کدهایی که توسط تیم خودتان نوشته می‌شوند و همچنین در کدهایی که به صورت پروژه‌های متن باز تهیه می‌گردند وجود دارد. از این رو اجرا و نصب پیوسته به‌روزرسانی‌ها باید به صورت یک هنجار و موضوع همیشگی باشد و نه یک استثناء. جهت همگام ماندن با تغییرات معمولاً نیاز به انتشار سریع نسخه‌های جدید وجود دارد. استفاده از روش‌های ادغام مستمر (یا CI) و تحویل مستمر (یا CD) در چرخه DevSecOps جهت پیگیری سریع و ایمن تغییرات صورت گرفته در کدها از جمله راهکارهای کاربردی در این زمینه است. افزودن بحث امنیت به این رویکرد و در نظر گرفتن آن از همان مراحل مقدماتی طراحی منجر به پیشرفته‌تر شدن راهکار مدنظرتان می‌شود.
بیدار شدن از کابوس امنیت پروژه‌های متن باز
احتمال اینکه حداقل یکی از محصولات مورد استفاده شما شامل اجزا و نرم‌افزارهای متن باز است بسیار زیاد می‌باشد. حتی ممکن است همین مطلب را در مرورگری مطالعه می‌کنید که بر اساس فناوری متن باز طراحی شده یا با سروری به دست شما رسیده که دارای هسته متن باز است. بنابراین به هیچ وجه نباید از امنیت پروژه‌های متن باز غافل شوید. اگرچه کابوس‌ها واقعی نیستند، ولی ممکن است در اثر یک ترس کاملاً معقول شکل گرفته باشند. برای جلوگیری از بروز مشکلات جدی، در هنگام استفاده از نرم‌افزارهای متن باز دقت لازم را بکار گرفته و موارد امنیتی را رعایت کنید.
[1] امکان ایجاد تغییر در کدهای اصلی این نرمافزارها و رفع خطاهای آنها توسط کاربران و مشتریان وجود دارد.
[2] یک مجموعه اداری متن باز
[3] شامل مجموعه‌ای از نرم‌افزارهای اداری
[4] مهندس نرم‌افزاری که مسئولیت هماهنگ‌کننده پروژه (هسته لینوکس) را بر عهده دارد- ویکی‌پدیا
[5] مهندس نرم‌افزار که مؤسس و مدیر OpenBSD و OpenSSH است.
[6] یک نرم‌افزار رایگان منبع باز که تمرکز ویژه‌ای بر روی تأمین و حفظ امنیت دارد.
[7] یک کتابخانه متن باز که شامل پیاده‌سازی کدهای SSL و TLS است.
منبع: forrester
آیا نرم افزارهای متن باز امنیت کمتری دارند؟
خیر. هیچ قطعیتی وجود ندارد. امنیت نرم‌افزارهای متن باز هم مثل سایر برنامه‌های کاربردی و نرمافزارها مستلزم پیروی از اصول برنامه‌نویسی و امنیتی است. البته همچنان امکان وجود آسیب‌پذیری هست ولی آسیب‌پذیری‌ها در کدهای متن باز زودتر شناسایی می‌شوند.