Over-the-air 更新プログラムについて

更新は、Azure Sphere セキュリティ モデルの重要な部分であり、再生可能なセキュリティの特性を体現しています。 更新プログラムが定期的に行われるのを確認すると、デバイス の 7 プロパティに 準拠した状態を維持するのに役立ちます。 Azure Sphere デバイスは、電源を入れた後、または [リセット] ボタンが押された後にインターネットに初めて接続したときに更新プログラムをチェックします。 その後、チェックは定期的に行われます (現在は 20 時間)。

更新プログラムには、前提条件の更新プログラム、OS更新プログラム、展開更新プログラムの 3 種類があります。 前提条件の更新プログラムは、更新プロセス自体が依存するコンポーネント (現在は信頼されたキー ストア (TKS) と証明書ストア) が最新の状態であることを確認するために使用されます。 TKS は、ダウンロードしてインストールするイメージを認証するために使用され、証明書ストアはインターネット接続を検証します。 OS の更新プログラムは、アプリケーションが実行される通常の世界のオペレーティング システムを含む、デバイス上の Microsoft が提供するソフトウェアだけでなく、プルトン サブシステムやセキュリティ モニターなどの下位レベルのファームウェアも対象としています。 展開更新プログラムは、独自のソフトウェア (高度でリアルタイムに対応するアプリケーションとボード構成イメージ (存在する場合)) を対象としています。 前提条件と OS の更新プログラムは Azure Sphere によって管理されます。アプリケーションの更新は、organizationによって作成されたデプロイに基づいて Azure Sphere によって調整されます。

任意のデバイスが前提条件または OS 更新プログラムを受け取るには、次の手順を実行します。

• インターネットに接続されている必要があります。
• ネットワーク要件を 適切に構成する必要があります。

任意のデバイスがアプリケーションとボードの構成イメージを更新するには、次の手順を実行します。

• アプリケーション開発機能を持つ必要はありません。
• これはカタログによって要求される必要があります。
• デバイス グループに属している必要があります。
• そのグループが属するデバイス グループは、展開の対象にする必要があります。
• デプロイには、organizationの代わりに作成されたアプリケーション イメージ (および必要に応じてボード構成イメージ) が含まれている必要があります。
• デバイス グループには UpdateAll 更新ポリシーが必要です。 az sphere device-group update コマンドを使用して、特定のデバイス グループのアプリケーション更新を無効にすることができます。

特定のデバイス グループ内のすべてのデバイスについて、そのデバイス グループを対象とする展開は、それらのデバイスをイメージングするための信頼できるソースと見なされます。 展開に存在しないデバイス上のイメージはすべて、デバイスから削除されます。 1 つの例外は、Azure Sphere OS 21.04 以降では、ボード構成イメージが新しいボード構成イメージに置き換えられない限り削除されないことです。

デバイス更新プログラムチェックは、次の 3 種類の更新プログラムに対応する 3 つのフェーズで発生します。

• 最初のフェーズでは、Azure Sphere は、TKS と証明書ストアの現在のバージョンを示すマニフェストを取得します。 デバイス上の TKS と証明書ストアが最新の状態である場合、更新は 2 番目のフェーズで続行されます。 そうでない場合は、現在のイメージがダウンロードされ、インストールされます。
• 2 番目のフェーズでは、Azure Sphere は、さまざまな OS コンポーネント イメージの現在のバージョンを示すマニフェストを取得します。 デバイス上のイメージが古い場合、現在のイメージは ロールバック イメージ と共にダウンロードされます。これは、更新プロセスが失敗した場合にデバイスを既知の良好な状態にロールバックするために使用できます。 OS イメージとロールバック イメージがダウンロードされ、デバイス上のステージング領域に格納された後、OS イメージがインストールされ、デバイスが再起動されます。
• 3 番目のフェーズでは、Azure Sphere は、デバイス グループが更新プログラムを受け入れているかどうかを確認します。 OS の更新と同様に、アプリケーションのロールバック イメージも必要に応じてステージングされます。 アプリケーション イメージとロールバック イメージがダウンロードされ、ステージング領域に格納された後、アプリケーション イメージがインストールされます。

ロールバックの更新

更新プロセスの各部分には、ロールバック オプションが含まれています。 前提条件の更新では、ロールバック イメージは単に更新前の状態のバックアップです。 更新が失敗した場合、更新前の状態が復元されます。

任意のレベルでロールバックすると、すべての上位レベルで強制的にロールバックされます。ファームウェア イメージの起動に失敗した場合、ファームウェアとアプリケーションの両方のパーティションがロールバックされます。

OS 更新の場合、署名検証エラーまたはランタイムの問題によってロールバックがトリガーされる可能性があります。 署名検証エラーが発生した場合は、イメージの修正が試行されます。これが失敗した場合は、完全なロールバックがトリガーされます。 完全なロールバックでは、OS とアプリケーションの両方に対してステージングされたロールバック イメージがインストールされます。

OS の更新プログラムと展開には独立したリリース サイクルがあるため、OS 更新プログラム間で複数の展開を行うことができます。 このような場合は、展開のロールバック ターゲットは最新のデプロイではなく、最後の OS 更新時のデプロイであることに注意することが重要です。 これにより、OS とアプリケーションがロールバック状態で連携します。

中断された更新プログラム

たとえば、停電や接続の喪失などによって更新が中断された場合、更新の種類ごとに 4 つのシナリオが考えられます。

• イメージの完全なセットが正常にダウンロードされ、ステージングされたが、まだインストールされていない場合、電源が復元されるとインストールが完了します。
• 一部のイメージがダウンロードされ、ステージングされていない場合、更新プログラムは不足しているイメージのダウンロードを続行し、インストールに進みます。
• ダウンロードが完了した後にインストール中に更新プログラムが中断された場合、インストールは起動時に再起動されます。
• イメージが完全にダウンロードされていない場合、インストールする準備が何もないため、電源が復元されると更新プロセスが新たに開始されます。

電源停止シナリオでの更新

Azure Sphere では、バッテリの寿命を節約するためにデバイスの電源を長時間 停止 できる低電力シナリオがサポートされています。 このようなシナリオでは、デバイスが更新プログラムのチェックを定期的に許可することが重要です。 Power Down サンプル アプリケーションは、デバイスが OS とアプリの更新プログラムのチェックに定期的に目を覚まし続けることを保証しながら、電力消費量を適切に削減する方法を示しています。

遅延更新プログラム

重要なタスクが更新によって中断されるのを防ぐために、高レベルのアプリケーションは 遅延更新プログラムを組み込むことができます。 この機能を使用すると、アプリケーションは重要なタスクを完了し、シャットダウンの準備をして更新を続行できます。 DeferredUpdate サンプルは、このような遅延更新プログラムを実装する方法を示しています。