مقدمه:

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

[ez-toc]

۱. تهدیدهای امنیتی MQTT

در محیط‌های واقعی، چندین تهدید اصلی می‌تواند امنیت پروتکل MQTT را به خطر بیاندازد:

• دسترسی غیرمجاز به تجهیزات کلاینت یا سرور

• شنود و رهگیری پیام‌ها

• حملات تزریق پیام کنترلی یا جعل بسته

• حملات DoS (انکار سرویس)

• اسکن تاپیک‌ها توسط مهاجم

• سوءاستفاده از شناسه‌های کلاینت یا Credentialها

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

۲. امنیت در سطوح مختلف MQTT

۲.۱. سطح شبکه (Network Level)

• استفاده از شبکه خصوصی یا VPN

• پیاده‌سازی DMZ برای جداسازی سرور MQTT از شبکه داخلی

• استفاده از فایروال برای فیلتر ترافیک

۲.۲. سطح انتقال (Transport Layer)

• پیاده‌سازی TLS/SSL برای رمزنگاری ارتباط

• استفاده از پورت 8883 (استاندارد برای MQTT با TLS)

• اطمینان از اعتبار گواهی X.509 سرور

۲.۳. سطح کاربرد (Application Layer)

• احراز هویت با Username/Password یا Client ID

• استفاده از JWT یا گواهی دیجیتال

• رمزگذاری Payload به‌صورت جداگانه برای امنیت مضاعف

۳. احراز هویت در MQTT

 روش‌های رایج:

1. Username + Password: اطلاعات ارسال شده در پیام CONNECT

2. Client ID: شناسه یکتای دستگاه (مثل MAC یا UUID)

3. گواهی X.509: در ارتباطات TLS

4. احراز هویت ترکیبی: استفاده از چند شناسه هم‌زمان

مثال: احراز هویت در HiveMQ

HiveMQ با استفاده از پلاگین‌نویسی (مثلاً OnAuthenticationCallback) امکان اتصال به پایگاه‌ داده، LDAP یا وب‌سرویس را برای احراز هویت فراهم می‌سازد.

۴. صدور مجوز و کنترل دسترسی (Authorization)

مجوز (Authorization) یعنی تعیین اینکه هر کلاینت به چه تاپیک‌هایی می‌تواند Publish یا Subscribe کند.

 مجوزها معمولاً با استفاده از لیست‌های کنترل دسترسی (ACL) یا سیاست‌های مبتنی بر نقش (RBAC) پیاده‌سازی می‌شوند.

۵. TLS و امنیت رمزنگاری در MQTT

نکات کلیدی در استفاده از TLS:

• استفاده از پورت 8883

• اجتناب از Cipher Suiteهای ضعیف یا NULL

• اعتبارسنجی گواهینامه سرور (Name Matching)

• فعال‌سازی Session Resumption برای کاهش بار پردازشی در دستگاه‌های سبک

توصیه:

همیشه از TLS نسخه 1.2 یا 1.3 با الگوریتم‌های امن استفاده کنید و از رمزگذاری نقطه به نقطه در کنار احراز هویت بهره بگیرید.

۶. رفتارهای مشکوک و نظارت امنیتی

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

• تلاش‌های مکرر برای اتصال یا احراز هویت

• قطع ناگهانی و غیرعادی اتصال

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

• ارسال پیام به تاپیک‌هایی که هیچ مشترکی ندارند

• کلاینت‌های خاموش یا بدون فعالیت

۷. ایمن‌سازی MQTT از دید زیرساخت

۸. رمزنگاری سبک برای کلاینت‌های محدود

دستگاه‌هایی که پردازش محدودی دارند می‌توانند از موارد زیر بهره‌مند شوند:

• TLS Session Resumption

• رمزنگاری با الگوریتم‌های سبک مانند AES-128 یا ECC

• استفاده از ISO 29192 برای رمزنگاری سبک

۹. پروفایل‌های امنیتی پیشنهادی

 

