بیشتر تیم‌های صنعتی اینترنت اشیا می‌توانند به شما بگویند که چه تعداد دستگاه لبه را در حال اجرا دارند. اما تعداد کمتری می‌توانند به دقت بگویند که روی هر دستگاه چه نسخه نرم‌افزاری نصب شده است، کدام مؤلفه‌ها آسیب‌پذیری‌های شناخته‌شده دارند، یا چقدر طول می‌کشد تا یک بسته امنیتی به تمام دستگاه‌های موجود در میدان ارسال شود.
این خلاء سال‌هاست که وجود داشته است. آنچه تغییر کرده، این است که رگولاتورها اکنون تیم‌ها را ملزم می‌کنند که به طور رسمی این فاصله را پر کنند. الزامات امنیتی اصلی قانون تاب‌آوری سایبری اتحادیه اروپا از دسامبر ۲۰۲۷ الزام‌آور می‌شود و وظایف گزارش‌دهی آسیب‌پذیری از همین ماه سپتامبر آغاز می‌گردد. جریمه‌های عدم تطابق با مواردی مانند امنیت پیش‌فرض یا فهرست اقلام نرم‌افزاری می‌تواند تا ۱۵ میلیون یورو یا ۲.۵ درصد از گردش مالی سالانه جهانی، هر کدام که بیشتر باشد، برسد.
این جدول زمانی نشان می‌دهد که انتظارات عملیاتی برای مدیریت نرم‌افزار لبه در سطح جهان به چه سمتی در حرکت است؛ چرا که ایالات متحده، ژاپن، هند و برزیل همگی در حال توسعه چارچوب‌های امنیتی برای دستگاه‌های متصل بر اساس مرجع پایه اتحادیه اروپا هستند.
الزامات مهم — یعنی امنیت پیش‌فرض، فهرست دقیق نرم‌افزارها و توانایی ارسال به‌روزرسانی به دستگاه‌ها در میدان — انتزاعی نیستند. این‌ها مشکلات مهندسی و عملیاتی هستند که هر تیمی که یک ناوگان لبه توزیع‌شده را اداره می‌کند، باید آن‌ها را حل کند؛ چه رگولاتور همین الآن از آن‌ها بخواهد و چه دو سال دیگر مطالبه کند.
امنیت پیش‌فرض یک تصمیم معماری است، نه یک مرحله پیکربندی
الزامات امنیت پیش‌فرض در قانون تاب‌آوری سایبری به این معناست که وضعیت اولیه دستگاه خارج از جعبه باید امن‌ترین حالت آن نیز باشد. اعتبارنامه‌های پیش‌فرض باید برای هر دستگاه منحصر به فرد باشند یا به طور کامل غیرفعال شوند، و بازگشت به تنظیمات کارخانه باید دستگاه را به همان خط مبنای امن بازگرداند، نه یک حالت ضعیف‌تر. پچ کردن ناوگان در طول چرخه عمر پشتیبانی، یک تعهد جداگانه و مداوم است. خدمات شبکه غیرضروری نیز باید مگر در صورت فعال‌سازی صریح، خاموش باشند.
برای تیم‌هایی که دستگاه‌های لبه را در کارخانه‌ها، انبارها یا سایت‌های میدانی مدیریت می‌کنند، پیامد این است که امنیت چیزی نیست که بتوانید پس از استقرار روی سیستم پیاده کنید؛ بلکه باید در تصویر نرم‌افزاری که روی دستگاه عرضه می‌شود، تعبیه شده باشد. این بدان معناست که فرآیند ساخت، مدیریت ایمیج و پایپ‌لاین استقرار شما باید از همان ابتدا پیکربندی امنیتی را لحاظ کند.
فهرست اقلام نرم‌افزاری یک وظیفه عملیاتی مداوم است، نه یک حسابرسی یک‌باره
الزامات مربوط به فهرست اقلام نرم‌افزاری از تولیدکنندگان می‌خواهد که یک فهرست به‌روز و دقیق از هر مؤلفه نرم‌افزاری در محصولات خود، از جمله وابستگی‌های شخص ثالث، نگهداری کنند. برای یک دستگاه واحد که پشته نرم‌افزاری مدرنی را اجرا می‌کند، این فهرست می‌تواند شامل صدها مؤلفه باشد. برای ناوگان دستگاه‌هایی که نسخه‌های مختلف میان‌افزار را در چندین سایت اجرا می‌کنند، حفظ فهرست دقیق یک تلاش عملیاتی مداوم است.
شکافی که بیشتر تیم‌ها آن را دست کم می‌گیرند، بخش «به‌روز» بودن است. تولید یک فهرست اولیه کار قابل‌اجرایی است. حفظ دقت آن با تکامل نرم‌افزار، با توجه به اینکه وابستگی‌های شخص ثالث به‌روزرسانی‌های خود را دریافت می‌کنند و دستگاه‌های مختلف در ناوگان شما نسخه‌های متفاوتی از نرم‌افزار شما را اجرا می‌کنند، نیازمند فرآیند و ابزار است، نه یک صفحه گسترده که هر فصل یک بار بررسی شود.
از نظر عملی، این بدان معناست که شما باید در هر لحظه بدانید: چه نرم‌افزاری روی کدام دستگاه‌ها در حال اجرا است، چه نسخه‌ای از هر مؤلفه روی هر دستگاه قرار دارد، و آیا هیچ‌یک از آن مؤلفه‌ها آسیب‌پذیری شناخته‌شده‌ای دارند یا خیر. بدون این میزان از شفافیت، شما نمی‌توانید الزامات افشای آسیب‌پذیری را نیز برآورده کنید، زیرا نخواهید دانست وقتی آسیب‌پذیری در یک وابستگیِ مورد استفاده شما گزارش می‌شود، کدام دستگاه‌ها تحت تأثیر قرار گرفته‌اند.
زیرساخت به‌روزرسانی هوایی الزامی است و باید به طور قابل‌اعتمادی کار کند
رگولاتورها عملاً تولیدکنندگان را ملزم می‌کنند که بتوانند به‌روزرسانی‌های امنیتی را روی دستگاه‌های موجود در میدان فشار دهند. برای محصولات مصرفی اینترنت اشیا، این موضوع به طور فزاینده‌ای به یک استاندارد تبدیل می‌شود. برای دستگاه‌های لبه صنعتی که اغلب در محیط‌های ایزوله، روی سخت‌افزارهای محدود یا در مکان‌هایی با اتصال غیرقابل‌اعتماد کار می‌کنند، ساخت زیرساخت به‌روزرسانی هوایی قابل‌اعتماد کلاس متفاوتی از مسئله است.
به‌روزرسانی هوایی قابل‌اعتماد در عمل به این معناست که به‌روزرسانی‌ها باید قبل از اجرا امضا و تأیید شوند تا اطمینان حاصل شود که یک به‌روزرسانی آلوده نمی‌تواند به ناوگان شما تزریق شود. به‌روزرسانی‌ها باید به طور ایمن با شکست مواجه شوند تا از خرابی یک به‌روزرسانی روی دستگاهی که خط تولید را اداره می‌کند جلوگیری شود، مبادا دستگاه از کار بیفتد یا به یک مهندس حضوری برای بازیابی نیاز داشته باشد. و فرآیند به‌روزرسانی شما باید با اتصال واقعی و محدودیت‌های سخت‌افزاری که دستگاه‌های شما تحت آن‌ها کار می‌کنند سازگار باشد، نه شرایط ایده‌آل یک محیط آزمایشگاهی.
برای تیم‌هایی که دستگاه‌های لبه را بدون مکانیزم به‌روزرسانی رسمی اداره کرده‌اند (مانند اتکا به به‌روزرسانی‌های دستی USB یا پنجره‌های تعمیر و نگهداری دوره‌ای در محل)، این بزرگ‌ترین شکاف عملیاتی برای رفع کردن است.
از کجا شروع کنیم
اگر در حال مدیریت یک ناوگان موجود هستید، اولویت‌های عملی به ترتیب زیر هستند:
- زیرساخت به‌روزرسانی هوایی، زیرا بدون آن نمی‌توانید آسیب‌پذیری‌ها را حتی پس از یافتن آن‌ها اصلاح کنید.
- فهرست نرم‌افزار، زیرا قبل از ارزیابی میزان مواجهه خود، به دیدگاهی شفاف نسبت به آنچه در حال اجراست نیاز دارید.
- حسابرسی امنیت پیش‌فرض برای درک فاصله بین پیکربندی‌های فعلی شما و آنچه رگولاتورها و مشتریانتان به طور فزاینده‌ای مطالبه خواهند کرد. کارت امتیاز آمادگی امنیتی عملیاتی پورتینر OT Security Readiness Scorecard آن حسابرسی را در یک قالب ساختاریافته طی می‌کند: ۲۵ سؤال در زمینه مدیریت پچ، کنترل دسترسی، معماری و قرار گرفتن در معرض مقررات.
تیم‌هایی که این موضوع را به عنوان یک مسئله تطابق با قوانین اروپا تلقی می‌کنند، مسیر پیش رو را دست کم می‌گیرند. الزامات مهندسی که قانون تاب‌آوری سایبری تدوین می‌کند (قابلیت به‌روزرسانی در چرخه عمر، شفافیت نرم‌افزاری، پیکربندی‌های پیش‌فرض امن) در حال تبدیل شدن به پیش‌شرط‌های اصلی برای فروش دستگاه‌های متصل در بازارهای سازمانی و صنعتی در سراسر جهان است. ساخت زیرساخت عملیاتی برای برآورده کردن آن‌ها صرفاً یک سرمایه‌گذاری برای انطباق نیست؛ بلکه شکل مدیریت قابل‌اعتماد ناوگان لبه در مقیاس وسیع است.
منبع: The Software Requirements Regulators Are About to Make Non-Negotiable for Edge Fleets — IoT For All؛ نویسنده: Portainer.io
منبع: iotforall