Hur vi skyddar dina data i Azure AD

Hej!

Med alla intrång i molnidentitetstjänster under de senaste åren får vi många frågor om hur vi skyddar kunddata. Så i dagens blogginlägg fördjupar vi oss i hur vi skyddar kunddata i Azure AD.

Säkerhet i datacenter och tjänster

Vi börjar med våra datacenter. Först och främst måste all personal på Microsofts datacenter genomgå en bakgrundskontroll. All åtkomst till våra datacenter är strängt reglerad och alla ingångar och utgångar övervakas. I dessa datacenter är de kritiska Azure AD-tjänsterna där kunddata lagras placerade i särskilda låsta rack – deras fysiska åtkomst är mycket begränsad och kameraövervakas dygnet runt. Om en av dessa servrar tas ur drift förstörs dessutom alla diskar logiskt och fysiskt för att undvika dataläckage.

Sedan begränsar vi antalet personer som har åtkomst till Azure AD-tjänsterna, och även de som har behörighet arbetar dagligen utan denna när de loggar in. När de väl behöver behörighet att komma åt tjänsten måste de klara multifaktorautentisering med ett smartkort för att bekräfta sin identitet och skicka en begäran. När begäran har godkänts etableras användarnas behörighet ”just-in-time”. Dessa behörigheter tas också bort automatiskt efter en viss tid och de som behöver mer tid måste gå igenom processen med begäran och godkännande igen.

När behörigheterna har beviljats utförs all åtkomst med en hanterad arbetsstation för administratörer (i enlighet med den publicerade vägledningen om arbetsstationer för privilegierad åtkomst). Detta krävs enligt princip och efterlevnad övervakas noga. På dessa arbetsstationer används en fast avbildning och all programvara på datorn är fullständigt hanterad. För att minimera det utsatta området för risker tillåts endast utvalda aktiviteter, och användarna kan inte oavsiktligt kringgå arbetsstationens design eftersom de inte har administratörsbehörighet på den. För att skydda arbetsstationerna ytterligare måste all åtkomst ske med ett smartkort och åtkomst till dem är begränsad till en viss uppsättning användare.

Slutligen har vi några få (färre än fem) ”break glass”-konton. Dessa konton får endast användas i nödsituationer och skyddas av ”break glass”-procedurer i flera steg. All användning av dessa konton övervakas och utlöser varningar.

Hotidentifiering

Det finns flera automatiska kontroller som vi genomför regelbundet med några minuters mellanrum för att säkerställa att allt fungerar som väntat, även när vi lägger till nya funktioner som våra kunder efterfrågat:

• Intrångsidentifiering: Vi söker efter mönster som tyder på intrång. Vi lägger regelbundet till i den här uppsättningen identifieringar. Vi använder också automatiserade tester som utlöser dessa mönster, så vi kontrollerar även om vår logik för intrångsidentifiering fungerar som den ska!
  
• Penetrationstester: Dessa tester körs hela tiden. De försöker göra allt möjligt för att kompromettera vår tjänst, och vi förväntar oss att testerna ska misslyckas hela tiden. Om de lyckas vet vi att något är fel och kan åtgärda det direkt.
  
• Granskning: All administrativ aktivitet loggas. All aktivitet som inte är förväntad (till exempel att en administratör skapar konton med behörighet) utlöser varningar som leder till att vi gör en noggrann inspektion av åtgärden för att säkerställa att den inte är avvikande.
  

Sa vi förresten att vi krypterar alla dina data i Azure AD? För det gör vi – vi använder BitLocker för att kryptera alla vilande Azure AD-identitetsdata. Under överföring då? Det gör vi också! Alla Azure AD-API:er är webbaserade och använder SSL via HTTPS för att kryptera data. Alla Azure AD-servrar är konfigurerade att använda TLS 1.2. Vi tillåter inkommande anslutningar via TLS 1.1 och 1.0 för att erbjuda stöd för externa klienter. Vi nekar uttryckligen anslutningar via alla äldre versioner av SSL, inklusive SSL 3.0 och 2.0. Åtkomst till information begränsas med hjälp av tokenbaserad auktorisering och varje klients data är endast tillgängliga för konton som tillåts inom den klienten. För våra interna API:er gäller dessutom det ytterligare kravet att använda klient/server-SSL-autentisering för betrodda certifikat och utgivningskedjor.

En sista sak

Azure AD levereras på två sätt, och i det här inlägget beskrivs säkerhet och kryptering för den offentliga tjänsten som levereras och drivs av Microsoft. Om du har liknande frågor om våra nationella molninstanser som drivs av betrodda partner får du gärna kontakta ditt kontoteam.

(Obs! Som en enkel tumregel beskriver det här inlägget hur vi skyddar och krypterar dina data om du hanterar eller ansluter till dina Microsoft Online-tjänster via URL:er som slutar med .com.)

Säkerheten för dina data har högsta prioritet för oss och vi tar den på STORT allvar. Jag hoppas du tyckte att den här översikten över våra protokoll för datakryptering och -säkerhet var betryggande och användbar.

Vänliga hälsningar,

Alex Simons (Twitter: @Alex_A_Simons)

Chef för programhantering

Microsoft Identity Division

[uppdaterades 2017-10-03 med specifik versionsinformation om vår användning av TLS och SSL]