برای امنیت MQTT اکیداً توصیه می‌شود که پیاده‌سازی‌های سروری که TLS را ارائه می‌کنند، باید از پورت 8883 در TCP   استفاده کند.  تعدادی تهدید وجود دارد که ارائه دهندگان راهكار باید در نظر بگیرند. مثلا:

•  تجهيزات ممکن است به خطر بی­افتند.
•  داده­های ذخيره شده در كلاينت­ها و سرورها ممکن است قابل دسترسی باشند.
•  رفتارهای پروتکل ممکن است عوارض جانبی داشته باشد (مانند «حملات زمان‌بندی»)
•  حملات انکار سرویس (DoS).
•  ارتباطات می­تواند رهگیری، تغییر، مسیریابی مجدد یا افشا شود.
•  تزریق بسته­های کنترلي جعلی
•  راه حل های امن­سازي MQTT اغلب در محیط­های ارتباطی متخاصم مستقر می­شوند. در پیاده­سازی­ها اغلب نیاز به ارائه مکانیسم­هایی برای موارد زیر دارند:
•  احراز هویت کاربران و تجهيزات
• مجوز دسترسی به منابع سرور
• یکپارچگی پكت­های کنترلی MQTT و داده­های کاربردی موجود در آن
• حریم خصوصی پكت­های کنترلی MQTT و داده­های برنامه موجود در آن
•  به عنوان یک پروتکل انتقال، MQTT تنها به انتقال پیام مربوط می­شود و بايد ویژگی­های امنیتی مناسب را ارائه دهد كه معمولاً با استفاده از  TLS به دست می­آید.
• رفتارهای غیرعادی كه نياز است سرور و كلاينت برای شناسایی حوادث امنیتی بالقوه به آنها نظارت کند. مانند:
•  تلاش های مکرر برای اتصال
•  تلاش های مکرر برای احراز هویت
•  قطع غیرعادی اتصالات
•  اسکن عنوان (تلاش برای ارسال یا اشتراک در بسیاری از موضوعات)
•  ارسال پیام­های غیر قابل تحویل (بدون اشتراک در موضوعات)
•  کلاینت­هایی که متصل می­شوند اما داده ارسال نمی­کنند

سرور بايد کلاینت­ هایی را که قوانین امنیتی آن را نقض می­کنند قطع کند. در پیاده‌سازی‌های، سروری که رفتار نامطلوب را تشخیص می‌دهد بايد یک لیست پویا را بر اساس شناسه‌هایی مانند آدرس IP یا شناسه مشتری پیاده‌سازی کند.

امنیت در MQTT به چندین لایه تقسیم شده و هر لایه از انواع مختلف حملات جلوگیری مي‎كند. از آنجا که MQTT یک پروتکل ارتباطی سبک و با کاربری آسان است. خود پروتکل صرفاً چند مکانیسم امنیتی را بیشتر مشخص نمي‎كند. پیاده سازی های MQTT معمولاً از دیگر استانداردهای امنیتی پیشرفته و به روز (مانند SSL/TLS برای امنیت انتقال) استفاده می‌کنند. از آنجایی که تامین امنیت دشوار است، منطقی است که بر اساس استانداردهای پذیرفته شده عمومی بنا شود.

سطح شبکه

یکی از راه‌های ارائه یک اتصال امن و قابل اعتماد، استفاده از یک شبکه امن فیزیکی یا VPN برای کلیه ارتباطات بین كلاينت­ ها و کارگزاران است. این راه حل برای مشتركين عمده و فوق عمده داراي RTU و بخش گیت­وی در ارتباطات مشتركين جزء مناسب است به اين صورت که گیت­وی از یک طرف به كنتور­ها و از طرف دیگر با کارگزار از طریق VPN در ارتباط است.

سطح انتقال

هنگامی که محرمانگی هدف اصلی است، TLS/SSL معمولا برای رمزگذاری انتقال استفاده مي‎شود. این روش یک راه مطمئن و اثبات شده برای اطمینان از عدم خواندن داده­ها در حین انتقال است و احراز هویت گواهی كلاينت را برای تأیید هویت هر دو طرف فراهم مي‎كند.

سطح کاربرد

