Hoe we je data beveiligen in Azure AD

Beste mensen,

Door alle gegevenslekken bij identiteitsservices in de cloud in de afgelopen jaren krijgen we heel veel vragen over hoe wij de gegevens van onze klanten beveiligen. In de blog van vandaag ga ik daarom bespreken hoe we klantgegevens beschermen in Azure AD.

Beveiliging van datacenters en services

Laten we beginnen met onze datacenters. Ten eerste krijgen alle medewerkers van een datacenter van Microsoft een antecedentenonderzoek voordat ze worden aangenomen. Alle toegang tot onze datacenters is aan strenge regels gebonden en iedereen die het gebouw betreedt of verlaat wordt gecontroleerd en geregistreerd. De kritieke Azure AD-services die klantgegevens opslaan, bevinden zich binnen deze datacenters op servers in speciale afgesloten rekken. De toegang tot deze rekken is fysiek beveiligd en er is 24 uur per dag camerabewaking. Als een van deze servers buiten gebruik wordt gesteld, worden alle schijven logisch en fysiek vernietigd om gegevenslekken te voorkomen.

Daarnaast beperken we het aantal personen dat toegang heeft tot de Azure AD-services, en zelfs de medewerkers met toegangsmachtigingen krijgen deze niet automatisch toegewezen wanneer ze inloggen. Wanneer ze bevoegdheden nodig hebben voor toegang tot de service, moeten ze met behulp van een smartcard en meervoudige verificatie hun identiteit bevestigen en een aanvraag indienen. Als de aanvraag is goedgekeurd, worden de gebruikersbevoegdheden ‘just-in-time’ ingericht. Deze bevoegdheden worden ook weer automatisch verwijderd na een vaste tijdsperiode en als iemand meer tijd nodig heeft, moet hij of zij de procedure van aanvraag en goedkeuring opnieuw doorlopen.

Als deze bevoegdheden zijn verleend, verloopt alle toegang via een beheerd werkstation (overeenkomstig gepubliceerde Privileged Access Workstation-richtlijnen). Dit wordt via beleid afgedwongen en compliance wordt nauw gecontroleerd. Deze werkstations gebruiken een vaste image en alle software op de machine is volledig beheerd. Om het risicogebied zo veel mogelijk te beperken, zijn alleen geselecteerde activiteiten toegestaan en kunnen gebruikers het ontwerp van het beheerwerkstation niet per ongeluk omzeilen aangezien ze geen bevoegdheden voor de machine hebben. Om de werkstations verder te beschermen, verloopt alle toegang via een smartcard en is de toegang tot elk werkstation beperkt tot een specifieke set gebruikers.

Ten slotte onderhouden we een klein aantal (minder dan vijf) ‘break glass’-accounts. Deze accounts zijn uitsluitend gereserveerd voor noodsituaties en worden beveiligd door ‘break glass’-procedures die uit meerdere stappen bestaan. Ieder gebruik van deze accounts wordt gemonitord en triggert waarschuwingen.

Detectie van bedreigingen

Er zijn een paar automatische checks die we regelmatig, om de paar minuten, doen om ervoor te zorgen dat de dingen werken zoals verwacht. Dit doen we zelfs als we nieuwe functionaliteit toevoegen die onze klanten nodig hebben:

• Detectie van schendingen: We controleren op patronen die een schending of inbreuk aangeven. We voegen regelmatig nieuw gevonden schendingen toe aan deze set detecties. We gebruiken ook geautomatiseerde tests die deze patronen triggeren, om te controleren of onze logica voor de detectie van schendingen goed werkt!
  
• Penetratietests: Deze tests worden doorlopend uitgevoerd. Met deze tests wordt op allerlei manieren geprobeerd om onze service in gevaar te brengen, en we gaan ervan uit dat deze tests steeds mislukken. Als dat niet zo is, weten we dat er iets mis is en kunnen we dit meteen verhelpen.
  
• Audit: Alle beheeractiviteiten worden geregistreerd. Elke onverwachte activiteit (zoals een beheerder die accounts met bevoegdheden aanmaakt) heeft tot gevolg dat er waarschuwingen worden getriggerd die resulteren in een uitvoerige inspectie van die actie om er zeker van te zijn dat die niet abnormaal is.
  

En hadden we al gezegd dat alle gegevens worden versleuteld in Azure AD? Maar dat gebeurt zeker. We gebruiken BitLocker om alle identiteitsgegevens van Azure AD te versleutelen wanneer ze niet worden gebruikt. En wat als de gegevens worden verzonden? Dan doen we dat ook! Alle API’s van Azure AD zijn webgebaseerd en gebruiken SSL via HTTPS om de gegevens te versleutelen. Alle Azure AD-servers zijn geconfigureerd voor het gebruik van TLS 1.2. Inkomende verbindingen over TLS 1.1 en 1.0 zijn toegestaan voor de ondersteuning van externe clients. Verbindingen over alle legacy versies van SSL worden expliciet geweigerd, ook SSL 3.0 en 2.0. Toegang tot gegevens wordt beperkt via op token gebaseerde autorisatie en de gegevens van elke tenant zijn alleen toegankelijk voor accounts die zijn toegestaan in die tenant. Daarnaast geldt voor onze interne API’s dat ze client/server-verificatie via SSL moeten gebruiken voor vertrouwde certificaten en uitgifteketens.

Ter afsluiting

Azure AD wordt op twee manieren aangeboden, en in dit bericht heb ik aandacht besteed aan de beveiliging en versleuteling voor de openbare service die wordt aangeboden en beheerd door Microsoft. Voor vergelijkbare vragen over onze National Cloud-instanties die worden beheerd door vertrouwde partners neem je contact op met onze accountteams.

(Opmerking: een eenvoudige vuistregel is dat als je URL’s eindigend op .com gebruikt voor het beheer of de toegang tot Microsoft Online-services, dit bericht betrekking heeft op hoe we onze data beschermen en versleutelen.)

De veiligheid van onze data heeft de hoogste prioriteit en we nemen dit dus ook ERG serieus. Ik hoop dat jullie dit overzicht van onze encryptie en beveiliging van data geruststellend en nuttig hebben gevonden.

Met vriendelijke groet,

Alex Simons (Twitter: @Alex_A_Simons)

Director van Program Management

Microsoft Identity Division

[bijgewerkt op 03/10/2017 om specifieke versiegegevens toe te voegen van ons gebruik van TLS en SSL]