سامانه گزارش سایبری اروپا راه افتاد؛ پاسخ فروشنده، رفع مشکل نیست

چه چیزی دیروز واقعاً عملیاتی شد؟

آژانس امنیت سایبری اتحادیه اروپا، ENISA، در ۱۱ سپتامبر ۲۰۲۶، برابر با ۲۰ شهریور ۱۴۰۵، اعلام کرد قابلیت عملیاتی اولیه «سامانه واحد گزارش‌دهی» یا SRP راه‌اندازی شده است. این ابزار برای ثبت گزارش‌های مقرر در قانون تاب‌آوری سایبری، CRA، ساخته شده؛ یک گزارش، مسیر رساندن اطلاعات به مراجع مربوط را فراهم می‌کند. خبر تازه، آغاز کار سامانه است، نه تصویب قانون در روز گذشته و نه اعلام پایان ریسک محصولات دیجیتال. ^[۱]

طبق اطلاعیه، تکلیف گزارش‌دهی سازندگان از ۱۱ سپتامبر ۲۰۲۶ شروع می‌شود، اما الزامات اصلی امنیت محصول از ۱۱ دسامبر ۲۰۲۷ اعمال خواهند شد. همین تفکیک برای خواندن خبر ضروری است: شروع یک بخش از اجرا، به معنی کامل‌شدن تمام مراحل نیست. پنجره این نسخه از ساعت ۰۷:۰۱ روز ۲۰ شهریور تا ۰۷:۰۱ روز ۲۱ شهریور به وقت تهران است؛ تاریخ انتشار اطلاعیه راه‌اندازی در این بازه قرار دارد. ^[۱]

خلاصه توضیحی کمیسیون اروپا، موضوع قانون را محصولات دارای عناصر دیجیتال، از جمله سخت‌افزار و نرم‌افزار عرضه‌شده در بازار اتحادیه، معرفی می‌کند. این خلاصه سند الزام‌آور یا شرح جامع همه استثناها نیست. برداشت ژرف‌بان: شرکت ایرانیِ خریدار نرم‌افزار را نباید صرفاً به‌خاطر خرید، همان سازنده مشمول دانست. اگر شرکتی محصول خود را در بازار اروپا عرضه می‌کند، نقش، محصول و مسیر عرضه‌اش نیازمند بررسی حقوقی جداگانه است؛ این خبر درباره شمول شرکت معین حکم نمی‌دهد. ^[۵]

۲۴ ساعت برای هشدار است، نه تضمین رفع آسیب‌پذیری

راهنمای کمیسیون اروپا دو موضوع گزارش را مشخص می‌کند: آسیب‌پذیریِ مورد بهره‌برداری فعال و رخدادی با اثر شدید بر امنیت محصول. برای هر دو، هشدار اولیه باید بدون تأخیر ناموجه و حداکثر ظرف ۲۴ ساعت پس از آگاهی سازنده ارسال شود؛ اطلاعیه بعدی نیز حداکثر ظرف ۷۲ ساعت از همان آگاهی است. بنابراین ۷۲ ساعت از پایان مهلت ۲۴ساعته شروع نمی‌شود و هر تیکت عادی پشتیبانی هم خودبه‌خود در این تعریف قرار نمی‌گیرد. ^[۲]

موعد گزارش نهایی به نوع رویداد وابسته است: برای آسیب‌پذیری مورد بهره‌برداری فعال، حداکثر ۱۴ روز پس از در دسترس قرار گرفتن اقدام اصلاحی؛ برای رخداد شدید، ظرف یک ماه پس از اطلاعیه ۷۲ساعته. مرجع دریافت، سازوکار گزارش‌دهی به نهادهای مسئول است. این اعداد زمان تحویل وصله به خریدار، مدت قطعی قابل قبول یا موعد تضمینی بازگرداندن سامانه مالی نیستند. گزارش نهاییِ وابسته به وجود اصلاح، وعده تولید اصلاح در ۱۴ روز محسوب نمی‌شود. ^[۲]

