Integriteit van platformcode
Een belangrijke uitdaging bij het uitvoeren van een complex systeem zoals Microsoft Azure is ervoor zorgen dat alleen geautoriseerde software wordt uitgevoerd in het systeem. Niet-geautoriseerde software biedt verschillende risico's 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 halen
- Kwaliteitsrisico van extern ontwikkelde software, die mogelijk niet voldoet aan de operationele vereisten van het bedrijf
In Azure hebben we dezelfde uitdaging en hebben we veel complexiteit. We hebben duizenden servers waarop software wordt uitgevoerd en onderhouden door duizenden technici. Dit presenteert een groot aanvalsoppervlak dat niet alleen kan worden beheerd via bedrijfsprocessen.
Een autorisatiepoort toevoegen
Azure maakt gebruik van een uitgebreid technisch proces dat poorten implementeert op de beveiliging, naleving en kwaliteit van de software die we implementeren. Dit proces omvat toegangsbeheer voor broncode, het uitvoeren van peercodebeoordelingen, het uitvoeren van statische analyses voor beveiligingsproblemen, het volgen van de SDL (Security Development Lifecycle) 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 deze garantie te bereiken.
Code-integriteit als autorisatiepoort
Code-integriteit is een service op kernelniveau die beschikbaar werd 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 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 de opgegeven SHA256-hashes. De kernel dwingt dit beleid af door de uitvoering te blokkeren van alles wat niet voldoet aan het ingestelde beleid.
Een probleem met een code-integriteitsbeleid is dat, tenzij het beleid perfect correct is, kritieke software in productie kan blokkeren en een storing kan veroorzaken. Gezien deze zorg kan men vragen 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 beveiliging en een kwaadwillende persoon die een permanente voet in uw vloot krijgt. In Azure hebben we aanzienlijk geïnvesteerd om elk risico van code-integriteit te beheren dat bijdraagt aan een klant die de storing beïnvloedt.
Bouwproces
Zoals hierboven is 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 het met behulp van een Azure-buildcertificaat. Het certificaat geeft aan dat de build het hele wijzigingsbeheerproces heeft doorlopen. De laatste test die door de build wordt uitgevoerd, heet Code Signature Validation (CSV). CSV bevestigt dat de zojuist gebouwde binaire bestanden voldoen aan het code-integriteitsbeleid voordat we implementeren in productie. Dit geeft ons een hoge mate van vertrouwen dat we geen klant veroorzaken die een storing veroorzaakt vanwege onjuist ondertekende binaire bestanden. Als csv een probleem vindt, worden de build-einden en de relevante technici gepaginad 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 productie een code-integriteitsstoring veroorzaakt. Een computer kan bijvoorbeeld een oude versie van het code-integriteitsbeleid uitvoeren of heeft mogelijk een slechte status die fout-positieven produceert in code-integriteit. (Op Azure-schaal hebben we alles gezien.) Daarom moeten we blijven beschermen tegen het risico van een storing tijdens de implementatie.
Alle wijzigingen in Azure zijn vereist om te implementeren 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 dient klanten van derden. Wanneer een wijziging wordt geïmplementeerd, wordt deze naar elk van deze fasen verplaatst en wordt gepauzeerd om de status van de fase te meten. Als de wijziging geen negatieve invloed heeft, wordt deze verplaatst 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 sommige servers in de vloot correct geautoriseerde software kunnen blokkeren en een klantprobleem kunnen veroorzaken, een van onze slechtste scenario's. Onze laatste verdedigingslaag is menselijk onderzoek. Telkens wanneer code-integriteit een bestand blokkeert, wordt er een waarschuwing weergegeven voor de aanroeptechnici die moeten worden onderzocht. Met de waarschuwing kunnen we beveiligingsonderzoeken starten en ingrijpen, of het probleem een indicator is van een echte aanval, een fout-positief of een andere situatie die van invloed is op de klant. Dit minimaliseert de tijd die nodig is om eventuele problemen met betrekking tot code-integriteit te beperken.
Volgende stappen
Zie voor meer informatie over wat we doen om platformintegriteit en -beveiliging te stimuleren: