Integriteit van platformcode
Een belangrijke uitdaging bij het gebruik van een complex systeem zoals Microsoft Azure is ervoor te zorgen dat alleen geautoriseerde software in het systeem wordt uitgevoerd. Niet-geautoriseerde software brengt verschillende risico's met zich mee voor elk bedrijf:
- Beveiligingsrisico's zoals speciale aanvalshulpprogramma's, aangepaste malware en software van derden met bekende beveiligingsproblemen
- Nalevingsrisico's wanneer het goedgekeurde wijzigingsbeheerproces niet wordt gebruikt om nieuwe software binnen te brengen
- Kwaliteitsrisico van extern ontwikkelde software, die mogelijk niet voldoet aan de operationele vereisten van het bedrijf
In Azure worden we geconfronteerd met dezelfde uitdaging en met een aanzienlijke complexiteit. We hebben duizenden servers waarop software wordt uitgevoerd, ontwikkeld en onderhouden door duizenden technici. Dit vormt een groot aanvalsoppervlak dat niet alleen via bedrijfsprocessen kan worden beheerd.
Een autorisatiepoort toevoegen
Azure maakt gebruik van een uitgebreid technisch proces dat gates implementeert voor de beveiliging, naleving en kwaliteit van de software die we implementeren. Dit proces omvat toegangsbeheer voor broncode, het uitvoeren van beoordelingen van peercode, het uitvoeren van statische analyses op beveiligingsproblemen, het volgen van De Levenscyclus van Beveiliging ontwikkeling (SDL) van Microsoft en het uitvoeren van functionele en kwaliteitstests. We moeten garanderen dat de software die we implementeren dit proces heeft doorlopen. Code-integriteit helpt ons die garantie te bereiken.
Code-integriteit als autorisatiepoort
Code-integriteit is een service op kernelniveau die beschikbaar is geworden vanaf Windows Server 2016. Code-integriteit kan een strikt uitvoeringscontrolebeleid toepassen wanneer een stuurprogramma of een dynamisch gekoppelde bibliotheek (DLL) wordt geladen, een uitvoerbaar binair bestand wordt uitgevoerd of een script wordt uitgevoerd. Vergelijkbare systemen, zoals DM-Verity, bestaan voor Linux. Een code-integriteitsbeleid bestaat uit een set autorisatie-indicatoren, ofwel codeondertekeningscertificaten of SHA256-bestands-hashes , die de kernel overeenkomt voordat een binair bestand of script wordt geladen of uitgevoerd.
Met code-integriteit kan een systeembeheerder een beleid definiëren dat alleen binaire bestanden en scripts autoriseert die zijn ondertekend door bepaalde certificaten of overeenkomen met opgegeven SHA256-hashes. De kernel dwingt dit beleid af door de uitvoering van alles te blokkeren dat niet voldoet aan het ingestelde beleid.
Een probleem met een code-integriteitsbeleid is dat, tenzij het beleid perfect juist is, kritieke software in productie kan blokkeren en een storing kan veroorzaken. Gezien dit probleem kan men zich afvragen waarom het niet voldoende is om beveiligingsbewaking te gebruiken om te detecteren wanneer niet-geautoriseerde software is uitgevoerd. Code-integriteit heeft een controlemodus die, in plaats van uitvoering te voorkomen, kan waarschuwen wanneer niet-geautoriseerde software wordt uitgevoerd. Waarschuwingen kunnen zeker veel waarde toevoegen bij het aanpakken van nalevingsrisico's, maar voor beveiligingsrisico's zoals ransomware of aangepaste malware kan het vertragen van de reactie met zelfs een paar seconden het verschil zijn tussen bescherming en een kwaadwillende persoon die een permanente voet aan de grond krijgt in uw vloot. In Azure hebben we aanzienlijk geïnvesteerd in het beheren van elk risico van code-integriteit dat bijdraagt aan een klant die invloed heeft op storingen.
Bouwproces
Zoals hierboven besproken, heeft het Azure-buildsysteem een uitgebreide set tests om ervoor te zorgen dat softwarewijzigingen veilig en compatibel zijn. Zodra een build is gevalideerd, ondertekent het buildsysteem deze met behulp van een Azure-buildcertificaat. Het certificaat geeft aan dat de build het hele wijzigingsbeheerproces heeft doorlopen. De laatste test die de build doorloopt, wordt Code Signature Validation (CSV) genoemd. CSV bevestigt dat de nieuw gebouwde binaire bestanden voldoen aan het code-integriteitsbeleid voordat we implementeren naar productie. Dit geeft ons hoge vertrouwen dat we geen storing van de klant veroorzaken vanwege onjuist ondertekende binaire bestanden. Als CSV een probleem vindt, worden de build-onderbrekingen en de relevante technici op de pagina geplaatst om het probleem te onderzoeken en op te lossen.
Veiligheid tijdens de implementatie
Hoewel we CSV uitvoeren voor elke build, is er nog steeds een kans dat een wijziging of inconsistentie in de productie kan leiden tot een storing in de code-integriteit. Een computer kan bijvoorbeeld een oude versie van het code-integriteitsbeleid uitvoeren of een beschadigde status hebben die fout-positieven in code-integriteit produceert. (Op Azure-schaal hebben we alles gezien.) Daarom moeten we ons blijven beschermen tegen het risico van een storing tijdens de implementatie.
Alle wijzigingen in Azure moeten worden geïmplementeerd via een reeks fasen. De eerste hiervan zijn interne Azure-testexemplaren. De volgende fase wordt alleen gebruikt om andere Microsoft-productteams te bedienen. De laatste fase is bedoeld voor externe klanten. Wanneer een wijziging wordt geïmplementeerd, wordt deze om de beurt naar elk van deze fasen verplaatst en onderbroken om de status van de fase te meten. Als de wijziging geen negatieve gevolgen heeft, gaat deze naar de volgende fase. Als we een ongeldige wijziging aanbrengen in een code-integriteitsbeleid, wordt de wijziging gedetecteerd tijdens deze gefaseerde implementatie en teruggedraaid.
Reageren op incidenten
Zelfs met deze gelaagde beveiliging is het nog steeds mogelijk dat een bepaalde server in het wagenpark de juiste geautoriseerde software blokkeert en een probleem veroorzaakt dat de klant ondervindt, een van onze ergste scenario's. Onze laatste verdedigingslaag is menselijk onderzoek. Telkens wanneer code-integriteit een bestand blokkeert, wordt er een waarschuwing gegenereerd voor de technici op oproep om dit te onderzoeken. Met de waarschuwing kunnen we beveiligingsonderzoeken starten en ingrijpen, ongeacht of het probleem een indicator is van een echte aanval, een fout-positieve of een andere situatie die de klant beïnvloedt. Dit minimaliseert de tijd die nodig is om problemen met code-integriteit te verhelpen.
Volgende stappen
Meer informatie over hoe Windows 10 configureerbare code-integriteit gebruikt.
Zie voor meer informatie over wat we doen om platformintegriteit en -beveiliging te stimuleren: