امنیت IoT و وب؛ هویت دستگاه، API، داده و Incident

اپراتور در پنل وب روی «خاموش‌کردن پمپ» کلیک می‌کند. UI پیام موفقیت نشان می‌دهد، اما فرمان قدیمی از Queue دوباره پخش شده، Device identity میان چند دستگاه مشترک است و سنسور رطوبت با ساعت اشتباه داده می‌فرستد. حادثه از یک «وب‌سایت هک‌شده» یا یک «دستگاه ضعیف» به‌تنهایی نیامده؛ قرارداد اعتماد میان Device، Broker، API و Control panel شکسته است.

امنیت IoT متصل به وب یعنی محافظت هم‌زمان از دارایی فیزیکی، داده، سرویس ابری، API، Dashboard و عملیات کل Fleet. WAF، HTTPS یا MFA هرکدام لازمِ بخشی از مسیرند، اما هیچ‌کدام به‌تنهایی هویت دستگاه، Replay فرمان، Firmware آسیب‌پذیر، دادهٔ جعلی یا پایان عمر محصول را حل نمی‌کنند.

IoT متصل به وب را به یک Website تقلیل ندهید

یک محصول IoT معمولاً چند سطح دارد:

Device sensors/actuators
  ↕ local interface / gateway / network
Message broker or ingestion API
  → stream/process/store/digital twin
  → application API / BFF
  → web dashboard / mobile app / operator

Management plane:
identity + provisioning + configuration + OTA + fleet status

External dependencies:
cloud/CDN/DNS/SMS/email/analytics/support/vendor supply chain

Data plane، Command plane و Management plane را جدا رسم کنید. Dashboard بهتر است از API/Policy layer فرمان بخواهد؛ قرارگرفتن Credential دستگاه در Browser یا اتصال مستقیم عمومی Browser→Device مرز اعتماد را مخدوش می‌کند.

Threat model را از پیامد شروع کنید

خانه هوشمند، پوشیدنی سلامت و کنترل صنعتی Profile یکسان ندارند. NIST نیز Baseline عمومی را نقطهٔ شروع می‌داند و Tailoring را براساس Customer، Application و Risk لازم می‌شمارد.

Baseline رسمی NIST را به Requirement تبدیل کنید

NISTIR 8259A شش Capability فنی پایه را معرفی می‌کند:

1. Device identification: شناسایی یکتا و منطقی/فیزیکی Device؛
2. Device configuration: تغییر Configuration فقط توسط Entity مجاز؛
3. Data protection: حفاظت از دادهٔ ذخیره و انتقال؛
4. Logical access to interfaces: محدودکردن Interface و Protocol؛
5. Software update: Update امن و قابل‌کنترل؛
6. Cybersecurity state awareness: مشاهده/گزارش وضعیت امنیتی Device.

این‌ها نام محصول یا کنترل آماده نیستند. برای هر مورد بنویسید «چه Entity، چه عملیات، چه شواهد و چه Failure». NISTIR 8259B نیز Documentation، دریافت گزارش/پرسش امنیتی، انتشار اطلاعات و آموزش را در Support lifecycle برجسته می‌کند؛ Device بدون سازوکار گزارش آسیب‌پذیری و EOL شفاف، محصول امنِ عملیاتی نیست.

Inventory باید Fleet، Firmware و Owner را به هم وصل کند

CMDB یا Fleet registry حداقل این فیلدها را لازم دارد:

Serial number لزوماً Secret یا Authentication credential نیست. Inventory باید Device clone، انتقال مالکیت، Factory reset، تعمیر، گم‌شدن و Decommission را هم پوشش دهد.

هویت دستگاه را از روز تولید تا خروج مدیریت کنید

یک Password مشترک کارخانه‌ای برای همه Deviceها، هر رخنه را به رخنهٔ Fleet تبدیل می‌کند. CISA در Secure by Design بر حذف Passwordهای پیش‌فرض مشترک تأکید دارد؛ ETSI EN ۳۰۳ ۶۴۵ نیز Universal default password را نمی‌پذیرد.

