Codificación para la seguridad renovable
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).
La compatibilidad con la seguridad renovable es una de las siete propiedades de los dispositivos altamente protegidos. En Azure Sphere, significa que todo el software del dispositivo (incluidas sus propias aplicaciones) se puede actualizar según sea necesario para solucionar las vulnerabilidades recién detectadas. La seguridad es la razón por la que existe Azure Sphere y no se puede resaltar con demasiada frecuencia que mantener el dispositivo seguro en todo momento es fundamental. No es posible escribir código completamente seguro, pero con buenas prácticas de codificación, diligencia extrema en responder a vulnerabilidades recién detectadas y un compromiso con la seguridad renovable, puede asegurarse de que el código de aplicación de alto nivel sea lo más seguro posible. El modelo de aislamiento de aplicaciones de Azure Sphere proporciona una serie de características para garantizar esto:
- Todas las aplicaciones deben firmarse correctamente para poder instalarlas o ejecutarse.
- Solo las funcionalidades de hardware y las direcciones de Internet especificadas en el archivo de manifiesto de aplicación de la aplicación pueden acceder a ellas.
- Las API proporcionadas por el SDK de Azure Sphere incluyen un subconjunto muy reducido de la biblioteca estándar de C, omitiendo posibles agujeros de seguridad, como cuentas de usuario y acceso de shell.
- Las aplicaciones del sistema operativo y del cliente de Azure Sphere se pueden actualizar de forma segura mediante el servicio de seguridad de Azure Sphere a medida que se identifican y abordan los problemas de seguridad.
Sin embargo, la firma de código y la minimización de la superficie expuesta a ataques solo te llevan hasta ahora. Seguir un conjunto de procedimientos recomendados para el desarrollo de software seguro puede ayudar a garantizar que las aplicaciones que firma sean lo más seguras y seguras posible. En este artículo se describen algunas de las herramientas que usa el equipo de Azure Sphere en sus propias prácticas de desarrollo.
Programación de implementaciones periódicas
El sistema operativo de Azure Sphere y el SDK de Azure Sphere se actualizan al menos trimestralmente. Debe tener como objetivo una programación similar para las implementaciones de sus propias aplicaciones.
Asegúrese de que la cadena de herramientas permanece actualizada
El sistema operativo y el SDK de Azure Sphere forman una gran parte de la cadena de herramientas de Azure Sphere, pero es posible que tenga otros componentes que administre por separado. Asegúrese de comprobar periódicamente si hay actualizaciones de estos componentes.
Las vulnerabilidades y exposiciones comunes (CVE) son informes públicos que se usan para describir una vulnerabilidad de seguridad en un sistema, incluido en Azure Sphere. Las actualizaciones del sistema operativo de Azure Sphere abordan periódicamente los CV y ayudan a proteger los dispositivos. Si es posible, incluya comprobaciones de los CV en las canalizaciones de compilación. Marque sitios como la página principal de CISA que realiza un seguimiento de las actualizaciones de seguridad. Recompile y vuelva a implementar las aplicaciones a medida que actualice la cadena de herramientas.
Propagación y cumplimiento de los estándares de codificación
El código que cumple un estándar conocido es más fácil de mantener, más fácil de revisar y probar. Hay estándares de codificación disponibles públicamente para C. MISRA está bien establecido y CERT también tiene un estándar de codificación para C. Además de estos estándares básicos, se recomienda usar el ciclo de vida de desarrollo de seguridad siempre que sea posible.
Asegúrese de que está compilando con marcas de seguridad esenciales
Todas las aplicaciones de Azure Sphere se compilan con compiladores de lenguaje C de la colección de compiladores de Gnu (GCC). El compilador de C, gcc, proporciona cientos de marcas del compilador y del enlazador. En Azure Sphere, las marcas siguientes se usan de forma predeterminada:
-fstack-protector-strong
: genera código para protegerse frente a ataques de aplastamiento de pila.pie
: genera ejecutables independientes de la posición.fPIC
: genera código independiente de posición.
La -fstack-protector-all
marca proporciona más protección que -fstack-protector-strong
, pero aumenta el uso de la pila de memoria. Debido a la memoria limitada en el hardware actual de Azure Sphere, -fstack-protector-all
no se usa de forma predeterminada.
Azure Sphere también usa varias marcas de advertencia: se pueden usar para identificar problemas con el código durante la compilación que se pueden corregir antes de la implementación:
-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 obtener más seguridad, -Wl,-z,now
o -Wl,-z,relro
podría agregarse, pero de nuevo, estas no se usan de forma predeterminada porque provocan un uso adicional de memoria.
Revisión de todo el código
Las revisiones de código son una herramienta sencilla pero eficaz para garantizar código de alta calidad. Se recomienda que no se proteja ningún código sin una revisión de código de un revisor calificado. Las revisiones de código uno a uno, en las que un desarrollador recorre el nuevo código con otro desarrollador, a menudo ayudan al desarrollador original a aclarar el pensamiento que entró en producir el código. Esto puede revelar puntos débiles de diseño o puntos de rama perdidos, incluso sin ninguna entrada del desarrollador de revisión.
Uso de pruebas automatizadas
Los marcos de pruebas automatizados, como gtest, permiten ejecutar conjuntos de funciones de prueba cada vez que se compila un proyecto. Un procedimiento recomendado es asegurarse de que todo el código protegido vaya acompañado de al menos una función de prueba; más suele ser mejor. Entre los tipos importantes de pruebas se incluyen los siguientes:
- Las pruebas unitarias básicas ejecutan cada fragmento de código para comprobar que funciona según lo diseñado. Los casos de prueba deben diseñarse que prueben el código en los bordes; los casos de esquina y los casos perimetrales suelen ser una fuente fructificante de errores.
- Prueba aproximada del código al proporcionar una entrada inesperada de varios tipos para asegurarse de que la función responde correctamente.
- Las pruebas de penetración son útiles para identificar vulnerabilidades que permiten a los atacantes penetrar en la aplicación.
Uso de analizadores de código estático
Los analizadores de código estáticos pueden ayudar a encontrar varios problemas comunes de código. La mayoría se centran en tipos específicos de errores. Las siguientes herramientas gratuitas y de código abierto están entre las usadas por el equipo de desarrollo de Azure Sphere y algunos usuarios de Azure Sphere:
- clang-tidy
- AddressSanitizer (ASan)
- MemorySanitizer (MSan)
- UndefinedBehaviorSanitizer (UBSan)
- Valgrind
La ejecución de algunas de estas herramientas puede requerir volver a compilar la aplicación (o partes de ella) para un sistema operativo de destino diferente.
Quitar código innecesario
El SDK de Azure Sphere proporciona una versión eliminada de las bibliotecas de desarrollo estándar de C; siempre que sea posible, debe buscar oportunidades para quitar su propio código a sus elementos esenciales. Cuantos menos líneas de código, la superficie expuesta a ataques más pequeña está disponible para posibles amenazas. Las advertencias sobre código no accesible o no utilizado se pueden usar para identificar el código innecesario.