در سطح انتقال، مخابره رمزگذاری شده و هویت ها احراز و تائید می­شوند. پروتکل MQTT یک شناسه کلاینت و نام کاربری/رمز عبور برای احراز هویت تجهيزات در سطح برنامه ارائه مي‎كند. این ویژگی توسط خود پروتکل ارائه شده است. مجوز یا کنترل کارهایی که هر دستگاه مجاز به انجام آن است با پیاده­سازی یک کارگزار خاص تعریف مي‎شود. علاوه بر این، امکان استفاده از رمزگذاری Payload در سطح برنامه برای ایمن سازی اطلاعات ارسالی (بدون نیاز به رمزگذاری انتقال تمام عیار) وجود دارد. در ادامه راه‌حل­های امنیتی رایج و مهم پیشبینی شده در پروتکل MQTT ارائه می­شوند.

احراز هویت با شناسه کاربری و کلمه عبور

احراز هویت بخشی از امنیت سطح انتقال و کاربرد در MQTT است. برای احراز هویت كلاينت به سرور با کمک امنیت لایه انتقال (TLS)، از اعتبارسنجی موفقیت آمیز یک گواهی كلاينت استفاده مي‎شود. در سطح کاربرد، پروتکل MQTT نام کاربری/ رمز عبور را برای احراز هویت ارائه مي‎كند. در ادامه رویکردهای مختلفی در پیاده­سازی کارگزار كه با احراز هویت همراه است توصیف مي­شود.

پروتکل MQTT فیلدهای نام­کاربری و رمزعبور را در پیام CONNECT برای احراز هویت ارائه مي‎كند. كلاينت این گزینه را دارد که هنگام اتصال به یک کارگزار MQTT، نام کاربری و رمز عبور را ارسال کند.

نام کاربری یک رشته رمزگذاری شده UTF-8 است. رمز عبور داده باینری با حداکثر 65535 بایت است. مطابق مشخصات MQTT مي‎توان نام کاربری را بدون رمز عبور ارسال نمود، اما ارسال رمز بدون نام کاربری امکان پذیر نیست.

هنگامی که از احراز هویت با نام کاربری/ رمزعبور داخلی MQTT استفاده می‌شود، کارگزار MQTT اعتبارنامه‌ها را بر اساس مکانیزم احراز هویت که پیاده‌سازی شده است ارزیابی مي‎كند و یکی از ReturnCode هاي تعریف شده را بر می‌گرداند.

هنگامی که نام­کاربری و رمزعبور برای كلاينت تعریف مي‎شود، اطلاعات به صورت متن ساده برای کارگزار ارسال مي‎شود. این متن در برابر شنود آسیب پذیر است و راه آسانی را برای مهاجمان برای به دست آوردن اعتبارنامه فراهم مي‎كند. انتقال ایمن نام­های کاربری و رمزهای عبور نیاز به رمزگذاری دارد.

در ادامه به مکانیسم های پیشرفته احراز هویت برای پیاده سازی احراز هویت در سمت کارگزار مي­پردازيم (به عنوان مثال، تأیید نام کاربری و رمز عبور ارائه شده با استفاده از ویژگی هایی مانند شناسه كلاينت برای احراز هویت).

چگونگی ایمن کردن MQTT

قبلا گفته شد که پروتکل MQTT یک نام کاربری و رمز عبور را در پیام CONNECT برای احراز هویت مهیا مي‎سازد. در اين بخش راهكارهاي بیشتری برای احراز هویت كلاينت معرفی می‌شود و نشان داده می‌شود که چگونه احراز هویت در سمت کارگزار MQTT پیاده‌سازی مي­شود. علاوه بر نام کاربری و رمز عبور، كلاينت­هاي MQTT اطلاعات دیگری مانند شناسه كلاينت را ارائه می­دهند که مي‎تواند برای احراز هویت استفاده شود.

هر كلاينت MQTT یک شناسه كلاينت منحصر به فرد دارد. كلاينت این شناسه منحصر به فرد را در پیام CONNECT به کارگزار ارائه مي‎دهد. شناسه كلاينت مي‎تواند حداکثر 65535 کاراکتر داشته باشد (مطابق مشخصات MQTT 3.1.1 محدودیت قبلی 23 کاراکتر حذف شده). استفاده از شناسه منحصر به فرد 36 کاراکتری (UUID) یا سایر اطلاعات كلاينت منحصر به فرد به عنوان شناسه كلاينت، مانند آدرس MAC ماژول شبکه یا شماره سریال دستگاه امری متداول است.

در فرآیند احراز هویت، شناسه­ های كلاينت اغلب در ترکیب با نام کاربری و رمز عبور استفاده مي‎شود. یک راه متداول برای تأیید اینکه آیا یک کلاینت مي‎تواند به کارگزار MQTT دسترسی داشته باشد، اعتبارسنجی نام کاربری/رمز عبور و شناسه كلاينت است که برای آن ترکیب اعتبارنامه صحیح است. همچنین مي‎توان نام کاربری/رمز عبور را نادیده گرفت و فقط با شناسه كلاينت احراز هویت کرد. با این حال، این روش یک روش امنیتی خوبي نیست. (برای برخی از سیستم­ها بسته به كاربرد، این نوع احراز هویت ممکن است کافی باشد).

گواهینامه X.509

یکی دیگر از روش­های احراز هویت ممکن، استفاده از گواهی كلاينت X.509 است. كلاينت این گواهی را در حین توافق TLS به کارگزار ارائه مي‎دهد (در ادامه به امنیت سطح انتقال و نحوه کار SSL/TLS با MQTT بیشتر پرداخته می‌شود). پس از یک توافق موفقیت آمیز TLS، برخی از کارگزاران مانند HiveMQ اجازه استفاده از اطلاعات گواهینامه را برای احراز هویت لایه برنامه می‌دهند. این کارگزار را قادر می‌سازد تا تمام اطلاعات گواهینامه را بخواند و از آن برای اهداف احراز هویت نیز استفاده کند. به ­هرحال گواهی‌های كلاينت X.509 می‌تواند منبع بسیار خوبی برای احراز هویت كلاينت­ها در کارگزار MQTT باشد.

مثالی از پیاده سازی احراز هویت با کارگزار برند Hiveq MQTT

انواع مختلفی از اطلاعات برای احراز هویت یک كلاينت MQTT وجود دارد. ارتباط کارگزار MQTT و ماژول احراز هویت می‌تواند یک پایگاه داده، یک وب سرویس، یک فهرست LDAP یا یک لیست کنترل دسترسی ساده (ACL) باشد.

در ادامه نحوه اجرای منطق احراز هویت در کارگزار HiveMQ MQTT (که به اختصار HiveMQ نامیده می‌شود) شرح داده مي‎شود. کارگزار HiveMQ دارای یک سیستم افزونه منبع باز است که امکان اتصال به رویدادهای مختلف به کارگزار را مهیا می‌سازد. HiveMQ رابط‌های پاسخگوی مختلفی را پیشنهاد مي‎دهد که پیاده‌سازی آنها در پلاگین‌های سفارشی بسیار آسان است. کارگزار اجرای پلاگین را در زمان اجرا فراخوانی مي‎كند. HiveMQ رابط OnAuthenticationCallback را برای احراز هویت فراهم مي‎كند.

صدور مجوز توسط MQTT

مجوز، حق دسترسی به یک منبع را مشخص مي‎كند. مجوز شامل تعریف و اجرای سیاست های کنترلی است که چه کسی مي‎تواند کاری را با یک منبع خاص داشته باشد یا انجام دهد. شرایط زیر بخش‌های ضروری مجوز هستند:

موضوع یا کاربری که می­خواهد به یک منبع دسترسی پیدا کند.

منبع، شی یا سرویسی که باید از دسترسی غیرمجاز محافظت شود.

خط­مشی که مشخص مي‎كند آیا یک عنوان یا کاربر به یک منبع دسترسی دارد یا خیر.

ارتباط احراز هویت و صدور مجوز

احراز هویت و صدور مجوز مفاهیم امنیتی مهمی هستند که در كنار هم امنيت را افزايش می­دهند. اگر از قبل هویت کاربر یا عنوان احراز هویت نشود، اجازه دادن به کاربر یا عنوان ارزش چندانی ندارد. مجوز برای محدود کردن ورود و اجازه دادن به افراد، كلايينت­ها یا افراد واجد شرایط برای دسترسی به منابع، داده ها یا موارد خاص است.

انکار  (Repudiation)

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

طراحان برنامه ممکن است نیاز به در نظر گرفتن استراتژی­های مناسب برای دستیابی به عدم انکار انتقال پيام داشته باشند.

انتشار

هنگامی که مشتری بدون مجوز صحیح عنواني را منتشر مي‎كند، کارگزار دو گزینه دارد:

کارگزار مي‎تواند ارتباط كلاينت را قطع کند زیرا براي انتشار در یک عنوان محدود مجاز نیست.

کارگزار مي‎تواند انتشار را به صورت عادی برای كلاينت تایید کند. در QoS1 یا QoS2 با پكت­های PUBACK یا PUBREL تصمیم بگیرید که پیام منتشر شده را برای كلاينت­ها ارسال نکند.

مشخصات فعلی MQTT 3.1.1 روشی مستقل از کارگزار برای اطلاع رسانی به كلاينت­ها در مورد انتشار غیرمجاز به غیر از قطع ارتباط كلاينت تعریف نمي‎كند. گزینه­ های اعلان ممکن است در نسخه­های آینده MQTT بهبود یابد.

اشتراک

هنگامی که كلاينت در یک عنوان مشترک مي‎شود، کارگزار باید هر اشتراک را با یک ReturnCode تأیید کند. ReturnCode ها شامل 4 کد مختلف هستند که عنوان­هايي را با QoS و کدهای خطا تایید مي‎كند. اگر كلاينت حق اشتراک موضوع خاصی را نداشته باشد، کارگزار مي‎تواند به كلاينت اعلام کند که اشتراک رد شده است.

TLS/SSL

قبل­تر احراز هویت و صدور مجوز بررسی گردید و در اینجا به رمزگذاری لایه انتقال با TLS پرداخته مي‎شود. امنیت لایه انتقال TLS و لایه سوکت های امن SSL، یک کانال ارتباطی امنی بین كلاينت و سرور را فراهم مي‎سازد. در هسته TLS و SSL پروتکل‌های رمزنگاری هستند که از مکانیزم توافق برای مذاکره با پارامترهای مختلف برای ایجاد یک ارتباط امن بین كلاينت و سرور استفاده می‌کنند. پس از تکمیل توافق، یک ارتباط رمزگذاری شده بین كلاينت و سرور برقرار مي‎شود و هیچ مهاجمی نمي‎تواند هیچ بخشی از ارتباط را شنود کند. سرورها یک گواهی X.509 (معمولاً توسط یک مرجع قابل اعتماد صادر مي‎شود) ارائه می­دهند که كلاينت ­ها از آن برای تأیید هویت سرور استفاده مي‎كنند.

برنامه­ها می­توانند به طور مستقل مقادیر هش را در پیام­های خود قرار دهند. این می­تواند یکپارچگی محتوای پكت­های کنترلی منتشر شده در سراسر شبکه و در حالت آماده ­باش  را فراهم کند.

TLS  الگوریتم ­های هش را برای تأیید صحت داده­های ارسال شده از طریق شبکه فراهم می­کند.TLS  می­تواند داده­های ارسال شده از طریق شبکه را رمزگذاری کند. مجموعه‌های رمزنگاری TLS معتبری وجود دارد که شامل یک الگوریتم رمزگذاری NULL است که داده‌ها را رمزگذاری نمی‌کند. برای اطمینان از حفظ حریم خصوصی، كلاينت­ها و سرورها باید از این مجموعه‌های رمزنگاری اجتناب کنند.

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