manufacturing identity / bootstrap trust
→ first-use enrollment and ownership binding
→ unique operational credential
→ periodic or event-based rotation
→ recovery / transfer / repair
→ compromise revocation and quarantine
→ decommission / wipe / tombstone

Credential را متناسب با Capability Device انتخاب کنید: Certificate/mTLS، کلید متقارن یکتا، secure element یا سازوکار دیگر. Secret در Source code، Firmware مشترک، Log، URL یا Browser قرار نگیرد. امکان Rotation بدون مراجعهٔ فیزیکی، Expiry، Revocation و Recovery را پیش از Scale آزمایش کنید.

OAuth ۲.۰ راه‌حل عمومی هویت Device نیست

OAuth یک Framework برای Delegated authorization است و در بعضی Client/Device flowها کاربرد دارد؛ اما به‌خودی‌خود Root of trust سخت‌افزار، Provisioning، اثبات مالکیت یا Firmware integrity را ایجاد نمی‌کند.

یک Token کاربر را به Device secret تبدیل نکنید و یک Certificate Device را مجوز همهٔ Endpointها ندانید.

Authentication را با Authorization شیء/عمل اشتباه نگیرید

پس از اثبات هویت باید تصمیم بگیرید «این Entity روی کدام Resource چه Actionی در چه Contextی می‌تواند انجام دهد». خطر Broken Object Level Authorization برای APIهای IoT جدی است: تغییر device_id نباید Telemetry یا فرمان Tenant دیگر را آشکار کند.

subject: operator-72
tenant: tenant-A
resource: pump-18
action: stop
context: maintenance-window + site-role + risk-level
decision: allow / deny / step-up / dual-approval
evidence: policy-version + reason + correlation-id

Policy را در Server-side enforcement point اعمال کنید؛ UI مخفی‌شده یا Disabled button کنترل امنیتی نیست. برای طراحی Object/function authorization و تست منفی، چک‌لیست امن‌سازی Endpoint API را به این مدل وصل کنید.

TLS لازم است، اما End-to-end truth نیست

TLS شنود و دست‌کاری مسیر هر Connection را کاهش می‌دهد و Peer authentication را بسته به Configuration فراهم می‌کند؛ اما اگر داده در Gateway/Broker terminate و دوباره ارسال شود، «رمزگذاری سرتاسری» خودکار ندارید. TLS همچنین Device آلوده، Credential دزدیده‌شده، Replay پیام معتبر یا دادهٔ سنسور جعلی را تشخیص نمی‌دهد.

• Certificate/hostname validation را غیرفعال نکنید.
• Protocol/cipher/version را با عمر Device و توان Update طراحی کنید.
• Trust store و CA rotation را پیش از انقضا آزمایش کنید.
• برای پیام حساس، Source identity، integrity و freshness در لایه پیام را بررسی کنید.
• Key material را در Log، Crash dump و Support bundle حذف/ماسک کنید.

Telemetry را دادهٔ غیرقابل‌اعتماد فرض کنید

Validation فقط جلوگیری از SQL Injection نیست. هر پیام Telemetry باید Contract داشته باشد:

device_id + tenant + schema_version
metric + unit + value + valid range
observed_at + received_at + sequence
firmware + sensor status + quality/confidence
provenance/integrity evidence
correlation + retention class

Timestamp آینده/قدیمی، Sequence تکراری، Unit اشتباه، جهش خارج محدوده و Firmware ناشناخته را جدا کنید. Idempotency و Dedup مانع دوباره‌شماری شوند. تصمیم پرخطر را با یک Sensor و یک Sample قطعی نکنید؛ Corroboration، threshold، hysteresis و human override متناسب با Safety لازم‌اند.

فرمان Device یک Transaction فیزیکی است

Control command با نمایش Dashboard فرق دارد. فرمان باید State machine داشته باشد:

requested → authorized → queued → delivered
→ acknowledged → applied / rejected / expired / unknown
→ reconciled with observed state

Required fields:
command_id, device_id, desired_state, issued_at, expires_at,
nonce/sequence, policy_version, actor, reason, idempotency_key

