Plattformskodintegritet
En viktig utmaning när det gäller att köra ett komplext system som Microsoft Azure är att se till att endast auktoriserad programvara körs i systemet. Otillåten programvara medför flera risker för alla företag:
- Säkerhetsrisker som dedikerade attackverktyg, anpassad skadlig kod och programvara från tredje part med kända sårbarheter
- Efterlevnadsrisker när den godkända ändringshanteringsprocessen inte används för att ta in ny programvara
- Kvalitetsrisk från externt utvecklad programvara, som kanske inte uppfyller verksamhetens driftskrav
I Azure står vi inför samma utmaning och med stor komplexitet. Vi har tusentals servrar som kör programvara som utvecklats och underhålls av tusentals tekniker. Detta ger en stor attackyta som inte kan hanteras enbart genom affärsprocesser.
Lägga till en auktoriseringsport
Azure använder en omfattande teknisk process som implementerar portar för säkerhet, efterlevnad och kvalitet för den programvara vi distribuerar. Den här processen omfattar åtkomstkontroll till källkod, granskning av peer-kod, statisk analys av säkerhetsrisker, efter Microsofts SDL (Security Development Lifecycle) och funktions- och kvalitetstestning. Vi måste garantera att den programvara som vi distribuerar har flödat genom den här processen. Kodintegritet hjälper oss att uppnå den garantin.
Kodintegritet som auktoriseringsport
Kodintegritet är en tjänst på kernelnivå som blev tillgänglig från och med Windows Server 2016. Kodintegritet kan tillämpa en strikt körningskontrollprincip när en drivrutin eller ett dynamiskt länkat bibliotek (DLL) läses in, en körbar binärfil körs eller ett skript körs. Liknande system, till exempel DM-Verity, finns för Linux. En kodintegritetsprincip består av en uppsättning auktoriseringsindikatorer, antingen kodsigneringscertifikat eller SHA256-filshashvärden , som kerneln matchar innan den läser in eller kör en binär fil eller ett skript.
Med kodintegritet kan en systemadministratör definiera en princip som endast auktoriserar binärfiler och skript som har signerats av vissa certifikat eller matchar angivna SHA256-hashar. Kerneln tillämpar den här principen genom att blockera körningen av allt som inte uppfyller den angivna principen.
Ett problem med en kodintegritetsprincip är att om inte principen är helt korrekt kan den blockera kritisk programvara i produktion och orsaka ett avbrott. Med tanke på detta problem kan man fråga sig varför det inte räcker att använda säkerhetsövervakning för att identifiera när obehörig programvara har körts. Kodintegritet har ett granskningsläge som i stället för att förhindra körning kan avisera när obehörig programvara körs. Aviseringar kan säkert ge mycket värde när det gäller att hantera efterlevnadsrisker, men för säkerhetsrisker som utpressningstrojan eller anpassad skadlig kod kan fördröjning av svaret med bara några sekunder vara skillnaden mellan skydd och en angripare som får ett beständigt fotfäste i din flotta. I Azure har vi investerat avsevärt för att hantera alla risker för kodintegritet som bidrar till att en kund drabbas av avbrott.
Byggprocess
Som beskrivs ovan har Azure-byggsystemet en omfattande uppsättning tester för att säkerställa att programvaruändringar är säkra och kompatibla. När en version har gått igenom valideringen signerar byggsystemet det med hjälp av ett Azure-byggcertifikat. Certifikatet anger att bygget har gått igenom hela ändringshanteringsprocessen. Det sista testet som bygget går igenom kallas validering av kodsignatur (CSV). CSV bekräftar att de nya binärfilerna uppfyller kodintegritetsprincipen innan vi distribuerar till produktion. Detta ger oss stort förtroende för att vi inte kommer att orsaka att en kund påverkar avbrott på grund av felaktigt signerade binärfiler. Om CSV hittar ett problem, öppnas byggbrytningarna och relevanta tekniker för att undersöka och åtgärda problemet.
Säkerhet under distribution
Även om vi utför CSV för varje version finns det fortfarande en risk att viss förändring eller inkonsekvens i produktionen kan orsaka ett kodintegritetsrelaterat avbrott. En dator kan till exempel köra en gammal version av kodintegritetsprincipen eller vara i ett feltillstånd som ger falska positiva identifieringar i kodintegriteten. (I Azure-skala har vi sett allt.) Därför måste vi fortsätta att skydda mot risken för avbrott under distributionen.
Alla ändringar i Azure krävs för att distribueras via en serie faser. Den första av dessa är interna Azure-testinstanser. Nästa steg används endast för att betjäna andra Microsoft-produktteam. Den sista fasen betjänar tredjepartskunder. När en ändring distribueras flyttas den till vart och ett av dessa steg i tur och ordning och pausar för att mäta statusen för fasen. Om ändringen inte har någon negativ inverkan flyttas den till nästa steg. Om vi gör en felaktig ändring av en kodintegritetsprincip identifieras ändringen under den här mellanlagrade distributionen och återställs.
Incidenthantering
Även med det här skiktskyddet är det fortfarande möjligt att vissa servrar i flottan kan blockera korrekt auktoriserad programvara och orsaka problem för en kund, ett av våra värsta scenarier. Vårt sista försvarslager är mänsklig undersökning. Varje gång kodintegritet blockerar en fil genereras en avisering för jourtekniker att undersöka. Med aviseringen kan vi starta säkerhetsutredningar och ingripa, oavsett om problemet är en indikator på en verklig attack, en falsk positiv eller annan kundpåverkande situation. Detta minimerar den tid det tar att minimera eventuella problem med kodintegritet.
Nästa steg
Mer information om vad vi gör för att skapa plattformsintegritet och säkerhet finns i: