Slik sikrer vi dataene dine i Azure AD

Heisann!

Med alle bruddene de siste årene på skyidentitetstjenester får vi mange spørsmål om hvordan vi sikrer kundedata. Dagens blogg er derfor et dypdykk i detaljene om hvordan vi beskytter kundedata i Azure AD.

Datasenter- og tjenestesikkerhet

Vi starter med datasentrene. For det første må alle Microsofts datasenteransatte bestå en bakgrunnssjekk. All tilgang til datasentrene våre er strengt regulert, og hver eneste inngang og utgang overvåkes. Innenfor disse datasentrene er de kritiske Azure AD-tjenestene som lagrer kundedata, plassert i spesielle låste hyller – fysisk tilgang til disse er svært begrenset og kameraovervåket 24 timer i døgnet. Og hvis én av disse serverne deaktiveres, destrueres alle diskene logisk og fysisk for å unngå datalekkasje.

Deretter begrenser vi antallet personer som kan få tilgang til Azure AD-tjenestene, og til og med de som har tilgangsrettigheter, fungerer uten disse rettighetene til daglig når de logger på. Når de har behov for tilgang til tjeneste, må de passere en godkjenningsutfordring med flere faktorer ved hjelp av et smartkort for å bekrefte identiteten sin og sende inn en forespørsel. Når forespørselen er godkjent, gis brukerrettighetene «akkurat i tide». Disse rettighetene fjernes også automatisk etter en fastsatt tidsperiode, og alle som trenger mer tid, må gå gjennom prosessen med forespørsel og godkjenning på nytt.

Når disse rettighetene er gitt, utføres all tilgang ved hjelp av en administrert admin-arbeidsstasjon (i samsvar med publisert veiledning for Privileged Access Workstation). Dette kreves ved policy, og overholdelsen overvåkes nøye. Disse arbeidsstasjonene bruker et fast bilde, og all programvare på maskinen administreres fullt ut. Slik at overflateområdet for risiko blir minst mulig, tillates bare utvalgte aktiviteter, og brukere kan ikke utilsiktet omgå utformingen av admin-arbeidsstasjonen, siden de ikke har administratorrettighetene på boksen. Arbeidsstasjonene får ekstra beskyttelse ved at all tilgang må gjøres med et smartkort, og tilgang til hver stasjon er begrenset til et bestemt sett med brukere.

Til slutt har vi et lite antall (mindre enn fem) «knus glasset»-kontoer som vi opprettholder. Disse kontoene er utelukkende til nødbruk, og de er sikret av «knus glasset»-prosedyrer med flere trinn. All bruk av disse kontoene overvåkes og utløser varsler.

Oppdaging av trusler

Vi har flere automatiske kontroller som vi utfører regelmessig, med få minutters mellomrom, for å sikre at ting fungerer som forventet, også når vi legger til ny funksjonalitet som kreves av kundene våre:

• Oppdaging av brudd: Vi ser etter mønstre som tilsier brudd. Vi legger stadig til dette settet med oppdagelser. Vi bruker også automatiske tester som utløser disse mønstrene, slik at vi også sjekker om logikken vår for oppdaging av brudd fungerer riktig.
  
• Penetreringstester: Disse testene kjøres hele tiden. Disse testene forsøker å gjøre alt mulig for å kompromittere tjenesten vår, og vi forventer at disse testene mislykkes hele tiden. Hvis de lykkes, vet vi at noe er galt, og vi kan rette det opp med én gang.
  
• Revisjon: All administrativ aktivitet loggføres. All aktivitet som ikke er forventet (for eksempel at en administrator oppretter kontoer med rettigheter), gjør at det utløses varsler slik at vi kan utføre en grundig inspeksjon av den handlingen for å være sikker på at den ikke er unormal.
  

Og sa vi at vi krypterer alle dataene dine i Azure AD? Ja, det gjør vi – vi bruker BitLocker til å kryptere alle inaktive Azure AD-identitetsdata. Hva med data som transporteres? Det gjør vi også! Alle Azure AD-API-er er nettbaserte og bruker SSL gjennom HTTPS til å kryptere dataene. Alle Azure AD-servere er konfigurert til å bruke TLS 1.2. Vi tillater at innkommende tilkoblinger over TLS 1.1 og 1.0 støtter eksterne klienter. Vi avviser uttrykkelig alle tilkoblinger over alle eldre versjoner av SSL, inkludert SSL 3.0 og 2.0. Tilgang til informasjon er begrenset gjennom tokenbasert godkjenning, og hver tenants data er bare tilgjengelig for kontoer med tillatelse i den tenanten. I tillegg har våre interne API-er et tilleggskrav om å bruke godkjenning for SSL-klient/server på klarerte sertifikater og utstedelseskjeder.

En ting til

Azure AD leveres på to måter, og dette innlegget beskriver sikkerhet og kryptering for den offentlige tjenesten som leveres og drives av Microsoft. For lignende spørsmål om de nasjonale skyforekomstene våre som er drevet av klarerte samarbeidspartnere, er du velkommen til å henvende deg til kontoteamet ditt.

(Obs! En enkel tommelfingerregel: Hvis du administrerer eller får tilgang til Microsoft Online-tjenestene dine gjennom nettadresser som slutter på .com, vil dette innlegget beskrive hvordan vi beskytter og krypterer dataene dine.)

Sikkerheten for dataene dine er vår høyeste prioritet, og det tar vi SVÆRT alvorlig. Jeg håper du synes denne oversikten av datakryptering og sikkerhetsprotokoll er beroligende og nyttig.

Vennlig hilsen

Alex Simons (@Twitter: @Alex_A_Simons)

Direktør for programstyring

Microsoft Identity Division

[oppdatert 03.10.2017 for å legge til spesifikk versjonsinformasjon om bruken vår av TLS og SSL]