Success UI را پس از «Queued» با Success فیزیکی یکی نگیرید. برای Actuator حساس، Expiry کوتاه، Anti-replay، Step-up یا Dual approval، interlock محلی و Safe default لازم است. پس از Disconnect، Device باید رفتار Fail-safe/Fail-secure تعریف‌شده داشته باشد؛ انتخاب آن به Hazard analysis وابسته است.

Broker و Topic نیز Authorization boundary هستند

MQTT، CoAP، HTTP یا Protocol دیگر به‌تنهایی امن/ناامن نیست؛ Deployment و Policy تعیین‌کننده‌اند. در Broker:

• Credential و ACL یکتا بر Device/Tenant/Topic؛
• Publish و Subscribe جدا و حداقل دسترسی؛
• Wildcard/retained message/last-will/QoS براساس Use case؛
• Payload/schema/size/rate و connection quota؛
• Backpressure، retry، dead-letter و poison-message quarantine؛
• Audit برای تغییر ACL/credential/topic؛
• Isolation و noisy-neighbor test.

الگوهای Outbox، Idempotency، Backpressure و Reconciliation در راهنمای Event-Driven Architecture توضیح داده شده‌اند؛ آن‌ها را با محدودیت Device و Safety Tailor کنید.

Network segmentation سطح حمله را محدود می‌کند

Device تک‌منظوره معمولاً به کل شبکه نیاز ندارد. VLAN/segment، egress allowlist، DNS policy و gateway می‌توانند دامنهٔ ارتباط را به Controller/Update/Time service لازم محدود کنند. RFC ۸۵۲۰ برای Manufacturer Usage Description معماری‌ای ارائه می‌دهد تا الگوی ارتباط موردنیاز Device به Network اعلام شود.

MUD جای Patch یا Policy محلی نیست و خود RFC آن را Directive اجباری نمی‌داند. Policy تولیدکننده را Verify و با Context سازمان تطبیق دهید. برای Resource-based enforcement و عدم اعتماد ضمنی به Location، راهنمای Zero Trust مکمل است.

Firmware و OTA بزرگ‌ترین Blast radius را دارند

Update mechanism خود یک مسیر اجرای کد روی کل Fleet است. Contract امن:

• Artifact امضاشده و Verification پیش از نصب؛
• Secure/verified boot متناسب با Hardware؛
• Version/compatibility/anti-rollback policy؛
• Atomic یا recoverable install در قطع برق/شبکه؛
• Canary cohort و staged rollout با telemetry؛
• Stop/rollback/recovery image و field-service path؛
• Signing key protection/rotation/revocation؛
• SBOM، vulnerability triage، patch SLA و EOL notice.

Rollback همیشه امن نیست: بازگشت به Version دارای Vulnerability یا Schema ناسازگار می‌تواند خطر را بیشتر کند. Rollback target باید Approved و Data compatibility آن آزموده شود.

Secure by Default را به Procurement ببرید

Logo یا «Military-grade encryption» شاهد نیست. Requirement، Version، Scope، Test و Owner بخواهید.

API IoT را با OWASP و Abuse case تست کنید

OWASP API Security Top ۱۰ ۲۰۲۳ خطرهایی مانند Broken Object Level Authorization، Broken Authentication، Unrestricted Resource Consumption، SSRF، Improper Inventory Management و Unsafe Consumption of APIs را برجسته می‌کند. برای IoT این Abuse caseها را اضافه کنید:

• Enumerate کردن Device ID و Tenant crossing؛
• Replay فرمان قدیمی یا جابه‌جایی Target؛
• Bulk endpoint برای تخلیه Fleet data؛
• Webhook/URL قابل‌کنترل Device و SSRF؛
• Firmware/update metadata دست‌کاری‌شده؛
• Flood با Credential معتبر؛
• Shadow/deprecated endpoint و Version drift؛
• Third-party telemetry/command API آلوده.

Rate limit را فقط بر IP نگذارید؛ هزاران Device پشت NAT یا یک Device با چند Credential می‌تواند False positive/negative بسازد. Device، Tenant، Identity، Endpoint، Cost و Business action را در Quota ببینید.

پنل وب یک Control plane پرخطر است

