انتقال امن داده از OT به IT با RUSG؛ داده را به هوش مصنوعی بدهید، نه دسترسی شبکه را

تا چند سال پیش، مسئله بسیاری از مدیران زیرساخت این بود که چگونه شبکه OT را از IT جدا کنند. امروز پرسش دشوارتر شده است: چگونه این جداسازی را حفظ کنیم، اما داده‌های عملیاتی را به SOC، SIEM، Historian، داشبوردهای مدیریتی، فضای ابری و سامانه‌های هوش مصنوعی برسانیم؟

پاسخ کوتاه این است: داده باید از مرز امنیتی عبور کند، نه دسترسی شبکه.

اینجا همان نقطه‌ای است که دروازه امن یک‌سویه رهبان (RUSG) معنا پیدا می‌کند. RUSG با استفاده از دیتادیود اپتیکال در هسته داخلی خود، به سازمان اجازه می‌دهد داده‌های موردنیاز را از شبکه عملیاتی به شبکه فناوری اطلاعات منتقل کند، درحالی‌که مسیر فیزیکی بازگشت فرمان، درخواست یا تهدید سایبری به OT وجود ندارد.

در این مقاله بررسی می‌کنیم چرا انتقال امن داده از OT به IT به یکی از موضوعات مهم امنیت سایبری در سال ۲۰۲۶ تبدیل شده، دیتادیود چه نقشی در هسته RUSG دارد و این محصول چگونه داده پروتکل‌های صنعتی را بدون ایجاد مسیر برگشت در اختیار سامانه‌های IT قرار می‌دهد.

خلاصه‌ای برای مدیران

• شبکه‌های OT برای پایش امنیت، نگهداری پیش‌بینانه، گزارش‌گیری و تحلیل هوشمند باید بخشی از داده‌های خود را در اختیار سامانه‌های IT قرار دهند.
• اتصال دوسویه، حتی اگر پشت فایروال باشد، یک مسیر شبکه برای بازگشت ترافیک ایجاد می‌کند و باید به‌عنوان یک سطح حمله مدیریت شود.
• دیتادیود داخلی RUSG، جهت انتقال را در سطح سخت‌افزار یک‌طرفه می‌کند؛ بنابراین خطای پیکربندی نمی‌تواند مسیر برگشت را دوباره فعال کند.
• دیتادیود به‌تنهایی فقط جهت جریان را تضمین می‌کند. RUSG برای انتقال پروتکل‌های مبتنی بر TCP، مدیریت کانکتورها، ثبت رخداد و بازسازی داده در مقصد به کار می‌رود.
• بهترین کاربردها شامل ارسال لاگ به SIEM، انتقال داده به Historian ثانویه، پایش مرکزی، داشبورد مدیریتی، تحلیل ابری و تغذیه مدل‌های هوش مصنوعی است.
• اگر یک فرایند واقعاً به فرمان برگشتی، نشست دوسویه یا تأییدیه انتهابه‌انتها نیاز دارد، نباید بدون بازطراحی روی مسیر یک‌سویه قرار گیرد.

چرا دیتادیود دوباره به یک ترند جدی تبدیل شده است؟

بازگشت توجه به دیتادیود فقط نتیجه افزایش حملات سایبری نیست. سه تغییر هم‌زمان، معماری امنیت OT را تحت فشار قرار داده‌اند.

۱. OT دیگر نمی‌تواند کاملاً از داده‌های سازمان جدا بماند

داده‌های PLC، SCADA، DCS، حسگرهای IIoT و سامانه‌های کنترل فرایند برای تصمیم‌گیری عملیاتی ارزش بالایی دارند. واحدهای نگهداری، بهره‌برداری، امنیت، مدیریت انرژی و تحلیل داده می‌خواهند این اطلاعات را در Historian مرکزی، داشبوردهای مدیریتی، دریاچه داده یا پلتفرم‌های تحلیلی استفاده کنند.

قطع کامل ارتباط ممکن است سطح مواجهه را کم کند، اما دیدپذیری، تحلیل و واکنش سازمان را نیز محدود می‌کند. معماری جدید باید میان دو هدف تعادل برقرار کند: استقلال شبکه OT و دسترس‌پذیری کنترل‌شده داده.

۲. باج‌افزار و حرکت جانبی، مرز IT و OT را حساس‌تر کرده‌اند

گزارش چشم‌انداز تهدید ENISA در سال ۲۰۲۵، باج‌افزار را اثرگذارترین تهدید سایبری در اتحادیه اروپا معرفی می‌کند و سوءاستفاده از وابستگی‌های دیجیتال و زنجیره تأمین را از روندهای قابل‌توجه می‌داند. هر اتصال میان IT، پیمانکار، Cloud و OT می‌تواند در ارزیابی مسیرهای حرکت جانبی مهاجم اهمیت پیدا کند.

دیتادیود همه مسیرهای آلودگی را از بین نمی‌برد؛ لپ‌تاپ تعمیرکار، حافظه USB، زنجیره تأمین یا یک ارتباط جایگزین همچنان می‌تواند ریسک ایجاد کند. اما در مسیر مشخصی که دیتادیود روی آن قرار گرفته است، امکان برگشت ترافیک از مقصد به مبدأ به‌صورت فیزیکی حذف می‌شود. این تفاوت میان «کاهش احتمال» و «حذف یک مسیر حمله» است.

۳. هوش مصنوعی و Cloud به داده نیاز دارند، اما نباید به کنترل دسترسی پیدا کنند

گزارش Global Cybersecurity Outlook 2026 مجمع جهانی اقتصاد نشان می‌دهد هوش مصنوعی هم‌زمان محرک نوآوری و یکی از مهم‌ترین عوامل تغییر ریسک سایبری است. در محیط صنعتی، این دوگانگی کاملاً ملموس است: الگوریتم‌ها برای تشخیص ناهنجاری، نگهداری پیش‌بینانه، بهینه‌سازی مصرف انرژی و تحلیل کیفیت به داده‌های OT نیاز دارند؛ ولی سرویس تحلیلی یا ابری نباید بتواند ارتباطی را از بیرون به سمت تجهیزات کنترل آغاز کند.

راهکار منطقی این نیست که از تحلیل داده صرف‌نظر کنیم. باید تله‌متری و داده مجاز را خارج کنیم، بدون آنکه دسترسی تعاملی به داخل ایجاد شود.

دیتادیود چیست و چگونه مسیر برگشت را حذف می‌کند؟

دیتادیود یا Data Diode یک تجهیز سخت‌افزاری برای انتقال داده فقط در یک جهت است. در پیاده‌سازی اپتیکال، سمت فرستنده دارای مؤلفه ارسال نور و سمت گیرنده دارای مؤلفه دریافت نور است؛ اما کانال متناظری برای ارسال از گیرنده به فرستنده وجود ندارد.

به همین دلیل، جهت ارتباط وابسته به Rule، ACL، Route یا تنظیم نرم‌افزاری نیست. تغییر پیکربندی، حساب کاربری سرقت‌شده یا آسیب‌پذیری سیستم‌عامل نمی‌تواند گیرنده را به فرستنده تبدیل کند، زیرا مسیر فیزیکی لازم وجود ندارد.

این ویژگی با فایروال تفاوت بنیادی دارد: فایروال ترافیک روی یک مسیر شبکه را طبق سیاست کنترل می‌کند؛ دیتادیود خودِ مسیر برگشت را حذف می‌کند. البته این دو رقیب مطلق یکدیگر نیستند و در معماری دفاع در عمق می‌توانند نقش‌های مکمل داشته باشند.

«چرا دیتا دیود از فایروال امن‌تر است؟»

ترند مهم ۲۰۲۶: جداسازی عملیاتی به‌جای خاموش‌کردن جریان داده

