Azure-säkerhet för molnbaserade appar
Dricks
Det här innehållet är ett utdrag från eBook, Architecting Cloud Native .NET Applications for Azure, tillgängligt på .NET Docs eller som en kostnadsfri nedladdningsbar PDF som kan läsas offline.
Molnbaserade program kan vara både enklare och svårare att skydda än traditionella program. På nackdelen måste du skydda mindre program och ägna mer energi åt att bygga ut säkerhetsinfrastrukturen. Den heterogena karaktären hos programmeringsspråk och formatmallar i de flesta tjänstdistributioner innebär också att du måste ägna mer uppmärksamhet åt säkerhetsbulletiner från många olika leverantörer.
Å andra sidan begränsar mindre tjänster, var och en med sitt eget datalager, omfattningen för en attack. Om en angripare komprometterar ett system är det förmodligen svårare för angriparen att hoppa till ett annat system än i ett monolitiskt program. Processgränser är starka gränser. Om en databassäkerhetskopiering exponeras är skadan dessutom mer begränsad, eftersom databasen endast innehåller en delmängd data och sannolikt inte kommer att innehålla personliga data.
Hotmodellering
Oavsett om fördelarna uppväger nackdelarna med molnbaserade program måste samma holistiska säkerhetstänk följas. Säkerhet och säkert tänkande måste ingå i varje steg i utvecklings- och driftsberättelsen. När du planerar ett program ställer du frågor som:
- Vad skulle effekten av att dessa data går förlorade?
- Hur kan vi begränsa skadorna från felaktiga data som matas in i den här tjänsten?
- Vem ska ha åtkomst till dessa data?
- Finns det granskningsprinciper kring utveckling och lansering?
Alla dessa frågor är en del av en process som kallas hotmodellering. Den här processen försöker besvara frågan om vilka hot det finns mot systemet, hur sannolikt hoten är och den potentiella skadan från dem.
När listan över hot har upprättats måste du bestämma om de är värda att mildra. Ibland är ett hot så osannolikt och dyrt att planera för att det inte är värt att spendera energi på det. Vissa aktörer på tillståndsnivå kan till exempel mata in ändringar i utformningen av en process som används av miljontals enheter. I stället för att köra en viss kod i Ring 3 körs koden i Ring 0. Den här processen möjliggör en exploatering som kan kringgå hypervisor-programmet och köra attackkoden på datorer utan operativsystem, vilket möjliggör attacker på alla virtuella datorer som körs på maskinvaran.
De ändrade processorerna är svåra att upptäcka utan mikroskop och avancerad kunskap om processorns kiseldesign. Det här scenariot kommer sannolikt inte att inträffa och dyrt att minimera, så förmodligen skulle ingen hotmodell rekommendera att skapa exploateringsskydd för det.
Mer sannolika hot, till exempel brutna åtkomstkontroller som tillåter Id inkrementella attacker (ersätter Id=2 med Id=3 i URL:en) eller SQL-inmatning, är mer attraktiva att bygga skydd mot. Åtgärderna för dessa hot är ganska rimliga för att bygga och förhindra pinsamma säkerhetshål som smutskastar företagets rykte.
Princip om minsta privilegium
En av grundidéerna inom datorsäkerhet är POLP (Principle of Least Privilege). Det är faktiskt en grundläggande idé i de flesta former av säkerhet, oavsett om det är digitalt eller fysiskt. Kort sagt är principen att alla användare eller processer ska ha minsta möjliga antal behörigheter för att utföra sin uppgift.
Tänk till exempel på kassörerna på en bank: att komma åt kassaskåpet är en ovanlig aktivitet. Så den genomsnittliga kassören kan inte öppna kassaskåpet själva. För att få åtkomst måste de eskalera sin begäran via en bankchef som utför ytterligare säkerhetskontroller.
I ett datorsystem är ett fantastiskt exempel rättigheterna för en användare som ansluter till en databas. I många fall används ett enskilt användarkonto för att både skapa databasstrukturen och köra programmet. Förutom i extrema fall behöver kontot som kör programmet inte möjlighet att uppdatera schemainformation. Det bör finnas flera konton som ger olika behörighetsnivåer. Programmet bör endast använda behörighetsnivån som ger läs- och skrivbehörighet till data i tabellerna. Den här typen av skydd skulle eliminera attacker som syftar till att släppa databastabeller eller införa skadliga utlösare.
Nästan alla delar av att skapa ett molnbaserat program kan ha nytta av att komma ihåg principen om minsta behörighet. Du kan hitta den när du konfigurerar brandväggar, nätverkssäkerhetsgrupper, roller och omfång i rollbaserad åtkomstkontroll (RBAC).
Intrångstest
I takt med att programmen blir mer komplicerade ökar antalet attackvektorer i en alarmerande takt. Hotmodellering är bristfällig eftersom den tenderar att köras av samma personer som bygger systemet. På samma sätt som många utvecklare har problem med att föreställa sig användarinteraktioner och sedan skapa oanvändbara användargränssnitt har de flesta utvecklare svårt att se varje attackvektor. Det är också möjligt att utvecklarna som bygger systemet inte är väl bevandrade i attackmetoder och missar något avgörande.
Intrångstestning eller "penntestning" innebär att man tar in externa aktörer för att försöka attackera systemet. Dessa angripare kan vara ett externt konsultföretag eller andra utvecklare med goda säkerhetskunskaper från en annan del av verksamheten. De får carte blanche att försöka omstörta systemet. Ofta hittar de omfattande säkerhetshål som behöver korrigeras. Ibland blir attackvektorn något helt oväntat som att utnyttja en nätfiskeattack mot VD:n.
Själva Azure genomgår ständigt attacker från ett team av hackare inom Microsoft. Under årens lopp har de varit de första som hittat dussintals potentiellt katastrofala attackvektorer och stängt dem innan de kan utnyttjas externt. Ju mer frestande ett mål är, desto mer sannolikt är det att eviga aktörer kommer att försöka utnyttja det och det finns några mål i världen som är mer frestande än Azure.
Övervakning
Om en angripare försöker penetrera ett program bör det finnas en varning om det. Ofta kan attacker upptäckas genom att undersöka loggarna från tjänster. Attacker lämnar telltale-tecken som kan upptäckas innan de lyckas. En angripare som till exempel försöker gissa ett lösenord gör många begäranden till ett inloggningssystem. Övervakning runt inloggningssystemet kan identifiera konstiga mönster som ligger i linje med det typiska åtkomstmönstret. Den här övervakningen kan omvandlas till en avisering som i sin tur kan varna en driftsperson för att aktivera någon form av motåtgärd. Ett mycket moget övervakningssystem kan till och med vidta åtgärder baserat på dessa avvikelser och proaktivt lägga till regler för att blockera begäranden eller begränsa svar.
Skydda bygget
En plats där säkerheten ofta förbises handlar om byggprocessen. Bygget bör inte bara köra säkerhetskontroller, till exempel genomsökning efter osäker kod eller incheckade autentiseringsuppgifter, utan själva bygget bör vara säkert. Om byggservern komprometteras ger den en fantastisk vektor för att introducera godtycklig kod i produkten.
Anta att en angripare vill stjäla lösenorden för personer som loggar in på en webbapp. De kan introducera ett byggsteg som ändrar den utcheckade koden för att spegla alla inloggningsbegäranden till en annan server. Nästa gång koden går igenom bygget uppdateras den tyst. Sårbarhetsgenomsökningen av källkoden fångar inte den här sårbarheten eftersom den körs före bygget. På samma sätt kommer ingen att fånga den i en kodgranskning eftersom byggstegen finns på byggservern. Den utnyttjade koden går till produktion där den kan hämta lösenord. Det finns förmodligen ingen granskningslogg för ändringarna i byggprocessen, eller åtminstone ingen som övervakar granskningen.
Det här scenariot är ett perfekt exempel på ett till synes lågt värdemål som kan användas för att bryta sig in i systemet. När en angripare bryter mot systemets perimeter kan de börja arbeta med att hitta sätt att höja sina behörigheter så att de kan orsaka verklig skada var de vill.
Skapa säker kod
.NET Framework är redan ett ganska säkert ramverk. Det undviker några av fallgroparna med ohanterad kod, till exempel att gå från matrisernas ändar. Arbete görs aktivt för att åtgärda säkerhetshål när de upptäcks. Det finns till och med ett bug bounty-program som betalar forskare för att hitta problem i ramverket och rapportera dem istället för att utnyttja dem.
Det finns många sätt att göra .NET-kod säkrare. Att följa riktlinjer som riktlinjerna för säker kodning för .NET är ett rimligt steg att vidta för att se till att koden är säker från grunden. OWASP top 10 är en annan ovärderlig guide för att skapa säker kod.
Byggprocessen är ett bra ställe att använda genomsökningsverktyg för att identifiera problem i källkoden innan de hamnar i produktion. De flesta projekt har beroenden för vissa andra paket. Ett verktyg som kan söka efter inaktuella paket får problem i en nattlig version. Även när du skapar Docker-avbildningar är det användbart att kontrollera och se till att basavbildningen inte har kända säkerhetsrisker. En annan sak att kontrollera är att ingen har checkat in autentiseringsuppgifter av misstag.
Inbyggd säkerhet
Azure är utformat för att balansera användbarhet och säkerhet för de flesta användare. Olika användare kommer att ha olika säkerhetskrav, så de måste finjustera sin metod för molnsäkerhet. Microsoft publicerar en hel del säkerhetsinformation i Säkerhetscenter. Den här resursen bör vara det första stoppet för de proffs som är intresserade av att förstå hur de inbyggda teknikerna för angreppsreducering fungerar.
I Azure-portalen är Azure Advisor ett system som ständigt genomsöker en miljö och ger rekommendationer. Vissa av dessa rekommendationer är utformade för att spara pengar för användarna, men andra är utformade för att identifiera potentiellt osäkra konfigurationer, till exempel att ha en lagringscontainer öppen för världen och inte skyddas av ett virtuellt nätverk.
Azure-nätverksinfrastruktur
I en lokal distributionsmiljö ägnar sig mycket energi åt att konfigurera nätverk. Att konfigurera routrar, växlar och sådant är komplicerat arbete. Nätverk gör det möjligt för vissa resurser att prata med andra resurser och förhindra åtkomst i vissa fall. En regel för frekventa nätverk är att begränsa åtkomsten till produktionsmiljön från utvecklingsmiljön på off chans att en halvutvecklad kodbit körs snett och tar bort en mängd data.
De flesta PaaS Azure-resurser har bara den mest grundläggande och tillåtande nätverkskonfigurationen. Till exempel kan vem som helst på Internet komma åt en apptjänst. Nya SQL Server-instanser är vanligtvis begränsade, så att externa parter inte kan komma åt dem, men IP-adressintervallen som används av Själva Azure tillåts via. Så även om SQL-servern är skyddad från externa hot behöver en angripare bara konfigurera ett Azure-brohuvud där de kan starta attacker mot alla SQL-instanser i Azure.
Som tur är kan de flesta Azure-resurser placeras i ett virtuellt Azure-nätverk som tillåter detaljerad åtkomstkontroll. På samma sätt som lokala nätverk etablerar privata nätverk som skyddas från omvärlden är virtuella nätverk öar med privata IP-adresser som finns i Azure-nätverket.
Bild 9-1. Ett virtuellt nätverk i Azure.
På samma sätt som lokala nätverk har en brandvägg som styr åtkomsten till nätverket kan du upprätta en liknande brandvägg vid gränsen för det virtuella nätverket. Som standard kan alla resurser i ett virtuellt nätverk fortfarande kommunicera med Internet. Det är bara inkommande anslutningar som kräver någon form av explicit brandväggsfel.
När nätverket har upprättats kan interna resurser som lagringskonton konfigureras för att endast tillåta åtkomst av resurser som också finns i det virtuella nätverket. Den här brandväggen ger en extra säkerhetsnivå, om nycklarna för lagringskontot skulle läcka ut, skulle angripare inte kunna ansluta till den för att utnyttja de läckta nycklarna. Det här scenariot är ett annat exempel på principen om lägsta behörighet.
Noderna i ett Azure Kubernetes-kluster kan delta i ett virtuellt nätverk precis som andra resurser som är mer inbyggda i Azure. Den här funktionen kallas Azure Container Networking Interface. I själva verket allokerar det ett undernät i det virtuella nätverket där virtuella datorer och containeravbildningar allokeras.
Att fortsätta på vägen mot att illustrera principen om minsta behörighet, inte alla resurser i ett virtuellt nätverk behöver prata med alla andra resurser. I ett program som till exempel tillhandahåller ett webb-API över ett lagringskonto och en SQL-databas är det osannolikt att databasen och lagringskontot behöver prata med varandra. All datadelning mellan dem skulle gå via webbprogrammet. Därför kan en nätverkssäkerhetsgrupp (NSG) användas för att neka trafik mellan de två tjänsterna.
En princip för att neka kommunikation mellan resurser kan vara irriterande att implementera, särskilt när du använder Azure utan trafikbegränsningar. I vissa andra moln är begreppet nätverkssäkerhetsgrupper mycket vanligare. Standardprincipen för AWS är till exempel att resurser inte kan kommunicera sinsemellan förrän de har aktiverats av regler i en NSG. Även om det är långsammare att utveckla detta ger en mer restriktiv miljö ett säkrare standardvärde. Att använda lämpliga DevOps-metoder, särskilt med Hjälp av Azure Resource Manager eller Terraform för att hantera behörigheter, kan göra det enklare att kontrollera reglerna.
Virtuella nätverk kan också vara användbara när du konfigurerar kommunikation mellan lokala resurser och molnresurser. Ett virtuellt privat nätverk kan användas för att smidigt koppla ihop de två nätverken. Med den här metoden kan du köra ett virtuellt nätverk utan någon typ av gateway för scenarier där alla användare är på plats. Det finns ett antal tekniker som kan användas för att upprätta det här nätverket. Det enklaste är att använda ett plats-till-plats-VPN som kan upprättas mellan många routrar och Azure. Trafiken krypteras och dirigeras via Internet till samma kostnad per byte som all annan trafik. För scenarier där mer bandbredd eller mer säkerhet är önskvärt erbjuder Azure en tjänst som kallas Express Route som använder en privat krets mellan ett lokalt nätverk och Azure. Det är dyrare och svårare att etablera men också säkrare.
Rollbaserad åtkomstkontroll för att begränsa åtkomsten till Azure-resurser
RBAC är ett system som tillhandahåller en identitet till program som körs i Azure. Program kan komma åt resurser med den här identiteten i stället för eller utöver att använda nycklar eller lösenord.
Säkerhetsobjekt
Den första komponenten i RBAC är ett säkerhetsobjekt. Ett säkerhetsobjekt kan vara en användare, grupp, tjänstens huvudnamn eller en hanterad identitet.
Bild 9-2. Olika typer av säkerhetsobjekt.
- Användare – Alla användare som har ett konto i Azure Active Directory är en användare.
- Grupp – En samling användare från Azure Active Directory. Som medlem i en grupp tar en användare på sig rollen för den gruppen utöver sina egna.
- Tjänstens huvudnamn – en säkerhetsidentitet under vilken tjänster eller program körs.
- Hanterad identitet – En Azure Active Directory-identitet som hanteras av Azure. Hanterade identiteter används vanligtvis när du utvecklar molnprogram som hanterar autentiseringsuppgifterna för autentisering till Azure-tjänster.
Säkerhetsobjektet kan tillämpas på de flesta resurser. Den här aspekten innebär att det är möjligt att tilldela ett säkerhetsobjekt till en container som körs i Azure Kubernetes, så att den kan komma åt hemligheter som lagras i Key Vault. En Azure-funktion kan få en behörighet som gör att den kan kommunicera med en Active Directory-instans för att verifiera en JWT för en anropande användare. När tjänsterna har aktiverats med ett huvudnamn för tjänsten kan deras behörigheter hanteras detaljerat med hjälp av roller och omfång.
Roller
Ett säkerhetsobjekt kan ta på sig många roller eller, med hjälp av en mer sartorial analogi, bära många hattar. Varje roll definierar en serie behörigheter, till exempel "Läsa meddelanden från Azure Service Bus-slutpunkten". Den effektiva behörighetsuppsättningen för ett säkerhetsobjekt är kombinationen av alla behörigheter som tilldelats till alla roller som ett säkerhetsobjekt har. Azure har ett stort antal inbyggda roller och användarna kan definiera sina egna roller.
Bild 9-3. RBAC-rolldefinitioner.
Inbyggda i Azure är också ett antal högnivåroller som ägare, deltagare, läsare och användarkontoadministratör. Med rollen Ägare kan ett säkerhetsobjekt komma åt alla resurser och tilldela behörigheter till andra. En deltagare har samma åtkomstnivå till alla resurser, men de kan inte tilldela behörigheter. En läsare kan bara visa befintliga Azure-resurser och en användarkontoadministratör kan hantera åtkomst till Azure-resurser.
Mer detaljerade inbyggda roller, till exempel DNS Zone Contributor , har rättigheter som är begränsade till en enda tjänst. Säkerhetsobjekt kan ta på sig valfritt antal roller.
Omfattningar
Roller kan tillämpas på en begränsad uppsättning resurser i Azure. Om du till exempel använder omfånget för föregående exempel på läsning från en Service Bus-kö kan du begränsa behörigheten till en enda kö: "Läsa meddelanden från Azure Service Bus-slutpunkten blah.servicebus.windows.net/queue1"
Omfånget kan vara så smalt som en enskild resurs eller så kan det tillämpas på en hel resursgrupp, prenumeration eller till och med hanteringsgrupp.
När du testar om ett säkerhetsobjekt har viss behörighet beaktas kombinationen av roll och omfång. Den här kombinationen ger en kraftfull auktoriseringsmekanism.
Neka
Tidigare var endast "tillåtna" regler tillåtna för RBAC. Det här beteendet gjorde vissa omfång komplicerade att skapa. Till exempel att ge ett säkerhetsobjekt åtkomst till alla lagringskonton förutom ett som krävs för att ge explicit behörighet till en potentiellt oändlig lista över lagringskonton. Varje gång ett nytt lagringskonto skapas måste det läggas till i den här listan med konton. Detta lade till hanteringskostnader som verkligen inte var önskvärda.
Neka regler har företräde framför tillåtna regler. Nu kan samma "tillåt alla utom ett"-omfång representeras som två regler "tillåt alla" och "neka den här specifika". Neka regler underlättar inte bara hanteringen utan tillåter resurser som är extra säkra genom att neka åtkomst till alla.
Kontrollera åtkomst
Som du kan föreställa dig kan ett stort antal roller och omfång göra det ganska svårt att räkna ut den effektiva behörigheten för ett huvudnamn för tjänsten. Att stapla förneka regler ovanpå detta tjänar bara till att öka komplexiteten. Lyckligtvis finns det en behörighetskalkylator som kan visa de gällande behörigheterna för alla tjänsthuvudnamn. Den finns vanligtvis under fliken IAM i portalen, enligt bild 9–3.
Bild 9-4. Behörighetskalkylator för en apptjänst.
Skydda hemligheter
Lösenord och certifikat är en vanlig attackvektor för angripare. Maskinvara med lösenordssprickor kan utföra en råstyrkeattack och försöka gissa miljarder lösenord per sekund. Därför är det viktigt att lösenorden som används för att komma åt resurser är starka, med många olika tecken. Dessa lösenord är exakt den typ av lösenord som är nästan omöjliga att komma ihåg. Lyckligtvis behöver lösenorden i Azure faktiskt inte vara kända av någon människa.
Många säkerhetsexperter rekommenderar att du använder en lösenordshanterare för att behålla dina egna lösenord. Även om det centraliserar dina lösenord på en plats, tillåter det också att du använder mycket komplexa lösenord och ser till att de är unika för varje konto. Samma system finns i Azure: ett centralt arkiv för hemligheter.
Azure Key Vault
Azure Key Vault tillhandahåller en central plats för att lagra lösenord för saker som databaser, API-nycklar och certifikat. När en hemlighet har angetts i valvet visas den aldrig igen och kommandona för att extrahera och visa den är målmedvetet komplicerade. Informationen i kassaskåpet skyddas med antingen programvarukryptering eller FIPS 140-2 Level 2-verifierade maskinvarusäkerhetsmoduler.
Åtkomst till nyckelvalvet tillhandahålls via RBACs, vilket innebär att inte bara alla användare kan komma åt informationen i valvet. Anta att ett webbprogram vill komma åt databasen anslutningssträng lagras i Azure Key Vault. För att få åtkomst måste program köras med hjälp av ett huvudnamn för tjänsten. Under den här rollen kan de läsa hemligheterna från kassaskåpet. Det finns ett antal olika säkerhetsinställningar som ytterligare kan begränsa den åtkomst som ett program har till valvet, så att det inte kan uppdatera hemligheter utan bara läsa dem.
Åtkomst till nyckelvalvet kan övervakas för att säkerställa att endast de förväntade programmen kommer åt valvet. Loggarna kan integreras i Azure Monitor igen, vilket låser upp möjligheten att konfigurera aviseringar när oväntade förhållanden påträffas.
Kubernetes
Inom Kubernetes finns det en liknande tjänst för att underhålla små delar av hemlig information. Kubernetes-hemligheter kan anges via den typiska kubectl körbara filen.
Att skapa en hemlighet är lika enkelt som att hitta base64-versionen av de värden som ska lagras:
echo -n 'admin' | base64
YWRtaW4=
echo -n '1f2d1e2e67df' | base64
MWYyZDFlMmU2N2Rm
Lägg sedan till den i en hemlighetsfil med namnet secret.yml till exempel som ser ut ungefär som i följande exempel:
apiVersion: v1
kind: Secret
metadata:
name: mysecret
type: Opaque
data:
username: YWRtaW4=
password: MWYyZDFlMmU2N2Rm
Slutligen kan den här filen läsas in i Kubernetes genom att köra följande kommando:
kubectl apply -f ./secret.yaml
Dessa hemligheter kan sedan monteras i volymer eller exponeras för containerprocesser via miljövariabler. Metoden för tolvfaktorsappar för att skapa program föreslår att du använder den lägsta gemensamma nämnaren för att överföra inställningar till ett program. Miljövariabler är den minsta gemensamma nämnaren eftersom de stöds oavsett operativsystem eller program.
Ett alternativ för att använda de inbyggda Kubernetes-hemligheterna är att komma åt hemligheterna i Azure Key Vault inifrån Kubernetes. Det enklaste sättet att göra detta är att tilldela en RBAC-roll till containern som vill läsa in hemligheter. Programmet kan sedan använda Azure Key Vault-API:erna för att komma åt hemligheterna. Den här metoden kräver dock ändringar i koden och följer inte mönstret för att använda miljövariabler. I stället går det att mata in värden i en container. Den här metoden är faktiskt säkrare än att använda Kubernetes-hemligheterna direkt, eftersom de kan nås av användare i klustret.
Kryptering under överföring och i vila
Att skydda data är viktigt oavsett om det är på disk eller överföring mellan olika tjänster. Det mest effektiva sättet att hindra data från att läcka är att kryptera dem till ett format som inte är lätt att läsa av andra. Azure har stöd för en mängd olika krypteringsalternativ.
På väg
Det finns flera sätt att kryptera trafik i nätverket i Azure. Åtkomsten till Azure-tjänster görs vanligtvis via anslutningar som använder TLS (Transport Layer Security). Till exempel kräver alla anslutningar till Azure-API:erna TLS-anslutningar. På samma sätt kan anslutningar till slutpunkter i Azure Storage begränsas till att endast fungera via TLS-krypterade anslutningar.
TLS är ett komplicerat protokoll och att bara veta att anslutningen använder TLS räcker inte för att garantera säkerheten. TLS 1.0 är till exempel kroniskt osäkert och TLS 1.1 är inte mycket bättre. Även i versionerna av TLS finns det olika inställningar som kan göra anslutningarna enklare att dekryptera. Det bästa sättet är att kontrollera och se om serveranslutningen använder uppdaterade och väl konfigurerade protokoll.
Den här kontrollen kan göras av en extern tjänst, till exempel SSL Labs SSL Server Test. En testkörning mot en typisk Azure-slutpunkt, i det här fallet en Service Bus-slutpunkt, ger en nästan perfekt poäng av A.
Även tjänster som Azure SQL-databaser använder TLS-kryptering för att hålla data dolda. Det intressanta med att kryptera data under överföring med TLS är att det inte är möjligt, inte ens för Microsoft, att lyssna på anslutningen mellan datorer som kör TLS. Detta bör ge tröst för företag som är oroliga för att deras data kan vara i fara från Microsoft korrekt eller till och med en statlig aktör med mer resurser än standardanfallaren.
Bild 9-5. SSL-labbrapport som visar poängen A för en Service Bus-slutpunkt.
Även om den här krypteringsnivån inte räcker hela tiden bör den inge förtroende för att Azure TLS-anslutningar är ganska säkra. Azure fortsätter att utveckla sina säkerhetsstandarder när krypteringen förbättras. Det är trevligt att veta att det finns någon som tittar på säkerhetsstandarderna och uppdaterar Azure när de förbättras.
I vila
I alla program finns det ett antal platser där data vilar på disken. Själva programkoden läses in från någon lagringsmekanism. De flesta program använder också någon form av databas, till exempel SQL Server, Cosmos DB eller till och med den otroligt priseffektiva tabelllagringen. Alla dessa databaser använder starkt krypterad lagring för att säkerställa att ingen annan än de program som har rätt behörighet kan läsa dina data. Inte ens systemoperatorerna kan läsa data som har krypterats. Så att kunderna kan vara säkra på att deras hemliga information förblir hemlig.
Lagring
Grunden för stora delar av Azure är Azure Storage-motorn. Virtuella datordiskar monteras ovanpå Azure Storage. Azure Kubernetes Service körs på virtuella datorer som själva finns i Azure Storage. Även serverlösa tekniker, till exempel Azure Functions Apps och Azure Container Instances, får slut på diskar som ingår i Azure Storage.
Om Azure Storage är väl krypterat ger det en grund för att de flesta andra också ska krypteras. Azure Storage krypteras med FIPS 140-2-kompatibel256-bitars AES. Detta är en väl ansedd krypteringsteknik som har varit föremål för omfattande akademisk granskning under de senaste 20 åren. För närvarande finns det ingen känd praktisk attack som gör att någon utan kunskap om nyckeln kan läsa data som krypterats av AES.
Som standard hanteras nycklarna som används för att kryptera Azure Storage av Microsoft. Det finns omfattande skydd för att förhindra skadlig åtkomst till dessa nycklar. Användare med särskilda krypteringskrav kan dock också tillhandahålla sina egna lagringsnycklar som hanteras i Azure Key Vault. Dessa nycklar kan återkallas när som helst, vilket i praktiken skulle göra innehållet i lagringskontot otillgängligt.
Virtuella datorer använder krypterad lagring, men det är möjligt att tillhandahålla ett annat krypteringslager med hjälp av tekniker som BitLocker i Windows eller DM-Crypt i Linux. Dessa tekniker innebär att även om diskbilden läckte ut från lagringen skulle det förbli nästan omöjligt att läsa den.
Azure SQL
Databaser som finns i Azure SQL använder en teknik som kallas transparent datakryptering (TDE) för att säkerställa att data förblir krypterade. Det är aktiverat som standard på alla nyligen skapade SQL-databaser, men måste aktiveras manuellt för äldre databaser. TDE kör realtidskryptering och dekryptering av inte bara databasen, utan även säkerhetskopieringar och transaktionsloggar.
Krypteringsparametrarna lagras i master databasen och läss vid start in i minnet för de återstående åtgärderna. Det innebär att master databasen måste förbli okrypterad. Den faktiska nyckeln hanteras av Microsoft. Användare med krävande säkerhetskrav kan dock tillhandahålla sin egen nyckel i Key Vault på ungefär samma sätt som för Azure Storage. Key Vault tillhandahåller tjänster som nyckelrotation och återkallande.
Den "transparenta" delen av TDS kommer från det faktum att det inte behövs några klientändringar för att använda en krypterad databas. Även om den här metoden ger god säkerhet räcker det med att läcka databaslösenordet för att användarna ska kunna dekryptera data. Det finns en annan metod som krypterar enskilda kolumner eller tabeller i en databas. Always Encrypted ser till att krypterade data inte visas i oformaterad text i databasen.
För att konfigurera den här krypteringsnivån måste du köra en guide i SQL Server Management Studio för att välja vilken typ av kryptering som ska användas och var i Key Vault du vill lagra de associerade nycklarna.
Bild 9-6. Välja kolumner i en tabell som ska krypteras med Always Encrypted.
Klientprogram som läser information från dessa krypterade kolumner måste göra särskilda justeringar för att läsa krypterade data. Anslut ionssträngar måste uppdateras med Column Encryption Setting=Enabled och klientens autentiseringsuppgifter måste hämtas från Key Vault. SQL Server-klienten måste sedan vara förberedd med kolumnkrypteringsnycklarna. När det är klart använder de återstående åtgärderna standardgränssnitten till SQL Client. Det betyder att verktyg som Dapper och Entity Framework, som bygger på SQL Client, fortsätter att fungera utan ändringar. Always Encrypted kanske ännu inte är tillgängligt för varje SQL Server-drivrutin på alla språk.
Kombinationen av TDE och Always Encrypted, som båda kan användas med klientspecifika nycklar, säkerställer att även de mest krävande krypteringskraven stöds.
Cosmos DB
Cosmos DB är den senaste databasen som tillhandahålls av Microsoft i Azure. Det har byggts från grunden med säkerhet och kryptografi i åtanke. AES-256-bitars kryptering är standard för alla Cosmos DB-databaser och kan inte inaktiveras. Tillsammans med TLS 1.2-kravet för kommunikation krypteras hela lagringslösningen.
Bild 9-7. Datakrypteringsflödet i Cosmos DB.
Även om Cosmos DB inte tillhandahåller för att tillhandahålla kundkrypteringsnycklar, har teamet utfört ett betydande arbete för att säkerställa att det förblir PCI-DSS-kompatibelt utan det. Cosmos DB stöder inte heller någon typ av kryptering med en enskild kolumn som liknar Azure SQL:s Always Encrypted ännu.
Att hålla sig säker
Azure har alla verktyg som krävs för att släppa en mycket säker produkt. En kedja är dock bara lika stark som den svagaste länken. Om de program som distribueras ovanpå Azure inte utvecklas med rätt säkerhetstänk och bra säkerhetsgranskningar blir de den svaga länken i kedjan. Det finns många bra verktyg för statisk analys, krypteringsbibliotek och säkerhetsrutiner som kan användas för att säkerställa att programvaran som installeras på Azure är lika säker som Själva Azure. Exempel är statiska analysverktyg, krypteringsbibliotek och säkerhetsrutiner.
