Acerca das atualizações ao ar livre

Atualizações são uma parte importante do modelo de segurança do Azure Sphere, uma vez que incorporam a propriedade de segurança renovável. Garantir que as atualizações ocorrem regularmente ajuda a manter os seus dispositivos em conformidade com as 7 propriedades . Os dispositivos do Azure Sphere verificam a existência de atualizações quando se ligam pela primeira vez à Internet depois de ligar ou depois de premir o botão Repor. A partir daí, as verificações ocorrem em intervalos regulares (atualmente 20 horas).

Existem três tipos de atualizações: atualizações de pré-requisitos, atualizações do SO e atualizações de implementação. As atualizações de pré-requisitos são utilizadas para garantir que os componentes nos quais o próprio processo de atualização se baseia — atualmente o Arquivo de Chaves Fidedignos (TKS) e o arquivo de certificados estão atualizados. O TKS é utilizado para autenticar as imagens a serem transferidas e instaladas, enquanto o arquivo de certificados valida as ligações à Internet. Uma atualização do SO destina-se ao software fornecido pela Microsoft no dispositivo, incluindo o sistema operativo normal no qual as suas aplicações são executadas, mas também firmware de nível inferior, como o subsistema Pluton e o Monitor de Segurança. As atualizações de implementação destinam-se ao seu próprio software — as suas aplicações de alto nível e em tempo real e imagens de configuração de quadros (se existirem). Os pré-requisitos e as atualizações do SO são geridos pelo Azure Sphere; As atualizações de aplicações são coordenadas pelo Azure Sphere com base nas implementações criadas pela sua organização.

Para que qualquer dispositivo receba pré-requisitos ou atualizações do SO:

• Tem de estar ligado à Internet.
• Os requisitos de rede têm de ser devidamente configurados.

Para que qualquer dispositivo atualize as imagens de configuração da aplicação e do quadro:

• Não pode ter a capacidade de desenvolvimento de aplicações.
• Tem de ser reclamada por um catálogo.
• Tem de pertencer a um grupo de dispositivos.
• O grupo de dispositivos ao qual pertence tem de ser visado por uma implementação.
• A implementação tem de conter imagens da aplicação (e, opcionalmente, uma imagem de configuração do quadro) criadas por ou em nome da sua organização.
• O grupo de dispositivos tem de ter a política AtualizarTodos as atualizações. Pode desativar as atualizações de aplicações para um grupo de dispositivos específico com o comando az sphere device-group update .

Para todos os dispositivos num determinado grupo de dispositivos, as implementações direcionadas para esse grupo de dispositivos são consideradas a fonte de verdade para a criação de imagens desses dispositivos. Todas as imagens no dispositivo que não existem na implementação serão removidas do dispositivo. A única exceção, a partir do SO 21.04 do Azure Sphere, é que as imagens de configuração do quadro não são removidas, a menos que sejam substituídas por uma nova imagem de configuração do quadro.

A verificação da atualização do dispositivo ocorre em três fases correspondentes aos três tipos de atualizações:

• Na primeira fase, o Azure Sphere obtém um manifesto que lista as versões atuais do TKS e do arquivo de certificados. Se o TKS e o arquivo de certificados no dispositivo estiverem atualizados, a atualização continuará com a segunda fase. Caso contrário, as imagens atuais são transferidas e instaladas.
• Na segunda fase, o Azure Sphere obtém um manifesto que lista as versões atuais das várias imagens dos componentes do SO. Se alguma imagem no dispositivo estiver desatualizada, as imagens atuais são transferidas juntamente com imagens de reversão que podem ser utilizadas para reverter o dispositivo para um bom estado conhecido se o processo de atualização falhar. O SO e as imagens de reversão são transferidas e armazenadas numa área de teste no dispositivo e, em seguida, as imagens do SO são instaladas e o dispositivo é reiniciado.
• Na terceira fase, o Azure Sphere verifica se existem atualizações de implementação se o grupo de dispositivos as aceitar. Tal como acontece com a atualização do SO, as imagens de reversão das aplicações também são testadas conforme necessário. As imagens de aplicação e reversão são transferidas e armazenadas na área de teste e, em seguida, as imagens da aplicação são instaladas.

Reversão da atualização

Cada parte do processo de atualização inclui uma opção de reversão. Na atualização de pré-requisitos, a imagem de reversão é simplesmente uma cópia de segurança do estado de pré-atualização. Se a atualização falhar, o estado de pré-atualização será restaurado.

A reversão a qualquer nível força a reversão em todos os níveis mais elevados: se alguma imagem de firmware não arrancar, as partições de firmware e de aplicação são revertidas.

Para a atualização do SO, uma falha de verificação de assinatura ou dificuldades de runtime podem acionar uma reversão. Em caso de falha de verificação de assinatura, é efetuada uma tentativa para corrigir a imagem; Se isto falhar, é acionada uma reversão completa. Numa reversão completa, as imagens de reversão faseadas são instaladas para o SO e as aplicações.

As atualizações e implementações do SO têm ciclos de lançamento independentes, pelo que é possível que várias implementações ocorram entre atualizações do SO. Se isto acontecer, é importante ter em atenção que os destinos de reversão da implementação não são a implementação mais recente, mas sim a implementação no momento da última atualização do SO. Isto garante que o SO e a aplicação funcionam em conjunto no estado revertido.

Atualizações interrompidas

Se uma atualização for interrompida, por exemplo, por uma falha de energia ou perda de conectividade, existem quatro cenários possíveis para cada tipo de atualização:

• Se um conjunto completo de imagens tiver sido transferido e testado com êxito, mas ainda não estiver instalado, a instalação será concluída quando a energia for restaurada.
• Se algumas, mas nem todas as imagens foram transferidas e testadas, a atualização continuará a transferir as imagens em falta e, em seguida, avançará para a instalação.
• Se uma atualização for interrompida durante a instalação após a conclusão da transferência, a instalação será reiniciada no arranque.
• Se nenhuma imagem tiver sido completamente transferida, o processo de atualização começará de novo quando a energia for restaurada, uma vez que não haverá nada pronto para instalar.

Atualizações em cenários de redução de energia

O Azure Sphere suporta cenários de baixa potência que permitem que os dispositivos sejam desligados durante longos períodos para conservar a duração da bateria. Nestes cenários, é importante que o dispositivo seja autorizado a procurar atualizações periodicamente. O exemplo de aplicação power down demonstra como reduzir corretamente o consumo de energia, garantindo que o dispositivo permanecerá periodicamente ativo para verificar a existência de atualizações do SO e da aplicação.

Atualizações diferidas

Para impedir que tarefas críticas sejam interrompidas por atualizações, as aplicações de alto nível podem incorporar atualizações diferidas. Esta funcionalidade permite que a aplicação conclua as suas tarefas críticas e, em seguida, prepare-se para o encerramento para permitir que a atualização prossiga. O exemplo DeferredUpdate demonstra como implementar essa atualização diferida.