راهنمای امنیت اتصال OT مرکز ملی امنیت سایبری بریتانیا (NCSC) که در ژانویه ۲۰۲۶ منتشر شده، توصیه می‌کند هرجا ممکن است ارتباط خروجی و یک‌طرفه برقرار شود تا اثر سیستم‌های خارجی بر OT کاهش یابد. همین راهنما تأکید می‌کند دیتادیود جهت را در سخت‌افزار تضمین می‌کند، اما به‌تنهایی جای همه کنترل‌های یک راهکار Cross Domain را نمی‌گیرد.

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

بنابراین ترند اصلی، بازگشت ساده به Air Gap نیست. موضوع روز، Operational Isolation یا جداسازی عملیاتی است: مرزی که اجازه می‌دهد خروجی‌های تعریف‌شده از OT عبور کنند، اما شبکه بیرونی نتواند یک نشست یا فرمان را به داخل آغاز کند.

معماری انتقال امن داده از OT به IT در RUSG چگونه است؟

یک معماری درست معمولاً فقط از یک جعبه در میانه شبکه تشکیل نمی‌شود، جریان داده باید از ابتدا تا انتها تعریف، محدود و قابل پایش باشد.

گام اول: تعریف نیاز اطلاعاتی

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

نمونه‌های نیاز اطلاعاتی عبارت‌اند از:

• لاگ‌های امنیتی برای SOC و SIEM؛
• مقادیر فرایندی منتخب برای Historian ثانویه؛
• وضعیت سلامت تجهیزات برای نگهداری پیش‌بینانه؛
• شاخص‌های تولید و انرژی برای داشبورد مدیریتی؛
• داده‌های برچسب‌گذاری‌شده برای تحلیل یا مدل‌های هوش مصنوعی؛
• گزارش‌ها و فایل‌های تأییدشده برای شبکه سازمانی.

گام دوم: دریافت و خاتمه پروتکل در سمت مبدأ

بسیاری از پروتکل‌های رایج مانند OPC UA، MQTT و Modbus TCP بر TCP یا الگوهای تعاملی متکی‌اند. نشست TCP، ACK و پیام‌های کنترلی آن نمی‌توانند به همان شکل از یک کانال فیزیکی یک‌طرفه عبور کنند.

در RUSG، کانکتور سمت OT ارتباط لازم را با منبع برقرار می‌کند، داده مجاز را دریافت و به قالب انتقال داخلی تبدیل می‌کند. بنابراین نشست اصلی در همان سمت خاتمه می‌یابد؛ چیزی به نام «عبور مستقیم نشست TCP از دیتادیود» وجود ندارد.

گام سوم: انتقال یک‌طرفه از هسته سخت‌افزاری

داده بسته‌بندی‌شده از دیتادیود اپتیکال داخلی RUSG عبور می‌کند. این بخش فقط دارای فرستنده در سمت OT و گیرنده در سمت IT است. وضعیت لینک، صف، نرخ انتقال و خطاها پایش می‌شود، بدون آنکه سازوکار مدیریتی مسیر برگشت مخفی ایجاد کند.

گام چهارم: بازسازی و انتشار در سمت مقصد

کانکتور مستقل RUSG در سمت IT داده را دریافت، بازسازی و برای مصرف‌کننده مقصد بازنشر می‌کند. مقصد ممکن است SIEM، Historian، Broker پیام، پایگاه داده، سامانه مانیتورینگ یا API داخلی باشد.

این مدل را می‌توان چنین خلاصه کرد:

در این زنجیره، داده فقط از منبع OT به سمت مصرف‌کننده حرکت می‌کند و هیچ نشست شبکه‌ای از مقصد به منبع بازنمی‌گردد.

پنج سناریوی پرکاربرد RUSG در سال ۲۰۲۶

۱. ارسال لاگ OT به SOC و SIEM

SOC برای کشف رخداد و هم‌بستگی هشدارها به لاگ نیاز دارد، اما SIEM سازمانی یا ابری نباید به تجهیزات OT دسترسی شبکه‌ای پیدا کند. الگوی NCSC برای صادرات امن داده، دیتادیود را به‌عنوان یکی از کنترل‌های تضمین جریان یک‌طرفه معرفی می‌کند.

