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 / アプリ更新の受信が前提となる構成
• 提供状況の確認: 製品としての提供方針やサポート期間は変わり得るため、導入前に最新の公式情報を確認する。新規採用の可否や代替の検討も含め、定性的に判断する
• 具体的な対応チップ・リージョン・上限値は変動するため、最新の公式情報で確認する

内部の仕組み

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

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

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

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

• 最小権限で宣言する: 高レベルアプリには必要な接続先・周辺機器・権限だけを宣言し、既定の「全拒否」を活かす
• アプリの役割を分離する: 時間制約の厳しい処理はリアルタイムコア、ネットワークや上位ロジックは高レベルアプリへと分ける
• 更新を前提に運用する: OS とアプリの自動更新を有効にし、出荷後も脆弱性対応を継続できる体制を作る
• 接続先を絞る: 機器が通信できる宛先を許可したものに限定し、想定外の外部通信を遮断する
• クラウド連携は証明書で: 他サービスへの接続は機器の証明書ベース認証を使い、機器に秘密情報を直接埋め込まない
• 段階的に展開する: デバイスグループ単位で更新を試験配信してから全体へ広げ、不具合の影響を抑える

運用・監視

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

コスト

Azure Sphere のコストは、主に **認定 MCU（ハードウェア）**と、機器を支える セキュリティサービスの利用に関わる費用で構成されます。汎用の従量課金サービスとは性質が異なり、対象機器のライフサイクル全体を見据えて評価します。

• ハードウェア側は対象 MCU の調達コストとして発生する
• クラウド側は機器のセキュリティ・更新・認証を支えるサービス利用に関わる
• 出荷後の長期サポートを前提に、機器の ライフサイクル全体での総コストで比較する
• 具体的な単価や課金条件は変わり得るため、最新の公式情報で確認する

セキュリティ

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

関連サービス・比較

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

ハンズオン / CLI例

# Azure Sphere の CLI（azsphere）でテナント情報を確認する
azsphere tenant list

# 認証して操作対象のテナントを選ぶ
azsphere login

# デバイスを現在のテナントに登録（要求された情報に従う）
azsphere device claim

# デバイスのグループ単位での更新管理に使う製品を作成
azsphere product create --name contoso-thermostat

# OS とアプリの自動更新を受けるデバイスグループに割り当てる
azsphere device update --device <デバイス識別子>