Share via


Operationele overwegingen voor gegevens

In dit artikel vindt u meer informatie over operationele overwegingen voor gegevens voor uw configuratie. Er is informatie over hoe logboekbestanden en andere functies werken met betrekking tot Microsoft Entra-id, zoals gebruiksgegevens en operatorbeveiliging. U krijgt informatie over overwegingen voor fysieke beveiliging, naast richtlijnen over hoe het Microsoft Entra-team implementaties en wijzigingen definieert.

Logboekbestanden

Microsoft Entra ID genereert logboekbestanden voor controle, onderzoek en foutopsporing voor acties en gebeurtenissen in de service. Logboekbestanden kunnen gegevens bevatten over gebruikers, apparaten en Microsoft Entra-configuratie, bijvoorbeeld beleidsregels, apps en groepen. Logboekbestanden worden gemaakt en opgeslagen in Azure Storage in het datacenter waar de Microsoft Entra-service wordt uitgevoerd.

Logboekbestanden worden gebruikt voor lokale foutopsporing, beveiliging, gebruiksanalyse, systeemstatusbewaking en servicebrede analyse. Deze logboeken worden gekopieerd via een TLS-verbinding (Transport Layer Security) met Machine Learning-systemen van Microsoft, die zich in datacenters van Microsoft bevinden in het continentale Verenigde Staten.

Gebruiksgegevens

Gebruiksgegevens zijn metagegevens die worden gegenereerd door de Microsoft Entra-service die aangeeft hoe de service wordt gebruikt. Deze metagegevens worden gebruikt voor het genereren van beheerders- en gebruikersgerichte rapporten. Het technische team van Microsoft Entra gebruikt de metagegevens om systeemgebruik te evalueren en mogelijkheden te identificeren om de service te verbeteren. Over het algemeen worden deze gegevens naar logboekbestanden geschreven, maar in sommige gevallen worden verzameld door onze servicebewakings- en rapportagesystemen.

Operatorbeveiliging

Toegang tot Microsoft Entra ID door Personeel, contractanten en leveranciers van Microsoft (systeembeheerders) is zeer beperkt. Waar mogelijk wordt menselijke interventie vervangen door een geautomatiseerd proces op basis van hulpprogramma's, waaronder routinefuncties zoals implementatie, foutopsporing, diagnostische verzameling en het opnieuw opstarten van services.

Beheer istrator-toegang is beperkt tot een subset van gekwalificeerde technici en vereist voltooiing van een verificatievraag met phishingbestendige referenties. Systeemtoegangs- en updatefuncties worden toegewezen aan rollen die worden beheerd door het JIT-systeem (Just-In-Time) van Microsoft. Systeembeheerders vragen benodigde bevoegdheden aan met behulp van het JIT-systeem, waarmee de aanvraag voor handmatige of geautomatiseerde goedkeuring wordt gerouteerd. Na goedkeuring verheft JIT het account. Aanvragen voor uitbreiding, goedkeuring, uitbreiding van rollen en verwijdering van rollen worden vastgelegd voor toekomstige foutopsporing of onderzoeken.

Microsoft-personeel kan alleen bewerkingen uitvoeren vanaf een beveiligd toegangswerkstation, dat gebruikmaakt van een intern geïsoleerd sterk verificatie-identiteitsplatform. Toegang tot andere Microsoft-identiteitssystemen verleent geen toegang tot het werkstation voor beveiligingstoegang. Het identiteitsplatform wordt afzonderlijk uitgevoerd van andere Microsoft-identiteitssystemen.

Fysieke beveiliging

Fysieke toegang tot servers die bestaan uit de Microsoft Entra-service en toegang tot Back-endsystemen van Microsoft Entra, wordt beperkt door azure-faciliteit, on-premises en fysieke beveiliging. Microsoft Entra-klanten hebben geen toegang tot fysieke assets of locaties, daarom kunnen ze de RBAC-beleidscontroles (op rollen gebaseerd toegangsbeheer) niet omzeilen. Personeel met operatortoegang is gemachtigd om goedgekeurde werkstromen voor onderhoud uit te voeren.

Meer informatie: Azure-faciliteiten, -locaties en fysieke beveiliging

Wijzigingsbeheerproces

Als u wijzigingen in de service in datacenters wilt implementeren, definieert het Microsoft Entra-team de lagen van een implementatieomgeving. Het toepassen van de wijzigingslagen wordt beperkt door strikte afsluitcriteria. De hoeveelheid tijd die nodig is om een wijziging over lagen te rollen, wordt gedefinieerd door het operationele team en is gebaseerd op mogelijke effecten. Meestal duurt een implementatie tussen 1 en 2 weken. Kritieke wijzigingen, zoals beveiligingsoplossingen of hot fixes, kunnen sneller worden geïmplementeerd. Als een wijziging niet voldoet aan de afsluitcriteria wanneer deze wordt toegepast op een implementatielaag, wordt deze teruggedraaid naar de eerdere, stabiele status.

Resources

Volgende stappen