در این سناریو، RUSG لاگ‌های منتخب را از OT به مخزن مرکزی منتقل می‌کند. حتی اگر SIEM، Collector سمت IT یا حساب کاربری تحلیل‌گر به خطر بیفتد، مهاجم نمی‌تواند از همان لینک به OT بازگردد یا نسخه اصلی لاگ را در مبدأ تغییر دهد.

۲. تکثیر داده Historian بدون Trust دوسویه

روش‌های متداول Replication پایگاه داده و Historian معمولاً به TCP دوسویه و رابطه اعتماد میان دو سر نیاز دارند. نمونه اجرایی NCSC برای خروج داده OT توضیح می‌دهد که این مدل می‌تواند مسیر حرکت جانبی ایجاد کند و یک الگوی Stateless و یک‌طرفه، با Snapshot یا Export داده، جایگزین مناسب‌تری برای برخی سناریوهاست.

در عمل، RUSG می‌تواند داده‌های برچسب‌گذاری‌شده را دریافت و به Historian ثانویه در IT منتقل کند؛ بدون آنکه Replica بتواند از همان مسیر به Primary متصل شود.

۳. تغذیه تحلیل ابری و هوش مصنوعی

مدل‌های تشخیص ناهنجاری و نگهداری پیش‌بینانه به جریان پیوسته داده نیاز دارند، نه لزوماً دسترسی مستقیم به PLC یا SCADA. RUSG داده‌های منتخب را به‌صورت یک‌سویه به محیط تحلیلی منتقل می‌کند و نتیجه تحلیل از همان مسیر نمی‌تواند به فرمان کنترلی تبدیل شود.

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

۴. پایش متمرکز چند سایت صنعتی

سازمان‌هایی با چند کارخانه، نیروگاه، ایستگاه یا مرکز عملیاتی می‌توانند با استقرار RUSG، داده‌های سلامت و شاخص‌های منتخب هر سایت را به مرکز نظارت منتقل کنند. مرکز، دید تجمیعی دریافت می‌کند اما توان برقراری نشست به سمت کنترلرهای سایت از همان مسیر را ندارد.

۵. انتقال فایل و گزارش میان شبکه‌های جداشده

دیتادیود جهت انتقال را تضمین می‌کند، اما سالم‌بودن فایل را تضمین نمی‌کند. فایل می‌تواند در جهت مجاز نیز حامل محتوای مخرب باشد. برای این کاربرد باید لایه‌هایی مانند تشخیص نوع واقعی فایل، محدودسازی فرمت، YARA، چند موتور ضدبدافزار، CDR و Sandbox بر اساس سطح ریسک در نظر گرفته شود.

دیتادیود، RUSG و سامانه انتقال امن فایل یک راهکار واحد نیستند

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

در سبد راهکارهای رهبان، RDD-1001 یک دیتادیود سخت‌افزاری برای انتقال مستقیم و یک‌طرفه مبتنی بر UDP است؛ اما راهکار موردنظر این مقاله برای انتقال کاربردی داده از OT به IT، دروازه امن یک‌سویه رهبان (RUSG) است. RUSG برای سناریوهایی طراحی شده که داده پروتکل‌هایی مانند OPC UA، Modbus TCP، S7 یا MQTT باید در سمت OT دریافت و پس از عبور یک‌طرفه از دیتادیود داخلی، در سمت IT بازنشر شود. پشتیبانی دقیق از هر پروتکل و توپولوژی باید در مرحله طراحی سناریو تأیید شود.

برای انتقال فایل نیز پادرا لایه‌های تحلیل و پاک‌سازی مانند CDR، YARA، Multi-AV و Sandbox را با مسیر انتقال یک‌سویه ترکیب می‌کند. این تفکیک مهم است: دیتادیود جهت را تضمین می‌کند و لایه‌های نرم‌افزاری، سیاست و محتوای جریان را مدیریت می‌کنند.