نتیجه قراردادی پیشنهادی ژرف‌بان، جداکردن سه تعهد است: چه زمانی فروشنده شرکت را از خطر مربوط به محصولش آگاه می‌کند، چه زمانی راه‌حل موقت یا اصلاح ارائه می‌دهد، و چه شاهدی بازگشت عملیات را تأیید می‌کند. اگر قرارداد فقط «پاسخ در ۲۴ ساعت» دارد، بپرسید پاسخ یعنی تأیید دریافت پیام یا آغاز رسیدگی متخصص. عددی که برای یک مرحله نوشته شده نباید بی‌توضیح به دو مرحله دیگر تعمیم داده شود؛ اعلام دریافت می‌تواند درست انجام شود، درحالی‌که مسئله هنوز باز است.

نسخه اولیه چه محدودیت عملی مهمی دارد؟

پرسش‌های متداول ENISA، به‌روزشده در ۱۱ سپتامبر، می‌گوید نسخه آغازین فقط گزارش‌های اجباری مربوط را پشتیبانی می‌کند؛ گزارش‌دهی داوطلبانه در مرحله بعد خواهد آمد. همچنین در عرضه اولیه، رابط برنامه‌نویسی یا API وجود ندارد و ثبت باید از رابط خود سامانه انجام شود. پس یکپارچه‌سازی گردش داخلی سازمان با ابزارهایش، معادل ارسال خودکار گزارش به SRP نیست. تکلیف متناظر متولیان نرم‌افزار متن‌باز نیز از دسامبر ۲۰۲۷ شروع می‌شود، نه هم‌زمان با سازندگان در خبر دیروز. ^[۳]

راهنمای ثبت‌نام ENISA، به‌روزشده در ۱۰ سپتامبر و مقدم بر پنجره خبر، ورود شخصی EU Login با احراز هویت چندعاملی را لازم می‌داند. اعتبارسنجی ارتباط نماینده با سازنده موازی با گزارش‌دهی انجام می‌شود و انتظار برای آن مانع ارسال اولیه نیست. خود راهنما توصیه می‌کند ثبت‌نام و آغاز اعتبارسنجی در SRP هنگام نیاز به ارسال گزارش انجام شود؛ آماده‌کردن حساب ورود با ثبت‌نام پیشاپیش در سامانه یکی نیست. ^[۴]

برای مدیری که واقعاً در سازمان مشمول مسئولیت دارد، پیشنهاد ژرف‌بان تعیین فرد مسئول، جانشین و مسیر دسترسی پیش از رخداد است؛ نه خرید فوری یک اتصال خودکارِ تأییدنشده. برای خریدار داخلی نیز سؤال مشابه، اما قراردادی است: فروشنده چه کسی را در شرکت مخاطب هشدار می‌داند و در نبود او چه می‌کند؟ وابستگی به صندوق ایمیلی که آخر هفته دیده نمی‌شود، مسئله فرایند شرکت است؛ نام یک سامانه اروپایی به‌تنهایی آن را حل نمی‌کند.

خریدار چه شاهدی بخواهد، نه چه شعار امنیتی؟

یک پشتوانه مستقل برای این پرسش، راهنمای مرکز ملی امنیت سایبری بریتانیا درباره شناخت زنجیره تأمین است؛ منتشرشده در ۱۶ فوریه ۲۰۲۳ و بازبینی‌شده در ۱۲ اکتبر همان سال، نه خبر تازه. این راهنما پیشنهاد می‌کند مهلت اطلاع‌رسانی و پاسخ به رخداد، کمک به یافتن علت اصلی و امکان ارزیابی تأمین‌کننده در قرارداد دیده شود. همچنین پیمانکاران فرعی و اهمیت خدمت را وارد بررسی می‌کند. این توصیه خرید است، نه تفسیر CRA یا قانون الزام‌آور برای ایران. ^[۶]

کاربرد پیشنهادی ژرف‌بان برای شرکت دارای سرور فایل، آرشیو اسناد یا نرم‌افزار مالی، سنجش تعهد همان فروشنده‌ای است که قرارداد را امضا می‌کند. در تمدید پشتیبانی، کانال اطلاع‌رسانی مربوط به مدل و نسخه مورد استفاده، مدت پوشش و مسئول اجرای اصلاح را مکتوب بخواهید. عبارت کلی «منطبق با استانداردهای اروپا» بدون دامنه محصول و شاهد، پاسخ این پرسش‌ها نیست. از طرف دیگر، نبود همین عبارت تبلیغاتی نیز به‌تنهایی برای ناامن دانستن محصول دیگر کافی نیست.

