Kodning för förnybar säkerhet

Artikel
09/27/2024

Viktigt!

Det här är dokumentationen om Azure Sphere (Legacy). Azure Sphere (Legacy) upphör den 27 september 2027 och användarna måste migrera till Azure Sphere (integrerad) vid den här tiden. Använd versionsväljaren ovanför TOC för att visa dokumentationen om Azure Sphere (integrerad).

Stöd för förnybar säkerhet är en av de sju egenskaperna för högskyddade enheter. I Azure Sphere innebär det att all programvara på enheten , inklusive dina egna program, kan uppdateras efter behov för att åtgärda nyligen identifierade sårbarheter. Säkerhet är anledningen till att Azure Sphere finns och det kan inte betonas alltför ofta att det är av största vikt att alltid hålla enheten säker. Det går inte att skriva helt säker kod, men med bra kodningsmetoder, extrem aktsamhet när det gäller att hantera nyligen upptäckta sårbarheter och ett åtagande om förnybar säkerhet kan du se till att din programkod på hög nivå är så säker som möjligt. Azure Sphere-programisoleringsmodellen innehåller ett antal funktioner för att säkerställa följande:

Alla appar måste signeras korrekt innan de kan installeras eller köras.
Endast de maskinvarufunktioner och internetadresser som har angetts i programmets appmanifestfil kan nås av programmet.
API:erna som tillhandahålls av Azure Sphere SDK innehåller en mycket reducerad delmängd av C-standardbiblioteket, vilket utelämnar potentiella säkerhetshål som användarkonton och gränssnittsåtkomst.
Azure Sphere-operativsystemet och kundprogrammen kan uppdateras på ett säkert sätt med hjälp av Azure Sphere Security Service när säkerhetsproblem identifieras och åtgärdas.

Men kodsignering och minimisering av attackytan tar dig bara så långt. Genom att följa en uppsättning metodtips för säker programvaruutveckling kan du se till att de program du signerar är så säkra och säkra som möjligt. Den här artikeln beskriver några av de verktyg som Azure Sphere-teamet använder i sina egna utvecklingsmetoder.

Schemalägga regelbundna distributioner

Azure Sphere OS och Azure Sphere SDK uppdateras minst kvartalsvis. Du bör sträva efter ett liknande schema för distributioner av dina egna program.

Se till att din verktygskedja förblir uppdaterad

Azure Sphere OS och SDK utgör en stor del av Azure Sphere-verktygskedjan, men du kan ha andra komponenter som du hanterar separat. Se till att regelbundet söka efter uppdateringar för dessa komponenter.

Vanliga sårbarheter och exponeringar (CVE) är offentliga rapporter som används för att beskriva en säkerhetsrisk i ett system, inklusive i Azure Sphere. Azure Sphere OS-uppdateringar hanterar regelbundet CVE:er och hjälper till att skydda dina enheter. Inkludera om möjligt kontroller av CVE:er i dina bygg-pipelines. Bokmärkeswebbplatser, till exempel CISA-startsidan som spårar säkerhetsuppdateringar. Återskapa och distribuera om dina program när du uppdaterar verktygskedjan.

Sprida och följa kodningsstandarder

Kod som följer en känd standard är enklare att underhålla, enklare att granska och enklare att testa. Det finns offentligt tillgängliga kodningsstandarder för C. MISRA är väletablerat och CERT har också en kodningsstandard för C. Utöver dessa grundläggande standarder rekommenderar vi att du använder livscykeln för säkerhetsutveckling där det är möjligt.

Se till att du kompilerar med viktiga säkerhetsflaggor

Alla Azure Sphere-appar skapas med C-språkkompilatorer från Gnu Compiler Collection (GCC). C-kompilatorn gcc innehåller hundratals kompilator- och länkflaggor. I Azure Sphere används följande flaggor som standard:

-fstack-protector-strong: genererar kod för att skydda mot stack smashing-attacker.
pie: genererar positionsoberoende körbara filer.
fPIC: genererar positionsoberoende kod.

Flaggan -fstack-protector-all ger mer skydd än -fstack-protector-strong, men ökar minnesstackens användning. På grund av det begränsade minnet på den aktuella Azure Sphere-maskinvaran -fstack-protector-all används inte som standard.

Azure Sphere använder också ett antal varningsflaggor– dessa kan användas för att identifiera problem med koden under kompileringen som kan åtgärdas före distributionen:

-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

För mer säkerhet eller -Wl,-z,now -Wl,-z,relro kan läggas till, men återigen, används dessa inte som standard eftersom de orsakar extra minnesanvändning.

Granska all kod

Kodgranskningar är ett enkelt men effektivt verktyg för att säkerställa kod av hög kvalitet. Vi rekommenderar att ingen kod checkas in utan en kodgranskning från en kvalificerad granskare. En-mot-en-kodgranskningar, där en utvecklare går igenom den nya koden med en annan utvecklare, hjälper ofta den ursprungliga utvecklaren att klargöra tanken som gick till att producera koden. Detta kan avslöja designbrister eller missade grenpunkter även utan indata från granskningsutvecklaren.

Använda automatiserade tester

Med automatiserade testramverk som gtest kan du köra paket med testfunktioner varje gång ett projekt skapas. Bästa praxis är att se till att all incheckad kod åtföljs av minst en testfunktion. mer är vanligtvis bättre. Viktiga typer av testning omfattar följande:

Grundläggande enhetstestning kör varje kodstycke för att verifiera att den fungerar som den är utformad. Testfall bör utformas som testar koden vid kanterna. Hörnfall och kantfall är vanligtvis en givande källa till buggar.
Fuzz-testningen använder kod genom att tillhandahålla oväntade indata av olika typer för att säkerställa att funktionen svarar korrekt.
Intrångstestning är användbart för att identifiera sårbarheter som gör att angripare kan penetrera programmet.

Använda statiska kodanalysverktyg

Statiska kodanalyserare kan hjälpa dig att hitta ett antal vanliga kodproblem. De flesta fokuserar på specifika typer av fel. Följande kostnadsfria verktyg och verktyg med öppen källkod hör till dem som används av Azure Sphere-utvecklingsteamet och vissa Azure Sphere-användare:

Om du kör några av de här verktygen kan du behöva kompilera om programmet (eller delar av det) för ett annat måloperativsystem.

Ta bort onödig kod

Azure Sphere SDK tillhandahåller en avskalad version av C-standardutvecklingsbiblioteken. Där det är möjligt bör du leta efter möjligheter att ta bort din egen kod till dess bare essentials. Ju färre kodrader, desto mindre attackyta är tillgänglig för potentiella hot. Varningar om oåtkomlig eller oanvänd kod kan användas för att identifiera onödig kod.

Dela via