RUSG کجا انتخاب مناسبی نیست؟

یک راهکار امنیتی خوب از پاسخ «نه» نیز شروع می‌شود. RUSG برای هر نوع ارتباطی مناسب نیست و برای جریان‌هایی طراحی شده است که ماهیت واقعی آن‌ها یک‌طرفه است.

اگر فرایند به هر یک از موارد زیر نیاز دارد، معماری باید بازطراحی یا راهکار دیگری انتخاب شود:

• کنترل مستقیم و بلادرنگ تجهیزات از شبکه IT؛
• Remote Access یا عیب‌یابی تعاملی از بیرون؛
• پروتکلی که بدون پاسخ طرف مقابل قابل استفاده نیست و Proxy مناسبی برای آن وجود ندارد؛
• تأییدیه انتهابه‌انتها از سامانه مقصد به منبع؛
• به‌روزرسانی، Patch Management یا توزیع فرمان از IT به OT؛
• همگام‌سازی دوسویه پایگاه داده.

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

چک‌لیست انتخاب و پیاده‌سازی RUSG

پیش از خرید یا اجرای پایلوت فنی، پاسخ این پرسش‌ها باید روشن باشد:

• جهت دقیق جریان داده چیست و چرا مقصد به ارسال پاسخ نیاز ندارد؟
• منبع و مصرف‌کننده نهایی داده کدام سامانه‌ها هستند؟
• پروتکل مبدأ و مقصد چیست و نشست آن در کدام سمت خاتمه می‌یابد؟
• نرخ تولید داده، Peak، Latency قابل‌قبول و ظرفیت Buffer چقدر است؟
• در زمان قطع مقصد، داده Drop، ذخیره یا پس از بازیابی ارسال می‌شود؟
• چگونه کامل‌بودن، ترتیب، Timestamp و تازگی داده در مقصد پایش می‌شود؟
• کدام فیلدها یا تگ‌ها مجازند و چه داده‌ای نباید از OT خارج شود؟
• آیا محتوای عبوری ساختاریافته و قابل اعتبارسنجی است؟
• مدیریت، ثبت رخداد و به‌روزرسانی Gateway چگونه انجام می‌شود؟
• آیا در طراحی، مسیرهای جایگزین مانند Wi-Fi، مودم، VPN، لپ‌تاپ تعمیرکار و USB نیز بررسی شده‌اند؟
• در شرایط بحران، نقطه جداسازی و رویه ادامه عملیات چیست؟
• آزمون پذیرش چگونه ثابت می‌کند هیچ مسیر فیزیکی برگشتی وجود ندارد؟

چند تصور اشتباه درباره دیتادیود

«دیتادیود جای همه ابزارهای امنیتی را می‌گیرد»

خیر. دیتادیود یک کنترل بسیار قدرتمند برای جهت ارتباط است، نه جایگزین مدیریت دارایی، سخت‌سازی، EDR، کنترل دسترسی، مانیتورینگ، امنیت فیزیکی و پاسخ به رخداد.

«هر داده‌ای که از دیتادیود عبور کند سالم است»

خیر. یک‌طرفه‌بودن درباره جهت است، نه ماهیت محتوا. داده و فایل باید پیش از تحویل به محیط حساس، متناسب با سناریو اعتبارسنجی یا پاک‌سازی شوند.

«دیتادیود یعنی دیگر داده بلادرنگ نداریم»

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

«اگر فایروال Rule یک‌طرفه داشته باشد، نتیجه همان است»

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

«دیتادیود به‌تنهایی جلوی هر باج‌افزاری را می‌گیرد»

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

پرسش‌های متداول درباره انتقال یک‌سویه داده

آیا می‌توان OPC UA را با RUSG از OT به IT منتقل کرد؟

بله. نشست TCP مربوط به OPC UA مستقیماً از دیتادیود عبور نمی‌کند. در RUSG، Client یا Connector سمت OT داده را دریافت می‌کند، داده از کانال یک‌طرفه داخلی منتقل می‌شود و Server یا Publisher مستقل در سمت IT آن را بازنشر می‌دهد.

