Azure Sphere

解決する課題

家電・産業機器・センサーなどの組み込み機器は、コストや消費電力の制約から小さなマイコン（MCU）で動き、いったん出荷すると長期間フィールドに残ります。こうした機器はセキュリティ対策が後回しになりやすく、攻撃の踏み台や乗っ取りの対象になりがちです。Azure Sphere は、シリコン・OS・クラウドを一体で設計し、組み込み機器のセキュリティを土台から作り込むことでこの問題に取り組みます。

• 出荷後に アップデートが届かないまま脆弱性が放置される機器をなくしたい
• マイコン単体では難しい 強固な認証と鍵管理を、小型・低消費電力の機器でも実現したい
• ファームウェアの 改ざんや不正起動を、ハードウェアの根（信頼の起点）から防ぎたい
• 機器とクラウドの通信を なりすましや盗聴から守り、許可した相手とだけつなぎたい
• 多数の現場機器に対して OS とアプリの更新を自動で配信し、運用負担を抑えたい

主要概念と用語

• Azure Sphere 認定 MCU: セキュリティ機能を内蔵した専用マイコン。アプリ用コアと通信・セキュリティ用コアを内包する
• Pluton セキュリティサブシステム: チップ内に組み込まれたセキュリティの中核。鍵の保管・暗号処理・信頼の起点（ハードウェアルートオブトラスト）を担う
• Azure Sphere OS: マイコン上で動く専用の組み込み Linux ベース OS。アプリを隔離し、最小権限で実行する多層構造を持つ
• 高レベルアプリケーション: OS 上のコンテナ的な隔離環境で動くアプリ。既定では外部へのアクセスが拒否され、必要な権限だけを宣言して使う
• リアルタイムアプリケーション: 専用のリアルタイムコア上で動く、時間制約の厳しい処理向けのアプリ
• Azure Sphere Security Service: 機器の認証・証明書発行・更新配信・障害報告を担うクラウド側サービス
• デバイス認証と証明書: 機器ごとに発行される証明書ベースの ID。クラウドや他サービスへの接続時に身元を証明する
• 更新（OS / アプリ）: OS とアプリを安全に配信・適用する仕組み。ロールバック耐性を持つ
• 製品 / デバイスグループ: 機器を束ねて更新の配信対象を管理する単位

仕様・制限・クォータ

• 対象はマイコン級の機器: 高性能な SoC や PC ではなく、組み込み向けの小型 MCU を想定した基盤
• 専用シリコン前提: 任意のチップではなく、Azure Sphere 認定 MCU の上でのみ動作する
• アプリの隔離: 高レベルアプリは既定で外部アクセスが拒否され、接続先や周辺機器の利用は宣言した範囲に限られる
• 通信の制御: 機器が接続できる先は許可した宛先に限定され、想定外の通信は遮断される
• 更新の前提: セキュリティ維持には継続的な OS / アプリ更新の受信が前提となる構成
• Legacy 管理面: 旧 Public API（PAPI）と azsphere CLI は 2027年9月27日に退役する。既存の自動化は Azure Resource Manager 統合版の API、ポータル、az sphere CLI へ先に移す
• 保安サービス終了後: 2031年7月31日以降は OS / アプリ更新、修正、セキュリティパッチに加え、デバイスの構成証明と認証も停止する。IoT Hub など上流への接続にも影響する
• 新規採用: MT3620 は 2026年7月31日に製品寿命を迎えるため、新規製品は代替 MCU と別の認証・更新基盤を前提にする
• 具体的な対応チップ・リージョン・上限値は変動するため、最新の公式情報で確認する

内部の仕組み

横にスクロール

Azure Sphere のセキュリティは、ハードウェア・OS・クラウドの三層が連携することで成り立ちます。土台となるのが認定 MCU 内の Pluton セキュリティサブシステムで、ここがチップ内の鍵を保管し、暗号処理と「信頼の起点（ハードウェアルートオブトラスト）」を提供します。起動時にはこの起点から段階的に署名を検証していき、改ざんされたファームウェアが立ち上がらないようにします。

OS 層では、Azure Sphere OS がアプリを隔離して最小権限で動かします。高レベルアプリは既定で外部へアクセスできず、必要な接続先や周辺機器の利用を宣言した範囲でのみ許可されます。これにより、あるアプリが侵害されても被害が機器全体へ広がりにくくなります。時間制約の厳しい処理は専用のリアルタイムコア側で動かし、役割を分離します。

クラウド層の Azure Sphere Security Service は、機器ごとの証明書ベース認証、OS とアプリの安全な更新配信、そして障害報告の収集を担います。機器は接続のたびに証明書で身元を証明し、許可された宛先とだけ通信します。OS とアプリの更新は継続的に配信されるため、出荷後に発見された脆弱性にも対処し続けられます。

ただし、この一体型の認証・更新経路は 2031年7月31日で停止します。単に別の IoT Hub へ接続先を変えるだけでは代替できません。Microsoft は移行部品として、IoT Hub と Azure Device Registry / X.509 証明書管理（公開プレビュー）、PSA Certified Attestation API 対応 MCU、Device Update for IoT Hub、Azure IoT ライブラリ、FIPS 140-3 対応暗号ライブラリの評価を案内しています。公開プレビュー機能は本番前提にせず、GA 状況と制約を再確認します。