Dashboard باید علاوه بر API security این کنترل‌ها را داشته باشد:

• MFA/step-up برای عمل حساس و Session management؛
• CSRF protection و Output encoding/CSP برای XSS؛
• Tenant/object/function authorization در Server؛
• WebSocket/SSE authentication، reauthorization و expiry؛
• عدم نمایش Secret/Token/Full PII در HTML/Log/Analytics؛
• Audit actor/action/target/reason/result بدون دادهٔ حساس زائد؛
• واضح‌بودن Desired/Reported/Unknown/Offline state؛
• Confirmation متناسب، Undo/compensation و emergency path.

پنل نباید «آخرین دادهٔ کش‌شده» را Current نشان دهد. Age، source، quality و connectivity state را کنار عدد نمایش دهید.

DDoS فقط با WAF حل نمی‌شود

IoT دو نقش در Availability risk دارد: Deviceهای آلوده می‌توانند بخشی از Botnet علیه وب باشند، یا Fleet/credential معتبر می‌تواند API/Broker خودتان را Flood کند. WAF عمدتاً HTTP را می‌بیند و Capacity upstream، DNS، Broker، TCP/UDP protocol یا Logic abuse را کامل پوشش نمی‌دهد.

معماری لایه‌ای و Runbook در راهنمای دفاع DDoS تکمیل شده است؛ مدیریت Traffic خودکار و False positive در راهنمای ربات مخرب آمده است.

حریم خصوصی را از Sensor تا مشتق‌ها Map کنید

دادهٔ IoT فقط Payload خام نیست. زمان حضور، الگوی خواب، موقعیت، صدای محیط، تصویر، مصرف انرژی و حتی Metadata ارتباط می‌توانند دربارهٔ انسان استنباط بسازند.

sensor field → purpose → legal basis/consent where applicable
→ device/gateway/broker/store/analytics/support recipients
→ retention → access/export/correction/deletion
→ derived inference → sharing → incident impact

Data minimization را در Sampling، Resolution، on-device processing، upload trigger و retention اعمال کنید. «برای بهبود محصول» Purpose دقیق نیست. Debug log و Support bundle نیز ممکن است موقعیت/Token/PII داشته باشند. برای Budget و Evidence برنامه، راهنمای حریم خصوصی داده را ببینید.

Observability باید Fleet-aware و Privacy-aware باشد

Log کردن «همه‌چیز» راه‌حل نیست. Schema، sampling، redaction، access، retention، integrity و clock synchronization را تعریف کنید. Device clock قابل‌اعتماد فرض نشود؛ observed_at و received_at جدا بمانند.

Incident response باید Device را ایمن نگه دارد

NIST CSF ۲.۰ چرخه را با Govern، Identify، Protect، Detect، Respond و Recover می‌بیند. Runbook IoT:

1. Scope: model/firmware/credential/tenant/region/command/data؛
2. Safety owner و مجوز Isolation؛
3. Quarantine network/policy بدون ساخت Hazard جدید؛
4. Credential revoke/rotate و command freeze؛
5. Preserve evidence با clock/source limits؛
6. Patch/config/rollback یا field action؛
7. Telemetry و business data reconciliation؛
8. Customer/operator communication و safe workaround؛
9. Recovery gate و cohort monitoring؛
10. Root cause، regression و supplier action.

«خاموش‌کردن همه Deviceها» ممکن است در Safety-critical system خطرناک‌تر باشد. Containment باید با Engineering/Operations/HSE و Playbook تمرین‌شده تصمیم‌گیری شود.

تست امنیت IoT فقط Pentest وب نیست

OWASP IoT Security Testing Guide دامنه را میان Device، Firmware، Data exchange، Interface و Ecosystem گسترش می‌دهد. Test plan:

Rules of Engagement باید Device damage، Radio/legal boundary، Production data، physical safety و emergency stop را مشخص کند. روش Authorization/RoE/Evidence/Retest در راهنمای تست نفوذ وب‌اپلیکیشن باید برای Hardware و Safety بسط داده شود.

سناریوی ایران: قطع شبکه، Clock drift و Cloud خارجی

