فرمان روشنایی از کجا آمده است؟ ارزیابی امنیت KNX و Zigbee با رویکرد دفاع در عمق

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

## KNX؛ دسترسی به باس و مسئله اعتبار فرمان

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

راهکار KNX Secure از دو بخش با محدوده عملکرد متفاوت تشکیل شده است. «امنیت داده KNX» یا KNX Data Secure، تلگرام های مرتبط را با رمزنگاری، احراز اصالت و کنترل شماره توالی محافظت می کند و گیرنده موظف است تلگرام تکراری یا قدیمی را رد کند. از سوی دیگر، «امنیت IP در KNX» یا KNX IP Secure، ارتباط روی بستر IP را ایمن می سازد، اما به تنهایی تلگرام های خط زوج تابیده را امن نمی کند.

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

در راه اندازی امن، کلید اختصاصی کارخانه ای تجهیز به نرم افزار ETS معرفی شده و سپس کلید برنامه ریزی جایگزین آن می گردد. نتیجه اجرایی کاملا روشن است: کدهای راه اندازی و فایل پروژه بخشی از دارایی های امنیتی ساختمان محسوب می شوند؛ بنابراین پیشنهاد می شود دسترسی و تحویل آن ها درست مانند سایر مدارک حساس پروژه ثبت شود.

## Zigbee؛ رمزنگاری بدون مدیریت کلید کافی نیست

در Zigbee، امنیت لایه شبکه بر پایه کلید مشترک شبکه بنا شده و سازوکارهای امنیتی شامل رمزنگاری، صحت سنجی و شمارنده فریم هستند. به همین دلیل، ارزیابی امنیت باید علاوه بر شنود رادیویی، سناریوی افشای کلید از یک عضو شبکه را نیز پوشش دهد؛ چرا که دانستن کلید شبکه در بسیاری از تبادلات معمول Zigbee 3.0 برای مشارکت در پیام رسانی کافی است.

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

هنگام خرید و تحویل تجهیزات Zigbee 3.0، پرسش صحیح این نیست که «آیا این تجهیز رمزنگاری دارد؟»؛ بلکه باید پرسید: «ورود دستگاه چگونه احراز می شود و کلید شبکه چگونه تحویل داده می شود؟». مستندات Zigbee میان کلید پیوند پیش فرض شناخته شده و کلید اختصاصی مشتق شده از کد نصب تمایز قائل می شوند. پیشنهاد اجرایی این است که پشتیبانی واقعی هاب و تجهیز از روش اختصاصی، پیش از خرید تایید و پس از راه اندازی نیز آزموده شود.

## دفاع در عمق؛ مرزبندی پیش از اتصال

مفهوم دفاع در عمق به این معناست که امنیت پروتکل نباید تنها مانع پیش روی مهاجم باشد. استاندارد IEC 62443-3-2:2020 با عنوان «امنیت سامانه های اتوماسیون و کنترل صنعتی بخش ۳۲: ارزیابی ریسک امنیتی برای طراحی سامانه»، مواردی همچون تعریف محدوده سامانه، تقسیم آن به ناحیه ها و گذرگاه های ارتباطی، ارزیابی ریسک و تعیین سطح امنیت هدف را مطالبه می کند. هرچند دامنه این استاندارد صنعتی است، اما استفاده از منطق آن در ساختمان ها نیز کاربرد دارد، هرچند به خودی خود ادعای انطباق کامل ایجاد نمی کند.

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

برای نمونه، در یک سناریوی اجرایی، ممکن است روتر KNX و هاب Zigbee به همان سوئیچی متصل باشند که به شبکه کاربران سرویس می دهد. پیشنهاد اصلاحی این است که جداسازی منطقی یا فیزیکی بخش کنترل انجام شده و دسترسی های مدیریتی محدود گردند؛ سپس حفاظت خط KNX و فرآیند پذیرش دستگاه Zigbee به صورت جداگانه بررسی شوند. مرزبندی شبکه هرگز جایگزین حفاظت تلگرام و مدیریت کلید نمی شود، بلکه هر لایه مسیر متفاوتی را پوشش می دهد.

## چک لیست پیشنهادی برای مجری برق ساختمان

موارد زیر را به عنوان معیارهای پذیرش پروژه و متناسب با ارزیابی ریسک، در صورت جلسه تحویل نهایی ثبت کنید:

- تهیه نقشه امنیتی: خطوط باس، رابط های IP، هاب ها، نقاط دسترسی فیزیکی و مسیرهای نگهداری را به طور کامل مشخص کنید.

- بررسی تفکیکی KNX: وضعیت KNX Data Secure را در گروه های حساس و وضعیت KNX IP Secure را در ارتباطات IP به صورت جداگانه ثبت کنید؛ مسیرهای ناامن باقی مانده را پنهان نکنید.

- ارزیابی Zigbee: روش پذیرش دستگاه، استفاده از کد نصب و نحوه تحویل کلید شبکه را بررسی کنید و تنها به عناوین تجاری محصول اکتفا نکنید.

- کنترل پذیرش دستگاه: پذیرش تجهیزات جدید را فقط هنگام نصب مجاز بدانید و پس از آن، بسته بودن مسیر پذیرش را بیازمایید؛ سیاست ورود دستگاه باید جزئی از تنظیمات مستند مرکز اعتماد باشد.

- مدیریت فایل های پروژه: فایل پروژه، کدهای نصب و اطلاعات بازیابی را با دسترسی محدود تحویل داده و مسئول نگهداری آن ها را به صراحت مشخص کنید.

- آزمون عملی: با کسب مجوز از مالک و در یک محیط کاملا کنترل شده، مسدود شدن ارتباطات غیرمجاز و محدودیت دسترسی بین ناحیه ها را بررسی کرده و نتایج را ثبت کنید.

## جمع بندی

مقایسه مهندسی به پاسخ قطعی برای این پرسش که «KNX امن تر است یا Zigbee؟» منجر نمی شود، بلکه محدوده حفاظت و کیفیت پیاده سازی را مشخص می کند. در پروتکل KNX باید به روشنی دانست که کدام تلگرام و کدام بستر امن شده است؛ و در پروتکل Zigbee باید چرخه ورود دستگاه و مدیریت کلید را به خوبی شناخت. معیار تحویل پروژه نیز بهتر است مبتنی بر شواهد پیکربندی و آزمون باشد: «پروتکل امن، پیکربندی مستند، مرزبندی آزموده».

## منابع

۱. توماس واین تسیرل، انجمن KNX؛ «امنیت KNX: حفاظت تاسیسات از داخل و خارج»، ۲۰۲۱.

۲. اتحاد استانداردهای اتصال؛ «مشخصات زیگبی»، بازنگری ۲۳، سند ۰۵-۳۴۷۴-۲۳، فصل خدمات امنیتی، ۲۰۲۳.

۳. سیلیکون لبز؛ «کاربرد امنیتی کدهای نصب در دستگاه های زیگبی»، مستندات توسعه دهندگان، نسخه ۹٫۱٫۲.

۴. کمیسیون بین المللی الکتروتکنیک؛ استاندارد IEC 62443-3-2:2020، «امنیت سامانه های اتوماسیون و کنترل صنعتی بخش ۳۲: ارزیابی ریسک امنیتی برای طراحی سامانه»، ۲۰۲۰.

۵. انجمن KNX؛ «مروری بر امنیت KNX»، مستندات پشتیبانی، ۲۰۲۶.