設計パターン / ベストプラクティス

• 新規設計では採用しない: MT3620 の製品寿命と 2031 年の保安サービス終了が決まっているため、代替 MCU と標準的な構成証明・PKI・更新基盤を選ぶ
• 保安機能を分解して移行する: 構成証明、端末証明書、業務データ接続、OS / アプリ更新、障害報告を別々の要件として棚卸しし、代替先と責任者を決める
• 管理面を先行移行する: PAPI と azsphere を使うスクリプトを洗い出し、2027年9月27日までに Integrated API と az sphere へ切り替える
• 最小権限で宣言する: 高レベルアプリには必要な接続先・周辺機器・権限だけを宣言し、既定の「全拒否」を活かす
• アプリの役割を分離する: 時間制約の厳しい処理はリアルタイムコア、ネットワークや上位ロジックは高レベルアプリへと分ける
• 更新を前提に運用する: OS とアプリの自動更新を有効にし、出荷後も脆弱性対応を継続できる体制を作る
• 接続先を絞る: 機器が通信できる宛先を許可したものに限定し、想定外の外部通信を遮断する
• クラウド連携は証明書で: 他サービスへの接続は機器の証明書ベース認証を使い、機器に秘密情報を直接埋め込まない
• 段階的に展開する: デバイスグループ単位で更新を試験配信してから全体へ広げ、不具合の影響を抑える

運用・監視

• 3つの期限を分けて管理: MT3620 調達は 2026年7月31日、Legacy 管理面は 2027年9月27日、OS・保安サービスは 2031年7月31日を期限として、依存関係と移行状況を追跡する
• 更新の配信状況を製品 / デバイスグループ単位で管理し、対象機器に OS とアプリが行き渡っているかを把握する
• 障害報告をクラウド側で収集し、現場機器のクラッシュや異常の傾向を遠隔から分析する
• 段階配信で一部のデバイスグループに先行適用し、問題がなければ範囲を広げる
• 機器の 証明書や接続の状態を監視し、認証失敗や想定外の通信を早期に検知する
• セキュリティ維持の前提が 継続的な更新受信であることを踏まえ、長期間オフラインの機器がないか運用で確認する

コスト

Azure Sphere は MCU の一度きりの購入価格に、チップ、Azure Sphere OS、Security Service、OS 更新が含まれます。Azure Sphere または Security Service 自体に継続的なサブスクリプション料・従量料金はありません。IoT Hub など別の Azure サービスを利用すれば、その通常料金は別途発生します。

退役移行では、代替 MCU の再設計・認証、PKI / 構成証明、OTA 更新、既存端末の交換や現地作業まで含めた総コストを見積もります。MT3620 の在庫確保だけでは 2031 年以降の認証・更新停止を解消できません。

セキュリティ

• ハードウェアルートオブトラスト: Pluton サブシステムがチップ内に信頼の起点を持ち、鍵保管と暗号処理を担う
• セキュアブート: 起動時に署名を段階的に検証し、改ざんされたファームウェアの起動を防ぐ
• アプリ隔離と最小権限: 高レベルアプリは既定で外部アクセスが拒否され、宣言した範囲だけが許可される
• 証明書ベースのデバイス認証: 機器ごとの証明書で身元を証明し、なりすましを防ぐ
• 通信の制御: 許可した宛先とだけ通信し、想定外の外部接続を遮断する
• 継続的な更新: OS とアプリの自動更新で、出荷後に見つかった脆弱性にも対処し続ける
• 期限後の境界: 2031年7月31日以降は Microsoft から更新・パッチが届かず、構成証明と認証も停止する。期限前に代替の信頼起点・証明書発行・失効・更新経路を実装する

関連サービス・比較

Azure Sphere は機器側のセキュリティと信頼の起点を担う基盤で、多数のデバイスをつなぐハブである Azure IoT Hub とは役割が異なります。Sphere の機器を IoT Hub に接続し、接続管理は Hub に、デバイス自体の保護は Sphere に分担させる構成が代表的です。

ハンズオン / CLI例

Legacy の azsphere CLI ではなく、Azure Resource Manager と Entra ID / RBAC に統合された az sphere CLI を使います。以下は既存資産の確認と管理面移行の出発点です。

# Azure CLIとIntegrated版の拡張機能を用意
az extension add --upgrade --name azure-sphere
az login

# サブスクリプション内のカタログを確認
az sphere catalog list --all --output table

# 接続中の端末IDを確認し、カタログへ一度だけ登録
az sphere device list-attached --output table
az sphere device claim \
  --resource-group <リソースグループ名> \
  --catalog <カタログ名> \
  --device <端末ID>

# 管理対象と更新グループを確認
az sphere device list \
  --resource-group <リソースグループ名> \
  --catalog <カタログ名> \
  --output table
az sphere device-group list \
  --resource-group <リソースグループ名> \
  --catalog <カタログ名> \
  --output table