چگونه با RUSG لاگ‌های شبکه OT را به SIEM بفرستیم؟

ابتدا منابع لاگ و فیلدهای ضروری تعیین می‌شوند. سپس کانکتور RUSG در سمت OT پیام‌ها را دریافت و از مسیر یک‌سویه به بخش گیرنده RUSG در سمت IT منتقل می‌کند. داده در قالب مورد انتظار SIEM تحویل داده می‌شود. Buffer، قطع ارتباط، Timestamp و هشدار توقف جریان نیز باید در طراحی سناریو دیده شوند.

آیا دیتادیود می‌تواند جای Air Gap را بگیرد؟

دیتادیود برای سناریوهایی مناسب است که جداسازی قوی همراه با خروج مستمر داده لازم است. Air Gap و دیتادیود الزاماً هم‌معنا نیستند؛ تصمیم به حساسیت دارایی، نیاز عملیاتی و مسیرهای جانبی وابسته است.

آیا می‌توان داده OT را به Cloud فرستاد؟

بله، اگر معماری مقصد، حاکمیت داده، رمزنگاری، احراز هویت و حداقل‌سازی داده به‌درستی طراحی شود. دیتادیود می‌تواند مانع آغاز ارتباط از Cloud به OT از طریق همان لینک شود، اما امنیت حساب ابری و سامانه مقصد همچنان ضروری است.

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

دیتادیود مؤلفه سخت‌افزاری تضمین‌کننده جهت است. دروازه امن یک‌سویه مجموعه‌ای از دیتادیود، کانکتورها، Proxyها، مدیریت سرویس، ثبت رخداد و کنترل‌های لازم برای انتقال کاربردی داده میان دو شبکه است.

آیا استفاده از دیتادیود باعث از دست رفتن داده می‌شود؟

پروتکل یک‌طرفه تأیید دریافت انتهابه‌انتها را به مبدأ بازنمی‌گرداند؛ بنابراین مدیریت Buffer، شماره توالی، تشخیص Gap و مانیتورینگ گیرنده اهمیت زیادی دارد. میزان تحمل از دست رفتن داده باید پیش از طراحی مشخص شود.

منابع و مطالعه بیشتر

• ENISA Threat Landscape 2025
• Global Cybersecurity Outlook 2026 – World Economic Forum
• Secure Connectivity Principles for Operational Technology – NCSC
• Operational OT Data Export Example – NCSC
• Design Pattern: Safely Exporting Data – NCSC

جمع‌بندی: مرز امن، مرزی نیست که داده را زندانی کند

سازمان‌ها نمی‌توانند برای همیشه میان امنیت OT و استفاده از داده یکی را انتخاب کنند. SOC به لاگ نیاز دارد، مدیریت به شاخص‌های عملیاتی نیاز دارد و سامانه‌های تحلیلی و هوش مصنوعی برای ایجاد ارزش به داده واقعی متکی‌اند. چالش این است که دسترسی موردنیاز برای دریافت داده، به مسیر نفوذ به شبکه کنترل تبدیل نشود.

RUSG این مسئله را از پایه تغییر می‌دهد: دیتادیود داخلی آن، مسیر برگشت را در سطح سخت‌افزار حذف می‌کند و کانکتورهای دو سمت، این تضمین فیزیکی را به یک سرویس قابل استفاده برای OPC UA، MQTT، Historian، SIEM و سایر مصرف‌کنندگان تبدیل می‌کنند.

اگر در سازمان شما داده باید از OT خارج شود اما هیچ فرمانی نباید از IT، Cloud یا مرکز پایش به شبکه عملیاتی بازگردد، تیم رهبان آمادگی دارد جریان‌های اطلاعاتی، پروتکل‌ها و الزامات عملیاتی را بررسی و سناریوی متناسب با RUSG را طراحی کند.