پیاده­سازی­های سرویس گیرنده و سرور با استفاده از TLS باید قابلیت­هایی را فراهم کنند تا اطمینان حاصل شود که هر گواهینامه SSL ارائه شده هنگام شروع اتصال TLS با نام میزبان كلاينت متصل یا سروری که به آن متصل است مرتبط است.

استقرار فیزیکی ممکن است سخت افزار ضد دستکاری را با انتقال داده های خاص در پيام­هاي برنامه ترکیب کند. به عنوان مثال، یک تصحيح كننده ممکن است یک GPS تعبیه شده داشته باشد تا اطمینان حاصل شود که در مکان های غیرمجاز استفاده نمی­شود. IEEE 802.1AR استانداردی برای پیاده‌سازی مکانیسم‌هایی برای احراز هویت یک دستگاه با استفاده از یک شناسه محدود رمزنگاری شده است.

اعتبارنامه‌های احراز هویت كلاينت یا سرور، مانند نام کاربری و رمز عبور، اگر گم شده‌اند یا در معرض خطر تلقی می‌شوند باید باطل شوند و یا دوباره صادر شوند.

 در مورد اتصالات طولانی مدت:

پیاده سازی های سرویس گیرنده و سرور با استفاده از TLS  باید امکان راه­اندازي مجدد نشست را برای ایجاد پارامترهای رمزنگاری جدید (جایگزینی کلیدهای جلسه، تغییر مجموعه­ های رمزنگاری، تغییر اعتبارنامه­های احراز هویت) فراهم کند.

سرورها ممکن است ارتباط کلاینت­ها را قطع کنند و از آنها بخواهند با اعتبارنامه ­های جدید احراز هویت مجدد را انجام دهند.

MQTT و TLS

MQTT پروتکل انتقال متکی  بر TCP است. به طور پیش فرض، اتصالات TCP از یک ارتباط رمزگذاری شده استفاده نمي‎كنند. برای رمزگذاری کل ارتباطات MQTT، بسیاری از کارگزاران MQTT (مانند HiveMQ) اجازه استفاده از TLS را به جای TCP ساده می­دهند. اگر از فیلدهای نام کاربری و رمز عبور پكت CONNECT پروتکل MQTT  برای مکانیسم‌های احراز هویت و مجوز استفاده می‌شود، باید قویاً استفاده از TLS در نظر گرفته ‌شود.

پورت 8883 برای اتصال ایمن MQTT استاندارد شده است. نام ” secure-mqtt” استاندارد شده در  IANA است. پورت 8883 منحصراً برای MQTT از طریق TLS رزرو شده است.

ایمن سازی سیستم­های MQTT

در اینجا بر روی استقرار ایمن یک سیستم MQTT تمرکز مي‎شود. لایه‌های مختلف امنیتی و نحوه تقویت استقرارشان برای جلوگیری و کاهش حملات بررسی خواهند شد. لایه­های امنیتی مختلفی وجود دارد که باید در مورد آنها بحث گردد :

• زیرساخت
• سیستم عامل
• کارگزار MQTT

زیرساخت

کارگزاران MQTT معمولاً بر روی نوعی از زیرساخت شبکه مستقر می­شوند. درک توپولوژی شبکه و هدف سیستم بسیار مهم است. همچنین مهم است که مهاجمان در اسرع وقت بلاك شوند تا از آسیب و خرابی سیستم­های پایین دستی جلوگیری شود.

فایروال

هر اتصال به یک کارگزار MQTT باید حداقل از یک فایروال عبور کند که قوانین پیچیده­ای را برای دسترسی به اجزای پایین دستی پیاده­سازی کند.

DMZ

DMZ اصطلاحاً منطقه ايمن شبکه می‌باشد. خدمات اینترنت مانند کارگزار MQTT اغلب در این منطقه وجود دارد. DMZ یک زیرشبکه است كه از دسترسی به سرویس­های پایین دستی مانند پایگاه­های داده و خدمات برنامه داخلی توسط یک فایروال اضافی محافظت مي‎كند. اگر مهاجم به یکی از سرویس‌های DMZ دسترسی پیدا کند، به طور خودکار به سیستم‌های دیگر پشت فایروال اضافی دسترسی پیدا نمي‎كند.

