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 mjukvara, som kanske inte uppfyller företagets operativa krav

Azure står inför samma utmaning med betydande komplexitet. Tusentals servrar kör mjukvara som tusentals ingenjörer utvecklar och underhåller. Denna skala utgör en stor attackyta som affärsprocesser ensamma inte kan hantera.

Lägga till en auktoriseringsport

Azure använder en avancerad utvecklingsprocess som har kontrollpunkter för säkerhet, efterlevnad och kvalitet i driftsatt programvara. Denna process inkluderar åtkomstkontroll till källkod, granskning av kamratkod, statisk analys för säkerhetssårbarheter, Microsoft Security Development Lifecycle (SDL) samt funktions- och kvalitetstestning. Microsoft måste garantera att distribuerad mjukvara flyter igenom denna process. Kodintegritet hjälper till att uppnå den garantin.

Kodintegritet som auktoriseringsgrind

Kodintegritet är en kärnnivåtjänst 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 kodintegritetspolicy består av en uppsättning auktorisationsindikatorer, antingen kodsigneringscertifikat eller SHA-256-filhashar , som kärnan matchar innan en binär eller ett skript laddas in eller körs.

Kodintegritet gör det möjligt för systemadministratörer att definiera en policy som endast auktoriserar binärfiler och skript som vissa certifikat signerar eller som matchar specificerade SHA-256-hashar. Kerneln tillämpar den här principen genom att blockera körningen av allt som inte uppfyller den angivna principen.

En kodintegritetspolicy kan blockera kritisk programvara i produktion och orsaka ett avbrott om inte policyn är helt korrekt. Med tanke på denna oro kan du fråga varför säkerhetsövervakning inte är tillräckligt för att upptäcka obehörig mjukvaruexekvering. Kodintegritet har ett granskningsläge som, istället för att förhindra exekvering, kan varna när obehörig programvara körs. Aviseringar kan tillföra mycket värde för att hantera efterlevnadsrisker. Men för säkerhetsrisker som ransomware eller specialanpassad skadlig kod kan en fördröjning av svaret med bara några sekunder vara skillnaden mellan skydd och att en motståndare får ett bestående fotfäste i din flotta. Inom Azure investerar Microsoft betydande för att hantera risken för kodintegritet som kan bidra till ett kundpåverkande avbrott.

Byggprocessen

Som tidigare beskrivits har Azure-byggsystemet en rik uppsättning tester för att säkerställa att mjukvaruändringar är säkra och kompatibla. Efter att en build har gått igenom validering signerar byggsystemet den med ett Azure-byggcertifikat. Certifikatet indikerar att bygget har gått igenom hela förändringshanteringsprocessen. Det sista testet som bygget går igenom är Code Signature Validation (CSV). CSV bekräftar att de nybyggda binärfilerna uppfyller kodintegritetspolicyn innan Microsoft distribuerar dem till produktion. Denna validering ger Microsoft stort förtroende för att felaktigt signerade binärfiler inte kommer att orsaka ett kundpåverkande avbrott. Om CSV hittar ett problem går bygget sönder och relevanta ingenjörer kallas in för att undersöka och åtgärda problemet.

Säkerhet under distribution

Även om Azure utför CSV för varje bygg kan någon förändring eller inkonsekvens i produktionen ändå orsaka ett avbrott relaterat till kodintegritet. Till exempel kan en maskin köra en gammal version av kodintegritetspolicyn, eller så kan den vara i ett ohälsosamt tillstånd som ger falska positiva resultat i kodintegriteten. I Azure-skala har Microsoft sett allt. Azure fortsätter att skydda mot risken för avbrott under driftsättningen.

Alla ändringar i Azure måste distribueras genom en serie steg. De första stegen är interna Azure-testinstanser. Nästa steg betjänar endast andra Microsoft-produktteam. Den sista fasen betjänar tredjepartskunder. När Azure rullar ut en ändring går den vidare till varje steg i tur och ordning och pausar för att mäta stegets hälsa. Om förändringen inte har någon negativ påverkan går den vidare till nästa steg. Om Microsoft gör en dålig ändring i en kodintegritetspolicy, upptäcker den stegvisa distributionen ändringen och rullar tillbaka den.

Incidenthantering

Även med detta lager-på-lager-skydd kan en server i flottan blockera korrekt auktoriserad programvara och orsaka ett kundnära problem, ett av Microsoft värsta scenarier. Det sista försvarslagret är mänsklig utredning. Varje gång kodintegriteten blockerar en fil utlöses en avisering så att beredskapsingenjörerna kan undersöka det. Varningen gör det möjligt för ingenjörer att inleda säkerhetsutredningar och ingripa, oavsett om problemet är en indikator på en verklig attack, ett falskt positivt eller en annan kundpåverkande situation. Denna varning minimerar tiden det tar att åtgärda eventuella problem relaterade till kodintegritet.

Nästa steg

För att lära dig mer om hur Microsoft driver plattformens integritet och säkerhet, se:

  • Last updated on