سناریوی فرضی مدیریتی: فروشنده دریافت پیام را به‌موقع تأیید می‌کند، اما برای کاهش خطر، توقف موقت دسترسی به آرشیو لازم تشخیص داده می‌شود. هنوز باید معلوم باشد چه کسی توقف را تأیید می‌کند، اسناد ضروری پرداخت از کدام مسیر مجاز در دسترس می‌مانند و بازگشایی چگونه کنترل می‌شود. هزینه کارشناس، اجرای اصلاح و دوباره‌کاری واحد مالی را جدا برآورد کنید. صرف اطلاع‌رسانی به‌موقع، این هزینه‌ها را صفر نمی‌کند و مسئول پرداخت آن‌ها نیز بدون قرارداد روشن نیست.

این هفته چه سندی از فروشنده بخواهیم و چه چیزی را رصد کنیم؟

اقدام محدود و پیشنهادی ژرف‌بان، انتخاب یک سامانه حیاتی و یک قرارداد در آستانه تمدید است. مالی، فناوری و خرید برای همان مورد، زمان اعلام رخداد، دامنه پشتیبانی، هزینه خدمت اضطراری و اختیار تصمیم را روشن کنند. خروجی مفید، پاسخ مکتوب فروشنده به یک سناریوی مشخص است؛ مثلاً اگر دسترسی به اسناد پرداخت متوقف شد، چه کسی ظرف چه مهلتی خبر می‌دهد و اقدام بعدی چیست. این کار به معنی الزام به تعویض فوری محصول نیست.

در مقایسه پیشنهادها، هزینه ثابت قرارداد را از هزینه موردی رسیدگی و هزینه احتمالی توقف جدا کنید. اگر زمان بازیابی یا جبران خسارت در پیشنهاد مبهم است، آن را تعهد قطعی تلقی نکنید و برای روشن‌شدنش مذاکره کنید. بهبود مستندسازی ممکن است ارزشمند باشد، اما بدون شاهد اجرای واقعی، کاهش زیان یا صرفه‌جویی عددی قابل ادعا نیست. آزمون بازیابی و کنترل دسترسی، موضوع‌هایی مکمل‌اند؛ دریافت هشدار جای آن‌ها را نمی‌گیرد و تغییر قرارداد نیز باید با اختیار طرفین انجام شود.

ENISA اعلام کرده قابلیت‌ها و راهنمای عملیاتی در ماه‌های بعد توسعه می‌یابند؛ بنابراین وضعیت API و گزارش داوطلبانه باید از اطلاعیه بعدی، نه وعده فعلی یک واسطه، تأیید شود. شاهد مهم برای خریدار ایرانی هم تغییر مکتوب شرایط پشتیبانی و نتیجه آزمون مورد توافق است. اگر فقط صفحه بازاریابی فروشنده عوض شده باشد، برداشت ما از بهترشدن خدمت هنوز تأیید نشده است. این تمایز، معیار بازبینی خبر را از شمار اعلان‌ها به کیفیت تعهد قابل سنجش منتقل می‌کند. ^{[۱] [۳]}

حدود بررسی: شش سند از سه ناشر استفاده شده و چند صفحه ENISA، تأییدهای مستقل متعدد محسوب نمی‌شوند. متن کامل مقرره در EUR-Lex هنگام بررسی به صفحه عمومی دیگری هدایت شد؛ ادعاهای اجرایی این نسخه بر راهنماهای مستقیم کمیسیون و ENISA متکی‌اند، نه ادعای مطالعه متن کامل قانون. خلاصه قدیمی کمیسیون، راهنمای بریتانیا و راهنمای ثبت‌نام، زمینه‌اند و خبر دیروز معرفی نشده‌اند. نتیجه درباره قرارداد ایرانی، تحلیل مشروط ژرف‌بان است؛ از آن الزام عمومی داخلی، مجوز عرضه خارجی یا تضمین امنیت استنتاج نمی‌شود.