سیستم عامل

کارگزارهای MQTT بر روی سرورهایی (مجازی و فیزیکی) نصب می­شوند که سیستم عامل­های مختلفی را اجرا مي‎كنند. قبل از اینکه در مورد امنیت برنامه کارگزار MQTT صحبت کنیم، درک این نکته مهم است که بسیاری از حملات بر روی حفره‌های امنیتی در سیستم عامل یا نرم‌افزار و سرویس‌هایی که معمولاً با سیستم عامل نصب می‌شوند تمرکز دارند. نحوه امن سازي سيستم عامل­ ها مهم است كه در این بخش نمي­گنجد.

ایمن­سازی سیستم­های MQTT (شبیه به هر سیستم فناوری اطلاعات) مي‎تواند چالش برانگیز باشد و امنیت باید در سطوح مختلف در نظر گرفته شود.

رمزنگاری سبک براي تجهيزات با پردازش محدود

استاندارد رمزگذاری پیشرفته AES و استاندارد رمزگذاری داده DES به طور گسترده مورد استفاده قرار گرفته­اند.  ISO 29192 [11] توصیه­هایی را برای رمزنگاری­های ابتدایی که به طور خاص برای اجرا در تجهيزات “پایین­دست” تنظیم شده­اند، ارائه می­دهد.

تجهيزات با پردازش محدود و كلاينت­ها در شبکه‌های با پردازش محدود می‌توانند از سرگیری نشست TLS استفاده کنند تا پردازش‌های اتصال مجدد نشست­ها را کاهش دهند.

استفاده از SOCKS

پیاده‌سازی كلاينت­ها باید آگاهانه باشند که برخی به استفاده از پراکسی‌های SOCKSv5 برای ایجاد اتصالات شبکه نیاز دارند. برخی از پیاده­سازی­های MQTT می­توانند از تونل­های ایمن جایگزین (مانند SSH) از طریق استفاده از SOCKS باشد. در جایی که پیاده‌سازی‌ها با SOCKS را انتخاب می‌کنند، باید از پروکسی‌های SOCKS احراز هویت رمزعبور و نام­کاربری پشتیبانی کنند.

پروفایل­های امنیتی

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

مشخصات ارتباطی را پاک کنید

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

پروفایل ارتباط شبکه ایمن

هنگام استفاده از مشخصات ارتباط شبکه ایمن، پروتکل MQTT روی یک شبکه فیزیکی یا مجازی اجرا می‌شود که دارای کنترل‌های امنیتی (مانند VPN) است.

مشخصات انتقال ایمن

هنگام استفاده از مشخصات انتقال ایمن، پروتکل MQTT روی یک شبکه فیزیکی یا مجازی و با استفاده از TLS  اجرا می­شود که احراز هویت، یکپارچگی و حریم خصوصی را فراهم می­کند.

جمع‌بندی

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

سوالات متداول 

 آیا MQTT به‌خودی‌خود امن است؟

خیر، MQTT ذاتاً سبک است و ویژگی‌های امنیتی پایه‌ای دارد. باید با استفاده از TLS، احراز هویت و زیرساخت امن، تقویت شود.

چه پورت‌هایی برای MQTT امن استفاده می‌شود؟

پورت استاندارد 8883 برای اتصال رمزنگاری‌شده MQTT با TLS استفاده می‌شود.

بهترین روش احراز هویت در MQTT چیست؟

ترکیب Client ID منحصر به‌فرد با Username/Password و در صورت نیاز گواهی X.509 بهترین روش است.

آیا امکان رمزنگاری پیام‌ها به‌صورت مستقل از TLS وجود دارد؟

بله، می‌توان Payload را به‌صورت مجزا رمزنگاری کرد (مثلاً با AES یا RSA)، حتی بدون TLS.

چگونه از حملات DoS در MQTT جلوگیری کنیم؟

با محدود کردن نرخ درخواست‌ها (Rate Limiting)، لیست سیاه/سفید و تشخیص رفتارهای مشکوک توسط کارگزار.