Skip to content

MS_AzureIoT

Jump to bottom
nishi_74322014 edited this page Sep 1, 2026 · 1 revision

Microsoft Azure IoT

概要

Microsoft の IoT サービス群。

サービス

IoTソリューション向けプラットフォーム

サービス 位置づけ
Azure IoT Hub IoT デバイスの登録・認証・管理。双方向通信を仲介する（PaaS の基盤）
Azure IoT Central SaaS 型の IoT アプリケーション プラットフォーム。可視化が同梱
Azure IoT solution accelerators IoT Central より大規模なソリューションのテンプレート

  • Azure IoT Central

    • IoT データ、テレメトリ・データの可視化機能が同梱されている。
    • 開発、管理、および保守の負担とコストを削減する。
    • 制御機能の一部は含まれていないが、その分、必要な設定・管理・運用の負担も少ない。

  • solution accelerators

    • 予知保全やリモート監視など、一般的な IoT の利用シーンを想定した
      アプリケーション開発を容易にするテンプレートを提供
    • 各種のリソースを使用して組み上がっているので修正が難しい
      （IP アドレス / VM / Managed Disks / Blob Storage / IoT Hub /
      Stream Analytics / Time Series Insights / App Service / Cosmos DB）

補足（IoT Hub と IoT Central の選び分け）: 「基盤を組むか、
出来合いを使うか」という違いである。

IoT Hub（PaaS） IoT Central（SaaS）
提供範囲 通信の基盤だけ 可視化・ルール・ダッシュボードまで
開発 バックエンドを自分で作る ほぼ設定だけ
柔軟性 高い 低い（型にはまる）
立ち上がり 遅い 速い

PoC や「まず可視化したい」なら IoT Central、
「独自の業務ロジックを組み込む」なら IoT Hub、という判断になる。
なお IoT Central は内部で IoT Hub を使っており、後から移行もしやすい。

Digital Twin

フロントエンド

サービス 内容
Azure IoT Edge クラウド側の処理を Edge 側で処理する。ランタイムをコンテナ化＆デプロイ
Azure IoT Hub DPS 大規模なデバイス プロビジョニング
Device Update for IoT Hub IoT デバイスを OTA 更新するサービス

デバイス・エッジ（物理）

  • Azure Sphere: Linux ベースのセキュリティ・ソリューション
  • Azure RTOS: IoT デバイスと Edge デバイスのための RTOS 開発スイート
  • Raspberry Pi Simulator: 簡単にテストできるシミュレータ

基本的な可視化のバックエンド

その他のバックエンド

サービス 用途
Azure Functions PoC 等
Azure Stream Analytics ストリーミング処理の定番
Azure Event Hubs プッシュして他サービスでプル
Azure Event Grid イベント駆動。発生順は保証されない
Azure Service Bus 従来のエンタープライズ向けメッセージング

アーキテクチャ

構成

Things Gateway Insights1 Path Insights2 Actions
IoT デバイス
エッジ デバイス		 クラウド ゲートウェイ
デバイス プロビジョニング		 ストリーム処理 → Hot → Logic Apps（EDI）等 結果を利用する
アプリケーション
〃 〃 Azure Functions（FaaS） → Warm → Azure Cosmos DB
（ウォーム パス ストレージ）		 〃
〃 〃 Azureのストレージ
（コールド パス ストレージ）		 → Cold → Azure Synapse、機械学習
集計結果や推論結果など		 〃
  • データ・パイプライン型: ハブ機能が無く、アクションに OT への
    フィードバックが無いモノ。
  • ハブ＆メッセージ・サービス型: ハブ機能が有って、
    アクションに OT へのフィードバックが有るモノ。

Path

Path 内容
Hot データが到着すると、ほぼリアルタイムでそのデータを分析
Warm Hot と Cold の中間
Cold より長い間隔（毎時または毎日）でバッチ処理を実行

補足（ラムダ アーキテクチャの一形態）: この Hot / Warm / Cold の
3 分割は、同じデータを目的別に別経路で処理するという考え方である。

Path 求めるもの 犠牲にするもの
Hot 即時性（異常検知・アラート） 精度・網羅性
Warm 参照のしやすさ（直近のダッシュボード） －
Cold 網羅性・精度（機械学習・長期分析） 即時性

1 つの経路で全部を満たそうとすると破綻するため、
要件ごとに経路を分けるのが IoT / ビッグデータ設計の定石になる。

セキュリティ

認証・認可

選択肢（いずれかを使用する）

分類 手段
証明書 自己署名証明書 / CA 署名証明書
Azure 独自機構 SAS トークン（トークン）/ Azure Managed Identity / Entra ID の OAuth 2.0
OSS 独自機構 SASL 認証

使い分け

対象 推奨
Azure サービス Azure Managed Identity
Azure サービス以外（リッチ） Entra ID の OAuth 2.0
Azure サービス以外（シン） 証明書 / SAS トークン / OSS 独自機構

その他

  • 保護された通信: 暗号化、署名、SSL/TLS
  • 物理的な改ざん防止: TPMによるストレージの暗号化など
  • 監視およびログ記録 / テレメトリのトレース

補足（IoT のセキュリティは「デバイスは奪われる」前提）: IoT では
デバイスが物理的に攻撃者の手に渡ることを前提に設計する必要がある。

前提 対策
分解して鍵を読まれる TPM / セキュア エレメントに鍵を格納
1 台の鍵が漏れる デバイスごとに個別の鍵（共通鍵を焼き込まない）
通信を傍受される TLS + 証明書の検証（自己署名を無条件で信頼しない）
侵害されたデバイスが暴走 失効（DPS の登録取り消し）とレート制限

特に 2 番目が重要で、「全デバイス共通の SAS キー」を焼き込むと、
1 台バラされただけで全台が乗っ取られる。
Azure IoT Hubで述べた CA 署名証明書 + DPS が
大規模では事実上必須になる理由でもある。

参考

Microsoft Learn

Tags: 移行, インフラストラクチャ, クラウド, Azure, IoT

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally