امنیت اینترنت اشیا یک رشته‌ی چندوجهی است: تحلیل فرمور، امنیت سختافزار، پروتکل‌های رادیویی و امنیت اپلیکیشن موبایل، هر کدام تخصص جداگانه‌ای‌اند. اما وقتی سطح حمله‌ی یک محصول IoT واقعی را فهرست می‌کنید، یک نکته‌ی تکراری بیرون می‌آید: تقریباً هر استقرار IoT یک کنسول مدیریت تحت وب و یک API ابری دارد، و همان دو، متعارف‌ترین و اغلب ضعیف‌ترین بخش کل سامانه‌اند — و دقیقاً همان‌جایی که با روش‌های شناخته‌شده‌ی آزمون برنامهی وب قابل بررسی‌اند.
در یک نگاه
- سطح حمله‌ی IoT چندلایه است: سختافزار، فرمور، رادیو، اپلیکیشن موبایل، API ابری و کنسول وب.
- دو لایهی آخر، برنامهی وب متعارفاند و همان دسته‌های OWASP Top 10:2025 روی آن‌ها صدق می‌کند.
- OWASP در
A08:2025مستقیماً به بهروزرسانی امضانشده‌ی فرمور روترهای خانگی به‌عنوان نمونه اشاره می‌کند. - CVSS v4.0 با سنجه‌ی ایمنی، ارزیابی ریسک را رسماً به دستگاه‌های متصل هم گسترش داد.
سطح حمله‌ی یک محصول IoT
| لایه | نمونه‌ی ضعف | تخصص لازم |
|---|---|---|
| سختافزار | پورت اشکال‌زدایی باز، حافظه‌ی قابل خواندن | تخصص سختافزار |
| فرمور | اعتبارنامه‌ی سخت‌کدشده، کلید مشترک بین همه‌ی دستگاه‌ها | مهندسی معکوس |
| پروتکل رادیویی | نبود رمزنگاری یا جفت‌شدن ناامن | تخصص رادیو |
| اپلیکیشن موبایل | ذخیره‌ی توکن به‌شکل ناامن، نبود سنجش گواهی | آزمون موبایل |
| API ابری | نبود بررسی مجوز روی شناسه‌ی دستگاه | آزمون برنامهی وب |
| کنسول مدیریت وب | اعتبارنامه‌ی پیش‌فرض، نقص مجوزدهی، تزریق | آزمون برنامهی وب |
چهار ردیف نخست تخصصهای مستقلاند و ادعای پوشش‌دادن‌شان توسط یک تیم امنیت برنامه نادرست است. اما دو ردیف آخر — که در بیشتر محصولات، دروازه‌ی واقعی کنترل دستگاه‌اند — همان کاری است که در هر آزمون برنامهی وب انجام می‌شود.
چرا کنسول وب و API ابری، حلقه‌ی ضعیف‌اند
سه دلیل ساختاری:
- عجله‌ی محصول. در بسیاری از محصولات، تمرکز تیم روی سختافزار و فرمور است و پنل مدیریت با کمترین زمان ساخته می‌شود.
- مدل مالکیت چندگانه. یک API ابری معمولاً به دستگاه‌های چند مشتری متفاوت خدمت می‌دهد. اگر بررسی مالکیت روی شناسه‌ی دستگاه انجام نشود، یک کاربر می‌تواند دستگاه دیگری را کنترل کند — همان الگوی IDOR، اما با پیامد فیزیکی.
- عمر طولانی و بهروزرسانی نادر. دستگاهی که پنج سال در محل نصب می‌ماند، نسخه‌ی برنامهی وبی را نگه می‌دارد که سال‌ها وصله نشده است.
یافته‌های متعارف در این لایه همان‌هایی است که در هر برنامهی وب دیگری دیده می‌شود: اعتبارنامه‌ی پیش‌فرض تغییرنیافته (A02:2025)، نبود بررسی مجوز روی نقاط انتهایی (A01:2025)، احراز هویت ضعیف و نبود محدودیت نرخ (A07:2025)، و تزریق فرمان در نقاطی که ورودی کاربر به فرمان سیستمی می‌رسد (A05:2025) — الگوی رایج در پنل‌های تشخیصی که مثلاً امکان اجرای ping به یک میزبان را می‌دهند. شرح این دسته در تزریق فرمان آمده است.
یکپارچگی بهروزرسانی
دسته‌ی A08:2025 با عنوان نقص یکپارچگی نرم‌افزار یا داده، صریحاً به این حوزه اشاره می‌کند و یکی از نمونه‌های رسمی‌اش روترهای خانگی و فرم‌ورهایی با بهروزرسانی امضانشده است: اگر دستگاه امضای بستهی بهروزرسانی را راستیآزمایی نکند، مهاجمی که بتواند مسیر بهروزرسانی را دستکاری کند، فرمور دلخواه خود را نصب می‌کند.
کنترل‌های مؤثر بر پایه‌ی توصیه‌های همان دسته و دسته‌ی A03:2025:
- راستیآزمایی امضای دیجیتال هر بستهی بهروزرسانی روی خود دستگاه؛
- دریافت بهروزرسانی فقط از کانال معتبر و روی اتصال احراز هویتشده؛
- موجودی مؤلفه‌ها و SBOM برای فرمور — بیشتر فرم‌ورها بر پایه‌ی کتابخانههای متن‌باز ساخته میشوند و همان CVEها را به ارث می‌برند؛
- انتشار مرحلهای بهجای استقرار همزمان روی کل ناوگان.
«دستگاه ما پشت NAT است و از اینترنت در دسترس نیست، پس امن است.» در معماری متعارف IoT، خود دستگاه اتصال خروجی به ابر برقرار می‌کند و کنترل از همان مسیر ابری انجام می‌شود. یعنی دروازه‌ی واقعی کنترل دستگاه، API ابری است نه آدرس IP دستگاه — و آن API از کل اینترنت در دسترس است. مهاجم لازم نیست به دستگاه شما برسد؛ کافی است در سرویس ابری، بررسی مالکیت روی شناسه‌ی دستگاه انجام نشده باشد.
ارزیابی ریسک: چرا پیامد فیزیکی مهم است
در IoT، پیامد یک آسیب‌پذیری می‌تواند از حوزه‌ی داده خارج شود. CVSS v4.0 که در ۱ نوامبر ۲۰۲۳ منتشر شد، دقیقاً برای همین گروه سنجه‌های تکمیلی را اضافه کرد؛ این گروه بر امتیاز عددی اثر نمی‌گذارد اما زمینه‌ی تصمیم را روشن می‌کند:
- Safety (S) — احتمال آسیب فیزیکی به انسان، بر پایه‌ی دسته‌بندی‌های IEC 61508؛
- Automatable (AU) — آیا حمله در مقیاس قابل خودکارسازی است؛ برای ناوگان‌های بزرگ دستگاه، تعیین‌کننده است؛
- Recovery (R) — دستگاهی که در محل نصب فیزیکی دارد، بازیابی‌اش گران‌تر از یک سرور است.
تغییر ساختاری دیگر v4.0 هم اینجا کاربرد دارد: جداسازی صریح اثر روی سامانه‌ی آسیب‌پذیر از اثر روی سامانه‌های بعدی. در IoT این تفکیک طبیعی است — دستگاه آسیب‌پذیر ممکن است خودش کم‌ارزش باشد، اما پلی به شبکه‌ی داخلی مشتری بسازد. توضیح کامل در CVSS.
اگر محصول IoT می‌سازید، از کجا شروع کنید
- API ابری و کنسول وب را مثل یک برنامهی وب حیاتی آزمون کنید — با تمرکز بر بررسی مالکیت روی شناسه‌ی دستگاه، محدودیت نرخ و مدیریت نشست. این کم‌هزینه‌ترین و پربازده‌ترین گام است: تست نفوذ وب.
- اعتبارنامه‌ی پیش‌فرض و مشترک را حذف کنید. توصیه‌ی صریح
A07:2025این است که هیچ محصولی نباید با اعتبارنامه‌ی پیش‌فرض عرضه شود؛ کلید مشترک بین همه‌ی دستگاه‌ها هم به همین اندازه خطرناک است. - زنجیره‌ی بهروزرسانی را امضا کنید و راستیآزمایی امضا را روی خود دستگاه پیاده کنید.
- SBOM فرمور بسازید و CVEهای کتابخانههای استفادهشده را رصد کنید.
- اپلیکیشن موبایل را جداگانه بسنجید — تست نفوذ موبایل.
- ثبت رخداد سمت ابر برای عملیات حساس دستگاه، مطابق
A09:2025.
گام نخست را دست‌کم نگیرید. در بیشتر ارزیابی‌های محصولات متصل، پرخطرترین یافته نه در فرمور بلکه در همان API ابری بوده که بررسی مالکیت را انجام نمی‌داده — یافته‌ای که با ابزار متعارف وب و در چند ساعت پیدا می‌شود. چارچوب پیگیری هم در مدیریت آسیب‌پذیری آمده است.
پرسش‌های متداول
امنیت اینترنت اشیا شامل چه چیزهایی است؟
شش لایه: سختافزار، فرمور، پروتکل رادیویی، اپلیکیشن موبایل، API ابری و کنسول مدیریت وب. چهار لایهی نخست تخصصهای مستقلاند؛ دو لایهی آخر برنامهی وب متعارفاند و با همان روشها آزمون میشوند.
ضعیف‌ترین بخش یک سامانه‌ی IoT کجاست؟
در بیشتر موارد، API ابری و کنسول مدیریت وب. دلیلش ساختاری است: تمرکز تیم محصول روی سختافزار و فرمور است، پنل مدیریت با کمترین زمان ساخته می‌شود، و همان پنل دروازه‌ی واقعی کنترل دستگاه است.
دستگاه ما پشت NAT است، باز هم ریسک دارد؟
بله. در معماری متعارف IoT، دستگاه خودش اتصال خروجی به ابر برقرار می‌کند و کنترل از همان مسیر انجام می‌شود. یعنی دروازه‌ی واقعی، API ابری است که از کل اینترنت در دسترس است؛ اگر بررسی مالکیت روی شناسه‌ی دستگاه انجام نشود، مهاجم لازم نیست به شبکه‌ی شما برسد.
بهروزرسانی فرمور را چطور امن کنیم؟
امضای دیجیتال بستهی بهروزرسانی و راستیآزمایی آن روی خود دستگاه، دریافت فقط از کانال معتبر و احراز هویتشده، ساخت SBOM برای فرمور و رصد CVE کتابخانههای استفادهشده، و انتشار مرحلهای بهجای استقرار همزمان روی کل ناوگان.
برای محصول IoT خود از کجا شروع کنیم؟
از آزمون API ابری و کنسول وب، با تمرکز بر بررسی مالکیت روی شناسه‌ی دستگاه، محدودیت نرخ و مدیریت نشست. این کم‌هزینه‌ترین گام است و در عمل پرخطرترین یافته‌ها معمولاً همان‌جا پیدا میشوند، نه در فرمور.
منابع
امیر پیامنی
شکارچی ضعف‌های زیرساخت؛ از نقشه‌برداری سطح حمله تا بهره‌برداری از سرویس‌های شبکه و حرکت جانبی داخل دامنه.