Acerca de las actualizaciones por vía inalámbrica

Importante

Esta es la documentación de Azure Sphere (heredado). Azure Sphere (heredado) se retira el 27 de septiembre de 2027 y los usuarios deben migrar a Azure Sphere (integrado) en este momento. Use el selector de versiones situado encima de la TOC para ver la documentación de Azure Sphere (integrado).

Las actualizaciones son una parte importante del modelo de seguridad de Azure Sphere, ya que incorporan la propiedad de la seguridad renovable. Asegurarse de que las actualizaciones se realicen periódicamente ayudan a mantener las 7 propiedades de los dispositivos conformes . Los dispositivos de Azure Sphere comprueban si hay actualizaciones cuando se conectan por primera vez a Internet después de encender o después de presionar el botón Restablecer. Después, las comprobaciones se producen a intervalos regulares (actualmente 20 horas).

Hay tres tipos de actualizaciones: actualizaciones de requisitos previos, actualizaciones del sistema operativo y actualizaciones de implementación. Las actualizaciones de requisitos previos se usan para asegurarse de que los componentes en los que se basa el propio proceso de actualización(actualmente, el almacén de claves de confianza (TKS) y el almacén de certificados están actualizados. El TKS se usa para autenticar las imágenes que se van a descargar e instalar, mientras que el almacén de certificados valida las conexiones a Internet. Una actualización del sistema operativo tiene como destino el software proporcionado por Microsoft en el dispositivo, incluido el sistema operativo normal en el que se ejecutan las aplicaciones, pero también firmware de nivel inferior, como el subsistema Plutón y el Monitor de seguridad. Las actualizaciones de implementación tienen como destino su propio software: sus aplicaciones de alto nivel y con respuesta en tiempo real e imágenes de configuración de placa (si las hay). Azure Sphere administra las actualizaciones de requisitos previos y del sistema operativo; Las actualizaciones de aplicaciones se coordinan mediante Azure Sphere en función de las implementaciones creadas por la organización.

Para que cualquier dispositivo reciba actualizaciones de requisitos previos o del sistema operativo:

• Debe estar conectado a Internet.
• Los requisitos de red deben configurarse correctamente.

Para que cualquier dispositivo actualice sus imágenes de configuración de aplicaciones y placa:

• No debe tener la funcionalidad de desarrollo de aplicaciones.
• Un inquilino debe reclamarlo.
• Debe pertenecer a un grupo de dispositivos.
• El grupo de dispositivos al que pertenece debe tener como destino una implementación.
• La implementación debe contener imágenes de aplicación (y, opcionalmente, una imagen de configuración de placa) creada por o en nombre de la organización.
• El grupo de dispositivos debe tener la directiva updateAll. Puede deshabilitar las actualizaciones de aplicaciones para un grupo de dispositivos determinado mediante el comando azsphere device-group update.

Para todos los dispositivos de un grupo de dispositivos determinado, las implementaciones destinadas a ese grupo de dispositivos se consideran la fuente de verdad para crear imágenes de esos dispositivos. Las imágenes del dispositivo que no existen en la implementación se quitarán del dispositivo. La única excepción, a partir del sistema operativo Azure Sphere 21.04, es que las imágenes de configuración de placa no se quitan a menos que se reemplacen por una nueva imagen de configuración de placa.

La comprobación de actualización del dispositivo se produce en tres fases correspondientes a los tres tipos de actualizaciones:

• En la primera fase, Azure Sphere obtiene un manifiesto que enumera las versiones actuales del TKS y el almacén de certificados. Si el TKS y el almacén de certificados del dispositivo están actualizados, la actualización continúa con la segunda fase. Si no es así, las imágenes actuales se descargan e instalan.
• En la segunda fase, Azure Sphere obtiene un manifiesto que enumera las versiones actuales de las distintas imágenes de componentes del sistema operativo. Si alguna imagen del dispositivo no está actualizada, las imágenes actuales se descargan junto con las imágenes de reversión que se pueden usar para revertir el dispositivo a un estado correcto conocido si se produce un error en el proceso de actualización. Las imágenes del sistema operativo y la reversión se descargan y almacenan en un área de almacenamiento provisional en el dispositivo y, a continuación, se instalan las imágenes del sistema operativo y se reinicia el dispositivo.
• En la tercera fase, Azure Sphere busca actualizaciones de implementación si el grupo de dispositivos los acepta. Al igual que con la actualización del sistema operativo, las imágenes de reversión de las aplicaciones también se almacenan provisionalmente según sea necesario. Las imágenes de aplicación y reversión se descargan y almacenan en el área de almacenamiento provisional y, a continuación, se instalan las imágenes de la aplicación.

Reversión de actualizaciones

Cada parte del proceso de actualización incluye una opción de reversión. En la actualización de requisitos previos, la imagen de reversión es simplemente una copia de seguridad del estado previo a la actualización. Si se produce un error en la actualización, se restaura el estado previo a la actualización.

La reversión en cualquier nivel fuerza la reversión en todos los niveles superiores: si alguna imagen de firmware no se puede arrancar, tanto el firmware como las particiones de la aplicación se revierten.

En el caso de la actualización del sistema operativo, un error de comprobación de firmas o dificultades en tiempo de ejecución pueden desencadenar una reversión. En caso de error de comprobación de firma, se intenta corregir la imagen; si se produce un error, se desencadena una reversión completa. En una reversión completa, las imágenes de reversión almacenadas provisionalmente se instalan para el sistema operativo y las aplicaciones.

Las actualizaciones e implementaciones del sistema operativo tienen ciclos de versión independientes, por lo que es posible que se produzcan varias implementaciones entre las actualizaciones del sistema operativo. Si esto sucede, es importante tener en cuenta que los destinos de reversión de la implementación no son la implementación más reciente, sino la implementación en el momento de la última actualización del sistema operativo. Esto garantiza que el sistema operativo y la aplicación funcionen juntos en el estado revierte.

Actualizaciones interrumpidas

Si se interrumpe una actualización, por ejemplo, una interrupción de energía o una pérdida de conectividad, hay cuatro escenarios posibles para cada tipo de actualización:

• Si se ha descargado y almacenado provisionalmente un conjunto completo de imágenes, pero aún no instalado, la instalación se completará cuando se restaure la alimentación.
• Si algunas pero no todas las imágenes se descargaron y almacenaron provisionalmente, la actualización continuará descargando imágenes que faltan y, a continuación, continuará con la instalación.
• Si se interrumpe una actualización durante la instalación una vez completada la descarga, la instalación se reiniciará durante el arranque.
• Si no se ha descargado completamente ninguna imagen, el proceso de actualización comenzará cuando se restaure la alimentación, ya que no habrá nada listo para instalarse.

Actualizaciones en escenarios de apagado

Azure Sphere admite escenarios de bajo consumo que permiten que los dispositivos se apaguen durante largos períodos para conservar la duración de la batería. En estos escenarios, es importante que el dispositivo pueda comprobar si hay actualizaciones periódicamente. La aplicación de ejemplo Power Down muestra cómo reducir correctamente el consumo de energía, a la vez que se garantiza que el dispositivo permanecerá activo periódicamente para comprobar si hay actualizaciones del sistema operativo y de la aplicación.

Actualizaciones diferidas

Para evitar que las actualizaciones interrumpan las tareas críticas, las aplicaciones de alto nivel pueden incorporar la actualización diferida. Esta característica permite que la aplicación complete sus tareas críticas y, a continuación, prepare el apagado para permitir que la actualización continúe. El ejemplo DeferredUpdate muestra cómo implementar dicha actualización diferida.