Codificação para segurança renovável

Artigo
09/27/2024

Importante

Esta é a documentação do Azure Sphere (Legado). O Azure Sphere (Legado) será desativado em 27 de setembro de 2027 e os usuários devem migrar para o Azure Sphere (Integrado) até esse momento. Use o seletor de versão localizado acima do sumário para exibir a documentação do Azure Sphere (Integrado).

O suporte para segurança renovável é uma das sete propriedades de dispositivos altamente seguros. No Azure Sphere, isso significa que todo o software no dispositivo, incluindo seus próprios aplicativos, pode ser atualizado conforme necessário para resolver vulnerabilidades recém-descobertas. A segurança é a razão pela qual o Azure Sphere existe, e não se pode enfatizar com muita frequência que manter seu dispositivo seguro em todos os momentos é fundamental. Não é possível escrever código completamente seguro, mas com boas práticas de codificação, extrema diligência na resposta a vulnerabilidades recém-descobertas e um compromisso com a segurança renovável, você pode garantir que seu código de aplicativo de alto nível seja o mais seguro possível. O modelo de isolamento de aplicativo do Azure Sphere fornece vários recursos para garantir isso:

Todos os aplicativos devem ser assinados adequadamente antes de poderem ser instalados ou executados.
Somente os recursos de hardware e endereços da Internet que foram especificados no arquivo de manifesto do aplicativo do aplicativo podem ser acessados pelo aplicativo.
As APIs fornecidas pelo SDK do Azure Sphere incluem um subconjunto muito reduzido da biblioteca C padrão, omitindo possíveis falhas de segurança, como contas de usuário e acesso ao shell.
O sistema operacional Azure Sphere e os aplicativos do cliente podem ser atualizados com segurança usando o Serviço de Segurança do Azure Sphere à medida que as preocupações de segurança são identificadas e resolvidas.

No entanto, a assinatura de código e a minimização da superfície de ataque levam você apenas até o fim. Seguir um conjunto de práticas recomendadas para o desenvolvimento seguro de software pode ajudar a garantir que os aplicativos assinados sejam o mais seguros possível. Este artigo descreve algumas das ferramentas que a equipe do Azure Sphere usa em suas próprias práticas de desenvolvimento.

Agendar implantações regulares

O sistema operacional Azure Sphere e o SDK do Azure Sphere são atualizados pelo menos trimestralmente. Você deve apontar para um cronograma semelhante para implantações de seus próprios aplicativos.

Certifique-se de que sua cadeia de ferramentas permaneça atualizada

O sistema operacional Azure Sphere e o SDK formam uma grande parte da cadeia de ferramentas do Azure Sphere, mas você pode ter outros componentes gerenciados separadamente. Certifique-se de verificar regularmente se há atualizações para esses componentes.

Vulnerabilidades e exposições comuns (CVEs) são relatórios públicos usados para descrever uma vulnerabilidade de segurança em um sistema, inclusive no Azure Sphere. As atualizações do SO Azure Sphere abordam regularmente CVEs e ajudam a manter os seus dispositivos seguros. Se possível, inclua verificações de CVEs em seus pipelines de compilação. Marque sites como a página inicial da CISA que rastreiam atualizações de segurança. Recrie e reimplante seus aplicativos à medida que atualiza sua cadeia de ferramentas.

Propagar e aderir aos padrões de codificação

O código que adere a um padrão conhecido é mais fácil de manter, mais fácil de revisar e mais fácil de testar. Existem normas de codificação publicamente disponíveis para C. MISRA está bem estabelecido e CERT também tem um padrão de codificação para C. Além desses padrões básicos, recomendamos o uso do Ciclo de Vida de Desenvolvimento de Segurança sempre que possível.

Certifique-se de que está a compilar com sinalizadores de segurança essenciais

Todos os aplicativos do Azure Sphere são criados com compiladores de linguagem C da Gnu Compiler Collection (GCC). O compilador C, gcc, fornece centenas de sinalizadores de compilador e vinculador. No Azure Sphere, os seguintes sinalizadores são usados por padrão:

-fstack-protector-strong: gera código para proteger contra ataques de esmagamento de pilha.
pie: gera executáveis independentes de posição.
fPIC: gera código independente de posição.

O -fstack-protector-all sinalizador fornece mais proteção do que -fstack-protector-strong, mas aumenta o uso da pilha de memória. Devido à memória limitada no hardware atual do Azure Sphere, -fstack-protector-all não é usado por padrão.

O Azure Sphere também usa vários sinalizadores de aviso — eles podem ser usados para identificar problemas com seu código durante a compilação que podem ser corrigidos antes da implantação:

-Wall -Wswitch -Wempty-body -Wconversion -Wreturn-type -Wparentheses -Wno-format -Wuninitialized -Wunreachable-code -Wunused-function -Wunused-value -Wunused-variable -Wstrict-prototypes -Wno-pointer-sign -Werror=implicit-function-declaration

Para maior segurança, -Wl,-z,now ou -Wl,-z,relro poderia ser adicionado, mas, novamente, eles não são usados por padrão porque causam uso de memória extra.

Rever todo o código

As revisões de código são uma ferramenta simples, mas eficaz para garantir um código de alta qualidade. Recomendamos que nenhum código seja verificado sem uma revisão de código de um revisor qualificado. As revisões de código individuais, nas quais um desenvolvedor percorre o novo código com outro desenvolvedor, geralmente ajudam o desenvolvedor original a esclarecer o pensamento que levou à produção do código. Isso pode revelar fraquezas de design ou pontos de ramificação perdidos, mesmo sem nenhuma entrada do desenvolvedor de revisão.

Use testes automatizados

Estruturas de teste automatizadas, como gtest, permitem que você execute conjuntos de funções de teste sempre que um projeto é construído. Uma boa prática consiste em assegurar que todo o código registado seja acompanhado por, pelo menos, uma função de ensaio; mais é geralmente melhor. Os tipos importantes de testes incluem o seguinte:

O teste de unidade básica executa cada parte do código para verificar se está funcionando conforme projetado. Casos de teste devem ser projetados para testar o código nas bordas, corner-cases e edge cases geralmente são uma fonte frutífera de bugs.
O teste Fuzz exerce código, fornecendo entrada inesperada de vários tipos para garantir que a função responda adequadamente.
O teste de penetração é útil para identificar vulnerabilidades que permitem que invasores penetrem no aplicativo.

Usar analisadores de código estático

Os analisadores de código estático podem ajudar a encontrar vários problemas de código comuns. A maioria concentra-se em tipos específicos de erros. As seguintes ferramentas gratuitas e de código aberto estão entre as usadas pela equipe de desenvolvimento do Azure Sphere e alguns usuários do Azure Sphere:

A execução de algumas dessas ferramentas pode exigir a recompilação do seu aplicativo (ou partes dele) para um sistema operacional de destino diferente.

Remover código desnecessário

O SDK do Azure Sphere fornece uma versão reduzida das bibliotecas de desenvolvimento C padrão; Sempre que possível, você deve procurar oportunidades para remover seu próprio código para o essencial. Quanto menos linhas de código, menor a superfície de ataque estará disponível para ameaças potenciais. Avisos sobre código inacessível ou não utilizado podem ser usados para identificar código desnecessário.

Partilhar via