برای سامانهٔ سنجش گلخانه یا کنترل تجهیزات در ایران، Availability خارجی و کیفیت شبکه را واقع‌بینانه مدل کنید:

• چند ISP/اپراتور، DNS، IPv4/IPv6 و Gateway مختلف؛
• قطع/نوسان Cloud، Broker، CDN، SMS/Email/API خارجی؛
• Store-and-forward با Sequence/Expiry/Integrity؛
• Clock drift و نبود Time service؛
• Local safe mode و محدودیت فرمان Offline؛
• OTA mirror با Signature verification، نه خاموش‌کردن TLS؛
• Firmware/console فارسی، Bidi و خطای قابل‌فهم؛
• Support، قطعه، Patch و EOL در چرخهٔ واقعی تأمین.

برای عبور از اختلال، Certificate validation را حذف، Port عمومی باز یا Credential مشترک نسازید. Availability و Security باید با Store-and-forward، local control، redundancy و recovery طراحی شوند. Shared responsibility و Incident/restore ایران در راهنمای هاست ابری امن تکمیل شده است.

برنامهٔ ۹۰ روزهٔ کاهش ریسک

سؤال‌های متداول

آیا HTTPS برای امنیت IoT کافی است؟

خیر. TLS برای حفاظت Connection ضروری است، اما Provisioning و هویت یکتا، Authorization، Secret storage، Replay protection، Telemetry validation، Update امن، Browser/API security و Incident response را جایگزین نمی‌کند.

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

روش واحدی برای همه Deviceها وجود ندارد. Certificate/mTLS، کلید متقارن یکتا یا Hardware-backed identity بسته به توان Device، Risk و Operations انتخاب می‌شوند. معیار اصلی Lifecycle کامل Bootstrap، Enrollment، Rotation، Revocation، Recovery و Decommission است.

چگونه جلوی فرمان جعلی یا تکراری را بگیریم؟

Policy Server-side برای Actor/Tenant/Device/Action، Command ID یکتا، Expiry، Nonce/Sequence، Integrity، Idempotency، State reconciliation و در عمل حساس Step-up/Dual approval و interlock محلی لازم‌اند. ACK شبکه به معنی اجراشدن فیزیکی نیست.

WAF از حملات IoT و DDoS جلوگیری می‌کند؟

WAF فقط یک لایه و عمدتاً برای HTTP است. DNS/Network scrubbing، CDN/origin isolation، API/Broker quota، per-device/tenant limits، backpressure، bounded work، degraded mode و Runbook لازم‌اند.

در زمان قطع اینترنت Device چه کاری باید انجام دهد؟

رفتار باید از Hazard analysis بیاید: حالت امن محلی، فرمان‌های مجاز Offline، Queue محدود با Expiry/Sequence، Store-and-forward معتبر و Reconciliation پس از اتصال. خاموش‌کردن TLS یا پذیرش فرمان قدیمی راه‌حل Availability نیست.

جمع‌بندی

امنیت IoT و وب یک زنجیرهٔ کنترل است، نه خرید WAF یا افزودن HTTPS. معماری و Trust boundary را رسم کنید، Baseline NIST را به Requirement قابل‌آزمون تبدیل کنید، Fleet و Credential lifecycle را مدیریت و Human/Device/Workload identity را جدا کنید. Telemetry را غیرقابل‌اعتماد، Command را Transaction فیزیکی و OTA را مسیر با Blast radius بالا بدانید. سپس Broker/API/Web، DDoS، Privacy، Observability، Vendor/EOL و Incident را با تست چندسطحی و سناریوی شبکه ایران عملیاتی کنید.

منابع رسمی منتخب

• NIST — NISTIR 8259 Series
• NIST — IoT Device Cybersecurity Capability Core Baseline
• NIST — Cybersecurity Framework 2.0
• ETSI — EN 303 645 Consumer IoT security baseline
• OWASP — API Security Top 10 2023
• OWASP — IoT Security Testing Guide
• OWASP — IoT Security Verification Standard
• CISA — Secure by Design: eliminating default passwords
• IETF RFC 8520 — Manufacturer Usage Description